Reliable Recall — 2.6 系¶

翻訳について: 正本は英語版です。この日本語版は参照用の翻訳で、内容が食い違う場合は英語版が優先されます。

Status: 設計であって、挙動ではない。本ページは 2.6 系が何を建て、なぜそうするかの正本です。想起プロセス、その入力契約、スコアリングの prior、出口、そしてそれぞれの測り方を扱います。ここにあるものは、何一つ出荷済みの保証ではありません。ある節が挙動になるのは、実装され、 behaviour golden で固定され、ライフサイクル標準を通して出荷された時だけです。本ページとリリース済みのツール記述が食い違う場合、正しいのはリリースで、食い違いは本ページの欠陥です。

各節は単独で読め、引用でき、単独で注入できるように書いています。2.6 が各ラインの中でどこに座るかはロードマップが言い、それが何であるかを本ページが言います。

0. なぜこのラインがあるのか¶

2.5 系は、呼び出し側が受け取るものを変えずにサーバーの内側を建て直しました: 1 つの接続 seam、1 つの分離ヘルパー、観測した応答の golden 記録、テストが噛むことの変異証明、そしてスケール階段の最初の 2 段。検索品質には意図的に手を付けませんでした — ランキングや到達範囲を変える変更はすべて留められました。本番 soak の最中のランキング変化は、リグレッションと見分けが付かないからです。

2.6 は何が返ってくるかを変えるラインです。それを、1 つの命題の上で行います。

Recall はルックアップではなくプロセスである。モデルが答えについて考えるように、サーバーも記憶について考えることを許されるべきだ — 反復的に、決定論的に、そしてエージェントのトークンを一切使わずに。

以下はすべて、この命題を 1 つずつ建てて測れる部品に分解したものです。

どのラインでも決して変わらない 5 つ (サーバーはモデルを呼ばない、ユーザーが所有する 1 つの SQLite ファイル、スキーマは前にしか動かない、劣化は報告される、挙動は変える前に固定される) は、ロードマップに一度だけ書いてあります。ここでは前提として、繰り返しません。

1. Deliberative Recall — 想起プロセス¶

答える前に推論する言語モデルは、二度尋ねられたからより良い答えを出すのではありません。内部のループ (仮説、検証、修正) を回して出すのであり、その中間段階は呼び出し側に届きません。Deliberative Recall は、記憶層に同じ形を与えます。

想起の意図
    ↓
動的検索窓                    (最初にどこを見るか)
    ↓
取得                          (ランク付きリストを 1〜2 本)
    ↓
評価                          (証拠は十分か?)
    ↓
動的検索窓の修正              (広げる、緩める、手がかりを追う) ──┐
    ↓                                                          │  有界
証拠の選択                    ←────────────────────────────────┘
    ↓
再構成                        (出口 — 第 7 節)

最初の箱には名前があります。動的検索窓 (Dynamic Retrieval Envelope) は、取得が狙うストアの部分で、ループがそれを動かします。広げ、緩め、手がかりを追います。ベクトル走査窓ではありません。走査窓はベクトルの arm が順位付けする範囲の固定の上限のままです。また、agent_id・ project_id・channel の隔離の境界を越えることはありません。出荷されている想起のプロセスでは、入力は呼び出し側の時期の手がかり 1 つです。手がかりの期間を確信度に応じて広げ、修正は最大 1 回です (想起のプロセス §2)。

これを比喩ではなく設計にしているのは 4 つの決定です。

ループはサーバーの中で回る。 recall を繰り返し呼び、そのたびにクエリを調整するエージェントも、ループを回しています。しかしその 1 周ごとにツールの往復、入力トークン、出力トークン、レイテンシがかかり、合計は周回数とともに増えます。それは agentic な記憶ループのコスト構造で、このラインが拒むのはまさにその構造です。Deliberative Recall は 1 回の呼び出しの中で、決定論的な policy の下で反復するので、ループが何周しようとエージェントが払うのは 1 リクエストと 1 レスポンスの分だけです。エージェントが受け取るペイロードと下流で使うトークンは、ループの深さによって変わりません。これはこのプロジェクトの工学的命題の最も具体的な形です: 他のシステムが検索の問題をモデル呼び出しの回数で解くところを、これは構造で解きます。

ほとんどの反復は索引に触れない。 高価なのは、ベクトル・字面・キーワードの各 arm からランク付きリストを取得する段です。100,000 行のコーパスでの実測では、連続配置の索引はベクトル走査に数十ミリ秒で答えます。100 万行では同じ走査が一桁遅く、それを 30 回回すループは誰も有効にしない機能です。だからループの取得は 1〜2 回です。near リストと、動的検索窓が求める時には走査窓の外の far リストを取ります。以後のすべての反復は、既に手元にある候補プールを再重み付け・再フィルタします。字面の arm は、コーパスの大きさではなく一致した行数でコストが伸び、大規模ではまだ測られていないので、反復ごとに問い直しません。これは第 8 節の counterfactual replay と同じ原理です: 保存した候補を再採点するだけの変更は、1 回の取得の値段で何度でも試せます。

手がかりの伝播 (cue propagation) がループの本体。 閾値を少し変えて同じクエリを同じコーパスに投げ直す反復はパラメータ掃引で、数周で尽きます。ループが反復に値するのは、各周が次の周で使える何かを学ぶ時だけです。強いヒットの timestamp が動的検索窓の期間を絞る。それが属する episode・source・project が文脈の手がかりになる。それが座っている溢れ分の連鎖と、その上に宣言された関係 (第 6 節) が、次に見るべき場所を名指しする。これはすべての段が決定論的で記録される spreading activation です。連想層と溢れ分の連鎖を、横に並んだ機能ではなく想起プロセスの一部にしているのもこれです — ループが追う燃料だからです。

ループは判断される前に有界化される。 思考に自然な天井はありませんが、記憶の検索には無ければなりません。ループは証拠の十分性で止まります。スコアの分離、gate の結果、候補数、呼び出し側が渡した手がかりの被覆、矛盾の密度です。ただし hard な上限が先に来ます。段数の最大、考慮する候補数の最大、費やすミリ秒の最大です。上限に当たったループは、このサーバーの他のすべての有界操作と同じく、trace にそう書きます。

