Hindsight - 経験を統合して検索・内省するエージェント記憶基盤

エージェントに過去を参照させる素朴な方法は、会話や作業記録を保存し、次の依頼に関連しそうな断片を取り出すことだ。READMEも一般的な手法としてベクトル検索と知識グラフを挙げる。前者は意味の近さから、後者はエンティティ間の関係から手掛かりを探す。ただし、取り出した断片がそのまま継続的な理解になるわけではない。ある利用者が何を好み、どの判断を後に修正したかを使うには、複数の記録をつなぎ、現在の問いに即して解釈する処理が残る。Hindsightが対象にするのは、この検索と解釈の間にある作業だ。

「似た内容を探す」なら意味検索が役に立つ。一方、固有名詞を含む記録、出来事の前後関係、特定の期間に起きたことを知りたい場合は、別の手掛かりも必要になる。Hindsightは、意味、BM25によるキーワード、グラフ、時間範囲という四つの検索経路を用意する。単一の検索方式に全ての問いを押し込まない構成だ。ただし、検索経路が増えることと、取り出した情報が正しいことは別の問題である。入力時の抽出や、その後の統合が誤れば、複数経路で見つかった結果も誤りを含み得る。

Hindsightの基本単位はbankだ。ユーザー、エージェント、プロジェクトごとに独立した記憶領域として扱う。例えば、利用者ごとの対話履歴を引き継ぐ用途と、あるリポジトリの作業履歴を引き継ぐ用途では、保存すべき文脈も参照すべき範囲も違う。bankを分ける設計は、その境界をアプリケーションから明示する手段になる。逆に、どの入力をどのbankへ渡すかは利用側の設計事項だ。記憶基盤を入れれば、利用者やプロジェクトの境界が自動的に正しく定まるわけではない。

開発元はHindsightを、想起だけでなく経験から学ぶエージェント記憶システムと説明する。ここで確認できる具体的な仕組みは、入力を構造化して保存すること、複数の方法で想起すること、関連事実を観察へ統合すること、指定した問いへの回答を更新することだ。「学ぶ」をモデルの重みの更新や、判断の正しさが保証されることと読み替えるべきではない。記事中では、world factsを外界についての事実、experiencesを経験、observationsを統合された見解として区別する。この区別が、検索された記録と、記録から作られた解釈を混同しないための足場になる。

エージェントはbank IDと内容を指定してretainを呼ぶ。そこでLLMが入力から事実、時間情報、エンティティ、関係を抽出し、正規化された表現と検索用の情報を作る。入力を丸ごと保存して後から類似文を探すだけではなく、誰について、いつ、どの関係が述べられたかを後続の検索で扱えるようにする工程だ。このため、記憶の品質は取り込み時の抽出に依存する。曖昧な発言、古くなった情報、互いに矛盾する記録をどのように扱うかは、保存できることとは分けて評価したい。LLMを呼ぶ以上、保持する量に応じた呼び出しコストと遅延も考慮が必要になる。

recallでは、意味検索、BM25、グラフ、時間範囲検索を並列に実行する。各経路の候補をreciprocal rank fusionでまとめ、クロスエンコーダを使って順位付けし、トークン上限に合わせて結果を切り詰める。意味の近い記述、正確な語、エンティティ間のつながり、時期という異なる手掛かりを、最後に一つの応答へ集約する流れだ。検索の入口が複数あるため、問い合わせの性質に合わせて利用側が検索方式を一つだけ選ぶ必要はない。ただし、順位付けと切り詰めを通った結果だけがエージェントに渡る。重要な記録が常に残ると仮定せず、実際の問い合わせで想起内容を確かめる必要がある。

Hindsightは関連する事実をバックグラウンドでobservationへ統合する。観察には、根拠となる事実への引用と件数が保持される。これが、生の記録を検索する層と、複数の記録から形成した見解を使う層の接点だ。例えば同じ対象について記録が増えたとき、毎回断片を並べて解釈する代わりに、統合済みの見解を参照できる。ただし、引用が付くことは見解の正しさそのものを保証しない。どの事実が統合され、後から入った情報によって見解がどう変わるかを追えることが、長期運用では重要になる。

