本文へスキップ
ToolSimu

SaaS・AI・クラウド · インタラクティブ・シミュレーター

RAGとベクトルデータベースのコストシミュレーター:検索で補強された回答1件の本当のコスト

検索拡張型の回答は、1回なら安く、100万回なら高くつきます。コンテキストの大きさ、モデルの価格、リランキング、インデックスの規模が、AI機能が採算に乗るかどうかをどう決めるかを確かめましょう。

コントロールタワー

プロダクトが1か月に答える質問の数です。1件ごとに検索とモデルの呼び出しが1回ずつ発生します。

300,000

サブスクリプションまたは従量課金の収入を、提供した回答数で割った、1回答あたりの平均収入です。

¥6

ベクトルデータベースに保存されているテキストのチャンク数で、単位は百万です。

5

回答ごとにプロンプトへ貼り付ける、検索で取得した文章です。モデルコストの最大の要因です。

4,000

言語モデルが入力100万トークンあたりに課す料金です。出力トークンはこの何倍かの価格が設定されています。

¥375

取得した文章の並び順を改善するため、リランキングモデルを通す検索の割合です。

60%

現在のシナリオに対して、逆ストレステストと1,000回のモンテカルロ・シミュレーションを実行します。

月次の純損益

¥483,548

連鎖するドミノの流れ

各段階が次の段階に影響します。緑は安全、黄は警告、赤は危険を表します。

  1. 1

    回答1件あたりのトークン数

    4,690

    プロンプトと回答のトークン

    安全

  2. 2

    回答1,000件あたりのコスト

    ¥2,458

    1,000件あたりの変動費

    警告

  3. 3

    コストの割合

    41%

    売上のうち検索とモデルに充てる割合

    警告

  4. 4

    貢献利益

    56%

    すべての変動費を差し引いた後の利益率

    安全

  5. 5

    利益

    ¥48万

    月次の純利益

    安全

金額はJPYで、実際の為替レートではなく例示的な目安のスケールで表示しています。

詳細ガイド

RAGとベクトルデータベースのコストシミュレーター:検索で補強された回答1件の本当のコスト

業界のエグゼクティブ分析

検索拡張生成は、チャット機能へのちょっとした追加に見えます。文書をベクトルとして保存し、質問ごとに最適な文章を取り出して、言語モデルに回答を書かせるのです。最初のプロトタイプはほとんどお金がかかりません。問題は規模が大きくなったときに現れます。回答のたびに同じ有料のステップが繰り返され、その中で最大のもの、つまりプロンプトに含まれるトークンは固定ではないからです。それは、貼り付けるテキストの量によって決まります。テスト中には1セントの何分の1かで済む機能が、本番では回答1件あたり数セントになることがあります。

この問題の構造は、回答ごとのコストの上に月ごとのコストが積み重なったものです。回答ごとには、入力トークン、出力トークン、場合によってはリランキングの呼び出し、データベースの読み取りに支払います。月ごとには、ベクトルをメモリに保持するコスト、変更された文書の再埋め込み、評価とトレーシングの運用に支払います。売上は回答に結びついているため、プロダクトの利益率は、月ごとの層を回答数で割った後の、回答1件あたりの収入と変動費の差です。

ドミノモデルは、これを5つの段階でたどります。コンテキストの大きさとプロンプトが、回答1件あたりのトークン数を決めます。それにモデルの価格を掛けると、1,000件あたりのコストが決まります。それを回答1件あたりの売上と比べたものが、コストの割合です。オブザーバビリティの費用を差し引いた残りが貢献利益で、チームの固定費が月次の利益を決めます。コンテキストが長くなる、モデルが高価になる、リランキングの割合が増えるといった変化は、いずれも2つ目のボックスを押し上げ、利用が伸びると、損害は薄まるのではなく倍増します。

氷山は、目につく請求と、気づきにくい請求を分けて示します。水面上にあるのは、モデルの入力トークンとベクトルデータベースです。水面下にあるのは、入力の何倍もの価格が付く出力トークン、検索ごとのリランキングの呼び出し、文書が変わるたびの再埋め込みのコスト、そして本番のシステムに必要な評価、トレーシング、ログ記録です。どれも、初期の見積もりでは抜け落ちやすいものです。このシミュレーターで、月次の損益がゼロになるコンテキストの大きさやモデルの価格を見つけ、何から削るかを決めましょう。

