Brain: 知識Wikiとしてのエージェントメモリ

オフラインでコンパイルされ、オンデマンドでナビゲートされる、構造化され、追跡可能で、自己改善型のMarkdownファイルシステム。

著者Perplexity Engineering

Computerユーザーは、数か月にわたり数百のセッションに及ぶ作業を行います。10回目のセッションまでに、システムは1回目のセッションよりもはるかに生産的であるべきです。ユーザー、ユーザーの好み、およびすでに完了した作業に関するコンテキストを蓄積するべきです。

例えば、ユーザーが以前に説明したワークフローの図を描くように求められた場合、Computerはその詳細を記憶し、それらを使用してユーザーの好みのスタイルで図を作成して出力する必要があります。ユーザーがワークフローの詳細を再説明したり、PNGアーティファクトに対するPDFの好みを繰り返したりする必要はありません。システムは、過去のセッションからそのコンテキストを正確に回収し、自動的に適用できなければなりません。

メモリは、継続的なエージェントの改善の基礎です。効果的なメモリシステムは、構造化され、追跡可能で、適応性があるべきであり、エージェントが各タスクに対して適切な幅と深さで検索を行えるようにすると同時に、すべての決定を最新の情報に基づいて行うことを可能にします。

はじめに

エージェントに関連するコンテキストを吹き込むことは、多面的な問題です。まず、エージェントは存在するものとそれにアクセスする方法を知る必要があります。第二に、役立つ情報を見つけたとき、それが完全であり、正確であり、最新であることを確認する必要があります。エージェントが関連情報を見つけ、それが信頼できるソースからのものであることを確認し、より新しい観測結果で更新する必要がないことを保証できなければ、孤立した事実の価値は限られたものになります。

静的なメモリファイルをモデルコンテキストに直接詰め込むことは、エージェントへのアクセシビリティを最大化しますが、古典的な精度と再現率のトレードオフを提示します。情報が多すぎると、重要性の低いアイテムでエージェントのコンテキストウィンドウが飽和し、少なすぎると関連するコンテキストの不足により回答の品質が低下します。対照的に、外部データベースへのオンデマンドアクセスはより柔軟ですが、ナビゲーションの負担をエージェントに課します。ベクトルデータベースは多くの場合切断された断片を保存し、グラフデータベースではエージェントが効果的にクエリする方法を知る必要があります。

最近、私たちはComputerのメモリシステムのコアコンポーネントであり、両方の長所を提供する Brainを導入しました。Brainは、静的なメモリファイルとエビデンスの上に位置する構造化されたナレッジWikiです。引用によって主張がそのソースに結び付けられ、関連する情報の断片が横方向につながります。整理されたWikiにより、詳細な成果物がその下層に保持される一方で、必要に応じてコンテキストをナビゲート可能になります。

グラフとして表示されたBrainのナレッジWiki。エンティティがノードとなり、関連するサブジェクトがエッジで結ばれています。
合成ペルソナに基づいたBrainのサンプル。

Brainは、耐久性のあるメモリ記憶、クエリに答えるためにメモリを使用するフォアグラウンドエージェント、およびメモリを更新して改善するバックグラウンドエージェントという3つの主要コンポーネントを持つ包括的なメモリシステムに接続します。次の図は、Brainの全体的なシステムアーキテクチャ内に配置されたこれらのコンポーネントを描写しています。

耐久性のあるメモリ記憶、メモリを読み取るフォアグラウンドエージェント、およびメモリを更新するバックグラウンドエージェントを示すアーキテクチャ図。
メモリシステムは、共有される耐久性のあるメモリ、メモリを使用するフォアグラウンドエージェント、およびメモリを更新するバックグラウンドエージェントで構成されています。

この記事では、各層を詳細に説明し、Brainがどのようにメモリを整理し、エージェントがそれをどのように使用し、バックグラウンドプロセスがどのようにそれを最新の状態に保つかを解説します。また、Brainの設計を検証し、低コストでエージェントのパフォーマンスを向上させることを実証する、内部評価の結果についても紹介します。

メモリの整理と保管

