TypeSafe Jev を RAG の rerank に使うと、Cohere Rerank より関連文書を正しく見分けられるのか検証した

はじめに

TypeSafe の Jev は、文章を生成する代わりに「はい／いいえ」の確率や、決められた選択肢のどれかを返す AI モデルです。最近は「Jev as a Judge」、つまり判定役としての使い方が注目されています。

出どころの論文は、LLM の回答の良し悪しを Jev に判定させています。回答どうしの優劣や、根拠に照らした事実確認では、比較した判定器の中で最も強かった GPT-6 Astra との正答率の差が 3 パーセントポイント以内でした。判定 1,000 件あたりの費用は GPT-6 Astra の 12.182 ドルに対して Jev が 0.044 ドルで、約 280 分の 1 です。一方、導出の正しさを確かめる判定などでは差が大きくなっています。

この論文が判定しているのは、LLM が書いた回答です。一方、RAG の rerank は、検索で集めた候補文書を、質問への関連度で並べ替える工程です。rerank で判定するのは、回答を作る前の材料である文書で、各文書が質問に答える根拠になるかを見ます。この使い方は論文では検証されていません。

課題	Jev に渡すもの	判定すること
回答どうしの優劣（論文）	質問、回答 A、回答 B	A と B のどちらが良い回答か
根拠に照らした事実確認（論文）	質問、根拠の文章、回答 1 件	回答が根拠の文章に支えられているか
参照解答との照合（論文）	質問、正解、回答	回答が正解と一致しているか
rerank（本記事）	質問、候補文書 10 件	各文書が、質問に答える根拠になるか

そこで、この判定役としての力を RAG の rerank に使ったらどうなるかを検証しました。

結論

• Wikipedia の検索結果に人が関連の有無を付けた公開データ（MIRACL 日本語版）では、1 つの質問に対して検索で集めた候補文書を並べ替える力は Cohere Rerank とほぼ同じか、わずかに上回った
• 同じデータで、1 つのしきい値で全質問の候補文書を切り分ける使い方では、Jev の方が無関係な文書を多く落とせた。関連文書の 9 割を残すように切ったとき、残った文書のうち本当に関連する割合は Cohere Rerank が 42%、Jev が 58%
• 同じ会社・同じ話題で、年度や部署だけが違う文書が並ぶ合成データでは、並べ替えとしきい値の両方で大差が付いた。1 位に関連文書を置けた問題の割合は Cohere Rerank が 32%（でたらめに並べた場合と同じ）、Jev が 93%。しきい値で切ったときに残った文書の関連割合も 35% と 83%
• 候補文書 10 件の rerank 1 回の費用は Cohere Rerank の約 10 分の 1
• 検索そのものを Jev に置き換えるのは、チャットのように数秒で答えたい用途では 1,000 件程度でも待ち時間が長すぎる

参考情報

検証内容

本記事では、次の 3 点を検証します。

1. rerank で、Jev は Cohere Rerank より関連文書を正しく見分けられるか。判定基準の効果と、時間と費用も比べる

2. 候補文書を何件ずつまとめて Jev に渡すのがよいか

3. 埋め込み検索を使わず、全文書を Jev に判定させて検索できるか

1 と 2 は結果1と結果2で測りました。3 は精度を測れるデータがなかったので、時間と費用の見積もりだけを補足に書きます。

Jev の基本的な仕組み

Jev には、state と質問を一緒に送ります。state は判定の材料となるデータで、今回は RAG の質問文と候補文書を入れます。質問ごとに答えの型を選べ、今回は Noul（TypeSafe 独自の型の名前）を使いました。「はい」である確率を 0〜1 で返す型です。

rerank では、候補文書 1 件ごとに「この文書は質問に答える根拠になるか」を尋ねます。実際に送ったリクエストは次の形です（文書本文は途中を省略しています）。

jev-rerank-request.json