ループの各周は、recall trace (第 8 節) に記録されます。渡された意図、各段の動的検索窓、段ごとの gate 値と候補 id、動的検索窓を修正した理由です。呼び出し側が誤りだと思った recall は、高価なものを何も再実行せずに再生し、原因を帰属できます。

このプロセスがツール契約の中で名前を持つのは、エージェントが触れる場所だけです。入力 (第 2 節) と出口 (第 7 節) です。その間のすべては policy で、サーバーと一緒に版管理され、 trace に述べられます。

2. Cued Recall — 入力契約¶

認知心理学は、自由再生 (free recall) と手がかり再生 (cued recall) を区別します。自由再生は裸の問いから取り出すもの、手がかり再生は取り出す側に対象の部分情報 (だいたいいつ、だいたいどこで、だいたい何をしていた時か) を与えるものです。既存の recall ツールは自由再生です。Cued Recall は、エージェントが半分思い出していることをサーバーに渡し、想起プロセスが正しい場所から始められるようにする契約です。

エージェントは手がかりを宣言するのであって、検索パラメータを宣言するのではありません。融合の重みや減衰率を設定するのではなく、その記憶について信じていることを言い、サーバーがそれを policy に変換します。手がかりは常に prior であり、決してフィルターではない:

手がかりは recall を改善しなければならず、recall の前提条件になってはならない。

誤った手がかりは最初の窓を偏らせますが、コーパスから答えを消しはしません。widening は最後には無条件の検索に到達するので、悪い手がかりの最悪ケースはループのコストであって、見えなくなった記憶ではありません。分離の境界は例外で、hard のままです。agent_id、project_id、channel は手がかりではなく、検索が起きる空間であり、どの widening もそれを越えません。

2.6 が受け付けるもの:

時間の手がかり。 絶対 (after / before) または相対 (weeks_ago、months_ago、 long_ago、…) で指定し、3 値の確信度 (sure、likely、vague) を伴います。確信度が列挙なのは意図的です。0 から 1 の数値は名前を変えた重みであり、あるエージェントと次のエージェントの間で較正されておらず、それを提供することは「エージェントはパラメータでなく信念を宣言する」規則と矛盾します。
他はまだ無い。 場所の手がかり (ワールド、アプリケーション、ワークスペース) には専用の列がありません: 場所に見える軸 — project と channel — は分離の境界であり、境界をヒントに緩めてはなりません。状況の手がかり (コーディング中、会議中、障害調査中) には、このラインにはデータがありません。どちらも、必要なデータを足すラインの候補です。

手がかりの不在は、恒等ケースです。手がかり無しの呼び出しは、今日とまったく同じ、 byte 単位で同一の挙動をします。Cued Recall は recall の progressive enhancement であって、置き換えではありません。

3. 1 つの prior 関数¶

既にある複数の設定と、このラインが足す 2 つは同じものです: 行がどこに座るか — 走査位置、年齢、呼び出し側の宣言からの距離 — の関数としての、その行の票への重み。到達範囲と新しさの計画がこの表の最初の 5 行とその背後の計測を並べており、このラインは 6 行目を足します。

prior `p(row)`	何がそれを出荷するか
走査窓の内側で 1、外で 0	窓だけ (今日の既定)
内側で 1、`[window, reach)` で 1、その先で 0	reach 設定
内側で 1、最初の N 件の far 行で 1、残りで 0	far リストの長さ
内側で 1、`[window, reach)` で w、その先で 0	値段の付いた far の票 (2.6)
年齢の滑らかな関数	recency-weighted search (2.6)
年齢と宣言された時間の手がかりの関数	Cued Recall (2.6)

これらを 1 つの機構として建てるのは整頓のためではなく、計測の比較可能性を保つためです。計画の計器は far の票の sweep の両端に既に identity control を持っており、時間の手がかりは同じ関数のもう 1 つのパラメータとして、同じコーパスの同じ層で測られます。

3 つの 2.6 の行すべてに先立つ決定が 1 つあります。本番では confidence scorer が on で、 on の時、recall の最後の段は融合後のリスト全体を、融合の順序が生き残らないスコアで再ソートします — scorer off では 1 割の行で異なる 2 つの融合モードが、on では全行で一致します。融合だけが見る prior は本番では不可視になります。したがってこのラインは、最終再ソートを除くか、confidence スコアを融合スコアの関数にするかのどちらかを、どの prior を測るよりも前に決めます。これまでのベンチマーク記録は scorer off で取られています。計画は 2 つの regime が一致すると仮定するのでなく、そう明記します。

4. 深さは件数ではない¶

現行の recall ツールでは 2 つの数が混同されています。limit は per-retriever の検索深度として文書化されています: 各 arm が融合に渡す top-K なので、5 件を求めると各 arm も 5 候補しか融合しません。limit 5 はどの gate 値でも行を構造的に到達不能にしました。

同じ件数のまま深く融合すると返る行が良くなるかは別の問いで、仮定せず測ります。事前登録した最初の sweep (LongMemEval の harness、件数 10) では改善が出なかったので (benchmarks/measurements/results-recall-depth-floor-sweep.md)、depth floor は 0 で出荷します。以前ここで引いていた「全順位対 100 行で切った同じ順位」の対比は、深さだけでなく返った行数も違う比較で、どちらの向きの証拠にもなりません。

このラインは 2 つを分離し、それぞれに名前を与えます:

想起深度 (Recall Depth) は、サーバーがどこまで掘るか — 融合が見る per-arm の候補深度、そして第 7 節の出口については、辿ってよい関係の hop 数と証拠の数。下限・既定・実測されたコストを持つサーバー側のノブで、呼び出し側が受け取りたいと言った数とは独立です。
応答数は、何行返ってくるか。recall では limit がこの意味になります。出口では第 7 節の再構成窓です。

検証は 1 つの不変条件です: 件数だけを変えても、融合が考慮した候補 id の集合は変わってはならない。テストがそれを assert し、2 つを再結合する変異 (candidate_limit = count) がそのテストを赤くしてからでなければ、この作業を完了と呼びません。

