デモではなく、本番運用のために設計するAIシステム

本番AIシステムは、レイヤーとして捉えると考えやすくなります。ユーザーはアプリケーション層とやり取りします。アプリケーションはAIオーケストレーション層を呼び出し、そこからモデルとエージェントが呼び出されます。モデルとエージェントはナレッジ・データ層を参照し、エンタープライズシステムやAPIを通じて操作を行います。そのすべての下にインフラストラクチャとオブザーバビリティがあります。

アプリケーションをLLM APIに直接つなぐと、これらのレイヤーは一つの関数呼び出しに潰れてしまいます。それでも動きますが、その呼び出しでは提供できないものが必要になった時点で行き詰まります。非公開データに基づく根拠づけ、ユーザーごとの権限、単純なリクエスト向けの安価なモデル、回答の理由の記録、指示を含むドキュメントに対する防御などです。それぞれは特定のレイヤーに属するもので、後から追加するにはアプリケーションの再構成が必要になります。

同じ経路はライフサイクルとしても読めます。データ、モデル、オーケストレーション、アプリケーション、評価、オブザーバビリティです。データ品質は検索が返せるものの上限を決め、評価は何をリリースしてよいかを決め、オブザーバビリティは実際の失敗を評価セットに還元します。

モデルは、コンテキストウィンドウに入っているものをもとに回答します。したがってコンテキスト管理は設計上の課題です。どの指示、検索されたパッセージ、会話履歴、ツールの結果を、どの順序で入れるのか。会話が長くなるにつれて何を要約し、何を落とすのか。コンテキストは多ければよいわけではありません。無関係なパッセージは回答品質を下げ、コストとレイテンシを押し上げます。

エンタープライズシステムにおけるハルシネーションの多くは検索の失敗です。正しいパッセージが検索されなかったために、モデルがその空白を埋めてしまうのです。私たちは検索を生成とは別に計測し、ハイブリッド検索とリランキングで再現率を高め、検索されたソースへの引用を必須とし、ソースに答えが含まれていない場合はそう述べるようシステムに指示します。他のシステムに渡される出力については、自由記述の代わりにスキーマ制約付きの生成と検証を用います。

埋め込みは意味の類似性を捉えるため、セマンティック検索や、単一のパッセージで答えられる問いに適しています。一方、廃止されたポリシーを参照している契約はどれか、といったエンティティと関係をまたぐ問いには、ナレッジグラフや構造化クエリのほうが適しています。よく設計されたシステムは、両者の間でルーティングを行います。

推論コストはトークン数とモデルサイズに応じて増え、レイテンシは出力の長さと逐次的なモデル呼び出しの回数に応じて増えます。主な調整手段は、単純なリクエストを小さなモデルにルーティングすること、変化しないプロンプトのプレフィックスや繰り返される回答をキャッシュすること、コンテキストを削ること、オフライン処理をバッチ化すること、そして最初のトークンをすぐにユーザーへ見せるためのストリーミングです。逐次的に10回呼び出すエージェントは、どのモデルを使っても遅くなります。そのため、より高速なエンドポイントよりも、ツール呼び出しの並列化とステップ数の削減のほうが効果的です。

モデルのオブザーバビリティは、トレーシングをAIの経路まで拡張するものです。各リクエストについて、プロンプトのバージョン、検索されたドキュメント、ツール呼び出し、モデル、トークン数、レイテンシ、結果を記録し、機微な内容はマスキングします。トレースの上で、出力をサンプリングして自動および人による品質採点を行い、ユーザーフィードバックを追跡し、品質、リクエストあたりのコスト、回答拒否率のドリフトに対してアラートを出します。これがなければ、プロバイダー側のモデル変更やインデックスの劣化は、誰かが苦情を言うまで見えないままです。