RAGアプリが本番環境で失敗する理由（そして解決策）

デモで完璧に動くRAGアプリの9割が、本番環境で壊れます。その理由と、各失敗パターンの具体的な解決策を解説します。

RAGアプリを構築した。デモは完璧だった。経営陣も感心した。そして本番リリースした。

現実が始まったのはそこからです。

ユーザーは誤った回答を受け取る。チャットボットは自信満々に間違いを答える。実際のトラフィックが来るとレイテンシが跳ね上がる。ベクトル検索が無関係なChunkを返してくる。サポートチケットが積み上がる。

これはあなただけの問題ではありません。現在のエンタープライズAIプロジェクトで最もよく見られる展開です。「デモで動く」と「本番で動く」の間に横たわるギャップ——そこでほとんどのRAGプロジェクトは死を迎えます。

この記事では、RAGの典型的な7つの失敗パターンを取り上げ、それぞれの具体的な解決策を説明します。

RAGとは何か、そしてなぜ壊れやすいのか

RAGはRetrieval-Augmented Generationの略です。LLMの学習データだけに頼るのではなく、自社のナレッジベースから関連ドキュメントを検索し、モデルが回答する前にプロンプトへ注入します。

シンプルに聞こえますが、実際は複雑です。

Ingestion、Chunking、Embedding、Retrieval、Ranking、Prompting、Generationと、パイプラインのすべてのステップが、実際のユーザーが現れるまで見えない形で壊れている可能性があります。

失敗パターン1：ChunkのサイズがMultipleの視点でずれている

これは最も頻繁に発生するミスであり、デバッグが最も難しい失敗です。なぜなら、すべてが正常に見えるからです。

ドキュメントを取り込む際、Embeddingの前にChunkに分割します。Chunkが大きすぎると、Embeddingが複数のアイデアのぼやけた平均値になり、正しいドキュメントは検索できても間違ったContextが返ってきます。逆にChunkが小さすぎると、回答を意味のあるものにする周辺Contextが失われます。

解決策： ハイブリッドなChunking戦略を採用してください。固定のトークン数ではなく、段落やセクションの境界で分割するSemantic Chunkingから始めます。次にParent-Childアーキテクチャを使用します。精度の高いRetrievalのために小さなChunkをEmbedし、LLMにはより大きな親ChunkをContextとして返します。LlamaIndexのようなライブラリを使えばこれは難しくありません。

実用的な出発点：256〜512トークンのChunk、10〜15%のOverlap、実際のクエリセットで評価。

失敗パターン2：間違った指標を測定している

ほとんどのチームは、ドキュメントに確実に入っている質問でRAGをテストします。本番環境のユーザーは、想定外の表現で質問してきます。

Evaluationフレームワークがなければ、何も見えない状態で飛行しているのと同じです。モデルのアップデート、データの更新、Promptの変更がいつシステムを壊したのかわかりません。

解決策： リリース前にEvalセットを構築してください。50〜100件の実際のまたはリアルなクエリを収集します。各クエリに対して、期待される回答と期待されるソースドキュメントを定義します。そして次の3つを測定します。

Retrieval Recall — 正しいChunkが返ってきたか？
Answer Faithfulness — LLMは取得したContentに忠実だったか？
Answer Relevance — 回答は実際に質問に答えていたか？

RAGAS、DeepEval、またはシンプルなLLM-as-judge構成でこれを自動化できます。デプロイのたびにEvalを実行してください。

失敗パターン3：EmbeddingがQueryのスタイルと一致していない

Embeddingは意味的な意味をエンコードしますが、500語の技術ドキュメントのChunkの意味と、10語のユーザークエリの意味は根本的に異なります。このミスマッチは、静かにRetrievalの品質を破壊します。

多くのチームはすべてに汎用のEmbeddingモデル（text-embedding-ada-002など）を使います。デモでは動きますが、それはデモのクエリが慎重に作られているからです。短く、曖昧で、ドメイン固有の質問をする実際のユーザーが来ると壊れます。

解決策： 短いクエリが長いドキュメントを検索するAsymmetric Searchのためにトレーニングされたモデルを使用してください。bge-large-en-v1.5とCohere embed-v3は有力な選択肢です。さらに良いのは、自社ドメインのQuery-Documentペアでモデルをファインチューニングすることです。数百件のサンプルでRetrieval Precisionを大幅に向上できます。

また確認してください："search query: "のようなクエリプレフィックスを付けるとRetrievalが改善するか？一部のモデルはこのプレフィックスを期待するようにトレーニングされています。

失敗パターン4：取得するChunk数が多すぎる（または少なすぎる）

ほとんどのRAGチュートリアルのデフォルトはtop_k=3かtop_k=5です。本番環境では、この数値が非常に重要です。

Chunkを少なく取得しすぎると重要なContextを見逃します。多く取得しすぎるとPromptがノイズだらけになり、LLMが混乱し、レイテンシが上昇し、コストが増加します。