5. 適応的融合¶

3 つの検索 arm は固定重みの reciprocal rank で融合されます。ベンチマーク記録は、なぜそれが誤った定数かを示しています: 弱い埋め込みモデルでは字面の arm がスコアを 6 点押し上げ、タスク族を丸ごと救います。強いモデルではその押し上げはほぼ消え、別のタスクに移ります。融合はどちらの状況にいるかを判別できません。

このラインの旗艦は、定数ではなく埋め込みモデル・コーパス・クエリに追従して振る舞う融合です。候補の軸は、各 arm の信頼度の教師なし推定 (閾値較正の null 分布の機構が既にあり再利用できます)、ランク融合と類似度スケールの原理的な接続、そしてクエリ単位の arm 選択です。成功条件は後から調整できないよう先に述べます: 適応的融合は、記録を生んだ同じ 22 タスクのベンチマークで、弱いモデルと強いモデルの両方で同時に生の埋め込みを上回らなければなりません。

この節は意図して最も短くしています。その中身は計測プログラムであり、本ページはそのプログラムが示すべきものだけを固定します。

そのプログラムは最初の結果と設計を出しました。凍結段リプレイは損失の在り処を特定しました: 純 ranking のタスクでは損失は融合段そのもの — lexical の票が dense 行を関連行の上へ持ち上げる — であり、残りの損失は小さすぎる宇宙に適用された admission floor と gate です。識別可能性ノートは、アームごとの較正では融合を決められないことを示し、決められる量を名指しします。両者から従う設計 — 予約不変条件、gate の順位カットの撤去、計測済みの lexical 重み定数、default-off の条件付き証拠モード — は、上で固定した成功条件に照らしてそこで決定されます。

6. 手がかりとしての連想と溢れ分の連鎖¶

このラインの 2 つの機能は検索経路として設計されました。第 1 節の想起プロセスは、それらをそれ以上のものにします。

連想記憶は宣言されたグラフです: エイリアスを持つ登録語と、エージェントが主張しサーバーが保存・走査する主語–述語–目的語の関係。構成上決定論的です — これまで試したあいまいな拡張はすべて汚染ベンチマークでリグレッションしたので、ベクトルと字面の arm が確率的であるところで、連想は正確です。A/B で汚染のリグレッションが無いと示すまで gate の後ろで既定 off で出荷します。空のレジストリは byte 単位で同一の no-op です。

溢れ分の連鎖は実測された欠陥に答えます: 埋め込みの窓は最長の記憶より短いので、長いレコードの尾はベクトル検索から見えません。窓を超えるレコードは、埋め込みサーバーが報告する窓に対して決定論的に、それぞれが自分の埋め込みを持つノードの連鎖に分割されます。分割は報告され、決して沈黙しません。最初の段階ではノードを検索の索引に入れません: ノードは返されたレコードを最も関連する部分で引用するために使い、recall が返すレコードは変わりません。ノードを検索の候補にもするかは、それ自身の計測で決めます。スキーマ、分割の規則、不変条件は溢れ分の tree の設計にあります。

想起プロセスの中では、両方とも手がかりです。連鎖の中のヒットはその兄弟を名指しし、登録済みエンティティへのヒットはその上に宣言された関係を名指しし、ループは索引から二度目の取得をせずにどちらも追います。そして第 7 節の出口では、「同じ連鎖に属する」と「宣言された関係で結ばれている」が、候補を証拠に束ねる決定論的キーのうちの 2 つです。どちらもプロセスが動くために必須ではありません — 関係も連鎖も無ければ対応する段は恒等写像です — が、あればループには行き先があります。

7. 再構成想起 — 出口¶

自由再生と手がかり再生は候補行を返します。再構成想起は想起単位 (recall item) を返します: 候補から組み立てられた記憶の単位で、それぞれが、それを支える正本の行まで追跡できます。ここでの「再構成」は選択し、整列し、役割を割り当てることであって — 決して合成ではありません。サーバーは、保存していない文を書きません。

別のツール。 出口は recall のモードではなく新しいツールです。それにより recall の契約に触れず、1 つの応答に意味の違う 2 つのノブが並ぶことを避け、追加を additive にします — 以前存在しなかったツールは pre-release の梯子を発動しません。

入力。 想起プロセスが作った候補プール、そのままの分離軸、任意の時間の手がかり、必須の境界の集合 — 候補の深さ、関係の hop、証拠の数 — そして任意の count。

再構成窓 (Reconstruction Window)¶

count は返す想起単位の数の上限です。充足目標ではなく、検索深度でもありません。

base      = forced_count ?? requested_count ?? default_count
effective = min(base, max_count)
0 <= returned - reserved <= effective
0 <= reserved <= reservation        (Block の腕が off なら 0)

default_count は呼び出し側が何も言わない時のサーバーの既定、max_count は絶対の上限、forced_count は運用者がすべての呼び出しの base を固定できる設定で、設定しない限り null です。既定または強制値が最大を超える構成は起動時のエラーであって、黙った clamp ではありません。
すべての応答は effective_count と returned_count を述べます。サーバーが要求と違うことをした時 — 件数を上限で丸めた、または運用者が強制した — には requested_count と count_policy (source、clamped、reason) を加え、呼び出し側は自分の要求がサーバーでどう扱われたかを見られます。要求どおりに処理した時は繰り返しません: エージェントは 1 つの問いで何度も検索するので、毎回繰り返す監査情報は毎回の費用になります。 trace=true は、どの呼び出しでも監査情報をすべて返します。
窓より少ない件数は正常な結果で、理由を伴います: 関連する証拠が無い、品質閾値未満、 policy によるフィルター、provenance 不足、ペイロード予算の枯渇、システムの劣化。不足分は、重複や低品質の項目や、証拠が支えない内容で決して埋められません。
Block の腕が on の時、recall はその腕だけが届いたレコードのために決まった数の別枠を確保し (Block による到達 §5)、 reconstruct も同じ形を保ちます。そうした行だけでできた束は窓の中の位置を取りません。窓から外れた束のうちそうした行を含むものが、別枠の行数まで、窓の後ろに admission: "reservation" の印を付けた項目として続き、reserved_count が返った数を述べます。これらは窓の項目を押しのけず、窓が足りないかどうかはこれらを除いて判定し、returned_count が effective_count を超えるのは別枠の行数までです。既定の予算は別枠の項目 1 件ごとに見出し 1 つ分広がります。呼び出し側や運用者が指定した予算は広がらず、それが外した別枠の項目は reserved_omitted として報告されます。
未設定時の既定は 1 件です。実測による最適値ではなく、控えめな呼び出し契約です。最大値は、長期記憶ベンチマークで count とペイロード予算を sweep し、回答と証拠の品質をペイロードのトークン量・レイテンシと比較するまでは実験的な値です。どちらの既定値の変更を提案する場合も、この計測による根拠を必要とします。