{
  "state": {
    "query": "ソラノハ食品の2025年度第3四半期の営業利益率が前年同期を下回ったのはなぜか。",
    "candidates": [
      {"text": "調達部 月次報告：2025年度第3四半期の小麦粉の調達単価は、前年同期比で18%上昇した。…"},
      {"text": "2022年度第3四半期 決算説明資料：営業利益率は前年同期を1.6ポイント下回った。主な要因は小麦粉の調達単価が27%上昇したこと…"},
      {"text": "2025年度第3四半期 決算短信（要約）：営業利益 29億円（同 18.3%減）、営業利益率 9.3%（前年同期 11.8%）…"}
    ]
  },
  "questions": {
    "d1": {
      "type": "noul",
      "instructions": "`candidates[0].text` は `query` に答えるための根拠として役に立ちますか。",
      "criteria": {
        "true": "クエリが指す対象そのものを扱い、回答を裏づける事実・数値・定義を含む。",
        "false": "話題が重なるだけ、参照先が異なる、または根拠となる情報を含まない。"
      }
    },
    "d2": {
      "type": "noul",
      "instructions": "`candidates[1].text` は `query` に答えるための根拠として役に立ちますか。",
      "criteria": {
        "true": "クエリが指す対象そのものを扱い、回答を裏づける事実・数値・定義を含む。",
        "false": "話題が重なるだけ、参照先が異なる、または根拠となる情報を含まない。"
      }
    },
    "d3": {
      "type": "noul",
      "instructions": "`candidates[2].text` は `query` に答えるための根拠として役に立ちますか。",
      "criteria": {
        "true": "クエリが指す対象そのものを扱い、回答を裏づける事実・数値・定義を含む。",
        "false": "話題が重なるだけ、参照先が異なる、または根拠となる情報を含まない。"
      }
    }
  }
}

criteria は、何を「はい」とみなすかを言葉で書いた判定基準です。この例では、Jev は state を 1 回読み、3 つの質問をそれぞれ独立に評価します。

state（候補文書3件）を1回読む
   ├─ 質問d1 を state に対して評価 → 0.84   ← d2とd3の答えは見えない
   ├─ 質問d2 を state に対して評価 → 0.09   ← d1とd3の答えは見えない
   └─ 質問d3 を state に対して評価 → 0.56   ← d1とd2の答えは見えない

見えないのは、ほかの質問の答え（確率）だけです。state には候補文書 3 件の本文がすべて入っているので、d1 を判定するときも d2 と d3 の本文は読めます。

数値は実際に返ってきた確率で、大きいほど「根拠になる」と判定しています。質問は「なぜ下がったか」なので、正解は理由を書いた d1 だけです。d2 は同じ会社の別の年度の資料、d3 は下がった事実だけを書いて理由がない資料です。Jev は d2 をはっきり外し、d3 は 0.56 と迷っています。

同じ 3 件を Cohere Rerank に渡すと、d1 が 0.922、d2 が 0.665、d3 が 0.889 でした。Cohere Rerank のスコアは 0〜1 に正規化された関連度で、Jev の確率とは意味が違うので、数値は直接比べられません。並べ替えの順序はどちらも同じです。ただ、Cohere Rerank は 3 件とも高く、しきい値で d2 と d3 を切り落とすのは難しい結果です。

32k と 64k の制約

Jev 1.13 の入力には 2 つの上限があります（Models）。

• state と、一番長い質問 1 つを合わせて 32k トークンまで
• state と、すべての質問を合わせて 64k トークンまで

日本語はおおむね 1 文字が 1 トークン前後になります。今回のデータで実際の請求トークン数を見ると、候補文書 1 件あたり約 480 トークンでした（質問文や判定基準の分も含みます）。候補文書 10 件を 1 リクエストにすると約 4,800 トークンで、上限には十分収まります。

ただし、上限に収まることと、精度が保てることは別です。公式ドキュメントの Jev 1.13 jaggedness は、判定に関係のない文章が state に増えるほど精度が落ちると説明しています。何件までまとめてよいかは、結果2 で測りました。

比べ方

質問と文書の組ごとに、各手法が付けたスコアで「関連する／しない」を正しく見分けられているかを測ります。候補文書のうち、質問に答える根拠になる文書を関連文書、それ以外を無関係文書と呼びます。どの文書が関連文書かは、データセットに正解として付いています。

