ZEP: 知的身体記憶のための時間的知識グラフ・アーキテクチャ

抄録

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

1.はじめに

近年、Transformerベースの大規模言語モデル（LLM）が産業や研究に与える影響が注目を集めている[1]。LLMの主な応用例として、チャットベースのインテリジェンスの開発が挙げられる。しかし、これらのインテリジェンスの能力は、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.ナレッジ・マッピング

ここで、ℬはノード、↪Ll_212F はエッジ、φ:ℯ×ᵏ→ は形式化された関連関数を表します。は形式化された関連関数を表す。このグラフは、プロットサブグラフ、意味エンティティサブグラフ、コミュニティサブグラフの3つの階層サブグラフから構成される。

2.1 エピソード

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

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

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

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

2.2.1 エンティティ

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

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

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

アトラス作成のためのヒントは、付録に掲載されている。

2.2.2 事実

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

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

2.2.3 時間抽出とエッジの無効化

他のナレッジグラフエンジンとの主な差別化点は、時間的抽出とエッジ無効化処理によって動的な情報更新を管理することです。

システム利用 t_レフ プロットのコンテキストから、事実に関する時間情報を抽出する。これにより、絶対的なタイムスタンプ（例：「アラン・チューリングは1912年6月23日生まれ」）や相対的なタイムスタンプ（例：「2週間前に新しい仕事を始めた」）を含む、正確な抽出と時系列表現が可能になる。デュアルタイムモデリングアプローチに従い、システムは4つのタイムスタンプを追跡する：t^′ 作成する t^′ 有効期限T^′ ファクトがシステム内で作成または無効化されるタイミングを監視する。 t_妥当 歌で応える t_無効∈T 事実が確立された時間枠を追跡する。これらの時間データポイントは、他の事実情報とともにサイドに保存される。

新しいエッジの導入は、データベース内の既存のエッジを無効にする可能性がある。システムはLLMを用いて、新しいエッジを意味的に関連する既存のエッジと比較し、潜在的な矛盾を特定する。システムが時間的矛盾を識別する際には t_無効 の無効側に設定する。 t_妥当 影響を受けたエッジを無効にする。トランザクションのタイムラインによると T^′グラフティはエッジの無効性を判断する際、常に新しい情報を優先する。

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

2.3 コミュニティ

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

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

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

3.記憶検索

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

- 検索（φ）：このプロセスは、まず、関連情報を含む可能性のある選択後のノードとエッジを特定する。Zepは多くの異なる探索方法を採用しているが、全体的な探索関数はφとして表すことができる。S→ℰ_s^n-×𝒩_sⁿ.×𝒩_cⁿ.このように、φはクエリを、意味エッジ、エンティティノード、コミュニティノード（関連するテキスト情報を含む3つのグラフタイプ）のリストを含む3タプルに変換する。

- 並べ替え機能 (ρ)：第2段階は検索結果の並べ替えである。並べ替え機能またはモデルは検索結果のリストを受け取り、それらの結果の並べ替えバージョンを生成する：ρ:φ(α),...→。ℰ_sⁿ×𝒩_sⁿ×𝒩_cⁿ.

- コンストラクタ (χ): 最後のステップで、コンストラクタは関連するノードとエッジをテキスト・コンテキストに変換する。ℰ_sⁿ×𝒩_sⁿ×𝒩cⁿ→S.それぞれについて e_i∈ℰs、χはファクトを返し t_妥当, t_無効 フィールドを使用する。 n_i∈𝒩_sは名前と概要のフィールドを返す。 n_i∈𝒩_c要約フィールドを返す。

これらの定義が整えば、次のように設定できる。 f は、これら3つのコンポーネントの組み合わせとして表される：f(α) = χ(ρ(φ(α))) = β。

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

FACTS 和 ENTITIES 表示与当前对话相关的上下文信息。
以下是最相关的事实及其有效日期范围。如果该事实与某个事件相关，则表示该事件发生在这个时间范围内。
格式：FACT（日期范围：from - to）
<FACTS>
{facts}
</FACTS>
以下是最相关的实体
ENTITY_NAME：实体简介
<ENTITIES>
{entities}
</ENTITIES>

3.1 検索

Zepは3つの検索関数を実装している。_コス), Okapi BM25 全文検索 (φ)_bm25})と幅優先探索(φ_ビーフ).最初の2つの関数は、Neo4jのLucene [15] [16]の実装を利用している。それぞれの検索関数は、関連する文書を特定するという点で異なる機能を提供し、一緒に並べ替え前の候補結果の包括的なカバレッジを提供します。検索フィールドはオブジェクトの種類によって異なります。_sについては、ファクト・フィールドを検索する。_sについては、エンティティ名を検索する。_cLightRAG[17]では、コミュニティで扱われている関連キーワードやフレーズを含むコミュニティ名を検索する。私たちのコミュニティ検索方法は独自に開発されたものですが、LightRAG [17]の高レベルキー検索方法と類似しています。LightRAGの手法をGraphitiのようなグラフベースのシステムと組み合わせることは、今後の研究の有望な方向性を提供する。

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

全文検索は単語の類似性を、コサイン類似性は意味的類似性を、幅優先検索は文脈的類似性を明らかにする。このように多面的なアプローチで候補結果を特定することで、最適なコンテキストを発見する可能性が最大化される。

3.2 再注文者

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

4.実験

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

両実験とも、ZepのAPIを介して対話履歴をZep知識グラフに統合した。そして、セクション3で説明した技術を使用して、最も関連性の高い20のエッジ（事実）とエンティティノード（エンティティ要約）を取得する。システムはこのデータをZepメモリ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]は現在、93.41 TP3Tの精度で性能指標をリードしており、再帰的要約によって達成された35.31 TP3Tのベースラインよりも大幅に改善されている。

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

