イントロダクション：RAG開発における「評価の壁」
「PoC（概念実証）ではうまくいったんです。でも、本番データを入れた途端、回答がおかしくなって……修正すればするほど、別のどこかが壊れていくんです」
これは最近、AI導入の現場で頻繁に耳にする課題です。
生成AI、特にRAG（検索拡張生成）を用いたアプリケーション開発において、多くのプロジェクトが直面する最大のボトルネック。それは、モデルの選定でもプロンプトエンジニアリングでもなく、実は「評価」にあります。
AI導入コンサルタントの視点から言えば、「評価なき改善は、目隠しでダッシュするようなもの」です。顧客体験の向上と業務効率化を両立させるためには、データドリブンな評価基盤が欠かせません。
PoCの成功が本番運用の悪夢に変わるとき
初期段階、例えばテストデータが50件程度のときは、エンジニアやPMがExcelシートを片手に「この回答はOK」「これはNG」と目視でチェックすれば足ります。みんなでワイワイ言いながらプロンプトを調整するのは、正直楽しい時間でもあります。
しかし、対象ドキュメントが数千ページになり、想定質問が数百パターンに増えたとき、その楽しさは悪夢に変わります。
「ハルシネーション（もっともらしい嘘）を減らすためにプロンプトで『厳密に答えろ』と指示したら、今度は回答が素っ気なくなりすぎて、ユーザーからの評判が落ちた」
「特定の製品スペックについて正しく答えられるように調整したら、なぜか返品ポリシーについての回答が崩れた」
いわゆるリグレッション（退行）です。これを防ぐには、修正のたびに全パターンのテストを行う必要がありますが、人間が手作業で数百件の回答を毎回チェックするのは物理的に不可能です。結果として、「怖くてプロンプトを触れない」「ドキュメントの更新が遅れる」という事態に陥り、プロジェクトは塩漬けになります。
なぜ「人手による評価」は破綻するのか
人間による評価には、時間的コスト以外にも致命的な欠点があります。
- 評価基準の揺らぎ: Aさんは「丁寧で良い」と評価し、Bさんは「冗長で悪い」と評価する。その日の気分や疲労度でも変わります。
- スケーラビリティの欠如: データ量が10倍になれば、評価工数も10倍になります。ビジネスの成長スピードに追いつけません。
- フィードバックサイクルの遅延: 評価に3日かかれば、改善サイクルも3日に1回しか回せません。AI開発において、この遅さは致命傷です。
だからこそ、「LLM-as-a-Judge（審査員としてのLLM）」、つまりAIによる自動評価システムの構築へと舵を切る必要があるのです。今回は、実務の現場で構築されることが多い、RAGASを活用した評価パイプラインの裏側や、よくある失敗例について解説します。
Q1: なぜ既存の評価手法ではなく「RAGAS」を選んだのか？
―― 以前は自然言語処理（NLP）の評価といえば、BLEUスコアなどが一般的でした。なぜRAGASというフレームワークが選ばれるのでしょうか？
橋本: 多くの開発現場では、翻訳タスクなどで実績のあるBLEUやROUGEといった従来の指標を最初に検討しがちです。しかし、RAG（検索拡張生成）の評価において、これらの指標だけでは不十分であることが明らかになっています。
BLEUやROUGEスコアでは測れない「意味」の評価
BLEUスコアなどは、基本的に生成されたテキストと正解テキスト（参照文）の間で、単語（n-gram）がどれくらい重なっているかを見る指標です。しかし、最新のLLMを用いたチャットボットにおいて、「正解と表現は違うが、意味は合っている」というケースは頻繁に発生します。
例えば、「営業時間を教えて」という質問に対し、正解データが「午前9時から午後6時までです」だったとします。
AIが「9:00〜18:00で営業しております」と答えた場合、意味は完璧ですが、単語の重なりが少ないため従来のスコアは低く出ることがあります。逆に、AIが「午前9時から午後6時までは定休日です」と答えたら、単語はほぼ一致しているのでスコアは高くなりますが、内容は真逆の大嘘（ハルシネーション）です。
RAGにおいて最も警戒すべきは、この「流暢な嘘」です。単語の一致率を見るだけの指標では、これを見抜くことが難しく、「スコアは改善しているのに、ユーザー体験は向上しない」という矛盾が生じやすくなります。
構成要素別評価（Retrieval vs Generation）の重要性
そこで、現在のRAG開発で標準的に採用されているのがRAGAS（Retrieval Augmented Generation Assessment）のようなフレームワークです。これを選定する最大の理由は、RAGのプロセスを「検索（Retrieval）」と「生成（Generation）」に分解して評価できる点にあります。
RAGが誤った回答をする原因は、大きく分けて2つあります。
- 検索の失敗: そもそも質問に関連するドキュメントをベクトルデータベースから取得できていない。
- 生成の失敗: ドキュメントは正しいのに、LLMがそれを読み間違えたり、無視して勝手なことを言ったりする。
従来の評価では、最終的な回答だけを見て判断していましたが、これでは検索ロジック（チャンクサイズや埋め込みモデル）を直すべきなのか、生成プロンプトを直すべきなのか切り分けができません。
RAGASを活用すれば、「Faithfulness（忠実性）」で生成の質を、「Context Recall（コンテキスト再現率）」で検索の質を、それぞれ個別に数値化できます。また、RAGASは評価自体にLLMを使用する「LLM-as-a-Judge」のアプローチを採用しており、単語の一致ではなく「意味的な正しさ」を判定できるため、より人間に近い感覚での評価が可能になります。これにより、具体的な改善アクションが明確になり、開発サイクルを適正に回せるようになるのです。
Q2: 「グラウンディング精度」をどう定義し、測定しているか
―― RAGの信頼性を担保する上で重要な「グラウンディング（根拠に基づく回答）」ですが、現場では具体的にどう測定されていますか？
橋本: グラウンディング精度こそが、企業向けAIにおける生命線です。クリエイティブな文章生成なら多少の飛躍も面白いですが、カスタマーサポートで規約にないことを約束されたら大事故ですからね。
実務においては、主にRAGASのFaithfulness（忠実性）という指標が最重要視されます。
「もっともらしい嘘」を見抜くための指標設計
Faithfulnessは、「生成された回答に含まれる主張のうち、どれだけが検索されたコンテキスト（根拠ドキュメント）から導き出せるか」を測定します。
具体的には、裏側でLLMを使って以下のような処理を行わせます。
- AIの回答から、いくつかの「主張（Statements）」を抽出する。
- それぞれの主張が、検索されたコンテキストの中に根拠として存在するかを検証する。
- 根拠がある主張の割合をスコア化する（0〜1）。
例えば、AIが「このプランは月額500円で、初月無料です」と回答したとします。
コンテキストに「月額500円」という記述はあるが、「初月無料」という記述がどこにもなければ、Faithfulnessスコアは下がります。これがまさにハルシネーションの検知です。
現場で徹底されるべきルールは、「Answer Relevance（回答の関連性）が高くても、Faithfulnessが低ければリリースしてはいけない」ということです。質問に対して的確な答え（Relevanceが高い）であっても、それが嘘（Faithfulnessが低い）であれば、企業としての信用に関わるからです。
Context RecallとContext Precisionのトレードオフ
もう一つ、検索部分の評価で苦労するのがContext Recall（再現率）とContext Precision（適合率）のバランスです。
- Recall: 正解を導くために必要な情報が、検索結果に含まれているか。
- Precision: 検索結果の中に、無駄なノイズが含まれていないか。
初期段階で「とにかくRecallを上げよう」として、検索取得数（top_k）を増やすケースがあります。そうすると必要な情報は取れるようになりますが、同時に無関係なノイズも大量にLLMに渡すことになります。
結果として、LLMがノイズ情報に引っ張られて混乱し、逆に回答精度が落ちる現象が起きます。いわゆる「Lost in the Middle（情報の埋没）」問題です。
一般的なアプローチとしては、RAGASのスコアを見ながら、「top_k=5あたりがRecallとPrecisionの最適解だ」と判断したり、「リランキング（再順位付け）処理を挟むことでPrecisionを上げよう」といったチューニングが行われます。この意思決定を、感覚ではなく数値に基づいて行えるのが定量的評価の強みです。
ただし、これを実現するには「Golden Dataset（正解データセット）」の準備が不可欠です。「質問」と「理想的な回答」、そして「根拠となるべきドキュメント」のセットを作る。正直、このデータセット作成がプロジェクトの中で一番泥臭く、一番コストがかかる部分です。ここをサボると、どんなに高度な自動評価ツールを入れても意味がありません。
Q3: 自動評価パイプラインの構築とCI/CDへの統合
―― 評価手法が決まっても、それを継続的に回すのは大変そうです。どのように自動化されているのでしょうか？
橋本: おっしゃる通り、手動でスクリプトを回しているうちは運用とは言えません。実務の現場では、GitLab CI（またはGitHub Actions）を使って、コードやプロンプトが変更されるたびに自動で評価が走るパイプラインが構築されます。
プロンプト変更時のリグレッションテスト自動化
開発フローはこうです。
- エンジニアがプロンプトを修正し、プルリクエスト（PR）を出す。
- CIツールが検知し、自動的に評価スクリプトを実行。
- RAGASを使って、テストデータセット（例えば100問）に対する回答を生成し、スコアを算出。
- 前回のスコアと比較し、「Faithfulnessが0.1ポイント低下しました」といったレポートをPRにコメント。
- スコアが閾値を下回っていれば、マージをブロックする。
これにより、「良かれと思って修正したら、全体として品質が下がった」というコードが本番に混入するのを防げます。いわば、ソフトウェア開発における単体テストや結合テストと同じことを、LLMアプリでもやっているわけです。
コストと実行時間のバランスをどう取るか
ここで最大の課題になるのが「コスト」です。
RAGASの評価には、審査員としてChatGPTなどの高性能モデルを使うのが推奨されています。しかし、プルリクエストのたびに100問×複数の指標をChatGPTで評価していたら、API利用料だけで月に数十万円、場合によっては数百万円が吹き飛びます。また、実行時間もバカになりません。
一般的なコスト削減策としては、以下のようないくつかのアプローチがあります。
- スモークテストの導入: 全件テストは夜間の定期実行（Nightly Build）のみにし、PRごとの実行は重要度の高い20問程度に絞る。
- モデルの使い分け: 複雑な論理判断が必要なFaithfulnessの評価にはChatGPTを使うが、単純な関連性チェックにはGPT-3.5や、安価なClaudeモデルなどを使う。
- キャッシュの活用: プロンプトや検索ロジックに変更がない場合、過去の評価結果を再利用する。
「精度のためのコスト」と「開発のスピード」のバランスをどう設計するか。ここはエンジニアリングマネージャーの腕の見せ所です。プロジェクトのフェーズに合わせてテストの網羅率を調整することが求められます。
Q4: RAGASスコアの「落とし穴」と人間による評価の役割
―― 自動化が進めば、人間による評価は不要になるのでしょうか？
橋本: いえ、絶対に不要にはなりません。むしろ、自動評価が進むほど、人間による定性評価の重要性は増します。
RAGASのスコアには「落とし穴」があります。それは、「人間味」や「ブランドトーン」を評価できないことです。
スコアが高いのにユーザー満足度が低いケース
例えば、RAGASの全スコアが素晴らしい数値を叩き出したモデルをリリースしようとしたとします。しかし、最終確認で実際に触ってみると、問題が発覚することがあります。
回答が極めて機械的で、冷たかったのです。
「申し訳ありませんが、その情報は不明です」とだけ突き放す回答。事実は正確（Faithfulnessは高い）ですし、質問への回答にもなっています（Relevanceも高い）。しかし、カスタマーエクスペリエンスの観点からは不十分です。「お困りのことと存じますが、現時点での資料には記載がございません。担当部署へお問い合わせいただけますでしょうか？」といった配慮が欠けていました。
また、逆のケースもあります。RAGASが「回答に関連性がない」と低いスコアをつけた回答が、実はユーザーの潜在ニーズを汲み取った素晴らしい回答だった、ということもあります。
最終的な品質保証におけるヒューマン・イン・ザ・ループ
自動評価はあくまで「足切り」です。明らかなハルシネーションや、的外れな回答をフィルタリングするためのざるです。
実際の運用では、以下のようなハイブリッド体制をとることが推奨されます。
- 自動評価（Level 1）: CIパイプラインでRAGASスコアを計測。閾値以下のものは即修正。
- サンプリング目視（Level 2）: 自動評価をパスしたものの中から、ランダムに（またはスコアが境界線上のものを）人間が抽出してチェック。
- UX評価（Level 3）: 定期的に実際の会話ログを分析し、「冷たい表現はないか」「ブランドイメージに合っているか」をCS担当者がレビュー。
ツールを過信せず、かといって人手に頼りすぎず。このバランス感覚こそが、持続可能なRAG運用には不可欠です。
編集後記：評価駆動開発（EDD）がRAGの進化を加速させる
RAG開発においては「評価なくして改善なし」という鉄則があります。
テスト駆動開発（TDD）ならぬ、評価駆動開発（Evaluation Driven Development: EDD）。
まず「何を良しとするか」という評価基準（データセットとメトリクス）を定め、そのスコアを上げるために実装を行う。このサイクルが確立できれば、RAGプロジェクトは「終わりのないモグラ叩き」から脱却し、着実な進化の道を歩めるようになります。
評価基盤の整備は、決して派手な作業ではありません。地味で、面倒で、コストもかかります。しかし、ここを乗り越えたチームだけが、ユーザーに真の価値を届けるAIプロダクトを生み出せるのです。
もしプロジェクトが「修正のたびに何かが壊れる」状態にあるなら、一度立ち止まって、評価の自動化に投資することが重要です。それは結果として、顧客体験の向上と業務効率化の両立につながります。
コメント