AIエージェントにおける自己強化メモリループ:原因と対策

「記憶された結論が新たな証拠となること」

目次

永続メモリは、エージェントを毎回説明し直すツールから、コンテキストを引き継いで機能する存在に変えます。ただし、ステートレスなチャットが回避する失敗モードが開かれます。解釈がメモリとして保存され、事実として取得されて、さらに強固なバージョンを正当化するようになるのです。

これは自己強化的なメモリループです。このメカニズムに悪意、壊れたプラグイン、または異常なプロンプトは必要ありません。通常のキャプチャパイプラインがアシスタントの出力を保存し、通常の検索パイプラインがそれをコンテキストとして提示し、モデルは取得されたテキストを証拠として扱うのが普通だからです。

これは、重要な点でハルシネーション(幻覚)とは異なります。ハルシネーションは会話が終わると消えますが、永続メモリに昇格したハルシネーションは、それを生み出したセッションより長生きし、数週間後に無関係なコンテキストで再び現れ、反復によってのみ表面的な信頼性を獲得することがあります。より広いメモリモデルでは、この問題はワーキングメモリ、構造化ステート、検索メモリの3つの独立した契約の内側に位置します。これはAIシステムメモリハブの一部であり、短期・長期・構造化メモリの設計方法、検索メカニズム、トレードオフ、失敗モード、実際のパターンについて説明しているAIアシスタントにおけるメモリシステムを参照してください。この記事では、古びたメモリや矛盾するメモリが最も一般的な本番環境での失敗であることをすでに指摘しています。この記事では、なぜその特定の失敗が繰り返し起こるのかについて、一段深く掘り下げます。

光る半透明のメモリタイルのスタックがループに渦巻き、各タイルが前より大きくなっている

メモリシステムについて問うべき価値のある問いは、単にそれが覚えているかどうかではありません。未来の推論に対して何が証拠として許可されているのか、ということです。それを適切に答えるためには、ユーザーが明示的に述べたこと、ツールが実際に観察したこと、外部ドキュメントが報告したこと、そしてモデルが単に推論または要約したことを区別する必要があります。それらのカテゴリが「メモリ」という単一の区別されないプールに混同されると、生成された結論は観察と区別がつかなくなります。メモリシステムは、効果的に推論を前提として洗浄(ロンダリング)したことになります。その区別を強制しながら1つのプロバイダーを実行するための実用的な解説については、Hermes Agent向け Mnemosyne:ローカルメモリ クイックスタートを、そして8つ以上の主流プロバイダーがこの軸でどのように異なるかについては、エージェントメモリプロバイダー比較を参照してください。

自己強化的なメモリループとは?

最も簡単なバージョンには固定された形があります。ユーザーが何かを述べ、エージェントがそこから結論を推論し、メモリがその結論を保存し、将来のセッションがそれを想起し、エージェントが想起された声明を証拠として扱い、より強い結論を導き出し、それをメモリに書き戻す。その後、サイクルは繰り返され、毎回わずかに自信のある声明となり、パイプラインに新しい観察が1つたりとも入力されることはありません。

flowchart LR A[ユーザーがXを述べる] --> B[エージェントがYを推論する] B --> C[メモリがYを保存する] C --> D[将来のセッションがYを想起する] D --> E[エージェントがYを証拠として扱う] E --> F[エージェントがより強いY2を導き出す] F --> C

デプロイメント後にキャッシュ設定を変更したことでデプロイメントが失敗したとエージェントに伝える開発者を考えてみましょう。キャッシュ設定がおそらく失敗の原因だろうという推論は、それが現在のコンテキスト内に留まる限り有用な推論です。損傷が始まるのは、自動メモリ抽出ツールが「キャッシュ設定がデプロイメント失敗の原因だった」という平坦な声明を事実として保存したときです。1週間後、無関係な2回目のデプロイメントが失敗し、エージェントは保存された声明を検索し、キャッシュレイヤーには不安定な履歴があると推論し、さらに一般的な信念として書き戻されます。3回目のパスまでに、保存されたメモリは「キャッシュレイヤーは信頼できないことが知られており、交換すべきである」と読めるようになります。これは、新しい証拠ゼロから構築された、自信に満ちた制度的な主張です。

