プロンプトエンジニアリングってソフトウェア開発?と感じるあなたへ ~ LLM開発とソフトウェア開発の違いの話
この記事はLLM開発におけるプロンプトエンジニアリングに違和感がある人に向けた、捉え方を変えてみたら少し印象が変わるかも、という提案をするものです。
かくいう自分もなんだか普通のソフトウェア開発とは異なると感じていました。この違和感の言語化を試みると、すべてはブラックボックス化したインプットとアウトプットに集約される気がします。
- コンテキスト量が増えると回答の取りこぼしが発生する
- 突然"ない答え"を作り始める
- "一呼吸しましょう"など謎のおまじないが回答率を上げる
などなど。プロンプトを調整し、期待した結果が得られるかお伺いをたてる開発プロセスは、トライアンドエラーするしかないといった具合です。*1
そんな折に、たまたま聴いたのがStack Overflow podcastのこのエピソードでした。
ゲストのKatanforoosh氏は元々機械学習の研究者で、現在はスタンフォード大学でDeep Learning講座を受け持っています。その彼に対してホストから投げかけられた、 ”CSの学生がAIや機械学習開発を始めるために何に取り組めば良いか?” という質問への答えの中で、彼はこう述べました。
“AI開発とソフトウェア開発の根本的な違いは、Less predictable(予測がつきにくい)ということです。多くのソフトウェア開発はアイデアからリリースまでの見通しが立てやすいです。AIはモデルがいつ機能するか予測を立てるのが難しいです”
これを聴いたとき、自分はハタと手を打ちました。なるほど、LLMのような汎用的なモデルの登場によって、ソフトウェア開発にパラダイムシフトが起きたのだと。
機械学習モデルのプロジェクトでは、効果的に機能するまでモデルの改善を行うプロセスがプロジェクトに組み込まれています。これまでの機械学習を使ったプロダクト開発では最終的なモデルを利用するだけなので、ある種決定論的にアウトプットが得られました。
しかし、インプットでアウトプットの精度を向上できるLLMのような汎用モデルが登場したことにより、機械学習のチューニングがソフトウェア開発にシフトし、開発段階での改善プロセスが必要になったのです。
そのような開発では結果評価とフィードバックの仕組みが重要になります。最近自分の取り組んでいるAI開発プロジェクトでは、どのように結果評価を行うかの検討を始めました。現状LLM開発についてはいくつかのツールや考え方があるようです。
Langsmith
- 実装したプロンプトのテストや評価、ログの分析を包括的に行うサービス
- LangchainがサポートするLLMとの統合
AWS Bedrock
Open AI Production best practices
https://platform.openai.com/docs/guides/production-best-practices
- Open AIによる、AIを本番利用するためのMLOps戦略やコスト・マネジメントについて整理されたガイド
そんなわけで、最近自分はもうちょっと本腰入れてLLMOps(というのかな?)やプロンプトエンジニアリングについて学んでみようと思っています。面白いアイデアや実装ができたら、またシェアします。
*1:もちろん安定した結果を得るためにRAGを含めたさまざまな手法はあります