比べた手法

どの手法も、データセットに含まれる同じ候補文書にスコアを付けます。埋め込みもベクトル索引から検索するのではなく、質問と各候補文書のベクトルの近さをそのままスコアにしています。

手法	中身
キーワード一致（BM25）	質問と同じ単語を多く含む文書ほど高く採点する
埋め込み	Cohere Embed v4 で質問と文書をベクトルにし、意味の近さで採点する
Cohere Rerank	Amazon Bedrock の Cohere Rerank 3.5。rerank 専用に訓練されたモデル
Jev（10 件ずつ）	候補文書を 10 件ずつ 1 つの state にまとめて判定させる。1 件ずつ判定させる場合は 結果2 で比べる

指標

成績は PR-AUC で示します。関連文書を上位に、無関係文書を下位に並べられているほど 1 に近づく 0〜1 の値です。候補文書をスコアの高い順に並べ、関連文書が出てくるたびに、そこまでに並んだ文書のうち関連文書が占める割合を記録し、その平均を取ります。式にすると次のとおりです。

\text{PR-AUC} = \frac{1}{R} \sum_{k} \frac{\text{上位 } k \text{ 件に含まれる関連文書の数}}{k}

R は関連文書の数で、k は関連文書が出てきた順位です。たとえば関連文書が 1 位と 4 位なら、(1/1 + 2/4) ÷ 2 = 0.75 です。関連文書がすべて先頭に並べば 1 になります。1 問に関連文書が複数あるので、最初の関連文書の順位だけを見る MRR ではなく、関連文書すべての順位を見る PR-AUC を選びました。PR-AUC は全問題をまとめても計算できるので、次の 2 つの使い方を同じ指標で比べられます。

• 問題ごとに計算して平均した値。1 つの質問に対する候補文書を正しく並べ替えられるかを表す。rerank に必要なのはこちら
• 全問題の文書をまとめて 1 本の順位に並べて計算した値。質問が変わってもスコアの高低がそろっているかも含めて表す。1 つのしきい値で全質問の候補文書を切り分ける使い方に必要なのはこちら

2 つの違いを、質問 2 つ、候補文書 3 件ずつの例で示します。

質問	候補文書	正解	手法 A のスコア	手法 B のスコア
質問 1	文書 a	関連	0.9	0.9
質問 1	文書 b	無関係	0.8	0.2
質問 1	文書 c	無関係	0.7	0.1
質問 2	文書 d	関連	0.4	0.8
質問 2	文書 e	無関係	0.3	0.3
質問 2	文書 f	無関係	0.2	0.1

A も B も、各質問の中では関連文書を 1 位にしているので、問題ごとの PR-AUC はどちらも 1.0 です。全問題をまとめると、6 件をスコアだけで 1 本に並べることになり、差が出ます。● が関連文書です。

手法A: a● 0.9 > b 0.8 > c 0.7 > d● 0.4 > e 0.3 > f 0.2   PR-AUC 0.75
手法B: a● 0.9 > d● 0.8 > e 0.3 > b 0.2 > c 0.1 > f 0.1   PR-AUC 1.0

A では、質問 2 の関連文書 d が、質問 1 の無関係文書 b と c より下に来ます。A のスコアは 1 つの質問の中での高低を表すだけで、質問をまたいで「0.8 なら関連」とは読めません。0.5 で切ると、質問 1 では b と c が残り、質問 2 では d が落ちます。B なら 0.5 の 1 本で両方の質問を切り分けられます。

Cohere Rerank は A に近い性質を持ち、無関係な候補文書に 0.8 が付くこともありました。Jev は「はい」である確率を返すので B に近く、同じデータの中なら質問が変わってもスコアの高低がそろいやすいと考えられます。ただし確率の値そのものはデータによってずれ、どこで切るのがよいかはデータごとに変わります。

2 つの値は計算方法が違うので、表をまたいで比べず、同じ表の中で手法どうしを比べてください。結果1 の表には、目安として、でたらめに並べた場合の値も載せています。

