0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@revsystem(Tsuyoshi Yamasaki)

OpenAI の Decisions API を、RAG の rerank の判定器として Jev 1.14 と比べた

0
Posted at

はじめに

前々回の記事では、TypeSafe の Jev を RAG の rerank に使い、Cohere Rerank と関連文書を見分ける精度を比べました。rerank は、検索で集めた候補文書を、質問への関連度で並べ替える工程です。前回の記事では、AWS がリリースした判定専用モデル strands-decider を同じ条件で検証しました。

その後、OpenAI が Decisions API を public beta として公開しました。文章ではなく、「条件が成り立つ確率」「選択肢」「段階の評価」を、型の決まった答えで返す API です。Jev も同じ種類の答えを返します。また、2026 年 10 月 14 日には Jev の新しいバージョン 1.14 がリリースされています。

そこで、前々回と同じコーパス、同じ「関連する」の定義、同じ指標で、Decisions API と Jev 1.14 を同じ日に測って比べました。

結論

  • Decisions API に候補文書を 10 件まとめて渡すと、候補の並び順を逆にしただけで確率が大きく動いた。本測定では、候補文書を 1 件ずつ判定させる形だけを使った
  • 1 件ずつ判定させる同じ形で比べると、同じ確率の候補を 4 段階の評価で並べ分ける限り、1 つの質問の候補文書を並べ替える力は、3 種類のデータすべてで Jev 1.14 と差がはっきりしなかった
  • 1 つのしきい値ですべての質問の候補文書をふるい分ける使い方を表す全問まとめた PR-AUC では、MIRACL 日本語版と J-RAGBench で Decisions API が Jev を下回った。J-RAGBench では、Decisions API は関連文書の 3 割に確率 0.00 を付けた
  • J-RAGBench と合成データでは、Jev は 10 件まとめて渡す方が成績がよく、この形の Jev と比べると、並べ替える力でも Decisions API が下回った
  • 料金表の単価で計算すると、1 件ずつの判定の費用は Decisions API が Jev の約 2 倍だった

参考情報

検証内容

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

  1. Decisions API に候補文書をまとめて渡したとき、確率が候補文書の中身で決まるか、並び順で動くか

  2. Jev 1.14 と同じ条件で、Decisions API は 1 つの質問の候補文書をどれだけ正しく並べ替えられるか

  3. 1 つのしきい値ですべての質問をふるい分ける使い方と費用で、どれだけ差があるか

1 は「本測定の前の確認」、2 は「結果1」、3 は「結果2」と「費用と処理時間」で扱います。

Decisions API の仕組み

Decisions API では、POST /v1/decisions に、判定させる材料（input）と尋ねる質問の一覧（questions）を送ります。使えるモデルは gpt-6-luna だけです。質問の型は 3 つあります。

型 答え
predicate 条件が成り立つ確率（0〜1）
choice 渡した選択肢のうちの 1 つと、選択肢ごとの確率
score 渡した段階（levels）の番号を、確率で重みづけた平均

Jev の Noul、Choice、Score とほぼ同じ構成ですが、細かいところで違います。

項目 Decisions API Jev 1.14
モデル gpt-6-luna（バージョン付きの ID はない） jev-1.14.0（jev-latest は確認時点でまだ jev-1.13.0 を指していた）
判定させる材料 文字列、または文章と画像を含むメッセージ state（文字列、JSON のオブジェクト、文字列の配列）
判定基準の渡し方 predicate には専用の欄がなく、質問文（instructions）に書く。score の段階と choice の選択肢には説明（description）を書ける Noul の criteria に「はい」と「いいえ」の定義を渡せる
材料の一部を指す書き方（candidates[0].text など） 説明がない 質問文にパスを書けば、モデルが state のどの部分を判定するか分かると公式ドキュメントにある
答えない場合 質問ごとに refusal（答えの拒否）が返りうる 確認した範囲のドキュメントには記述がない
料金（入力 100 万トークンあたり） 0.10 ドル。出力とキャッシュには課金なし 0.042 ドル。出力には課金なし

Decisions API の料金は、Decisions のガイドに書かれた /v1/decisions の料金です。gpt-6-luna のモデルページには出力の単価も載っていますが、これは Responses API など、ほかのエンドポイントで使うときの単価です。ガイドには長い入力に料金の乗数がかかるとも書かれています。モデルページの条件（1 リクエストの入力が 27 万 2 千トークンを超えた場合）と同じだと考えられ、今回のリクエストは数百〜数千トークンでした。料金とモデルの情報は、2026 年 10 月 19 日に公式ページで確かめた値です。

