エージェントの記憶を「ファイル形式」で実現する「memoryfield」——複雑なパイプラインは不要
Agent Memory as a File Format
AIエージェントの記憶を、MarkdownファイルとSQLiteベースのベクトルインデックスで構成する「memoryfield」というファイル形式を提案。従来のエージェント記憶システム（ハーネスに依存するもの、複雑なもの、グラフベースのもの）がうまく機能しない理由を挙げ、記憶をプロセスではなくデータとして扱うべきだと主張。セマンティック検索で関連ページに直接ジャンプし、並列読み込みすることで、知識グラフの探索よりも高速かつ信頼性が高いと述べる。オープンな仕様で、転送手段も自由。
記憶は、特にモデルにとっては、プロセスよりもはるかにデータとして表現する方が適している。
HNでの議論
82- dataviz1000
記憶を使わない人は他にいますか？
一行でも毒のあるテキストが入ると、それ以降のすべてに悪影響を及ぼすことに気づきました。その代わりに、temp/フォルダにドキュメントを置き、エージェントやモデルごとに異なるファイルを使っています。そして、常にファイルを整理して削除しなければなりません。推測できる情報はすべてノイズであり、エージェントに悪影響を及ぼします。データベース構造の定義があり、それが実装されているなら、その情報はテキストドキュメントに含めるべきではありません。それはノイズであり、ドリフトし、エージェントが望ましくない動作をし続ける理由のデバッグが不可能になります。
私は~/Projectsフォルダを持っています。例えば、パフォーマンステストとリーク検出のためにPlaywrightをChrome DevTools Protocolと一緒に使っています。それを処理するスクリプトがあります。私のプロンプトは「~/ProjectsをCDPとPlaywrightを使ったパフォーマンステスト用に検索して、ここに実装して」です。つまり、何か必要なものがあれば、リソースを指し示すか、リソースを検索するように頼むと、すぐに見つけてくれ、そして最も重要なことに、毎回それを改善してくれる傾向があります。
もし私が組織にいたら、リポジトリを持ち、ローカルに記憶するよりも、リソースを指し示して「それを使って」と言うほうがいいでしょう。
- JohnMakin
> Markdownの「ページ」と、
> （オプションの）YAMLフロントマターと、
> （オプションの）セマンティック検索用のSQLiteベクトルインデックス
これはまさに、私が構築したMCP APIで使っているもので、かなりうまく機能しています。S3のようなストレージシステムを使ってメタデータを活用すれば、さらに強化できます。
「ハーネス管理」のメモリは完全にゴミだと確信しており、すぐに無効にしています。主な問題は、時間の経過とともに劣化し、矛盾した情報や完全に誤った情報が忍び込むことです。そしてある日、それが酔っ払っていると確信するでしょう。そして、その状態になるたびに調査すると、自動管理メモリが常に問題でした。
- morelandjs
これは本質的にRAGなので、皮肉なことを書く準備をしていましたが、著者は重要と思われる微妙な詳細に触れていると思います。
- メモリシステムは、すべてのドキュメントを自分で生成する特定のタイプのナレッジベースです。埋め込みトークン制限未満になるように生成すれば、チャンキングの必要がなくなります。
- 埋め込みモデルは向上しており、もはや単なるセマンティック平均ではありません。
- 小さなモデルは非常に安価になり、並列読み取りのコストが管理可能になりました。
彼らが説明しているのは、これらの観察を活用した最もシンプルなアーキテクチャのようなものです。彼らがそれがうまく機能すると言うのを信じます。
しかし、すべてのメモリが単なるベクトルである場合、キーワード検索のようなものは完全に失敗するだろうと疑っています。だからこそ、Typesenseのハイブリッド検索のようなものが依然として有用であり得るのです。
- Avijit_Thawani
「無関係な素材はセマンティック検索によって表面化されることは決してない」
それはかなり楽観的です。エージェントとの過去のチャットや「メモリ」には、間違った場所を探していたり、最終的に間違っていることが証明されたために抑制され、忘れられるべきものがたくさんあります。しかし、セマンティックには将来の検索に非常に関連しているように見えるでしょう。だからこそ、試験を解くときに教科書とSFの両方を検索すべきではないのです。
- JustFinishedBSG
「マークダウンだ」と言うために、たくさんのテキストがありますね。