ZEP-Graphiti：インテリジェンスにおける記憶のための時間的知識グラフ・アーキテクチャ

速記

知的身体記憶への挑戦とゼップのイノベーション

AIエージェントは複雑なタスクにおいてメモリのボトルネックに直面している。従来の大規模言語モデル(LLM)ベースのAIエージェントはコンテキストウィンドウに制約されており、長期的な会話履歴や動的データを効果的に統合することが困難で、パフォーマンスが制限され、幻覚を見やすくなっています。Zepは革新的なナレッジグラフアーキテクチャであり、コアコンポーネントであるGraphitiを通じて、動的な情報環境に対処するための強力なメモリ機能をAIエージェントに提供します。Zepは、革新的なナレッジグラフアーキテクチャであり、コアコンポーネントであるGraphitiを通じて、AIエージェントに強力なメモリ機能を付与し、動的な情報環境に対応することができます。

実装： グラフィティ - 時間を意識した知識グラフエンジン

グラフィティ インテリジェントな身体記憶は、マルチレベルの知識グラフの構築、時間情報の動的管理、効率的な検索メカニズムによって実現される。

1. マルチレベルの知識グラフ構築
   • プロットのサブプロット： 生データ（ダイアログメッセージ）は、テキストとタイムスタンプを含むプロットノードとして使用される。
   • 意味実体部分グラフ： エンティティ（人名、地名、商品名など）は、セマンティック・エンティティ・ノードとしてプロット・ノードから抽出される。
   • コミュニティ・サブマップ 同じトピックに関するエンティティノードを集約してコミュニティノードを形成する。
   • この階層構造は拡張性を高め、インテリジェンスがより効率的に情報を理解することを可能にする。
2. 時系列情報をダイナミックに管理：
   • 二時間モデル： イベントのタイミング（タイムラインT）とデータの取り込みタイミング（タイムラインT'）を記録し、絶対／相対時間情報を処理する。
   • ダイナミック・アップデート： ナレッジグラフをリアルタイムに更新し、時間的なコンフリクトを処理する。
   • グラフィティの時系列認識機能は、情報の正確性と最新性を保証します。
3. 効率的な検索メカニズム：
   • 多方式の統合： コサイン類似検索、全文検索、幅優先検索を組み合わせて、関連するコンテキストをすばやく正確に検索します。

エンタープライズ・アプリケーション：完全なサンプル・プロセス

取る企業向けカスタマーサポート・インテリジェンス

ユーザー入力::
先月購入したHP LaserJet Pro MFP M28wプリンターに問題があり、印刷物にゴーストが発生しています。以前テクニカルサポートに連絡したところ、プリンタを再起動すれば問題が解決すると言われたのですが、それを試してもまだ解決しません。"

1.エピソード・ノード摂取::
グラフィティは、ユーザーの最新ニュースを、現在のタイムスタンプ（例：2024年2月20日午前10時30分）を持つ新しいエピソード・ノードとしてナレッジグラフに取り込む。同時に、システムは「プリンター問題」に関連する過去の対話エピソードを検索する。

2.エンティティと関係の抽出::

• 物理的抽出::
  • プリンタモデル：HP LaserJet Pro MFP M28w
  • 購入日：2024年1月10日
  • 問題の内容: 文書を印刷するとゴーストが発生する
  • 前回連絡：2024年1月15日
  • 前の解決策：プリンタを再起動する
• 関係抽出::
  • [ユーザー] 購入 [プリンター］
  • プリンター]の問題[印刷された文書に二重画像がある]。
  • [プリンターの再起動] はい [解決策] 試しました。

3.コミュニティ・テスト::
このシステムは、プリンタ "HP LaserJet Pro MFP M28w "に関連するすべてのエンティティと関係を1つのコミュニティに集約し、より効率的な検索を可能にします。

