エージェントにコンテキストウィンドウで100万トークンを与えても、彼らはまだうまく機能しません。
これを保存してください :)
あなたは有能なモデルにいくつかのツールと長いタスクを与えます。最初の15ステップは素晴らしいです。集中力があり、正確です。質問に答え、ユーザーにうまく問いかけます。
しかし、会話が長引くにつれて、エージェントは迷い始めます。10ステップ前に下した決定に矛盾し始めます。捏造された情報でコンテキストウィンドウを汚染し始めます。ユーザーの好みが存在することは知っていますが、確実に取得できません。その間、あなたはなぜ壊れたのかを必死に解明しようとします。
そこで、あなたはさらに多くのものを求め始めます。タスクをより長く保持できる、より大きなコンテキストウィンドウを持つモデル。RAGパイプラインの最適化を試みます。インターネットでエージェントメモリのソリューションを探します。
そして、何も期待通りには機能しません。
その理由を理解することは、エージェントスタック全体の中で最も価値があり、最も理解されていない層へと私たちを導きます。
失敗はループである
エージェントが劣化する理由は、能力の不足ではありません。それはフィードバックループであり、4つのリンクがあります。4つすべてを認識すると、通常の修正策は解決策には見えなくなります。
リンク1：モデルはコンテキスト全体を均等に使用できず、コンテキストが埋まるにつれて悪化する。
これはほとんどの人が決して内面化しない部分です。モデルが情報を使用する能力は、コンテキストウィンドウ全体で均一ではありません。モデルは、最初と最後にあるものを確実に使用し、中間部分には体系的に注意を払いません。特に長い入力用に構築された場合でもです。さらに詰め込むと、信頼性はさらに低下します。これは、単語のリストを繰り返すような些細なタスクでも現れます。1つのディストラクターを追加するだけで、パフォーマンスは測定可能なほど低下します。複数の複合的なものを追加するとさらに悪化します。
つまり、モデルが実際に確実に推論できる効果的なコンテキストは、箱に書かれた数字よりもはるかに小さいのです。そして、さらに詰め込むにつれて、それは縮小します。
では、エージェントが何をするかを考えてみてください。エージェントは蓄積します。すべてのツール結果、履歴のすべてのステップ、自分へのメモがすべてコンテキストに追加されます。つまり、エージェントは自身が取るすべてのステップの品質を着実に低下させているのです。増大するコンテキストは、ステップごとのエラーを生み出しています。
リンク2：それらのステップごとのエラーは加算されるのではなく、乗算される。
エージェントがほんの数ステップしか取らないのであれば、わずかなステップごとのエラーでも問題ありません。しかし、エージェントは数十のステップを取ります。そして、失敗は蓄積されるのではなく、複合的に悪化します。5ステップで95%信頼できるエージェントは、20ステップのタスクでも95%の信頼性を維持するわけではありません。十分なステップを実行すると、コイン投げに近づいていきます。
それ以上に悪いことに、エラーは自己増強します。わずかに軌道を外れた1回のツール呼び出しは、次の呼び出しも外れる可能性を高めます。それを、ウィンドウが埋まるにつれてベースエラー率自体が上昇しているリンク1の上に積み重ねると、長時間 horizon のエージェントの特徴的な障害モードが得られます。それらは徐々に劣化するのではありません。耐えてから、突然崖から落ちます。
リンク3：タスクは長く、モデルはステートレスであるため、状態をモデルの外部に配置する。
言語モデルは呼び出し間で何も保持しません。すべての呼び出しは空白から始まります。モデルが知っているのは、フィードバックされたものだけです。したがって、長時間のタスクでは、状態を外部化する必要があります。スクラッチパッド。進捗ファイル。チェックポイント。ベクターストア。事実を抽出し、セッション間で再提供する専用のメモリレイヤー。
これは正しく、必要不可欠です。そして、それはクリーンな修正のように見えます。すべての重要なものは永続的なストレージに存在するため、エージェントは重要なことを何も忘れません。
リンク4：保存されたメモリは不活性であり、それを呼び戻すことは、それが解決するはずだった問題そのものを助長する。
ここでループが閉じます。モデルはデータベースを推論できません。コンテキストウィンドウにあるものだけを推論できます。したがって、メモリが役立つのは、それが呼び戻された瞬間だけです。そして、すべての取得はトークンを追加します。エージェントが進捗を追跡するために書くすべての要約は、後で再読する必要があるトークンです。履歴を圧縮して場所を空けるすべての圧縮ステップはロッシーであり、破棄される詳細は、後で重要性が明らかになる微妙なものであることがよくあります。
したがって、コンテキスト制限を打ち破るために構築したメモリシステムは、結局それを助長することになります。より多くのメモリはより多くの取得を意味し、それはウィンドウ内のより多くのノイズを意味し、それはより多くのステップごとのエラーを意味し、それが複合的に悪化し、それがそもそもメモリを探す原因となったのです。
ループは現実です。そして、コンテキストウィンドウの大きさは関係ありません。
容量は決して重要な軸ではなかった
ループが理解できれば、標準的な修正策の無益さは明らかです。
より大きなコンテキストウィンドウはそれを壊さない。 それは、崖に達する前に蓄積できる腐敗の上限を引き上げるだけです。一方、有効コンテキストに関するすべての研究は同じことを示し続けています：確実に使用可能な割合は、宣伝されている数字よりもはるかにゆっくりと成長します。あなたは実際には使用できない容量を購入しているのです。
より多くのメモリはそれを壊さない。 それは、すでにすべてを収容できないウィンドウに再び入り込もうとする材料の量を増やすだけです。
次のアーキテクチャもそれを壊さない。 アテンションに対抗する挑戦者、Mambaのような状態空間モデルとそのハイブリッドは、すべてのトークンをアドレス可能に保つのではなく、過去を固定サイズの状態に圧縮することで勝利します。これにより、線形時間の推論と、シーケンスとともに成長しないメモリフットプリントが得られます。しかし、想起は得られません。固定サイズの状態はすべてを保持できないため、設計上忘れます。大規模では、純粋な状態空間モデルは、正確に外部メモリが存在する目的、つまりシーケンス内の任意の時点から特定の事実を呼び戻すことにおいて、トランスフォーマーに劣ります。これが、真剣なポストアテンションの取り組みが、想起を行うために少数のアテンション層を保持するハイブリッドである理由です。状態モデルはそれができません。アーキテクチャを変更しても壁は動きません。反対側から壁に到達するだけです。
したがって、教訓は「より大きな数字を選べ」ではありません。容量は決して制約ではなかったということです。
制約は、各ステップでどのトークンがウィンドウを占有するかという決定の質です。
それがすべてのゲームです。利用可能な最大のコンテキストではなく、最小限の十分なコンテキスト。想起よりも関連性。切り捨ての偶然ではなく、第一級の操作としての意図的な忘却。研究はこれを直接裏付けています：数千の適切に選択されたトークンの順序保存取得は、完全な128Kウィンドウをモデルにダンプするよりも優れています。利点は、どれだけ入れるかではなく、何を入れるかを選択することにあります。
そして、これがほとんどのチームを陥れる罠です。なぜなら、選択を行うために彼らが手を伸ばすツールは、間違った形だからです。
類似性は関連性ではない
どのコンテキストを呼び戻すかを決定するデフォルトの方法は、類似性検索です。すべてを埋め込み、エージェントがコンテキストを必要とするときに、現在のクエリに最も近いベクトルを取得します。
しかし、類似性は間違った質問に答えます。それは近いものを返しますが、関連するものは返しません。そして、これらは非常に異なるものです。
エージェントが実際に答える必要がある質問は、決して「これに類似しているものは何か」ではありません。「このタスクと現在の状態を考慮して、何が重要なものに接続しているのか」です。それは関係性の質問です。依存関係、来歴、何が何に取って代わったか、どの決定がどの結果を引き起こしたかについてです。類似ベクトルを取得するように調整されたストアは、代わりにモデルにニアミスの山を渡します。そして、ニアミスはまさにリンク1からのディストラクターであり、崖に複合的に悪化するステップごとのエラーを引き起こすものです。
これが、修正策が埋め込みストアの前の薄っぺらいキャッシュではありえない理由です。知性はルックアップにあるのではありません。構造にあるのです。
誰も価格設定していない層
エージェントスタックで捉える最も重要な層は、モデルでもストアでもありません。その間の層です。モデルが何に注意を向けるかを決定する層です。
そして、実際にその仕事をするためには、3つの条件を満たす必要があります。
それはニュートラルでなければならない。 内部構造は常に変化しています。トランスフォーマーから状態空間、ハイブリッドへ。あるフロンティアモデルから次のモデルへ、数ヶ月ごとに新しい価格性能リーダーが現れます。単一のモデルに溶接されたコンテキスト戦略は、動く標的への賭けです。あなたの組織が実際に蓄積する価値は、そのコンテキスト、つまりエージェントが知っていることと行ったことの、苦労して得た構造化された記録です。それを1つのベンダーのメモリ機能にロックすると、あなたの最も耐久性のある資産を、あなたのものではないロードマップの人質にすることになります。単一のモデルの外に存在する選択層は、同じ組織化されたコンテキストが、あなたが実行するすべてのモデル、そしてまだ採用していない次のモデルにも役立つようにします。
それは水平でなければならない。 フレームワークのチェックポイントは1回の実行について知っています。モデルの組み込みメモリは1つのモデルの会話について知っています。ベクターインデックスは1つのコーパスについて知っています。本当のワークロードを実行し始めると、実際に重要な全体像を保持しているものはありません：多くのエージェント、多くのセッション、多くのモデル、すべてが1つの一貫したクエリ可能なコンテキストビューを必要としています。この記録システムの役割は、アプリやフレームワーク、ラボが保持する形ではありません。なぜなら、それぞれが自分のスライスしか見ていないからです。それはそれ自身の層であり、それらすべての上に水平に横たわっています。
それは構造化されていなければならない。 これが「単なるより優れたデータベース」との違いです。選択は関連性の問題であり、関連性は関係性です。コンテキスト、関係と依存関係、来歴と取って代わりの構造は、取得を選択に変えるものです。これはストレージとは根本的に異なるプリミティブであり、ループが要求するものです。
「ラボがこれを出荷してくれるのでは？」
明白な異論は、モデルラボがこれを吸収するだろうということです。彼らはメモリとコンテキストの機能を出荷し続けており、モデル自身のアテンションへの特権的なアクセスを持っています。
彼らはそうするでしょう。そして、その異論は半分正しいです。単一のアプリをラップする単一のモデルについては、ラボに任せることで十分であることがよくあります。それで問題ありません。
しかし、ラボのインセンティブは、自社のモデルをより stickier にすることです。それはポータビリティの反対です。単一のモデルの内部構造に融合されたキュレーションは、マルチモデル、組織全体のケースに役立ちません。真のコンテキスト基盤は、これらの機能と正面から競合するものではありません。それは、ラボが構造的に提供する傾向がない状況のために存在します：複数のエージェントとチームにわたって複数のモデルを実行し、エージェントが考える内容を決定する層が、今日たまたま実行しているモデルのベンダーによって所有されることを拒否する場合です。
そして、その傾向はこれをさらに強めます。モデルがより有能になればなるほど、より多く使用されます。より多く使用されればされるほど、組織はより多くのエージェントを実行します。より多くのエージェントを実行すればするほど、ニュートラルで、水平で、構造化された選択層の価値が高まります。
誰がこれを構築しているのか？
ここで Hydradb が登場します。ニュートラルで、水平で、構造化されています。類似性検索が平坦化してしまう関係、依存関係、来歴、取って代わりを保持します。時間的にバージョン管理され、選好を認識するため、何が真実であるかだけでなく、何がそれを置き換えたかも知っています。これにより、特定のエージェントが時間の経過とともに学んだことに対する可視性が解放されます。その構造が取得を選択に変えるのです。
内部では、Hydradb は階層型ストレージで動作します：アクティブなコンテキスト用のホットインメモリキャッシュ、ウォーム用のNVMe、コールド用のオブジェクトストレージ。コンテキストは、最近性と重要性によって昇格および降格されるため、モデルが推論するワーキングセットは意図的に小さく保たれます。モデルと、モデルが知りうるすべてのものとの間で。
すべてのエージェントが答えなければならない質問
アーキテクチャの議論、メモリ製品、コンテキストウィンドウの軍拡競争を剥ぎ取ってください。そのすべての根底では、すべての長時間実行エージェントが、すべてのステップで同じ質問に答えます。
知っているすべてのことの中で、今何について考えるべきか？
より大きなウィンドウはそれに答えません。それはエージェントに無視するものをより多く与えるだけです。ループは現実であり、永続的であり、どれだけの容量でもそれを閉じることはできません。
業界はまだ容量で買い抜けようとしています。それはできません。それが常に選択の問題であったことを内面化したチームは、機能するエージェントを出荷するでしょう。一方、他のすべてのチームは、ほとんど機能するエージェントを出荷するでしょう。
これは決してモデルの純粋な限界ではありませんでした。有限の予算の下で動作するものはすべて、何に注意を向けるかを選択しなければなりません。選択は今日の限界の回避策ではありません。それは、限界の下での推論が常に必要としてきたものです。
これが役に立ったなら、私をフォローしてください @eng_khairallah1 。このような AI コンテンツをさらに投稿しています。毎週、解説、コース、ツールを公開しています。
これがあなたにとって役に立ったことを願っています、Khairallah ❤️
