長期運用中のフラット RAG システムと向き合い、4 つの質問を投げかけてみてください。「なぜそう言ったのか？」—— モデルは顧客の契約更新日について自信満々に答えたが、元のソース条項へのトレースは存在しない。「その主張を再検証してほしい —— ソースが変わった」—— 契約は先週修正された。そこから導かれた事実はすべて疑わしい。しかし、それらを見つけることはできない。なぜなら、どの文書から来たのかシステムが認識していないからだ。「この 2 つの矛盾する事実の間で判断してほしい」—— 一方は Alex が Google で働いていると言い、もう一方は Stripe だと言う。どちらにも信頼度スコアやソースのタイムスタンプはない。書き込みの新しさと証拠の新しさは無関係だ。「この幻覚の原因を特定してほしい」—— モデルは会議が木曜日にあったと言った。しかし木曜日に会議はなかった。LLM が日付を作り出したのか、それともメモリ内の不正なデータが誤解を招いたのか、判断できない。
これら 4 つの失敗は、共通の原因を持っています。それぞれが欠落した列（カラム）なのです。ソース識別子、キャプチャタイムスタンプ、信頼度スコア、応答引用ログ。それぞれ書き込み時に数バイトのコストがかかるだけです。それらを持たないことのコストは計り知れません。すべての主張が監査不可能になり、すべての矛盾が解決不可能になり、すべての幻覚が追跡不可能になります。
19 のシステムを調査すると、パターンは一貫しています。最も強力な実装は、証拠を裁判所が扱うように扱います。つまり、すべての主張は途切れることのない保管の連鎖とともに提示されるか、まったく提示されないかのどちらかです。最も弱い実装は何も保持せず、本番環境で問題が発生するたびにその代償を払っています。本稿では、調査対象から明らかになった 6 つの来歴レベル、それらを分ける 3 つの実装成熟度レベル、そして最初から正しく構築するための正直なコストについて説明します。
6 つのレベル、1 つの原則
19 のシステムを読み比べると、6 つの異なる来歴レベルが浮かび上がります。これらは階層構造ではなく、直交しています。システムによっては、ソース来歴はあっても因果来歴がない場合もあります。バージョン管理はあっても信頼度スコアリングがない場合もあります。最も強力な実装は 6 つすべてをカバーしています。最も弱い実装はどれもカバーしていません。
「同一性」は「どの事実か、正確には？」に答えます。OpenContext は取り込み時にすべてのコンテキストに対して UUID を発行し、エージェントが応答で直接使用できる引用スキームとして公開します。識別子は、コンテンツにバインドされておりパスにはバインドされていないため、名前変更、移動、再編成後も存続します。mem9 はすべての行に安定したメモリ ID を保持し、さらに If-Match 並行性保護付きの明示的なバージョンカウンターを保持します。同一性来歴がなければ、問題が発生したときに何について話しているのかさえ特定できません。
「ソース」は「それはどこから来たのか？」に答えます。Hindsight はすべての観測にソースタイプと識別子を記録するため、システムはどの会話や文書が特定の事実を生成したかを答えられます。mem9 はすべての行にソース、エージェント ID、セッション ID を保持します。Supermemory はメモリとともに文書 ID を保存します。ソース来歴がなければ、ソースが変更されたときに更新をカスケードできません。なぜなら、どの事実がそのソースに依存しているかをシステムが知らないからです。
「因果」は「どのエージェントステップがこれを使用したか？」に答えます。Hindsight は、取得され使用されたすべての事実を、完全な取得コンテキスト（どのリトリーバーがそれを表面化させたか、どのランクを達成したか、エージェントが実際に消費したかどうか）とともに、観測層にキャプチャします。Moraine はすべてのトレースステップを独自の来歴レコードとして扱い、エージェントの実行全体をソースアドレス可能なイベントのシーケンスとして回復可能にします。因果来歴がなければ、「システムがこの事実を取得した」のか、「エージェントがその応答を生成するためにこの事実を使用した」のかを区別できません。
「キャプチャ信頼度」は「それを書き留めたとき、どの程度確信があったか？」に答えます。Graphify はナレッジグラフのすべてのエッジに 3 段階のキャプチャ信頼度をマークします。確定抽出の場合は CONFIRMED、高信頼度の LLM 推論の場合は LIKELY、不確かな主張の場合は AMBIGUOUS です。AMBIGUOUS なエッジは、暗黙のうちに事実として扱われるのではなく、人間によるレビューのための「知識ギャップ」として表面化します。Hindsight はすべての観測に信頼度スコアを保持し、その鮮度ライフサイクルを通じて時間とともに減衰します。新鮮な観測は信頼され、古い観測は重み付けが下げられるか、破棄されます。mem9 はまずシャドウモードでニアデュプリケート検出を実行し、エンジニアが実際のデータからしきい値を調整するまで、スコアを記録してもそれに基づいて行動しません。キャプチャ信頼度がなければ、不確かな事実と確実な事実が同じ重みで取得され、エージェントは確固たる主張と推測を区別できません。
「バージョン管理」は「以前、私たちは何を信じていたか？」に答えます。Supermemory はメモリを型付きエッジ（更新、拡張、派生）を持つバージョン管理された DAG として扱い、すべての信念にコミット履歴を与えます。mem9 は書き込みパスを分割します。人間による編集にはインプレース変更、新しいコンテンツが古いものを意味的に置き換える LLM 駆動の書き換えには追加およびアーカイブを使用します。Tolaria はバージョン履歴全体を Git に任せ、1 行の差分を第一級のユーザー向け成果物として扱います。バージョン管理された来歴がなければ、システムが火曜日に何を信じていたかを巻き戻すことはできません。なぜなら、古い信念はアーカイブされるのではなく削除されるからです。
「相互関係」は「どの他の事実がこの起源を共有しているか？」に答えます。llm-wiki は 4 信号関連性グラフにおいて、直接リンクよりもソースの重複を重視します。同じ生文書から来た 2 つのページは、直接的なウィキリンクがある 2 つのページよりも強く関連していると推定されます。なぜなら、LLM は相互リンクに信頼性が低い一方、ソースのフロントマターは機械的に維持されるからです。EdgeQuake はコーパス全体のエンティティとリレーションシップにソース ID を蓄積するため、異なるソースから同じエンティティが繰り返し言及されると、その来歴の重みが強化されます。second-brain はソースを語彙索引の複合キーの一部として保持し、単一の文書を複数のパイプラインから独立してインデックスできるようにします。相互関係来歴がなければ、「このシステム内で同じ会話から来たすべてのものを表示して」や「その文書から他に何を学んだか？」という質問に答えることはできません。
6 つのレベルは直交していますが、互いに強化し合います。ソース来歴は同一性なしでは役に立ちません（事実を追跡する前に名前を付ける必要があります）。バージョン管理は信頼度なしでは弱くなります（編集の履歴はわかっても、それぞれについてシステムがどの程度確信していたかはわかりません）。相互クエリは、ソースが最初に存在することに依存します。6 つすべてを保持するシステムは、メモリが静かに腐敗しないシステムです。
3 つの実装成熟度レベル
調査対象は、来歴がどこに存在し、読み取り時に何ができるかに基づいて 3 つの層に分けられます。
Tier 1 はプロビナンスなしの RAG で、ほとんどのチームが出発点とします。コンテンツと埋め込みを持つフラットなベクトルストア。ソース列、信頼度スコア、バージョン履歴はありません。事実が取得されると、テキストと類似度スコアが得られます。どこから来たのか、システムがどの程度確信していたのか、すでに置き換えられていないかどうかを追跡できません。ここから始めたシステムはすべて、時間の経過とともに Tier 2 へと移行しています。
Tier 2 は行に来歴を保持します。ソース ID、信頼度、バージョン — すべて事実とともに列として存在します。mem9 はここに位置し、すべての行にソース、エージェント ID、セッション ID、バージョンを保持します。Supermemory のバージョン管理された DAG は Tier 2 の構造です。Graphify の 3 段階エッジ信頼度は Tier 2 の規律です。来歴はクエリに利用可能ですが、取得結果を自動的に修飾するわけではありません。それを使用するクエリを記述する必要があります。
Tier 3 は、呼び出し元が明示的に要求しなくても、読み取り時の結果に来歴コンテキストを付与します。Hindsight がここでのリファレンスです。取得されたすべての事実には、ソースタイプ、信頼度スコア、鮮度状態、リトリーバーごとのランキングがすでに付属しています。結果を消費するエージェントは、来歴を別個のルックアップとしてではなく、事実の一部として認識します。mem9 のソースターン装飾は Tier 2 と Tier 3 の中間に位置し、読み取り時のコンテキストを Tier 2 のスキーマに付与します。
移行は一方通行です。Tier 3 から始めて来歴規律を削除することを決定したシステムはありません。列は、存在すればすぐにその価値を証明します。今日メモリシステムを設計しているのであれば、問題は「来歴は必要か？」ではなく、「どの層から始めたいか？そして、選択した層より上のすべての層は、後から到達するよりも今組み込む方がはるかに簡単であることを認識した上で？」です。
警告事例：計算されて破棄される
Understand-Anything は、信頼度の基盤は存在するがそれを記録する列がない場合に何が起こるかを示しています。このシステムは、決定論的エッジ（プロジェクトスキャナーがソースファイルから解決）と推論エッジ（セマンティック分析中に LLM が推測）を区別します。この情報は現実的で意味があります。構造的なインポートエッジは、コード以外の推論よりも高い信頼度に値します。しかし、両方とも重み 0.7 として、グラフ内で同一に保存されます。信頼度シグナルは書き込み時に計算され、永続化の前に破棄されます。
信頼度フィールドを追加することは、情報品質に大きな見返りをもたらす小さな変更です。システムは、どのエッジが確固たるもので、どのエッジが推測かをすでに認識しています。ただ、それが重要となる場所、つまりエージェントがそれらを区別する必要があるときに後で取得される行に、その区別を記録していないだけです。このパターンは、調査対象の複数のシステムにわたって現れます。情報は書き込み時に利用可能で、キャプチャするのは安価ですが、誰も列を追加しなかったために失われます。
正しく構築するための正直なコスト
来歴にはバイト単位のコストがかかります。ソース ID、信頼度スコア、バージョンカウンター — それぞれ行ごとに数フィールド追加します。スケールが大きくなればそれは重要ですが、本番環境で問題が発生し、システムが間違った答えを生成した理由を追跡できない場合のコストに比べれば、はるかに重要ではありません。
計算コストは予想よりも低くなります。信頼度スコアリングには通常、書き込み時に 1 回の LLM 呼び出し（または構造的事実に対する決定論的ヒューリスティック）が必要ですが、これはその後のすべての読み取りにわたって償却されます。ソース追跡には、すでに存在する識別子を記録する以上のコストはかかりません。バージョン管理には、完全なスナップショットではなく、書き込みごとに 1 つの追加列または 1 つの追加処理が必要です。Hindsight の観測層は、取得され使用された事実の数に比例してストレージを追加しますが、エージェントが実際に消費したものだけを記録し、見たものすべてを記録するわけではありません。
運用コストが本当の問題です。Tier 3 の装飾は、取得ごとにより多くのデータが流れることを意味し、コンテキストウィンドウの使用量と応答レイテンシをわずかに増加させます。これを実現しているシステムは、装飾を簡潔に保つことで対応しています。ソースタイプの列挙型、信頼度の浮動小数点数、鮮度状態など、完全な来歴ツリーをインライン化するのではなく、エージェントがメタデータに溺れることなく区別するのに十分な情報を提供します。
最も強力な実装に共通するもの
調査対象の模範的な実装は、同じ問題の同じ部分を解決しているものは 2 つとないため、改めて述べる価値があります。
OpenContext は、あらゆるファイルシステムの再編成後も存続する UUID を発行し、エージェントが直接使用できる引用スキームとして公開します。mem9 はすべての行にソース、エージェント ID、セッション ID を保持し、すべての更新にバージョンを保持し、検索結果に明示的な予算によって管理されるソースターンコンテキストを付与します。Supermemory はメモリを型付きエッジを持つバージョン管理された DAG として扱い、すべての信念にコミット履歴を与えます。Hindsight は、取得され使用されたすべての事実を、完全なソース来歴、進化履歴、リトリーバーごとのランキングとともに観測層にキャプチャします。Graphify はすべてのエッジに 3 段階のキャプチャ信頼度をマークし、不確かなエッジを事実として扱うのではなく、人間によるレビューのために表面化させます。
共通する観察結果は明白です。来歴はメタデータではなく、事実の一部なのです。そのように扱うシステムは、メモリが静かに腐敗せず、矛盾を裁定でき、幻覚を追跡でき、信念の履歴を事前に必要性を予期することなく過去の任意の時点に巻き戻せるシステムです。
そうでないシステムは、ユーザーが最終的に、信頼していたメモリがずっと孤立した島だったことを知るシステムです。
来歴は、書き込み時に購入できる最も安価な保険です。その教訓は、必要だと気づく前に購入することです。
この記事が役に立ったと思われましたら、他の方にも届くようシェアをお願いします。
次回の記事では、ベクトル信号とキーワード信号を、一方が他方を圧倒することなく組み合わせるパターンであるハイブリッド検索と RRF について説明します。これは、来歴が事実が確固たるものであると示しているにもかかわらず、関連性だけではそれが埋もれてしまう場合に最も重要になります。その記事は近日公開予定です。
