はじめに
前回の記事では、TypeSafe の Jev を RAG の rerank に使い、Cohere Rerank と関連文書を見分ける精度を比べました。rerank は、検索で集めた候補文書を、質問への関連度で並べ替える工程です。
その後、2026 年 10 月 1 日に、AWS がリリースした判定専用モデル「Strands Decider 2B」が、Strands Agents の公式ブログで発表されました。strands-decider は「decision model」と呼ばれる種類のモデルで、Jev と同じく、文章を生成せずに「はい／いいえ」の確率や選択肢を返します。手元の GPU で動かせるのが特徴です。
そこで、前回と同じコーパス、同じ質問文と判定基準、同じ指標で strands-decider を検証し、Jev と比べました。
結論
- 1 つの質問に対して検索で集めた候補文書を並べ替える力は、3 種類のデータすべてで Jev より低かった。人が判定した MIRACL 日本語版では、1 が満点の指標で Jev の 0.865 に対して 0.692
- 候補文書をまとめて 1 回で判定させると、でたらめに並べた場合に近い成績になった（J-RAGBench だけはやや上回った）。候補文書ごとに 1 回ずつ判定させる必要がある
- 判定基準を渡さなくても、質問文を英語にしても、成績はほとんど変わらなかった
- 判定 1 回（候補文書 1 件）の処理時間は、RTX 3060 Ti で中央値 80 ms 前後だった
参考情報
検証内容
本記事では、次の 3 点を検証します。
-
Jev と同じ条件で、strands-decider は関連文書をどれだけ正しく見分けられるか。判定基準のありなしと、質問文の言語の違いも比べる
-
候補文書を 1 件ずつ渡す場合と、最大 10 件まとめて渡す場合で、成績はどう変わるか
-
Jev との差は、何によって説明できるか
1 と 2 は結果1と結果2で測り、3 は「Jev との差をどう説明できるか」で、測定とコードで確かめたことと推測を分けて書きます。
strands-decider の仕組み
strands-decider は、文章を生成する言語モデル（Qwen3.5-2B-Base）から、文章を生成する部分を取り除き、選択肢を指す小さな読み出し部を付けたモデルです。パラメーター数は 1.9B（名前の 2B は丸めた値）で、今回は公開されている v19 のモデル（StrandsAgents/strands-decider-2B-hobson-v19）を使いました。
strands-decider serve で起動するサーバーは、Jev と同じ POST /v1/systemone で、state（判定させる材料。今回は質問と候補文書）と、モデルに尋ねる質問文を受け取ります。質問文の型（「はい」の確率で答えさせる Noul など）と判定基準（criteria）の書き方も Jev と同じです。ただし、公式ドキュメント（docs/inference.md）には、Jev の API との互換性は確認していないと書かれています。
Jev との主な違いは次のとおりです。
| 項目 | strands-decider（v19） | Jev |
|---|---|---|
| 動く場所 | 手元の GPU（または CPU） | TypeSafe の API |
| 入力の上限 | 4,096 トークン | state と一番長い質問 1 つで 32k トークン |
| 上限を超えたとき | エラーにせず、state を末尾側で切り詰める | エラーを返す（検証中に 400 max_tokens_exceeded を受け取った） |
質問文にパス（candidates[0].text など）を書いて state の一部を指す書き方 |
説明がない。サーバーは state を JSON の文字列にしてそのまま渡す | ある。パスを書けば、モデルが state のどの部分を判定するか分かると公式ドキュメントにある |
| 同時リクエスト | 検証されていない | 並列で送れる |
検証環境
ハードウェアと OS
| 項目 | 値 |
|---|---|
| CPU | AMD Ryzen 5 5600X |
| メモリ | 64GB（このうち 16GB を WSL2 に割り当て。.wslconfig の memory=16GB） |
| GPU | NVIDIA GeForce RTX 3060 Ti（8GB）、ドライバー 616.92 |
| OS | Windows 11（ビルド 26220）+ WSL2（2.7.14.0、カーネル 6.18.33.2） |
| WSL のディストリビューション | Ubuntu 24.04.5 LTS |
ソフトウェア
検証に使ったソフトウェアとバージョンです。CUDA ツールキットと causal-conv1d は、結果の表を測ったあとで入れました。入れる前と後で、1 件ずつの経路を合成データと MIRACL で測り直しましたが、処理時間にもスコアにもほとんど違いはありませんでした。
| 項目 | バージョン |
|---|---|
| Python | 3.13.14 |
| uv | 0.12.22 |
| strands-decider | 0.1.0 |
| torch | 2.14.1（CUDA 13.0 版） |
| transformers | 5.18.0 |
| flash-linear-attention | 0.5.2 |
| CUDA ツールキット | 13.0.3（nvcc V13.0.88） |
| causal-conv1d | 1.7.0 |
strands-decider のインストール
作業用のディレクトリに、uv で Python 3.13 の仮想環境を作ります。--seed を付けて仮想環境に pip を入れておきます。
mkdir -p ~/work/sandbox/strands-decider
cd ~/work/sandbox/strands-decider
uv venv --seed --python 3.13 .venv
PyPI から strands-decider を入れます。バージョンは指定しておらず、0.1.0 が入りました。torch は個別に入れず、strands-decider の依存として入ります。入った torch 2.14.1 は、CUDA 13.0 のランタイムを依存パッケージとして取り込む版（2.14.1+cu130）でした。
.venv/bin/pip install strands-decider
torch から GPU が見えていることを確かめます。cuda True と表示されれば準備完了です。
.venv/bin/python -c "import strands_decider, torch; print('torch', torch.__version__, 'cuda', torch.cuda.is_available())"
flash-linear-attention のインストール
公式ドキュメント（docs/inference.md）が、NVIDIA の GPU（--device cuda）でサーバーを動かすときに追加で入れるものとして挙げているモジュールです。strands-decider のベースモデルである Qwen3.5 には Gated DeltaNet という種類の層があり、flash-linear-attention はこの層の計算を GPU 向けに速くします。モデルの学習のときだけでなく、サーバーが質問に答えるとき（今回なら、候補文書が質問に関連するかどうかを判定するとき）にも使われます。入っていないと、サーバーは「chunk_gated_delta_rule is falling back to its reference PyTorch implementation」という警告を出し、PyTorch だけの遅い処理で計算します。
モデルを自分で学習し直すための手順書（training/README.md）によれば、flash-linear-attention の GPU 用の処理は Linux でしか動きません。Windows で直接学習すると PyTorch の汎用の処理に切り替わり、学習が約 2.3 倍遅くなります。WSL2 では Linux と同じく flash-linear-attention が動き、GPU を本来の速さで使えるとされています。今回の検証も WSL2 なので、flash-linear-attention を入れて使いました。
PyPI の 0.1.0 には GPU 用の追加パッケージの指定がまだないので、個別に入れます。
uv pip install flash-linear-attention
CUDA ツールキットのインストール
もう 1 つのモジュール causal-conv1d は、手元の CUDA ツールキットでビルドする必要があります。公式にバージョンの指定はないので、torch の CUDA 13.0 版に合わせました。
NVIDIA の CUDA on WSL User Guide は、WSL の中に Linux 用の GPU ドライバーを入れないよう求めています。GPU ドライバーは Windows 側のものを使います。そこで、NVIDIA の WSL 用リポジトリから、ドライバーを含まないツールキットだけのパッケージを入れます。手順は、NVIDIA の CUDA 13.0 のダウンロードページ（WSL-Ubuntu、deb (network)）に示されているものです。古い署名鍵が入っている環境では、手引きにあるとおり、先に sudo apt-key del 7fa2af80 で削除しておきます。
wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt-get update
sudo apt-get -y install cuda-toolkit-13-0
causal-conv1d のビルド
ツールキットを指定して、causal-conv1d をビルドします。手元の環境では 8 分 44 秒かかりました。
CUDA_HOME=/usr/local/cuda-13.0 PATH=/usr/local/cuda-13.0/bin:$PATH MAX_JOBS=8 \
uv pip install causal-conv1d --no-build-isolation
causal-conv1d がないと、サーバーは「causal_conv1d_fn is falling back to its reference PyTorch implementation」という警告を出し、PyTorch だけの処理で動きます。今回の環境では、入れる前と後で、候補文書 1 件の判定の処理時間はほぼ変わりませんでした。中央値で、合成データは 79.8 ms と 79.9 ms、MIRACL は 82.0 ms と 81.5 ms です。
サーバーの起動
サーバーを起動します。初回の起動時には、Hugging Face からベースモデルの Qwen3.5-2B-Base と、strands-decider v19 のモデルファイル（ベースモデルに追加する LoRA アダプターと読み出し部など）をダウンロードします。手元では、ベースモデルが 4.3GB、v19 のモデルファイルが 88MB でした。
.venv/bin/strands-decider serve StrandsAgents/strands-decider-2B-hobson-v19 --device cuda --port 8099
GPU メモリの使用量を、nvidia-smi の GPU 全体の値で測りました（WSL では /usr/lib/wsl/lib/nvidia-smi にあります）。起動前は、Windows 側の画面表示などで 784 MiB を使っていました。モデルを読み込むと 4,645 MiB になりました。J-RAGBench の候補文書を 1 件ずつ判定している間は最大 5,097 MiB、最大 10 件ずつ（state は 3,600 トークン以内）では最大 7,186 MiB でした。起動前からの増加分は、1 件ずつで約 4.2 GiB、10 件ずつで約 6.3 GiB です。PyTorch が確保したメモリを手放さないため、判定が終わっても使用量は下がらず、サーバーを止めると元に戻りました。8GB の GPU では、10 件ずつの判定で残りが 1GB ほどになります。
比べ方
データ、指標、質問文と判定基準は、前回の記事と同じです。指標と区間の詳しい説明は、前回の記事を参照してください。
使ったデータ
データは 3 つです。
- MIRACL 日本語版: Wikipedia の検索結果に人が関連の有無を付けた公開データ（860 問）。問題ごとの指標は、候補文書がすべて関連文書の 63 問を除いた 797 問で計算する
- J-RAGBench: 架空の企業を舞台にした業務寄りの質問（60 問）
- 合成データ: 同じ会社・同じ話題で、年度や部署だけが違う紛らわしい文書を含む業務の質問（60 問）
成績は PR-AUC（関連文書を上位に並べられているほど 1 に近づく 0〜1 の値）で示します。
判定させた経路
strands-decider には、次の 4 通りで判定させました。
| 経路 | 内容 |
|---|---|
| 1 件ずつ | 候補文書 1 件を state に入れ、Jev と同じ日本語の質問文と判定基準で尋ねる |
| 1 件ずつ、判定基準なし | 判定基準を渡さず「関連しますか」とだけ尋ねる（後述のとおり、サーバーが既定の基準で補う） |
| 1 件ずつ、英語 | 質問文と判定基準を英語にする（候補文書は日本語のまま） |
| 最大 10 件ずつ | 候補文書を最大 10 件まとめて state に入れ、candidates[0].text のように 1 件ずつ尋ねる（Jev の 10 件ずつと同じ形） |
1 件ずつの経路で実際に送ったリクエストは、次の形です。前回の記事の Jev の例と同じ質問で、state の candidates には候補文書を 1 件だけ入れます（文書本文は途中を省略しています）。
{
"model": "strands-decider-2B-hobson-v19",
"state": {
"query": "ソラノハ食品の2025年度第3四半期の営業利益率が前年同期を下回ったのはなぜか。",
"candidates": [
{"text": "調達部 月次報告：2025年度第3四半期の小麦粉の調達単価は、前年同期比で18%上昇した。…"}
]
},
"questions": {
"c_0": {
"type": "noul",
"instructions": "`candidates[0].text` は `query` に答えるための根拠として役に立ちますか。",
"criteria": {
"true": "クエリが指す対象そのものを扱い、回答を裏づける事実・数値・定義を含む。",
"false": "話題が重なるだけ、参照先が異なる、または根拠となる情報を含まない。"
}
}
}
}
1 件ずつの経路では、1 回のリクエストで返ってくるのは、その候補文書 1 件についての「はい」の確率だけです。候補文書が 10 件ある質問なら、10 回のリクエストに分けて判定させます。PR-AUC は、同じ質問の 10 回分の確率を集めてスコアの高い順に並べ、正解と照らして計算します。合成データの 1 問での実際の値を、確率の高い順に並べると次のとおりです。10 行それぞれが、別々のリクエストの結果です。
| 順位 | 候補文書 | 正解 | 確率 |
|---|---|---|---|
| 1 | d02 | 関連 | 0.895 |
| 2 | d10 | 無関係 | 0.738 |
| 3 | d07 | 関連 | 0.736 |
| 4 | d09 | 無関係 | 0.725 |
| 5 | d05 | 無関係 | 0.712 |
| 6 | d04 | 関連 | 0.571 |
| 7 | d01 | 無関係 | 0.535 |
| 8 | d03 | 無関係 | 0.442 |
| 9 | d08 | 無関係 | 0.226 |
| 10 | d06 | 無関係 | 0.183 |
関連文書は 1 位、3 位、6 位に出てくるので、この問題の PR-AUC は (1/1 + 2/3 + 3/6) ÷ 3 = 0.722 です。この計算は、別々のリクエストで出た確率どうしを、大きさで比べてよいことを前提にしています。
入力の上限と送り方
入力の上限は 4,096 トークンで、strands-decider 0.1.0 は超えた分をエラーにせず切り捨てます。GitHub の main ブランチには、上限を超えた入力をエラーで拒否する --strict-window が追加されていますが、まだリリースされていません。記事の執筆時点で PyPI に公開されているのは 0.1.0 だけです。そこで、送る前に strands-decider のトークナイザーで state のトークン数を数え、質問文の分を残して、state を 3,600 トークン以内に区切りました。そのため、候補文書が長いデータでは、「最大 10 件ずつ」の 1 リクエストが 10 件未満になります。1 件ずつなら、すべての候補文書が上限に収まります。
リクエストは 1 件ずつ順に送りました。同時リクエストの動作は、公式に検証されていないためです。
結果1：関連文書を正しく見分けられるか
1 つの質問に対する候補文書を並べ替える力（問題ごとの PR-AUC の平均）です。1 に近いほど、各質問の候補文書を正しく並べ替えられています。
| データ | でたらめに並べた場合 | Cohere Rerank | Jev（1 件ずつ） | Jev（10 件ずつ） | strands-decider（1 件ずつ） |
|---|---|---|---|---|---|
| MIRACL（797 問） | 0.37 | 0.841 | 0.860 | 0.865 | 0.692 |
| J-RAGBench | 0.36 | 0.932 | 0.909 | 0.931 | 0.818 |
| 合成データ | 0.47 | 0.521 | 0.867 | 0.940 | 0.785 |
Jev と strands-decider（1 件ずつ）の差と、その 95% 区間は次のとおりです。渡し方が同じ「1 件ずつ」どうしの差と、それぞれの一番良い渡し方（Jev は 10 件ずつ）どうしの差を並べます。
| データ | Jev（1 件ずつ）− strands-decider（1 件ずつ） | Jev（10 件ずつ）− strands-decider（1 件ずつ） |
|---|---|---|
| MIRACL | +0.168（+0.146〜+0.188） | +0.173（+0.152〜+0.194） |
| J-RAGBench | +0.091（+0.043〜+0.145） | +0.113（+0.070〜+0.162） |
| 合成データ | +0.082（+0.033〜+0.126） | +0.155（+0.110〜+0.203） |
3 つのデータすべてで Jev が上回り、どちらの比べ方でも区間の両端はプラスでした。問題の選び方が変わっても、Jev が上回るという向きは変わりにくいということです。Cohere Rerank と比べると、strands-decider は合成データでは上回りましたが、MIRACL と J-RAGBench では下回りました。
上位の並びで見ると、次のようになります。質問ごとに候補文書をスコアの高い順に並べ替え、1 位が関連文書だった質問と、上位 3 件に関連文書が 1 件以上入っていた質問の割合を数えました。大きいほど良い結果です。
| データ | 並べ方 | 1 位が関連文書 | 上位 3 件に関連文書を含む |
|---|---|---|---|
| MIRACL | でたらめに並べた場合 | 21% | 49% |
| MIRACL | Cohere Rerank | 82% | 96% |
| MIRACL | Jev（10 件ずつ） | 84% | 98% |
| MIRACL | strands-decider（1 件ずつ） | 63% | 85% |
| J-RAGBench | でたらめに並べた場合 | 21% | 51% |
| J-RAGBench | Cohere Rerank | 93% | 98% |
| J-RAGBench | Jev（10 件ずつ） | 97% | 100% |
| J-RAGBench | strands-decider（1 件ずつ） | 83% | 93% |
| 合成データ | でたらめに並べた場合 | 32% | 74% |
| 合成データ | Cohere Rerank | 32% | 80% |
| 合成データ | Jev（10 件ずつ） | 93% | 100% |
| 合成データ | strands-decider（1 件ずつ） | 78% | 98% |
判定基準のありなしと、質問文の言語
strands-decider の 1 件ずつの経路で比べた、問題ごとの PR-AUC です。
| データ | 判定基準あり（日本語） | 判定基準なし（日本語） | 判定基準あり（英語） |
|---|---|---|---|
| MIRACL | 0.692 | 0.691 | 0.694 |
| J-RAGBench | 0.818 | 0.836 | 0.838 |
| 合成データ | 0.785 | 0.756 | 0.788 |
どれも差は小さく、判定基準や質問文の言語を変えても、成績はほとんど変わりませんでした。
なお、「判定基準なし」は、厳密には基準が空の状態ではありません。0.1.0 のサーバーは、Noul の質問で判定基準を省くと、英語の既定の基準で補います。true は「the statement holds for this state」、false は「the statement does not hold for this state」です（prompting.py の NOUL_DEFAULT_CRITERIA）。今回の比較は、Jev と同じ日本語の基準と、この汎用の既定の基準との比較です。
確率の当たり具合
strands-decider も「はい」の確率を返しますが、「関連する」に大きく寄りました。MIRACL で 0.5 を境に切ると、関連文書の 95% を拾う一方、「関連」と判定したもののうち本当に関連するのは 26% でした。
確率の当たり具合は、たとえば 0.7 と答えた文書のうち、実際に約 7 割が関連していれば当たっている、という見方です。そのずれを ECE という指標で測りました。0 に近いほど当たっています。MIRACL での ECE は、strands-decider（1 件ずつ）が 0.46、Jev（10 件ずつ）が 0.14 でした。
処理時間
サーバーが返す処理時間は、候補文書 1 件の判定で中央値 80 ms 前後でした。J-RAGBench の長い候補文書では 120 ms 前後です。判定基準のありなしや質問文の言語では、処理時間はほとんど変わりませんでした（MIRACL の中央値で、日本語の基準あり 82.0 ms、基準なし 82.3 ms、英語 81.3 ms）。入力の大半を候補文書が占め、判定基準の分は小さいためと考えられます。1 件ずつ順に送るため、候補文書が約 10 件ある 1 問の判定には 0.8〜1.6 秒かかりました。Jev はネットワーク越しに 10 件ずつまとめて送っていて、送り方が違うので、速さは比べていません。
結果2：候補文書をまとめて渡したとき
候補文書を最大 10 件まとめて 1 回で判定させた結果です（問題ごとの PR-AUC の平均）。
| データ | でたらめに並べた場合 | strands-decider（最大 10 件ずつ） | strands-decider（1 件ずつ） |
|---|---|---|---|
| MIRACL | 0.37 | 0.412 | 0.692 |
| J-RAGBench | 0.36 | 0.496 | 0.818 |
| 合成データ | 0.47 | 0.489 | 0.785 |
まとめて渡すと、でたらめに並べた場合に近い成績になりました（J-RAGBench はやや上）。前回の記事では、Jev は同じ質問の候補文書を 10 件まとめて渡すと、1 件ずつより正確になりました。strands-decider では逆に、まとめると成績が大きく下がります。
Jev との差をどう説明できるか
測定やコードで確かめたことと、推測を分けて書きます。
候補文書をまとめて判定できない
測定で確かめたのは、候補文書をまとめて渡すと、でたらめに近い成績になることです。コードで確かめたのは、strands-decider には state の中の候補文書を candidates[0].text のように指す仕組みがなく、state を JSON の文字列としてそのまま読むことです。
候補文書を 3 件まとめて、2 件目について尋ねた場合に、モデルが実際に読む文章を示します。strands-decider 0.1.0 の prompting.py の build_prompt で生成したものです。
<state>
{
"query": "ソラノハ食品の2025年度第3四半期の営業利益率が前年同期を下回ったのはなぜか。",
"candidates": [
{
"text": "調達部 月次報告：2025年度第3四半期の小麦粉の調達単価は、前年同期比で18%上昇した。…"
},
{
"text": "2022年度第3四半期 決算説明資料：営業利益率は前年同期を1.6ポイント下回った。…"
},
{
"text": "2025年度第3四半期 決算短信（要約）：営業利益 29億円（同 18.3%減）…"
}
]
}
</state>
<question type="noul">
Decide whether the statement is true of the state.
`candidates[1].text` は `query` に答えるための根拠として役に立ちますか。
<options>
1. false — 話題が重なるだけ、参照先が異なる、または根拠となる情報を含まない。
2. true — クエリが指す対象そのものを扱い、回答を裏づける事実・数値・定義を含む。
</options>
</question>
<answer>
リクエストはエラーにならずに受け付けられます。サーバーは state を JSON の文字列にして質問文と並べるだけで、質問文の candidates[1].text も、そのままの文字列でモデルに渡ります。Jev は公式ドキュメント（Primitives）で、質問文にバッククォート付きのパスを書けば、モデルが state のどの部分を判定するか分かると説明しています。strands-decider のドキュメントには、このような書き方の説明がありません。モデルが手がかりにできるのは、質問文の文字列と、state の中の候補文書の並び順だけです。
このため、10 件まとめて渡すと、どの質問がどの候補文書について問われているのかを区別できなかったと考えられます。
前回の記事の合成データでは、Jev は同じ質問の候補文書を 10 件まとめると、1 件ずつより成績が上がりました（問題ごとの PR-AUC で +0.08）。並べて読むことで、どれが必要な事実を持っているかを比べられるためと考えられます。strands-decider ではこの使い方ができないので、1 件ずつ判定するしかありません。
1 件ずつでも差がある
測定で確かめたのは、1 件ずつどうしで比べても Jev が上回ることです。まとめて渡せないことだけでは、差を説明できません。
この差の理由は、モデルの中身を比べられないので確かめられていません。考えられるのは、モデルの大きさと学習データの違いです。strands-decider は 1.9B のモデルです。公開されている学習データの一覧（data/sources.md）は、英語の短い文の分類（ニュースの分野分け、含意の判定など）と複数段の質問応答が中心で、見た範囲では、検索結果の関連度の判定のデータは見当たりませんでした。Jev の学習データとモデルの大きさは公開されていません。
日本語の扱い
strands-decider のドキュメントとモデルカードには、対応する言語の記述がありません。ベースモデルの Qwen3.5-2B-Base は、モデルカードで 201 の言語と方言に対応するとしていますが、日本語が含まれるかは確認できませんでした。学習データも英語が中心です。日本語の候補文書の読み取りが成績を下げている可能性はあります。
ただし、Jev も主な学習言語は英語で、他言語の精度は英語より低いと公式ドキュメントに書かれています。どちらも英語中心のモデルなので、それだけで Jev との差は説明しにくいです。質問文と判定基準を英語にしても成績はほとんど変わらなかったので、言えるのは、質問文の言語は主な原因ではない、というところまでです。候補文書の言語の影響は、今回の測定では切り分けられていません。
入力の上限
今回は送る前に state を区切ったので、切り捨ては起きておらず、上限は今回の成績の原因ではありません。ただし、まとめて渡す使い方を考えるときの制約になります。
各問題の候補文書を 10 件ずつ区切ると、J-RAGBench では 117 個のまとまりになります。そのうち 35 個は、質問を入れる前の state だけで上限の 4,096 トークンを超えました（最大 7,595 トークン）。仮に候補文書を指す仕組みがあっても、候補文書が長いデータでは、10 件をまとめること自体ができません。
検証の再現方法
検証コードは、前回の記事で公開したリポジトリの feat/strands-decider-comparison ブランチにあります。前回の記事の再現手順を変えないよう、strands-decider 用のコードは別のブランチに置いています。strands-decider 用の判定の経路を足し、前回と同じデータと指標で測れるようにしました。
測定結果はリポジトリの results/ に入っていて、strands-decider のサーバーがなくても、次のコマンドで結果1と結果2の表を再現できます。
git clone https://github.com/revsystem/jev-search-and-retrieval.git
cd jev-search-and-retrieval
git switch feat/strands-decider-comparison
uv venv
uv pip install -e ".[dev]"
uv run jev-rag report-judge --results-dir results
サーバーを起動したうえで、測定そのものをやり直すこともできます。--dataset は synthetic、jragbench、miracl の 3 つです。
uv run jev-rag prepare-judge
uv run jev-rag judge --dataset miracl --rankers decider_single,decider_single_plain,decider_single_en,decider_pointwise
検証の制約
- v19 のモデルを strands-decider 0.1.0 で動かした場合だけを測った。新しいバージョンや、より大きなモデルでは結果が変わりうる
- GPU は RTX 3060 Ti の 1 枚で、処理時間はこの環境での値
- 本記事の結果の表は causal-conv1d を入れる前の値。入れたあとの測り直しは、1 件ずつの経路を合成データと MIRACL で行った
- 候補文書はすべて日本語で、英語の候補文書では測っていない
- Jev の測定は前回の記事のもので、strands-decider と同じ日に測り直してはいない
- 1 件ずつどうしの差の理由（モデルの大きさや学習データ）は推測で、確かめていない
- 1 件ずつの経路の PR-AUC は、別々のリクエストで出た確率をそのまま並べて計算した。前回の記事の結果2から、Jev ではこの並べ方で問題ないと読めたが、strands-decider では確かめていない
まとめ
本記事では、AWS がリリースした判定専用モデル「Strands Decider 2B」（strands-decider）を、Jev と同じコーパス、同じ質問文と判定基準で検証しました。
日本語の RAG の rerank に使う判定器としては、今回の条件では Jev に及びませんでした。候補文書をまとめて渡す使い方ができないので、使うなら候補文書を 1 件ずつ判定させることになります。その場合でも、MIRACL と J-RAGBench では Cohere Rerank を下回りました。紛らわしい文書を含む合成データでは、Cohere Rerank を上回りました。
一方で、手元の GPU で動き、API の利用料金がかからない点は strands-decider の利点です。判定 1 回の処理時間も、RTX 3060 Ti で中央値 80 ms 前後でした。