AIエンジニアリング
AIプロトタイプの多くが本番で失敗する理由
プロトタイプが証明するのは、モデルが一度は良い回答を出せるということです。本番で求められるのは、誰も整備していないデータに対して、把握できるコストで、毎回許容できる回答を返すシステムです。両者の差を埋めるのはモデルの品質ではなく、エンジニアリングです。
· 4分で読めます · Starone エンジニアリング
AIプロトタイプは多くの場合、プロンプトとモデルAPI、そして作った本人が選んだ少数の入力で構成されます。答えている問いは一つ、そもそもモデルにこのタスクができるのか、です。これは有益な問いであり、ノートブックはそれに答える場として適切です。
本番が投げかける問いは別のものです。誰も選んでいない入力で何が起きるのか、モデルが遅いときや誤ったときにシステムはどう振る舞うのか、リクエストあたりのコストはいくらか、誰がどのデータを見てよいのか、品質が落ちたことをどうやって知るのか。私たちの見解では、プロトタイプの多くが行き詰まるのはモデルの力不足が原因ではなく、こうした問いが最初からプロトタイプに含まれていなかったためです。
デモは測るべきものを測っていない
デモの評価は、人が数件の出力を見て、もっともらしいと判断することで行われます。これは最良のケースに対するテストです。実際のトラフィックには、曖昧な依頼、想定外の言語による入力、スキャン品質の悪い文書、システムが拒否すべき質問、データの中に答えが存在しない質問が含まれます。
言語モデルは静かに失敗します。従来のサービスは答えられなければエラーを返しますが、モデルは答えられなくても流暢な文章を返します。正しい回答と流暢なだけの回答を区別する計測がなければ、提示された例の外でシステムがどう振る舞うのかについて、チームは何の根拠も持てません。
評価セットがなければエンジニアリングは始まらない
本番に向けて私たちが最初に作る成果物は、パイプラインではありません。評価セットです。代表的な入力に期待出力または採点基準を対応させ、難しいケースや敵対的なケースも含めてバージョン管理したものを指します。これが存在するまでは、プロンプトの変更も、モデルのアップグレードも、検索の調整もすべて推測にすぎず、リグレッションを見つけるのはユーザーになります。
評価セットは、他のテストスイートと同様に継続的インテグレーションで実行します。構造化出力は完全一致のチェックで検証できます。自由記述は別のモデルによるルーブリックベースの採点で検証できますが、採点側のモデル自体を人間の判断と突き合わせて抜き取り確認することが前提です。評価セットは本番から育てていくもので、報告された失敗はすべてテストケースになります。
データこそがシステムである
プロトタイプでは、文書は誰かがエクスポートしたフォルダです。本番では、所有者、権限、重複、矛盾、削除要件を伴って変化し続けるコーパスになります。地味な作業はここに集中します。表やスキャンされたPDFのパース、チャンク分割の方針決定、インデックスと原本の同期、そして撤回された文書をあらゆる場所から取り除くことです。
最も見落とされやすいのがアクセス制御です。検索が呼び出し元の権限を無視すれば、モデルはそのユーザーに閲覧資格のない文書を要約してしまいます。フィルタリングはプロンプト内の指示としてではなく、クエリ実行時に呼び出し元のアイデンティティに基づいて行わなければなりません。
レイテンシ、コスト、そしてテール
プロトタイプでは回答が遅くても許されます。待っているのは一人で、誰もトークンを数えていないからです。本番の経路にはレイテンシバジェットと単位コストがあり、どちらもテールに支配されます。複数のモデル呼び出しを連ねると、そのうちどれかが遅くなる、レート制限を受ける、タイムアウトする確率が掛け合わされて高まります。
エンジニアリング上の対応は、通常の手法を特殊な依存先に適用したものです。
- レスポンスのストリーミング。体感レイテンシを最後のトークンではなく最初のトークンまでの時間にします。
- タイムアウト、ジッターを加えた回数上限付きのリトライ、そしてプライマリが利用できないときのフォールバックモデルまたは縮退した回答。
- 単純なリクエストは小さなモデルに振り分け、大きなモデルは必要なケースのために確保します。
- 変化しないプロンプトプレフィックスと繰り返し発生する参照のキャッシュ。トークン使用量は機能単位、テナント単位で追跡します。
非決定性には変更管理が必要
同じ入力から異なる出力が生じることがあり、APIエイリアスの背後にあるモデルは、こちら側のデプロイなしに変わることがあります。リクエスト経路のどの部分に対する変更もリリースであり、コード変更と同じ管理が必要です。
出力が別のシステムに渡される場合は、出力を制約します。スキーマに沿った構造化出力を使用前に検証すれば、一群のパース失敗は、破損したレコードではなくリトライで済むようになります。
- プロンプト、モデルバージョン、検索設定、ツール定義を一つのリリース単位として扱います。
- 変動するエイリアスに追従せず、モデルバージョンを明示的に固定します。
- プロンプトをソース管理に置き、コードと同じようにレビューします。
- 評価セットで、置き換え対象より悪化していないと示された変更だけを昇格させます。
セキュリティとオブザーバビリティは後回しにされる
信頼できないテキストを読むモデルは、そのテキストから指示を受ける可能性があります。検索で取得した文書、メール、Webページを経由するプロンプトインジェクションは、この種のシステムを特徴づけるセキュリティ問題であり、プロンプトのレベルでは完全な対策がありません。頼りになる統制はアーキテクチャ上のものです。モデルにできることを制限し、読み取りの権限と実行の権限を分離し、取り消せない操作にはすべて確認を求めます。
もう一つ後回しにされるのがオブザーバビリティです。本番システムにはリクエストごとのトレースが必要で、そこにプロンプトのバージョン、取得したコンテキスト、ツール呼び出し、トークン数、レイテンシ、最終出力を記録し、個人データはポリシーに従って取り扱います。このトレースがなければ、回答が悪かったという苦情を再現できません。
プロトタイプがまさに正解である場合
以上はいずれも、プロトタイピングを否定するものではありません。素早く作って捨てられる実験は、タスクが実現可能か、ユーザーがその結果を求めているかを知るための最も安価な方法です。誤りは、実験を作り直さずにそのまま昇格させることにあります。私たちは原則として、プロトタイプを仕様として扱います。プロトタイプは良い出力がどのようなものかを示し、本番システムはその根拠をもとに設計します。
すべての出力を確認する少人数が使う社内ツールであれば、軽く堅牢化したプロトタイプで十分という場合もあります。投資は、誤った回答がもたらすコストに比例させるべきです。