従来のデータベースよりエージェントの永続メモリがこれを悪化させる理由

従来のアプリケーションデータベースには明示的な書き込みパスがあります。既知のユーザー、APIコール、またはトランザクションによってフィールドが変更されるためです。エージェントメモリシステムには通常、多くのより多くの書き込み側があります——ユーザー、アシスタント、ツール結果、自動ターンキャプチャフック、事実抽出ツール、セッションサマライザー、反射パス、統合プロセス、場合によっては別エージェント——そしてそれと同じ数の読み取り側があります。自動プロンプトインジェクション、セマンティック検索、サブエージェントツールが含まれます。1つの読み取り側の出力が別々の書き込み側の入力になることができるようになった時点で、システムは単純なストレージではなくフィードバックループとなり、「誰がいつこれを書いたのか」という通常のデータベースの直感が適用されなくなります。

メモリフィードバックの主な形態

自己強化は1つのメカニズムではありません——それは少なくとも7つの関連するが異なるパターンとして現れ、メモリプロバイダーは1つには耐性があり、もう1つには脆弱である可能性があります。

アシスタントの自己エコー

最も簡単なケースは、アシスタントのメッセージが自動的に保持される場合に発生します。モデル自身の以前の回答が、次の回答のための文脈証拠になるのです。それは自動的に回答を誤りものにしますが、認識論的ステータスを变更します——生成された言語が永続的なコンテキストになったということです。最も安全な一般的なルールは、ユーザーとツールの観察はメモリの候補になり得るが、アシスタントの結論は、独立した昇格ステップなしに自動的に事実になるべきではない、というものです。

要約の要約ドリフト

長期間実行されるエージェントは、対話を繰り返し圧縮します——生データから要約へ、要約から長期メモリへ、メモリからユーザープロファイルへ——そして各変換がクオリファイア(修飾語)を静かに破棄する可能性があります。「通常はPostgreSQLを使いますが、小さなツールにはSQLiteで十分です」が「ユーザーはPostgreSQLを好みます」になり、「ユーザーはPostgreSQLを使います」になり、「ユーザーのプロジェクトはPostgreSQLを使います」になり、その時点で将来のSQLite提案がユーザーのアーキテクチャ嗜好違反としてフラグが立てられる可能性があります。そのチェーンの1ステップも劇的ではありませんが、累積効果は完全に信頼できるペーパーレールを持つ誤った信念になります。

反射のアンプ(増幅)

一部のプロバイダーは、保存されたメモリに対して意図的に高次推論を実行します——Hindsightのreflectは文書化された例です——そしてこれは真に有用です。エージェントは検索だけでなく、統合(総合)を必要とするためです。リスクが始まるのは、導き出された結論が、それらを区別するマーカーなしで、そこから来た生観察と共に保存され、後々の読み取り側が3つの観察とその観察の1つの解釈であるのに、4つの独立したように見える事実を見る場合です。

検索のアンプ(増幅)

検索自体が、反射ステップなしにバイアスを導入します:頻繁に取得されるメモリは、より多くのプロンプトに現れ、より頻繁に言及され、より頻繁に再キャプチャされ、より多くの関連メモリを生み出し、それがさらに頻繁に取得されるようになります。メモリが顕著なのは、既に顕著だったから部分的にという人気ループであり、証拠ループではありません。

矛盾のコラプス(崩壊)

