本番環境のRAG：月額10,000ユーロから900ユーロへ

数千件のユーザークエリを処理するRAGパイプラインに月額10,000ユーロの推論コスト。数百万件ではない。数千件だ。これが2024年初頭、中規模欧州銀行とのキックオフで提示された数字だった。彼らのRAG POCはGPT-4で動作しており、チームは結果に満足していたが、全従業員にサービスを開放する前に予算が爆発していた。

6ヶ月後、同じ負荷、ユーザーが感じる品質も同じ：月額900ユーロ。誇張なしに、実際の数字と行った判断を説明する。

ネタバレ：これは「すべてをself-hostedに移行して魔法のように解決」というサクセスストーリーではない。妥協を前提としたハイブリッドで実用的なアプローチだ。まさにAbbealがやっていること：本番環境で機能するソフトウェアエンジニアリング。

背景：コストがかかる典型的なRAG

この銀行には正当なユースケースがあった：顧客アドバイザーが数千の規制文書、内部メモ、商品説明書から成るドキュメントベースを自然言語で問い合わせできるようにすること。典型的なRAG：ドキュメントのembedding、ベクトル検索、コンテキストを使った応答生成。

POCの初期スタック：

• Embedding：OpenAIのtext-embedding-ada-002
• Vector store：Pinecone（Starterプラン）
• LLM：GPT-4（8Kコンテキスト）
• Orchestration：LangChain、Cloud Runでホスト

ボリューム：パイロットフェーズで月間約3,000件のクエリ（アーリーアダプター50名）、クエリあたり平均4,000トークン（コンテキスト+プロンプト+応答）。合計で月額10,000ユーロ、そのうち85%がGPT-4呼び出し。

問題：この経済モデルでは500ユーザーへのスケールが不可能。推論だけで年間80-100K€の予想予算。事業側のスポンサーが難色を示し、プロジェクトは一時停止される寸前だった。

診断：どこにお金が消えているのか？

最適化の前に計測を行った。各API呼び出しに詳細なログを追加：入出力トークン、レイテンシ、単位コスト。1週間の分析での最初の発見：

• クエリの70%は単純な事実確認の質問で、GPT-4は不要だった。例：「Livret Aの金利は？」「フォームXの期限は？」など
• クエリの20%は複雑な推論や複数ドキュメントの要約が必要。真のGPT-4領域。
• クエリの10%は質問が不適切またはスコープ外で、それでもコストのかかる呼び出しを生成していた。

第二の発見：プロンプトに注入されるコンテキストが過剰だった。LangChainはデフォルトで6-8個のチャンク（各500トークン）を取得していたが、2個で十分なケースも多かった。結果：入力トークンが人為的に膨張。

戦略#1：複雑度による賢いルーティング

各クエリをsimple、medium、complexの3カテゴリに分類する軽量ルーターを実装した。複雑なfine-tuningは不要、ルールベース+手動でラベル付けした500例で学習したdistilbert分類器だけ。

• Simple → GPT-3.5-turbo（GPT-4より90%安い）
• Medium → GPT-4-turbo（GPT-4バニラの半額、コンテキストウィンドウが広い）
• Complex → GPT-4クラシック、ただしこのバケットをクエリの15%未満に削減

開発時間：分類器に3日、ルーターに2日。即座の効果：推論コストが-55%。月額10,000ユーロから4,500ユーロへ、品質の低下なし。

ルーターのコード（簡略版）

py
from transformers import pipeline

classifier = pipeline("text-classification", model="./query-complexity-model")

def route_query(query: str) -> str:
    result = classifier(query)[0]
    label = result["label"]
    score = result["score"]
    
    if label == "SIMPLE" and score > 0.8:
        return "gpt-3.5-turbo"
    elif label == "COMPLEX" and score > 0.75:
        return "gpt-4"
    else:
        return "gpt-4-turbo"  # default safe choice

革命的なものではない。平均20msで動作、コストはほぼゼロ。

戦略#2：RAGコンテキストの最適化

第二の手段：関連性を損なわずに送信トークン数を削減。retrievalチェーンを再構築した：

1. Reranking：ベクトル検索後、上位10チャンクをrerankingモデル（Sentence Transformersのcross-encoder）に通す。本当に関連性の高い2-3チャンクのみを保持。
2. コンテキスト圧縮：長いチャンクにはbart-large-cnnを使った軽いsummarizationステップを追加し、意味を失わずに情報を凝縮。
3. Prompt engineering：プロンプトをより指示的に書き直し、コンテキストの重複を避け、より簡潔な応答を要求。

