昨日の夜にぼんやりと考えていることを投稿したのですが、流石に背景を説明しなさすぎだし主語はデカすぎだしというので、私が考えていることを改めて書き出してみたいと思います。なお、LLMに関連するので自然言語処理に関連する人が主な対象という話ではありますが、個人的に今後画像音声系にも広がっていく気もするので、このブログ記事の中ではあえて限定はしていません。
LLMによるFew-shot/Zero-shotが当然の時代
LLMに代表される生成AIの登場により、ウェブサービスを含むあらゆるデジタル上で行われる行為が一変したのは言うまでもないでしょう。職種によってそれぞれ違った側面でその変化を捉えることができると思いますが、機械学習エンジニアとして特に私が感じた変化としては、データを作らなくなったし、性能を評価しなくなったということです。
LLMがウェブ上の大量のコーパスから言語モデルを学習する中で獲得した知識により、多くのタスクではLLM単体で解くことができるようになりました。つまり、解きたいタスクについて人間が事前に正解データを用意しなくとも良くなったということです。ここで言うデータとは、教師あり学習の枠組みで使われる、あるInputに対して想定されるOutputのペアのことを指しています。LLM以前は作成した正解データに対してモデルをfittingすることで学習させていましたが、LLMでその工程自体が不要になったり、fine-tuningでもあまり劇的な精度向上に繋がらないことから、そうした正解データ自体を作成するインベストに対するリターンが得られにくくなりました。また、LLM単体ではハルシネーションで間違った回答をする場合もあれば未知の事象について回答を得られない場合もありますが、それが起きたときにはプロンプトに追加で情報を入れ込むことで解決することが一般です。つまり何らかの知識をあらかじめ学習時に入れ込むのではなく、後から擬似的に外挿することができます。そのフォーマット自体が自然言語で柔軟に記述できるというのも、大きなメリットでしょう。
また、LLMを使う人間側のマインドセットとして、解けないならまあしょうがないかなと思ってしまうことも大きな変化だと感じます。別に自分が学習データを用意したわけでもないしモデル構造を工夫したわけでもないので、タスクの一部が解けないときにその理由を理解しようがないからです。それと同時に、LLMが要約したり翻訳したりと言葉で出力するようなタスクの複雑度が上がったことにより、LLMの出力を定量的かつ統一的に評価することが難しくなっています。LLMを使った解決法以外に、LLMに依存しない他の解法がサクッと実行できないというのも一員としてあるでしょう。あるLLMを使ってイマイチなら、他のLLMを試してみるほかありません。つまり、LLMでどれくらい正しく解けているかの評価が難しいために、人間が少数の結果を目で見て評価するしかなく、複数の手法を比較することが困難な状況です。
このように、与えられたタスクに対する正解データの作成が実質不要になり、後からでも調整できるインターフェイスにより試行錯誤の余地が生まれ、LLMが出力した結果の良し悪しに対して絶対的な評価が難しい。なんでも出来るけどほんとに出来ているかわからない、なにか不思議で不安定な状態だと私は感じています。
企業における機械学習エンジニアの役割
さて前置きが長くなりましたが、ようやく企業で働く機械学習エンジニアの話です。ここまで話したようにデータを作らず評価もしないLLMとの関わり方において、機械学習エンジニアがこれまでやっていた作業は大きく省略することができるようになりました。言ってしまえば、やることがなくなったようなものですね。これがAIに仕事を奪われたということなのでしょうか？w
もちろんタスク設計という大本の一番大事な作業は残っています。計算機にやらせたい複雑な処理を細かくシンプルなタスクに切り分けていく過程、とくに解けないタスクをいかに回避し、期待値を関係各所と調整することは特に重要です。ただ、それを(これまでの狭義の)機械学習エンジニアしか担えないとは思えず、LLM-nativeなソフトウェアエンジニアがドメイン知識と少しの機械学習の知識によって可能にしていく未来は十分ありえるでしょう。むしろ実装面ではソフトウェアエンジニアが圧倒的に得意ですし、プロンプトエンジニアリングは発想力と手数だと思っています。そうなると、実装から一歩引いたところから全体のタスク設計を行う、いわばプロダクトオーナーやプロダクトアーキテクトとしての側面が多くなってくるのではないかと思います。
最初のツイートで「機械学習が主軸ではないプロダクトの事業会社」と対象を絞ったのは、機械学習技術が中心にある事業であれば（機械学習を抜きにプロダクトが成り立たない事業であれば）まだ上記のタスク設計で機械学習エンジニアが大きく関わる余地があり、これまでの経験や知見を活かせるからです。LLM含む機械学習モデルの精度の評価および継続的なモニタリングは今まで以上に重要で、それ自体が他社との優位性につながるからです。後発や競合がパッとLLMで仕上げてくる以上のものを作り上げるために、人と金のリソースをつぎ込むはずです。
それとは逆に、機械学習が主軸ではなく、あくまで全体の歯車の一つとして機械学習が関与しているサービスであれば、機械学習エンジニアがバリューを発揮できる余地は少ないでしょう。プロダクトのいち機能という観点では事業に対するレバレッジもかけづらく、動いていれば正しさは二の次ということもあります。そのような中で必要になる能力は、機械学習的に正しく実装するということよりも、プロダクトに必要な機能を見極めそれを高速に検証するために作り上げ提供する、アイデアと機動力です。
（ただこのあたりは各社の事情やプロダクトの性質もあるでしょうし、私もあまり解像度は高くないし他社の事情はよくわからないので、下手なことは言えないなと思いながらふんわり書いています、ごめんなさい）
機械学習エンジニアの適応戦略
これまでを総合すると、post-LLMの時代に機械学習エンジニアは何の専門性をもってどんな仕事をするのか？ソフトウェアエンジニアとどう差別化していくのか？という話ですね。
コードを書いてプロダクトを作り上げる人たちをエンジニアと一括りにしたときに、その中の境界がだんだんと不明瞭になった感覚があります。LLMがコードすら書いてくれるようになったというのも一因です。もちろん仕事として高い品質のレベルでは専門性と知識、経験が要求される世界ですが、ある程度の動くモノを作ることが非専門領域のエンジニアでも可能になった、いわゆる知の高速道路がLLMにより延伸されたと思います。
そんな中で、事業会社の機械学習エンジニアは今後
プロダクトにおける機械学習の適用を考えられるプロダクトオーナーとして、機能設計やバリュープロポジション自体を考えていくエンジニア
フロントエンド/バックエンドなど機械学習の接合部分をより広く巻取りながら機能開発するフルスタックに近いエンジニア
LLM自体やプロンプトエンジニアリングの扱い方を極め、これからさらに導入が進むLLMプロダクトの中に入ってそのノウハウを横展開しオペレーションを含めて最適化していくLLMOpsエンジニア
に分かれていくのかなと感じています。
"機械学習"エンジニアとしての求められる役割や実際の業務はどうなっていくのかと、自分自身の今後のキャリア戦略をぼんやり考える1年でした。自分の今の職務経歴書は他社の人事やエンジニアにはどう映るのかがまだ分からないいま、これからの方向性を改めて考える年末になりそうです。