AIエンジニアの成長ストーリー～働き方編～

[[409282]]

この記事では、特に仕事の方法について取り上げます。エンジニアの中には非常に頭のいい人がたくさんいます。彼らは仕事の中で、多くの反復的で退屈なタスクに直面します。エンジニアリング思考でそれらに対処する方法は、近年の仕事と研究を通じてまとめられてきました。一般的には、次の側面があります。

01 反復プロセスの自動化

これはおそらくプログラマーの最も基本的な直感と認識です。 「CV エンジニア」の観点から自動化を理解することができます。Ctrl C+Ctrl V を使用して初めてコピー アンド ペーストするときは、コンポーネントまたはツールに抽象化できるかどうかを検討する必要があります。2 回目にコピー アンド ペーストするときは、コンポーネントの構造と設計がより明確になっている必要があります。 3 回目にコピーして貼り付けると、独自のコンポーネントやツールを使用できるようになります。

自動化はコード レベルに反映されるだけでなく、問題を解決する方法として捉えることもできます。自動化は繰り返しのステップにも使用できます。たとえば、ブログを書くときに画像ホスティングを使用する場合、一般的なプロセスは、画像をキャプチャして保存し、画像ホスティングにアップロードし、画像リンクを取得することです。このプロセスが自動化されていないと、人々は本当に諦めてしまうでしょう。それはとてもうんざりすることですが、実際には、Mac の Alfred Workflow では簡単に自動化を実現できます。たとえば、頻繁に会議を開催する場合は、会議の議事録のテンプレートを作成し、会議のたびにそれをコピーすることができます。重要なのは、反復的な動作を抽象化する方法を見つけることであり、この認識を持つことが重要です。

自動化は意識の問題なので、当然ながら非技術者にもそれが必要になりますし、おそらくそれ以上に必要になるでしょう。たとえば、管理スタッフは給与明細を手動で発行し、運用スタッフは 1 日に 1 回レポートをダウンロードして、レポートに対して統計やその他の処理を行う場合があります。これらのタスクは、実際には自動的に実行できます。

自動化には、Python の知識は必要ありません。前述のワークフロー画像ホスティングの例のように、コードの記述がより複雑な場合もあります。技術者以外の人にとっては、Excel の方が実用的であることが多いです。たとえば、統計、重複排除、スライス、フィルタリングなどはすべて、Excel でマウスを数回クリックするだけで実行できます。

ツールは重要ではありません。物事を「自動的に」実行できる限り、ツールがシンプルであればあるほど良いのです。

02 バッチ

バッチ生産と自動化は似ているかもしれませんが、バッチ生産は、ある種類の作業を一度に完了することに重点を置いています。中核は「バッチ」であり、自動化の中核は「自動化」です。バッチ処理は、一般的に、統一的な検索や置換、すべての文章に特定の文字を一律に追加する、データの一括ダウンロードなど、特定の作業内容を対象としています。

AI エンジニアはこれに非常に精通しているはずです。モデルトレーニングにおけるバッチは、実際にはバッチ処理の一例です。バッチは均一な特性を持つことが多いため、効率が向上するだけでなく、個別操作で起こり得るエラーも回避できます。たとえば、複数の列があるテキスト ドキュメントで数字を含む行を抽出するには、SublimeText を使用して正規表現ですべての数字を検索し、行を選択してコピーします。

大量生産では、物事を「一発で」できるかどうかが常に重視されます。これは多くの場合、運用レベルに反映されます。たとえば、荷物を取りに階下に行く必要がある場合、テイクアウトと一緒に受け取ることができます。または、会議で話し合うトピックを一緒にまとめるなどです。つまり、効率を向上させるために、同様のアクションを同時に完了するようにしてください。

バッチ処理の時間もあります。つまり、一つのことを行うためにまとまった時間を使うということです。私個人としては、通常、午前中は静かな時間として選び、集中力を必要とする作業に集中し、メッセージをチェックせず、基本的に動かないようにしています。

03 シンプルにする

ここでのシンプルさには 2 つの意味があります。1 つ目は一般的な意味での「シンプルさ」であり、2 つ目はシンプルさの大道における「シンプルさ」です。最初のレベルはシンプルさに似ており、通常は初期または一時的な解決策として使用されます。2 番目のレベルのシンプルさは、複雑で冗長な外観を通じて本質に到達することです。システム全体のレベルの明快さと美しさは、多くの場合、継続的な進化と改善の産物です。ここでは、AIエンジニアのビジネス視点から2つの側面について説明します。