幅が先、深さが後 — ペイロード予算¶

item の大きさは固定ではありません。ある item は保存された 1 行だけで、別の item は発話の連続や、支える claim を伴う episode です。したがって応答を形作る上限は 2 つあります。

count は幅 — 独立した記憶をいくつ返すか — を制限します。
ペイロード予算は深さ — item 全体で引用テキストをどれだけ運ぶか — を制限します。

2 つが測るものは別ですが、消費する資源は同じ、読み手のコンテキストです。予算が効くと、すべての item を残せば各 item を薄くするしかなく、各 item を丸ごと残せば数を減らすしかありません。どちらかが優先しなければならず、幅が優先します。深さの削減は取り戻せます: 省かれた claim はすべて ref を保ち、get_contents で展開できます。幅の削減は取り戻せません: 返されなかった記憶は、呼び出し側が展開する手がかりも、存在を知る手がかりも残しません。

budget_base      = forced_budget ?? requested_budget ?? default_budget(count)
effective_budget = min(budget_base, max_budget)

既定値は、設定された既定値か、窓の item の head の引用を合計した文字数のうち、大きい方です。head の引用はそれぞれの item の大きさで数えます (下記。 CPERSONA_RECONSTRUCT_QUOTE_CHARS が 0 の時はどの item も preview tier の大きさ)。件数を指定して予算を指定しなかった呼び出し側が、自分で決めていない既定値に幅を削られてはなりません: 既定 4,000・引用 500 字では、件数 10 の窓が 8 件しか返しませんでした。動くのは既定値だけです。呼び出し側や運用者が指定した予算はそのまま使い、件数 8 以下の窓はこれまでと同じ値になります。
予算は引用テキストの文字数 — content と下記の excerpts — で数えます。トークンは使いません: サーバーは読み手のトークナイザを知らず、preview tier と get_contents も既にペイロードを文字数で制限しているためです。ref、時刻、理由、role は数えず、それらは max_evidence が制限します。
preview tier の抜粋 1 つ分に満たない予算、または最大を超える既定・強制の予算は起動時のエラーであって、黙った clamp ではありません。したがって最初の item は必ず収まります。既定と最大の予算にはまだ値がありません: どちらも第 9 節の sweep で選び、下の例の数値は説明のためのものです。
item は head claim を content に運び、保持した他の claim の原文抜粋を excerpts に関連度の高い順で運びます。2.6 からは head claim を、そのレコードのうちクエリに一致した箇所から引用します: ブロックの支配範囲を順位順に、その item の引用の大きさに収まる限り詰め、本文順で示します — recall の抜粋と同じ詰め方です (設計)。ranges はそれがレコードのどこかを述べ、範囲の選び方 quote_basis は trace に入ります。2.6.4 (v1.2) で詰め方の 3 点を変えました。大きさは item の位置で決まります: 最初の CPERSONA_RECONSTRUCT_FULL_QUOTES (5) 件は CPERSONA_RECONSTRUCT_QUOTE_CHARS (800)、それより後は CPERSONA_RECONSTRUCT_TAIL_QUOTE_CHARS (400) です。非公開の実運用パックの開発用の問では、読み手が見られた根拠の引用 127 件のうち 102 件が最初の 4 件の item にあったためです。ブロックの順位は、レコードのすべてのブロックが保存済みの int8 ベクトルを持つ時はそのコサインで、そうでない時は符号ビットで付けます。接している範囲は 1 つの範囲として示し、間に本文がある範囲だけを区切ります。2 つのブロックにまたがる文が区切りで切れることはなくなりました。回答の読み手で LongMemEval を計測したところ、count 1 では単一の支配パッセージが 116 問に答えたのに対し 500 問中 154 問、count 5 では 223 問に対し 321 問に答えました。他の各抜粋は preview tier と同じ切り方です。抜粋は必ずその item 自身の claim から取ります: item が大きくなるのは記憶の構造が大きいからであり、関連度スコアが高いからではありません。スコアはモデルやコーパスをまたいで較正されておらず、束ねを超えて item を膨らませると、束ねのキーが独立と判定した記憶を混ぜることになります。
割り当ては 1 本の固定列です。 引用テキストを次の順に並べます: 選ばれた item の head を item 順に。次に各 item で最も関連度の高い残りの抜粋を item 順に。次に各 item の次の抜粋、以下同様。応答は、その列のうち予算に収まる最長の先頭部分を運びます。head が先頭部分の外に出た item は返さず、不足理由は budget_exhausted です。先頭部分の外に出た抜粋は省きますが、その claim、ref、role は item に残ります。
応答は予算が形を決めない列の先頭部分なので、予算だけを上げて item や抜粋が消えることはなく、予算だけを変えて候補プール、クラスタ、item の順序が変わることもありません。
予算を丸めた・引き上げた・強制した時は requested_budget と budget_policy (source、 clamped、reason) を、予算が item か抜粋を運べなかった時は effective_budget と used_budget を述べ、抜粋を削られた item は excerpts_omitted を述べます。呼び出し側は、削られたのが幅か深さかを見分けられます。予算が何も削らなかった応答は、予算について何も述べません。

