TECH BLOG

近年、LLM（大規模言語モデル）の実用化において、RAG（Retrieval-Augmented Generation）は標準的なアーキテクチャとしての地位を確立しました。なぜこれほどまでにRAGが注目されているのでしょうか。その理由は主に以下の2点に集約されます。

• ハルシネーション（幻覚）の抑制:
  LLM単体では防ぎきれない「もっともらしい嘘」を、外部データベースに基づいた回答生成を行うことで大幅に削減できます。
• 学習コストの削減と柔軟性:
  ファインチューニングのようにモデル自体のパラメータを更新（再学習）する必要がありません。同一のLLMを使い続けたまま、外部データの差し替えだけで専門領域の拡張や情報の更新が可能なため、運用・保守のコストを抑えやすいという利点があります。

しかし、RAGシステムが普及するにつれて、新たな壁が立ちはだかっています。
それが「評価の難しさ」です。

今回紹介するサーベイ論文『Retrieval Augmented Generation Evaluation in the Era of Large Language Models』では、RAGの評価における現状の課題として、以下の4点を指摘しています。

• LLMベース評価のブラックボックス性:
  近年、評価自体にLLMを用いる手法が増えていますが、その判定プロセスはブラックボックスになりがちです。LLMの不安定さやセキュリティリスクが、評価の信頼性に影響を与える可能性があります。
• 評価コストの高騰:
  ツールやデータセットが大規模化しており、徹底的な評価を行おうとすると金銭的・計算的なコストが非常に高くなってしまうのが現状です。
• 統合的な評価指標の欠如:
  OpenAIのo1モデルのような「深い思考（Deep Thinking）」を行うモデルや、検索・生成が複雑に絡み合うプロセス全体を、機能単位で分解して評価できる統括的な指標がまだ確立されていません。
• 言語的な偏り:
  現在の主要な評価フレームワークは、英語や中国語など一部の言語に偏っており、多様な言語をカバーできていないという課題があります。

本記事では、この論文をベースに、現在利用可能なRAGの評価指標を網羅的に紹介し、これらの課題に対してどのように向き合うべきかを解説します。

今回参考にさせていただいた論文はこちらです。

https://arxiv.org

• RAG構築を検討・実施しているエンジニア
• 社内チャットボット導入の担当者
• RAGの検証方針に迷っている人

RAGの評価指標は多岐にわたりますが、闇雲に測定しても意味がありません。この論文では、評価の視点を「内部評価（Internal Evaluation）」と「外部評価（External Evaluation）」の2つに大別して整理しています。

これは、自動車の検査に例えるとわかりやすいでしょう。

• 内部評価: エンジンの回転数やブレーキの効き具合など「部品（コンポーネント）の性能」をチェックすること。
• 外部評価: 実際に公道を走って、乗り心地や燃費、事故を起こさないかなど「完成車としての品質」をチェックすること。

内部評価は、RAGシステムを構成する機能の技術的な性能に焦点を当てます。
RAGは主に「検索（Retrieval）」と「生成（Generation）」という2つのプロセスから成り立っており、それぞれ以下の観点で評価されます。

• 関連性 (Relevance): クエリの意図に合ったドキュメントを取得できているか？
• 包括性 (Comprehensiveness): 必要な情報を漏れなく網羅できているか？
• 正確性 (Correctness): ノイズを含まず、正解となるドキュメントをピンポイントで取得できているか？

• 関連性 (Relevance): ユーザーの質問に対して、的を射た回答になっているか？
• 忠実さ (Faithfulness): 検索されたドキュメントの内容に基づいているか？
• 正確性 (Correctness): 回答の内容自体が事実として正しいか？

これらをまとめた概念図が以下になります。

外部評価は、RAGシステム全体を一つの「ブラックボックス」として捉え、実運用における「実用性（Utility）」を測るプロセスです。ここでは、コンポーネントごとの技術的なスコア以上に、ビジネス価値やユーザー体験（UX）に直結する指標が重視されます。

システムが予期せぬ入力や悪意ある操作に対して、どれだけ安全かつ信頼性を保てるかを評価します。

• 堅牢性 (Robustness)
  検索結果にノイズや誤った情報が含まれていた場合でも、それに惑わされず正確な回答を維持する能力。
• 事実性 (Factuality)
  正確な事実に基づいた情報を生成し、もっともらしいが誤った記述（ハルシネーション）を回避する性能。
• 公平性 (Fairness)
  検索された参照文書にバイアスが含まれている場合であっても、偏りを排除し、中立的で公平な回答を生成する能力。
• 透明性 (Transparency)
  回答に至るプロセスや参照元が明確であり、ブラックボックス化せずに説明責任を果たせる状態であるか。

実運用において、システムがどれだけパフォーマンス良く、かつ経済的に動作するかを評価します。

• 速度 (Latency)
  ユーザー体験を損なわない、ストレスのないレスポンス速度（特にTime to First Token）の確保。
• 費用 (Cost)
  LLMのトークン課金やインフラ費用などの運用コストが、システムから得られるビジネス価値に見合っているかの経済的妥当性。

次は「どうやって測定するか（How）」という具体的な評価指標（Metrics）の話に移ります。

現在のRAG評価指標は、歴史的背景から大きく2つのグループに分けられます。

• 従来の評価指標 (Traditional Metrics):
  • 検索器や翻訳AIの分野で確立された、数理的・統計的な計算に基づく指標です。
  • 特徴: 計算が高速で客観的ですが、「正解データ（Ground Truth）」が必要になるケースが多いです。