制限付きの API キーで呼ぶと、検証中に 403 The API key requires the api.decisions.write permission. を受け取りました。OpenAI のダッシュボードで、API キーに Model capabilities の Decisions（Write）の権限を付ける必要があります。

比べ方

データ、指標、「関連する」の定義（判定基準の文）は、前々回の記事と同じです。質問文は、それぞれの API の形に合わせました。

使ったデータ

質問と候補文書の 1 組を、以下「組」と呼びます。データは 3 つです。

  • MIRACL 日本語版: Wikipedia の検索結果に、人が関連の有無を付けた公開データ（860 問、8,354 組、関連文書の割合 21%）
  • J-RAGBench: 架空の企業を舞台にした業務寄りの質問（60 問、709 組、関連文書の割合 21%）
  • 合成データ: 同じ会社・同じ話題で、年度や部署だけが違う紛らわしい文書を含む業務の質問（60 問、600 組、関連文書の割合 32%）

用語

本記事で使う指標と用語です。どれも、正解（関連する／しない）が付いたデータで判定器の成績を測るためのものです。

用語 意味
PR-AUC 関連文書を上位に、無関係な文書を下位に並べられているほど 1 に近づく 0〜1 の値。でたらめに並べたときの値は、全問まとめた PR-AUC では関連文書の割合に近くなる。問題ごとの PR-AUC では、候補が 10 件前後と少ないぶん高めに出るので、表の「でたらめに並べた場合」の値と比べる
問題ごとの PR-AUC 質問ごとに候補文書を並べ替えて PR-AUC を求め、全質問で平均した値。rerank に必要な「1 つの質問の候補文書を並べ替える力」を表す。候補文書がすべて関連文書の質問は並べ替えようがないので除く（MIRACL では 63 問を除いた 797 問）
全問まとめた PR-AUC すべての質問の組を、確率の高い順に 1 本に並べて求めた PR-AUC。1 つのしきい値ですべての質問をふるい分けたときに、関連文書を多く残せるかを表す
95% 区間 差がどの程度確かかの目安。質問を重複を許して選び直し、両方の経路を同じ質問の組で計算し直して差を求める。この操作を 2,000 回繰り返し、差の分布の真ん中 95% の範囲を示す。区間が 0 をまたがなければ、質問の選び方が変わっても差の向きは変わりにくい
ECE 確率の当たり具合のずれ。0 に近いほど当たっている。たとえば 0.7 と答えた文書のうち、実際に約 7 割が関連していれば当たっている。求め方は結果2の「ECE の求め方」で例を示す

判定させた経路

本記事では、サービスを指すときは「Decisions API」、測った経路を指すときは「Decisions（1 件ずつ）」のように書きます。

経路 内容
Decisions（1 件ずつ） 候補文書 1 件ごとに 1 リクエスト。関連の確率（predicate）と 4 段階の評価（score）を尋ねる
Decisions（10 件ずつ） 候補文書を 10 件まとめて 1 リクエストにし、candidates[0].text のように 1 件ずつ尋ねる
Jev（1 件ずつ） Decisions（1 件ずつ）と同じ形。前々回の記事の結果2にある「1 件ずつ」は、候補文書の配列に 1 件だけ入れて関連の確率だけを尋ねる別の形
Jev（10 件ずつ） 前々回の記事の主な経路。候補文書を 10 件まとめて 1 つの state に入れる

Decisions（10 件ずつ）は、後述の「本測定の前の確認」で外したので、本測定では測っていません。

実際に送ったリクエストを、合成データの 1 問で示します。候補文書の本文は先頭だけ残して省略しています。

Decisions（1 件ずつ）は、次の形です。Jev の state と同じ JSON を文字列にして input に入れ、判定基準は質問文の末尾に足しました。levels の 4 つの文は、Jev の Score に渡しているものと同じです。