メモリには、すべてのコンテキストの断片をプロンプトに無理に詰め込むことなく、ユーザーの全履歴にスケールする表現が必要です。Computerのメモリシステムは、持続的なコンテキストをファイルシステムとして表現します。Brainは、未加工のソース全体から知識を統合し、関連するサブジェクトを接続し、主張をそれをサポートするセッションやファイルに結び付けます。以下に詳述するこの構造により、エージェントに特に適した形でメモリを整理することができます。

ファイルシステムベースのメモリ

コンピューターセッションはすでにファイルシステム、シェル、I/Oユーティリティを備えたサンドボックス内で動作しています。Brainの設計にあたり、モデルとエージェントメモリの間のインターフェースにおける新しい仕組みの導入を最小限に抑えたいと考えました。これが、Brainをファイルシステムネイティブなコンテキスト層の上に構築した理由です。メモリはサンドボックス内の memory/ ディレクトリ下にファイルとして具体化され、エージェントは他のすべてのファイルですでに使用しているものと同じツールをメモリファイルに対しても単に使用します。

メモリツリーのルートには、さまざまな抽象度レベルでコンテキストを維持する3つのトップレベルディレクトリがあります。knowledge/ はBrainそのものであり、エンティティ、概念、アクティブなプロジェクト、および過去の学習をリンクする合成されたナレッジWikiです。notes/ にはトピックごとのフォルダーとして整理された抽出スニペットが含まれ、sessions/ には未加工の履歴としてインデックス、要約、および完全なトランスクリプトが保持されます。下の図は、レイアウトの簡略化されたビューを示しています。

knowledge/、notes/、および sessions/ のサブフォルダーを持つ memory/ を示すディレクトリツリー。
メモリファイルシステムのレイアウトのサンプルビュー。

サーフェスは意図的に冗長になっています。単純なシングルホップの質問の場合、キーワードについて /notes 内のスニペットを検索するだけで十分なことが多く、一方 /knowledge 層は、数週間または数か月のComputerセッションにわたるエビデンスを繋ぎ合わせる必要がある質問に対して最も役立ちます。

Brain: ナレッジWiki

BrainはリンクされたMarkdownファイルのシステムである LLM wiki としてフォーマットされています。この形式の軽量に構造化されたMarkdownは、既存のコンテキストの全体的なビューを提供するため、エージェントはどのようなレコードが利用可能か、それらがどのように関連しているか、そしてどこで見つかるかを簡単に理解できます。各ページは1つのサブジェクトに対する維持管理されたビューであり、リンクを通じてさらなる探索を容易にしながら、単体で読まれた際にも有用であるべきです。

リンクには2つのタイプがあります。[[wikilinks]] はコンテキストエッジです。これらはページを横方向に接続します。プロジェクトはその所有者、クライアント、またはそれが依存する概念にリンクする場合があります。これらをたどることで、「他に何を知る必要があるか？」という疑問に答えます。[cite:N] 参照はエビデンスエッジです。これらは主張を下方の、それらをサポートする未加工のセッションやコネクタソースに接続します。これらをたどることで、「これが真実であることをどうやって知るか？」という疑問に答えます。

以下の図は、合成ペルソナであるアクセシビリティ研究者のナディアにとって、Brainの一部がどのように見えるかを描写しています。彼女のBrainには、サンプルのプロジェクト、日本のユニバーサルデザインスプリントに関するページが含まれており、セッションやコネクタからの知識を統合しています。グラフビューは、ページ内に存在するコンテキストとエビデンスのエッジが、関連するエンティティとソースをどのようにリンクしているかを示しています。

MarkdownとしてレンダリングされたサンプルBrainのWikiページ。インラインでWikiリンクと引用エッジを示しています。
BrainはMarkdownファイルのシステムです。
サンプルとなるBrainのWikiページからのサブグラフ。接続されたエンティティとソースのグラフとして視覚化されています。
埋め込まれたコンテキストとエビデンスのエッジがグラフ構造を形成し、簡単にナビゲートできるようにしています。

BrainはGitバックアップによってバージョン履歴を維持し、常に進化し続ける性質をサポートしています。ページは時間の経過とともに編集でき、変更ログには主要なアップデートが記録されるため、エージェントは過去のバージョンや差分を簡単に検査できます。これはエージェント間の協調もサポートしており、複数のエージェントが同時にBrainを使用および更新する場合に極めて重要です。

Brainの使用