• LLMベースの評価指標 (LLM-based Metrics):
  • LLM自体に「審査員」の役割をさせ、意味や文脈を判定させる新しい手法です。
  • 特徴: 「正解データ」がなくても評価可能ですが、コストがかかり、判定がブラックボックスになりがちです。

次のセクションからは、これらの指標を「検索」と「生成」のコンポーネントごとに詳しく解説していきます

検索器が「正しいドキュメント」を取得できたかを評価する、IR（Information Retrieval）分野の伝統的な指標です。

LLMが生成したテキストの品質を、正解データ（Ground Truth）と比較して評価します。

LLM自体を審査員（Judge）として利用し意味や文脈、ハルシネーションを評価する新しい手法です。

RAGシステムが「答えられない質問」に対して適切に振る舞えるか（リスク管理）を評価する4つの指標です。以下の4象限マトリクスに基づいて計算されます。

評価指標まとめ表

内部評価が「技術的な性能」を測定するのに対し、外部評価はシステム全体の「実用的な品質」を評価します。論文では、主に「安全性（Safety）」と「効率性（Efficiency）」の2つの観点から評価が行われます。

RAGシステムが、ノイズや攻撃、偏見に対してどれだけ安全に振る舞えるかを評価します。評価対象は多岐にわたりますが、論文では以下の6つの観点が重要視されています。

システムが「どれだけ速く、安く動くか」というパフォーマンスとコストを評価します。実運用においては、精度以上に重視されることもあります。

本記事の締めくくりとして、このサーベイ論文が580本以上の関連論文を調査して明らかにした「RAG評価のリアルな実態」について議論します。

LLMの進化に伴い、評価指標は多様化していますが、統計データを見ると「理想と現実のギャップ（不完全性）」が浮き彫りになってきました。

まず、研究者がRAGの「どの部分」を評価しているかの分布を見てみましょう。

評価手法の包括性

• 内部評価（検索・生成）：約90%の論文がカバーしており、技術的な性能向上に関心が集中しています。
• 外部評価（安全性）：一方で、安全性（Safety）に関する評価はわずか9.1%に留まっています。

実運用ではハルシネーションやポイズニング攻撃への対策が急務ですが、研究分野ではまだ「性能（精度）」の追求が優先されており、安全性の評価手法確立は発展途上であることがわかります。

次に、具体的にどのような「評価指標（メトリクス）」が使われているかの頻度です。大きくなっている評価指標ほど、論文で使われている評価指標であることを表しています。

RAG研究における評価指標の頻度統計ワードクラウド

ワードクラウドを見ると、Accuracy, F1-Score, Exact Match, Recall といった「従来の評価指標」が圧倒的に大きく、支配的であることがわかります。
一方で、LLMによる評価の手法は、話題性の割にまだ研究者の間で標準的な地位を確立しきれていません。

その理由は、LLMベース評価が抱える以下の「3つのコスト」にあります。

1. 実装の労力: 評価用プロンプトの設計や調整が難しい。
2. 再現性の低さ: 同じプロンプトでも、モデルのバージョンや温度（Temperature）パラメータで結果が変わってしまう。
3. コスト: 評価するたびにAPI利用料や計算リソースがかかる。

しかし時系列でのトレンドを見ると、課題がありつつもLLMベースの評価手法の採用数は増加しています。

RAGにおけるLLMベースの評価を明示的に言及した論文の数

これは、LLM自体の性能向上に加え、RAGシステムが複雑化し、もはや単純な単語一致（BLEU等）では測れない「高度な推論能力」や「実世界での有用性」を評価する必要に迫られているためです。今後は、LLM評価の「ブラックボックス性」や「不安定さ」を克服するための、より堅牢なフレームワーク（RAGASの進化版など）が登場することが期待されます。

冒頭で述べた「4つの課題」について、本記事での解説を踏まえて改めて整理します。これらは、私たちがこれからRAGを開発・評価する上で向き合うべきテーマです。

1. 評価自体の信頼性（脱ブラックボックス）:
   LLMに評価させる場合、「なぜその点数なのか？」の説明責任や、評価者としてのLLMのバイアスをどう取り除くかが課題となります。
2. コストと効果のバランス:
   すべての指標を測定するのは現実的ではありません。「開発時はRecallとRAGAS」「リリース前は人手評価と安全性チェック」のように、フェーズに応じた評価戦略が必要です。
3. 「思考プロセス」の評価:
   単に回答が合っているかだけでなく、「正しい手順で推論できたか」を評価する指標が必須になります。
4. 多言語対応:
   現在のフレームワークは英語中心です。日本語特有のニュアンスを正しく評価できるデータセットや指標の整備が待たれます。

本記事では、サーベイ論文をベースに、RAG評価の全貌を「内部/外部」「従来/最新」の視点から解説しました。RAGの開発において、「評価」はゴールではなく、改善のための「羅針盤」です。
Recallが高くてもユーザーが満足するとは限りませんし、RAGASのスコアが良くても安全とは限りません。

重要なのは、一つの指標に固執するのではなく、「自分のRAGシステムにとって、今一番守るべき品質は何か？（精度か、速度か、安全性か）」を見極め、適切な指標を組み合わせて継続的にモニタリングすることです。

まだ「完全な評価手法」が存在しないこの過渡期において、本記事が皆さまのRAG開発における羅針盤選びの一助となれば幸いです。

https://arxiv.org