計算式と方法論の設計図

モデルは月単位で動きます。売上は、回答数に回答1件あたりの売上を掛けたものです。回答ごとに、取得したコンテキストと固定のプロンプトがモデルに送られ、入力単価の4倍の価格が付く固定長の回答が返されます。ベクトルデータベースにはメモリ分が課金され、その量は、チャンク数に埋め込みの次元数と4バイトを掛け、インデックスのオーバーヘッドを加えたものに、1GBあたりの単価を掛けて求めます。これに、100万クエリあたりの読み取り料金が加わります。リランキングは検索ごとに課金され、選択した割合のクエリに適用されます。変更された文書は毎月再埋め込みされます。

モデルの入力
I = 回答数 × (コンテキスト + プロンプトのトークン) ÷ 100万 × 単価
多くのプロダクトで最大の費用項目で、コンテキストの大きさと回答数に応じて増えます。
モデルの出力
O = 回答数 × 350トークン ÷ 100万 × 単価 × 4
出力トークンは入力トークンの何倍もの価格が付くため、長い回答はすぐに積み上がります。
ベクトルの保存
V = チャンク数 × 1,536 × 4バイト × 1.5 × 1GBあたり$5 + 読み取り
インデックスのオーバーヘッドを含むメモリ常駐のベクトルと、クエリごとの読み取り料金です。
リランキングと再埋め込み
R = 回答数 × リランキングの割合 × $0.002 + チャンク数 × 8% × 400トークン × 埋め込み単価
リランキングした検索ごとの呼び出しと、変更された文書の毎月の更新です。
純利益
純利益 = 売上 − I − O − V − R − オブザーバビリティ − 固定費
月次の結果です。破綻点は、これがゼロになる点です。

連鎖する弾力性

コンテキストのトークンとモデルの価格は、互いに掛け合わされたうえで回答数にも掛かるため、最も感応度の高い入力です。回答1件あたりの売上は、収入の側で同じように強い力を持ちます。リランキングの割合とインデックスの規模は影響が穏やかですが、継続的です。回答数は両方向に働きます。回答が増えれば稼ぎも増えますが、それは回答1件あたりの収入が、その回答をつくる変動費を上回っている間だけです。

実例に基づく3つのケーススタディ

自己資金で始めるスタートアップ

整ったインデックスを持つ小さなサポートボット

プロダクトチームがヘルプ記事の数十万チャンクをインデックス化し、控えめなモデル、短いコンテキスト、わずかなリランキングで、月に6万件の回答を提供しています。回答1件あたりの稼ぎは十分です。これを読み込むと、プロンプトが簡潔でナレッジベースが小さいときに、検索がいかに手頃かがわかります。

成長中の中堅企業

効率的なプロンプトを持つ大量処理のアシスタント

プラットフォームは6千万のチャンクを対象に月250万件の回答を提供していますが、コンテキストを短く保ち、低コストのモデルを使っています。回答1件あたりの売上は薄いものの、ボリュームは大きくなっています。これを読み込むと、プロンプトの規律が規模を利益に変える仕組みと、より高価なモデルに対する感応度がわかります。

ブラックスワン級の危機

プレミアムモデルでの巨大なコンテキスト

チームは、すべてのプロンプトに1万5千トークンの文書を貼り付け、プレミアムモデルを使い、1億チャンクに対するすべての検索でリランキングを行っています。回答1件あたりの稼ぎはわずか2セントです。これを読み込むと、モデルのトークンだけで売上を超え、その月が大きく赤字に転じる様子がわかります。

業界ベンチマーク一覧

指標危険ゾーン業界平均上位10%のエリート水準
売上に占めるモデルと検索のコストの割合60%超20~40%15%未満
回答1件あたりのコンテキストトークン9,000超2,000~5,0001,500未満
リランキングされる検索の割合すべての検索で100%30~60%選択的に30%未満
インデックスに占める月次の再埋め込みの割合25%超5~10%3%未満
回答1件あたりの貢献利益率25%未満45~60%70%超

変数とレバー

月間の回答数

プロダクトが1か月に答える質問の数です。1件ごとに検索とモデルの呼び出しが1回ずつ発生します。