ユーザーからのクエリに応答する際、エージェントは適切な詳細レベルで適切なコンテキストを見つけられる必要があります。Brainの構造により、エージェントは簡単にメモリを探索できます。エージェントは、関連情報を見つけるためにコンテキストリンクをたどる、主張を検証するためにエビデンスリンクをたどる、あるいは追加のコンテキストを取得して合成するためにサブエージェントを呼び出すといった、実行可能なステップから選択できます。私たちは、関連情報へのエージェントのアクセスの容易さを最大化することを目的とした数々の方法を通じて、エージェントによる探索プロセスを誘導します。

探索戦略

初期のユーザーメッセージ内にBrainのコンパクトなインデックスを含めることで、エージェントはすでに何が存在するのかについての作業知識を持って開始できます。その後、エージェントは馴染みのある操作を使用してBrainと対話します。インデックスによって参照される特定のアイテムの読み取り、ページ全体を検索するための grep の使用、リンクのフォローと引用の検査、Gitリビジョンの比較、セッションや未加工のトラジェクトリへの降下などです。以下のコードブロックは、合成ペルソナのサンプルコマンドを描写しています。

bash
# 1. Orient: the index is a map of everything known cat memory/knowledge/index.md # 2. Target: find pages that touch the question grep -Ril "kyoto\|sendai" memory/knowledge/ # 3. Read the page; follow context edges as needed cat memory/knowledge/projects/japan-universal-design-sprint.md cat memory/knowledge/entities/sora-city-laboratory.md # via [[wikilink]] cat memory/knowledge/entities/sapphir-mobility-coop.md # via [[wikilink]] # 4. Only if the claim must be verified: resolve evidence # city bases → [cite:1], [cite:10] → pplx://sessions/<id> # # Example (pseudo, replace with your real tool): # pplx-session-fetch 1eaf53d4-09e0-5823-bb96-c8662f582708 --slice <slice-id> # 5. Some evidence lives outside the sessions # meeting slots → [cite:15] → connector://google-calendar # # pplx-connector-fetch google-calendar --query "japan-sprint"

エージェントは固定されたパイプラインではなく、自己誘導型のループを通じてこのコンテキストを探索します。したがって、エージェントは見つかったコンテキストに満足するまで検索を続けることができます。また、エージェントは、詳細を見つけたり検証したりするために引用やエビデンスを検査するタイミングを選択できます。好みの些細な事項は単一のBrainページから直接採用される場合がありますが、重大な決定やソース間の矛盾については、引用をたどって元のレコードを読むことが正当化される場合があります。グラフベースの構造により、エージェントは関連情報をあてもなく検索するのではなく、具体的な次のステップの中から選択することができます。

ページ間のリンクおよび未加工のソースへの引用をたどることによって、Brainを段階的に探索するエージェントのフロー図。
エージェントは、タスクに十分なコンテキストが揃ったと確信するまで、Brainのリンクをたどって新しいBrainのページやエビデンスソースに移動できます。

ファイルの具体化

エージェントによる探索が機能するためには、エージェントがサンドボックスのファイルシステムを通じて memory/ ツリー全体にアクセスできる必要があります。サンドボックスが起動されるたびにツリー全体をローカルにコピーすることは、コストが高く、かつエージェントがそれらのファイルの大部分に触れることがないため不要です。もう一つの選択肢は、リモートファイルシステムを使用し、エージェントがファイルをローカルにコピーせずに任意のファイルにアクセスできるようにすることです。しかし、エージェントは1つのコマンドで何千ものファイルシステム操作を実行することが多く、それぞれがネットワークリクエストになると、ラウンドトリップのコストが探索ループの大部分を占めるようになります。内部テストでは、リモートのFUSEバックトパスに対する単純な grep ワークロードは、ローカルファイルに対する同等の操作と比較して、およそ400〜500倍遅くなりました。

その代わりに、具体化されたファイルのローカルワーキングセットを構築する一方で、より大きなコーパスはメモリ取得システムの背後に保持されます。Computerは起動時に、サンドボックス上に初期マップ（最近のメモリ、セッション、要約、および利用可能な知識から取得）をプリロードします。Computerのエージェントは、セマンティック検索を実行して新しいファイルのセットをロードできるサブエージェントであるメモリ・エージェントにアクセスできます。必要なコンテキストが存在しない場合、Computerは必要な情報の記述とともにメモリ・エージェントを呼び出すことができます。メモリ・エージェントはファイルをまたがって検索し、即座のテキスト合成を返し、サポートするレコードをメモリツリーの下にファイルとして具体化します。このようにして、ワーキングセットは時間の経過とともに自然かつ徐々に拡張され、すでに存在するエビデンスの安定したパスとソースの関係が保持されます。

