Qwen3 RAG費用計算：埋め込みと再ランキング候補数の予算

サポート用ナレッジベースを検索する RAG では、ベクトル索引の大きさよりも、再ランキングする候補段落の数が費用を左右する場合があります。以下の予算例では、候補を 20 件から 100 件に増やすと再ランキングの入力量は 5 倍になります。返却結果を 5 件に指定しても、評価した段落が 5 件だけとは限りません。

この記事では、Orux の qwen3-embedding-8b と qwen3-reranker-8b の現行価格を使い、オフラインで実行できる Python 計算器を紹介します。最初の候補数と、その後に測定する項目を決めるためのガイドです。計算はローカルで実行しましたが、新たなモデル呼び出しや検索ベンチマークは行っていません。処理量は明記した仮定であり、読者のアプリを測定した値ではありません。

索引作成・クエリの埋め込み・再ランキングを分ける

埋め込みモデルはテキストを比較可能なベクトルへ変換します。再ランキングモデルはクエリと候補文書の関連度を評価します。変更のない文書は通常、索引作成時に一度埋め込みます。一方、再ランキングはクエリを受け取り、候補を選んだ後に実行します。ネイティブモデルの説明は Qwen 埋め込みモデルカードと Qwen 再ランキングモデルカードで確認できます。

予算では、索引作成・更新で埋め込む文書トークン、検索時に埋め込むクエリトークン、再ランキングで評価するクエリと文書のトークンを別々に数えます。毎回全文書を送る実装でなければ、コーパス全体に月間検索数を掛けないでください。逆に、ペア単位の再ランキング見積もりではクエリを一度だけ数えてはいけません。同じクエリが各候補と組み合わされるためです。

回答を書く言語モデルは 4 番目の費用項目です。ベクトル保存、検索インフラ、通信、該当する税金も計算器の対象外です。費用を分けておけば、予想外の請求をすべて回答モデルのせいにせず原因を調べられます。

現在の価格を同じ単位で比較する

以下は 2026 年 10 月 30 日に確認した Orux の公開入力価格です。サービス価格であり、モデル提供元の公式ホスト API 価格や品質比較ではありません。1 Credit は約 $0.005 です。ゼロ表示は現在の設定価格で、永続的な無料提供、無制限の容量、今後のリクエスト成功を保証しません。

横にスワイプすると表全体を確認できます。

代替モデルは bge-m3 と bge-reranker-v2-m3です。ゼロ価格は現行条件を確認する理由にはなりますが、関連度、遅延、言語要件を満たす証拠ではありません。依存先にする前にアクセス条件、制限、最新見積もりを確認してください。

関連する LLM リクエスト費用比較は回答生成という別の段階を扱います。DeepSeek API 価格ガイドもベクトル検索ではなくテキスト生成の記事です。いずれも再ランキングの価格表には代えられません。

サポート検索の予算例

ナレッジベースを 10,000 段落、各 400 トークンと仮定します。最初の集計期間に 10,000 回の検索があり、クエリは平均 40 トークンです。各検索で 20、50、100 件を再ランキングする場合を比較します。この長さは計画用の入力値です。言語、トークナイザー、書式、文書構成で実使用量は変わります。

初回索引作成は 10,000 × 400 = 4,000,000 トークンで、Qwen の埋め込み料金では 46.6668 Credits。クエリの埋め込みは 10,000 × 40 = 400,000 トークンで 4.66668 Credits。合計は 51.33348 Credits です。この例で索引作成は一度の費用であり、未変更のコーパスに毎期かかる費用ではありません。

再ランキングの概算式は、検索数 × 候補数 ×（文書トークン + クエリトークン）です。候補 20 件では 10,000 × 20 × 440 = 88,000,000 入力トークン。88 × 11.6667 = 1,026.6696 Credits になります。これは処理量の見積もりで、サービスの実測使用量や精算記録の代わりではなく、モデル固有の書式による追加分も除いています。

横にスワイプすると表全体を確認できます。

合計には初回索引作成、クエリ埋め込み、再ランキングを含み、回答生成は含みません。次期も索引が同じなら 46.6668 Credits を引きます。一部更新なら、実際に再埋め込みしたトークン量で置き換えます。この表を遅延や精度の実測結果として使ってはいけません。

この仮定では候補を 20 から 50 件にすると再ランキング費用が 2.5 倍、100 件では 5 倍です。処理量の式から求めた比率であり、品質が 2.5 倍や 5 倍になるという意味ではありません。図は編集上の計算で、モデル生成結果ではありません。

API キーなしで計算する

次のコードを budget.py に保存し、python3 budget.py を実行します。Python 標準ライブラリのみを使い、ネットワーク通信は行いません。Decimal により、金額を二進浮動小数点に変換せず公開料金を扱います。別の日付や用途に使う際は、料金と処理量を変更してください。

"""Scenario calculator, not a tokenizer or a measured API bill. No network calls."""
from decimal import Decimal
RATE = Decimal('11.6667')  # Credits per 1M input tokens, checked 2026-10-30
USD_PER_CREDIT = Decimal('0.005')
QUERIES, CHUNKS, DOCUMENT_TOKENS, QUERY_TOKENS = 10000, 10000, 400, 40