解決策： top_kを動的にしてください。狭い事実確認クエリには3 Chunkで十分です。複雑な推論を必要とする質問には8〜12必要かもしれません。Reranker（Cohere RerankやCross-encoderモデルなど）をセカンドパスとして使用し、LLMに送る前に取得したChunkを関連性でスコアリングします。広く取得して、その後積極的に絞り込むことができます。

また：Relevanceの閾値を設定してください。取得したChunkのうち類似度スコアが0.7を超えるものがない場合、回答を作り上げるのではなく、その情報がないとユーザーに正直に伝えましょう。

失敗パターン5：PromptがモデルをContextに固定していない

Retrievalはモデルに正しい情報を与えます。しかしSystem Promptがその情報だけを使うよう明示的に指示していなければ、モデルは取得したContextと自身の（時に誤った）学習データを平気で混合させます。

これが自信満々なHallucinationが生まれる仕組みです。モデルは真実に近い何かを知っており、それを取得したContextと混合して、流暢だが誤った回答を生成します。

解決策： System Promptで明確かつ明示的に指定してください。例えば：

"あなたは有能なAssistantです。提供されたContextの情報のみを使用してユーザーの質問に回答してください。Contextに回答するための十分な情報が含まれていない場合は、明確にそう伝えてください。外部の知識は使用しないでください。"

さらに：使用したContextのどの部分を参照したか引用するようモデルに指示してください。これにより根拠付けが強制され、Hallucinationが検証可能になります。

失敗パターン6：データパイプラインが陳腐化している

RAGはRetrieval対象のドキュメントの質に直結します。本番環境では、ナレッジベースは変化し続けます——新しいポリシー、更新された価格、廃止された機能。ほとんどのチームはIngestionを一度設定して、そのまま放置します。

元データがVector Indexから乖離すると、Retrievalは古い情報を完全な自信とともに返します。これは知らないと認めるよりも悪い状態です。

解決策： IngestionパイプラインをData Productとして扱ってください。以下を組み込んで構築します：

Change Detection — ソースドキュメントが更新されたときにRe-ingestionをトリガー（Webhook、ファイル監視、データベースCDC）
Versioning — 古いコンテンツをフィルタリングできるようlast_updatedタイムスタンプでChunkにタグ付け
Monitoring — 静かなIngestion失敗のアラート（ゼロChunkを生成する壊れたPDFはよくある障害）

またEmbeddingモデルをアップグレードする際に全体をRe-embedできるよう、生のソースドキュメントをEmbeddingと一緒に保存しておいてください。

失敗パターン7：Observabilityがない

本番RAGシステムで問題が発生したとき、パイプラインのどこで壊れたかを知る必要があります。Retrieval？ Reranking？ LLMのPrompt？ Chunking戦略？

ほとんどのチームはパイプラインレベルでのLoggingを全くせずにリリースします。ユーザーが苦情を言っても、調査するものが何もありません。

解決策： すべてのステップですべてをログに残してください：

クエリ
取得したChunk（スコア付き）
Rerank後のChunk
LLMに送られた最終Prompt
LLMのレスポンス
ユーザーフィードバック（UIがあれば高評価/低評価）

LangSmith、Langfuse、またはArize Phoenixのようなツールを使用して、リクエストごとにパイプライン全体をトレースしてください。本番環境で稼働しているものには交渉の余地はありません。

RAG本番環境チェックリスト

リリース前に以下を確認してください：

[ ] Chunking戦略を実際のクエリで検証済み（開発者クエリだけでなく）
[ ] Evaluationセットを構築し、デプロイのたびに自動Evalが実行されている
[ ] Embeddingモデルをクエリ対ドキュメントの比率でテスト済み
[ ] Rerankerをセカンドパスフィルタとして設置済み
[ ] System Promptがモデルを取得したContextに明示的に固定している
[ ] IngestionパイプラインがChange Detectionで自動化されている
[ ] Relevanceの閾値を設定済み——誤った回答よりも無回答の方が良い
[ ] パイプライン全体のObservabilityとPer-requestトレーシングが整備されている
[ ] 現実的な同時負荷でのレイテンシベンチマーク実施済み
[ ] Retrieval失敗時のフォールバック動作が定義済み

アーキテクチャへの示唆

RAGはFeatureではなく、システムです。各Componentに失敗モードがあります。本番環境で成功するチームは、最高のLLMを持つチームではありません。Retrieval品質、Evalカバレッジ、パイプラインのObservabilityを初日から一級のEngineering上の関心事として扱うチームです。

良いニュースは、これらの問題はどれも解決不可能ではないということです。研究上の問題ではなく、Engineeringの問題です。あとは来ることを知っているかどうかだけです。

RAGアプリを構築中、または壊れたものを修正中ですか？

Simlicoでは、適切なEvaluation、Observability、Retrievalアーキテクチャを備えた本番グレードのAIシステム（RAGパイプラインを含む）を設計・提供しています。チームがこれらの失敗パターンのいずれかに直面している場合は、無料相談をご予約ください。問題を特定し、解決するお手伝いをします。

Simplico Engineering 発行 — AI/RAGアプリ、Eコマース、ERP、モバイル
simplico.net