LLMジャッジはインテリゲンチャの応答を提供された正解と比較する。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.21 TP3Tの精度向上を達成し、gpt-4oは18.51 TP3Tの精度向上を達成した。また、キューサイズが小さくなったことで、ベースライン実装と比較してレイテンシコストが大幅に削減されました。

表2：LongMemEvals

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

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

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

シングルセッションヘルパー問題での性能低下（gpt-4oでは17.7%、gpt-4o-miniでは9.06%）は、Zepの一貫した改善とは対照的な顕著な例外であり、さらなる研究の必要性を示唆しています。これは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 エンティティ抽出

<之前的消息>
{previous_messages}
</之前的消息>
<当前消息>
{current_message}
</当前消息>
根据上述对话内容，从当前消息（CURRENT MESSAGE）中提取明确或隐含提到的实体节点：
指导原则：
1. 始终将说话者/行动者提取为第一个节点。说话者是每行对话中冒号前的部分。
2. 提取当前消息中提到的其他重要实体、概念或行动者。
3. 不要为关系或行为创建节点。
4. 不要为时间信息（如日期、时间或年份）创建节点（这些信息将在后续作为边添加）。
5. 节点名称尽量具体，使用全称。
6. 不要提取仅在前文中提到的实体。

6.1.2 エンティティ解決

<之前的消息>
{previous_messages}
</之前的消息>
<当前消息>
{current_message}
</当前消息>
<已有节点>
{existing_nodes}
</已有节点>
根据上述已有节点（EXISTING NODES）、消息（MESSAGE）以及之前的消息（PREVIOUS MESSAGES），判断从对话中提取出的新节点（NEW NODE）是否是已有节点中的重复实体。
<新节点>
{new_node}
</新节点>
任务：
1. 如果新节点与已有节点中任意一个代表的是同一个实体，请在回复中返回 `is_duplicate: true`。
否则，返回 `is_duplicate: false`。
2. 如果返回为 is_duplicate: true，还需在回复中返回重复节点的 uuid。
3. 如果返回为 is_duplicate: true，请返回该节点最完整的全名作为名称。
指导原则：
1. 请结合节点的名称和摘要来判断是否为重复实体。重复节点的名称可能不同。

6.1.3 事実の抽出

<PREVIOUS MESSAGES>
{previous_messages}
</PREVIOUS MESSAGES>
<CURRENT MESSAGE>
{current_message}
</CURRENT MESSAGE>
<ENTITIES>
{entities}
</ENTITIES>
根据以上的消息（MESSAGES）和实体（ENTITIES），从当前消息（CURRENT MESSAGE）中提取所有与列出的实体有关的事实信息。
指南：
1. 仅提取出现在所提供实体之间的事实。
2. 每条事实应代表两个**不同节点**之间的明确关系。
3. relation_type 应为简洁、全大写的关系描述（例如：LOVES、IS_FRIENDS_WITH、WORKS_FOR）。
4. 提供包含所有相关信息的更详细事实描述。
5. 如有必要，考虑关系中的时间要素。

6.1.4 事実分析

根据以下上下文，判断 New Edge 是否与 Existing Edges 列表中的任意一条边表示相同的信息。
<EXISTING EDGES>  
{existing_edges}  
</EXISTING EDGES>  
<NEW EDGE>  
{new_edge}  
</NEW EDGE>
任务：  
1. 如果 New Edge 表达的信息与 Existing Edges 中任意一条边的事实信息相同，请在回复中返回 `is_duplicate: true`；否则返回 `is_duplicate: false`。  
2. 如果 `is_duplicate` 为 true，还需在回复中返回该现有边的 uuid。
指导原则：  
1. 即使事实信息不完全一致，只要表达的是相同的信息，即可视为重复。

6.1.5 時間抽出

<先前消息>
{previous_messages}
</先前消息>
<当前消息>
{current_message}
</当前消息>
<参考时间戳>
{reference_timestamp}
</参考时间戳>
<事实>
{fact}
</事实>
重要提示：仅当时间信息是所提供事实的一部分时才提取时间，否则请忽略提到的时间。
请根据提供的参考时间戳尽可能确定确切日期（例如 “10 年前”“2 分钟前” 这样的相对时间也要换算为确切时间）。
如果关系并非是持续性的，但仍能确定日期，请仅设置 valid_at 字段。
定义：
- valid_at：描述该事实所代表关系首次成立或变为真实的日期时间。
- invalid_at：描述该事实所代表关系不再成立或终止的日期时间。
任务：
分析对话内容，判断是否有与该关系事实相关的日期信息。仅当日期明确涉及关系的建立或变化时才填写。
指南：
1. 使用 ISO 8601 格式（YYYY-MM-DDTHH:MM:SS.SSSSSSZ）表示日期时间。
2. 判断时使用参考时间戳作为当前时间。
3. 如果事实是以现在时表述的，则使用参考时间戳作为 valid_at 日期。
4. 如果没有用于建立或更改关系的时间信息，请将字段留空（null）。
5. 不要根据相关事件推测日期。只使用直接用于建立或更改关系的日期。
6. 如果提到的相对时间与关系直接相关，请根据参考时间戳计算出实际日期时间。
7. 如果只提到了日期而没有具体时间，默认时间为当日 00:00:00（午夜）。
8. 如果只提到了年份，默认时间为该年 1 月 1 日的 00:00:00。
9. 始终包含时区偏移（若未提及具体时区，请使用 Z 表示 UTC）。

参考までに：

https://arxiv.org/pdf/2501.13956

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

ゼップ：AIアプリケーション用の長期記憶レイヤーを構築し、ユーザー情報、ビジネスデータを抽出・更新する。