製品デザイン

製品の設計段階では、ニーズを満たすことができる限り、シンプルで継続的な最適化を選択する必要があります。私が「シンプルな」デザインと考えるものを具体的に述べてみましょう。一方では、それぞれが単一の明確で不可欠な機能を備えたさまざまなモジュールがあり、他方では、各モデルのコア機能がその基本的な前提と一致しています。モジュールには、一部のケースにのみ適用される特別な設計があってはならないことに注意してください。

AIエンジニアを例にとると、Googleの製品はDoc2vecやBERTなど「シンプルな」標準を満たしていることが多いのですが、修正された論文の多くはそれを複雑にしています。産業界のエンジニアとしては、実はGF（Google、Facebook）の最先端の研究成果に注目するだけで十分です。他（特に大学のもの）はあくまで参考程度にとどめてください。自分の能力以上のことはやってはいけません。

製品アーキテクチャ

建築設計自体は非常に複雑な問題です。既存の機能の組み合わせのように見えますが、選択に難しさがあります。シンプルなアーキテクチャは、全体的な複雑さの観点からより考慮されており、モジュールとコンポーネント間の相互作用はシンプルです。これを実現するには、現実から始めて、現時点で最も適切なアーキテクチャを選択し、スケーラビリティを考慮し、システムを進化させ続ける必要があります。

特に注意が必要な点は 3 つあります。まず、過剰なデザインです。優れたアーキテクチャは、最初から適切に設計されるのではなく、進化していくことが多いです。第二に、新しい技術を追求します。それ自体は良いことですが、建築設計者としては、さまざまな要素を考慮する必要があります。技術レベル以外にも、新しい技術が安定しているかどうか、チームが持ちこたえられるかどうか、オーナーの将来計画など、すべてが非常に重要な要素です。 3番目に、1つのステップで完了させたいです。実際、アーキテクチャの調整は段階的に実行されることがよくあります。最初に特定のモジュールを調整してから、次のモジュールを調整することが可能です。場合によっては、システム全体を覆して再設計する必要があります。建築設計は一度きりの仕事ではありません。

04 限界収益の最大化

経済学では、限界収益とは、投入量を 1 単位増加させることで得られる利益を指します。限界収益は、収益が減少する傾向があります。たとえば、お腹が空いているときは、最初に食べるパンが一番おいしいのですが、食べ進めていくとだんだんおいしくなくなってしまいます。職場では、限界利益を最大化する仕事を優先すべきです。簡単に言えば、これは 2-8 ルールです。つまり、リソースの 20% を使って、効果の 80% を生み出す仕事を行うということです。

手動部分を優先する

長期的には、10年以上前の電子商取引と同様に、ほぼすべての企業がAIに直面することになるでしょう。これは「一部の」企業に限ったことではありません。この点に関しては、AI を電気に例える Andrew Ng 氏の見解に私はより同意します。客観的な観点から見ても、AI テクノロジーは、カスタマー サービス ロボット、検索、推奨など、多くの面でビジネス効率を向上させることができます。唯一の違いは、実装の程度です。 AIを部分的に導入している企業でも、最適化の余地はまだあるかもしれません。全体の効率を上げるための技術があることを知っておくだけで、あとは少しずつ最適化していくだけです。

新しい技術を重視

理由が何であれ、それは新しいテクノロジーを使用しない理由にはなりません。特に AI の分野では、ディープラーニングの有効性は疑う余地がありません。多くのシナリオで、従来の方法に取って代わったり、既存の結果をさらに改善したりすることができます。業界の一員として、新しい方法や技術が登場したときは、たとえそれがうまくいかなかったとしても、ましてやその効果が素晴らしいものであったとしても、学ぶべきです。

さまざまなアプローチのコアコンポーネントを組み合わせる

方法やモデルが異なれば、焦点となる点も異なるため、効果も異なる可能性があります。現実には、たとえ最新かつ最良の方法であっても、1 つの方法セットですべての問題を解決できないことがよくあります。ここで私が言いたいのは、異なる手法にはそれぞれ異なる焦点があるからこそ、それを活かして複数の手法を組み合わせて選択し、それぞれの手法の利点を最大限に活用する必要があるということです。