区間

Jev と Cohere Rerank の差（プラスなら Jev が上）には、95% の区間を付けました。問題を重複を許して選び直し、差を計算し直す操作を 1,000 回以上繰り返して、2.5 パーセンタイルから 97.5 パーセンタイルまでを区間としています。区間の両端がどちらもプラスなら、Jev が上回ったのは偶然とは言いにくいと読めます。マイナスとプラスの両方が入るなら、どちらが上とも言えません。結果2 で Jev の渡し方どうしを比べるときも、同じ区間を付けています。

使ったデータ

性質の違う 3 つのデータを使い、それぞれ別に集計しました。

MIRACL（日本語）

Wikipedia の文章を対象に、実際の検索で出てきた候補文書へ、人が関連の有無を付けたデータです。860 問、1 問あたり約 10 件の候補文書があり、関連文書の割合は 21% です。正解が人の判断に基づくので、本記事ではこれを一番の根拠にします。ただし質問は「〜の出身はどこ」のような一問一答型です。

J-RAGBench

架空の企業を舞台にした業務寄りの質問 60 問で、関連文書の割合は約 21% です。紛らわしい無関係文書も含みますが、キーワード一致だけでもかなり見分けられます。

合成データ

業務の RAG では「A 社と B 社で制度はどう違うか」「利益率が下がったのはなぜか」のように、1 つの文書だけでは答えきれない質問が多くあります。公開データにはこの種の質問がほとんどないため、比較・理由・経緯・複数要因・複数文書の統合の 5 種類で 60 問作りました。1 問あたりの候補文書は 10 件で、そのうち関連文書の割合は 32% です。

正解は作り方で決めました。質問に答えるのに必要な事実を先に決め、それを書いた文書を関連、書いていない文書を無関係とします。

無関係文書は、同じ会社の別の年度、別の部署、改定前の規程、数値のない一般論など、話題も単語も質問と重なるのに、必要な事実だけがない文書にしました。話題の近さで採点する手法には不利で、文書の中身を読む手法には有利な条件を、意図して作っています。Jev に渡した判定基準がこの形に合っていて有利に働いたかどうかは、結果1の「判定基準を書いたから勝ったのか」で確かめています。

問題は LLM が作り、その問題を作っていない別の AI に、正解を伏せて各文書に必要な事実が書かれているかを判定させました。判定は作成時の正解と全文書で一致し、無作為に選んだ 6 問は人も確認しています。使ったモデルの内訳は、リポジトリの README にまとめています。

結果1：関連文書を正しく見分けられるか

1 つの質問に対する候補文書を並べ替える力

rerank に必要な、問題ごとの PR-AUC の平均です。1 に近いほど、各質問の候補文書を正しく並べ替えられています。MIRACL には候補文書がすべて関連文書の問題が 63 問あり、並べ替えの良し悪しを測れないので除いて、797 問で計算しました。

データ	でたらめに並べた場合	埋め込み	Cohere Rerank	Jev（10 件ずつ）	Jev − Cohere Rerank（95% 区間）
MIRACL（797 問）	0.37	0.771	0.841	0.865	+0.024（+0.007〜+0.040）
J-RAGBench（60 問）	0.36	0.880	0.932	0.931	−0.001（−0.045〜+0.043）
合成データ（60 問）	0.47	0.487	0.521	0.940	+0.419（+0.367〜+0.465）

MIRACL と J-RAGBench のような一問一答に近い検索では、Jev と Cohere Rerank の差はほとんどありません。人が判定した MIRACL では +0.024 で、区間の両端はプラスですが小さな差です。J-RAGBench では同等でした。

差がはっきり出たのは、紛らわしい文書が並ぶ合成データです。Cohere Rerank と埋め込みは、でたらめに並べた場合（0.47）に近い値で、話題が同じで中身だけが違う文書を見分けられていません。Jev は、必要な事実が書かれているかを読んで判定しています。ただし、この差の大きさは作り方に左右されます。紛らわしい文書が多い場面で開きうる差の、大きい側の目安として読んでください。

