この記事で分かること／分からないこと
- 分かること: 実行時にLLMを呼ばず索引だけを引く「確定配信」という設計
- 分かること: ビルド時と実行時でコストがどう分かれるか(自社実測)
- 分かること: この設計が何を捨てて何を得ているか
- 分からないこと: 想定外の質問への耐性を示す定量評価
- 分からないこと: 他社RAG実装とのコスト比較
確定配信とは、実行時にLLMを呼ばない設計のこと
RAGの運用コストは、モデルの呼び出し回数やトークン数を減らす工夫が話題になりやすい。だが自社実装で採用しているのは、そもそも実行時にLLMを呼ばないという、もう一段手前の設計である。想定質問と根拠のペアを事前に作り込み、検証まで済ませた状態で索引に格納し、本番では入力に対して索引を引いて返すだけにする。この構成を確定配信と呼んでいる(実体: docs/STORAGE_AND_BILLING.md)。生成をビルド時に前倒しし、実行時は照合処理に置き換える発想である。
コストはビルド時に払い、実行時にほぼゼロへ落とす
自社実測では、生成と盲検によるビルド時の処理に1テナントあたり概ね1,500円かかる一方、実行時(確定配信・0 LLM)は1会話あたり概ね0〜1円、実測で0.12円/sessionにとどまる(出所: docs/STORAGE_AND_BILLING.md、確認日2026-09-06)。ビルドは差分再生成で再発を抑えられ、更新のたびに全体を作り直す必要はない。費用の大半をビルド時に寄せ、実行時をほぼゼロに近づける構造そのものが工夫の中心になる。
実行時に触るのは索引だけ、という構造
この設計では、原本や生成過程の中間データをビルド時にしか使わない大容量データとして扱い、実行時に毎回引く索引だけを低レイテンシな領域に分けて置く(出所: docs/STORAGE_AND_BILLING.md、確認日2026-09-06)。一度きりの読み出しで済むデータと会話のたびに引かれるデータを同じ場所に置くと、軽く保ちたい実行時の経路まで重くなる。実行時に何を触るかを先に決め、それ以外を経路から外しておく必要がある。
捨てているのは「想定外の質問への柔軟さ」
確定配信は万能ではない。想定していない質問や、その場での推論・要約・言い換えを必要とする質問には、索引を引くだけでは答えられない。捨てているのはその場での柔軟な生成、得ているのは費用の予見可能性とレイテンシである。確定配信が向くのは想定質問の範囲をある程度絞り込める用途に限られ、想定外の質問が一定割合で出る用途では、索引で答えられない場合の扱い(問い合わせへの誘導など)を別途用意する必要がある。
よくある質問
Q1. 確定配信とは何か
実行時にLLMを呼ばず、検証済みの質問と根拠のペアを格納した索引を引くだけで応答する設計である。生成はビルド時に前倒しされている。
Q2. なぜ実行時コストがほぼゼロになるのか
実行時に生成を行わず索引の参照だけで完結するため、モデル呼び出しの費用が発生しない。自社実測で0.12円/session(出所: docs/STORAGE_AND_BILLING.md、確認日2026-09-06)にとどまる。
Q3. どんな質問に向かないのか
想定していない質問や、その場での推論・要約・言い換えを必要とする質問には向かない。索引に無い内容には答えられず、範囲外の扱いを別途用意する必要がある。
Q4. 導入する際に何を準備する必要があるか
想定質問と根拠のペアを事前に作り込み、検証を経て索引に格納する準備が必要になる。この費用はビルド時に発生し、自社実測では概ね1,500円/テナントとなっている。
測定地点でレイテンシの意味が変わる点はレイテンシ計測の記事、他の下げ方はキャッシュが効く条件の記事と埋め込みを作り直さない工夫の記事で扱う。RAGの運用コスト設計について相談したい方は、お問い合わせから編集部までご連絡いただきたい。
- ハブ記事: RAGサービス比較15選
- 関連記事: RAGのレイテンシ計測
- 関連記事: キャッシュが効く条件と効かない条件
- 関連記事: 埋め込みを作り直さずに済ませる