コンテンツにスキップ

較正は字面アームの損失の原因か? (2026 年 9 月)

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

Status: measurement (実測)、探索的 (事前登録なし)。

ハイブリッドのパイプラインが生の埋め込みを下回るタスクのうち 7 つを、3 つの較正法 それぞれの下で 2 回ずつ再走し、admission の統計をタスクごとに記録しました。加えて 別のプローブで、閾値を取り得る 2 つの null 分布を比較しました。

ここの数値は適応的融合の導出へ供給されます。ここに あるものは、何一つ出荷済みの挙動ではありません。生データは第 6 節が名指しする ベンチマークハーネスの出力ディレクトリにあり、集計スクリプトはまだリポジトリに 入っていません。

結果を 4 行で。

  1. 較正 (dense アームの admission floor) は、損失の主因ではありません。 3 つの 方法 (separation、percentile、zscore) のいずれでも SciFact、ESGReports、TMD は 1 点のうちに収まる同じスコアになり、3 つとも生の埋め込みを 4〜8 点下回ったままです。 反復どうしは 0.21 NDCG@10 以内で一致するので、較正のランダムな引きは上位 10 件を 動かしていません。

    残る損失は admission より後ろに座っています。結合の中か、融合後の段の中か、 候補母集団の中かです。この実測は、その 3 つを分離していません。 2. 例外は QASPER です。 床をより低く置く zscore が +2.1 得ています (45.46 対 43.32)。床が gold を削り込んでいる場所では、admission が効きます。 3. 文書–文書の null は、クエリ–文書の admission にとって誤った参照です。 非対称 プロンプトのモデルでは、doc–doc null の平均はクエリ–doc null の平均の 1.3〜2.2 倍に なります。そこから取った床は (0.5 の係数をかけた後でも) いくつかのタスクで gold ペアの 12〜46% を退け、係数なしでは 68〜100% を退けることになります。2026 年 3 月に 導入された 0.5 の係数は、誤った母集団から取った null に対する粗い補正でした。 4. 小さなコーパスでは正例プロキシが退化し (19〜200 文書からなる EPBench と Gorilla の グループで Youden の J が 0.02〜0.19)、dense アームは EPBench のクエリの 5〜18%、 Gorilla のクエリの 8〜13% で何も受理しません。方法の選択が NDCG を動かすのは、この 飢餓が起きている場所だけです。

1. 条件

  • モデル: jina-embeddings-v5-text-nano (768 次元、非対称の Query: / Document: プロンプト)。埋め込みはハーネスのキャッシュから供給したので、エンコードは一切 行っていません。
  • レジーム: benchmarks/run_trackb.sh の Track B レジーム (自動較正付きの reciprocal rank fusion、較正済み融合ゲートと autocut は無効、limit はコーパスサイズと同じ) を、 admission の計装を追加したコミット ad7dfed 時点のツリーで実行しました。

    較正済みゲートを無効にしても、_apply_quality_gate は無効になりません。その ヒューリスティック分岐は依然として走り、導出ノートはそれを未解決の帰属問題として 記録しています。 - --fast --accel_backend numpy。セルフチェックは 1,084 件の比較で不一致 0 件でした。 torch バックエンドはコサインが等しい tie を順位 1,000 より後で別の順に並べるため、 使っていません。 - 腕 (実験条件): 3 方法 × 2 反復 × 7 タスクです。損失の大きい 5 つ (SciFact、 ESGReports、QASPER、TMD、EPBench) に、ReMe と Gorilla を加えました。1 腕あたり約 5 分かかります。

2. 主表 — 方法は負けているタスクを動かさない

Track A は 2026 年 7 月に測った生の埋め込みのスコア、B (Jul) は同じ月のハイブリッドの スコアです。各方法の列は、2 回の反復にわたる NDCG@10 の平均、較正された閾値、そして null 受理率 (閾値を超えるランダムペアの割合) を示します。

