AI eval ツール Ragas: RAG 評価に特化した OSS フレームワーク

RAG (Retrieval-Augmented Generation、検索拡張生成) を本番に出すと、独特の失敗モードに必ずぶつかります。「取ってきた文書は合っているのに回答が外す」「それっぽい回答だが根拠がない」といった類です。Ragas は、こうした RAG 特有の失敗を数値で捉えるための OSS 評価フレームワークです。

本稿では、Ragas が何をする道具なのか、なぜ RAG の評価は難しいのか、代表的な metric、最小動作例、合成データ生成、向くケース・向かないケース、連携、ハマりどころを順に整理します。

Ragas とは

Ragas (RAG Assessment) は、RAG パイプラインを定量的に評価するための Python ライブラリです。LLM-as-a-judge を使って、取得した文脈 (context)、生成された回答 (response)、質問 (query)、正解 (reference) の関係を 0〜1 のスコアで表します。

一言でいえば、「人間が目視で RAG を点検していた作業」を自動化するためのツールキットです。

なぜ RAG の評価は難しいか

RAG は少なくとも 2 つのコンポーネントの合成です。

1. Retriever: 質問に関連する文書を取ってくる
2. Generator: 取ってきた文書から回答を作る

従来の「回答の正誤」だけ測ると、どちらが悪いか切り分けられません。たとえば回答が間違っているとき、

• Retriever が間違った文書を取ってきたのか
• Retriever は正しかったが Generator が hallucination を起こしたのか
• 正しい文書は取れたが足りなかったのか

で、打つべき対策はまったく違います。Ragas が複数の metric を揃えているのは、この切り分けを可能にするためです。

評価設計には 5 つの要素があります。Interaction mode / Data / Metrics / Tooling / Context の 5 つです。Ragas はこのうち Metrics と Tooling を強くカバーする道具だと位置づけると、立ち位置がわかりやすくなります。

誰が作ったか・ライセンス

Ragas は Exploding Gradients (Vibrant Labs) が中心となって開発している OSS です。GitHub リポジトリは explodinggradients/ragas、ライセンスは Apache-2.0 で、商用利用も問題ありません。GitHub スター数は 1 万 5 千を超え、Discord コミュニティも活発です。

主な metrics

Ragas の RAG 向け metric は、どのコンポーネントを測るかで整理できます。

Faithfulness (忠実度)

生成された回答が、取得した文脈に裏付けられているかを測ります。回答を主張 (claim) 単位に分解し、各主張が文脈から導けるかを LLM に判定させます。hallucination 検出の基本 metric です。

• 入力: response、retrieved_contexts
• スコア: 文脈に裏付けのある主張の割合

Answer Relevancy (回答関連性)

回答が質問にどれだけ答えているかを測ります。回答から逆に質問を生成し、元の質問とのコサイン類似度を取る、という発想です。「文脈には忠実だが質問に答えていない」ケースを拾います。

• 入力: user_input、response
• スコア: 生成質問と元質問の類似度平均

Context Precision (文脈精度)

取ってきた文脈のうち、本当に回答に必要なものがどれだけ上位にランクされているかを測ります。Retriever のランキング品質を評価する metric です。

• 入力: user_input、retrieved_contexts、reference
• スコア: 関連文書の順位を加味した精度

Context Recall (文脈再現率)

正解を導くのに必要な情報が、取ってきた文脈にどれだけ含まれているかを測ります。「取り漏らし」を検出します。

• 入力: user_input、retrieved_contexts、reference
• スコア: 正解の各ステートメントが文脈にある割合

Context Entity Recall (文脈エンティティ再現率)

正解に出てくる固有表現 (人名、組織、場所、製品名など) が、文脈にどれだけ含まれているかを測ります。固有名詞中心の QA (企業 FAQ、商品検索) で特に効きます。

• 入力: retrieved_contexts、reference
• スコア: 文脈に出現する固有表現の割合

この 5 つを並べて見ると、「Retriever 側」「Generator 側」「両者の噛み合わせ」をそれぞれ別の数字で捉えられる構造になっています。

最小動作例

実際にメトリクスを計算する最小コードは次のとおりです。

from ragas import evaluate, EvaluationDataset
from ragas.dataset_schema import SingleTurnSample
from ragas.metrics import (
    Faithfulness,
    ResponseRelevancy,
    LLMContextPrecisionWithReference,
    LLMContextRecall,
)
from ragas.llms import LangchainLLMWrapper
from langchain_openai import ChatOpenAI, OpenAIEmbeddings

llm = LangchainLLMWrapper(ChatOpenAI(model="gpt-4o-mini"))
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")

samples = [
    SingleTurnSample(
        user_input="Ragas のライセンスは？",
        retrieved_contexts=[
            "Ragas は Apache-2.0 ライセンスで公開されている OSS です。",
            "GitHub スター数は 1 万 5 千を超えています。",
        ],
        response="Ragas は Apache-2.0 ライセンスの OSS です。",
        reference="Apache-2.0",
    ),
]

dataset = EvaluationDataset(samples=samples)

result = evaluate(
    dataset=dataset,
    metrics=[
        Faithfulness(llm=llm),
        ResponseRelevancy(llm=llm, embeddings=embeddings),
        LLMContextPrecisionWithReference(llm=llm),
        LLMContextRecall(llm=llm),
    ],
)

print(result)
# {'faithfulness': 1.0, 'answer_relevancy': 0.94, ...}

SingleTurnSample に 1 件の入力 (質問、取得文脈、回答、正解) を詰め、EvaluationDataset でまとめ、evaluate() に metric のリストを渡すだけです。本番環境では、オフラインで集めた QA ログをこの形に整形して流し込みます。

合成データ生成: TestsetGenerator

