生のベクトルメモリを構造化されたバージョン管理AIメモリに置き換える
ベクトルデータベースは、似たようなチャンクを取得します。彼らは、昨日の事実が今日の事実と矛盾していることを知りません。MemoryLakeは、構造化されたユーザーステート、競合解決、監査トレイルを必要とするRAGおよびエージェントアプリ用に構築されたベクトルメモリの代替です。単なる最近傍マッチではありません。
問題: 生のベクトル検索は生産RAGには不十分
純粋なベクトルRAGパイプラインは、コサイン類似度によってランク付けされたチャンクを返します。それは、どのチャンクが権威あるものであるか、どれが古くなっているか、またはどれがユーザーによって先週明示的に撤回されたかを判断できません。事実、イベント、意見を一つの袋にぼかします。生産チームは、再ランク付け、メタデータフィルター、重複排除ロジックでこれを修正します — 最終的にはメモリシステムを再発明します。
MemoryLakeがベクトルメモリを置き換え、拡張する方法
型付けされたメモリ、フラットなチャンクではない — 背景、事実、イベント、会話、反省、スキルメモリはそれぞれ異なる方法で取得します。事実は重複排除され、競合チェックが行われます; イベントは時間順に保持され、会話は圧縮されます。
書き込み時の競合解決 — 新しいコンテンツが保存されたメモリと矛盾する場合、MemoryLakeは両方を静かに埋め込むのではなく、それをフラグ付けします。解決策を選択できます: 最新のソース、信頼度の重み、または手動。
ロールバック機能付きのバージョン管理メモリ — 先週のインジェストが取得を悪化させましたか? 悪いコミットをロールバックします。ベクトルストアではこれができません。
既存のベクトルDBとペアリング — ドキュメントチャンクをそのままにしておきます。ユーザーステート、エージェントステート、構造化された事実のためにMemoryLakeをその上に使用します。
ベクトルメモリの代替としての仕組み
- 接続 — インジェストパイプラインをMemoryLakeに向けます(またはベクトルDBと並行して)。
- 構造化 — MemoryLakeは各チャンクをメモリタイプに分類し、以前のコンテンツに対して重複排除を行い、出所を保存します。
- 再利用 — 推論時に取得します。ランク付けされた、競合のない、型を意識したメモリを取得し、プロンプトにドロップする準備が整います。
前と後: RAGメモリスタック
| Without MemoryLake | With MemoryLake | |
|---|---|---|
| Conflicting chunks in retrieval | Both returned, model confused | Conflict resolved at write time |
| Outdated facts after a refresh | Stale chunks still surface | Versioned memory rolls forward |
| User-specific state | Stored in a separate session DB | Unified with document memory |
| Audit "where did this fact come from?" | Vector ID only | Full provenance chain |
対象者
単一のベクトルデータベースを超えた生産RAGを運営しているチーム — そして、ベクトルができないことを補うためにカスタムの重複排除、再ランク付け、メタデータフィルタリングコードを書くことに疲れたチーム。
関連するユースケース
よくある質問
ベクトルデータベースを廃棄する必要がありますか?
ベクトルデータベースを廃棄する必要がありますか?
いいえ。MemoryLakeはそれを補完します。ドキュメントチャンクの取得にはベクトルDBを保持し、ユーザーステート、エージェントステート、構造化された事実にはMemoryLakeを使用します。
MemoryLakeはセマンティック検索を行いますか?
MemoryLakeはセマンティック検索を行いますか?
はい、構造化メモリの上に。埋め込みベースの取得と型付けされたメモリクエリの両方を1つのAPIから取得できます。
100M以上のアイテムをどのように処理しますか?
100M以上のアイテムをどのように処理しますか?
MemoryLakeは、ミリ秒の取得遅延とLoCoMoの長期リコールベンチマークで94.03%の精度を持つ100M以上のドキュメントワークロードでベンチマークされています。