def credits(tokens):
    return Decimal(tokens) * RATE / Decimal(1000000)

def scenario(candidates):
    index_tokens = CHUNKS * DOCUMENT_TOKENS
    query_tokens = QUERIES * QUERY_TOKENS
    pair_tokens = QUERIES * candidates * (DOCUMENT_TOKENS + QUERY_TOKENS)
    rerank = credits(pair_tokens)
    total = credits(index_tokens + query_tokens) + rerank
    return pair_tokens, rerank, total, total * USD_PER_CREDIT

if __name__ == '__main__':
    assert credits(4000000) == Decimal('46.6668')
    assert scenario(20)[1] == Decimal('1026.6696')
    assert scenario(50)[1] / scenario(20)[1] == Decimal('2.5')
    assert scenario(100)[1] / scenario(20)[1] == Decimal('5')
    print('k | rerank tokens | rerank Credits | first-period Credits | USD equivalent')
    for k in (20, 50, 100):
        print(k, *scenario(k), sep=' | ')

assert は索引作成の算術と候補数による 2 つの比率を検証し、出力は上表を再現します。検証対象は計算器であり、モデル品質やホストサービスが報告する正確なトークン数ではありません。導入後は最初の実使用記録と比較し、仮定した文書・クエリの平均長を置き換えると役立ちます。

候補数と返却件数は別のもの

現在の Orux 再ランキングフォームには query、documents、任意の top_n があります。評価対象の段落は documents 配列で決まります。top_n は求める返却件数であり、費用制御のために入力配列を短くする代わりにはしないでください。20 件と 100 件の予算を比較するなら、実際に異なる候補集合を準備します。

埋め込みリクエストでは input と現在公開されている encoding_format: "float" を使います。ネイティブモデルの機能とホスト側フォームは別の契約です。モデルカードの全機能が Orux のパラメーターとして公開されていると推測しないでください。接続前にモデルページの正確な別名と現在の入力フォームを確認します。

例えば「請求書のメールアドレスを変更するには？」という質問なら、使用を許可された自社文書から候補を検索してから、その段落だけを再ランキングに送ります。文書 ID をテキストと一緒に保持し、返却インデックスや結果を出典に対応付けます。関連度スコアは、文書が最新か、ユーザーに閲覧権限があるか、回答に十分かを保証しません。

必要な根拠を残せる最小の候補集合を選ぶ

候補に入らなかった関連段落は再ランキングでも回収できません。したがって候補削減は常に有効な最適化ではありません。正確な製品名、曖昧な表現、最近の規約変更、有効な回答のない質問を含む、代表的なサポート質問のラベル付きセットを用意します。比較前に正答に必要な段落を記録してください。

候補数ごとに、必要な段落が再ランキング前に取得されたか、処理後の順位、回答段階に十分な根拠が渡るかを測ります。遅延と請求使用量は別々に記録します。再ランキング前に文書が欠けているなら検索と文書準備を調べてください。大型・高価格の再ランキングモデルでも、受け取っていない文書は評価できません。

20、50、100 件を比べる際は評価セットと文書スナップショットを固定します。そうしないとコーパス更新をモデル改善と誤認する可能性があります。この記事に万能の候補数はありません。根拠の網羅性と利用体験の実測が許容できる場合にのみ安い設定を採用します。文書長、トラフィック構成、価格が大きく変わったら再評価してください。

よくある質問

Q.初回期間の合計は API 請求額の保証ですか？

いいえ。明示した処理量と価格時点に基づく概算です。書式の追加分、実際のトークン化の違い、回答生成、インフラは含みません。候補予算を同じ条件で比較するために使い、予測として採用する前に実リクエストの使用量と請求を照合してください。

Q.top_n を 5 にすれば候補 5 件分の料金になりますか？

そうとは限りません。リクエストには評価のために送った全文書が残ります。入力候補数と返却件数を分けて考えてください。候補削減の予算効果を調べるには documents 配列を減らし、必要な根拠が失われないか確認します。

Q.未変更の文書も検索ごとに埋め込みますか？

ここで説明した索引型の処理では不要です。文書の埋め込みは保存され、内容や埋め込み設定が変わるまで再利用します。クエリの埋め込みは別工程です。全文書に検索数を掛けるのではなく、追加・編集・意図的な索引再作成を数えます。

Q.BGE のゼロ価格は最良の選択という証拠ですか？

いいえ。確認日の入力価格を示すだけです。検索品質、アクセス条件、遅延、将来価格については何も保証しません。本番環境で依存する前に、代表的な質問で評価し、最新のモデルページを確認してください。

Q.この計算器はモデルや Credits を使いますか？

いいえ。Python 標準ライブラリによるローカル計算で、API キーもネットワーク要求も不要です。予算の関係を示すもので、ベクトルや関連度スコアは生成しません。後日ホストモデルを呼ぶ結合テストは別の操作であり、その時点の価格と制限に従います。

価格確認日：2026-10-30。出典：Orux Qwen 埋め込み、Orux Qwen 再ランキング、Orux BGE 埋め込み、Orux BGE 再ランキング、および上記 Qwen モデルカード 2 件。