decisions-single-request.json
{
  "model": "gpt-6-luna",
  "input": "{\"query\": \"ソラノハ食品の2025年度第3四半期の営業利益率が前年同期を下回ったのはなぜか。\", \"candidate\": \"ソラノハ食品 調達部 月次報告（2025年12月）\\n2025年度第3四半期の小麦粉の調達単価は、前年同期比で18%上昇した。…\"}",
  "questions": [
    {
      "type": "predicate",
      "name": "relevance",
      "instructions": "`candidate` は `query` に答えるための根拠として役に立ちますか。\n判定基準: はい（true）= クエリが指す対象そのものを扱い、回答を裏づける事実・数値・定義を含む。いいえ（false）= 話題が重なるだけ、参照先が異なる、または根拠となる情報を含まない。"
    },
    {
      "type": "score",
      "name": "grade",
      "instructions": "`candidate` が `query` の根拠としてどの程度有用かを判定してください。",
      "levels": [
        {"label": "無関係。クエリの主題とも参照先とも一致しない。"},
        {"label": "話題は重なるが、クエリへの回答根拠にはならない。"},
        {"label": "部分的な根拠を含む。回答の一部を裏づけるが単独では不十分。"},
        {"label": "直接的な根拠を含む。この記述だけでクエリに答えられる。"}
      ]
    }
  ]
}

Jev（1 件ずつ）は、次の形です。候補文書が 10 件ある質問なら、candidate だけを替えて 10 回送ります。query と 2 問の質問は毎回同じです。判定基準は Noul の criteria に、4 段階の文は Score の criteria に渡します。

jev-single-request.json
{
  "model": "jev-1.14.0",
  "state": {
    "query": "ソラノハ食品の2025年度第3四半期の営業利益率が前年同期を下回ったのはなぜか。",
    "candidate": "ソラノハ食品 調達部 月次報告（2025年12月）\n2025年度第3四半期の小麦粉の調達単価は、前年同期比で18%上昇した。…"
  },
  "questions": {
    "relevance": {
      "type": "noul",
      "instructions": "`candidate` は `query` に答えるための根拠として役に立ちますか。",
      "criteria": {
        "true": "クエリが指す対象そのものを扱い、回答を裏づける事実・数値・定義を含む。",
        "false": "話題が重なるだけ、参照先が異なる、または根拠となる情報を含まない。"
      }
    },
    "grade": {
      "type": "score",
      "instructions": "`candidate` が `query` の根拠としてどの程度有用かを判定してください。",
      "criteria": [
        "無関係。クエリの主題とも参照先とも一致しない。",
        "話題は重なるが、クエリへの回答根拠にはならない。",
        "部分的な根拠を含む。回答の一部を裏づけるが単独では不十分。",
        "直接的な根拠を含む。この記述だけでクエリに答えられる。"
      ]
    }
  }
}

Jev（10 件ずつ）は、1 回のリクエストで済みます。候補文書 10 件を state の candidates に入れ、関連の質問を 10 問並べて、candidates[0].text のように位置で候補文書を指します。質問の名前は文書の ID です。3 問目以降は、名前と candidates[N] の番号だけが違う同じ形なので省略しています。4 段階の評価は尋ねていません。

jev-batched-request.json
{
  "model": "jev-1.14.0",
  "state": {
    "query": "ソラノハ食品の2025年度第3四半期の営業利益率が前年同期を下回ったのはなぜか。",
    "candidates": [
      {"text": "ソラノハ食品 2025年度第3四半期 決算短信（要約） 売上…"},
      {"text": "経理部 新任者研修資料「営業利益率の見方」 営業利益率は、売…"},
      {"text": "ソラノハ食品 調達部 月次報告（2025年12月） 2025…"},
      {"text": "ソラノハ食品 経営企画部 競合分析メモ ハナツグ製菓の202…"},
      {"text": "ソラノハ食品 2022年度第3四半期 決算説明資料より 営業…"},
      {"text": "ソラノハ食品 営業本部 評価制度FAQ（2025年度第3四半…"},
      {"text": "ソラノハ食品 2025年度第2四半期 決算説明資料より 営業…"},
      {"text": "ソラノハ食品 取締役会議事録（2025年9月定例） 議題3 …"},
      {"text": "ソラノハ食品 経理部 四半期決算メモ（2025年度第3四半期…"},
      {"text": "ソラノハ食品 2023年度第3四半期 決算説明資料より 営業…"}
    ]
  },
  "questions": {
    "a-011-d04": {
      "type": "noul",
      "instructions": "`candidates[0].text` は `query` に答えるための根拠として役に立ちますか。",
      "criteria": {
        "true": "クエリが指す対象そのものを扱い、回答を裏づける事実・数値・定義を含む。",
        "false": "話題が重なるだけ、参照先が異なる、または根拠となる情報を含まない。"
      }
    },
    "a-011-d03": {
      "type": "noul",
      "instructions": "`candidates[1].text` は `query` に答えるための根拠として役に立ちますか。",
      "criteria": {
        "true": "クエリが指す対象そのものを扱い、回答を裏づける事実・数値・定義を含む。",
        "false": "話題が重なるだけ、参照先が異なる、または根拠となる情報を含まない。"
      }
    },
    …
  }
}

