8月14日、Towards Data Scienceが「Cut an Enterprise RAG Pipeline's Latency and Cost by Calling the LLM Less, Not by Buying a Faster Model」と題した記事を公開した。LLMの呼び出し回数を減らすことでエンタープライズRAGパイプラインのレイテンシとコストを削減する実践的なルーティング手法を解説しており、新たなモデルやMLモデルを導入することなく、既存の検索スコアだけで実装できる点が特徴的だ。
「速いモデルに乗り換える」より「モデルを呼ばない」の方が安い
RAGパイプラインが遅いとき、最初に思いつく対策はモデルのアップグレードだ。しかし記事が示す答えはシンプルで、モデルを呼ぶ回数を減らす方が、コストとレイテンシの両方で大きな改善になる。
前提として、記事が最適化対象とするパイプラインは1つの質問に対して3回のLLM呼び出しを直列で実行する構成だ：
- 質問を正規化してキーワードを抽出する呼び出し
- 取得した候補ドキュメントを評価するアービター（仲裁：複数の候補から最適な回答行を選ぶ役割）呼び出し
- 型付き回答を生成する呼び出し
この3回は難しい質問には正当化される。だが「年間保険料はいくら？」のような単純な質問でも同じコストがかかる。キーワードマッチがすでに答えを1行に絞り込んでいるにもかかわらず、だ。
コアアイデア：スコアの「マージン」でルートを決める
記事の核心は、既存のキーワードスコアをそのままルーターの信号として使うという発想だ。新たなモデルもMLモデルも必要ない。
RAGパイプラインの検索ステップでは、各行に対してキーワード共起スコア（co_occurrence_score）が計算されている。これは、クエリのキーワードが対象テキスト行に何語同時に出現するかを数値化したもので、本記事が属するシリーズ（doc-intelシリーズ）で構築してきた独自の検索スコアリング手法だ。このスコアの「トップスコア」と「2位との差（マージン）」を見るだけで、ルートが決まる。
例1：モデル不要な質問
「年間保険料は？」に対し、"The annual premium is EUR 1,200, payable…" という行がスコア5を取り、他の全行はスコア0。1位と2位の差（マージン）は5。1つの行が圧倒的に勝っており、モデルが介入する余地はない。
例2：モデルが必要な質問
「私の場合、どの保証を外せる？」に対しては、3行がスコア2で並ぶ。マージンは0。モデルが文脈を読んで推論する必要がある。
実装はわずか十数行で完結する：
def route_question(line_df, primary, secondary, *, min_score=4, min_margin=3):
"""Decide, with no model call, whether the keyword path already answers."""
scores = [co_occurrence_score(t, primary, secondary) for t in line_df["text"]]
top, second = sorted(scores, reverse=True)[:2]
confident = top >= min_score and (top - second) >= min_margin
return "fast" if confident else "full"
fastルートはモデルを完全にスキップし、決定論的な値抽出に進む。fullルートは従来どおりアービターと生成まで走らせる。
削減幅：1クエリあたり2秒 vs 0.1ミリ秒
実際の計測結果が記事に示されている。
- ファストパス（ルーティング + 決定論的抽出）：約0.1ミリ秒、ネットワーク呼び出しなし
- フルパイプライン（3回のLLM呼び出し直列）：約2秒
この差はチューニングの話ではなく、オーダーが違う。どちらも同一クエリに対する計測値であり、単純に「LLMを呼ぶかどうか」だけで生じる差だ。しかも「簡単な質問」はユーザーが最も繰り返し尋ねるタイプだ。サポートデスクで1万件の契約に対して同じ50問が飛び交うような運用では、トラフィックの大部分がファストパスに流れる。コスト削減の効果もそれに比例する。
閾値はコーパスごとにチューニングが必要
記事は正直に限界も述べている。min_score=4やmin_margin=3は普遍的な定数ではなく、ドメインの語彙、質問のテンプレート化の度合い、1回答が何行にわたるかによって変わる。本記事はdoc-intelシリーズの一篇であり、シリーズ内の評価フェーズ（Article 20）で解説されているラベル付きデータセットを用いた手法と同様に、実際のコーパスで閾値を調整するのが前提とされている。
ルーター以外の最適化フロント
記事はマージンスコアによるルーティング以外にも、モデル呼び出しを減らす方向性を3つ挙げている：
- 回答キャッシュ：同じ質問が過去にあれば、ドキュメントが更新されていない限り、キャッシュを返す。取得もモデルも不要。
- 型辞書の活用：
premium→(single, amount)のように、既知の概念は辞書から回答形式を決定論的に取得できる。モデルは辞書に載っていない新規の質問にだけ使う。 - アービター結果の再利用：検索結果が明確に1行に絞れた時点で、生成ステップをスキップする（本記事のメインテーマ）。
記事はこれらを「決定論的指標でさばける多数を無料で処理し、モデルは指標で分類できないケースへのフォールバックにする」という設計思想でまとめている。エージェント型RAGへの拡張においても、この「決定論的優先、曖昧なときだけモデル」の原則は上位レイヤーにそのまま適用できるとしている。
動作確認可能なノートブックはdoc-intel/notebooks-vol1（GitHub）で公開されており、ブローカーコーパス上でルーターを実行し、質問ごとの信頼スコアとルーティング結果を確認できる。
詳細はCut an Enterprise RAG Pipeline's Latency and Cost by Calling the LLM Less, Not by Buying a Faster Modelを参照していただきたい。
