AIシステムの健忘症はモデルの問題ではなく、インフラの問題だ
この光景を、AI製品チームはあまりにもよく知っている。あるユーザーが20分かけてアシスタントとのコンテキストを構築する。予算、食事制限、変更できない日程、家族の好み。そして3ターン後、システムはその会話がまるで存在しなかったかのように振る舞う。ユーザーはサポート部門に連絡する。サポートは製品チームにエスカレーションする。製品チームはモデルプロバイダーに連絡する。そしてモデルプロバイダーは、正当にも、自社のモデルは設計通りに動作したと答える。
なぜなら、モデルは何も忘れていないからだ。モデルはそもそもその情報にアクセスできなかったのだ。
この区別は技術的で些細なことに見えるが、そのコストを計算するまでの話だ。ビジネス向けアシスタントにおける継続性の失敗は、単なるユーザー体験の摩擦ではない。それはシステムが、モデルに推論を求める前に、世界を誤って再構築しているというシグナルだ。そのパターンが1日数千セッションに渡って積み重なると、コストはサポートの過負荷だけで測れるものではなくなる。失われた信頼、放棄されたワークフロー、実現しないROIとして現れる。
良いニュースは、この問題には解決策があるということだ。悪いニュースは、ほとんどの組織がいまだに問題の本質がどこにあるかを理解していないということだ。
モデルは無実だ。パイプラインが犯人だ。
大規模言語モデルは、設計上、ステートレスな存在だ。APIへの各呼び出しは独立した数学的イベントだ。モデルはターン間に記憶を持たず、前のセッションにアクセスする手段もなく、ユーザーがすでに予算は4,000ドルだと言ったことを知る術もない。各ターンでモデルが目にするのは、そのターンにシステムが送信した内容だけだ。それ以上でも以下でもない。
つまり、継続性のあらゆる幻想、アシスタントが「覚えている」ように見えるすべての要素は、リクエストがモデルに届く前に何が起きるかにのみ依存している。このプロセスには技術的な名称があり、戦略的な重要性がますます高まっている。それがコンテキストパイプラインだ。
適切に構築されたコンテキストパイプラインは、各ターンで3つのフェーズを実行する。第一に、ハイドレーション：以前に何が言われたかを捉えたベクトル埋め込み、ユーザーのメタデータ、関連する履歴をストレージから抽出する。第二に、アセンブリ：その生の素材をフィルタリングし、圧縮し、一貫性のあるペイロードに構造化する。第三に、実行：コンパイルされたペイロードを推論エンドポイントに送信する。システムが記憶を演じることに失敗するとき、その失敗はこれら3つのフェーズのいずれかで発生している。モデルの内部ではない。
これらの失敗を診断するエンジニアリングチームは、パイプラインが最も頻繁に壊れる4つのゾーンを特定している。1つ目は不完全なリトリーバル：システムがストレージから正しい情報を抽出できない。2つ目はロッシーな圧縮：ローリングサマリーが正確な制約を無用な一般論に劣化させる。3つ目はコンテキストの希釈：モデルに大量の素材を送りすぎることで、関連データがノイズの下に埋もれる。4つ目はアセンブリエラー：誤った順序で並べられた情報ブロック、欠落した区切り文字、またはユーザーの修正より前に注入された古いバージョンの情報だ。
これらの失敗ゾーンはいずれも、ユーザーの視点からは同じように見える。つまり、自分が伝えたことを忘れたアシスタントだ。しかし、それぞれはスタックの全く異なるコンポーネントを指し示している。リトリーバルの失敗をシステムプロンプトの書き直しで解決しようとするのは、ハードドライブが壊れているサーバーにRAMを追加するようなものだ。
デモで成功する実装と実際の本番環境で成功する実装を分ける本物のアーキテクチャ
デモで機能するAI実装から、実際の本番環境で実負荷のもとで機能する実装へのジャンプは、大部分において問題の各レイヤーに対して正しいメモリアーキテクチャを選択することにかかっている。唯一の解決策は存在しない。それぞれのアプローチはあるボトルネックを解消し、別のボトルネックを生み出す。
スライディングウィンドウ、つまり直近のNメッセージを含めて残りを無視するアプローチは、ゼロインフラのオプションだ。数時間でデプロイできる。そして、長いセッションの冒頭で設定されたあらゆる制約が、アクティブなコンテキストから消えることを保証する。短いステートレスなトランザクションを処理するアシスタントには十分だ。しかし、20ターン前に設定された条件に依存する決定を含むビジネスワークフローにとっては、罠だ。
ベクトルに対するセマンティック検索は、その問題を部分的に解決する。直近のNメッセージを取得する代わりに、システムは現在のクエリを埋め込み、データベースから歴史的に最も関連性の高いフラグメントを取得する。ユーザーが会話の冒頭で述べた情報に依存する質問をした場合、数十ターンが経過していてもベクトル検索はそれに到達できる。このコストは些細ではない。インデックスインフラ、ランキングしきい値の調整、鮮度ロジック、リトリーバルパフォーマンスの継続的な評価が必要だ。ベクトルデータベースは数学的な近接性をマッピングするものであり、運用上の重要性をマッピングするものではない。この区別は継続的な調整を要求する。
ベクトル検索が構造的に失敗するのは、ハード制約においてだ。最大予算、食物アレルギー、口座番号、契約上のSLA。これらはセマンティックな類似性ランキングで競い合うべき情報ではない。検索によるリトリーバルに頼ることなく、システムが各ターンで確実に注入できなければならない事実だ。エンティティストア、これらの制約を個別の更新可能なフィールドとして保存する構造化データベースは、決定論的なリトリーバルによってその問題を解決する。ユーザーが予算を4,000ドルから5,000ドルに修正した場合、バックエンドは特定のフィールドを更新する。テキストサマリーの末尾に修正を追加するのではない。格納方法に曖昧さがないため、モデルは常に正しい数値を受け取る。
エンティティ間の複雑な関係には、グラフベースのリトリーバルがさらなる精度のレイヤーを加える。システムがユーザーの娘はピーナッツアレルギーがあり、配偶者は通路側の席を好み、両親は1階の部屋が必要だということを把握する必要がある場合、セマンティック検索はその3つの事実を取得できるかもしれないが、どの制約がどの人物に適用されるかを見失う可能性がある。グラフアーキテクチャはそれらの関係をエンティティ間の明示的なリンクとして格納し、リトリーバル中にそれをたどることができる。オントロジー設計からグラフの継続的なメンテナンスまで、運用上のオーバーヘッドはかなりのものだ。しかし、制約が本質的にリレーショナルである医療、旅行、金融サービスなどのドメインでは、その複雑さはオプションではない。
本番環境で最も堅牢なアーキテクチャは、これらのレイヤーを階層化されたスタックに組み合わせる。直近の会話の流れを維持するための直近ターンバッファ、セッション内のファクトや中期的なピボットのためのベクトルレイヤー、ユーザープロファイルと長期的な設定のための構造化データベースだ。このスタックの上で、コンテキストルーターがメッセージのタイプごとにどのレイヤーをアクティブにするかを決定する。シンプルな確認メッセージはどのデータベースも照会する必要がない。予約リクエストはエンティティストア、最近の履歴、ツールの状態をアクティブにする。目標は可能な限り重いパイプラインではない。目標は可能な限り選択的なパイプラインだ。
誰もシステムが本番で失敗するまで構築しないオブザーバビリティ
このパターンは、構造的と見なすに十分なほど繰り返される。チームがアシスタントをデプロイし、システムが「覚えていない」というユーザーレポートを受け取り、最初の反応はシステム指示を書き直すことだ。大文字でフレーズが追加される。「ユーザーの予算を必ず覚えておくこと」。動作は改善されない。モデルをより高価なバージョンにアップグレードする。動作はやはり改善されない。最終的に誰かが障害発生時にモデルに届いた正確なペイロードを確認し、予算がデータベースからリトリーブされなかったこと、またはリトリーブされたがアセンブリ前にフィルタリングされたこと、またはコンテキストには含まれたが3万トークンのプロンプトの末尾に置かれてモデルが実質的に処理しなかったことを発見する。
これらのシナリオのそれぞれは、全く異なる介入を意味する。パイプラインの状態が推論の瞬間に正確に可視化されていなければ、診断は当て推量だ。そしてAIシステムにおける当て推量にはコストがある。無駄なエンジニアリング時間、何も解決しないプロンプトのイテレーション、そして技術チームがスタックの間違った場所で作業している間にユーザーの信頼が累積的に低下することだ。
決定論的なトレーシングがこれを解決する。推論の直前の正確な瞬間に、完全にコンパイルされたプロンプトを、アクティブなルーティング決定とツールの生の出力とともに記録する。この可視性があれば、診断上の問いは「なぜモデルはそのように振る舞ったのか」ではなく、「モデルは正確に何を受け取ったのか」に変わる。それは、リクエストログありとなしでマイクロサービスをデバッグする違いだ。
オフライン評価は本番環境でのトレーシングを補完する。セッションの冒頭で設定された制約に正しい答えが依存する複数ターンの会話でテストセットを構築することで、デプロイ前にシステムがそれらのデータを正しくリトリーブし使用するかどうかを測定できる。このコンテキストで重要なメトリクスは、モデルのベンチマークメトリクスではない。リトリーバルのヒット率、メモリリコールの精度、注入されたコンテキストの実際の利用率、リトリーバルレイヤーの累積レイテンシだ。これらのメトリクスなしでは、チームは独立したテストでは良く見えるが、システム全体の動作を予測しないプロキシを最適化してしまう。
競争優位はもはや選択したモデルにはない
フロンティアモデルが推論能力において収斂するにつれ、差別化はそれを取り巻くインフラへとシフトする。2023年に最大のモデルをデプロイした組織は、より小さいモデルをデプロイしたものの、より精密なコンテキストパイプラインを備えた組織に対して、もはや構造的な優位を持たない。エンタープライズデータチームが発表した研究は、構造化されたコンテキストなしのスキーマで動作するシステムと、管理されたコンテキストレイヤーを持つシステムとの間で、回答精度に実質的な差があることを示している。その差はいかなるプロンプトの調整でも補うことができない。
これが製品の戦略的計画にとって意味することは小さくない。第一に、モデルプロバイダーの選択はメモリアーキテクチャよりも決定的でなくなる。第二に、自社所有のオープンなインフラ上でコンテキストレイヤーを構築したチームはポータビリティを持つ。知識表現を再構築することなくモデルを変更できる。制約をプロプライエタリなプロンプトに直接注入したチームにはその柔軟性がない。第三に、コンテキストの統治、つまり誰がエンティティストアのどのフィールドをどのような条件で、どの監査を経て更新できるかが、製品チームがデータチームに無期限に委任できない組織アーキテクチャの問いになる。
エンドユーザーにとって最も有能に感じられるアシスタントは、必ずしも最も多くのパラメータを持つモデルで動作しているものではない。多くの場合、それは背後に最も厳格な状態管理システムを持つものだ。それが見かけ上の知性とスケールにおいて持続可能な知性との違いだ。そして後者を構築するには、コンテキストパイプラインを他のあらゆる重要なインフラコンポーネントに適用するのと同じレベルのエンジニアリング規律で扱うことが必要だ。インターフェースコントラクト、スキーマバリデーション、バージョニング、そして継続的なオブザーバビリティを伴って。
コンテキストの失敗をモデルの失敗として診断し続ける組織は、最も必要としていないスタックの部分に投資し続けることになる。
