証拠の配分 — 設計¶

翻訳について: 正本は英語版です。日本語版が古い場合は英語版を参照してください。

Status: 2.6.5 に向けた設計で、まだ何も実装されていません。最初の pre-release (2.6.5a1) は、レコードをまたいで並べた引用の列を予算で切ります (第 3 節と第 4 節)。2 つ目 (2.6.5a2) は第 5 節の被覆の段を足すので、2 つの差は被覆の段だけの効果になります。どちらも、回答の呼び出しより前に登録した判定則で測ります (第 7 節)。SCHEMA_VERSION は変わりません。以下はすべて、ストアがすでに持っている Block と Block ごとの int8 ベクトルを読みます。

0. この段階は何か¶

reconstruct は、1 本の固定された列を予算で切って item を返します (第 7 節)。列は、すべての先頭引用を item の順に並べ、そのあと各 item の抜粋を順に回したものです。v1.2 からは、先頭引用はそのレコードの一致した部分で、大きさは item の位置で決まります — 最初の 5 件は 800 字、それ以降は 400 字です。予算はこの列の先頭をどこまで返すかだけを選ぶので、予算を上げて何かが消えることはありません (不変条件 9)。

小さい予算をどう使うかを決めているのはこの列で、列は予算を窓の中の位置に使い、証拠には使っていません。この段階は、引用する部分を、窓のすべてのレコードをまたいで答えを含んでいそうな順に並べ、その順序を切ります。

1. 先に測ったこと¶

OmniMemEval の LongMemEval-S (500 問、v1.2、同じ検索) での 4 つの計器が、この変更がすべきことを決めました。

測ったこと	結果
末尾から item を減らす (件数曲線)	4 件で 994.6 Context Tokens・77.00%。全件では 1,786.7・81.60%。複数セッションの問いが最も落ちる
すべての引用を短くする (引用長の曲線)	同じ費用では、測った 2 点ともに item を減らす方に負ける。4 件より 7.40 ポイント、6 件より 4.20 ポイント低い
文脈が何を引用しているか (証拠の指標)	全件では正解セッションの 96.2% を引用するが、引用した本文のうち正解セッション由来は 21.9% だけ。500 問中 426 問で最初の item が正解セッションを持つ
短い引用はどこで証拠を失うか	引用されたレコードの中にありながら引用の外に残る証拠の発話は、320/160 字で 7.5% から 23.3% に増える。長すぎる範囲を切ったために失われたものは 0
証拠はレコードの中で何位か	引用された正解レコードの証拠の発話 859 のうち、レコードの中で最上位の範囲が届くのは 62.9%。2 位 16.3%、3 位 6.3%、4〜5 位 6.4%、それ以下 8.1%。サーバーの順位付けで計算し直したもので、引用範囲 5,888 件をすべて再現した

この設計が拠って立つのは最後の 2 行です。答えている発話は、そのレコードの最上位の範囲でないことが多い。長い引用は 2 位・3 位の範囲まで埋めてそこに届き、短い引用は届きません。もう 1 つの一様な切り方である item の削減は、複数セッションの問いが必要とする 2 つ目のセッションを失います。どちらの切り方も証拠を見ていません。

2. 引用の候補¶

引用の候補は、窓の中のレコードの Block を、それを支配する範囲 (blocks.context_range: その Block が属する文と、それを修飾する隣) まで広げたものです。すべての item のすべてのレコードが Block を出します。現在の Block の集合を持たないレコードは、今と同じく読み出し時に分けた部分を出します。1 つのレコードの中で重なる範囲は、順位を付ける前に 1 つにまとめるので、同じ本文が 2 度候補になることはありません。

3. レコードをまたいだ 1 つの順序 (2.6.5a1)¶

今の rank_blocks は 1 つのレコードの Block を並べます。ここでは、すべてのレコードのすべての候補を、 3 つの順位の reciprocal-rank fusion で 1 つの順序に並べます。

