この記事はNTTドコモソリューションズ Advent Calendar 2025 22日目の記事です。
NTTドコモソリューションズの青木と申します！
普段は社内におけるGitHub Copilotの普及・利用促進に向けた活動を主にしています。
プライベートだとカービィのエアライダーにハマっています。バトチャリで蹂躙したい！
今回は、以前携わっていた業務で行ったRAGの精度検証について、
- RAGCheckerを用いた自動評価
- 人間が目視で採点する手動評価
をそれぞれ行ったため、どのように行ったかや使い分けについて紹介します。
はじめに
そもそもRAGって何？
ChatGPTのような世間一般に公開されている大規模言語モデル（Large Language Model/LLM）のサービスに、例えば皆さんの会社の社内規則について聞いたら答えてくれるでしょうか？きっと正しい回答は返せないでしょう。これは、社内規則が基本公開されていないため、LLMの学習データの中に社内規則が含まれず、LLMが学習していないからです。LLMは何でもは知りません。知っていることの延長線上の内容でしか回答することができません。
ところが、LLMのユースケースとして社内規則の問い合わせBotなど、本来LLMが知らない、学習していない情報に対応した事例が多く存在します。なぜ回答できるのでしょうか？
この疑問に対する回答の1つがRAGです。
RAGの流れを簡単に説明すると、⓪事前に社内ドキュメントなどの外部情報をDBに保存 ⇒ ①ユーザーが質問を送ると、質問に関連する情報をDBから検索/取得 ⇒ ②ユーザーの質問と検索結果をLLMに提供して回答生成/出力 となっています。
ポイントとして、LLM自体は社内規則などの追加情報を学習していない状態であることは変わっていません。ユーザーが質問をすることで、参考情報としてDBに格納されている質問の中から関連する情報をLLMに渡して、その後、LLMが受け取った情報を元に適切な回答を作成して出力しています。
DBについては、現状ドキュメントを分割してEmbeddingと呼ばれるベクトルに変換する処理を行い、チャンクと呼ばれる単位でベクトルDBの形式で保存する手法が主流です。
RAGにおける回答精度向上の着眼点としては、DBの検索精度、検索結果を適切に用いたLLMの回答精度、この2箇所が挙げられます。特にDBの検索精度については、私たちに限らず多くの開発者が苦労している部分だと思います。
- DBの検索精度
- ユーザーの質問文を元に、ベクトルDBの検索結果として適切な情報を取得できているか？
- そもそも質問に関連する情報を取得できなければ、LLMは知らない状態から変わらないため回答できません
- 【改善方法の一例】
- チャンクの長さや区切り文字、オーバーラップなどのチャンク戦略の変更
- DB検索に用いる検索ワードの見直し、質問文の整形など
- （図表が含まれる場合）マークダウンやPlantUMLなどのAIが理解しやすい形式に変換
- 検索結果を適切に用いたLLMの回答精度
- 検索結果を用いてLLMが適切な回答を生成できるか？
- 検索結果が正しくても、取得したチャンクをLLMが理解できない、適切に利用できない、そもそも参照しないケースも存在します
- 【改善方法の一例】
- 回答生成するLLMのプロンプト改善
- 取得したチャンクの優先度を再度並び替えるreRanking機能の導入
- 検索結果を用いてLLMが適切な回答を生成できるか？
自動評価
自動評価とは？
LLMが出力した回答内容をLLMなどのAIが評価する方法を指します。LLMに回答内容と評価軸をプロンプトとして渡して評価させる方法も存在しますが、RAGASやRAGCheckerなどのLLMを活用した定量評価ツールが知られています。
私が従事していた案件にて精度評価を行うために定量評価ツールを選定した際は、RAGASとも悩みましたが、RAGCheckerの方が出力された文章をクレームという細かい単位に分けてチェックできることから、RAGCheckerを採用しました。
クレームとは、文章の内容を主張や情報の最小単位に区切ったものです。
例えば、
カエルは、子どもの頃は水中で暮らすオタマジャクシから、成長すると陸上で生活する姿へと大きく変わる「変態」をする両生類です。発達した後ろ足で高くジャンプし、粘り気のある長い舌を素早く伸ばして昆虫などを捕らえます。日本では鳴き声が季節の風物詩として親しまれています。
というカエルの説明文があったとします。この文章をクレーム単位に分割した場合、以下のようになります。
・カエルは両生類である。
・子どものオタマジャクシから成体へと姿を変える「変態」を行う。
・発達した後ろ足で高くジャンプする。
・粘り気のある長い舌で昆虫などを捕らえる。
・鳴き声は季節の風物詩として親しまれている。
※必ずしもLLMが一言一句同じように分割するとは限りません。あくまで一例です
このように、LLMが生成した回答や取得したチャンクをクレーム単位という細かい単位に分けてから分析するため、より精度の高い評価をしてくれるのではないかと期待しました。
自動評価に必要なもの
自動評価に必要なものは以下の通りです。動かし方については、今回は省略します。
- RAGCheckerを動かせるPython実行環境
- LLM（私たちはAzure OpenAI提供のLLMを使用）
- RAGChecker実行時に投入するjsonファイル 以下jsonファイルの内容
- 質問
- 模範解答
- 評価対象のRAGアプリケーションが出力した回答
- ナレッジベース検索で取得したチャンク → 取得したチャンクを何かしらで保存する必要あり
問題・模範解答は、ベクトルDB化したドキュメントを元にLLMが作成したQAセットの内容を人間が目視で確認・修正して作成しました。
自動評価の見方
本ページでは、出力されるメトリクスの指標の大まかな見方について説明します。厳密さに欠けてしまうところもあるかと思いますが、おおよその理解に役立てれば幸いです。
各指標の厳密な定義は、RAGCheckerのGitHubページに公開されている下記の図やRAGCheckerの開発チームが公開した論文 RAGChecker: A Fine-grained Framework for Diagnosing Retrieval-Augmented Generation をご確認ください。
RAGChecker: A Fine-grained Framework For Diagnosing RAG
https://github.com/amazon-science/RAGChecker
（参照日：2025/12/16）
- precision,recall,f1
適切な回答内容を含んでいる割合であり、基本的にはこれら3項目が回答精度といっても差し支えないです。改善策の実装前後におけるこれら3項目の値を見て、値が増加していれば改善傾向、減少したら悪化してそうだな～と判断していました。
3項目についてもう少し詳細に説明すると以下のようになります。- precision：LLMが出力した回答の全クレームのうち、正しかった（模範解答にも含まれていた）クレームの割合
- recall：模範解答の全クレームのうち、LLMが出力した回答にどれだけ含まれていたかの割合
- f1：precision、recallの値を基に計算される値
- claim_recall
模範解答に対して適切なチャンクを取得できている割合。適切な回答を得るために必要なチャンクを取得できているか？というベクトルDBの検索精度を指しています。この値が低いとLLMの回答精度以前に、そもそも適切なナレッジを取得できていないのでは？ナレッジ検索の精度が悪いのでは？と考えていました。 - context_precision
取得したチャンク全体に対する質問に関連する適切なチャンク数の割合です。私たちが精度検証をしていたアプリケーションは、取得するチャンクが多いため、この指標は低い傾向が見られましたが、回答精度は良かったことからあまり重要視はしなかったです。余計なチャンクに引っ張られることによる誤った回答が目立つ場合は、ナレッジベースのチャンク戦略を変えたり、ドキュメントの形式を変えるべきだと思います。 - context_utilization
取得した適切なチャンクのうち、回答生成時に用いられた適切なチャンク数の割合。この割合が低い場合は、回答生成を行うLLMがチャンクを適切に理解できていない、LLMのプロンプトが不適切であると考えていました。 - noise_sensitivity
LLMの回答に含まれる模範解答の内容に含まれないクレームの割合。低い方が好ましいが、precision,recall,f1ほど注視はしませんでした。 - hallucination
LLMの回答の内、取得したチャンクに基づかないLLMが勝手に付け加えた誤ったクレームの割合。おそらく多くの開発者が注視している要素のため、低くしたい要素である。
余談ですが、LLMが学習する際に、回答内容に対して正解・不正解のみを与えるような報酬設計が原因でハルシネーションを起こすのではないか？というテーマの論文Why Language Models Hallucinate が、OpenAIより2025年9月に発表されました回答に対して正誤でしか判定されないのであれば、分からないと回答するより推測してでも何かしら回答を出力して正答率を上げたほうが高評価になりやすいことをLLMが学ぶようです。人間が試験でワンチャンを狙ってテキトーに回答するのと同じですね。紹介した論文では改善案として、虚偽の回答をした場合に分からないと回答したよりも評価にペナルティ（減点）を与えることが挙げられていました。今後LLMを提供する企業に期待ですね～ - self_knowledge
LLMの回答の内、取得したチャンクに基づかないLLMが勝手に付け加えた内容だが、回答として適切だったクレームの割合（=LLM由来の知識での回答）。該当するケースが少なかったため特に注視はしませんでした。 - faithfulness
LLMが適切なチャンクかどうかを問わず、取得したチャンクに基づいて回答した割合。この値が低いと取得したチャンクを用いずに好き勝手回答していることになるため、回答生成を行うプロンプトを修正する必要があると考えられます。
自動評価の長所/短所
自動評価 長所
- 一度実行環境さえ準備できれば、Pythonコードを実行するだけで評価結果を得られる
- 問題数が増えてもPythonスクリプトを実行するだけのため、実行の手間が変わらない
自動評価 短所
- AIによる採点結果のため、どうしてもブラックボックスであり、手動評価と比較すると信頼性に劣る
- 各指標の値がどの程度だと優れているのか、明確な基準が（おそらく）存在しないため、評価結果を見ても分かりにくい
- 外部に見せる成果としては、値の良い悪いが判断しづらいため、採用しにくい
例えば、唐突に弊社のRAGアプリケーションの精度はこちら！と見せられたとしてみなさんはどう思うでしょうか？
| precision | recall | f1 | claim_recall | context_precision | context_utilization | noise_sensitivity | hallucination | faithfulness |
|---|---|---|---|---|---|---|---|---|
| 67.7 | 85.5 | 73.5 | 96.7 | 33.5 | 85.5 | 10.7 | 4.3 | 0.8 |
※ 数値はサンプルです
(੭ᐕ))？？？？？？？？？？？？？？？？？？？？？
おそらく、多くの人が既存のRAGアプリケーションより凄いのかどうかがワカラナイ状態になっていたのではないでしょうか？
実際、各指標がこのレベルだと好ましいという目安を私も聞いたことがない状態です。
仮にどんなに良い成果だったとしても伝わらなければ意味がないので、外向けの資料（特にLLMに明るくない人向け）として採用するには厳しいと思います。そのため、開発チーム内で改善傾向を確認するために用いるぐらいの運用が好ましいと個人的には考えています。
当時行っていた自動評価方法
- 評価方法
LLMの特性上、上振れ下振れがあることから、RAGアプリケーションでの回答生成⇒RAGCheckerでメトリクス出力を5セット分行い、最終的な指標として平均値を採用しました - 利用用途
- 開発チーム内での実装前後における大体の改善傾向を掴む目的での使用
- ナレッジの検索精度など外部に紹介しない開発者のみが確認できれば良い指標を把握する用途として使用
手動評価
手動評価とは？
LLMが出力した回答と模範解答を照らし合わせて、人間が評価する手法です。手動評価の定石は特に定まっていませんが、
- 問題の採点基準を事前に定める
- 採点者によるバイアスを減らすために、複数人での採点結果の平均値を用いる
辺りは一般的に言われる話だと思います。2024年の記事ですが、ELYZA-japanese-Llama-2-70bのリリース記事では、3人の採点者の平均値を採用していて、問題ごとに採点基準を設けていました。
手動評価に必要なもの
手動評価に必要なものは以下の通りです。
- 質問
- 模範解答
- 採点基準
- 評価対象のRAGアプリケーションが出力した回答
- 複数の採点者、採点に時間をかけられる環境
採点基準の作り方
私たちが精度検証を行っていた時は、問題ごとではなく全問題共通の採点基準を事前に作成しました。全問題共通の採点基準を作成した意図としては、問題ごとに採点基準を作成した場合、各問題の採点基準を外向けの説明時に説明しないといけないのでは？と開発チーム内で懸念されたためです。
実際にRAGの精度検証を行った際は、以下のような全問題共通の〇△×の三段階の評価基準を事前に作成してから評価を行いました。
【RAG精度検証時の採点基準】
| 評価基準説明用の例題 | 〇（1点） | △（0.5点） | ×（0点） |
|---|---|---|---|
| 【質問】 光合成とは何か、簡潔に説明してください。 【模範解答】 植物が光のエネルギーを利用して、水と二酸化炭素からデンプンや酸素を作り出すこと。 |
【定義】 模範解答の要素がすべて含まれている かつ 虚偽の内容が含まれない場合 【回答例】 植物が、光のエネルギーを利用して、水と二酸化炭素から、自身の栄養となるデンプンなどの有機物と、呼吸に必要な酸素を作り出す働きのことです。 |
【定義】 模範解答の要素が一部含まれている かつ 虚偽の内容が含まれない場合 【回答例】 植物が太陽の光を浴びて、二酸化炭素を酸素に変えることです。 ※デンプンなど栄養分を作成すること、水を原料にする要素が抜けている。 |
【定義】 質問に関係ない回答がされている または 回答に虚偽の内容が含まれる場合 【回答例】 ①植物が、昼と夜の長さの違いを感じ取って季節を判断し、花を咲かせるタイミングを決める働きのこと ②植物が酸素を吸って二酸化炭素を出すことです。その際にデンプンなどの栄養も作られます。 ※①光合成と関係ない異なる内容の説明をしているため。 ※②光合成では酸素を吸って二酸化炭素を出さないため、誤った内容を説明している。 |
とはいえ、問題ごとに採点基準が明確化されていた方が採点しやすかったとは思うため、全問題共通の採点基準を上のように作成しつつ、共通の採点基準を問題ごとに落とし込んだ採点基準を別途LLMで作成した方が採点しやすかったな～と考えています。採点基準は3段階にしていましたが、もっと細かくするなどの改善の余地もありそうですね。
手動評価の長所/短所
手動評価 長所
- 採点のフローが透明化されているため、採点の精度や信頼性が自動評価よりも高い
- 外部に紹介する指標としても共感を得やすい
手動評価 短所
- 採点基準を事前に作成する必要がある
- とにかく人手と時間がかかる
目安ですが、30問採点をするのに一人当たり大体30分かかりました。
RAG精度検証時の手動評価方法
-
利用用途
POへの共有時に、RAGアプリケーションの回答精度の評価指標として使用 -
評価方法
LLMの特性上、上振れ下振れがあることから、RAGアプリケーションでの回答生成⇒手動評価を5セット分行い、毎回2人で採点して、最終的な指標として2人の採点結果の平均値を用いた。可能ならば3人は欲しかった記憶。
まとめ 自動評価と手動評価の使い分け
自動評価を使用したい箇所
- 開発者の中でおおよその改善傾向を把握したい場合
- ナレッジ検索精度のために取得したチャンクを1つ1つ確認など、人手の評価では時間がかかる項目の分析を行いたい場合
手動評価を使用したい箇所
- 回答精度などの検証結果を外部に紹介する場合
- 評価結果に対して信頼できる結果が欲しい場合
本記事ではRAGの自動評価、手動評価をどのように行ったかを説明しました。RAGの精度検証を進めるうえで一助になれば幸いですm(__)m
記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。