Skip to main content
bge-reranker-v2-m3 は、BAAI によるオープンソースの多言語リランキングモデルです。検索システムで最もよくある単一の失敗、つまり ベクトル検索は正しいドキュメントを返したのに、上位のものが実際には質問に答えていない という問題を解決します。 APIYI は標準の /v1/rerank エンドポイントを提供しています。1つの token で、他のすべてのモデルと同じキーを使います。
モデル名: bge-reranker-v2-m3 (case-sensitive). エンドポイント: POST /v1/rerank. defaultsvip のグループで利用できます。 このページのすべての数値は、2026-07-30 (UTC+8) における APIYI のテスト結果で、60+ 件のテストケースに基づいています。

それが何か、そしてどんなときに使うか

reranker は cross-encoder です。クエリと各候補ドキュメントを連結し、そのペアをモデルにそのまま通して、関連度スコアを直接出力します。 これは embedding モデルとは本質的に異なります: したがって、ベクトル検索の代わりになるわけではありません。その後ろに置かれる第2段階です。
reranker は インデックスを構築できず、検索もできません。ベクトル出力がなく、クエリなしでは ドキュメントを処理できません。やりたいことが「ドキュメントをベクトルデータベースに入れる」 であれば、このモデルではなく テキスト埋め込み が必要です。

具体的な比較

候補ドキュメントは同じ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_nreturn_documentsusage を変えません — どちらの場合でも各候補はスコアリングされます
今回は、課金記録から charges が prompt_tokens なのか total_tokens なのかを確認できませんでした(テスト用 token ではアカウント残高のエンドポイントを読み取れません)。100件の候補では、 2つの差は約45%あります。コストを重視する作業では、usage フィールドから支出を計算するのではなく、 コンソールの請求書を正として扱ってください。

最小限の呼び出し

レスポンス:
index が重要なフィールドです。 これは、送信した documents 配列内における文書の 元の位置 です。これを使って、自分の文書オブジェクト(ID、URL、メタデータ)を参照してください — 返された text で照合しようとしないでください。

リクエストパラメータ

測定済み機能マトリクス

知っておくべき3つのこと

つい「0.5で単純にフィルタする」と考えがちですが、計測データを見ると、それではうまくいきません:0.5 のしきい値では、正しいクロスリンガル結果をすべて捨ててしまい、非中国語では2位のヒットの大半も 捨てることになります。一方で、「Apple Inc. FY2024 revenue.」というクエリに対して、 リンゴ栽培の価格に関するドキュメントを受け入れてしまいます代わりにどうするか: これは信頼度ではなく、ソートキーとして扱ってください。どうしてもフィルタするなら、 相対しきい値(score >= top1_score × 0.3)を使うか、Top-N を取るだけにして、自分の ラベル付きデータでキャリブレーションしてください。
クエリ: 「冬に訪れるのに良い観光地はどこですか?」 2件の候補は明確に逆のことを言っています:モデルは「冬 + 観光地 + 旅行」というトピックに一致しただけで、否定を処理しませんでした。 nDCG@3 は 0.47 しかありませんでした。対策: 否定、除外、条件文を含むクエリ(「グルテンフリー」、「北京以外ならどこでも」、「未成年には適用外」など)では、リランキング後に LLM による検証パスを追加してください — Top-N をそのままユーザーに渡してはいけません。
同じ一致文に、無関係なダミー文をさまざまな量だけ追加した場合:さらに、長さは無関係なドキュメントも膨らませます: 同じ非一致ドキュメントは、短い場合は 0.029 でしたが、 付け足すと 0.121 になり、4倍高くなりました。対策: リランキング前に長いドキュメントを 200〜500 文字にチャンク化し、最もスコアの高い チャンクをそのドキュメントのスコアとして採用してください。チャンク化は、このモデルで最も効果の大きい 前処理です。
完全なチューニング手法 — チャンク化、しきい値、リコールのサイズ決定 — は 実践的なRAGチューニング にあります。

既知の問題

return_documents は効果がありません(2026-07-30 時点で計測)。truefalse を渡しても、あるいは 完全に省略しても、document.text がそのまま返されます。帯域に敏感なワークロード(候補集合が大きく、 ドキュメントが長い場合)では応答が想定よりはるかに大きくなります。フラグに頼らず、index で結果を自分で対応付けてください。
モデル名を誤ると 404 ではなく 503 が返ります。 メッセージは Current group default has no available channels for model xxx です。名前は 大文字と小文字を区別しますBGE-Reranker-v2-M3 は存在しないモデルとして扱われます。統合時に 503 が出たら、 チャネル障害を疑う前にスペルを確認してください。
上流のクォータはこのモデルにとって最も厳しい制約です。統合する前に token を見積もってください。上流(Huawei Cloud MaaS)では、このモデルに TPM 20,000 / RPM 120 まで利用できます。 同じプラットフォーム上の BGE-M3 埋め込みモデルでは TPM 1,200,000 が割り当てられます。60倍多い です。検証では、2つの 独立した メカニズムが切り分けられました:スロット上限を超えたリクエストは キューに積まれず、その場で拒否されます。また、どちらの失敗でも同一の メッセージ upstream load saturated が返るため、レスポンスだけでは見分けられません。したがって、それらも見込んで設計する必要があります。推奨事項: 同時実行数を 4 に抑え、指数バックオフを追加し、下の表を基準にスループットを設計してください。

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 サポートに連絡して上流のクォータを見直してもらってください
/v1/rerank だけが有効なパスです。 /rerank または /v2/rerank(Cohere v2 SDK の デフォルト)を要求すると、JSON の 404 ではなく HTTP 200 でウェブサイトの HTML ホームページ が返ります。クライアント側では 紛らわしいパースエラーに見えるだけです。統合で “unparseable response” と報告されたら、まず /v1 を確認してください。

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 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 自体を冪等性キーとして扱わないでください。
This model's maximum context length is 8192 tokens 付きの 400 が返ります。これは暗黙に切り詰められることはありません。 この上限はリクエスト全体ではなく、クエリと文書のペアごとに適用されます。たとえば、 400 文書 × 1000 文字(合計 330K tokens)の1件のリクエストでも通常どおり返ります。

関連ドキュメント