初期ファイルのプリロードと、ファイル図をサンドボックスに具体化するオンデマンドのメモリ・エージェントによる取得を示す図。
メモリ・エージェントによるセッションのプリロードとセマンティック検索により、エージェントが最も必要とする可能性の高いファイルの初期マップがロードされます。

この設計により、レイテンシのボトルネックが綺麗に解決されます。関連ファイルをローカルに保存することで探索に必要なファイルシステムの操作が高速に維持され、バッチ取得によって、ファイルごとに個別の呼び出しを行ったり大量の無関係なファイルをロードしたりすることなく、具体化されたファイルのプールを成長させることができます。また、ネストされたエージェントの設計により、メインエージェントが毎回バックエンドのコーパス全体を直接検索する必要がなくなり、エージェント的取得のメリットがComputerもたらされるため、最高価値の情報のために自身のコンテキストウィンドウを温存することができます。

Brainの維持管理

ユーザーは自分が行う作業や行う会話から常に学習しているため、エージェントメモリも同様に行う必要があります。Brainが有用であり続けるためには、最も重要な知識の簡潔な表現であるべきです。重要な新しいエンティティのために新しいページを作成し、関連するBrainページに新しい情報を追加し、時代遅れのコンテキストを季節ごとに削除する必要があります。たとえば、ユーザーの職が変更された場合、Brainはその変更を反映するべきであり、ユーザーの新しい職を含め、新しい責任やプロジェクトに関連する情報を優先するべきです。

Brainは私たちがDreamと呼ぶバックグラウンドエージェントによって維持されています。Dreamエージェントはファイルベースのメモリ上でオフラインで実行され、新しい情報をBrainのアップデートに統合します。私たちは、このタスクを効率的に実行するためのDreamエージェントのスコープと動作を注意深く定義するとともに、Brainのアップデートが一貫性があり正確であることを保証するためのDream固有のガードレールを策定しました。

Dream: メモリ洗練のためのバックグラウンドエージェント

Dreamエージェントは、インタラクティブなComputerセッションが持つものと同じファイルシステムと読み取り専用ツールにアクセスできるサンドボックス内で実行されますが、その唯一の目的は将来のセッションのためにコンテキストを改善することです。各実行は、ユーザーのコンテキストを最初から再構築するのではなく、以前の実行によって生成されたBrainから開始されます。その後、その現在のBrainを使用して方向性を定め、将来の実行で使用するための更新されたBrainを生成します。

ループ図: インタラクティブなセッションがDreamにフィードし、それがBrainを更新し、それが将来のセッションを改善します。
Dreamエージェントはバックグラウンドで動作してBrainを更新し、自己改善ループを形成します。

Dreamエージェントは、1つのプロンプトにフラット化された固定入力を受け取るのではなく、環境を受け取ってその探索方法を決定します。ファイルベースのメモリをナビゲートし、承認された読み取り専用のコネクタツールを使用して知識の断片を検証し、作業の限定された部分をメモリ・エージェントを含むサブエージェントに委任することができます。Dreamエージェントのスコープ（範囲）と責任は、スキルとして指定されます。

大まかに言って、Dreamの実行は4つのフェーズで構成されます。

  1. 方向付け: エージェントは順序付けられた方向付け手順を完了します。権限のスコープ、常時適用される指示、削除ログ、追加の入力、および停止条件を識別します。
  2. セッションの要約: 前回の更新以降に新しい（または新しいターンがあった）各セッションについて、エージェントはそのセッションの短い要約を記述（または更新）します。
  3. ファクトをサブジェクトに関連付ける: エージェントは、重要とみなしたすべての観測結果を、通常はWikiページである適切なホームに追加します。利用可能な場合は、認証されたコネクタをプローブしてクエリを実行します。
  4. ナレッジWikiの更新: エージェントは発見に基づいてWikiを更新します。持続的なサブジェクトのために新しいページを作成すること、現在の統合が変更されたときにページを修正すること、あるいは事実の主張をサポートする新しいリンクや引用を追加することができます。また、現在のグラフがすでに正しい場合には変更を加えないことを選択することもできます。