この窓は、このサーバーが既に持つ系列の 4 番目です: 埋め込み窓 (何が索引に載るか。分割は報告される)、走査窓 (何が走査されるか。gate fallback は報告される)、動的検索窓 (ループがどこを見るか。widening は報告される)、そして再構成窓 (何がエージェントに届くか。短い返却は報告される)。それぞれが有界の開口で、それぞれが切る時にそう言います。

処理と出力¶

処理 — 4 段、すべて SQL と純関数。

候補 — 想起プロセスからのプール、無改変。深さは第 4 節のノブ。
束ね — 決定論的キーで候補をクラスタ化する: 同じメッセージ id、同じ episode の時間区間、隣接する timestamp、同じ source、同じ溢れ分の連鎖。これらのキーは、サーバーが「同じ記憶」と呼ぶものの上限です。意味的な同一性はここでは判定しません (下記)。
有界な関係の走査 — 候補に付いた関係だけを hop 上限まで辿る: episode の包含、 metadata の明示参照、内容中に引用された安定 id、連想層があるなら宣言された関係。関係が無ければこの段は恒等です。
構造化 — 時間と版で整列する。同じ主題の 2 つの記述が食い違う場合は両方を残し、矛盾に印を付ける。要約しない、本文を統合しない。

出力 — 想起単位。

{ "items": [{
    "content": "…",            // head claim のうち一致した箇所を原文のまま " … " で連結
    "quote_basis": "blocks",   // trace のみ: blocks / lexical (読み取り時に分割) / start (1 ブロック) / whole (引用に収まる)
    "ranges": [[0, 212], [1480, 1731]],  // content の各パッセージがレコードのどこか、本文順
    "head_ref": "…",           // content が引用している claim
    "excerpts": [{ "ref": "…", "content": "…" }],      // 保持した他の claim、関連度順、予算の内側。無ければ省略
    "excerpts_omitted": 1,     // 予算がテキストを運ばなかった保持 claim の数。0 なら省略
    "claims": [{ "ref": "mem:…", "as_of": "…",         // 保持した行ごとに 1 つ、新しい順
                 "why": "cluster:chain",               // なぜここにあるか、常に
                 "roles": [{ "ref": "mem:…", "role": "supersedes" },
                           { "ref": "ep:…",  "role": "supports" }] }],  // その行に無ければ省略
    "independence_reason": "cluster:episode" }],                  // なぜ別の item か。"singleton" の時は無い
  "effective_count": 1, "returned_count": 1,                      // 常に
  // 以下は述べることがある時、または trace=true の時だけ:
  "effective_budget": 4000, "used_budget": 3980,                  // 予算が item か抜粋を運べなかった
  "bounds": { "top_k": 20, "max_hops": 2, "max_evidence": 40, "reached": ["top_k"] } }  // 境界が作用した

content は引用です。エージェントが合成された文を望むなら、委託経路 (サーバーが用意する brief、エージェントが返す verdict、別のツールがそれを適用する) がまさにそのためにあり、任意です。
役割の語彙は今固定し、段階的に埋めます: supports、supersedes、corrects、 qualifies、contradicts、temporal_predecessor。このラインでサーバーが導出できるのは supersedes (メッセージ id と時間順) と supports (episode の包含) です。corrects と qualifies にはサーバーが持たない真実の源が要り — in-place の更新は履歴を残しません — 宣言された関係が入った時に現れます。読み手は知らない役割を無視します。
本文全体は決して inline しません。content は head の引用の大きさで制限され、すべての抜粋は preview tier と同じ切り方で、ref は、今日の preview tier と同じく get_contents で展開します。

不変条件¶

保存された記憶は決して変更されない — これは read path で、唯一の書き込みは既存の recall カウンターです。
モデルを呼ばない。埋め込みは可、生成は不可。content は引用。
決定性 — 同じ DB 状態、同じクエリ、同じ境界、同じ出力。同点は、書き下された全順序で解く。
有界性 — 宣言された境界の先は走査せず、有効なペイロード予算を超えて引用しない。境界が落とした行は bounds.omitted、claims_omitted、excerpts_omitted、または不足理由で、到達しただけの境界は bounds.reached で報告する。
説明可能性 — すべての要素が、なぜ存在するかを言う。2.6.4 からは、既定の理由は無いことで示します: independence_reason の無い item は singleton、why の無い claim は seed で、trace=true はどちらも書き出します。
既存の recall 契約には触れない。その後 recall の行は additive な項目を 1 つ得た。切り詰めたプレビューに添える抜粋で、ここでの引用と同じブロック順位付けと支配文脈の規則で作る (設計)。呼び出し側が既に読んでいたものは何も変わらない。
件数と探索幅は分離 — candidate_limit、vector_top_k、fts_limit、 selected_evidence_limit のどれも count から導出してはならない。テスト: count だけを変えて候補 id の集合が不変。
水増ししない — 言い換え、1 レコードの断片、1 つの結論への複数の証拠は別の item ではない。キーで畳めない矛盾は 1 つの item の中に示す。
幅が先、深さが後 — ペイロード予算は item より先に抜粋を省き、応答は予算が形を決めない列の最長の先頭部分である。テスト: 予算だけを上げて item も抜粋も消えない。予算だけを変えて候補 id の集合、クラスタ、item の順序が不変。

先送りするもの。 適応的な既定、クエリ単位の最大、エージェント別の count と予算の policy、読み手のトークンで数える予算、モデル支援の独立性判定、statement 単位の provenance、count フィールドの標準化された export。適応化は、固定 policy が再現可能な baseline と監査契約を持ってからです。

再構成 v1 の実装範囲¶

実験的な v1 の出口は v0 の 4 段階を維持します。関係の走査は宣言された関係を辿り (連想記憶)、宣言が無ければ恒等です。 v1.1 からペイロード予算を上記のとおり実装しています。既定値 4,000 字と最大値 20,000 字は、 §9 の掃引が選ぶまでの暫定値です。呼び出し側の予算が見出しの引用 1 つ分 (CPERSONA_RECONSTRUCT_QUOTE_CHARS。充填が off のときはプレビュー層の抜粋 1 つ分) に満たない場合はその分まで引き上げ、budget_policy で申告します。レコードが現行の overflow tree ノードを完全に持つ claim は、クエリに最も合うノードから引用します: ノードをクエリ埋め込みとのコサインと、共有する文字 3-gram の数でそれぞれ順位付けし (同じ値は同じ順位)、相互順位融合で合わせ、同点は前のノードを取ります。引用には node (番号、ノード数、保存本文内の文字範囲) が付きます。ノードは item とその順序が確定した後に読むので、どの item が返るかは変えません (overflow tree)。引用の前後をレコードの残りなしで読むために、 get_contents は保存本文内のノード範囲または文字範囲を指定した ref を受け付けます。正確に返せない範囲は unresolved で申告し、行全体へ広げることはしません。以下の具体的な条件を追加します。