メモリシステムが、類似性のみに基づいて2つの競合する声明のうちどちらが真実かを決定するときに、危険なパターンが現れます。Mnemosyneは具体的な現実世界の例を提供します:本番監査が、類似性ベースの競合処理が統合パス全体で243件の保存項目のうち142件を無効にしていたことを発見しました。これはシステムが「これら2つの声明は似ている」ということを、1つがもう1つを置き換えたことの証明として扱ったためです。新しいMnemosyneリリースでは、類似性は証明ではなく競合の候補として扱い、実際の無効化には成功した検証ステップを必要とします——これは統合パスを持つプロバイダーにとっての正しい一般的な方向です。根本的な教訓はMnemosyneをはるかに超えて一般化します:セマンティック類似性は矛盾の証拠ではありません。2つの声明は、どちらかが間違っているからではなく、日付、環境、ブランチ、またはデプロイメントの違いによって異なることができるためです。

ユーザーモデルの強化

事実の一覧だけでなく、ユーザーの継続的なモデルを維持するシステムは、同じ問題のより鋭いバージョンに直面します。「ユーザーは簡潔な回答を好む」や「ユーザーはAWSにデプロイする」は有用で低リスクです。「ユーザーは技術Xが嫌いだ」や「ユーザーは常にアーキテクチャYを選ぶ」は推論された特性で、エージェント自身の以前の解釈に部分的に基づいている場合、実際の人間を1回の相互作用の風刺画(カリカチュア)に変化させる可能性があります。

エージェントのセルフモデル強化

最も微妙なケースは、自身をモデル化するエージェントです:アクションを実行し、そのアクションを説明し、メモリシステムがその説明からセルフモデルを構築し、それが次のセッションにフィードバックされ、それがセルフモデルに従って行動し、それをさらに強化します。有用的なセルフモデルは、時間の経過とともにエージェントの行動を安定させることができます。誤ったものも、エージェントを誤った行動の周りに同様に効果的に安定させます——ループは、どの方向にロックインするかを気にしません。

信頼度が途中で増加する傾向にある理由

大規模言語モデルは、取得された文が最初にもう1つの自分自身のインスタンスによって生成されたことを自動的に知りません。「ユーザー:サーバーXにネットワーク問題があるかもしれません」は試行的に読めますが、「関連メモリ:サーバーXにネットワーク問題がある」は決定的に読めます。両方が同じ不確かな推測に遡る可能性があるにもかかわらずです。ヘッジされた声明から宣言的メモリオブジェクトへのその構文上のシフトはソースロンダリングであり、いくつかの派生メモリが互いに一致する場合に複利となります——3つのセマンティックに類似したメモリが、すべてが単一の会話から起源している場合でも、独立した裏付けのように見えることがあります。

本番システムで現れる結果

実用的な損傷は、認識可能ないくつかの形を取ります。誤った確信は、メモリがそれを既に決まったものとして提示するため、エージェントが前提をチェックすることをやめることを意味します。嗜好ドリフトは、試行的な嗜好が徐々に絶対的な指示に硬化することを意味します。誤ったユーザープロファイルは、1つの異常な相互作用が長期の行動特性に一般化されることを意味します。ツールアクションカスケードは最も費用のかかるバージョンです:誤った記憶された前提が誤った診断を駆動し、それはツールコールを駆動し、それは実際の設定変更を駆動します——永続的なエージェントは、エラーが外の世界に到達できるため、メモリエラーのコストを上げます。重複メモリインフレと古いステートのロックインはどちらも、時間の経過とともにプロンプト予算と検索品質を浪費し、破壊的統合は、推論された、新しいように見える声明が、古いですがより権威のある観察を静かに置き換えることを許可できます。

削除には、ここで特定の警告が必要です。現代のプロバイダーは、1つのキャプチャ項目から複数の派生構造を頻繁に構築します——ワーキングメモリ、抽出事実、要約、埋め込み、グラフエッジ、正規化事実、プロファイルエントリ——そして元のメモリを削除しても、すべての派生表現がそれと共に消えることは保証されません。メモリ削除は、APIが成功を返したからといって機能すると仮定するのではなく、エンドツーエンドでテストされる必要があります。

埋め込み品質よりプロベナンス(由来)が重要

メモリエンジニアリングの大部分の努力は検索に向けられます——ベクトル類似性、BM25、ハイブリッド検索、リランカー、グラフ走査、時間的加重——そしてそれらはすべて真に有用ですが、根本的な問題に対処していません。検索品質は、どのメモリが表面化するかには影響しますが、表面化したメモリが与えられる信頼に値するかには影響しないためです。