RAG で気になる「上位に関連文書が来るか」で見ても、同じ傾向です。質問ごとに候補文書を各手法のスコアの高い順に並べ替え、1 位が関連文書だった質問と、上位 3 件に関連文書が 1 件以上入っていた質問の割合を数えました。大きいほど良い結果です。MIRACL は上の表と同じ 797 問で集計しました。

データ	並べ方	1 位が関連文書	上位 3 件に関連文書を含む
MIRACL	でたらめに並べた場合	21%	49%
MIRACL	Cohere Rerank	82%	96%
MIRACL	Jev	84%	98%
J-RAGBench	でたらめに並べた場合	21%	51%
J-RAGBench	Cohere Rerank	93%	98%
J-RAGBench	Jev	97%	100%
合成データ	でたらめに並べた場合	32%	74%
合成データ	Cohere Rerank	32%	80%
合成データ	Jev	93%	100%

合成データでは、Cohere Rerank が 1 位に関連文書を置けた割合は、でたらめに並べた場合と同じ 32% でした。

MIRACL で 1 位が関連文書にならなかった問題には、正解ラベルの誤りも含まれます。Jev が各問題で 1 位に置いた文書のうち、MIRACL のラベルでは「無関係」と付いていたもの（127 件）から 10 件を抜き出し、ラベルを伏せて 2 つの AI に判定させたところ、5 件は両方が「答えが書かれている」と判定しました。残りの 5 件は、判定が割れたか、答えの一部しか書かれていないものでした。MIRACL の 84% と 82% は、どちらも実際より低く出ている可能性があります。合成データの正解は作り方で決めているので、93% と 32% にはこの問題はありません。

質問をまたいでスコアの意味がそろっているか

全問題の文書をまとめて計算した PR-AUC です。どの質問にも同じしきい値を使えるかを表します。

データ	でたらめに並べた場合	キーワード一致	埋め込み	Cohere Rerank	Jev（10 件ずつ）	Jev − Cohere Rerank（95% 区間）
MIRACL	0.21	0.29	0.54	0.69	0.76	+0.07（+0.04〜+0.09）
J-RAGBench	0.21	0.64	0.70	0.79	0.88	+0.09（+0.02〜+0.16）
合成データ	0.32	0.35	0.33	0.36	0.92	+0.56（+0.52〜+0.59）

こちらでは、どのデータでも Jev が上回り、区間の両端はどれもプラスでした。Jev は「はい」の確率を返すので、同じデータの中なら、質問が変わってもスコアの高低がそろいやすいと考えられます。Cohere Rerank のスコアは、公式ドキュメント（Best Practices for using Rerank）でクエリによって変わる値（query dependent）とされていて、しきい値は代表的なクエリを集めて決めるよう勧められています。

しきい値で切る使い方は、たとえば関連文書がない質問で無関係な文書を LLM に渡さない、件数を固定せずに関連する文書だけを渡す、といった場面で使います。この使い方を直接比べました。手法ごとにスコアの範囲が違うので、同じ値で切るのではなく、手法ごとにしきい値を決めます。全質問の候補文書をスコアの高い順に 1 本に並べ、上から数えて関連文書が全体の 9 割に達した位置のスコアを、しきい値にしました。そのしきい値以上の文書のうち、本当に関連する割合を比べます。大きいほど、無関係な文書を多く落とせています。Jev は判定基準を付けた版で測りました。

データ	でたらめに並べた場合	埋め込み	Cohere Rerank	Jev（10 件ずつ）	Jev − Cohere Rerank（95% 区間）
MIRACL	21.4%	31.6%	42.2%	57.7%	+15.5 ポイント（+12.4〜+19.3）
J-RAGBench	20.7%	38.1%	53.4%	61.3%	+7.9 ポイント（−14.4〜+26.7）
合成データ	32.2%	32.9%	34.5%	83.3%	+48.8 ポイント（+43.3〜+54.3）

このとき使ったしきい値は次のとおりです。