mental modelは、指定した問いへの回答を保存し、新しい情報に応じてバックグラウンドで更新する仕組みだ。knowledge pageは、その内容を文書として使う形である。これに対しreflectは、蓄積した記憶を使って記憶間のつながりを分析し、回答を作る操作だ。recallが関連する材料を取り出す操作なら、reflectはその材料を踏まえて問いに応じる操作と捉えられる。指定した問いに対する更新済みの回答を持てる点は、同じ種類の問いを繰り返すエージェントに合う。ただし、事前に用意する問いが実際の作業とずれていれば、その回答を維持する価値も小さくなる。

利用口にはPython、Node.js、Goのクライアント、CLI、REST APIが示され、サーバーはbankごとのMCPエンドポイントも提供する。LLM WrapperはLLM呼び出し前に記憶を取得し、呼び出し後に会話を保持するため、既存の呼び出し経路へ記憶の読み書きを置ける。本番運用の保存層としてはPostgreSQLとpgvector、またはOracle AI Databaseが示されている。したがって、self-hosted構成ではエージェントの処理に加えて、サーバーと保存層も運用対象になる。どの連携方法を選んでも、bankの割り当てと、何を保持するかの判断は利用側に残る。

相性がよいのは、同じ利用者や作業対象に何度も戻るエージェントだ。READMEは、利用者ごとの履歴を使う対話エージェントと、開放的なタスクを扱いフィードバックから振る舞いを変えるエージェントを用途に挙げる。コーディングエージェント連携では、git履歴と過去セッションからリポジトリ単位のbankを構築する。過去の判断、修正、依頼の文脈を次の作業で参照したい場合、記憶を専用の層として扱う理由がある。一方、短い一回限りの処理では、取り込みと検索の仕組みを維持する利益は限られる。

ベクトル検索を用いたRAGは、関連文書や記録を取り出す用途でHindsightと重なる。知識グラフ型の記憶とも、関係をたどって情報を得る点で重なる。Hindsightの違いは、検索経路を組み合わせた上で、関連事実を観察へ統合し、指定した問いへの回答を更新する構成にある。既存の検索だけで必要な文脈を十分に返せるなら、この追加層は必須ではない。逆に、検索された断片から同じ見解を何度も組み立てているなら、観察やメンタルモデルを試す余地がある。比較の焦点は機能の数ではなく、実際の問いに対する回答と運用負担だ。

retainはLLMによる抽出を含むため、入力を保持するたびに呼び出しコストや遅延が発生し得る。self-hostedならサーバーと保存層の管理も加わる。秘密情報とPIIを検査するMemory Defenseは、READMEではbank単位で有効化する任意の機能で、対象は45パターンとされる。したがって、これを全bankに自動適用される保護と見なしてはいけない。何を記憶に渡すか、どのbankから誰が想起できるか、保存した情報をどう扱うかは、利用側が導入時に確かめるべき境界になる。

READMEはLongMemEvalで最高精度を得たと主張する。しかし、取得したテキストにはスコア、比較対象、条件、再現手順がない。この材料だけで、手元の用途でも既存方式より正確だとは言えない。取り込み時の抽出、観察の統合、想起時の順位付けが連なるため、実際の評価では、誤った記憶が残る場面や必要な記録が落ちる場面を見たい。Cloudとself-hostedの機能境界、誤った記憶の定着を防ぐ仕組みも、与えられた資料からは確定できない。APIの成熟度や対応環境についても、ここにある利用例だけから広い保証は導けない。

README自身、n8nなどの単純なワークフローには機能が過剰な場合があると記す。入力を処理して終える自動化や、更新される利用者像を必要としない処理なら、記録の検索だけで足りる可能性が高い。Hindsightを選ぶ理由は「長期記憶」という名前ではなく、同じ対象について事実が増え、過去の経験を次の判断に反映したいという具体的な要求にある。導入するなら、保持する情報、想起したい問い、観察やメンタルモデルが役立つ場面を先に定め、その利益が追加のLLM呼び出しと運用に見合うかを測るべきだ。