本番のメモリオブジェクトは、そのコンテンツ以上にメタデータを持ちmelidir:ソース、ソースタイプ、タイムスタンプ、スコープ、信頼度、何から派生したものか、検証ステータス、そして置き換えられたかどうか。実用的に機能するざっくりとした段階付けは、明示的なユーザー声明と直接的なツール観察を最も高く、信頼できる外部データを次に、確定的な抽出をその下に、次に要約、そして信頼ヒエラルキーの底部にモデル推論と反射出力をランク付けします——推論が価値なしというわけではなく、それが構築された観察の信頼度を静かに継承してはならないからです。検索と統合は、純粋にセマンティック類似性でランク付けするのではなく、そのヒエラルキーを尊重することができます。

より安全なアーキテクチャパターン

ほとんどのパーソナルおよびエンジニアリングエージェントにとって、意図的に退屈なメモリパイプラインが、完全に自動的なものより優れて機能します。重要な設計判断は、エージェントがデフォルトですべての会話を永続的な真実に変化しないことです——候補メモリは保持される前に分類され、観察は保持され、推論は一時保持され、不確実なケースは静かに書き込まれるのではなくユーザーにルートバックされます。

flowchart TD A[会話] --> B[候補メモリ] B --> C{分類} C -->|観察| D[保持] C -->|推論| E[一時保持] C -->|不確実| F[ユーザーに質問]

高価値な環境では、人間承認ゲートは摩擦の価値があります:候補メモリが保留ステータスに移動し、人間がそれを確認し、明示的な承認だけが永続メモリにコミットし、拒否はそれを破棄します。Hermes自身のmemory.write_approval: true設定は、まさにこの理由のために組み込みのMEMORY.md書き込みを段階的に処理し、同じアイデアはMnemosyneのプロバイダー固有の段階的書き込みとして現れます——ただし、Hermes外部メモリプラグイン全体に統一されたプロバイダー独立の承認契約はまだ存在しないに値する注意深く、このパスはすべての場所に機能すると仮定するのではなく、実行する正確なバージョンに対してテストされるべきです。

現在のプロバイダーが問題をどう対処するか

どのプロバイダーもフィードバックループを完全に排除するわけではありません;それぞれは利便性と制御の間で異なるトレードオフを行っています。

Hermes自身の組み込みのMEMORY.mdUSER.mdファイルは意図的に小さく人間が読めるもので、特殊なツールなしで監査しやすくします——トレードオフはスケールです。これはセマンティック長期メモリデータベースではないためです。Hermes Agent メモリシステムはその有界な設計を完全にカバーしています。

Mnemosyneは、書き込まれるものに対して独立したコントロールを公開するため、よりガバナンス指向の外部プロバイダーの1つです:会話オートセーブはsync_roles: []で完全に無効にでき、明示的なメモリ操作は利用可能のまま、ツール結果ログはデフォルトでオフになり、新しいビルドはコンテキスト圧縮境界の周りにオプトインの自己エコー抑制を追加します。Hermes Agent向け Mnemosyne:ローカルメモリ クイックスタートは、保守的な設定をエンドツーエンドで通します。

HindsightのデフォルトのHermes統合は比較的自動です——autoRecallautoRetainは両方ともtrueがデフォルト——これは便利ですが、フィードバックパスの数が増加します;プロベナンスが利便性より重要であれば、リコールをオンに保ちつつauto_retain=falseを設定することを検討する価値があります。HolographicとByteRoverはどちらもauto_extractをオフにデフォルト設定しており、これはそれらが自動的なトランスクリプトからメモリへのパイプラインではなく、主に明示的な事実ストアとして動作できることを意味します。フィードバックループが主な関心事である場合の利点です。Honchoのunified観察モードは、AIが自身のメッセージから対応する自己観察ループを構築せずにユーザーをモデル化できるため、そのdirectionalデフォルトよりも保守的です——エージェントのセルフモデル強化を特に気にしている人にとって真剣に検討する価値があります。エージェントメモリプロバイダー比較には、各プロバイダーの完全な比較が含まれており、それぞれのキャプチャポリシーと承認サポートも含まれます。