Decisions API の答えは answers の配列で返り、質問に付けた name で対応づけます。Jev の答えは、質問の名前をキーにしたオブジェクトで返ります。

同点の扱い

1 件ずつの経路は、関連の確率の高い順に候補文書を並べ、確率が同じ候補は 4 段階の評価で並べ分けます。Jev も Decisions API も、応答の確率は小数 2 桁でした（検証コードでは丸めていません）。Decisions API は確率をちょうど 0.00 にすることが多く、その割合は MIRACL で全組の 42%、J-RAGBench で 82%、合成データで 44% でした。Jev では 1 件もありませんでした。

そこで、結果1の「並べ替える力」は、経路が実際に並べた順序（確率、同じなら 4 段階の評価）で計算しました。確率だけで並べ、同じ確率の候補を区別しない場合の問題ごとの PR-AUC は、Decisions（1 件ずつ）が MIRACL 0.799、J-RAGBench 0.777、合成データ 0.826、Jev（1 件ずつ）が 0.860、0.907、0.847 です。predicate の確率だけで並べ替えると、Decisions API は同じ確率の候補を並べ分けられません。結果2のしきい値の指標は、しきい値を確率にかけるので、確率だけで計算しました。

送り方

Decisions API と Jev は、どちらも 8 並列で送りました。一時的な障害で失敗する条件をそろえるため、試行はどちらも 3 回まで、タイムアウトは 60 秒にしました。Decisions API は Python SDK の openai 3.35.1 から呼び、max_retries=2 で 3 回までにしています。本測定では、すべての経路で、refusal、欠けた答え、失敗した問題は 0 件でした。

本測定の前の確認

前回の記事の strands-decider は、候補文書を 10 件まとめて渡すと、でたらめに近い成績になりました（J-RAGBench だけはやや上回った）。candidates[1].text のようなパスで指した候補を区別できなかったと考えられます。Decisions API のドキュメントにも、パスで材料の一部を指す書き方の説明はありません。そこで本測定の前に、合成データの 5 問（50 組）について、候補文書をそのままの順と逆順の 2 通りで送り、文書ごとの確率を比べました。

確率が候補文書の中身で決まるなら、順序を逆にしても、同じ文書の確率はほぼ変わらないはずです。1 件ずつの経路は、順序を逆にしても入力が同じなので、2 回の差は実行ごとの揺れだけを表します。

経路 2 回の確率の差（中央値） 最も大きく動いた組の差 0.2 より大きく動いた組
Decisions（10 件ずつ） 0.03 0.87 16 / 50
Decisions（1 件ずつ） 0.00 0.00 0 / 50
Jev（10 件ずつ） 0.03 0.50 2 / 50
Jev（1 件ずつ） 0.01 0.09 0 / 50

Decisions（1 件ずつ）は、2 回とも同じ確率を返しました。Decisions（10 件ずつ）は、半分の組で 2 回とも確率が 0.05 未満のままほとんど動かず、差の中央値は小さくなりました。一方で、順序を逆にしただけで 3 組に 1 組の確率が大きく動きました。たとえば、ある無関係な文書は 0.87 から 0.00 に、ある関連文書は 0.77 から 0.05 になりました。並べ替えに使う判定器で、関連と無関係が入れ替わるほど確率が動くのは問題です。

ただし、確認は 5 問だけで、そのままの順での問題ごとの PR-AUC は 0.918 と、1 件ずつの 0.908 と同程度でした。言えるのは、順序を変えると確率が大きく動くので、まとめて渡したときの成績は安定しない、というところまでです。この結果から、Decisions は 1 件ずつの経路だけを本測定しました。

Jev（10 件ずつ）は、0.2 より大きく動いたのが 2 組だけで、Jev 1.14 でもまとめて渡す使い方が成り立ちます。

