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 は記憶層に同じ形を与えます:

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

これを比喩ではなく設計にしているのは 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 候補しか融合しません。ベンチマークのコーパスでの実測では、候補リスト全体の融合は 100 件で切った同じ融合をはるかに上回り、 limit 5 はどの gate 値でも行を構造的に到達不能にしました。

このラインは 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 タスクのベンチマークで、弱いモデルと強いモデルの両方で同時に生の埋め込みを上回らなければなりません。

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

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

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

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

溢れ分の連鎖は実測された欠陥に答えます: 埋め込みの窓は最長の記憶より短いので、長いレコードの尾はベクトル検索から見えません。窓を超えるレコードは、保存時に決定論的に、それぞれが自分の埋め込みを持つノードの連鎖に分割されます。ノードへのヒットは親のプレビュー、ノードの位置、参照を返し、エージェントは望めば残りを取りに行きます。分割は報告され、決して沈黙しません。

想起プロセスの中では、両方とも手がかりです。連鎖の中のヒットはその兄弟を名指しし、登録済みエンティティへのヒットはその上に宣言された関係を名指しし、ループは索引から二度目の取得をせずにどちらも追います。そして第 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 <= effective

default_count は呼び出し側が何も言わない時のサーバーの既定、max_count は絶対の上限、forced_count は運用者がすべての呼び出しの base を固定できる設定で、設定しない限り null です。既定または強制値が最大を超える構成は起動時のエラーであって、黙った clamp ではありません。
すべての応答は requested_count、effective_count、returned_count、そして count_policy (source、clamped、reason) を述べ、呼び出し側は自分の要求がサーバーでどう扱われたかを見られます。
窓より少ない件数は正常な結果で、理由を伴います: 関連する証拠が無い、品質閾値未満、 policy によるフィルター、provenance 不足、token 予算の枯渇、システムの劣化。不足分は、重複や低品質の項目や、証拠が支えない内容で決して埋められません。
既定と最大は固定する前に測ります: 長期記憶ベンチマークで count を sweep し、回答と証拠の品質をペイロードのトークンとレイテンシに対して読み、どこに膝があるかで決めます。

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

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

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

出力 — 想起単位。

{ "items": [{
    "content": "…",            // head claim の原文抜粋。preview tier と同じ切り方
    "claims": [{ "ref": "mem:1693", "as_of": "…",
                 "roles": [{ "ref": "mem:1585", "role": "supersedes" },
                           { "ref": "ep:411",   "role": "supports" }] }],
    "timeline": [{ "at": "…", "ref": "ep:411" }],
    "evidence": [{ "ref": "mem:1693", "why": "cluster:chain" }],   // なぜここにあるか、常に
    "independence_reason": "cluster:episode" }],                  // なぜ別の item か
  "requested_count": null, "effective_count": 1, "returned_count": 1,
  "count_policy": { "source": "server_default", "clamped": false, "reason": "count_omitted" },
  "bounds": { "top_k": 20, "max_hops": 2, "max_evidence": 40, "truncated": false } }

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

不変条件。

保存された記憶は決して変更されない — これは read path で、唯一の書き込みは既存の recall カウンターです。
モデルを呼ばない。埋め込みは可、生成は不可。content は引用。
決定性 — 同じ DB 状態、同じクエリ、同じ境界、同じ出力。同点は、書き下された全順序で解く。
有界性 — 宣言された境界の先は走査しない。切ったことは bounds.truncated で報告する。
説明可能性 — すべての要素が、なぜ存在するかを言う。
既存の recall 契約には触れない。
件数と探索幅は分離 — candidate_limit、vector_top_k、fts_limit、 selected_evidence_limit のどれも count から導出してはならない。テスト: count だけを変えて候補 id の集合が不変。
水増ししない — 言い換え、1 レコードの断片、1 つの結論への複数の証拠は別の item ではない。キーで畳めない矛盾は 1 つの item の中に示す。

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

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 節) は、事前登録した主張で判定します: ペイロードのトークンと end-to-end の記憶トークンが不変のまま、evidence recall が上がる — ループはエージェントのトークンを使わないからです。計器は、到達範囲の計測を生んだ near/far 層と rotation を持つ長期記憶コーパスです。腕は hint robustness pack — 正しい手がかり、近似の手がかり、誤った手がかり、手がかり無し、矛盾する手がかり — で、期待する形は: 正しければ改善、近似なら改善か中立、誤りなら graceful に回復、無しなら今日と同一。その条件で evidence recall が動かないなら、ループは飾りであり出荷しません。

出口 (第 7 節) は count の sweep — 1、2、4、最大まで — で、回答品質と証拠品質を別々にペイロードのトークンとレイテンシに対して読み、加えて、検索の失敗、証拠選択の失敗、再構成の失敗、エージェントの推論の失敗を分離する 7 本の ablation で判定します: 2.5 の flat recall。2.6 の検索のみ。再構成なしの証拠選択。count = 1 の再構成。sweep。oracle の証拠を与えた回答モデル。再構成でなく生の証拠を与えた回答モデル。出口を完了と呼ぶ前に失敗しなければならない変異: 既定を 1 から 2 に。最大との min を外す。forced と requested の優先順位を入れ替える。候補の上限を count に再結合する。重複排除を無効にする。provenance を落とす。返却数を常に有効数として報告する。

トークンはプロジェクトの方向が定義するとおりに測ります — 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 節の事前登録した主張が frozen baseline で示されている。
最終再ソートが決定され (第 3 節)、値段の付いた far の票と recency prior が 1 つの機構で、ベンチマーク記録が本番 regime で取り直されている。
深さと件数が分離され (第 4 節)、結合の不変条件がテストの下にある。
再構成想起がツールとして存在し、第 7 節の件数契約、役割の語彙、8 つの不変条件、 7 つの変異を持ち、その既定の窓が 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 の主題です。想起プロセスは、それらの信号が存在するようになった時に手がかりとしてループに入れるように建てられています。