r/LLMDevs、r/artificial）。その投稿では、LLMが自分のコンテキストウィンドウを引用根拠付きのドキュメントストアに保存し、推論回復のための検索メカニズムとして埋め込み類似度の代わりに、平易な言語でそれをクエリできるのではないかと提案しました。Karpathy's LLM Knowledge Bases post と、最近の TDS context engineering の記事 が、似た領域に触れていたので、実際にそれを作って見つけたことを改めて掘り起こすのに良いタイミングだと感じました。
ハイブリッドな問いは、実際に解決した
元のスレッドの複数のコメントは、最終的には必ずハイブリッドになるだろうと予測していました――安価なベクターフィルタを最初に行い、LLMが短いリストに対して推論する、と。だいたい合っています。ただ、そこに至った失敗モードは、私の予想とは別でした。純粋な意味検索がスケール自体のせいで劣化したのではありません。同じ概念を指しているにもかかわらず、クエリと対象コンテンツが異なる語彙を使っていたため、検索結果を取りこぼし始めたのです。解決策は「インデックス先行」戦略でした――NLクエリが走る前に候補を絞り込む、軽量なトピック・タグ付きインデックスです。したがって、ハイブリッド層はベクタの事前フィルタではなく、構造的メタデータです。
LLMは自分の「記憶」の利用に抵抗する
これは意外でした。Claude は、クエリすればより正確な結果が得られるとしても、記憶ストアを照会するより内部で推論することを、持続的に好む傾向があります。放置すると「検索」ではなく「再構築」を行ってしまい、まさにそのシステムが防ごうとして設計された失敗モードです。これを直すには、システムプロンプトに「クエリ必須」の要件をエンコードし、起動時のゲート・チェックリストを用意し、検索をスキップした場合に何がコストになるのかを明確に枠付ける必要がありました。これは行動上の問題でありアーキテクチャ上の問題ではありませんが、どちらの記事も触れていない現実の問題です。
記憶層は、インターフェースモデルから切り離されるべきだ
一つ、私はテストしていませんが、アーキテクチャから論理的に導かれることがあります。永続状態がモデルの中ではなくドキュメントストアにあるなら、インターフェースのLLMは入れ替え可能になります。Claude を ChatGPT や Gemini に差し替えても、忠実度の損失は最小限に抑えられるはずで、さらに調整（コーディネーション）層として、同じメモリに対して複数のモデルを同時に動かすことも可能でしょう。もう一つ、ベクタRAGには存在しない面白い品質の非対称性があります。ここでの検索は、別の埋め込みステップではなくインターフェースモデルの推論を使うため、より高能力なモデルは生成品質だけでなく検索品質そのものを直接改善すべきだからです。これらのいずれも実運用で検証はしていませんが、アーキテクチャはそれを示唆しているように思えます。同様のことを試した人がいるか、気になります。
メモリの衛生（ハイジーン）は、本当の意味でメンテナンス問題だ
Karpathy の投稿は、ウィキの不整合を「linting」する話をしています。私は別の角度から、似た問題に遭遇しました。追記のみのノートシステムだと、解決済みか稼働中かを区別する手段がないため、古いエントリが溜まっていきます。結局、ノートのライフサイクル（たとえば resolve、revise、retract など）と、バージョン付きの識別子を用意する必要が出てきます。そうすればシステムは「現在のもの」を把握できるようになります。メモリを一貫させ続けるための保守コストは、Karpathy でも TDS でも、過小評価されています。
まだ研究・構築の段階です。これをテストするために私が取り回していたアドホックな仕組みについて気になっている方のために、関連するリポジトリはこちらです： https://github.com/pjmattingly/Claude-persistent-memory ― pre-alpha の品質ですが、上で述べた観察の裏側で動いている動作基盤です。これらのどれかについて、さらに深掘りすることもできます。
[link] [comments]