時刻による束ねは project と channel の一致を必要とします。隣接時刻での束ねには source の役割と id の一致も必要です。連続する各間隔だけでなく、まとまり全体が設定された隣接時間内に収まる必要があります。
episode の時間包含が証拠になるのは、同じ project と channel の中だけです。メッセージ id による束ね・supersedes・競合の判定には、保存先 project の一致が必要です。別 project の同じ id は独立した記憶であり、文脈が不明な場合も同一性を認定しません。 in-place 更新の履歴を作ったり、意味的な矛盾を推論したりはしません。
head claim は item 内で最も関連度の高い行です。その記憶の新しい版 (同じ保存先 project の同じメッセージ id) が item 内にある場合は、その最新版が head になります。「最新」に意味があるのは版の連鎖の中だけで、1 つの発話の連続やエピソードに属する別々の行の間では、最後に書かれた行にすぎません。head_ref が head を示し、claims は新しい順のままです。
すべての item は同じ形です。行の ref、時刻、理由はその claim に 1 回だけ現れます: 別立ての timeline (時系列は claims を as_of で並べ替える) や evidence 配列はなく、 roles、excerpts、excerpts_omitted は空なら省略します。1 行だけの item では、並列の配列が払っていた付帯情報の文字数がおよそ半分になります。
max_evidence は保持する claims とその role の参照先を制限します。切り詰める時は head を残し、残りは関連度の高い行から保持します。落とした行数は item の claims_omitted に入り、この制限で落ちた claim を role が参照することはありません。
応答が申告すること。 2 つの事実を分けます。bounds.omitted は、手元にあった行を落とした境界の名前です: max_evidence (返した item について) か max_hops。 bounds.reached は、到達しただけの境界の名前です: 検索が許された数ちょうどの行を返した時の top_k。その先に行があったかは分からないので、切ったとは言いません。大きな記憶では候補が深さを埋めるのが普通で、両方の事実で true になる 1 つのフラグはそこで何も区別しませんでした。どちらも空なら省略します。
縮退した方法で選んだ引用は、そう申告します。quote_selection: lexical_only は、クエリの埋め込みが得られず、ノードを文字 3-gram の一致だけで順位付けしたことを示します。切り詰めた引用がノード由来でない item は node_unavailable を持ちます: no_nodes、またはノードはあるが不完全か別モデル製の場合の not_current。この引用は記録の先頭であって、クエリに合った箇所ではありません。続きは get_contents に span を渡して読みます。
項目が無いことは判定ではありません。 これらの項目が無い応答は、item が回答に十分であること、記憶全体を探索したこと、行の矛盾を検査したことのいずれも意味しません: conflicts が検出するのは、同じ message id で同じ時刻の行だけです。出口は自分が行ったことを報告します。証拠が十分かの判断は第 1 節の想起プロセス (サーバー内部) の役割で、これらの項目を通じて呼び出し側へ委ねるものではありません。
応答は既定で小さくします。回答の読み手で計測したところ、要求どおりに処理した検索が、方針・境界・候補数の言い直しに約 500 字を使っていました。行そのものの費用は recall の行と同じでした。この外枠は、述べることがある時だけ返します (上の件数と予算の規則、境界が行を落とした・到達した・ライブラリ上限で引き下げられた時の bounds、行を除外した時の reconstruction.excluded_without_provenance)。2.6.4 からは item の中にも同じ規則を当てます: singleton の時の independence_reason、seed の時の claim の why、 quote_basis、content_len が既に示している content_truncated は trace に回します。非公開の実運用パックの開発用の問では、これらが応答の約 9% でした。
ノード引用を切り詰めた item は expand を持ちます。get_contents にそのまま渡すと、そのノードの残りが返る引数です。ノードは引用の数倍、記録はノードの何倍もあるので、次に読む最小の単位をそのまま使える形で渡します: まずそのノード、次に前後のノード、記録全体は最後です。
trace=true は reconstruction (policy の版、候補数、クラスタ数、選択数、出典不足による除外数)、本文を含めない候補 ref とクラスタ構成、および node_order を追加します: ノードから引用した記録ごとの、上位数個のノード番号 (合う順)。これは順序であって確信度ではなく、回答計測で読み手が使うと示されるまで trace に留めます。呼び出し側は、count が出力を制限したのか、検索候補が足りなかったのかを確認できます。
指定した件数を返せた場合も gate_fallback を保持します。明示的な count 0 は item を返さず、count_zero を報告します。
検索が生成した advisory・update・suggestion は、空の結果でも返します。セッション単位の通知を消費した時は、その呼び出し元へ届けます。
bounds.top_k は要求した候補上限です。ライブラリ上限で制限された場合は bounds.effective_top_k に実効値を返します (空の結果でも)。件数不足は取得した候補の状態を示し、コーパス全体を探し尽くした保証にはなりません。
認証下での利用には、recall と同じエージェント単位の読み取り権限が必要です。

呼び出し時の count は契約上の既定が 1 件で、設定による強制値も指定できます。いずれも充足目標ではありません。有効な item が 2 件なら、5 件を要求・強制しても返すのは 2 件です。最大 10 件は実験的な上限です。どちらの値も、回答品質とペイロード量の関係で実測上の最適値と主張するものではありません。検証には実際の保存処理を使う会話フィクスチャと、保存済みセッションランキングの件数別リプレイを含みます。このリプレイは回答生成側の評価や本番の検索深度での評価を代替しません。benchmarks/measurements/ の再構成検証記録を参照してください。