RAG の評価で一番つらいのは、評価用の質問・正解ペアを集めること自体です。Ragas の TestsetGenerator は、与えた文書群から合成テストセットを自動生成します。

from ragas.testset import TestsetGenerator
from ragas.llms import LangchainLLMWrapper
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_community.document_loaders import DirectoryLoader

docs = DirectoryLoader("./knowledge_base", glob="*.md").load()

generator = TestsetGenerator(
    llm=LangchainLLMWrapper(ChatOpenAI(model="gpt-4o")),
    embedding_model=OpenAIEmbeddings(),
)

testset = generator.generate_with_langchain_docs(docs, testset_size=20)
testset.to_pandas().to_csv("testset.csv", index=False)

内部では、文書群を Knowledge Graph に変換し、ノード間の関係から多段推論型の質問や比較質問などを混ぜて生成します。質問タイプの分布もカスタマイズできるため、「単純 lookup だけでなくマルチホップも試したい」といった要件に応えやすい設計です。

ただし、生成された質問・正解はそのまま使うのではなく、必ず人手でサンプリング確認するのが前提です。合成データは LLM の癖を反映するので、丸ごと信じると評価が LLM の自画像になりがちです。

向くケース・向かないケース

向くケース

• RAG パイプライン (社内 FAQ bot、ドキュメント検索、サポート自動応答など) のオフライン評価
• Retriever と Generator を切り分けて改善したいとき
• プロンプトやチャンク戦略を変えた AB 比較
• Knowledge base の網羅性チェック (context recall が低い領域を可視化)

向かないケース

• マルチステップのツール呼び出しを伴う AI エージェント の挙動評価
• 対話全体の一貫性やタスク達成度の評価
• UI 操作や外部副作用を含むタスクの end-to-end 評価

エージェント寄りの評価には、別記事で扱う DeepEval や、エージェント専用のベンチマーク (τ-bench、SWE-bench 等) のほうが素直です。Ragas は「検索して答える」部分の計測屋だと割り切ると、位置づけがぶれません。

LangChain / LlamaIndex との統合

Ragas は代表的な RAG フレームワークとの連携を公式サポートしています。

• LangChain: LangchainLLMWrapper で任意の LangChain LLM をラップし、TestsetGenerator.generate_with_langchain_docs で LangChain Document を直接食わせられます。
• LlamaIndex: generate_with_llamaindex_docs が用意されており、LlamaIndex の Node から合成データを生成できます。評価側も evaluate にそのまま渡せます。
• LangSmith / Arize Phoenix: トレースと連携して、本番ログに Ragas の metric を後乗せ計算する運用が可能です。

その他に Haystack、Amazon Bedrock、R2R など、主要スタックは一通り押さえています。

ハマりポイント

実運用で引っかかりやすい点を挙げておきます。

• LLM コスト: metric はほぼ全て LLM 呼び出しを伴います。100 サンプル × 5 metric で数百回の API 呼び出しになるため、サンプリング設計 (N の決め方) を最初に握ることが大切です。
• 埋め込みモデル依存: Answer Relevancy はコサイン類似度を使うため、埋め込みモデルを変えるとスコアが動きます。モデルを変えたときは「スコアの絶対値」ではなく「変更前後の相対差」を見るのが安全です。
• Judge のバイアス: LLM-as-a-judge なので、judge 側のモデルや温度でスコアが変動します。judge は固定し、seed を指定し、ソース側の変更だけが差分として現れる状態を作ってください。
• 非同期とレート制限: evaluate() は内部で並列呼び出しを行います。OpenAI などのレート制限に当たりやすいので、run_config で並列数とリトライを調整しましょう。
• 合成データの質: TestsetGenerator の出力は、元の文書に本当にその情報があるかを LLM に任せています。文書の網羅性が低いドメインでは、「文書に書いていないことを問う質問」が混じります。必ず目視点検を挟んでください。
• バージョン追従: Ragas は現在も活発に API が変わります。Faithfulness(llm=...) の呼び出し方や metric 名はマイナーアップデートで変わることがあり、ドキュメントのバージョンと pip のバージョンを揃えて参照する運用がおすすめです。

まとめ

Ragas は、RAG を本番運用するチームにとって最もコスパのよい metric 層です。faithfulness と context recall を主軸に、answer relevancy と context precision を補助として置きます。合成データで一次評価、人手で二次確認、という流れに乗せると、改善サイクルが数値で回り始めます。

一方で、Ragas だけでは RAG のすべてを測れません。エージェントとしての判断や副作用、対話文脈の扱いには別の道具が要ります。評価の 5 要素のうち、Ragas は「Metrics × Tooling」をコスト低く埋める部品だと捉えます。Data (テストセット設計) と Context (業務要件とのすり合わせ) は自前で設計する、というバランスが実務上は現実的です。

chaff grade との連携 — 決定論的採点を混ぜる

Ragas の Faithfulness は RAG 回答が検索された文脈と矛盾しないかを LLM で判定します。これに決定論的な採点を足すと、「引用が原文に本当に存在するか」「数値の整合」が機械で確定できます。

chaffjs の grade を Ragas の Faithfulness と並べて走らせる例: isamu/lab: examples/evals/ragas（chaff_with_faithfulness.py 参照）

LLM-judge の「意見」と chaff の「事実」を分離して記録することで、どちらが落ちているかを切り分けやすくなります。

関連記事

• AI エージェント評価サーベイ論文を読み解く
• AI の評価って何？なぜ難しい？
• AI エージェントの evaluation (evals) 入門
• AI eval ツール: DeepEval
• AI eval ツール: Weave

Singularity Society はテクノロジー集団として MulmoClaude / MulmoTerminal / MulmoCast を開発しています。エンジニア・起業家向けの実践プログラム BootCamp も運営しています。