【AI開発必見】「忘却」を実装してRAGの精度を爆上げ！生物学的アプローチによるAIメモリ管理

多くのRAG環境が失敗するのは、メモリを単なる「静的なファイリングキャビネット」として扱っているからです。一時的なバグ修正や放置されたルールがすべて永遠に保存されると、コンテキストウィンドウはノイズで埋め尽くされ、トークンコストが急増し、エージェントの推論能力は低下してしまいます。この実装では、エビングハウスの忘却曲線を応用し、コンテキストを生き物のように管理する生物学的なアプローチを実験しています。各記憶には「強度」スコアが割り当てられ、呼び出すたびにデータが強化され、忘却曲線が緩やかになる（分散学習の仕組み）一方、使用されないデータは閾値に達すると自動的に削除されます。また、意味的な類似性だけで検索すると関連情報を取りこぼす「論理的近傍」問題を解決するため、ベクトルストアの上にグラフ層を追加しました。LoCoMoデータセットでベンチマークしたところ、Recall@5で52%を達成し、ステートレスなベクトルストアの約2倍の精度を実現。さらに、トークンの無駄を約84%削減することに成功しました。DuckDBを使用したローカルファーストのMCPサーバーとして構築しており、「何を覚えるか」と同じくらい「何を忘れるか」が、長期プロジェクトを扱うAIエージェントには不可欠であるという仮説に基づいています。非線形な減衰や、コンテキスト管理におけるこのような生物学的制約について、皆さんがどのように考えているか、ぜひ意見を聞かせてください。GitHub: https://github.com/sachitrafa/cognitive-ai-memory

アルツハイマーを機能として実装したのかよｗ でも真面目な話、これはかなり興味深いね

悪いけど、「生物学的な記憶」っていう表現は、基本的なキャッシュ機構をよく見せるためのマーケティング用の口実に見える。

トークン使用量を84％削減って言ってるけど、それって一般的なチャンク化されたRAGシステムなら当たり前の数字じゃない？

あと、なんでわざわざLoMoCoデータセットをテストに使ったの？あれって色々問題があるし、簡単に不正（スコアを盛る）できることで有名でしょ。

メモリの実装系はどれもしっくりこなかったから、いくつか試したけどやめた。

今はClaudeとのコードに関するやり取りを全部保存しておいて、そこからコンテキストを設定するようにしてる。

これなら自分で記憶を管理できるし、今のところこれが一番上手くいってるよ。

ここ数週間で「生物学的な記憶」系の投稿をいくつか見たけど、前にも言った通り、忘却率はリアルタイムの時計じゃなくて、コーディングセッション内での使用期間を基準にするべきだよ。そうじゃないと、作業が進んでなくても（例えばコーダーが休暇中とか）メモリが勝手に消えていくことになる。ここがどうなってるかは調べてないけど、概念化に失敗したナイーブな仮説って感じがするな。

もう一つ言うと、記憶を呼び出すトリガーには空間的な記憶の方が適してるはず。だからコーディングセッションがどこで始まったかとか、どのフォルダを参照したかとかをトラッキングしてないと、プロジェクトにとって重要な情報を引っ張ってくるための良い道筋を作れていないことになるよ。

みんなエージェントに過去の会話を全部覚えておいてほしいみたいだけど、正直その価値が分からないな。むしろ、昨日言ったことを元にエージェントが勝手に推測してくるせいで生産性が落ちる気がする。これまでメモリ系のシステムを試した時はいつも、過去の会話や開発の枝葉に引きずられてエージェントが本来のタスクから脱線してたよ。全然関係ないプロジェクト（仕事、オープンソース、雑多なサイドプロジェクトなど）を混ぜこぜにして、的外れな要件を満たそうとしたりするしね。

だから一般的な「メモリ」なんて目指すのはやめた。今はエージェントに、各プロジェクトのドキュメントを簡潔かつ網羅的に書かせるようにしてる。誰か他の人がプロジェクトを引き継ぐ前提の開発ドキュメントやロードマップを書かせておけば、翌週でも作業を再開するために必要な情報は全部揃うからね。

エージェントは友達じゃないんだから、誕生日とか、先週Reactについてボロクソ言ったことなんて覚えておかなくていい。必要なのは、誰であれ――人間でもエージェントでも――初めてそのレポジトリを見た時に、すぐに作業に入れる情報だよ。

分かりやすくて簡潔なドキュメントとチェックリストさえあれば、みんなが「メモリ」で解決できると思ってる問題は全部解決するよ。技術スタックの指定も、コマンドやテストの手順も、静的解析ツール（コードスタイルの強制）も全部そこに含めればいい。一ヶ月前に適当に喋ったことよりもずっと正確だし、何より安上がりだ。Markdownはエージェントのネイティブ言語なんだよ。MCPもスキルもAPIもいらない。ファイルを読ませるだけでいい。どんなエージェントでも、どんなモデルでも、新しくプロジェクトに入った人間でも同じように使えるしね。

要するに、メモリってエージェントをバカにして使いにくくするだけだと思う。俺はただ、目の前のタスクに集中してほしいんだ。

超知能AIを目指してる一方で、AIのあらゆる側面を「人間」に似せようと必死になってるのが面白いよね。個人的には、今のまま進めると、人間が持つあらゆるエラーや欠陥をそのまま引き継いだ「人間のようなAI」が出来上がるだけだと思う。

俺は忘却のためじゃなくて、チャンクの「ホット度」を確認するためにだけ減衰関数を使ってるよ。それより気になるのは、メモリ内にエラーが含まれている場合。それは忘却じゃなくて、別の仕組みで修正・削除しなきゃいけない（頻繁に呼び出される可能性があるからね）。

自分も今、ローカルエージェント向けにエビングハウス忘却曲線を使った同じようなメモリ構造と減衰メカニズムを構築中だよ。
直面している課題は、何をメモリに保存すべきかをどう判断するかだね。モデル自身に重要度を決めさせて要約して保存させるべきか？あと、メモリの冗長性を避けて適切にカテゴリ分けして、必要な時に正しい情報を引き出して、何を捨てるか判断するにはどうすればいいか。このあたりのアプローチや考え方を詳しく教えてほしいな。