データ	埋め込み	Cohere Rerank	Jev（10 件ずつ）
MIRACL	0.49	0.60	0.46
J-RAGBench	0.39	0.30	0.09
合成データ	0.44	0.36	0.38

人が判定した MIRACL でも、Jev の方がはっきり多く無関係な文書を落とせました。J-RAGBench は 60 問と少なく、区間にマイナスとプラスの両方が入っているので、どちらが上とも言えません。Jev のしきい値はデータによって 0.09〜0.46 と大きく変わりました。1 つのデータの中では 1 本のしきい値で切り分けやすい一方、確率の値そのものはデータごとにずれます。実務で同じことをするには、自分のデータに少量の正解を付けてしきい値を決める必要があります。

判定基準を書いたから勝ったのか

Jev には判定基準（criteria）を渡していました。この基準は「話題が重なるだけなら『いいえ』」と書いており、合成データの無関係文書はまさにその形です。そこで、基準を渡さず「関連しますか」とだけ尋ねる版も測りました。

並べ替える力を表す、問題ごとの PR-AUC の平均です。

データ	Cohere Rerank	Jev 基準なし	Jev 基準あり
MIRACL	0.841	0.852	0.865
J-RAGBench	0.932	0.943	0.931
合成データ	0.521	0.922	0.940

質問をまたいでスコアの意味がそろっているかを表す、全問題をまとめた PR-AUC です。

データ	Cohere Rerank	Jev 基準なし	Jev 基準あり
MIRACL	0.69	0.73	0.76
J-RAGBench	0.79	0.87	0.88
合成データ	0.36	0.89	0.92

合成データでは、基準がなくても Jev は Cohere Rerank を大きく上回りました。紛らわしい文書を見分ける力のほとんどは、判定基準ではなくモデル自体から来ています。並べ替えだけを見ると、基準のありなしの差は小さく、J-RAGBench では基準なしの方がわずかに高い値でした。それでも、Jev では関連の定義を判定基準として言葉で書けます。

しきい値で切る使い方では、基準の効果が見えました。関連文書の 9 割を残すしきい値で切ったとき、残った文書のうち本当に関連する割合は次のとおりです。

データ	Jev 基準なし	Jev 基準あり	差（95% 区間）
MIRACL	52.8%	57.7%	+4.9 ポイント（+3.1〜+7.0）
J-RAGBench	49.6%	61.3%	+11.7 ポイント（−6.1〜+20.5）
合成データ	76.4%	83.3%	+6.9 ポイント（+0.5〜+17.3）

MIRACL と合成データでは、基準を書くと無関係な文書をより多く落とせました。J-RAGBench でも基準ありの方が高い値でしたが、区間にマイナスとプラスの両方が入っているので、差があるとは言い切れません。Cohere Rerank には、何を関連とみなすかを利用者が指定する手段がありません。

1 回の rerank にかかる時間と費用

約 10 件の候補文書を rerank する 1 回あたりで比べます。時間は MIRACL 860 問を 1 問ずつ順に処理したときの 1 問あたりの平均です。

手法	1 問あたりの時間（参考）	1 回の費用	費用の根拠
Cohere Rerank 3.5	0.45 秒	約 0.002 ドル	1,000 クエリあたり 2.00 ドル（Amazon Bedrock の料金、1 クエリ最大 100 件）
Jev	0.33 秒	約 0.0002 ドル	入力 100 万トークンあたり 0.042 ドル（TypeSafe の Models）× 約 4,800 トークン

候補文書 10 件なら、Jev の費用は Cohere Rerank の約 10 分の 1 です。Cohere Rerank は 1 クエリごとの定額で、Jev は候補文書の件数に比例するので、この差は候補文書の数で変わります。候補文書 100 件では、両者はほぼ同じ費用になります。

時間は通信を含む今回の実行での値です。Jev の応答時間は測った時間帯によって変わり、別の時間帯に 10 件のリクエストを順に送ったときは中央値 0.65 秒でした。Cohere Rerank は 1 回しか測っていないので、時間帯によってはどちらが速いかが入れ替わりえます。速さの優劣は、この測定からは言えません。