Brainへのすべての更新が完全かつ一貫していることを確認するために、エージェントは提案された状態をステージングされた出力ツリーに書き込みます。エージェントが必要と見なすすべての更新を行うまで、永続的な変更は行われません。それらの決定を1つのエージェントプロセスで調整することにより、関連性のないページとしてではなく、グラフ全体として更新することが可能になります。

Brainページの提案されたアップデートを生成するDreamの実行のスイムレーン図。
Dreamエージェントは、既存のBrainと新しい情報を使用して、アップデートの提案と記述を行います。

いかなる変更も、2種類の検証チェックに合格する必要があります。決定論的バリデーションチェックにより、ページが適切に形成され、必須のフロントマターや引用フォーマットなどの客観的な基準を満たしていることが保証されます。セマンティック検証チェックにより、提案された統合が収集されたエビデンスによって裏付けられており、グラフの残りの部分と一貫性を保っていることが保証されます。エージェントが正常に処理を完了した後、制御された同期ステップによってステージングされた出力が以前の状態と比較され、変更がリポジトリに適用されます。同期ステップが完了すると、一連の最終的な編集はGitのバージョン履歴を通じて検査可能になります。

Brainの検証

有用なメモリシステムは、関連するエビデンスを保持し、必要なときにそれを表面化させ、エージェントがそのエビデンスを正しい回答に変換するのを助けなければなりません。したがって、私たちは制御されたオフラインのアブレーション、継続的なペアリプレイ、および無作為化された本番実験という複数のレベルでBrainを評価します。

オフライン評価

私たちのプライマリなオフライン評価では、44の合成ペルソナにわたる640の質問の内部データセットを使用しています。これらのペルソナは、ユーザーのプライバシーを保護するために本番のクエリテキストを含めない一方で、セッションの頻度、ターン数、トピックの組み合わせ、およびファクトの密度における本番由来のパターンを再現しています。各アカウントは、メモリ抽出、会話の要約、およびナレッジWikiのDreamによるコンパイルを含む本番のメモリパイプラインを通じてデータが投入されます。各質問に対し、正しい回答はアカウントの履歴に存在する特定のエビデンスに機械的に結び付けられています。

たとえば、先ほど紹介したアクセシビリティ研究者の合成ペルソナであるナディアの場合、データセットには「京都と仙台でどの組織と会う予定ですか？」という質問が含まれています。その答え（京都のSora City Labと仙台のSapphir Mobility Coop）は、対応するWikiページに直接記載されています。

コンパイルされたナレッジWikiを有効にした状態と無効にした状態で、同じ質問とアカウントを比較します。その他のメモリサーフェスは両方の条件で引き続き利用可能です。これにより、メモリなしとの比較ではなく、Brainのインクリメンタルな寄与を切り分けています。全体として、Brainにより回答の正確性が0.600から0.661へと向上し（6.1パーセンテージポイントの増加）、エビデンスの再現率が0.573から0.625へと向上しました（5.2パーセンテージポイントの増加）。この効果は、好みに関する質問（+10.2 pp）、時間的推論（+8.6 pp）、および以前のアクティビティからの詳細の抽出（+6.9 pp）に関する質問で最も顕著でした。質問の84%において、エージェントは確実にご褒美のエビデンスに結び付けられたソースにアクセスしました。

質問カテゴリ全体で、Brainがある場合とない場合の回答の正確性とエビデンスの再現率を比較する棒グラフ。
Brainは内部ベンチマークのパフォーマンスを向上させます。

また、2つの公開ベンチマークのサブセットに対して一致させたBrainのアブレーションを実行しました。LoCoMoでは、Wikiを削除すると、異なるモデルを使用した3回の実行において、回答の正確性が平均で4.6パーセンテージポイント低下しました。LongMemEval-Sでは、統計的に有意な変化は生じませんでした。この結果は、Brainの意図された役割と一致しています。LongMemEval-Sは主に個別のセッションからのファクトの回収をテストするものであり、そこでは基盤となるトランスクリプトが回答への冗長なパスを提供します。LoCoMoは、会話、話者、および日付に分散されたエビデンスに重点を置いており、Wikiのセッション間合成が貢献する機会をより多く生み出します。