タスク A B (Jul) sep thr null 受理 pct thr null 受理 z thr null 受理
LMEB_SciFact 82.18 76.92 76.81 0.74 0.007 75.89 0.39 0.050 75.89 0.33 0.129
ESGReports 49.11 44.64 41.19 0.44 0.105 42.21 0.49 0.050 41.19 0.41 0.161
QASPER 48.50 44.44 43.32 0.51 0.039 43.70 0.49 0.050 45.46 0.42 0.163
TMD 30.07 25.89 23.85 0.57 0.119 23.91 0.62 0.050 23.84 0.56 0.144
EPBench 80.84 77.23 77.47 0.49 0.556 75.43 0.69 0.051 76.83 0.60 0.141
ReMe 65.24 61.70 61.46 0.29 0.471 61.64 0.62 0.050 61.50 0.47 0.147
Gorilla 35.89 34.24 33.62 0.74 0.148 33.14 0.81 0.050 33.72 0.72 0.169

読み:

  • SciFact、TMD、ESGReports: 方法間のばらつきは最大でも 1.02 点で、Track A との差 (−5.4、−6.2、−7.9) を説明しません。null 受理率は 20 倍動く (SciFact で 0.007 から 0.16) のに、NDCG は動きません。床は上位 10 件を削っていません。
  • QASPER: 床を 0.25 から 0.21 へ下げると 2.1 点得られます。理由は第 4 節のプローブが 示します。QASPER の gold ペアの 20% が、床より下に座っています。
  • EPBench と Gorilla: 差は dense アームの飢餓で説明されます (第 5 節)。

3. 反復 — 較正の引きは NDCG@10 を動かさない

separation の閾値は反復のあいだで動きます (例えば ESGReports の J は 0.64 と 0.62) が、NDCG@10 は 7 タスク × 3 方法を通して最大でも 0.21 しか動きません (QASPER の separation は 43.42 と 43.21)。

較正のノイズが「サブタスクあたり ±1〜3 点」だとするベンチマーク README の教義は、 このレジームでは成り立ちません。成り立ち得るのは、第 5 節の飢餓が起きる場所だけです。 その教義は、別途訂正します。

4. プローブ — null はクエリ–文書ペアから取らなければならない

コーパスグループごとに 3 つの分布を取りました。doc–doc null (200 文書のあいだの 全ペア)、クエリ–doc null (200 クエリ × 200 文書)、そして gold ペア (関連性判定から最大 500 件の正例) で、いずれもキャッシュした埋め込みから計算したコサインです。floor は separation の反復 1 の融合 admission floor で、閾値に 0.5 の係数をかけたものです。

タスク / グループ 文書数 dd 平均 dd p95 qd 平均 qd p95 gold 平均 gold p10 floor gold < floor gold < dd p95
SciFact 1748 0.210 0.388 0.165 0.332 0.709 0.559 0.372 0.3 % 0.5 %
ESGReports 2407 0.301 0.507 0.239 0.425 0.512 0.324 0.220 4.2 % 45.8 %
QASPER 20508 0.313 0.499 0.201 0.384 0.407 0.195 0.252 20.0 % 67.8 %
TMD 7463 0.462 0.621 0.313 0.434 0.366 0.275 0.285 12.4 % 100 %
EPBench sci_fi 200 0.685 0.810 0.334 0.520 0.421 0.225 0.306 33.2 % 100 %
EPBench world_news 200 0.500 0.713 0.232 0.381 0.399 0.240 0.297 27.6 % 99.6 %
Gorilla huggingface 907 0.447 0.684 0.202 0.423 0.462 0.243 0.306 16.2 % 94.2 %
Gorilla tensorflow 55 0.700 0.955 0.321 0.612 0.441 0.237 0.445 45.5 % 100 %
ReMe appworld 218 0.374 0.705 0.289 0.575 0.592 0.373 0.128 0.0 % 70.2 %

読み:

  • doc–doc null は一貫してクエリ–doc null より高くなります (平均の比で 1.27〜2.18)。 非対称プロンプトのモデルにとって「文書どうしがどれだけ近いか」と「クエリが文書に どれだけ近いか」は別の分布であり、後者のほうが低くなります。
  • 較正は null を doc–doc ペアから取り、それをクエリ–doc の admission に使う前に閾値を 半分にします。0.5 の係数は、たまたまその隔たりを埋めた定数であり、各タスクに 必要な補正はそれぞれ異なります (SciFact が失う gold は 0.3%、Gorilla tensorflow は 45%)。
  • したがって、固定の p による null 参照の admission は、dense の null をランダムな クエリ–文書ペアから取らなければなりません。doc–doc null に対しては、p = 0.05 は gold の 68〜100% を退けることになります (最右列)。
  • 起動時点では、クエリの分布が存在しません。候補 (保持した過去のクエリ、疑似クエリと してエンコードした文書断片、あるいは変換を伴う doc–doc null) は、導出ノートの第 6 節 で比較検討しています。
  • 未解決の食い違いが 1 つあります。QASPER の較正記録はコーパス行数を 65,300 と報告する 一方、プローブが数えた一意な文書 id は 20,508 でした。2 つの計器が同じ母集団を採点して いたかどうかは、まだ突き合わせていません。