レバー: 回答1件あたりのコストが回答1件あたりの売上を下回ってから利用を拡大し、コストだけを生んで収入にならない無料ユーザーにはレート制限をかけましょう。

回答1件あたりの売上

サブスクリプションまたは従量課金の収入を、提供した回答数で割った、1回答あたりの平均収入です。

レバー: 従量課金にするか、ヘビーユーザー向けの上位プランを設けて、回答あたりの収入がモデルの請求額に連動するようにしましょう。

インデックス済みのチャンク

ベクトルデータベースに保存されているテキストのチャンク数で、単位は百万です。

レバー: インデックスの重複を排除して整理し、あまり使われない内容は安価なストレージに置きましょう。メモリ常駐のベクトルは毎月課金されます。

回答1件あたりのコンテキストトークン

回答ごとにプロンプトへ貼り付ける、検索で取得した文章です。モデルコストの最大の要因です。

レバー: より少なく、より質の高い文章を取得し、プロンプトに入れる前に絞り込みましょう。入力トークンは、回答のたびに支払うものです。

入力100万トークンあたりのモデル価格

言語モデルが入力100万トークンあたりに課す料金です。出力トークンはこの何倍かの価格が設定されています。

レバー: 単純な質問は小さなモデルに振り分け、繰り返される回答はキャッシュしましょう。トークン単価は、最大の費用項目に掛かります。

リランキングを使う回答

取得した文章の並び順を改善するため、リランキングモデルを通す検索の割合です。

レバー: あいまいな検索だけをリランキングし、精度の向上分を使ってモデルに送るコンテキストを短くしましょう。

このシミュレーターの使い方

  1. 1課金データから、月間の回答数と回答1件あたりの平均収入を入力します。
  2. 2取得したコンテキストの平均トークン数と、モデルの入力100万トークンあたりの価格を加えます。
  3. 3インデックス済みのチャンク数と、リランキングを使う検索の割合を設定します。
  4. 4「破綻点を探す」を押して、どの入力が最初に利益をゼロへ押し下げるかを確認します。
  5. 5現在の設計と、より的確な検索を、初期費用を含めて24か月にわたって比較します。

避けたい間違い

  • プロトタイプからコストを見積もること。テストのトラフィックはプロンプトが短くユーザーも少ない一方、本番では長いコンテキスト、再試行、繰り返しの質問が加わります。
  • 出力トークンを忘れること。回答はプロンプトよりトークン単価が高く、長くて冗長な応答は静かに請求額を押し上げます。
  • インデックスを無料だと考えること。メモリ常駐のベクトルは、誰がクエリを投げたかにかかわらず、毎月課金されます。
  • ますます大きなコンテキストで品質を追いかけること。ある点を超えると、文章を増やしても精度の向上より速くコストが増えるため、検索を改善するほうが安上がりです。

よくある質問

RAGの回答のコストを最も左右するのは何ですか?

たいていは、言語モデルに送られるトークンです。プロンプトに貼り付ける取得済みの文章は回答のたびに支払うことになるため、コンテキストの大きさが最初に見直すべきレバーです。

ベクトルデータベースは高いのですか?

多くの場合、費用の小さな部分にとどまります。チャンクが数千万に達する場合や、すべてをメモリに保持する場合には無視できなくなります。整理と階層化が役立ちます。

リランキングは費用に見合いますか?

並び順が改善され、モデルに送る文章を減らせるなら見合うことがあります。節約できた入力トークンが追加の呼び出しを上回るかどうかを検証してください。

なぜモデルに出力トークンが含まれているのですか?

出力トークンは入力トークンの何倍もの価格が付いているためです。同じコンテキストの大きさでも、冗長な回答は簡潔な回答より高くつきます。

破綻点はどうすれば見つかりますか?

「破綻点を探す」を押してください。ツールが各入力を不利な方向へ動かし、月次利益がゼロになる値を報告します。

この結果はどのくらい正確ですか?

前提を明示した教育目的のモデルであり、財務に関する助言ではありません。実際のトークンログと請求書を使い、ベンダーの最新の料金も確認してください。

これは前提条件を明示した、教育目的の計画モデルです。財務、税務、法律に関する助言ではありません。入力値はご自身の数字に置き換え、重要な判断は必ず資格を持つ専門家に確認してください。