以前、私はRAGパイプラインをブラックボックスのように扱っていました。エンベディングを入力すれば回答が出てくる、その間のどこかでクラウドの請求額が増えていく……といった具合です。私が話を聞いた多くの開発者と同様に、私は密ベクトルモデルこそが「悪役」だと思い込んでいました。それらは高価に聞こえたからです。1,000ページの文書を高次元の浮動小数点数に変換することは、まるで重工業のようなものに感じられ、私はそれ相応の注意を払って扱っていました。すでに処理済みのデータの再エンベディングを避けるために、専用のキャッシングレイヤーさえ構築しました。その最適化を、私は誇りに思っていたのです。しかし、請求書を開いて計算してみたとき、真実に気づきました。
私は、全く間違ったものを最適化していたのです。
エンベディングの罠
私の思い込みを打ち砕いた数字があります。1,000ページのドキュメントをエンベディングするコストは、およそ18セントです。これは打ち間違いではありません。ほとんどの都市におけるコーヒー1杯の価格よりも安く、本一冊分をベクトル化できるのです。さらに重要なのは、そのコストは取り込み（ingestion）時に一度だけ発生するということです。最初のパスが終われば、それらのベクトルはストレージに格納され、待機します。ユーザーがアプリケーションを開くたびに、従量課金の料金が発生することはありません。それらは資本的支出（capital expense）であり、継続的な流出ではないのです。
それにもかかわらず、誤解は根強く残っています。混乱の一因は構造的なものです。エンジニアが初期のエネルギーを注ぎ込むのは、取り込みパイプラインです。チャンカーを書き、トークナイザーと格闘し、ターミナル上で進捗バーがゆっくりと進むのを眺めます。その目に見える努力が、規模の錯覚を生み出します。それは労働集約的なプロセスであるため、高価な部分であるかのように感じられるのです。しかし、労働とコストは同じではありません。そしてRAGにおいては、それらはしばしば逆相関の関係にあります。
3つの全く異なる請求項目
コストをまとめて考えるのではなく、ステージごとに分離してみると、状況は一目瞭然になりました。RAGシステムは3つの異なる経済モデルで動作しており、予算を健全に保ちたいのであれば、その違いを理解することが不可欠です。
エンベディングは、一度限りの製造コストです。 ドキュメントをベクトルに変換するために支払いますが、それが終われば完了です。ドキュメントが静的なものであれば、この項目が月々の請求書にほとんど現れることはありません。
ベクトルデータベースは、インフラの賃貸料です。 システムを24時間稼働させ続けるために支払います。数百万のチャンクを保持するSSD、インデックスを維持するCPUコア、そして100ミリ秒未満の検索を実現するネットワークに対して支払います。このコストは実在し、データ量に応じてスケールしますが、一般的には予測可能です。ジムの月会費のようなものです。クエリを1回投げようが1万回投げようが、ベースとなるインフラコストはほぼ変わりません。
大規模言語モデル（LLM）は、消費税です。 ユーザーの質問が投げられるたびに、請求が発生します。検索レイヤーからプロンプトへと送られるすべてのトークンにコストがかかります。推論のステップ、フォーマットの指示、モデルに生成させる引用のすべてが、微小な重みを加算していきます。しかし、それらの微小な料金はセッション数によって倍増し、セッション数は右肩上がりに増えていきます。ここで、レイテンシと支出が相まって悪循環を生みます。クエリの遅延は、ユーザーにとって単にイライラさせるだけでなく、ユーザーが待っている間に、積極的に現金を燃やし続けていることになるのです。
これらは同じ問題のバリエーションではありません。3つの別々の問題です。取り込みコストを安くすることで、クエリ時の支出問題を解決することはできません。それは、駐車料金を節約するために車のエンジンをチューニングするようなものです。
実際にお金がどこへ消えているのか
もしあなたが本番環境でRAGアプリケーションを運用しているなら、コストエクスプローラーを開いて使用タイプ別にフィルタリングしてみてください。おそらく、エンベディングのジョブは1日1回、フラットな線を描いている一方で、LLMのエンドポイントはトラフィックに応じてスパイクする心拍計のような形をしているはずです。そのパターンがすべてを物語っています。ベクトルは眠っていますが、ユーザーが質問をするたびに、モデルは目を覚ますのです。
この気づきによって、私のエンジニアリング作業の優先順位は変わりました。私は「どうすれば取り込みを安くできるか」と問うのをやめ、「どうすれば各質問のコストを安くできるか」と問い始めました。この転換は当たり前のように聞こえるかもしれませんが、ほとんどのチームはいまだに勘で動いています。彼らはエンベディングのステージに精巧な重複排除ロジックを構築しながら、LLMに対しては、何の疑いもなく肥大化した、焦点の定まらないコンテキストウィンドウを流し込んでいます。彼らは屋根が雨漏りしているのに、床を磨いているようなものなのです。
パイプラインを壊さずにコストを削減する方法
RAGシステムでコストを削減するには、戦術をコストモデルに合わせる必要があります。実際に効果があるのは以下の方法です。
プロセスを実行する前に重複を排除する
Most organizational knowledge bases move slowly. Policies, handbooks, research PDFs, and archived reports sit untouched for months. In many pipelines, about eighty percent of source documents stay identical between ingestion runs. Despite this, plenty of systems drop the entire corpus and rebuild the index from scratch on a schedule. Do not do that. Build a gate at the entry to your pipeline. Hash incoming files. Compare last-modified timestamps. If a document has not changed, skip it entirely. Re-processing static files is pure waste. It costs compute, it wears SSDs unnecessarily, and it balloons your ingestion logs with false activity.
In practice, store a lightweight manifest that maps file paths to checksums. When the scheduler wakes up, let it check the manifest first. Only the minority of changed files should ever see a chunker.
Patch Documents, Do Not Replace Them
When a document does change, resist the instinct to treat it as a brand-new file. A fifty-page technical spec might receive a two-paragraph revision in section four. If your pipeline replaces the entire file, you will re-chunk and re-embed forty-nine perfectly good pages for no reason.
Instead, compare the new version against the old one. Identify the delta. Then re-chunk and re-embed only the sections that changed. Use metadata like page numbers, section IDs, header anchors, or paragraph ranges to track boundaries. If your chunking strategy respects document structure, this is straightforward. If it does not, fixing your chunker is a better investment than buying a bigger inference cluster. The engineering cost of maintaining a diff-aware pipeline pays for itself within weeks once your document count scales.
Attack the Recurring Costs Head-On
Since LLM calls run on every query, shaving even a few tokens or caching a handful of responses creates outsized returns. Start with prompt caching. If one user asks about your refund policy and another asks the same thing ten minutes later, there is no reason to hit the model twice. Store recent query-response pairs with semantic similarity matching. When a new question lands within a similarity threshold of a cached one, return the stored answer directly. No tokens generated, no dollars spent.
Next, look hard at your retrieval quality. A sloppy retriever forces the LLM to read a haystack to find the needle. If you stuff the prompt with twenty irrelevant chunks because your top-k cutoff is too loose, you are paying the model to skim noise. Tighten your retrieval. Trim your top-k. Compress chunks before sending them. Remove boilerplate footers and headers during ingestion so they never reach the prompt. Every token you remove from the context window is a fraction of a cent saved, and those fractions accumulate across thousands of daily queries.
Better retrieval also improves latency, which is another form of cost. Users abandon slow interfaces. A faster answer is both cheaper to produce and better for retention.
The Real Takeaway
Stop optimizing what feels expensive and start optimizing what your invoice says is expensive. Measure each stage independently. You will likely find that embeddings are the cheap part, vector storage is the steady part, and LLM inference is the part that bleeds. Focus your energy on query-time efficiency, incremental updates, and surgical deduplication. Build for the thousandth user question, not the fiftieth document upload. The bottleneck is rarely where you think it is.
Source: Where Does RAG Actually Cost You Money? I Decided to Stop Guessing
Join the discussion in the GyaanSetu AI learning community.