4.情報の動的更新::
グラフィティは更新が必要な情報をチェックします。 プリンターを再起動しても問題が解決されないというユーザーからの報告を受けて、システムは [プリンタの再起動]の[解決状況]。 というのも [未解決］.

5.関連コンテキストの検索::
システムは複数の検索方法を用いて検索する：

• 全文検索"プリンター"、"リイメージ"、"HP LaserJet Pro MFP M28w "などのキーワードを含む過去のダイアログを取得します。
• コサイン類似度検索印刷がぼやける」、「印刷の色がゆがむ」など、印刷に関する類似の問題を説明するダイアログを検索します。
• 幅優先探索より [HP LaserJet Pro MFP M28w】。］ コミュニティは、このプリンターモデルに関連するすべての一般的な問題と推奨される解決策を見つけることに着手しました。

6.回答の生成::
スマートボディは、取得したコンテキスト情報に基づいて、以下のレスポンスを生成する：

「こんにちは！ご意見ありがとうございます。 ご購入いただいたHP LaserJet Pro MFP M28wプリンターでゴーストが発生する文書が印刷されるとのことですが、以前にプリンターの再起動を試したことがあるとのことですが、それでも問題が解決しないとのことです。お客様の問題をより良く解決するために、以下の手順を試してみることをお勧めします：

1. カートリッジをチェックする： カートリッジが正しく取り付けられ、インクレベルが十分であることを確認してください。
2. プリントヘッドを清掃する： プリントヘッドが詰まっているとゴーストが発生することがあります。プリントヘッドのクリーニングをお試しください（手順についてはプリンタのマニュアルを参照してください）。
3. ドライバーを更新する： HPのウェブサイトから最新のプリンタドライバをダウンロードしてインストールしてください。

上記の手順を試しても問題が解決しない場合は、さらにトラブルシューティングを行うため、以下の情報をお知らせください：

• お使いのOSのバージョンは？
• ゴーストの問題は、すべての文書で発生するのですか、それとも特定の文書で発生するのですか？

ご協力ありがとうございました

7.知識の更新::
ユーザーがカートリッジを交換することで問題を解決した場合、インテリジェント・ボディは次のことを記録します。 [インクカートリッジの交換］ 沈降 [ゴーストが発生する文書の印刷] 問題 効果的な解決策を提示し、関連するエンティティや関係のタイムスタンプを更新して、その後の参照に役立てる。

実験結果と今後の展望

ゼップ LongMemEval評価では、ベースラインと比較して、gpt-4oモデルを使用した場合、精度が18.51 TP3T向上し、応答待ち時間が901 TP3T短縮した。 実験結果は、Zepが記憶精度、動的更新能力、効率的な検索、およびスケーラビリティの点で大きな利点を持つことを証明している。

今後の研究の方向性は以下の通りである：

• モデルの微調整：知識抽出の精度と効率の最適化。
• ドメイン・オントロジーの統合：特定のドメインに関する理解と推論の強化。
• 新しいベンチマーク開発：進化するメモリシステム。

関連アイテムGraphiti: ダイナミックな知識グラフの構築とクエリーツール（時間を考慮したロングメモリプログラム）

抄録

我々は、Deep Memory Retrieval (DMR)ベンチマークにおいて現在の最先端システムMemGPTを凌駕する、インテリジェンス向けの新しいメモリレイヤーサービスであるZepを紹介する。さらに、Zepは、実際のエンタープライズユースケースをよりよく反映した、DMRよりも包括的で困難な評価において優れた性能を発揮する。既存の大規模言語モデル（LLM）ベースの検索拡張生成（RAG）フレームワークは静的な文書検索に限定されていますが、企業アプリケーションでは進行中の会話やビジネスデータを含む様々なソースからの知識を動的に統合する必要があります。Zepはこの基本的な制限を、コア・コンポーネントである時系列認識ナレッジグラフエンジンGraphitiによって解決します。MemGPTチームが設定したDMRベンチマークにおいて、Zepはその優れた性能を実証しました（94.81 TP3T vs. 93.41 TP3T）。DMR に加えて、Zep の能力はより複雑な LongMemEval ベンチマ ークでさらに検証されました。このベンチマークは、複雑な時間推論タスクを通 じて企業のユースケースをよりよく反映しています。この評価では、Zepはベースライン実装と比較して、応答待ち時間を901 TP3T短縮しながら、精度を最大18.51 TP3T向上させました。これらの結果は、セッションをまたがる情報合成や長期的なコンテキスト維持などの企業にとって重要なタスクにおいて特に重要であり、実世界のアプリケーションにおけるZepの有効性を実証しています。

1.はじめに

近年、Transformerベースの大規模言語モデル（LLM）が産業界や研究コミュニティに与える影響に注目が集まっている[1]。LLMの主な応用例の1つは、チャットベースのインテリジェンスの開発である。しかし、これらの知能の能力は、LLMのコンテキストウィンドウ、効果的なコンテキストの利用、および事前学習で得られた知識によって制限される。そのため、領域外（OOD）知識を提供し、錯覚を減らすために、追加のコンテキストが必要である。

RAGは、LLMに必要なドメイン知識を提供するために、過去50年間に開拓された情報検索（IR）技術[2]を利用している。

RAGを使用するための現在のアプローチは、広範なドメイン知識と比較的静的なコーパスに焦点を当てている。インテリジェンスが日常生活に浸透し、些細な問題から非常に複雑な問題まで自律的に解決するようになるためには、ユーザとインテリジェンスとのインタラクションや、関連するビジネスや世界のデータから得られる、常に進化し続ける大規模なコーパスにアクセスする必要がある。我々は、インテリジェンスにこのような広範で動的な「記憶」を与えることが、このビジョンを実現するための重要な要素であると考えており、現在のRAGアプローチがこのような未来に適しているとは考えていない。対話履歴全体、ビジネスデータセット、その他のドメイン固有のコンテンツは、LLMのコンテキストウィンドウに効率的に適合しないため、知的身体記憶への新しいアプローチを開発する必要がある。LLM駆動型知能に記憶を追加することは新しいアイデアではなく、このコンセプトはMemGPT [3]で以前に検討されている。

近年、知識グラフ（KG）は、従来のIR技術の欠点の多くに対処するために、RAGアーキテクチャを補強するために使用されている[4]。Zepは、構造化されていないメッセージデータと構造化されたビジネスデータを取り込み、合成します。Graphiti KGエンジンは、有効期限を含む時間軸上の事実と関係を保持しながら、損失がない方法で知識グラフを動的に更新します。ナレッジグラフを動的に更新します。このアプローチにより、ナレッジグラフは複雑で進化する世界を表現することができます。

Zep は量産システムであるため、メモリ検索メカニズムの精度、レイテンシ、およびスケーラビリティを重要視しています。これらのメカニズムの有効性を評価するために、MemGPT [3]のDeep Memory Retrievalタスク(DMR)とLongMemEvalベンチマーク[7]の2つの既存のベンチマークを使用します。

2.ナレッジ・マッピング

Zepでは、記憶は時間的知覚動的知識グラフG = (N,E,φ)で構成される。G=(N,E,ϕ) をサポートする。N はノード、EE はエッジを表し、φ:E → N × Nφ:E→N×N は形式化された関連関数を表す。このグラフには、プロットサブグラフ、意味エンティティサブグラフ、コミュニティサブグラフの3つの階層サブグラフが含まれる。

- エピソード・サブプロット Geゲー :

プロット・ノード（プロット）、ni∈Neニ（ネメッセージ、テキスト、またはJSONの形で未加工の入力データを含む。意味的なエンティティと関係が抽出される、失われないデータストアとしてのプロット。プロットエッジ、ei（Ee）⊆ϕ＊（Ne×Ns）。ei（Ee⊆φ∗（Ne×Ns）これは、エピソードとそのエピソードが参照する意味上の実体を結びつけるものである。

- 意味実体部分グラフGsグラム :

意味エンティティサブグラフは、プロットサブグラフの上に構築される。エンティティノード（エンティティ）、ni∈Nsニ（Nsプロットから抽出され、既存のグラフ実体と解決された実体を表す。エンティティ・エッジ（セマンティック・エッジ）、ei∈Es⊆φ＊（Ns×Ns）。ei（Es⊆φ∗（Ns×Ns）プロットから抽出されたエンティティ間の関係を表す。

- コミュニティ・サブマップGcGc :

コミュニティ・サブグラフはZep知識グラフのトップレベルを形成する。コミュニティ・ノード（コミュニティ）、ni（Ncニ（Ncこれは、強く結びついたエンティティのクラスターを表す。コミュニティはこれらのクラスターの高レベルの要約を含み、Gsグラム の構造について、より包括的で相互に結びついた見方をする。コミュニティ・エッジ、ei∈Ec⊆φ＊(Nc×Nˉs)ei（Ec⊆ϕ∗（Nc×N_2C9↩s）コミュニティとその物理的なメンバーをつなぐものである。

生のエピソードデータと派生した意味的な実体情報の二重の記憶は、人間の記憶のメンタルモデルを反映している。これらのモデルは、さまざまな出来事を表すエピソード記憶と、概念とその意味との関連を捉える意味記憶を区別する[8]。このアプローチにより、Zepを使用するLLM知能は、人間の記憶システムに関する我々の理解により合致した、より複雑で微妙な記憶構造を開発することができる。知識グラフは、これらの記憶構造を表現するための効率的な媒体を提供し、我々が実装した異なるエピソードと意味サブグラフは、AriGraph [9]の同様のアプローチを利用している。

高レベルの構造とドメイン概念を表現するためにコミュニティ・ノードを使用することで、GraphRAG [4]の研究を発展させ、ドメインのより包括的でグローバルな理解を可能にしている。その結果、プロットからファクト、エンティティ、コミュニティへと階層的な構成ができ、既存の階層的なRAG戦略[10][11]を拡張している。

2.1 エピソード

Zepのグラフ構築は、エピソードと呼ばれる生データを取り込むことから始まる。エピソードは、メッセージ、テキスト、JSONの3つのコア・タイプのいずれかになる。各タイプは、グラフ構築時に特定の処理を必要とするが、本稿では、実験が対話記憶に集中しているため、メッセージ・タイプに焦点を当てる。私たちのコンテキストでは、メッセージは比較的短いテキスト（LLMのコンテキストウィンドウに複数のメッセージを収めることができる）と、その談話を生成した関連する参加者で構成される。

各メッセージには、参照タイムスタンプ trefトレフメッセージの送信時刻を示す時刻。この時間的情報により、Zep はメッセージの内容で言及された相対的または部分的な日付 (たとえば、「次の木曜日」、「2 週間後」、「去年の夏」など) を正確に識別し、抽出することができます。Zepは通時的モデルを実装し、タイムラインTT はイベントの時間的順序を表し、タイムラインT′はイベントの時間的順序を表す。T′ はZepデータ取り込みのタイミングトランザクションを表す。一方、T′はT′ タイムラインはデータベース監査の伝統的な目的を果たすが、TT タイムラインは、対話データとメモリの動的な性質をモデル化するための付加的な次元を提供する。このデュアルタイムアプローチは、LLM知識グラフ構築における新しい進歩であり、これまでのグラフベースのRAG提案と比較したZepのユニークな機能を支えている。

プロット・サイドイー プロットとその抽出されたエンティティノードを接続します。プロットとその派生セマンティックエッジは、エッジとそのソースプロット間の関係を追跡する双方向インデックスを保持します。この設計により、Graphitiのプロットサブグラフの非破壊的な性質が強化され、前方および後方のトラバーサルが可能になります。意味的な人工物は、参照や引用のためにそのソースをさかのぼることができ、プロットは関連するエンティティやファクトをすばやく検索することができます。これらの関連は、本論文の実験では直接検証されなかったが、今後の研究で検討される予定である。

2.2 意味的エンティティとファクト

2.2.1 エンティティ

エンティティ抽出はエピソード処理の初期段階を表す。取り込みプロセスでは、システムは現在のメッセージ・コンテンツと最後の nn メッセージは、名前付きエンティティ認識のためのコンテキストを提供する。本稿とZepの一般的な実装では、n = 4n=4また、文脈評価用に2ラウンドの対話が用意されている。メッセージ処理に重点を置くため、話し手はエンティティとして自動的に抽出される。最初のエンティティ抽出の後、reflection[12]に着想を得たリフレクション技法を採用し、イリュージョンを最小化し、抽出カバレッジを向上させる。また、その後のエンティティ解決と検索操作を容易にするために、エピソードからエンティティの要約を抽出する。

抽出後、各エンティティ名を1024次元のベクトル空間に埋め込む。この埋め込みにより、既存のグラフのエンティティノードをコサイン類似度で検索して、類似ノードを取り出すことが可能になる。このシステムは、さらに候補ノードを特定するために、既存のエンティティ名とアブストラクトに対して個別に全文検索も実行します。これらの候補ノードは、プロットコンテキストとともに、LLMを介して、エンティティの解決ヒントを使用して処理されます。システムが重複エンティティを識別すると、更新された名前と抄録が生成されます。

エンティティの抽出と構文解析の後、システムは定義済みのCypherクエリを使用してデータを知識グラフに統合する。LLMが生成するデータベースクエリよりもこのアプローチを選んだのは、一貫したアーキテクチャ形式を保証し、幻覚の可能性を減らすためである。

グラフを作成する際のヒントは、付録の中にある。

2.2.2 事実

のキー述語を含む各ファクトを抽出することができます。同様に、異なるエンティティ間で同じファクトを複数回抽出することができるため、Graphitiはハイパーエッジを実装することで、複雑な複数エンティティのファクトをモデル化することができます。

抽出後、システムはグラフ統合に備えてファクトの埋め込みを生成する。システムは、エンティティ解決と同様のプロセスによってエッジの重複排除を行う。ハイブリッド検索に関連するエッジは、新しいエッジと同一であるエンティティのペア間に存在するエッジに制限される。この制限は、異なるエンティティ間の類似エッジの不正な組み合わせを防ぐだけでなく、検索空間を特定のエンティティペアに関連するエッジのサブセットに制限することで、重複排除の計算量を大幅に削減する。

2.2.3 時間抽出とエッジの失敗

他のナレッジグラフエンジンと比較した場合のGraphitiの主な差別化点は、一時的な抽出とエッジの障害処理を通じて、動的な情報の更新を管理できることです。

システムはトレフを使用する。トレフ プロットの文脈から事実の時間的情報を抽出する。これにより、絶対的なタイムスタンプ（例えば、「アラン・チューリングは1912年6月23日に生まれた」）や相対的なタイムスタンプ（例えば、「2週間前に新しい仕事を始めた」）の時間表現を正確に抽出し、日付を付けることが可能になる。私たちの首尾一貫したモデリング・アプローチに従い、システムは4つのタイムスタンプを追跡する。t′ を作成する。t′ 有効期限∈ T′ は、ファクトがシステム内で作成または無効化されるタイミングを監視する。有効 とスズバリッド∈Tすず 事実が確立された時間枠を追跡する。これらの時間データポイントは、他の事実情報とともにサイドに保存される。

新しいエッジの導入は、データベース内の既存のエッジを無効にする可能性がある。システムはLLMを用いて新しいエッジを意味的に関連する既存のエッジと比較し、潜在的な矛盾を特定する。システムが矛盾する時間的矛盾を識別する場合、スズ有効エッジとスズ無効エッジを比較することで、それを行う。錫病 失敗側でtvalidに設定有効 を使用して、影響を受けるエッジを無効にする。トランザクションタイムラインT′に従ってT′グラフティはエッジの失敗を判断する際、常に新しい情報を優先する。

この包括的なアプローチにより、関係の現在の状態や時間の経過とともに発展した関係の履歴を維持しながら、会話の発展に合わせてデータを動的にGraphitiに追加することができます。

2.3 コミュニティ

プロットとセマンティックサブグラフを構築した後、システムはコミュニティ検出によってコミュニティサブグラフを構築する。我々のコミュニティ検出アプローチはGraphRAG [4]で説明されている技術をベースにしているが、Leidenアルゴリズム[14]ではなく、Label Propagationアルゴリズム[13]を採用している。この選択は、ラベル伝播の単純な動的スケーリングに影響され、新しいデータがグラフに入るにつれて、システムは正確なコミュニティ表現をより長く維持することができ、コミュニティの完全な更新の必要性を先送りする。

動的拡張は、ラベル伝播における単一の再帰的ステップのロジックを実装する。システムが新しいエンティティ・ノードni∈Nsをグラフに追加するときニ（Ns その際、近隣ノードのコミュニティを調査する。システムは新しいノードをその隣接ノードの大多数が持つコミュニティに割り当て、それに応じてコミュニティの要約とグラフを更新する。この動的な更新により、データがシステムに流れ込むにつれてコミュニティが効率的に拡張される一方で、結果として生成されるコミュニティは、完全なラベル伝播の実行によって生成されたものから徐々に逸脱していく。そのため、定期的なコミュニティの更新は依然として必要である。しかし、この動的更新戦略は、待ち時間とLLM推論コストを大幅に削減する実用的なヒューリスティックを提供する。

4]に従って、我々のコミュニティ・ノードは、反復的なマップ・リダクション・スタイルによってメンバー・ノードの要約を含んでいる。しかし、我々の検索アプローチはGraphRAGのマップ削減アプローチ[4]とは全く異なる。我々の検索アプローチをサポートするために、コミュニティの要約からキーワードと関連するトピックを含むコミュニティ名を生成した。これらの名前は、余弦類似検索を可能にするために埋め込まれて保存される。

3.記憶検索

Zepの記憶検索システムは強力で洗練され、高度に設定可能な機能を提供する。全体として、Zepグラフ検索APIは関数f:S→Sを実装する。f:S→Sを受け付ける。α ∈ S を入力とし、テキスト文字列コンテキストβ∈Sβ ∈ S を出力とする。出力ββ LLMインテリジェンスがクエリαに対して生成した、ノードとエッジのフォーマットされたデータが含まれる。α の正確な応答に必要なプロセスf(α) → βf(α) → β それは3つの異なるステップで構成されている：

- 検索 (φ)(φ)このプロセスではまず、関連情報を含む可能性のあるノードとエッジの候補を特定する。Zepはいくつかの異なる探索方法を採用しているが、全体的な探索関数はφ:S→Esn-×Nsnˉ×.Ncnと表すことができる。φ:S→Esn-×Nsnˉ×。Ncn.したがって、φφ クエリを、セマンティック・エッジ、エンティティ・ノード、コミュニティ・ノードのリストを含む3タプルに変換する。

- レオーデラー（ρ）(ρ)第2段階は検索結果の並び替えである。並べ替え関数またはモデルは検索結果のリストを受け取り、これらの結果の並べ替えバージョンを生成する：ρ:φ(α),...→Esn×Nsn×Ncnρ:φ(α), ...→ Esn×Nsn×Ncn.

- コンストラクタ（χ）(χ)最後のステップで、ビルダーは関連するノードとエッジをテキストコンテキストに変換する： χ:Esn×Nsn×Ncn→Sχ:Esn×Nsn×Ncn→S.各 ei ∈ Es に対してei（Esχχ ファクトとtvalidを返す有効スズバリ。錫病 フィールド；各ni∈Nsに対してニ（Ns名前フィールドと要約フィールドを返す。ニ（Nc要約フィールドを返す。

これらの定義が整えば、ff は、これら3つの成分の組み合わせとして表される。f(α)= χ(ρ(φ(α))) = βχ(ρ(φ(α))) = β.

コンテキスト文字列テンプレートの例：

事実と事業体 現在のダイアログに関連するコンテキストを表します。
これらは最も関連性の高いファクトとその有効な日付範囲です。 ファクトがイベントに関するものである場合、そのイベントはこの期間に発生しました。
フォーマット: fact (日付範囲: from - to)
<ファクト
{ファクト｝
</fact
これらは最も関連性の高いエンティティです。
エンティティ名: エンティティ概要
<エンティティ
{エンティティ｝
</エンティティ

3.1 検索

Zepは3つの検索関数を実装している：余弦意味類似度検索(φcos)(φcos）オカピBM25(φbm25)の全文検索がインターネット上で可能です。(φbm25) と幅優先探索(φbfs)(φbfs).最初の2つの関数は、Neo4jのLuceneの実装[15][16]を利用している。それぞれの検索関数は、関連文書を特定するという点で異なる機能を提供し、一緒に並べ替え前の候補結果の包括的なカバレッジを提供する。検索フィールドは3つのオブジェクトタイプで異なります。エスファクト・フィールドを検索する。Nsの場合、エンティティ名を検索する。エヌシーLightRAG[17]では、コミュニティで扱われている関連キーワードやフレーズを含むコミュニティ名を検索する。独自に開発されたものではあるが、我々のコミュニティ検索アプローチは、LightRAG [17]の高度なキー検索アプローチと類似している。LightRAGのアプローチとGraphitiのようなグラフベースのシステムとの組み合わせは、将来の研究の有望な方向性を提供する。

RAG[18]では、余弦類似度や全文検索法がよく確立されているが、知識グラフ上の幅優先検索は、AriGraph[9]やDistill-SynthKG[19]のようなグラフベースのRAGシステムにおける顕著な例外を除いて、RAGドメインでは限られた注目しか集めていない。Graphitiでは、幅優先探索はnn ホップ内のノードとエッジを追加し、最初の検索結果を向上させる。さらに、φbfsφbfs ノードは検索パラメータとして受け付けることができるため、検索機能をより詳細に制御することができる。この機能は、幅優先検索のシードとして最近のエピソードを使用する場合に特に有用であり、システムは最近言及されたエンティティや関係を検索されたコンテキストに組み込むことができる。

全文検索は単語の類似性を特定し、コサイン類似性は意味的類似性を捉え、幅優先検索は文脈的類似性を明らかにする。このような多面的なアプローチにより、最良の文脈を発見する可能性が最大化される。

3.2 再注文者

ZepはRRF（Reciprocal Ranking Fusion）[20]やMMR（Maximum Marginal Relevance）[21]などの既存の並べ替え手法をサポートしている。さらに、Zepはグラフベースのエピソード言及並べ替え機能を実装しており、エンティティやファクトが会話で言及される頻度に基づいて結果を優先し、頻繁に引用される情報にアクセスしやすくします。このシステムには、指定された中心ノードからの距離に基づいて結果を並べ替えるノード距離並べ替え機能も含まれており、知識グラフの特定の領域を特定するためのコンテキストを提供します。このシステムの最も洗練された並べ替え機能は、クロスエンコーダを採用している。クロスエンコーダは、LLMのクエリに対してノードとエッジを評価するクロスアテンションを使用して関連性スコアを生成する。

4.実験

本節では、LLM記憶に基づくベンチマークテストを用いて行われた2つの実験を分析する。最初の評価では、"Beyond Goldfish Memory: long-term open-domain dialogue" [22]で紹介されたマルチセッションチャットデータセットから500の会話のサブセットを使用し、[3]で開発されたDeep Memory Retrieval (DMR)タスクを使用する。2つ目の評価では、"LongMemEval: Benchmarking Chat Assistants on Long-Term Interaction Memory" [7]のLongMemEvalベンチマークを使用する。具体的には、LongMemEval ．⋅ このデータセットは、平均115,000トークンの長さの幅広い対話コンテキストを提供する。

両実験とも、ZepのAPIを介して対話履歴をZep知識グラフに統合した。そして、セクション3で説明した技術を使用して、最も関連性の高い20のエッジ（事実）とエンティティノード（エンティティの要約）を取得する。システムはこのデータをZepのMemory APIが提供する機能と一致するコンテキスト文字列に再フォーマットする。

これらの実験は、Graphitiの主要な検索機能を実証するものであるが、システムの全検索機能のサブセットを示すものである。このように範囲を絞ることで、既存のベンチマークテストとの明確な比較が可能になると同時に、今後の研究のために知識グラフを探索する機能を追加しておくことができます。

4.1 モデルの選択

我々の実験的実装では、並べ替えと埋め込みタスクにBAAIのBGE-m3モデルを使用している[23][24]。グラフ構築と応答生成には、グラフ構築にはgpt-4o-mini-2024-07-18を、提供されたコンテキストに対する応答を生成するチャット・インテリジェンスにはgpt-4o-mini-2024-07-18とgpt-4o-2024-11-20を使用する。

MemGPTのDMR結果と直接比較できるように、gpt-4-turbo-2024-04-09を使ったDMR評価も行った。

実験ノートブックはGitHubリポジトリで公開され、付録には関連する実験のヒントが含まれる。

表1：深層記憶検索

結果は[3]に報告されている。

4.2 ディープメモリー検索（DMR）

深層記憶検索評価は[3]によって導入され、500のマルチセッションダイアログで構成され、各ダイアログには1セッションあたり最大12メッセージの5つのチャットセッションが含まれる。MemGPTフレームワーク[3]は現在、gpt-4-turboを使用して93.41 TP3Tの精度で性能指標をリードしており、これは再帰的要約ベースラインの35.31 TP3Tを大幅に上回っている。

比較のベースラインを確立するために、2つの一般的なLLM記憶法を実装した。gpt-4-turboを使用した場合、フルダイアログのベースラインは94.41 TP3Tの精度を達成し、MemGPTが報告した結果よりわずかに高いが、セッションサマリーのベースラインは78.61 TP3Tを達成した。発表された研究に十分な方法論的詳細がないため、gpt-4o-miniを使用したMemGPTの結果を再現することはできませんでした。

Zepはgpt-4-turboで94.81 TP3T、gpt-4o-miniで98.21 TP3Tの精度を達成した。を達成し、MemGPTと対応する完全な対話ベースラインに対してわずかな改善を示した。各ダイアログには60のメッセージしか含まれず、現在のLLMコンテキストウィンドウに簡単に適応できます。

DMR評価の限界は、その規模の小ささにとどまらない。我々の分析は、このベンチマークテストの設計に重大な弱点があることを明らかにした。この評価は単発の事実検索問題だけに頼っており、複雑な記憶理解を評価することができない。多くの問題には曖昧な表現が含まれており、「好きなリラクゼーションドリンク」や「奇妙な趣味」のような、対話の中で明確に説明されていない概念を呼び出している。決定的なのは、このデータセットが、LLM知能の実際の企業ユースケースに適していないことである。最新のLLMの単純なフルコンテキストアプローチを使用して達成された高い性能は、メモリシステムの評価におけるこのベンチマークの欠点をさらに浮き彫りにしている。

この欠点は、LongMemEvalベンチマークにおけるLLMの性能が、ダイアログの長さが長くなるにつれて急速に低下することを示す[7]の調査結果によってさらに強調されている。LongMemEvalデータセット[7]は、より長く、より首尾一貫したダイアログを提供し、企業シナリオをよりよく反映し、より多様な評価質問セットを提供することによって、これらの欠点に対処している。

4.3 LongMemEval (LME)

LongMemEvals データセットは既存の LLM とビジネスメモリーソリューション [7]にとって大きな挑戦であり、ダイアログの長さは平均約 115,000 トークンである。この長さは非常に大きいが、まだ現在のフロンティアモデルのコンテキストウィンドウの範囲内であるため、Zepの性能を評価するための意味のあるベースラインを確立することができる。

このデータセットには、シングル・セッション・ユーザー、シングル・セッ ション・アシスタント、シングル・セッション嗜好、マルチ・セッション、 知識更新、時間推論の6種類の問題が含まれている。これらのカテゴリはデータセットに一様に分布しているわけではない。詳細は[7]を参照されたい。

実験はすべて2024年12月から2025年1月の間に行った。AWSのus-west-2でホストされているZepのサービスに接続するために、マサチューセッツ州ボストンにある自宅の消費者向けラップトップを使用した。この分散アーキテクチャにより、Zepのパフォーマンスを評価する際に追加のネットワーク遅延が発生するが、この遅延はベースライン評価には存在しない。

回答評価には、GPT-4oを使用し、人間の評価者に非常に適切であることが示されている[7]で提供された質問固有のキューを提供しました。

4.3.1 LongMemEvalとMemGPT

Zepと現在の最先端のMemGPTシステム[3]との比較ベンチマークを確立するために、LongMemEvalデータセットを使用してMemGPTの評価を試みた。現在のMemGPTフレームワークは既存のメッセージ履歴の直接取り込みをサポートしていないため、対話メッセージをアーカイブ履歴に追加することで解決策を実装した。しかし、この方法ではQ&Aを成功させることはできませんでした。性能データを比較することは、LLMメモリシステムの幅広い開発にとって有益であるため、このベンチマークテストが他の研究チームによって評価されることを期待している。

4.3.2 LongMemEval の結果

Zepはベースラインと比較して精度と待ち時間の両方で有意な改善を示した。gpt-4o-miniを使用した場合、Zepはベースラインより15.2%精度が向上し、gpt-4oは18.5%向上した。

表2：LongMemEvals

質問タイプ別の分析によると、Zepを使用したgpt-4o-miniは6つのカテゴリーのうち4つで改善を示し、複雑な質問タイプであるシングルセッション選好、マルチセッション、時間推論で最大の改善を示しました。Zepはさらに、gpt-4oを使用した場合、知識更新のカテゴリーで改善されたパフォーマンスを示し、より強力なモデルと使用した場合、より効果的であることを強調しました。しかし、より強力でないモデルによるZepの時間データの理解を改善するために、さらなる開発が必要かもしれない。

表3：LongMemEvals問題タイプの分解

これらの結果は、Zepがモデルスケールで性能を向上させる能力を実証しており、より強力なモデルで使用した場合、複雑でデリケートな問題タイプで最も顕著な改善が観察されました。待ち時間の改善は特に顕著で、Zepは高い精度を維持しながら応答時間を約901 TP3T短縮しました。

シングルセッションのヘルパー問題での性能低下（gpt-4oでは17.7%、gpt-4o-miniでは9.06%）は、Zepのそれ以外の一貫した改善に対する顕著な例外であり、次のことを示唆している。さらなる研究とエンジニアリングの必要性を示唆している。

5.結論

我々はZepを発表した。Zepは、意味記憶とエピソード記憶をエンティティやコミュニティの要約と組み合わせたLLM記憶へのグラフベースのアプローチである。我々の評価では、Zepは既存のメモリベンチマークにおいて最先端の性能を達成し、同時にトークンのコストを削減し、大幅に低いレイテンシで動作することが示された。

GraphitiとZepが達成した結果は印象的であるが、グラフベースのメモリシステムにおける予備的な進歩に過ぎないと思われる。Zepパラダイムへの他のGraphRAG手法の統合や、我々の研究の新たな拡張を含め、これら2つのフレームワークの上に複数の研究手段を構築することが可能である。

GraphRAGパラダイムでは、LLMエンティティ抽出とエッジ抽出のモデルを微調整することで、コストと待ち時間を削減しながら精度を向上させることができることが実証されている[19][25]。同様に、Graphitiキューのモデルを微調整することで、特に複雑なダイアログの知識抽出が強化される可能性がある。さらに、LLMによって生成された知識グラフに関する現在の研究は、主に正式なオントロジー[9][4][17][19][26]がない状態で行われているが、ドメイン固有のオントロジーには大きな可能性がある。グラフオントロジーは、LLM以前の知識マッピング作業の基本であり、Graphitiフレームワークでのさらなる探求に値する。

適切なメモリ・ベンチマーク・テストを探すと、その選択肢は限られており、既存のベンチマーク・テストはロバスト性と洗練性に欠けることが多く、単純なピンを探す事実検索問題がデフォルトになっていることが多い[3]。この分野では、メモリアプローチを効果的に評価し差別化するために、特に顧客経験タスクのようなビジネスアプリケーションを反映した、追加のメモリベンチマークテストが必要である。特に、既存のベンチマークテストは、構造化されたビジネスデータを用いて対話履歴を処理し合成するZepの能力を評価するには不十分である。ZepはLLMメモリに焦点を当てているが、従来のRAG能力は[17]、[27]、[28]の確立されたベンチマークテストに対して評価されるべきである。

コストとレイテンシを含む生産システムのスケーラビリティは、LLMメモリとRAGシステムに関する現在の文献では適切に扱われていない。我々は、LightRAGの著者の例に倣い、このギャップを解決するために、検索メカニズムのレイテンシベンチマークを含め、これらのメトリクスに優先順位をつけている。

6.付録

6.1 グラフ作成のヒント

6.1.1 エンティティ抽出

{現在のメッセージ｝
</current_message
上記のダイアログに基づいて、「現在のメッセージ」から明示的または暗黙的に言及されたエンティティ・ノードを抽出します：
ガイドライン
1.常に最初のノードとして話者/アクターを抽出する。発言者は、コロンより前の各行 の部分です。
2. "現在のメッセージ "で言及されたその他の重要なエンティティ、概念、またはアクターを抽出する。
3.関係やアクションのノードを作成しない。
4.日付、時間、年などの時間的情報のノードを作成しない（これらは後でエッジに追加される）。
5. ノードに名前を付けるときはできるだけ明確にし、フルネームを使用する。
6. 言及されたエンティティだけを抽出しない。

6.1.2 エンティティ解決

<前のメッセージ
{前のメッセージ｝
</previousメッセージ
<現在のメッセージ
{現在のメッセージ｝
</現在のメッセージ
<既存のノード
{既存のノード｝
</既存ノード
上記の既存のノード、メッセージ、および前のメッセージが与えられる。ダイアログから抽出された新しいノードが、既存のノードと重複するエンティティであるかどうかを判断する。
<新しいノード
{新しいノード｝
</new node
タスク
1. 新しいノードが既存のノードのいずれかと同じエンティティを表す場合、レスポンスに "is_duplicate: true" を返す。そうでない場合は、「is_duplicate: false」を返す。
2. is_duplicateがtrueの場合、既存のノードのuuidをレスポンスで返す。 3. is_duplicateがtrueの場合、既存のノードのuuidをレスポンスで返す。
3. is_duplicate が真の場合、ノードの最も完全なフルネームを返す。
ガイドライン
1. エンティティが重複しているかどうかを判断するには、ノードの名前と要約を使用します。

6.1.3 事実の抽出

<前のメッセージ
{前のメッセージ｝
</previousメッセージ
<現在のメッセージ
{現在のメッセージ｝
</現在のメッセージ
<エンティティ
{エンティティ｝
</エンティティ
上記のメッセージとエンティティが与えられたら、現在のメッセージからリストされたエンティティに関連するすべての要素を抽出します。
指示
1. 指定されたエンティティ間のファクトのみを抽出する。
2. 各ファクトは、2つの異なるノード間の明確な関係を表す必要があります。
3. relation_type は、ファクトを簡潔かつすべて大文字で記述する必要があります（LOVES、IS_FRIENDS_WITH、WORKS_FOR など）、
WORKS_FOR など)。
4. 関連するすべての情報を含む、より詳細なファクトを提供する。
5. 関係の時間的側面を考慮する（関連する場合）。

6.1.4 事実分析

次の文脈が与えられたとき、「新しいエッジ」が「既存のエッジ」リスト内のエッジによって表現されたものと同じ情報を表しているかどうかを判断する。
<既存のエッジ
{既存のエッジ｝
</existing_edges
<new_edge
{新しいエッジ｝
</new_edge
タスク
new_edge'が'existing_edge'のいずれかのエッジと同じ事実情報を表す場合、レスポンスに'is_duplicate: true'を返す。 そうでなければ「is_duplicate: false」を返す。
is_duplicate が true の場合、既存のエッジの uuid もレスポンスに返す。
ガイドライン
重複と判断するために、事実情報が全く同じである必要はない。

6.1.5 時間抽出

<前のメッセージ
{前のメッセージ｝
</previousメッセージ
<現在のメッセージ
{現在のメッセージ｝
</現在のメッセージ
<参照タイムスタンプ
{参照タイムスタンプ｝
</参照タイムスタンプ
<ファクト
{ファクト｝
</fact
重要 ： 提供されたファクトに時間情報が含まれている場合にのみ時間情報を抽出し、そうでない場合は言及された時間を無視します。
相対時間のみが言及されている場合 (例えば、"10 年前" や "2 分前" など)、提供された参照タイムスタンプに基づいて正確な日付を判断するよう最善を尽くしてください。
リレーションシップがスパニングされていない場合でも、日付を特定できる場合は、`valid_at`のみを設定する。
定義
- valid_at: このファクトによって記述されるリレーションシップが現実になった、または確立された日時。
- invalid_at：このファクトによって記述されるリレーションシップが実在しなくなった、または終了した日時。
タスク
ダイアログを分析し、ファクトに日付情報が含まれているかどうかを判断します。リレーションシップの作成または変更に明示的に関連する場合にのみ、日付を設定します。
指示：
1. ISO 8601 形式 (YYYY-MM-DDTHH:MM:SS.SSSSSSZ) を使用して日付時刻を表す。
2. 参照タイムスタンプを現在時刻として `valid_at` と `invalid_at` を計算する。
3. ファクトが現在形を使用している場合、参照タイムスタンプを `valid_at` 日付として使用する。
4. 関係を確立または変更する時間情報が見つからない場合は、フィールドを NULL に設定する。
5. 日付は関連するイベントから推測してはならない。
6. リレーションシップに直接関係する相対的な時刻が記載されている場合、実際の日付は 参照タイムスタンプに基づいて計算される。
7. 日付のみが言及され、時刻が指定されていない場合、デフォルトで 00:00:00（午前零時）が使用される。 8. 年のみが言及された場合、デフォルトで 00:00:00（午前零時）が使用される。
8. 年だけが記載されている場合、その年の1月1日の00:00:00が使われる。
9. 常にタイムゾーンのオフセットを含める（特定のタイムゾーンが指定されていない場合は、UTCにZを使用）。