結果1：候補文書を並べ替える力

問題ごとの PR-AUC です。

データ でたらめに並べた場合 Jev（10 件ずつ） Jev（1 件ずつ） Decisions（1 件ずつ）
MIRACL（797 問） 0.37 0.866 0.870 0.859
J-RAGBench 0.36 0.938 0.920 0.911
合成データ 0.47 0.952 0.849 0.845

Decisions から Jev を引いた差と、その 95% 区間です。渡し方が同じ「1 件ずつ」どうしの差と、Jev の主な経路（10 件ずつ）との差を並べます。

データ Decisions（1 件ずつ）− Jev（1 件ずつ） Decisions（1 件ずつ）− Jev（10 件ずつ）
MIRACL −0.011（−0.023〜+0.001） −0.007（−0.020〜+0.005）
J-RAGBench −0.009（−0.038〜+0.018） −0.027（−0.054〜−0.005）
合成データ −0.004（−0.034〜+0.027） −0.107（−0.146〜−0.070）

1 件ずつどうしでは、3 つのデータすべてで区間が 0 をまたぎ、差ははっきりしませんでした。Jev（10 件ずつ）と比べると、J-RAGBench と合成データでは区間の両端がマイナスで、Decisions が下回りました。合成データの差の大部分は、Jev が 10 件まとめて渡すと成績が上がることから来ています。

上位の並びで見ると、次のようになります。質問ごとに候補文書を経路の並べた順にし、1 位が関連文書だった質問と、上位 3 件に関連文書が 1 件以上入っていた質問の割合を数えました。経路の並べ方でも同じ値になった候補は、受け取った順のまま数えています。

データ 並べ方 1 位が関連文書 上位 3 件に関連文書を含む
MIRACL でたらめに並べた場合 21% 49%
MIRACL Jev（10 件ずつ） 84% 98%
MIRACL Jev（1 件ずつ） 86% 98%
MIRACL Decisions（1 件ずつ） 82% 97%
J-RAGBench でたらめに並べた場合 21% 51%
J-RAGBench Jev（10 件ずつ） 97% 98%
J-RAGBench Jev（1 件ずつ） 95% 97%
J-RAGBench Decisions（1 件ずつ） 95% 98%
合成データ でたらめに並べた場合 32% 74%
合成データ Jev（10 件ずつ） 97% 100%
合成データ Jev（1 件ずつ） 78% 100%
合成データ Decisions（1 件ずつ） 77% 100%

結果2：全質問に 1 つのしきい値を使ったとき

rerank では、質問ごとに並べ替えられれば十分です。一方、「確率 0.5 以上だけを回答の材料にする」のように、すべての質問に同じしきい値を使う場合は、確率の意味が質問をまたいでそろっている必要があります。

全問まとめた PR-AUC と ECE を示します。あわせて、関連文書の 9 割が残るようにしきい値を決めて切ったとき、残った文書のうち関連する割合も示します。

データ 経路 全問まとめた PR-AUC 9 割を残したときの関連の割合 ECE
MIRACL でたらめに並べた場合 0.21 21.4% -
MIRACL Jev（10 件ずつ） 0.76 59.4% 0.156
MIRACL Jev（1 件ずつ） 0.75 57.9% 0.161
MIRACL Decisions（1 件ずつ） 0.68 56.0% 0.133
J-RAGBench でたらめに並べた場合 0.21 20.7% -
J-RAGBench Jev（10 件ずつ） 0.87 62.0% 0.051
J-RAGBench Jev（1 件ずつ） 0.78 53.5% 0.066
J-RAGBench Decisions（1 件ずつ） 0.71 20.7% 0.112
合成データ でたらめに並べた場合 0.32 32.2% -
合成データ Jev（10 件ずつ） 0.92 84.1% 0.055
合成データ Jev（1 件ずつ） 0.74 65.9% 0.085
合成データ Decisions（1 件ずつ） 0.73 53.9% 0.157

全問まとめた PR-AUC と 95% 区間で、Decisions（1 件ずつ）− Jev（1 件ずつ）は、MIRACL で −0.07（−0.08〜−0.05）、J-RAGBench で −0.07（−0.14〜−0.02）、合成データで −0.01（−0.05〜+0.02）でした。1 つの質問の中での並べ替えには差がなくても、質問をまたいで確率を比べる使い方では、MIRACL と J-RAGBench で差が出ました。