8. Recall Quality Engineering¶

かつて、誤って返ってきた recall は、ログを読み、推測し、設定を変え、ベンチマーク全体を再実行して調べていました。このラインは recall の失敗を工学の対象にします: 観測でき、分類でき、再生でき、原因に対処する最小の変更で直せるもの。

パイプラインと、それが失敗する場所。

capture / representation
    ↓
candidate generation
    ↓
ranking / fusion / filtering
    ↓
evidence selection / reconstruction
    ↓
agent consumption / task outcome

各段には答えを失う固有の形があり、2.5 baseline で既に見つかった失敗はそのすべてに散らばっています: 応答上限と取り違えられた走査窓が古い記憶を構造的に不可視にした。 cosine を持たない行が持つ行を上回った。スコアリングの変更が古い較正を復元した。1 回の random draw が融合 gate を揺らした。日付の無い行が最新として扱われた。timestamp の修正が別のペナルティを発火させた。どれもチューニングの問題ではありませんでした。それぞれが機構間の相互作用であり、この節の要点は、次のものは推測ではなく段を見ることで見つかる、ということです。

recall trace。 recall は求めに応じて、再生に十分な trace を生成できます: 正規化後のクエリと policy の版、分離のスコープ、要求された件数と有効な件数と内部の候補数、arm ごとの候補とその融合前後のランクとスコア、候補ごとの寄与とすべての除外の理由、選ばれた証拠と棄却された証拠と各々の寄与、索引の世代、埋め込みモデル、構成のハッシュ、段ごとのレイテンシ、そして想起プロセスについては第 1 節が述べるループの各段。機械の外へ出る trace は生のクエリ・記憶・埋め込みを運びません — PPDC の下の診断カプセルの仕事が、何を運んでよいかを定めます。

失敗の分類。 調査されたすべての失敗は 1 つのコードを得ます:

コード	意味
`CAPTURE_MISS`	情報が保存されていなかった
`REPRESENTATION_MISS`	保存済みだが、検索可能な形ではなかった
`CANDIDATE_MISS`	答えがどの arm の候補にも入らなかった
`RANKING_MISS`	候補にはあったが、返却の切れ目より下に順位付けられた
`FILTER_DROP`	フィルター、閾値、予算で除かれた
`EVIDENCE_NOISE`	選ばれるべきでなかった証拠に埋もれた
`RECONSTRUCTION_LOSS`	束ねまたは構造化の際に失われた
`RECONSTRUCTION_UNSUPPORTED`	どの証拠も支えない内容が現れた
`STALE_CONFLICT`	古い、または矛盾した情報が勝った
`AGENT_MISUSE`	正しい記憶が返り、エージェントがそれを誤用した
`SYSTEM_DEGRADED`	障害、タイムアウト、構成不整合が品質を下げた
`UNATTRIBUTED`	まだ帰属できない

想起プロセスは独自のものを足します: INTENT_MISLEADING、WINDOW_TOO_NARROW、 WINDOW_TOO_WIDE、WIDENING_PREMATURE、WIDENING_INSUFFICIENT、PRIOR_DOMINANCE、 PRIOR_IGNORED、INTENT_NORMALIZATION_ERROR。ループの policy が決定論的なので、これらは 1 つだけ変えて trace を再生することで機械的に付与できます。UNATTRIBUTED は隠さず報告します — 失敗を帰属できる率そのものが、この節の指標です。

Counterfactual replay。 失敗した recall を取り、条件を 1 つ変える: 深さを上げる。閾値を外す。arm を 1 本だけ走らせる。融合の重みを変える。再構成でなく生の証拠を返す。予算を広げる。手がかりを無効にする。埋め込みを差し替える。2.5 のコードを走らせる。回答モデルに oracle の証拠を渡す。保存した候補プールで足りる限り、これらは埋め込みもモデルも無しにローカルで大量に走ります。ある段を再実行しなければならない時も、疑われる原因より後の段だけです。

改善ループ。 失敗が検出され (ベンチマークか本番の報告で)、trace が解析されコードが付与され、類似の失敗が機構ごとにクラスタ化され、仮説が replay で検証され、修正候補が隔離環境で試され、失敗 slice で確認され、次に frozen holdout と全ベンチマークで確認され、トークン・レイテンシ・メモリ・provenance 忠実度へのコストが検査され、人間が版付きの変更として昇格させる。隔離実験は自動化されます。昇格はされません。

ループが公開ベンチマークに過学習しないよう、3 つのデータ集合を分けて持ちます: 帰属と探索のための development set、修正候補を選ぶための validation set、最終判断まで開かない frozen holdout。加えて cross-benchmark の確認と、production-like なケースの privacy-preserving な replay。

auditor profile。 上の帰属は SuperAuditor 標準の profile です: 標準は finding の形、severity、配送を固定し、何を検出するかは何も言わず、 profile が trace、分類、原因の証拠、replay の結果を固定します。この層分けは意図的です。 core は小さく汎用のまま、profile が recall 固有のすべてを運び、第 2 の記憶システムはこのサーバーの内部を採用せずに profile を実装できます。profile は、標準自身がそうであったように、その第 2 の実装が存在してから書きます。

9. このラインの測り方¶

本ページのすべての主張は、起きるのを待っている計測であり、計測は 1 つの規則を共有します: 2.5 baseline を凍結し、2.6 をそれに対して測る — 同じコーパス、クエリ、埋め込み、回答モデル、ハードウェア、トークン予算。集計だけでなく、タスク別、クエリ種別、言語別、記憶規模別、失敗 slice 別に比較する。リグレッションとトレードオフを改善の横に公開する。

検索品質は、記録を作った 22 タスクのベンチマークで、truncation 層を off にした full ranking regime で測ります — ベンチマークハーネスが文書化しているとおりです。適応的融合 (第 5 節) と prior 関数 (第 3 節) はここで判定します。ベンチマークの k とこのサーバーの応答数は別の変数で、決して混同しません。

