導入：なぜRAGの評価は「人力」だと破綻するのか？
RAG（検索拡張生成）システムの回答精度を、どのように担保していますか？
もし、「エンジニアやプロジェクトメンバーがスプレッドシートに生成結果を貼り付け、一つひとつ目視で確認している」という状況であれば、この記事が転機となるはずです。数百件のログを目視確認し続け、夕方には判断力が鈍ってしまう。こうした現場の疲弊は、プロジェクトの進行において決して珍しい話ではありません。
終わらない目視チェックの罠
PoC（概念実証）の初期段階であれば、数十件の質問を目視で確認するのは有効なアプローチです。モデルの挙動を肌感覚で理解できるからです。
しかし、本番運用を見据えてデータ量が増えたり、GraphRAG（導入時は公式リポジトリ等で最新仕様を確認してください）などの高度な検索手法や、エージェント型RAGといった複雑なアーキテクチャを採用したりするフェーズに入ると、手作業による全件テストは非効率極まりないものになります。例えば、参照ドキュメントを更新するたび、あるいはプロンプトを少し調整するたびに、すべてを手動で再確認することは物理的に困難です。
結果として、「おそらく問題ないだろう」という感覚値でリリースし、ユーザーから「ハルシネーション（もっともらしい嘘）が含まれている」と指摘を受けるリスクが高まります。これはビジネス上のROI（投資対効果）を損なう要因にもなり得ます。
主観による評価ブレが招くリスク
さらに深刻なのが「評価基準のブレ」です。
例えば、ある担当者は「意味が通じればOK」と判断する一方、別の担当者は「参照元に忠実でない」としてNGを出すケースがあります。あるいは、同じ担当者でも、その日のコンディションによって判定基準が変わることもあり得ます。
これでは、システムを改修した結果、性能が向上したのか低下したのか、定量的に判断することが困難です。プロジェクトマネジメントやエンジニアリングにおいて「計測できないものは改善できない」というのは鉄則です。
AIをAIで評価する「RAGAS」という選択肢
そこで導入を検討したいのが、RAGAS（Retrieval Augmented Generation Assessment） という評価フレームワークです。
これは、「LLMが生成した回答を、別のLLM（評価用モデル）を使って検証させる」というアプローチです。「AIの回答をAIに評価させることに妥当性はあるのか？」という疑問を持たれるかもしれませんが、RAGASは評価指標（メトリクス）が体系化されており、人間よりも高速かつ一貫した基準でスコアリングできる点が強みです。
特に、以下の主要な指標はRAGの品質管理において標準的になりつつあります：
- Faithfulness（忠実性）: 回答が検索されたコンテキストに基づいているか
- Answer Relevancy（回答関連性）: 質問に対して適切な回答になっているか
- Context Precision（コンテキスト適合率）: 必要な情報が正しく検索できているか
この記事では、RAGASを活用して目視評価から脱却し、効率的な開発サイクル（LLMOps）を構築するための実践的なヒントを提示します。コードの細かい実装よりも、まずは運用の勘所を押さえることが重要です。
※RAGASや関連ライブラリは頻繁にアップデートされています。具体的な実装手順や最新の対応モデル、評価指標の詳細については、必ず公式ドキュメント（docs.ragas.io）を直接参照して最新情報を確認してください。
Tip 1：まずは「Faithfulness（忠実性）」だけでいい
RAGASには多くの評価指標（メトリクス）が用意されています。ドキュメントを見ると、Faithfulness, Answer Relevance, Context Precision, Context Recall...と並んでいて、全てを実装しなければならないのかと考えるかもしれません。
まずは 「Faithfulness（忠実性）」 ひとつに絞って導入することをお勧めします。
ハルシネーションを検知する最重要指標
Faithfulnessは、「その回答は、検索してきたドキュメント（コンテキスト）に基づいているか？」を測る指標です。
RAGにおいて最も避けたいリスクは、AIがもっともらしい嘘をつく「ハルシネーション（幻覚）」です。社内規定に記載されていないことを勝手に捏造して回答された場合、業務システムとしては大きな問題となります。
Faithfulnessスコアが低ければ、それは「検索結果に含まれていない情報を、LLMが作り出した」可能性を示唆します。
「検索結果にある情報だけで答えているか」を機械的に判定
RAGASの仕組みでは、LLMを用いて以下のステップで判定を行います。
- 生成された回答から、主張（Statements）を抽出する。
- それぞれの主張が、検索されたコンテキスト（Context）によって裏付けられるかを確認する。
- 裏付けられた主張の割合をスコア（0～1）として算出する。
人間がこれを行う場合、検索された複数のドキュメントを読み込み、回答と突き合わせる必要があり、膨大な時間がかかります。RAGASならこれを自動で実行できます。
複雑に考えず、まずはこの1指標から自動化する
「回答がユーザーの意図に合っているか」も重要ですが、まずは「嘘をついていないか」を担保するのが実用的なRAG構築の第一歩です。
Faithfulnessのスコアを毎日モニタリングするだけでも、「プロンプト変更でハルシネーションが増加した」ことに気づける可能性があります。これだけでも、開発チームの安心感は大きく向上します。
Tip 2：ユーザーの「問い」に答えているかを測る
Faithfulnessで「嘘をつかない」状態を作れたら、次に気にすべきは「会話が成立しているか」です。
ここで役立つのが 「Answer Relevance（回答関連性）」 という指標です。
Answer Relevance（回答関連性）の活用法
例えば、ユーザーが「今月の交通費の申請期限はいつ？」と質問したとします。
AIが「交通費の申請には領収書が必要です。指定のシステムから入力してください」と答えた場合、どうでしょうか？
書かれている内容は事実（Faithfulnessは高い）かもしれません。しかし、ユーザーが知りたい「いつ（期限）」には答えていません。これではユーザー体験（UX）は低下してしまいます。
Answer Relevanceは、生成された回答が「元の質問に対してどれだけ適切な応答になっているか」を評価します。
正しいけれど「会話が噛み合っていない」を防ぐ
RAGASはこの指標を算出するために、「生成された回答から、逆に質問を生成し、元の質問とどれくらい似ているか」を評価します（逆生成アプローチ）。
もし回答が適切であれば、そこから生成される質問は元の質問と近くなるはずです。逆に、不適切な回答からは、元の質問とは異なる質問が生成されてしまいます。
質問の意図を汲み取れているかの自動チェック
このスコアが低い場合、原因は検索精度ではなく、プロンプトにあることが多いです。「質問に対して簡潔に答えてください」「日付を含めてください」といった指示をプロンプトに追加することで改善できる可能性があります。
Faithfulnessで「守り」を固め、Answer Relevanceで「使いやすさ」を向上させる。この2軸があれば、最低限の品質は担保できます。
Tip 3：検索精度は「Context Precision」で可視化する
RAGシステムで回答がおかしい時、原因は大きく2つに分かれます。
- Generation（生成）の問題: LLMが情報をうまくまとめられなかった。
- Retrieval（検索）の問題: そもそも必要な情報が検索できていなかった、あるいは不要な情報ばかり検索してしまった。
Tip 1, 2は「生成」の評価に近いですが、RAGの重要な要素である「検索」そのものの質を測るのが 「Context Precision（コンテキスト適合率）」 です。
ゴミ情報が混ざっていないかチェック
Context Precisionは、検索結果（例えば上位5件のチャンク）の中に、正解にたどり着くために必要な情報がどれだけ上位に含まれているか（ランク付けの精度）を評価します。
もし、検索結果の上位に無関係なドキュメント（ノイズ）が混ざっていると、LLMは混乱する可能性があります。コンテキストウィンドウの無駄遣いにもなりますし、ハルシネーションの原因にもなります。
回答生成前の「検索フェーズ」を評価する
このスコアが低い場合は、LLMのプロンプトを調整するのではなく、以下の対策が必要です。
- チャンクサイズの変更（文章の切り方を変える）
- 埋め込みモデル（Embedding Model）の変更
- ハイブリッド検索（キーワード検索とベクトル検索の併用）の導入
- リランク（Re-ranking）処理の追加
チャンク分割や検索アルゴリズム見直しのきっかけに
「回答が不適切だ」という現象に対して、闇雲にプロンプトを修正するのではなく、「Context Precisionが低いから、検索周りを見直そう」と冷静に判断できるようになります。
これができるようになると、開発チーム内の議論も「なんとなく」から「データに基づく」論理的な議論へと進化します。
Tip 4：テストデータセットは「黄金の20問」から
RAGASのような自動評価を導入しようとすると、課題となる点があります。
「評価するための正解データ（Ground Truth）がない」という問題です。
自動評価するには、「質問」と、それに対応する「理想的な回答（Ground Truth）」のペアが必要です。
いきなり数百件を用意する必要はない
完璧主義を発揮して、「ドキュメント全体を網羅する多数の質問を作成しよう」とすると、プロジェクトが停滞する可能性があります。
まずは実践的なアプローチとして、「黄金の20問」を作成する ことをお勧めします。
- ユーザーから頻繁に来るであろう質問トップ10
- 間違えるとリスクが高い質問トップ5
- 過去に誤回答して問題になった質問トップ5
この20問だけで、人間がしっかりと精査した「模範解答」を作成します。これを評価セットの核（ゴールデンセット）にします。
典型的な質問と理想的な回答（Ground Truth）のペアを作る
20問でも、システム改修時に「少なくともこの重要ポイントは問題ないか」を確認するリグレッションテストとして十分に機能します。
自動生成でテストデータを作る機能の活用
さらに、RAGASには Synthetic Test Data Generation（合成テストデータ生成） という機能があります。これは、ドキュメントを読み込ませると、LLMが「質問」と「正解（Ground Truth）」のペアを作成する機能です。
自動生成されたものなので完璧ではありませんが、網羅性を高めることができます。「黄金の20問（人間作成）」＋「自動生成の質問」を組み合わせることで、効率よくテストデータセットを構築できます。
Tip 5：スコアの「絶対値」より「推移」を見る
最後に、運用上の重要な考え方をお伝えします。
RAGASが出したスコア（例えば Faithfulness: 0.85）という数字そのものに、過剰にこだわらないでください。「0.9を目指せ！」と目標値を設定するのは、初期段階ではあまり意味がありません。
0.8か0.9かに一喜一憂しない
LLMによる評価自体にも多少の変動はありますし、0.85が良いのか悪いのかは、ドメインや質問の難易度によって変わるためです。
重要なのは「絶対値」ではなく 「推移（差分）」 です。
プロンプト変更前後での変化量（デルタ）を追う
- 先週は 0.85 だった。
- 今週プロンプトを修正したら 0.82 に下がった。
この「下がった」という事実が重要です。「何か改悪（リグレッション）をしてしまったのではないか？」というアラートとして機能するためです。
逆に、新しい検索アルゴリズムを入れたら 0.85 → 0.88 に上がったなら、「この施策は正しい方向性だ」と論理的に判断できます。
CI/CDパイプラインへの組み込みイメージ
理想的には、コードをGitにプッシュしたら自動的にRAGASが実行され、スコアが急激に低下していたらアラートが通知される、というCI/CD（継続的インテグレーション/継続的デリバリー）環境を構築することです。
ここまでいけば、エンジニアは「評価」という作業から解放され、「改善」に集中できるようになります。
まとめ：評価を自動化して「改善」にリソースを使おう
RAG開発において、目視評価は必要な過程ですが、そこに留まるべきではありません。
- Faithfulness で嘘を防ぐ。
- Answer Relevance で会話の噛み合いを見る。
- Context Precision で検索の質を評価する。
- 黄金の20問 からスモールスタートする。
- スコアの推移 を見て改善の方向性を確かめる。
この5つのステップを踏むだけで、開発効率は飛躍的に向上します。
人間は人間にしかできない判断に集中する
自動評価ツールを導入する目的は、単なる効率化だけではありません。時間を有効活用し、「ユーザーは何を求めているのか？」「ビジネス課題を解決するためにどんな体験を提供すべきか？」といった本質的な問いに向き合うためです。
RAGASはツールですが、適切に活用すれば強力なパートナーとなります。まずは「黄金の20問」を作成することから始めてみてください。皆さんのプロジェクトがより良い方向へ進むことを願っています。
コメント