bge-reranker-v2-m3 は、BAAI によるオープンソースの多言語リランキングモデルです。検索システムで最もよくある単一の失敗、つまり ベクトル検索は正しいドキュメントを返したのに、上位のものが実際には質問に答えていない という問題を解決します。
APIYI は標準の /v1/rerank エンドポイントを提供しています。1つの token で、他のすべてのモデルと同じキーを使います。
モデル名:
bge-reranker-v2-m3 (case-sensitive). エンドポイント: POST /v1/rerank.
default と svip のグループで利用できます。
このページのすべての数値は、2026-07-30 (UTC+8) における APIYI のテスト結果で、60+ 件のテストケースに基づいています。それが何か、そしてどんなときに使うか
reranker は cross-encoder です。クエリと各候補ドキュメントを連結し、そのペアをモデルにそのまま通して、関連度スコアを直接出力します。 これは embedding モデルとは本質的に異なります:
したがって、ベクトル検索の代わりになるわけではありません。その後ろに置かれる第2段階です。
具体的な比較
候補ドキュメントは同じ10件、クエリも同じ(「My API requests keep returning 429 — how do I fix it?」)、変わるのはランキング手法だけです:
ベクトル検索では、HTTP 4xx の用語集と「4月29日」に触れたメンテナンス告知が上位3件に入りました。どちらも話題としては近く、クエリと語彙も共有していますが、どちらも質問には答えていません。reranker はその両方を下げました。
それが価値のすべてです。「同じ話題」と「実際に質問へ答えている」を分けることです。
モデル情報
料金
無視できるほど安いです。 100件の候補を再ランク付けするコスト(約2,700 tokens)は、およそ $0.000027 です。
100万回実行しても $27 です。RAG システムでは、再ランク付けがコストのボトルネックになることはほとんどありません —
制約になるのはレイテンシであって、お金ではありません。候補セットのサイズは、支出ではなくレイテンシに合わせて調整してください。
prompt_tokens= クエリ(1回分としてカウント)に加えて、すべての候補ドキュメントです。実際には厳密に線形で、≈ 26.9 × doc count + 7です(当てはめ誤差 < 0.31%)ので、クライアント側で予測できますtotal_tokensのほうが大きく、その差は候補数が増えるほど広がります。これは、クエリがクエリ-ドキュメントのペアごとに1回ずつカウントされることと一致しますinput_tokens/output_tokensはこのチャネルでは 常に 0 です。使わないでくださいtop_nとreturn_documentsは usage を変えません — どちらの場合でも各候補はスコアリングされます
最小限の呼び出し
リクエストパラメータ
測定済み機能マトリクス
知っておくべき3つのこと
1. relevance_score は、クエリ間で比較できる信頼度ではありません
1. relevance_score は、クエリ間で比較できる信頼度ではありません
つい「0.5で単純にフィルタする」と考えがちですが、計測データを見ると、それではうまくいきません:
0.5 のしきい値では、正しいクロスリンガル結果をすべて捨ててしまい、非中国語では2位のヒットの大半も
捨てることになります。一方で、「Apple Inc. FY2024 revenue.」というクエリに対して、
リンゴ栽培の価格に関するドキュメントを受け入れてしまいます。代わりにどうするか: これは信頼度ではなく、ソートキーとして扱ってください。どうしてもフィルタするなら、
相対しきい値(
score >= top1_score × 0.3)を使うか、Top-N を取るだけにして、自分の
ラベル付きデータでキャリブレーションしてください。2. 否定はこのモデルの明確な弱点です
2. 否定はこのモデルの明確な弱点です
クエリ: 「冬に訪れるのに良い観光地はどこですか?」 2件の候補は明確に逆のことを言っています:
モデルは「冬 + 観光地 + 旅行」というトピックに一致しただけで、否定を処理しませんでした。
nDCG@3 は 0.47 しかありませんでした。対策: 否定、除外、条件文を含むクエリ(「グルテンフリー」、「北京以外ならどこでも」、「未成年には適用外」など)では、リランキング後に LLM による検証パスを追加してください — Top-N をそのままユーザーに渡してはいけません。
3. 長いドキュメントは関連度を薄め、ノイズも増やします
3. 長いドキュメントは関連度を薄め、ノイズも増やします
同じ一致文に、無関係なダミー文をさまざまな量だけ追加した場合:
さらに、長さは無関係なドキュメントも膨らませます: 同じ非一致ドキュメントは、短い場合は 0.029 でしたが、
付け足すと 0.121 になり、4倍高くなりました。対策: リランキング前に長いドキュメントを 200〜500 文字にチャンク化し、最もスコアの高い
チャンクをそのドキュメントのスコアとして採用してください。チャンク化は、このモデルで最も効果の大きい
前処理です。
既知の問題
1分あたりの検索回数
計測された≈26.9 tokens/document を基に TPM 20,000 に照らすと:
これにより、1 回のリクエストに候補を載せすぎられない理由も説明できます: 1000 candidates は
26,867 token で、1 回のリクエストだけで 1 分間の予算全体の 134% を消費するため、429 は確実です。2000 candidates では 269% になります。
クォータ拡大は進行中です。 上記の TPM 20,000 は上流の初期割り当てであり、
APIYI はすでに引き上げを申請しています。ワークロードが表の許容量を超える場合は、
現在の数値に合わせて設計を縮小するのではなく、APIYI サポートに連絡して上流のクォータを見直してもらってください。
FAQ
ベクトル検索またはリランキングのどちらか一方だけを使えますか?
ベクトル検索またはリランキングのどちらか一方だけを使えますか?
ベクトル検索のみ: 使えますが、Top-N の精度はかなり低下します(計測した nDCG@3 は
1.00 から 0.53 に低下)。リランキングのみ: いいえ。 ベクトル出力がなく、候補セットが必要です。数百万件の
文書を1件ずつスコアリングするのは、実用的でもコスト的にも現実的ではありません。標準的な形は2段階です。ベクトル検索/BM25 で 50〜100 件をリコールし → 3〜5 件まで
リランキング → LLM に渡します。
何件の候補をリコールすべきですか?
何件の候補をリコールすべきですか?
計測したレイテンシは候補数にほぼ線形に比例します(短い文書の場合)。10 ≈ 2 s、
100 ≈ 4 s、500 ≈ 15 s、1000 ≈ 33 s です。50〜100 が最適です。 20 未満では、リランカーが修正すべき誤順位があまり残りません。
200 を超えると、レイテンシが対話性を損ない始める一方で、リコールリストの末尾に答えが
含まれていることはめったにありません。予算も重要です。100 件の候補は約 1,325 tokens なので、TPM 20,000 では 1 分あたり
約 15 回しか検索できません。候補数を2倍にするとスループットは半減します。
候補数は品質だけでなく、容量の判断でもあります。
Cohere または Jina の SDK をそのまま向けられますか?
Cohere または Jina の SDK をそのまま向けられますか?
cohere SDK v2 はそのままでは動作しません: /v2/rerank を対象にしており、JSON ではなく
HTML のホームページが返るため、SDK はパースエラーを出します。パラメータ名(query / documents / top_n / return_documents)は Cohere Rerank
v1 と一致しますが、documents は 文字列配列しか受け付けず([{"text": "..."}] は 400 を返します)、
レスポンスに id / meta フィールドはありません。HTTP 呼び出しを自分でラップするのが
最も簡単です — RAG tuning in practice には、すぐ使える
LangChain と LlamaIndex のアダプターがあります。動作確認済みクライアント: 素の requests POST ✅ と、openai SDK のエスケープハッチ
client.post("/rerank", ...) ✅。結果をキャッシュできますか?
結果をキャッシュできますか?
はい、とても安定しています。同一リクエストを10回繰り返すとビット単位で完全一致します(ずれはゼロ)。
約 3.7e-4 のずれは、候補の順序をシャッフルしたとき(bf16 バッチ処理のジッター)にのみ
現れ、順序付けには影響しません。キャッシュのキーは
normalised query + ordered hash of document contents にしてください。順序がそのわずかなずれを生むため、
relevance_score 自体を冪等性キーとして扱わないでください。8192 tokens を超えるとどうなりますか?
8192 tokens を超えるとどうなりますか?
This model's maximum context length is 8192 tokens 付きの 400 が返ります。これは暗黙に切り詰められることはありません。
この上限はリクエスト全体ではなく、クエリと文書のペアごとに適用されます。たとえば、
400 文書 × 1000 文字(合計 330K tokens)の1件のリクエストでも通常どおり返ります。