この記事は、RAG（Retrieval-Augmented Generation）を使ったシステムの「見えにくい出費」に切り込んだものです。
RAGは、ざっくり言うと
「質問に答える前に、関連しそうな資料を検索して、その内容をLLMに渡す仕組み」
です。ChatGPTみたいなLLM単体よりも、社内文書やFAQ、製品マニュアルに強くなるので、実務ではかなり便利です。
ただし著者が言うのは、RAGは**“答えの質”には強いけど、“請求額”には無頓着**だということ。
これはかなり納得感があります。実際、開発中は「ちゃんと答えた」「速度も許容範囲」で満足しがちなんですよね。けれど運用が始まると、トークン代がじわじわ効いてくる。ここは本当に怖いところだと思います。
著者は、標準的なRAG実装にありがちなコストの穴を3つに整理しています。
多くの実装は、とりあえず top-10 のチャンク（文書の断片）を取ってきます。
でも実際には、2〜3個あれば十分なことが多い。残りはノイズです。
つまり、
「念のため入れた余計な文章」にもトークン代を払っている
わけです。
記事内の試算では、1回あたり500トークン、うち7チャンクが不要だとすると、
これはかなり生々しい数字です。
個人的には、この「念のため」が積み上がる世界って、クラウド費用あるあるの典型だなと思います。
同じ質問を2回されたら、本来は前回の結果を再利用したいですよね。
でも素のRAGパイプラインだと、毎回いちから埋め込みを作って、検索して、LLMを呼ぶことになります。
著者はこれを「semantic memory がない」と表現しています。
要するに、**“意味が同じ質問”を同じ質問として扱えていない**のです。
これはかなりもったいないです。
「LLMって何の略？」みたいな質問に、最上位クラスの高価なモデルを使う必要はまずありません。
著者は、
を同じルートで処理するのは無駄だと主張します。
そして、モデル価格の差がかなり大きい前提では、ルーティングしないだけで大きなコスト差が出る、と述べています。
この記事の中心はここです。
著者はRAGの上に、コストを意識して振る舞いを変える4層の仕組みを重ねました。
この発想が面白いのは、RAGを「1本の処理」と見ずに、どこでお金が漏れるかを段ごとに監視する形にしていることです。
かなり実務っぽい、地に足のついた設計だと思います。
これは一番わかりやすいです。
過去の質問と回答を保存しておき、意味が近い質問が来たら、LLMを呼ばずにキャッシュから返します。
ここでのポイントは、単なる完全一致ではなく、semantic similarity（意味の近さ）で判定していること。
たとえば「RAGって何？」と「RAGとは？」は、文字列は違っても意味はほぼ同じですよね。そういうケースを拾います。
著者の実装は pure Python で、外部依存をなるべく減らした設計です。
埋め込みには TF-IDF を使っています。
TF-IDFは、ざっくり言うと「その単語がその文書にどれだけ特徴的か」を数値化する方法です。最近の文脈では少し古典的ですが、シンプルで扱いやすいのが利点です。
キャッシュにヒットしたとみなすには、類似度のしきい値を超える必要があります。
著者は、TF-IDFベースでは 0.75 をデフォルトにしているそうです。
一方で、より高品質な埋め込みモデルでは 0.92〜0.95 くらいになることが多いと説明しています。
ここは地味だけど重要です。
キャッシュは「入れれば勝ち」ではなく、雑にやると危ない。
個人的には、コスト削減の機能ほど、誤答リスクとの綱引きがキツいと思います。
記事では、200クエリの検証で以下のような結果が出ています。
ただしこの高い hit rate は、事前に40%のクエリをキャッシュへ入れてある「ウォームキャッシュ」前提です。
つまり、最初から何でも98.5%当たるわけではありません。
ここは誤解しない方がいいポイントですね。
次はモデルの使い分けです。
質問の難しさを見て、
に振り分けます。
これ、当たり前に見えるんですが、実際の現場では意外とできていないことが多いと思います。
「とりあえず最高性能のモデルで統一」は運用が楽ですが、財布には優しくないです。
著者は3つのシグナルを組み合わせています。
これらを重み付きで足して、スコア化しています。
要するに、短くて単純な質問は軽く、長くて固有名詞だらけの質問は重いとみなすわけです。
記事によると、ベンチマークでは
とのこと。
これはかなり強いです。
実際、FAQっぽい問い合わせが多いシステムなら、かなりの割合で安いモデルに逃がせるはずです。
これは「使いすぎ防止」の仕組みです。
RAGでは、検索で取ってきた文脈が増えすぎると、そのままLLM入力が膨らみます。
すると、費用も増えるし、場合によっては回答品質も落ちます。
なぜなら、長すぎるコンテキストはノイズも増えるからです。
各リクエストに対して、使ってよいトークン量の予算を決めておき、
その範囲内でだけ文脈を詰めるようにします。
もし予算オーバーしそうなら、
といった制御を入れます。
これは単純ですが、かなり実用的です。
「よくわからないけど、全部盛り」で逃げないためのブレーキですね。
Circuit breaker は、システムが暴走しそうなときに止める安全装置です。
たとえば、キャッシュミスが急増したり、予算を超えそうになったりしたときに働きます。
これがないと、異常時に
“高い処理を延々と回し続ける”
ことになります。
クラウド費用の事故って、だいたいこういう形で起きます。怖い。
Circuit breaker は、品質よりも先にコストが壊れる状況を防ぐためのもの、と考えるとわかりやすいです。
著者は、前提条件に基づく試算として、以下のようなコスト比較を示しています。
月額換算では、10,000 req/day の場合
これはかなりインパクトがあります。
もちろん、あくまで記事内の前提価格・ローカルベンチマークに基づく数字ですが、それでも「RAGは品質だけ見ていると普通に金食い虫になる」という主張はかなり説得力があります。
この記事の面白いところは、単なる「安くするテクニック集」ではないことです。
本質は、
RAGを“回答生成の仕組み”としてだけでなく、“運用コストを管理するシステム”として見るべき
という視点にあります。
これは重要だと思います。
なぜなら、プロトタイプ段階では見えない問題が、本番では一気に効いてくるからです。
この4つは、どれも「正しく動いているのに高い」という厄介な問題を生みます。
RAGは賢いけれど、何も考えずに使うと財布には全然賢くない。
この一文が、この記事の核心ではないかと思います。
個人的には、この記事はかなり実務寄りで好きです。
派手なAIデモではなく、**“ちゃんと使うときに何が痛いのか”** を真正面から扱っているからです。
特に良いのは、
を一つの設計としてまとめている点です。
どれか1個だけでも効果はありますが、組み合わせると「コストに対して反応するシステム」になる。ここが強い。
一方で、もちろん万能ではありません。
実運用では、
など、現場ごとの調整が必要です。
なので、この記事の数字をそのまま自分のシステムに当てはめるのは危険だと思います。
でも、**“RAGの費用は後から効いてくる”** という警鐘としては、とても価値があります。
この論文的な記事が教えてくれるのは、RAGは「作る」より「運用する」段階で本当の難しさが出る、ということです。
答えが正しいだけでは足りない。
安く、速く、無駄なく回せて初めて、現実のシステムになる。
その意味でこの記事は、RAGを使っている人ほど刺さる内容だと思います。
参考: RAG Is Burning Money — I Built a Cost Control Layer to Fix It