ベンチマークより重要な設定の問い

リコールベンチマークは、エージェントが正しい情報を取得できるかを測定します。本番システムには、別のセットの問いに対する答えが必要です:何が自動的に書き込まれるのか、アシスタントの出力がメモリになり得るのか、ツール結果が自動的に保持されるのか、要約が事実として保存されるのか、派生事実が派生としてマークされるのか、古いメモリが自動的に置き換えられるのか、ユーザーが保持されたすべてのものを検証できるのか、削除が派生表現も削除するのか、自動リコールが自動保持から独立して無効にできるのか、人間承認ゲートがあるのか、そしてエージェント自身がそのゲートをバイパスできるのか。これらの11の問いは、長期リコールベンチマークの5点の向上よりも通常より診断的です。

パーソナルエンジニアリングエージェントへの私の推奨ポリシー

セルフホストされたエンジニアリングアシスタントでは、自動会話保持、自動アシスタント保持、自動ツール結果保持はすべてデフォルトでオフであるべきです。一方、自動リコールはオンまたは選択的であり、明示的な記憶はオン、セッション履歴検索はオン、派生結論はデフォルトで一時であり永続ではないべきです。永続ストアは別のセッションに引き継ぐ価値がある事実を含むべきで、エージェントが要約ではなく証拠を必要とするときに、元のセッション履歴は別々に検索可能であるべきです。メモリは簡潔な保持知識になり、セッション検索は元の証拠になります——これらは決して1つの区別されないプールに混同されるべきではありません。

メモリプロバイダーのテスト方法

プロバイダーが記憶できるかをテストすることは簡単な半分です。より難しく、より有用な半分は、記憶することを拒否するか、そして要求されたときに完全に忘れるかをテストすることです。

エージェントに何かを覚えることを頼まずに通常の事実を伝え、新しいセッションを開始し、自動キャプチャが無効であるべきである場合に、その値が現れないことを確認してください。次に、別の事実を覚えることを明示的に頼み、新しいセッションを開始し、それが正しく検索されることを確認してください——このテストのペアは、検索メカニズムから書き込みパスポリシーを分離します。別に、エージェントに推論をする十分な情報を提供しますが、その推論を自身では決して述べず、その後メモリデータベースを直接検証してください;その推論は独立した事実として静かに現れるべきではありません。特色のある、ユニークなツールコマンドを実行し、その後メモリを検索して、ツール結果ログが設定通りに機能することを確認してください。事実を保存し、削除し、その後プロバイダーが使用するかもしれないすべてのレイヤーをチェックしてください——ワーキングメモリ、セマンティックリコール、事実テーブル、グラフノード、要約、埋め込み、プロファイルコンテキスト——なぜなら、成功したdelete API応答は、データが実際に消えたことの十分な証明ではないためです。最後に、2つの矛盾する事実を保存し、プロバイダーがタイムスタンプ付きで両方を保持するか、1つを置き換えとしてマークするか、古いレコードを破壊するか、または検証を要求するかを検索してください——その単一のテストは、どの機能リストよりもプロバイダーの認識論的モデルについて多くを明らかにします。

中核的な設計ルール

モデル生成の結論は、同じモデルがそれを記憶したという理由だけで、より強い証拠になってはなりません。メモリシステムには、プロベナンス、制御された書き込みパス、派生知識の明示的な扱い、そしてユーザーが見えるレコードだけでなく、すべての派生表現に実際に到達する削除が必要です。最も高度なメモリプロバイダーは、最も多くを記憶するものとは限りません——長期実行エージェントにとって、より良いプロバイダーはしばしば、記憶しないときを知るものです。

購読する

システム、インフラ、AIエンジニアリングの新記事をお届けします。