結果：クエリあたりの平均トークンが4,000から2,200に減少。追加効果：残りのコストから-45%。約月額2,500ユーロに。

戦略#3：アグレッシブなキャッシングとself-hosted embeddings

まだ2つの手段が残っていた：

セマンティックキャッシュ

セマンティックキャッシュを実装：新しいクエリが既に処理されたクエリに十分近い場合（embeddingsのコサイン類似度>0.92）、キャッシュから応答を提供。Redis + RediSearchでベクトルインデックス化。

1ヶ月後のヒット率：18%。低く見えるが、3,000クエリで540回のLLM呼び出しを節約。約300ユーロの月間節約、月額50ユーロのRedisで。

Self-hosted embeddings

text-embedding-ada-002（OpenAI）をオープンソースモデルbge-large-en-v1.5に置き換え、Google CloudのGPU VM（T4）にデプロイ。VMコスト：月額150ユーロ。embedding呼び出しの節約：月額約400ユーロ。

純利益：月額250ユーロ、さらにこのコンポーネントについてOpenAIからの独立性。

戦略#4：FAQ用の小型モデルのfine-tuning

最後で最も技術的な最適化：繰り返し出現する約200の質問（内部FAQ型）のクラスターを特定。完全なRAGパイプラインを通す代わりに、これら200のQ&A + GPT-4で生成した1,000の合成例でMistral-7Bをfine-tuning。

このモデルをCPU VM経由で提供（量子化Q4_K_Mを使った推論にGPUは不要）。レイテンシ：平均800ms。限界コスト：ほぼゼロ、VMは他のサービスでも稼働中。

ルーターがクエリがFAQにマッチするか検出し（シンプルなElasticsearchインデックス経由）、マッチすればfine-tuningされたMistralに切り替え。クエリの約12%をカバー。追加節約：月額400ユーロ。

数字でのまとめ：10,000ユーロから900ユーロへ

累積効果のまとめ：

• 賢いルーティング：-5,500ユーロ
• RAGコンテキスト最適化：-2,000ユーロ
• セマンティックキャッシュ：-300ユーロ
• Self-hosted embeddings：-250ユーロ
• FAQ fine-tuning：-400ユーロ
• 追加インフラコスト（VM、Redis）：+350ユーロ

合計：月額900ユーロ、つまり91%の削減。総開発時間：約6人週、4ヶ月にわたって実施（各ステップでA/Bテストを行いながら慎重に反復）。

学んだこと（そして別のやり方）

具体的な経験からのフィードバック：

• 最適化の前に計測すること。実際の数字を得る前に、誤った部分の最適化に2週間を無駄にした。
• 賢いルーティングが手段#1。一つだけやるなら、これをやること。即座のROI、リスクは低い。
• Rerankingを過小評価しないこと。RAGの精度を大きく変えるゲームチェンジャーで、コストはゼロ。
• Self-hosting：社内にMLOpsスキルが既にある場合のみ実行。そうでなければ、隠れたコスト（保守、監視、デバッグ）がすぐに利益を食いつぶす。
• Fine-tuning：本当に繰り返し発生し、明確に識別されたクエリのクラスターがある場合のみ採算が取れる。そうでなければ時間の無駄。

やり直すなら、POC段階からルーティング+rerankingを開始していただろう。プロジェクト中盤の予算パニックを避けられたはずだ。

結論：ハイブリッド>教条主義

「すべてオープンソースでself-hosted」または逆に「すべてSaaS managed」という主張をよく見かける。現実には、ハイブリッドアプローチが最も実用的であることが多い：複雑なユースケースにはmanaged API、コモディティ化されたコンポーネントにはself-hosted、繰り返しパターンにはターゲットを絞ったfine-tuning。

このRAGプロジェクトは4ヶ月前からクライアントの本番環境で稼働しており、500人以上のアクティブユーザーがいて、インフラ予算は月額1,200ユーロ以下に留まっている。社内チームが日常的な保守を引き継ぎ、機能拡張については必要に応じてサポート介入している。

予算が爆発しているRAGプロジェクトを抱えている、またはPOCフェーズでこの罠を避けたい場合、類似プロジェクト4-5件でこのアプローチを磨いてきた。Abbealでは請負作業を売っているわけではない：具体的な問題を解決し、スキルを移転し、終わったら去る。話をしよう。