RAGCheckerとは｜RAGを検索と生成に分けて診断するAmazonの評価フレームワーク

RAGChecker（ラグチェッカー）は、RAG（Retrieval-Augmented Generation＝検索拡張生成）システムの品質を、検索（リトリーバル）と生成（ジェネレーション）に分けて数値化する評価フレームワークです。Amazonの研究チームが開発し、論文「RAGChecker: A Fine-grained Framework for Diagnosing Retrieval-Augmented Generation」（arxiv 2408.08067）としてNeurIPS 2024のDataset and Benchmark Trackで発表されました。回答を「クレーム（主張）」単位に分解して事実の含意を照合するため、どの工程が精度を落としているのかを切り分けられるのが最大の特徴です。この記事では定義・論文の位置づけから、RAGASとの違い、評価指標の読み方、pip installからの使い方、導入前に押さえる注意点までを一次情報に沿って解説します。

まとめ

• 正体：Amazon製のRAG評価フレームワーク。論文はarxiv 2408.08067、NeurIPS 2024で採択。OSSとしてGitHub（amazon-science/RAGChecker）で公開。
• 強み：回答をクレーム単位に分解して含意チェックし、検索側と生成側の指標を分離。人間の評価との相関が従来指標より高いと報告されている。
• 指標：全体（precision／recall／f1）、検索（claim_recall／context_precision）、生成（faithfulness／hallucination など）の3層で構成。
• 使い方：pip install ragchecker（PyPI最新0.1.9・Python 3.9以上）とJSON形式の評価データを用意し、CLIまたはPython APIで実行。extractorとcheckerにLLMを指定する。
• 注意：クレーム抽出・照合でLLMを多数回呼ぶため課金と時間がかかる。標準は英語（spaCy en_core_web_sm）前提で、日本語評価は結果の妥当性を自分で検証する必要がある。

RAGCheckerの定義・開発元・論文

RAGは「Retrieval-Augmented Generation」の略で、外部の文書を検索して取り込み、その内容を根拠にLLMが回答を生成する仕組みです。RAGは検索器（Retriever）と生成器（Generator）が組み合わさった複合システムのため、回答が誤ったときに「検索が悪いのか」「生成が悪いのか」を切り分けにくいという評価上の難しさがあります。RAGCheckerはこの切り分けを目的に、Amazonが設計しました。

論文はarxivに2024年8月15日投稿（識別子 2408.08067）され、NeurIPS 2024のDataset and Benchmark Trackで採択されています。論文では8種類のRAGシステムをRAGCheckerで評価し、指標が人間の判断とどれだけ相関するか（メタ評価）を検証しています。ベンチマークとコードはオープンソースで、実装はrefchecker（同じくAmazon製の事実性チェックライブラリ）を土台にしています。

従来のRAG評価（RAGASなど）との違い

RAG評価で広く使われるRAGASは、回答全体を一つのまとまりとして扱い、忠実性や関連性をスコア化します。手軽な一方で、回答が長文になるほど「一部だけ誤っている」状態を平均に埋もれさせやすいという弱点があります。

RAGCheckerはここを、回答と正解をクレーム（1つの主張＝最小の事実単位）に分解し、各クレームが検索文脈や正解に含意されるかを一件ずつ照合する方式で解きます。これにより「回答の中のどの主張が、根拠のない幻覚なのか」「検索できていた文脈を生成側が使えていないのか」といった粒度で原因を特定できます。RAGCheckerとRAGASは排他ではなく、まず全体傾向をRAGASで掴み、原因の切り分けが要る局面でRAGCheckerを使う、という併用も現実的です。ハルシネーション検出に特化した評価データセットを併用したい場合はRAGTruth（RAGの幻覚を検出するACL 2024評価データセット）も選択肢になります。

RAGCheckerの評価指標一覧と読み方

指標は「全体（Overall）」「検索（Retriever）」「生成（Generator）」の3グループに整理されています。どの指標が低いかで、手を入れるべき工程がそのまま分かる設計です。

検索（Retriever）指標

claim_recallは、正解に含まれる主張のうち検索文脈がカバーできた割合で、これが低ければ検索の網羅性（取りこぼし）が問題です。context_precisionは取得した文脈のうち実際に有用だった割合で、低ければノイズ文書を拾いすぎています。前者はチャンク分割や検索件数、後者はリランクやフィルタで改善を狙う、と読み替えられます。

生成（Generator）指標

faithfulnessは回答が検索文脈に忠実か、hallucinationは文脈にも正解にも無い主張（幻覚）の割合です。context_utilizationは検索できていた正解情報を生成側が実際に使えた割合、self_knowledgeは文脈を使わずモデルの内部知識だけで答えた割合を示します。noise_sensitivity_in_relevant／noise_sensitivity_in_irrelevantは、それぞれ関連文書内・無関係文書内のノイズにどれだけ引きずられて誤ったかを表します。

指標からの改善方針の読み取り

切り分けの型は単純です。claim_recallが低ければ検索の見直し、検索は足りているのにhallucinationやnoise_sensitivityが高ければプロンプトや生成モデルの見直し、self_knowledgeが高ければ「検索結果を無視して勝手に答えている」状態なので根拠提示の指示を強める、という具合に指標が次の一手を指し示します。検索そのものの手法を改善したい場合は、RRF（Reciprocal Rank Fusion）によるRAG-Fusionやベクトル不要の推論型RAG（PageIndex）のような検索設計の見直しが打ち手になります。