5. 小さなコーパス — プロキシの退化と dense アームの飢餓

タスク 方法 dense 候補が 0 のクエリ J (separation、最小 / 中央値)
EPBench (9 グループ、19〜1,967 文書) separation 176 / 3,644 (4.8 %) 0.02 / 0.05
percentile 665 / 3,644 (18.2 %) —
zscore 362 / 3,644 (9.9 %) —
Gorilla (3 グループ、907 / 43 / 55 文書) separation 58 / 598 (9.7 %) 0.14 / 0.23
percentile 78 / 598 (13.0 %) —
zscore 47 / 598 (7.9 %) —
ReMe (6 グループ、96〜218 文書) separation 0 0.05 / 0.08
percentile 反復ごとに 2 —
残る 4 タスク すべて 0 0.64〜0.76
  • ベンチマークは全文書を同じ瞬間に保存するので、時間的近接という「同じセッション」 プロキシはここでは情報を持ちません。それでも較正は最近傍プロキシへフォールバック しませんでした (proxy_source はどのグループでも temporal です)。J が 0.02〜0.19 だということは、正例と null が分離していない場所に閾値が置かれたということです。
  • 飢餓は、小さなコーパスでの高い doc–doc null (EPBench sci_fi で 0.69、Gorilla tensorflow で 0.70) と、そこから置かれた高い床の産物です。第 4 節の「誤った null」の 問題の極端な場合であって、別個の欠陥ではありません。
  • 本番のコーパスは時間的な構造を持つので、そこではプロキシはそう簡単には退化しません。 それでも設計には最小サンプルサイズと J の下限が必要です (導出ノートが規則を 与えます)。

6. 再現

MODEL_PATH=jinaai/jina-embeddings-v5-text-nano EMB_CACHE_DIR=<cache> OUTPUT_DIR=<out> \
  bash benchmarks/run_trackb.sh --fast --accel_backend numpy --selfcheck_rate 0.02 \
    --trust_remote_code --default_task retrieval \
    --tasks LMEB_SciFact,ESGReports,QASPER,TMD,EPBench,ReMe,Gorilla \
    --record_admission --calibrate_method <separation|percentile|zscore>

各タスクの JSON は calibration ブロック (方法、プロキシの出所、閾値、null と正例の 受理率、Youden の J、融合の admission floor) と、コーパスグループごとの vector_admission ブロック (受理割合の平均とパーセンタイル、1 件も受理しなかった クエリと全件受理したクエリ、limit で打ち切られたクエリ) を持ちます。null プローブと 腕をまたぐ集計は、リポジトリの外にあるスクリプトから実行しました。それらを取り込むのは 今後の課題です。

7. 設計に何を渡すか

較正の側には、3 つが残ります。

  1. dense の null をクエリ–文書ペアから取ること (第 4 節)。それが入れば RRF_THRESHOLD_FACTOR は撤去の候補になります。
  2. 正例プロキシに対する妥当性のゲート (J の下限と最小サンプル数) と、それが退化した時に 取る、明示されたフォールバック (第 5 節)。
  3. 本番に近い形のコーパスで「床より下の gold」を測る計器。固定 p の admission が削って いないことを示せるようにするためです。

較正の外では、次のようになります。SciFact、TMD、ESGReports の損失は 3 つの方法の いずれでも同じで、Track A を下回ったままです。したがって、admission floor を変えること では、それらを説明できません。

では何が説明するのかは、この実測では決着していません。損失は融合の中にあるかもしれず、 その後に依然として走るヒューリスティックなゲートの中かもしれず、候補母集団の中かも しれません (第 4 節は、食い違いを 1 つ未解決のまま残しました)。

そこで次の実測は、融合の規則を選ぶ前に、凍結した候補の上でそれらの段を分離します。 その順序は、導出ノートの第 9 節が与えます。損失が本当に融合の中にあるなら、導出ノートの 混合則が候補となる手当てです。ただし、そこで導かれる影響度はクエリ単位ではなく行単位 である点に注意してください。