結果2：候補文書を何件ずつまとめて渡すか

Jev に候補文書を 1 件ずつ判定させる場合と、10 件ずつまとめて判定させる場合で、成績が違いました。何が効いているのかを確かめるため、合成データの各問題の 10 件に、他の問題の文書 90 件を混ぜて 100 件にし、まとめる件数を変えて測りました。

他の問題の文書は別の会社の話なので、どれも無関係です。100 件は無作為に並べ替えてから区切りました。そのため 10 件ずつの場合、1 リクエストに元の候補文書は平均 1 件ほどしか入りません。成績は、各問題の元の 10 件についてだけ測っています。

候補文書の中身	1 リクエストの件数	並べ替え（問題ごと）	全問まとめ	混ぜた文書を「関連」（確率 0.5 以上）と誤った割合
同じ問題の 10 件	1 件ずつ	0.87	0.75	混ぜていないため該当なし
同じ問題の 10 件	10 件まとめて	0.94	0.91	混ぜていないため該当なし
混ぜた 100 件	10 件ずつ	0.84	0.74	0%
混ぜた 100 件	25 件ずつ	0.83	0.72	3%
混ぜた 100 件	50 件ずつ	0.72	0.61	21%
混ぜた 100 件	100 件まとめて	0.55	0.46	47%

値はどちらも PR-AUC で、1 に近いほど良い結果です。同じ問題の候補文書 10 件をまとめると、1 件ずつより上がりました。差は並べ替えで +0.08（95% 区間 +0.05〜+0.11）、全問まとめで +0.16（+0.10〜+0.21）です。

一方、同じ 10 件ずつでも、一緒に並ぶのが無関係な文書なら 1 件ずつと同程度か、わずかに下がります。効いているのは件数ではなく、一緒に並ぶ中身です。state に同じ話題の候補文書の本文が並ぶので、どれが必要な事実を持っているかを見比べられるためと考えられます。

無関係な文書が混ざる場合、25 件ずつまでは 10 件ずつとほぼ変わりませんでしたが、50 件を超えると崩れました。100 件をまとめると、混ぜた文書の半分近くを「関連」と判定しています。100 件のリクエストも上限エラーにはならずに処理されたので、上限内であっても詰め込みすぎると精度は落ちます。

候補文書が 30〜50 件あるときは、上位から 10 件ずつ区切って送ることになります。混ぜた 100 件を 10 件ずつ送った行では、元の候補文書が約 10 個のリクエストに散らばっても、1 件ずつと同程度の成績でした。別々のリクエストで出た確率は、そのまま並べて比べてよいと読めます。ただし、同じ話題の候補文書を分けると見比べられる範囲が 10 件に限られるので、10 件まとめたときの上乗せがどこまで残るかは測っていません。

補足：検索そのものを Jev に任せられるか

rerank で有効なら、埋め込み検索を使わず、全文書を Jev に判定させて検索できないかという疑問が出ます。これは精度を測っていません。数百〜数千件の全文書に関連の有無が付いたデータが手元になく、ラベルのない文書を無関係とみなすと、Jev が本当に関連する文書を拾ったときに誤りと数えてしまうからです。

所要時間と費用は見積もれます。文書を 10 件ずつ 1 リクエストにまとめ、8 リクエストを並列で送った実測を、文書数に比例させました。文書 100 件で 1 問あたり 1.4〜3.1 秒です。並列で送ると、1 リクエストあたりの時間は順に送ったときより長くなりましたが、見積もりにはこの並列時の実測を使っています。API の上限は、2026 年 10 月 5 日に Models のページで確かめた値で、毎秒 100,000 トークンと毎秒 80 リクエストです。この値は予告なく変わるとされています。候補文書 10 件で約 4,800 トークンのリクエストなら、トークンの上限が先に効き、毎秒約 20 リクエストが最速です。どれだけ並列にしても、これより速くはなりません。費用は入力 100 万トークンあたり 0.042 ドル、候補文書 1 件あたり約 480 トークンで計算しました。