想起プロセス (第 1〜2 節) は、事前登録した主張で判定します: 問いが述べる手がかりを渡すと、recall が返す行の中で根拠が上がる — 手がかり無しの同じ呼び出しに対しても、手がかり無しで同じ数だけ多く求めた場合に対しても。後者を主張に含めるのは、時期の手がかりが件数を超えて別枠を取りうるからです (想起プロセスの設計)。同じ数の手がかり無しの行でも得られる伸びは、ループの手柄ではありません。ループはエージェントのトークンを使わず、足した行の数は結果と並べて報告します。計器は時期に依存する問の集合 — LMEB の TMD (日付つきの会話を発話 1 つずつ記録として保存) — で、手がかりは問の本文と日付だけから抽出します。腕は、手がかり無し、抽出した手がかり、手がかり無しで同じ数だけ多く、期間をずらした (誤った) 手がかり、一部だけ正しい手がかりです。矛盾する手がかりは腕にしません: 時期の手がかりは 1 回の呼び出しで 1 つの期間しか受けないためです。期待する形は: 正しければ両方の比較相手より改善、一部だけ正しければ改善は小さく、誤りなら損は小さく、無しなら今日と同一。この判定則での最初の計測は主張を満たしました (benchmarks/measurements/results-tmd-time-cue.md)。会話の広がりが中央値 10 日の LongMemEval では、前の方針は満たしませんでした (benchmarks/measurements/results-longmemeval-time-cue.md)。その条件で根拠が動かないなら、ループは飾りであり出荷しません。

出口 (第 7 節) は count の sweep — 1、2、4、最大まで — とペイロード予算の sweep を掛け合わせ、回答品質と証拠品質を別々にペイロードのトークンとレイテンシに対して読んで判定します。sweep は束ねが実際に起きるコーパス — 発話を行として、セッションの日付と話者の役割付きで保存したもの — で走らせ、claim を 2 つ以上持つ item の割合を報告します: すべての item が 1 行のコーパスでは、sweep が測るのは順位付きの行であって再構成ではありません。加えて、検索の失敗、証拠選択の失敗、再構成の失敗、エージェントの推論の失敗を分離する 7 本の ablation で判定します: 2.5 の flat recall。2.6 の検索のみ。再構成なしの証拠選択。count = 1 の再構成。sweep。oracle の証拠を与えた回答モデル。再構成でなく生の証拠を与えた回答モデル。出口を完了と呼ぶ前に失敗しなければならない変異: 既定を 1 から 2 に。最大との min を外す。forced と requested の優先順位を入れ替える。候補の上限を count に再結合する。重複排除を無効にする。provenance を落とす。返却数を常に有効数として報告する。すべての head を置く前に抜粋を割り当てる。 item の外から抜粋を取る。割り当ての列を予算によって並べ替える。

トークンはプロジェクトの方向が定義するとおりに測ります — recall payload tokens、downstream input tokens、end-to-end memory tokens、amortised write tokens、tokens per correct answer — そして cached と uncached、入力と出力、記憶に帰属する分とエージェントの総量を分けて報告します。件数を減らすことはトークン効率の主張ではありません。

規模は 1K、10K、100K、1M 行で、品質・トークン・レイテンシ・ピークメモリを一緒に読んで測ります。指標は到達した最大の数ではなく、劣化の傾きです。

このどれのためにも新しい計器は作りません。ベンチマークハーネス、埋め込みキャッシュ、走査窓の計器は既にあり、上のすべての計測はその上で走ります。

10. 「完了」の意味¶

このラインは、以下がすべて成り立った時に閉じます。重要度の順に:

想起プロセスと Cued Recall が gate の後ろで、既定 off、既定では byte 単位で同一で出荷され、第 9 節の事前登録した主張がその判定則のもとで示されている。
最終再ソートが決定され (第 3 節)、値段の付いた far の票と recency prior が 1 つの機構で、ベンチマーク記録が本番 regime で取り直されている。
深さと件数が分離され (第 4 節)、結合の不変条件がテストの下にある。
再構成想起がツールとして存在し、第 7 節の件数契約、役割の語彙、9 つの不変条件、第 9 節の変異を持ち、その既定の件数とペイロード予算が sweep で選ばれている。
適応的融合が同じベンチマークで両方のモデルで生の埋め込みを上回っているか、そうでなかった理由と何がそれに代わるかを節が記録している。
ベンチマーク上のすべての失敗がコードと再生可能な trace を持ち、未帰属率が報告され下がっており、auditor profile の schema が公開されている。
精度–トークン–レイテンシ–メモリの frontier が 2.5 に対して動いており、slice 別のリグレッションが開示されている。
2.5 baseline の未解決の品質債務 — 絶対 gate として使われているクエリ相対のスコア、較正済みスケールに対する非正規化の埋め込み backend、テキスト比較の中の offset 混在の timestamp、limit の結合、包括的 baseline の欠如 — がそれぞれ、修正、理由付きで棄却、または理由付きで持ち越しになっている。

2 つのものは、意図して完了条件ではありません。Go の索引サービスはロードマップのランタイム軸に属します: それは版ではなくコーパスの大きさで発火し、このラインに結び付けるとどちらかがもう一方を人質に取れてしまいます。そして連想層の既定 on への切替は、ラインの閉じではなく、それ自身の A/B に属します。

11. このページが決めないこと¶

版番号と日付。 ロードマップが 2.6 をラインの中に置き、リリースノートが何が出荷されたかを言います。
実装順序。 依存は拘束するところで述べます (どの prior よりも前に再ソートの決定、出口よりも前に深さの分離)。その中の順序は作業のものです。
スコアリングの意味論そのもの — 融合の式、prior の曲線、同点の順序 — は、確定に応じてそれぞれの設計記録で計測により固定されます。
このラインが消費する標準。 SuperAuditor 標準は公開済みです。認知効率のオープンなベンチマーク (資源正規化、ベンダー中立、Pareto で順位付け) と privacy-preserving な診断カプセル (PPDC — raw data stays local, diagnosis travels) は草案で、議論を離れた時にそれぞれ自分のページとして公開されます。
この先のライン。 記憶の知性 — 確信度、訂正、矛盾、忘却 — は 2.7 の主題です。想起プロセスは、それらの信号が存在するようになった時に手がかりとしてループに入れるように建てられています。