技術的サマリー：Tenure – LLM メモリにおける構造化された信念状態

1. 問題：再方向付け税と検索抽象化の失敗

本論文は、現在の大規模言語モデル（LLM）のワークフローにおける根本的な非効率性、「再方向付け税」を特定している。すべての新しい LLM セッションは空のコンテキストウィンドウから始まり、ユーザーはすべての対話において、設定、技術的制約、プロジェクトの決定（例：「厳格モード付きの TypeScript」「MongoDB の生ドライバ」）を再確立することを強要される。このコンテキストがなければ、モデルは自信を持って誤った出力を生成し、オーバーヘッドを倍増させる修正プロンプトが必要となる。

業界の支配的な対応は「検索拡張メモリ（RAM）」であった：会話履歴を保存し、それを埋め込み、ベクトル検索（例：コサイン類似度）を通じて意味的に類似した断片を检索する。著者らは、これが「間違った抽象化」であると主張し、その理由は以下の 3 点である：

1. メモリは検索問題ではなく、状態問題である：設定や決定は、クエリが一致したときのみ検索される受動的な事実ではなく、能動的な構造的制約である。検索は、構造的保証が必要な場面で不要な条件付けを導入する。
2. 限定された語彙の文脈では類似性検索は失敗する：単一ユーザーまたは収束したチーム環境では、特定の技術ドメイン（例：インフラ）に関するすべての信念は意味的に近接している。ベクトル検索は、「Redis」に関するクエリと「MongoDB」や「Kubernetes」に関する信念を区別できない。なぜなら、それらは同じ意味領域（コサインスコア 0.65–0.83）を占有しているからである。これにより、リコールは高いが、精度は壊滅的となる。
3. コンテキストの劣化：明示的な状態管理を欠くシステムは、古びた、置き換えられた、または矛盾する事実を蓄積する。**置き換え（supersession）**のメカニズムがなければ、メモリシステムは最終的に古くなったコンテキストに基づいた自信ある応答を生成する。

2. 手法：Tenure アーキテクチャ

Tenure は、メモリを検索インデックスではなく、型付けされた信念状態として扱うローカルファーストのプロキシとして提案されている。これは、意味的類似性の代わりに構造化抽出とエイリアス重み付けされた用語マッチングを用いる、「精度第一」の検索パラダイムで動作する。

2.1 信念スキーマ

メモリの最小単位は、信念 - 欲求 - 意図（BDI）アーキテクチャに由来するが、永続状態にスコープを限定した 14 項のタプルである**信念（Belief）**である。主要なコンポーネントは以下の通り：

• タイプ：preference（設定）、decision（決定）、entity（実体）、open question（未解決の質問）、relation（関係）。
• 認識状態：active（有効）、inferred（推論済み）、exploratory（探索的）、superseded（置き換え済み）。重要なのは、superseded された信念は監査のために保持されるが、決して注入されないことで、コンテキストの劣化を防ぐことである。
• スコープ：確率的な重みではなく構造的フィルタとして機能する、ハードな隔離ラベル（例：user:universal、domain:code、project:<slug>）。
• 「なぜ重要か」フィールド：事実を行動に変換する命令的な指示（例：「すべてのコード例を TypeScript に向けて形状化する…」）。このフィールドは、モデルが完全なコンテキストを持つ書き込み時に生成され、モデルが再導出するための生データではなく、「結晶化された推論」を提供する。

2.2 精度第一の検索（ベクトルに対する BM25）

Tenure は、読み取りパスにおける埋め込み類似性を拒否する。代わりに、期待されるクエリ表面に一致するように作成されたエイリアスを用いた、信念ストア上のエイリアス重み付けされた BM25を利用する。

• インデックス検索の非対称性：システムは、長いクエリ対短く構造化されたドキュメントという逆検索問題を利用する。カスタムアナライザを使用して、スネークケースの正規名（例：redis_cache）をトークン化された形式にマッピングし、句マッチングのためにシャングル生成を適用する。
• エイリアス強化のフライホイール：システムは、ユーザーのクエリで観察された新しい表面形式（エイリアス）を継続的にインデックス化し、時間とともに精度を向上させる。
• カウンターシグナル特性：エイリアスには、拒否された技術の用語（例：fastify の信念のエイリアスリストにある express）が含まれており、ユーザーが拒否された代替案をクエリした際に、有効な設定を表面化させることを可能にする。