文書数	1 クエリのリクエスト数	所要時間（8 並列の実測から）	API 上限での最短時間	1 クエリの費用
1,000	100	14〜31 秒	約 5 秒	約 0.02 ドル
10,000	1,000	2.4〜5 分	約 48 秒	約 0.2 ドル
100,000	10,000	24〜51 分	約 8 分	約 2 ドル
1,000,000	100,000	4〜8.5 時間	約 80 分	約 20 ドル

チャットのように数秒で答えたい用途では、1,000 件の時点ですでに待ち時間が長すぎます。10 万件を超えると、1 回の検索のために API の上限を数分から 1 時間以上使い続けることになります。候補文書を絞る検索は、これまでどおり埋め込み検索が担うのが現実的です。

検証の再現方法

本記事の検証に使ったコードとデータは、GitHub の revsystem/jev-search-and-retrieval で公開しています。比べた各手法の実装、合成データ（問題、候補文書、作成時の正解、検証結果）、本記事の測定結果が入っています。

測定結果には、質問と候補文書の組ごとの ID、正解のラベル、各手法のスコアが入っています。そのため API を呼ばなくても、本記事の表を同じ値で再現できます。

git clone https://github.com/revsystem/jev-search-and-retrieval.git
cd jev-search-and-retrieval
uv venv
uv pip install -e ".[dev]"
uv run jev-rag report-judge --results-dir results

測定そのものをやり直すこともできます。その場合は TypeSafe の API キーと、Amazon Bedrock で Cohere Embed v4 と Cohere Rerank 3.5 を使える AWS アカウントが必要で、API の利用料金がかかります。手順はリポジトリの README にまとめています。API の応答は実行ごとに少し揺れるので、測り直した値は本記事の表と完全には一致しません。

検証の制約

• データはすべて日本語。Jev の公式ドキュメントは、日本語の精度が英語より低いと説明している
• 合成データの正解は作り方で決めたもので、人が観察したものではない。紛らわしい文書で並べ替えにも大差が出たという結果は合成データだけのもので、人が判定したデータでは確かめていない
• 合成データは LLM（Claude と Grok）が書いた文章。LLM が書いた文章を AI モデルが判定するときに有利に働く偏りがある可能性は、確かめていない
• Jev が各問題で 1 位に置いた文書のうち、MIRACL のラベルでは「無関係」と付いていたものから 10 件を選んで AI に確かめると、5 件は答えが書かれていた。MIRACL のラベルには漏れがあると考えられるが、全体でどの程度あるかは確かめていない。AI にラベルを付け直させると正解がその AI の判断になるため、数値は補正していない
• J-RAGBench と合成データは 60 問ずつで、差の区間は広め
• 判定基準は「あり」と「なし」の 2 通りしか試していない
• 所要時間は今回の並列度、通信環境、測定した時間帯での値

まとめ

本記事では、RAG の rerank で Jev と Cohere Rerank のどちらが関連文書を正しく見分けられるかを、3 種類の日本語データで検証しました。

Jev を rerank に選ぶ理由は、場面によって違います。

• 一問一答に近い検索では、1 つの質問に対する候補文書を並べ替える精度は Cohere Rerank とほぼ同じ。それでも、候補文書 10 件なら費用が約 10 分の 1 で、1 つのしきい値で無関係な文書を多く落とせ、何を関連とみなすかを判定基準で指定できる。しきい値は、自分のデータに少量の正解を付けて決める
• 版違い・年度違い・部署違いの文書が多い社内文書の RAG では、今回の合成データのように並べ替えの精度そのものが上がる可能性がある。ただし、この差は合成データでしか確かめていない

どちらの場面でも、埋め込み検索で候補文書を絞り、判定基準を付けて候補文書を 10 件ずつ Jev に判定させる構成をおすすめします。同じ質問の候補文書をまとめて渡すと 1 件ずつより正確になり、無関係な文書を 50 件以上詰め込むと崩れます。検索そのものを Jev に任せるのは、1,000 件程度でも対話的な用途には遅すぎます。