Memoryfields: エージェントのメモリをポータブルなファイル形式として

エージェントのメモリは、多段階の処理パイプラインではなく、ポータブルなデータ形式として扱うべきです。Memoryfieldsの提案は、既存のエージェントメモリシステム——プロプライエタリなプラットフォームにロックされたハーネス、過度に複雑なデータベースアーキテクチャ、あるいは硬直的なナレッジグラフ——が、メモリをデータではなくプロセスとして扱っているために失敗していると主張しています。メモリをMarkdownファイルとオプションのSQLiteベクトルインデックスの集合として表現することで、エージェントは大幅に低いレイテンシと高い柔軟性で情報を維持し、取得することができます。

既存のメモリシステムの失敗

従来のエージェントメモリシステムは、通常3つのカテゴリに分類され、それぞれに特有の欠点があります。

プロプライエタリなハーネス: これらは会話履歴から情報をマイニングすることが多く、一般的な世界知識よりもユーザー固有のデータに重点を置いており、ユーザーを特定のプロバイダーのプラットフォームにロックインさせます。
複雑なアーキテクチャ: 一部のシステムは、何が記憶に値するかを判断するためだけに、pgvector、Neo4jグラフデータベース、および専用のLLMを組み合わせて使用します。この複雑さは管理上のオーバーヘッドを生み出し、モデルを混乱させることがよくあります。
ハイ・モダニストなナレッジグラフ: これらのシステムは、情報を文脈から切り離して、蒸留された事実や論理的な命題を作成します。このアプローチは情報を孤立させ、エージェントやユーザーにとって無意味なものにしてしまいます。

Memoryfieldの仕様

Memoryfieldは、通常.zipファイルとしてアーカイブされるポータブルなメモリファイル形式であり、以下で構成されます。

Markdown Pages: メモリの主要なストレージであり、散文形式で記述されます。
YAML Frontmatter: 各ページのためのオプションのメタデータ（title、created date、updated date、UUID、およびsummary）です。
SQLite Vector Index: セマンティック検索のためのオプションのインデックスであり、エージェントが関連するコンテンツに直接ジャンプすることを可能にします。

設計決定 1: チャンクではなく散文

従来のRAG (Retrieval-Augmented Generation)に見られる複雑なチャンキングとリランキングのパイプラインを使用するのではなく、Memoryfieldsは散文を利用します。エージェント自身がメモリを書き込むため、エージェントがすでに最適化されている形式であるMarkdownで直接記述することができます。

ベクトル埋め込みとの互換性を確保するため、1ページあたり約8KB（約2,000トークン）のソフトリミットが設けられています。この制限は、巨大な文書ではなく、焦点を絞った複数のページを作成することを促し、これはエージェントとリトリーバーの両方にとって有益な制約となります。

設計決定 2: セマンティック・ジャンプ vs. グラフ・ウォーキング

ナレッジグラフ（Karpathyのwikiなど）は、エージェントがリンクを逐次的に辿ることを要求し、「N+1ツールコール問題」を引き起こします。関連情報がNステップ先に存在する場合、エージェントはN+1回の逐次的なツールコールを行う必要があり、それぞれが数秒のレイテンシを追加します。さらに、ページタイトルやリンクテキストが検索用に完璧に最適化されていない場合、エージェントは情報を探し出すのに苦労することがよくあります。

Memoryfieldsは、グラフの探索をセマンティック検索に置き換えます。これにより、エージェントはコンテンツに基づいて関連するすべてのページに直接ジャンプし、それらを並列に読み取ることができます。これにより、プロセスは最大2回のツールコールに削減されます。つまり、検索と読み取りの1回ずつです。

設計決定 3: 低メカニズムによるモデルのスケーリング

複雑なAPIではなく、シンプルなファイル形式を使用することで、Memoryfieldsはエージェントが本来持っている強み——Bash、Markdown、およびSQLiteへの習熟度——を活用して、独自のアクセスパターンを考案することを可能にします。この「低メカニズム」アプローチは、モデルの最前線が進むにつれてシステムがスケールすることを保証します。モデルの能力が向上するにつれ、彼らは固定されたAPIに制限されることなく、よりインテリジェントにメモリを管理できるようになります。

設計決定 4: 転送不変性

ロックインを避けるため、形式はオープンで転送不変です。標準的なアーカイブ形式はZIPファイルですが、仕様はメモリをローカルファイル、Amazon S3、GitHub、またはHTTP経由で提供されることを許可します。これにより、ユーザーが蓄積した知識が、異なるエージェントやモデルを横断してポータブルで交換可能であり続けることが保証されます。

実装と技術的制約

埋め込みモデルについては、仕様はnomic-embed-text-v1.5を推奨しています。このモデルは、サイズ（270MB）とパフォーマンスのバランスがバランスよく取れており、非GPUハードウェアでも動作可能でありながら、広く推奨されるデフォルトとして機能します。

セキュリティ上の考慮事項

メモリはコンテキストウィンドウに直接注入されるため、プロンプトインジェクションに対して脆弱です。著者は、ユーザーは信頼できない第三者とコンテキストウィンドウやmemoryfieldsを共有すべきではないと強調しています。静的なZIPファイル形式を使用することで、ユーザーはsha256sumを介してメモリフィールドをマニュアルでレビューし、ピン留めすることができ、セキュリティを確保できます。

コミュニティの視点と反論論点

技術的なユーザー間の議論は、ファイルベースのメモリについて、いくつかの重要な考慮事項をハイライトしています。

「ポイズニング」問題: 一部のユーザーは、メモリ内の単一の「汚染された」あるいは不正確なテキストの1行が、後続のすべての出力に悪影響を受ける可能性があると主張しています。一つのユーザーは、ノイズやドリフトを避けるために、正式なメモリシステムよりも単純なドキュメントのディレクトリが好ましいと提案しています。
RAGとの比較: これを「単なるRAG」と見る向きもありますが、他のユーザーは、エージェントがメモリの著者であるという役割の違いに注目しています。これは、読み取りだけでなく、書き込みにも最適化されたシステムを構築することを目指しています。
外部化のギャップ: 哲学的な批判は、散布されたデータベースをTransformerに被せることは「絆創膏」的な解決策であると示唆しています。議論の論点は、真のメモリは外部の足場（scaffold）としてではなく、モデルのトレーニングやアーキテクチャに統合されるべきであるというものです。
メンテナンスの負担: セマンティック検索は、「忘却」や古い情報の更新を更新する問題を解決していません。メモリが誤っていると判明した場合、それでも将来の検索でセマンティック・レレバント（意味的に関連する）と判定され、エージェントが古い経路を辿る可能性が残ります。

"Irrelevant material is simply never surfaced by the semantic search... that's quite optimistic. there's lots of 'memory' or past chats with agents that should be suppressed and forgotten because they were looking in the wrong place or were eventually proven wrong."

データ・ファースト・ワークフローの要約

Write: エージェントはメモリをMarkdownファイルとして書き込みます。
Embed: ファイルは埋め込まれ、ベクトルはSQLiteデータベースに保存されます。
Retrieve: エージェントはセマンティック検索を使用して、関連するメモリを並列に読み取ります。