窓を作った recall でのレコードの順位
レコードの中での候補の順位 (今の rank_blocks の順)
保存済みの int8 ベクトルと問いのベクトルの cosine による、全候補の中での順位

同点は、レコードの順位、次に本文の中の位置で決めるので、順序は全順序で決定論的です。スコアは返しません。 trace に各候補の 3 つの順位を記録します。

1 つのレコードの中だけで見ると、この順序が rank_blocks と違うのはベクトルに余分な重みを与える点だけです (レコードの順位はそのレコードのすべての候補で同じ)。使い道はレコードをまたぐことなので、今の列の中ではなく、第 4 節の引用の列として測ります。

4. 引用の列 (2.6.5a1)¶

引用の列は、第 3 節の順に並べた候補になり、予算には依りません。予算はこの列を今の列と同じように切ります。応答は、収まる最長の先頭部分です。不変条件 9 は形を保ちます — 予算は先頭部分を選ぶだけなので、予算を上げて引用が消えることはありません — が、その前半は変わります: 列は、もはやすべての先頭引用を抜粋より前に置きません。1 件目のレコードの引用が 10 件目のレコードの唯一の引用より前に来ることがあり、小さい予算では、より少ない item をより多く返すことがあります。第 1 節がその理由です: 同じ費用では、すべての item を薄く保つ方が、少ない item を丸ごと保つより多くを失いました。

応答の形は変わりません。item は今もレコードごとに 1 つで、recall の順に並びます。item の content は、その先頭レコードのうち切り取りに入った候補を本文の順に並べ、今の先頭引用と同じようにつないだものです (ranges が範囲を示します)。excerpts は今まで通り item の他の claim を引用します。予算の中に候補が 1 つも入らなかったレコードの item は返さず、そのことは今と同じく報告します。count の意味 (item 数の上限) は変わりません。trace は列と、各候補の順位 (2.6.5a2 からは押さえた部分も) を記録します。

5. 被覆 (2.6.5a2)¶

第 4 節の列を、やはり予算に依らない貪欲法で作り直します。

第 3 節の順序から始める。
最初の候補を取る。それが押さえる問いの部分 — 被覆台帳の部分、つまり宣言済みの実体と珍しい語で、 trace.coverage に記録されるもの — に印を付ける。
残りを並べ直す: まだ押さえていない部分を押さえる候補は上がり、押さえ済みの部分しか押さえない候補は下がる (決まった段数)。最初のものを取る。すべての候補が並ぶまで繰り返す。

複数セッションの問いの 2 つ目のセッションが上がってくるのはここです: その候補は、1 つ目のセッションの候補が押さえなかった部分を押さえます。

6. 変わらないこと¶

モデルは呼びません。content は保存された本文の引用です。結果は決定論的です。すべての候補はそのレコードの参照を持ちます。スキーマ、窓を作る recall、count の意味は変わりません。

7. 判定の仕方¶

主: Context Tokens が 1,000 以下になる予算で、4 件 (994.6 で 77.00%) との正答率の対の差の 95% bootstrap 区間の下限が 0 より上 — 同じ費用で今より良い。
副: 全件 (81.60%) に対して下限が −2.0 ポイント以上。件数曲線の規則です。
調整用と判定用を分けます。 設定は、非公開の実運用パックの調整用の問いと、固定した乱数で 1 度だけ選んだ LongMemEval-S の 100 問 (v1_5_dev_questions.json) で選び、主張は残りの 400 問で 1 度だけ測ります。
どの点でも証拠の指標を正答率の横に報告し、対照 (4 件、6 件、全件、引用長の曲線の 2 点) は記録済みの回答を使い回します。

8. 後回しにしたこと¶

被覆のために問いを節に分けること: 被覆は台帳の字句の部分から始め、細かい分け方は第 5 節の被覆の段を測ってから検討します。
問いに応じて変わる予算 (想起の設計の第 7 節は、固定方針が再現できる基準と監査の契約を持つまで適応を後回しにします。この設計がその固定方針です)。
Block より細かい証拠の単位と、埋め込みサーバーからの sparse や late-interaction のスコア。