RAGのデモをつくるのは簡単です。LLMをベクトルストアに接続し、答えをすでに知っている質問を投げかけて、それが動くのを眺めるだけです。しかし、顧客の前に出せるRAGシステムはまったく別の問題です。失敗のパターンは静かに現れ、リスクは現実的で、「試したときはうまくいった」という事実は、本番環境でどう振る舞うかについてほとんど何も教えてくれません。
グラウンディングは、モデルの問題である前にデータの問題である
RAGの品質問題の多くは、生成ではなく検索（retrieval）に起因します。チャンク分割の戦略、埋め込み（embedding）の鮮度、そしてインデックスが元の文書構造をどれだけ正確に反映しているか——これらは、その上に載せるモデルの選択よりも重要です。プロンプトを調整する前に、私たちはまず、そもそも正しい文書の断片が検索結果として取得されているかどうかを徹底的に確認します。ここができていなければ、どれだけプロンプトエンジニアリングを重ねても回答は改善しません。
「なんとなく」ではなく、実際のタスクで評価する
「良さそうに見える」は指標ではありません。本番環境のRAGシステムには、既知の正解を持つ実際の質問からなるゴールデンセットが必要であり、検索ロジック、プロンプト、モデルバージョンなど、パイプラインへのあらゆる変更に対して自動的に実行されるべきです。私たちはグラウンディング度（回答が実際に取得されたコンテキストに基づいているか）、関連性、そしてハルシネーション率を追跡し、これら三つのいずれかが悪化した場合は、CIでのテスト失敗と同様にリリースをブロックする問題として扱います。
安全にリリースできるようにするのがガードレール
元の文書箇所にリンクする引用機能、システムの対象範囲外の質問に対する明確な拒否動作、そして検索されたコンテキストとモデルの出力の両方における個人情報（PII）の明示的な取り扱い——これらは「あれば嬉しい」機能ではなく、気の利いたプロトタイプを法務・セキュリティチームが実際に承認できるものへと変える要素です。
本当の学びは本番環境で得られる
リリースしたら終わりではありません。ソースドキュメントが変化するにつれて検索品質はドリフトしていきます。ユーザーの質問も、当初のゴールデンセットが想定していなかった形で進化していきます。私たちは本番トラフィックにまさにこのための計測を組み込んでいます——実際のクエリをサンプリングし、確信度の低い回答をレビュー対象としてフラグ付けし、そのシグナルを定期的に評価セットへフィードバックする。こうすることで、システムは静かに劣化していくのではなく、時間とともにより信頼できるものになっていきます。
これはより高性能なモデルを選ぶという話ではありません。顧客が本当に信頼する生成AIをリリースできるチームとは、グラウンディング、評価、ガードレールを、他のどんな本番システムにも適用するのと同じ厳格さを持った、第一級のエンジニアリング課題として扱うチームなのです。