J-RAGBench の Decisions（1 件ずつ）は、関連文書 147 件のうち 45 件に、確率 0.00 を付けました。関連文書の 9 割を残すには、しきい値を 0.00 まで下げてすべての文書を残すしかなく、関連の割合は、でたらめに並べた場合と同じ 20.7% になりました。0.5 を境に切ると、関連文書のうち残ったのは 40% です。Jev は、1 件ずつで 48%、10 件ずつで 66% でした。

ECE は、MIRACL でだけ、Decisions の方が Jev のどちらの経路よりも小さくなりました。

ECE の求め方

ECE は、次の手順で求めます。

  1. 全組を確率の小さい順に並べ、件数が等しくなるように 10 の区間に分ける
  2. 区間ごとに、答えた確率の平均と、実際に関連していた組の割合を出す
  3. 区間ごとに、その 2 つの差の大きさ（ずれ）を出し、10 区間で平均する

合成データ（600 組、1 区間 60 組）での実際の値です。

区間 Jev（10 件ずつ）の確率の平均 実際に関連していた割合 ずれ Decisions（1 件ずつ）の確率の平均 実際に関連していた割合 ずれ
1 0.023 0.000 0.023 0.000 0.033 0.033
2 0.037 0.033 0.003 0.000 0.017 0.017
3 0.056 0.000 0.056 0.000 0.100 0.100
4 0.082 0.017 0.066 0.000 0.017 0.017
5 0.119 0.000 0.119 0.006 0.183 0.177
6 0.203 0.133 0.069 0.028 0.233 0.206
7 0.412 0.400 0.012 0.100 0.367 0.267
8 0.677 0.750 0.073 0.263 0.683 0.420
9 0.824 0.900 0.076 0.595 0.767 0.172
10 0.933 0.983 0.050 0.973 0.817 0.157
ECE（ずれの平均） 0.055 0.157

Jev は、どの区間でもずれが 0.12 以下でした。Decisions は、区間 8 で、平均 0.263 の確率を付けた組のうち実際には 68% が関連していて、確率を低く付けすぎています。区間 10 では反対に、平均 0.973 と答えた組のうち、関連していたのは 82% でした。

区間を件数で等しく分けるのは、確率が 0 付近に集中するためです。0〜0.1、0.1〜0.2 のように幅で分けると、多くの区間がほぼ空になります。Decisions は確率 0.00 の組が多いので、区間 1〜4 はどれも平均 0.000 になりました。

費用と処理時間

各経路が使った入力トークンと、「Decisions API の仕組み」の表の単価から計算した費用です。

データ 経路 入力トークン 費用（ドル）
MIRACL Jev（10 件ずつ） 3,896,652 0.164
MIRACL Jev（1 件ずつ） 7,325,018 0.308
MIRACL Decisions（1 件ずつ） 5,976,555 0.598
J-RAGBench Jev（10 件ずつ） 552,982 0.023
J-RAGBench Jev（1 件ずつ） 855,195 0.036
J-RAGBench Decisions（1 件ずつ） 701,465 0.070
合成データ Jev（10 件ずつ） 208,811 0.009
合成データ Jev（1 件ずつ） 480,386 0.020
合成データ Decisions（1 件ずつ） 397,627 0.040

同じ内容を送っても、入力トークンは Decisions API の方が 2 割ほど少なく数えられました（Jev には JSON のオブジェクト、Decisions API には JSON を文字列にしたものを送っています）。それでも単価が 2 倍以上なので、1 件ずつの判定の費用は Decisions API が Jev の約 2 倍になります。

Jev は 10 件ずつの方が、入力トークンが 1 件ずつの 43〜65% で済みました。合成データの 1 問（候補文書 10 件）で送り方を変えて測ると、10 件ずつの 1 リクエストは 3,537 トークン、1 件ずつの 10 リクエストは合わせて 7,944 トークンでした。差の主な理由は 2 つです。1 件ずつの経路は 4 段階の評価の質問も尋ねていて、この 1 問で 173 トークン増えます。また、中身がほぼ空のリクエストでも 271 トークン数えられたので、リクエストごとに一定の分が加わると考えられます。1 件ずつだとこれが 10 回分になります。

