エージェントの記憶をファイルフォーマットとして扱う

エージェントの記憶をファイルフォーマットとして August 2026 Memoryfields - エージェントの記憶を行うための、はるかにシンプルな方法 [フロッピーディスク挿入音] すごい - 私は企業のVLAN構成を知っています 多くのモデルベンチマークは、空のコンテキストウィンドウから始まります。AIのタブラ・ラサ（白紙状態）。ある程度は、ベンチマークを公平に保つために理にかなっています。しかし、実際のエージェントは空のコンテキストウィンドウから始めるべきではありません。可能な限り多くの関連情報にエージェントがアクセスできるようにして始めるべきです。AIエージェントは記憶とともに始まるべきです。 既存のエージェント記憶システムが機能しない理由 問題は、多くのエージェント記憶システムが実際にはかなりひどいということです。現在、およそ3種類の一般的な記憶システムがあると思いますが、それぞれが独自のやり方で機能していません。最初のタイプは、特定のハーネスに意図的にあなたを縛り付けるものです。通常は、そのハーネスを貸し出すラボによって書かれています。そのラボは、「APIビジネス」（非常に競争が激しい）から、より収益性の高い「プラットフォームビジネス」へと移行することを必死に望んでいます。この種のシステムは通常、会話履歴から情報をマイニングすることで機能しますが、その結果、世界の情報が一般的にずっと役立つにもかかわらず、ほとんどの記憶があなた自身に関するものになります。 別の種類は、ばかげているほど複雑です。私は、記憶に値するものを決定するためだけに、pgvector、Neo4jグラフデータベース、そして独自のLLMを必要とする著名なシステムを知っています。この複雑さは管理が難しいだけでなく、私が説明する理由から、これらの大規模システムはモデルも混乱させます。また、モデルのフロンティアが進むにつれてスケールしません。 最後の種類は「ハイ・モダニスト」型で、理想化された合理主義的な記憶を想像します。必然的に、これにはグラフが含まれ、場合によっては論理命題も含まれます。このタイプは体系的に情報をコンテキストから剥ぎ取り、エージェント（そしてあなた）にとって孤立して無意味な状態にします。「蒸留された事実」の単純なリストは、結局のところどれほど役立つでしょうか？ それらに共通しているのは、記憶をプロセスとして扱うことです。しかし、記憶、特にモデルにとって、データとして表現する方がはるかに優れています。記憶は、マルチステージパイプラインではなく、データフォーマットであるべきです。 ブルックスはこう言いました。「私にフローチャートを見せて、表を隠してください。そうすれば、私はまだ当惑し続けるでしょう。私に表を見せてください。通常、フローチャートは必要ないでしょう。それらは明白になるでしょう。」 そこで、「memoryfield」ポータブルメモリファイルフォーマットを紹介します： my-memories.memoryfield.zip ├── carbon-fibre-woks.md ├── finnish-bureaucracy-tips.md ├── [... 他にも多くのmdファイル...] ├── wec-2026-season-notes.md └── nomic-embed-text-v1.5.sqlite3 A memoryfieldは、Markdownの「ページ」で構成され、オプションのYAMLフロントマターと、オプションのSQLiteベクトルインデックス（意味検索用）が含まれます。 エージェントはファイルとともに最もよく機能します。説明させてください。 設計上の決定1：チャンクや「事実」ではなく、散文を使用する RAGパイプラインが非常に複雑になる主な理由は、既存の、人間が作成した文書の塊をAIエージェントが読めるようにしようとしていることです。多くの場合、これらの文書はエージェントが直接読むのが非常に困難です。例えば、大きなPDFである場合などです。しかし、エージェントの記憶は複雑なレガシー文書ではありません。記憶は、形成される時点で、散文を書くことができるAIエージェントに直接生じます。その散文は、チャンク化、エンリッチメント、二重要約、またはその他の機械的処理を必要としません。エージェントがそのお気に入りのフォーマット（Markdown）で直接記憶を書き込むだけで十分です。 A memoryfieldページは次のようになります： --- title: Carbon Fibre Woks created: '2026-03-01T09:00:00Z' updated: '2026-08-22T14:30:00Z' uuid: 6aa615f0-486f-48a7-a210-ba4f5ff18c8b summary: Thermal properties of carbon fibre cookware --- Carbon fibre woks conduct heat evenly, but... 唯一の制限は、確かに、ページがベクトル埋め込みに収まるのに十分な短さでなければならないことです。そのため、約8KB（約2000トークン）のソフトリミットがあります。しかし、これは実際には非常に有益な制限です。8,000文字は約1,300語、または中程度の長さのマガジン記事の長さです。これは、実際には、課すのが理にかなっている制限です。より詳細を追加するには、さらにページを追加してください。エージェントはこれを実行するのに苦労しません。 設計上の決定2：グラフウォークではなく、セマンティックジャンプ 先行技術の重要な要素は、Karpathy wikisでした。Karpathy wikisは、ハイパーリンクされたMarkdownファイルを中心に構成されています。RoamやObsidianで使用されているものにモデル化されています。アイデアは、エージェントが「ナレッジグラフ」を歩いて関連ページを見つけることでした。しかし実際には、AIエージェントがナレッジグラフをたどるのは遅く、信頼性が低いだけでなく、エージェントを混乱させます。 美しいナレッジグラフ - AIエージェントがそれを絶対に嫌うのは本当に残念です トラバーサルが遅いのは、モデルが連続するページを読み取るために、頻繁にツール呼び出しを停止する必要があるためです。エージェントがナレッジグラフをたどるための大まかなアルゴリズム： 1. Wikiのフロントページを読む [ツール呼び出し] 2. 関連リンクを見つける 3. リンク先のページを読む [ツール呼び出し] 4. 関連リンクを見つける 5. 十分な関連情報が見つかったかどうかを決定する 6. そうでない場合は、#2に進む 関連情報がナレッジグラフでNステップ深い場合、それを取得するにはN+1回のツール呼び出しが必要です。これは遅いです。あなたの数十億（数兆？）ドルのLLMモデルは、それぞれ約2〜3秒かかる各ツール呼び出しのために一時停止する必要があります。また、深くネストされたナレッジグラフを大幅にペナルティするため、率直に言って、それはそれらの全体的な目的を損ないます。 ナレッジグラフは信頼性も低いです。AIは、リンクテキスト、または外部化されている場合はページタイトルを見ることでしか資料が関連しているかどうかを判断できないためです。これは、リンクテキスト/タイトル/キャプションが検索エージェントにとって迅速かつ正確であることを保証するために、エージェントに1990年代のSEOスタイルのページメタデータハッキングを実行するように大きな圧力をかけます。そうすることは、脱線を罰し、副次的な詳細の環境的な記録、および大規模なテキストコーパスで一般的で非常に役立つ暗黙の伝承を罰します。実際には、Karpathy wikisでは、検索エージェントにとって魅力的に見えるようにタイトルやキャプションが付けられていないため、関連情報が見逃されることがよくあります。そして、ナレッジグラフは、グラフを歩き回る際に多くの無関係な情報を精査する必要があるため、エージェントを混乱させます。意図せず無関係な情報を読むこと（フロントページがしばしば主な原因です）は、モデルのコンテキストウィンドウにノイズを大量に送り込み、出力の質を低下させ、奇妙なものに固執しているように見せます。 これはすべて、セマンティック検索を使用して、関連ページ（実際のコンテンツに基づき、ページメタデータに基づくのではなく）に直接ジャンプし、エージェントにすべての関連ページを一度に並列で読ませることで解決されます。これは、ほとんどのモデルが現在行うことです。したがって、memoryfieldでは、最大2回のツール呼び出しが必要です（#1で検索、#2で並列読み取り）。関連するものが実際に見つかり、無関係な入力トークンが最小限に抑えられます。 設計上の決定3：より多くのモデル、より少ないメカニズム 「ハイ・メカニズム」記憶システム（特別に作成されたAPIやデータベースを多数含むもの）がもたらす問題の1つは、それらを使用するために、エージェントは目標を達成するためにインターフェースの迷宮をナビゲートしなければならないことです。インターフェースが大きい場合、大量のopenapi.jsonをコンテキストにロードすることになります。インターフェースが小さい場合、それは制限的です。バランスが取れていても、APIが間違っていることがよくあります。誰かが書いたAPIを使用しなければならなかった時のことを思い出してください。その経験を楽しめましたか？ したがって、Memoryfieldsは「ロー・メカニズム」システム（単なるファイルフォーマット）であるため、エージェントは独自のアクセスパターンを考案するためのより大きな自由度を得られます。（うまくいけば）役立つツールがいくつか提供されていますが、エージェントは好きなアクセスパターンを自由に使うことができます。例えば、Perlを使ってコーパス全体で検索・置換を行ったり、メモリ内にインラインCSVファイルを配置してSQLiteでクエリしたり（どちらも私が個人的に見た実際の例です）などです。「ロー・メカニズム」であることは、memoryfieldsがモデルのフロンティアとともにスケールすることも意味します。