RAGCheckerの導入と使い方

ragcheckerのインストール手順

PyPIで公開されており、Python 3.9以上で動きます（最新は0.1.9・2024年9月25日リリース）。クレーム抽出に使うため、spaCyの英語モデルも合わせて導入します。

pip install ragchecker
python -m spacy download en_core_web_sm

評価データの準備

評価対象のRAG出力を、次のJSON形式で用意します。各レコードは質問（query）・正解（gt_answer）・RAGの回答（response）・検索で取得した文脈（retrieved_context）を持ちます。

{
  "results": [
    {
      "query_id": "q1",
      "query": "RAGとは何の略か",
      "gt_answer": "Retrieval-Augmented Generation",
      "response": "検索拡張生成のことです",
      "retrieved_context": [
        {"doc_id": "d1", "text": "RAG = Retrieval-Augmented Generation"}
      ]
    }
  ]
}

評価の実行

クレームの抽出（extractor）と含意チェック（checker）にLLMを指定します。Amazon Bedrockのほか、OpenAIなどLiteLLM経由のモデルを指定できます。CLIとPython APIのどちらでも実行でき、既存RAGとの接続を楽にするLlamaIndex連携も用意されています。

from ragchecker import RAGResults, RAGChecker
from ragchecker.metrics import all_metrics

with open("checking_inputs.json") as fp:
    rag_results = RAGResults.from_json(fp.read())

evaluator = RAGChecker(
    extractor_name="bedrock/meta.llama3-1-70b-instruct-v1:0",
    checker_name="bedrock/meta.llama3-1-70b-instruct-v1:0",
    batch_size_extractor=64,
    batch_size_checker=64,
)
evaluator.evaluate(rag_results, all_metrics)
print(rag_results)

抽出と照合を担うLLMの質が評価そのものの質を左右するため、extractor／checkerには十分に賢いモデルを使うのが前提です。RAGCheckerが内部で使う「LLMを評価者に据える」考え方は、LLM-as-a-Judge（大規模言語モデルを評価者として用いる手法）と同じ系譜にあります。

導入前に押さえる注意点と向かない場面

RAGCheckerはRAGの誤りをクレーム単位で切り分けられますが、無条件に勧められる道具ではありません。導入前に、コスト・日本語適合・プロジェクト規模の3点を判断材料にしてください。

LLMコストと時間：回答をクレームに分解し一件ずつ照合するため、1問あたりのLLM呼び出しが多くなります。数百〜数千件を回すとAPI課金と実行時間が無視できません。CI（継続的統合）に毎回組み込むより、リリース前や改修の前後で回す使い方が現実的です。

日本語での妥当性：標準構成はspaCyの英語モデル（en_core_web_sm）を前提にしており、クレーム分解の粒度は英語で最適化されています。日本語RAGにそのまま適用すると分解が不自然になり得るため、少数サンプルで人手評価と突き合わせ、スコアが信頼できるかを必ず確認してから本採用してください。

規模とフェーズ：バージョンは0.1系で、APIやモデル指定は今後変わる可能性があります。試作段階の単発検証や、そもそも検索器・生成器を分離して直す体制が無い小規模プロジェクトでは、詳細指標を出しても打ち手に結びつかず過剰投資になりがちです。まずRAGAS等で全体を掴み、原因の切り分けが必要になった段階でRAGCheckerに進むのが手堅い順序です。評価対象のRAG設計自体を見直す場合は、意図に応じて検索手段を使い分けるOmniRAGの設計パターンも参考になります。

よくある質問

RAGASとRAGChecker、どちらを使うべきですか？

目的が違います。全体傾向を手軽に測るならRAGAS、検索と生成のどちらが原因かを切り分けたいならRAGCheckerです。両方を併用し、RAGASで異常を検知してRAGCheckerで原因を掘る流れが実務では扱いやすいです。

日本語のRAGでも使えますか？

動作はしますが、標準は英語モデル前提です。日本語では少数サンプルで人手評価と照合し、スコアの妥当性を確認したうえで使ってください。

RAGChecker自体は無料ですか？

RAGChecker本体はオープンソースで無料です。ただしextractor／checkerに使うLLM（Bedrock・OpenAIなど）の利用料は別途かかります。

オフライン（ローカルLLM）で動かせますか？

LiteLLM経由でモデルを指定する仕組みのため、ローカルLLMを立てて指定すればAPI課金なしで動かせます。ただし評価精度は指定モデルの賢さに依存します。

最新バージョンはどれですか？

執筆時点のPyPI最新は0.1.9（2024年9月25日公開）です。0.1系のため、正確な仕様は公式リポジトリで最新を確認してください。

関連記事

• RAGTruthとは｜RAGのハルシネーションを検出するACL 2024評価データセットを解説
• LLM-as-a-Judgeとは何か？大規模言語モデルを評価者として用いる新手法の概要
• RRF（Reciprocal Rank Fusion）とは？RAG-Fusionでの仕組み・スコア計算・実装を解説
• PageIndexとは？ベクトル不要の推論型RAGの仕組み・使い方・従来RAGとの違い
• OmniRAGとは？意図に応じてDB・ベクトル検索・ナレッジグラフを使い分けるRAG設計パターン