全体として、Brainが有効な場合、本番エージェントはLongMemEval-Sで0.91、LoCoMoで0.83の回答正確性を達成しました。これらの実験ではベンチマークのサブセットが使用されたため、決定的なベンチマーク結果ではありません。しかし、アブレーションは、特に会話全体にわたってエビデンスを統合する必要がある場合に、Wikiがパフォーマンスを向上させるという強いシグナルを提供し続けます。Brainは最適化されたベンチマーク特化型の取得システムではなくComputerの一部であるため、本番のワークフローにより似たタスクにおいて競争力はさらに高まると確信しています。

オンライン評価

オフラインデータセットでは実際のユーザー履歴のすべての機能をキャプチャできないため、新鮮な本番由来のコホートに対して毎日のペア評価も実行します。同じ固定の質問に対して、Brainが有効および無効にされた一致するユーザー状態に対して回答が生成され、その後正確性、最新性、および再現率について判定されます。

6月18日に報告された初期結果は、Brainが回答の正確性を25%、再現率を16%向上させることを実証しました。これらのパフォーマンスの向上は維持され続けており、過去30日間において、Brainが有効なセッションはすべての実行およびすべての評価されたディメンションにおいてコントロールを上回りました。絶対値として、Computerユーザーは、正確性で9.3ポイント、最新性で8.0ポイント、再現率で8.9ポイントの向上を享受しました。また、Brainが有効なトラジェクトリでは、トークンが約15%少なくなり、コストが10%低くなり、生成が10%速くなりました。

トークン、コスト、およびレイテンシの削減と並行して、正確性、最新性、および再現率の向上を示すオンラインペア評価結果のチャート。
Brainは回答の品質を向上させ、コストを削減します。

継続的な改善

ユーザーに最高のメモリ体験をもたらすために、私たちはBrainの洗練を続けています。最近の変更の1つとして、エージェントが後から発見して読み取ることを要求するのではなく、Brainのコンパクトなインデックスをエージェントの初期コンテキストに直接配置するようにしました。ランダム化された実験において、このプリフィル処理により、Brainの使用量が増加し、メモリ関連の不満が6.9%減少しました。

オフライン評価ハーネスは、自律的改善パイプラインの一部としても機能します。Brainのメモリサブエージェント、取得スキル、およびプロンプトに対する提案された変更は、内部データセットおよび公開ベンチマークに対するマッチしたアブレーションを通じて実行されます。Computerのエージェントは結果に対して自律的に反復処理を行い、各イテレーションの変更、デルタ、およびコストを耐久性のあるレコードとして保持し、数値を動かす変更のみを保持します。その結果、Brainの評価者がその最適化担当者ともなり、将来の改善を推進するシステムが実現します。

結論

継続的な学習は、数週間および数か月にわたって機能するエージェントシステムを構築するための決定的な課題の1つです。メモリアーキテクチャは、エージェントが通常のツールセットを使用して直接探索できる環境として公開されるのが最適であると私たちは考えています。メモリをファイルシステムとして公開し、その上に構造化されたナレッジWikiとしてのBrainを配置することで、シンプルで使い慣れたツールを通じてコンテキストを効率的にナビゲート可能になります。

Brainは自己改善できるように設計されているため、使用量が増えるにつれてメモリシステムをさらに向上させることができます。Dreamのバックグラウンドエージェントは最新情報をBrainのアップデートに要約（ディステル）し、フォアグラウンドエージェントが常に最新のコンテキストが整理されたビューで新しいセッションを開始できるようにします。評価ハーネスは、コアメモリアーキテクチャおよびエージェント向けインターフェースにおける自動リサーチ（オートリサーチ）ループのテストベッドとしても機能します。

すでに、Brainにより消費トークン数を削減しながら、より正確でパフォーマンスの高いエージェントセッションが実現しています。ComputerのプロダクションスタックとBrainを慎重に共同設計したことにより、これらのメリットがユーザーにとっての実際の利益に直接還元されることが保証されます。

Computerのメモリの品質を向上させるための機能を引き続き構築しています。その間、Brainが有効になっているユーザーの場合、メモリはセッションごとに向上します。