処理時間は、1 件ずつの経路を 8 並列で送った MIRACL の 8,354 組で、Jev が 457 秒、Decisions API が 440 秒でした。並列度、通信環境、時間帯で変わるので、速さの優劣は結論にしていません。

検証の再現方法

検証コードは、前々回の記事で公開したリポジトリの feat/openai-decisions-comparison ブランチにあります。前々回の記事の再現手順を変えないよう、別のブランチに置いています。

測定結果はリポジトリの results/decisions/ に入っていて、API キーがなくても、次のコマンドで結果1、結果2、費用の表の値を再現できます（1 分ほどかかります）。「本測定の前の確認」の値は、同じディレクトリの probe-order.json にあります。本文の補足の値（確率が 0.00 の割合など）は、保存したスコアから計算しました。

git clone https://github.com/revsystem/jev-search-and-retrieval.git
cd jev-search-and-retrieval
git switch feat/openai-decisions-comparison
uv sync --extra dev
uv run jev-rag report-judge --results-dir results/decisions

確認と測定そのものをやり直すには、.env.example を .env に写し、TYPESAFE_API_KEY と OPENAI_API_KEY を書いて、JEV_DIRECT_MODEL=jev-1.14.0 にします（JEV_TRANSPORT=direct は .env.example に書かれています）。--dataset は synthetic、jragbench、miracl の 3 つです。

cp .env.example .env
uv run jev-rag prepare-judge
uv run jev-rag probe-order
uv run jev-rag judge --dataset miracl \
  --rankers jev_pointwise,jev_pointwise_plain,jev_crossencode,decisions_crossencode \
  --out out/decisions/judge-miracl.json

検証の制約

  • 2026 年 10 月 19〜20 日の gpt-6-luna と jev-1.14.0 で測った。Decisions API は public beta で、GA（一般提供）までに結果が変わりうる
  • Decisions API の predicate には判定基準の欄がないので、判定基準は質問文の末尾に書いた。Jev の criteria と同じ渡し方ではない
  • Decisions の 10 件ずつの経路は、本測定の前の確認で外したので、まとめて渡したときの成績は測っていない。確認は合成データの 5 問だけで行った
  • 1 件ずつの 2 経路は、4 段階の評価も保存するために測り直した。Decisions API は 1 回目と同じ確率を返した。Jev の確率は実行ごとに少し揺れ、結果2の Jev（1 件ずつ）の値も 1 回目とわずかに違う
  • 経路の並べ方でも同じ値になった候補は、上位 1 件・3 件の割合を数えるときは受け取った順に並べ、PR-AUC では同点のまま扱った。MIRACL の 797 問のうち、1 位が同点だった問題は、Jev（10 件ずつ）で 104 問、Jev（1 件ずつ）で 66 問、Decisions（1 件ずつ）で 50 問だった。Jev（10 件ずつ）は 4 段階の評価を尋ねていないので、確率が同じならそのまま受け取った順になる
  • 1 件ずつの経路は、別々のリクエストで出た値をそのまま並べて計算した（結果1は確率と 4 段階の評価、結果2は確率）。Decisions API で、別々のリクエストの値どうしを比べてよいかは確かめていない
  • 候補文書はすべて日本語。Decisions のガイドと gpt-6-luna のモデルページには、対応言語や日本語の精度の記述が見当たらなかった。Jev は、主な学習言語が英語で、他言語の精度は英語より低いと公式ドキュメントに書かれている
  • 費用は、使った入力トークンに料金表の単価を掛けた値で、請求額では確かめていない
  • トークンの内訳は、合成データの 1 問で測った値

まとめ

本記事では、OpenAI が public beta として公開した Decisions API を、Jev 1.14 と同じコーパス、同じ「関連する」の定義で、RAG の rerank の判定器として比べました。

候補文書を 1 件ずつ判定させ、同じ確率の候補を 4 段階の評価で並べ分ければ、1 つの質問の候補文書を並べ替える力に、Jev との差ははっきりしませんでした。確率が 0.00 に偏るので、この並べ分けが要ります。一方、全問まとめた PR-AUC では、MIRACL と J-RAGBench で Jev を下回りました。

候補文書をまとめて渡すと確率が並び順で動いたので、使うなら 1 件ずつ判定させることになります。その場合の費用は Jev の約 2 倍で、Jev は 10 件まとめて渡せばさらに安く、J-RAGBench と合成データでは成績も上がりました。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?