8. 副産物

  • このモデルでの Track B は、同じキャッシュでの 7 月の実行より、どのタスクでも 0.1〜3.5 点 低くなっています (TMD は 2,134 クエリで −2.0、ESGReports は 36 クエリで −3.5)。あいだの どのリリースでランキングが動いたかは、まだ分かっていません。公開済みの表は 8 月のもので 影響を受けませんが、次の再測定は影響を受けます。
  • ベンチマーク README のノイズに関する教義は、第 3 節と矛盾します。
  • 計装の最初の実行で、既存の欠陥が 2 つ捕まりました (--fast が far リストを丸ごと 落としていたこと、そしてライブラリ側の limit の上限が全順位付けの実行を切っていたこと)。 どちらも、これらの腕を走らせる前に修正しました。

9. 3 つのモデル、1 つの表

bge-m3 の Track A は 2026 年 9 月に測り直しました (平均 56.83 で公開値と一致するので、 計器は無傷です)。bge-m3 の Track B は 8 月の実行、jina は 7 月の 2 本、MiniLM は 3 月の パイプラインのもので、参考値にすぎません。

タスク bge A bge B Δ bge Δ jina Δ MiniLM (旧)
MemBench 71.24 65.62 −5.62 −2.88 −0.04
QASPER 51.54 48.55 −2.99 −4.18 +25.05
TMD 28.11 25.18 −2.93 −4.16 ±0.00
ConvoMem 64.41 61.59 −2.81 −2.91 −0.04
REALTALK 44.98 43.04 −1.94 +0.41 +0.19
ReMe 61.39 59.61 −1.78 −3.54 −0.01
LMEB_SciFact 76.41 74.90 −1.51 −5.71 ±0.00
Gorilla 34.37 32.93 −1.44 −1.63 −13.98
MLDR 81.33 80.66 −0.67 −1.98 +0.37
LoCoMo 46.53 45.92 −0.61 +0.11 +0.09
PeerQA 29.73 30.04 +0.31 −2.06 −0.01
Proced_mem_bench 51.23 52.13 +0.90 −1.60 +5.88
ESGReports 40.82 43.27 +2.45 −4.47 ±0.00
LongMemEval 78.29 81.07 +2.78 +4.49 +0.26
EPBench 87.45 90.24 +2.79 −3.87 −3.31
MemGovern 85.98 89.04 +3.06 +1.94 +0.05
DeepPlanning 52.86 56.70 +3.84 +4.55 −7.82
NovelQA 32.24 36.10 +3.86 +4.21 +0.72
CovidQA 79.46 83.94 +4.48 +3.60 +0.08
KnowMeBench 46.51 51.62 +5.11 +6.53 ±0.00
LooGLE 58.94 64.12 +5.18 +5.19 +0.70
ToolBench 46.38 52.21 +5.83 +1.79 −1.12

読み:

  • bge-m3 も 10 タスクで負けています。 平均 +0.83 は、得と損が打ち消し合った結果 です。jina と bge-m3 の両方で負けるタスクが 8 つあります (MemBench、QASPER、TMD、 ConvoMem、ReMe、SciFact、Gorilla、MLDR)。モデルが強いほど、同じ族がより多く 負けます。
  • Gorilla は 3 モデルすべてで負けます (−13.98 / −1.63 / −1.44)。MemBench、ConvoMem、 ReMe は 3 つとも 0 かそれ以下です。これは、埋め込みモデルが何であれハイブリッドの パイプラインが害する族です。その害を為しているのが融合なのか、それより後の段なのかは、 段を凍結した再生が決めなければならないことです。
  • QASPER は符号が変わります (+25 → −4 → −3)。字面アームは弱いモデルを救い、同じ票が 強いモデルを害します。3 つすべてで得をするタスク (LongMemEval、LooGLE、KnowMeBench、 CovidQA、NovelQA) も、同じくらい一貫しています。
  • admission は、この族を動かしません (第 2 節)。したがって、これを取り戻すものが何で あれ、admission より後で働かなければなりません。導出ノートが挙げる候補は、字面の票を dense アームの null からの距離と秤にかける規則を、行ごとに適用するものです。段が 分離されるまでは、それは候補のままです。