検索システムを定常的に変更した後、モデル自体が同じで、サービスが正常に稼働し、デプロイ前のチェックにも成功しているにもかかわらず、ドキュメントアシスタントが時間内に応答できなくなることがある。その理由は、変更によってモデルに送られるコンテキストが大きくなり、生成が長引き、推論サーバーの前でリクエストが蓄積する一方、アプリケーションコンテナをロールバックしても、別の場所で変更された検索設定までは戻らない可能性があるためだ。
この仮想的なシナリオは、AIアプリケーションの運用における実務的な問題を示している。実際に何がデプロイされたのか。生成AIアプリケーションでは、システムの挙動を決めるのはモデルのバージョンだけではない。入力、前処理、プロンプト、インデックス、埋め込みモデル、ツールのコントラクト、サービス設定は、それぞれ個別に変化し得る。
リリースの境界を明確にする
本稿は、共にテストされたすべてのコンポーネントへの参照を保持する、バージョン管理されたリリース記述から始めることを提案している。そこには、リリース識別子、アプリケーションのバージョン、モデルのバージョン、プロンプトのバージョン、インデックスのバージョン、埋め込みのバージョン、分割および再ランキングのパイプライン、実行設定、評価セットに加え、直前のバージョンを含めることができる。
これらの参照先は、保存され、検査可能な設定または成果物を指すべきであり、秘密情報の値ではなく、その参照を保存する必要がある。実行バージョンには、トークン上限、バッチ処理、タイムアウト、リソース配分を含めるべきだ。ツールを呼び出すアプリケーションでは、ツールのスキーマとアダプターのバージョンも含めなければならない。
この記述によって逐語的な再現性が保証されるわけではない。外部サービスは変化する可能性があり、生成は依然として非決定的であり、一部のプロバイダーは固定されたモデルスナップショットを提供していないためだ。したがって、データが継続的に変化する場合には、こうした制約に加え、データの取得時点とインデックス作成設定も記録すべきである。複数の設定ストアを順番に更新することは、アトミックなリリースを構成しない。
モデル呼び出しだけでなく完全なタスクをテストする
HTTPリクエストが成功しても、ユーザーが正しい回答を得たことにはならない。評価ゲートは、アクセス可能な出典を引用すること、正しい製品バージョンを考慮すること、証拠がない場合に指示を捏造しないことなど、製品そのもののタスクを測定すべきだ。
本稿は、通常の質問、過去の失敗、曖昧なリクエスト、証拠が不足しているケース、権限境界を回避しようとする試みを含む、バージョン管理されたデータセットを推奨している。また、チューニングには使用していないセットも保持すべきだ。スキーマの正しさ、ツールの引数、引用識別子、権限の適用には決定論的なチェックを適用できる。一方、意味的な判定には明確な基準と人によるレビューが必要である。別のモデルによる判定はケースの順位付けには役立つかもしれないが、正解の基準ではない。
リリースは、検索から生成、出力検証までの完全な経路で実行し、その後、入力長、言語、製品バージョン、証拠が乏しいケースなど、重要なセグメント別に結果を確認すべきだ。また、候補リリースを確認する前に、権限違反を一切認めないこと、品質低下の限度、レイテンシーとコストの予算を含む受け入れ基準を定めなければならない。
ユーザーが感じるワークロードとコストを測定する
1秒あたりのリクエスト数をテストするだけでは不十分だ。入力と出力の長さ、同時実行レベル、アクセスの急増、ウォームおよびコールドメモリの挙動に分けてテストを実施すべきである。ストリーミング応答では、最初のトークンが現れるまでの時間を、後続トークンのレートおよび完了時間から分け、キューでの待ち時間も測定する必要がある。
本稿は、まずリクエスト全体のトレースを取得し、その後、検索、再ランキング、キュー、初期化段階と生成段階、後続の呼び出しを調べることを推奨している。異なる段階のパーセンタイルを集計して包括的なパーセンタイルと見なすべきではない。各測定は異なるリクエストを表している可能性があるためだ。
また、トレースと構造化されたリクエストログで同じ識別子をリリースに関連付け、品質、レイテンシー分布、エラー、トークン使用量、代替経路へのフォールバック率を追跡すべきだ。リクエストあたりのコストが低いからといって、完了したタスクのコストが必ずしも低いとは限らない。そのため本稿は、失敗した試行を含めて成功したタスクのコストを計算し、成功の代替指標を使用する場合にはそれを明確に示すことを提案している。
ロールバックではモデルの重みだけでなく依存関係も戻す
候補リリースは、現行リリースを利用可能なまま、トラフィックの限定的な割合に投入できる。ただし、段階的テストを成功させるには、候補と制御のシグナルを比較し、候補が重要な負荷セグメントにさらされるようにしなければならない。意思決定者、停止条件、最低監視期間を定め、展開開始前に復旧手順を実行しておく必要がある。
候補リリースが検索インデックスをその場で置き換える場合、リクエストを古いアプリケーションイメージに振り向けるだけでは不十分だ。インデックスの互換性のあるバージョンを保持するか、可逆的な移行を設計する必要があり、現在実行中の削除操作や権限取り消しも考慮しなければならない。また、メール送信やレコード変更のようなツールの副作用を、冪等性と適切な承認境界によって保護しつつ、実行中の生成を排出またはキャンセルする方針も定めるべきだ。
なぜこのアプローチが重要なのか
これらの提案の実務的な価値は、AIアプリケーションの管理を「どのモデルを使うのか」という問いから、より広い問いへと移す点にある。すなわち、悪い回答を生成した完全なリリースを特定し、既知で互換性のあるバージョンを復元できるか、という問いだ。これは、役立つ最小限の構成が既存のリポジトリ内に存在し得ることを意味する。その構成は、リリース記述、評価タスク、代表的な負荷テスト、リリースに関連付けられたトレース、実際に行うロールバック訓練から成る。
制約も明らかである。限定的なテストセットを通過したからといって、セキュリティ上の欠陥やまれな失敗がないことは証明できない。また、本番環境からのフィードバックは選択的であり、回答の正しさと常に同じとは限らない。そのため、人によるレビューと、アプリケーション、プラットフォーム、データの接点における責任の明確化は、完全に自動化できる単なる追加機能ではなく、運用アーキテクチャの一部であり続ける。