2.3 抽出と圧縮

• 書き込み時抽出：信念は、サイドカーブロックを介して非同期に抽出される。ティアゲートは、高構造出力信頼性を持つモデルのみが抽出を実行することを保証する。
• 圧縮：ノイズの蓄積を防ぐため、システムは重複する信念をマージし、設定を重複排除し、専門知識レベルを統合する。これは、非構造化メモリシステムで観察される「幻覚の蓄積」という失敗モードを防ぐ。
• スコープ隔離：ハードな検索後フィルタは、権限のないスコープ（例：project:client-a にいるときに project:client-b の信念）からの信念が、意味的類似性に関係なく決して検索されないことを保証する。

3. 主要な貢献

1. 形式化された信念スキーマ：認識状態、バージョン管理された置き換え、および命令的な「なぜ重要か」の指示を備えた型付けされたスキーマ。
2. 精度第一の検索設計：限定された語彙の文脈において、エイリアス重み付けされた BM25 が高密度ベクトル検索を上回ることを示す実証的デモンストレーション。
3. 圧縮アーキテクチャ：ノイズフロアの蓄積を防ぐためのエイリアス強化、カウンターシグナルインデックス、および信念マージのメカニズム。
4. 72 ケースの評価スイート：エイリアス解決、スコープの曖昧さ除去、置き換えチェーン、およびマルチターンでのトピックのドリフトを網羅する再利用可能なベンチマーク。

4. 結果

本論文は、Tenure の BM25 バックエンドを標準的なベクトルバックエンド（nomic-embed-text、768 次元）と比較する、72 の検索ケース（60 の静的、12 のセッションレベル）における制御された評価を提示する。

• 静的検索精度：

  • BM25：72/72 のケースが合格（平均精度：1.0）。
  • ベクトル検索：8/72 のケースが合格（平均精度：0.12）。
  • 観察：ベクトル検索は正しい信念を検索したが、意味的に隣接するドメインからの 8〜9 のノイズ信念（例：Redis をクエリしたときに MongoDB の信念を検索するなど）が伴っていた。

• マルチターンのトピックドリフト（セッション評価）：

  • トピックのドリフトを伴うマルチターンの蓄積下（例：Redis から Kubernetes/React への切り替え）、ベクトルバックエンドのドリフトスコア（検索されたノイズ信念の割合）は0.43–0.50まで上昇した。
  • BM25 はすべてのターンでドリフトスコアを0.0に維持し、蓄積されたセッションノイズから再エントリークエリを正常に隔離した。

• スコープと置き換え：

  • BM25 は、ESLint と Biome が有効な場合に TSLint をフィルタリングするなど、ハードなスコープ隔離と置き換えチェーンを正しく強制したが、ベクトル検索はこれらの構造的制約に基づいて区別することに失敗した。

5. 意義と主張

本論文は、セッション間 LLM メモリは検索問題ではなく、状態管理問題であると主張する。

• 構造的保証対確率的検索：Tenure は、「正しい信念が表面化し、かつユーザーが許可した境界内でのみそれらが存在する」という構造的保証を提供する。これは、生成時にモデルが関連性を区別しなければならない検索ベースのシステムとは対照的であり、システムが排除しようとする認知的オーバーヘッドを再導入する。
• 実行可能な推論：事実を書き込み時に命令的な指示（「なぜ重要か」）に変換することで、Tenure はモデルが再導出を必要とする生トランスクリプトではなく、「結晶化された推論」を受け取ることを保証する。
• 限定的なスコープ：著者らは明示的に、検索精度は応答品質にとって必要な前提条件であり、十分条件ではないと述べている。再方向付け税は観察的な主張である。本論文は、Tenure がコンテキスト注入を可能にするために必要な精度ギャップを解決することを確立しており、最終的な応答品質の測定は未解決の課題として残している。
• 適用性：単一ユーザーのコーパスで実証されたが、このアーキテクチャは、共有コードベースとランブックが「収束した語彙」を作成し、エイリアス重み付けされた精度のための同じ構造的条件を満たすエンジニアリングチームに拡張可能であると主張されている。

本論文は、Tenure が、信念状態を監査可能にするスキーマ、精度を確保する検索設計、および時間の経過とともにストアの整合性を維持する圧縮アーキテクチャを通じて、再方向付け税に対する一貫した回答を提供すると結論付けている。