RagasでRAGを評価する｜指標の意味とPythonコード

Ragas（ラガス）は、RAG の「検索」と「回答」を別々に点数化する Python のライブラリです。 判定役の LLM に「回答の文は資料に書いてあるか」「この資料は答えに役立ったか」を1つずつ判定させ、その割合を 0〜1 の点数にします。0.4.3 では、指標は ragas.metrics.collections から読み込み、await metric.ascore(...) で1件ずつ採点します。

import asyncio
from openai import AsyncOpenAI
from ragas.llms import llm_factory
from ragas.metrics.collections import Faithfulness

llm = llm_factory("gpt-4o-mini", client=AsyncOpenAI())   # 判定役の LLM
metric = Faithfulness(llm=llm)

result = asyncio.run(metric.ascore(
    user_input="有給休暇はいつまでに申請しますか",
    response="有給休暇は取得日の3営業日前までに申請します。勤怠システムから申請します。",
    retrieved_contexts=["有給休暇は取得日の3営業日前までに勤怠システムで申請します。"],
))
print(result.value)   # 回答の2文がどちらも資料から言えれば 1.0

確認環境：ragas 0.4.3（pip の最新版）・langchain-community 0.4.1・openai 1.109.1・instructor 1.3.2・Python 3.11.15（Linux）。指標の計算式とプロンプトは、インストールした ragas のソース（ragas/metrics/collections/）で確かめました。判定役に送られるリクエストは、base_url を手元の擬似エンドポイント（OpenAI 互換の chat・embeddings の形を返す小さな HTTP サーバー）に向けて記録しました。擬似エンドポイントは「文字の重なりで判定する」簡単な規則で答えを返しているので、この記事の点数は Ragas の計算の流れを確かめるための値です（本物の LLM なら判定の中身は変わります）。指標の定義は docs.ragas.io で確かめました（確認日 2026年10月13日）。

インストールと 0.4 での書き方の変化

pip install ragas
export RAGAS_DO_NOT_TRACK=true     # 使用状況の送信を止める（後述）
export OPENAI_API_KEY="sk-..."

2026年10月13日時点の import エラー

pip install ragas で入った組み合わせ（ragas 0.4.3・langchain-community 0.4.2）では、import ragas が次のエラーで止まりました。

ModuleNotFoundError: No module named 'langchain_community.chat_models.vertexai'

langchain-community を 0.4.1 にすると import できました。

pip install ragas "langchain-community<0.4.2"

以前の書き方から 0.4.3 の書き方へ

ネットの記事の多くは 0.1〜0.2 の書き方です。0.4.3 で動かした結果を並べます。

ragas.metrics から読み込んだときの警告です。

DeprecationWarning: Importing faithfulness from 'ragas.metrics' is deprecated and will be removed in v1.0. Please use 'ragas.metrics.collections' instead.
DeprecationWarning: evaluate() is deprecated and will be removed in a future version. Use the @experiment decorator instead.

collections の指標に、以前の LangChain のラッパーを渡すと Collections metrics only support modern InstructorLLM. Found: ... Use: llm_factory('gpt-4o-mini', client=openai_client) というエラーになる作りです（ragas/metrics/collections/base.py の検証処理）。

使用状況の送信

ragas の _analytics.py には、使用状況を https://t.explodinggradients.com に送る処理があります。環境変数 RAGAS_DO_NOT_TRACK=true で止まる作りです。社内のデータで評価するときは、最初に設定しておくと安心です。

評価データの形

1件の評価データは、質問・回答・検索した資料・正解の4つです。 正解（reference）は、人が書いた「理想の答え」です。

reference が要らない指標（Faithfulness・Answer Relevancy）は、本番のログにもそのまま使えます。 reference が要る指標は、評価用に正解を用意した質問でだけ測れます。

この記事では、社内規程の FAQ を想定した5件を使いました。それぞれ、わざと違う種類の失敗を入れています。

CTX_LEAVE   = "有給休暇は取得日の3営業日前までに勤怠システムで申請します。"
CTX_SICK    = "当日の体調不良による休暇は、始業前に上長へ連絡し、事後に申請します。"
CTX_EXPENSE = "経費精算は月末締めで、翌月5日までに申請します。"
CTX_REMOTE  = "在宅勤務は週3日までです。前週の金曜日までに申請します。"

samples = [
  dict(id="S1 正常", user_input="有給休暇はいつまでに申請しますか",
       retrieved_contexts=[CTX_LEAVE, CTX_SICK],
       response="有給休暇は取得日の3営業日前までに申請します。勤怠システムから申請します。",
       reference="有給休暇は取得日の3営業日前までに勤怠システムで申請します。"),
  dict(id="S2 根拠にない文", user_input="在宅勤務は週何日までですか",
       retrieved_contexts=[CTX_REMOTE],
       response="在宅勤務は週3日までです。申請は前週の金曜日までです。交通費は在宅日も支給されます。",
       reference="在宅勤務は週3日までです。前週の金曜日までに申請します。"),
  dict(id="S3 検索の取りこぼし", user_input="経費精算の締め日はいつですか",
       retrieved_contexts=[CTX_REMOTE, CTX_LEAVE],
       response="経費精算は月末締めで、翌月5日までに申請します。",
       reference="経費精算は月末締めで、翌月5日までに申請します。"),
  dict(id="S4 順位が低い", user_input="体調不良で休むときの手続きは",
       retrieved_contexts=[CTX_EXPENSE, CTX_LEAVE, CTX_SICK],
       response="始業前に上長へ連絡し、事後に申請します。",
       reference="当日の体調不良による休暇は、始業前に上長へ連絡し、事後に申請します。"),
  dict(id="S5 はぐらかし", user_input="在宅勤務の申請期限は",
       retrieved_contexts=[CTX_REMOTE],
       response="申し訳ありませんが、分かりません。",
       reference="前週の金曜日までに申請します。"),
]

4つの指標をまとめて採点するコード

判定役の LLM と埋め込みを1回作り、4つの指標を1件ずつ ascore で採点します。

import asyncio, os
from openai import AsyncOpenAI
from ragas.llms import llm_factory
from ragas.embeddings.base import embedding_factory
from ragas.metrics.collections import Faithfulness, AnswerRelevancy, ContextPrecision, ContextRecall

client = AsyncOpenAI()                                   # 社内の互換サーバーなら base_url=... を足す
llm = llm_factory("gpt-4o-mini", client=client)
emb = embedding_factory("openai", model="text-embedding-3-small", client=client)

faith    = Faithfulness(llm=llm)
ans_rel  = AnswerRelevancy(llm=llm, embeddings=emb)      # 埋め込みも使う
ctx_prec = ContextPrecision(llm=llm)
ctx_rec  = ContextRecall(llm=llm)

async def main():
    for s in samples:
        f = await faith.ascore(user_input=s["user_input"], response=s["response"],
                               retrieved_contexts=s["retrieved_contexts"])
        a = await ans_rel.ascore(user_input=s["user_input"], response=s["response"])
        p = await ctx_prec.ascore(user_input=s["user_input"], reference=s["reference"],
                                  retrieved_contexts=s["retrieved_contexts"])
        r = await ctx_rec.ascore(user_input=s["user_input"], retrieved_contexts=s["retrieved_contexts"],
                                 reference=s["reference"])
        print(s["id"], round(f.value, 3), round(a.value, 3), round(p.value, 3), round(r.value, 3))

asyncio.run(main())

from ragas.embeddings import embedding_factory と書くと、0.4.3 では Importing embedding_factory from ragas.embeddings is deprecated の警告が出ました。ragas.embeddings.base から読み込むと出ません。

擬似エンドポイントに向けて実行した結果です。

answer_relevancy の値は、擬似エンドポイントが返した簡易な埋め込み（文字の重なり）でのコサイン類似度なので、本物の埋め込みモデルとは大きく違います。ほかの3つは「判定の 0/1 から割合を計算する」部分がそのまま出ています。以下、指標ごとに計算の仕組みと、この結果の読み方を説明します。

Faithfulness：回答が資料に忠実か

回答を短い文（主張）に分け、それぞれが資料から言えるかを 0/1 で判定し、1の割合を点数にします。 資料に書いていないことを回答に足すと下がります（ハルシネーションの検出）。

計算の流れ（ソース：metrics/collections/faithfulness/metric.py）

1. 文に分ける：判定役に質問と回答を渡し、代名詞を使わない短い文のリスト（statements）を作らせる（StatementGeneratorPrompt）。
2. 1文ずつ判定する：資料（retrieved_contexts を改行でつないだもの）と文のリストを渡し、各文に verdict（1：資料から直接言える、0：言えない）と reason を付けさせる（NLIStatementPrompt）。
3. 割合を出す：verdict が1の文の数 ÷ 文の数。

$$\text{Faithfulness} = \frac{\text{資料から言える文の数}}{\text{回答から作った文の数}}$$

文が1つも作られないときは NaN（数値なし）を返します。

この結果の読み方

• S2 は 0.667：回答の3文のうち「交通費は在宅日も支給されます」が資料に無いので、2/3 になりました。内容が正しいかどうかではなく、資料に書いてあるかで決まります。資料の外の一般知識で正しく答えても下がります。
• S3 は 0.000：回答は正しい内容ですが、検索した資料（在宅勤務・有給）に経費精算の話が無いので、どの文も資料から言えません。LLM が自分の知識で答えた場合も、この形になります。
• S5 は 0.000：「分かりません」という文も、資料から言える内容ではないと判定されました。

判定役に送られたプロンプト

文に分ける1回目のリクエストの、最後の部分です（ragas が組み立てた user メッセージ）。

Now perform the same with the following input
input: {
    "question": "有給休暇はいつまでに申請しますか",
    "answer": "有給休暇は取得日の3営業日前までに申請します。勤怠システムから申請します。"
}
Output:

その前に、英語の指示文（Given a question and an answer, analyze the complexity of each sentence in the answer. Break down each sentence into one or more fully understandable statements. Ensure that no pronouns are used in any statement.）、出力の JSON Schema、アインシュタインの例（英語）が入っていました。このメッセージは 1,744 文字でした。2回目の判定のプロンプトの指示文は For each statement you must return verdict as 1 if the statement can be directly inferred based on the context or 0 if the statement can not be directly inferred based on the context. です。

Answer Relevancy：回答が質問に向き合っているか

回答から「この回答が答えていそうな質問」を判定役に作らせ、元の質問との埋め込みのコサイン類似度の平均を点数にします。 回答が質問からずれているほど、作られた質問が元の質問と似なくなり、点数が下がります。

計算の流れ（ソース：metrics/collections/answer_relevancy/metric.py）

1. 判定役に回答を渡し、question（作った質問）と noncommittal（はぐらかしなら1）を返させる。これを strictness 回（既定3回）くり返す。
2. 元の質問と、作られた質問それぞれを埋め込みにする。
3. コサイン類似度の平均を出す。3回とも noncommittal=1 なら0にする。

$$\text{Answer Relevancy} = \frac{1}{N}\sum_{i=1}^{N}\cos(E_{q},\ E_{g_i}) \times [\text{はぐらかしでない}]$$

ここで $E_q$ は元の質問の埋め込み、$E_{g_i}$ は作られた $i$ 番目の質問の埋め込み、$N$ は strictness です。

• S5 が 0.000 なのは、「分かりません」に対して noncommittal=1 が3回返り、最後に0を掛けたためです。
• 正しい情報を含んでいても、質問と関係のない話が多い回答は下がります。逆に、事実が誤っていても質問に向き合っていれば高く出ます。正しさはこの指標では測れません。
• 埋め込みのコサイン類似度は、モデルによって「関係のない文どうし」でも 0.5 前後になることがあります。点数の絶対値より、同じモデルでの比較に使います。

AnswerRelevancy(llm=llm, embeddings=emb, strictness=1) のように strictness を下げると、判定役の呼び出しが減ります。

Context Precision：役立つ資料が上位にあるか

検索した資料を1件ずつ「正解を出すのに役立ったか」で 0/1 判定し、上位ほど重く見る「平均適合率」を点数にします。 役立つ資料がすべて上位にあれば1、下位にあるほど下がります。

計算の流れ（ソース：metrics/collections/context_precision/metric.py）

資料1件ごとに判定役を1回呼び、verdict（0/1）を集めて次の式で計算します。

$$\text{Context Precision@K} = \frac{\sum_{k=1}^{K}\left(\text{Precision@}k \times v_k\right)}{\text{上位K件の中の役立つ資料の数}}$$

$v_k$ は $k$ 位の資料が役立つなら1、そうでなければ0です。Precision@$k$ は「上位 $k$ 件のうち役立つ資料の割合」です。ソースでは分母に 1e-10 を足しているので、CSV に保存された値は 0.9999999999 のようになっていました。

S4 は、必要な資料（体調不良の規程）は取れているのに3位だったため 0.333 になりました。 検索結果を LLM に渡す件数を絞る（上位2件だけ渡すなど）と、この資料は落ちます。

ContextPrecision は正解（reference）と比べる版です。正解が無いときは、回答と比べる ContextPrecisionWithoutReference（ascore(user_input, response, retrieved_contexts)）を使います。

Context Recall：必要な情報がそろっているか

正解を文に分け、それぞれが検索した資料から言えるかを判定し、言える文の割合を点数にします。 正解に必要な情報を検索が取りこぼすと下がります。

計算の流れ（ソース：metrics/collections/context_recall/metric.py）

1. 資料を改行でつなぎ、正解と一緒に判定役に1回渡す。
2. 判定役は、正解を文に分け、各文に attributed（1：資料から言える、0：言えない）を付けて返す。
3. attributed の合計 ÷ 文の数。

$$\text{Context Recall} = \frac{\text{資料から言える正解の文の数}}{\text{正解の文の数}}$$

• S3 は 0.000：経費精算の資料が検索で取れていないためです。回答は正しいので、回答だけ見ていると気づけない失敗です。
• S5 は 1.000：検索は必要な資料を取れていて、回答の段階で失敗しています。Context Recall と Faithfulness の組み合わせで、どちらの段階の問題かが分かります。

判定役 LLM の設定と、送られるリクエスト

llm_factory は、OpenAI の SDK のクライアントを受け取り、instructor（構造化出力のライブラリ）を通して判定役を呼びます。 擬似エンドポイントに届いたリクエストを記録しました。

client = AsyncOpenAI(base_url="http://127.0.0.1:8143/v1", api_key="dummy")
llm = llm_factory("gpt-4o-mini", client=client)          # 型は InstructorLLM
emb = embedding_factory("openai", model="text-embedding-3-small", client=client)   # 型は OpenAIEmbeddings

system メッセージは instructor が付けたもので、As a genius expert, your task is to understand the content and provide the parsed objects in json that match the following json_schema: で始まっていました。判定役のモデルは、JSON モード（response_format: json_object）に対応している必要があります。

5件の評価で何回呼ばれたか

chat が39回、埋め込みが10回でした。 Context Precision は資料の数に比例し、Answer Relevancy は strictness に比例します。1件あたりの資料を10件にすると、Context Precision だけで1件10回になります。費用を見積もるときは、この回数に1回あたりのトークン数を掛けます。英語の指示と例が毎回入るので、短い質問でもプロンプトは長くなります（文に分けるプロンプトは 1,744 文字でした）。

判定役の選び方と注意

• 判定役は、評価される RAG と別のモデルにしておくと、点数の比較がしやすくなります。 RAG 側のモデルを入れ替えて比べるときも、判定役が同じなら物差しが変わりません。
• 判定役のプロンプトと例は英語です。日本語の回答でも動きますが、文の分け方は判定役の LLM しだいです。各プロンプトには adapt(target_language, llm) というメソッドがあり、例を翻訳したプロンプトを作れます（ragas/prompt/metrics/base_prompt.py）。
• 判定はモデルが変わると変わります。判定役のモデルとバージョンを固定し、点数と一緒に記録します。
• 最初は判定役の結果を人が20〜30件ほど見て、人の判断と合っているか確かめると、点数を信頼できるか判断できます。

Anthropic のモデルを判定役にするときは、llm_factory("claude-...", provider="anthropic", client=AsyncAnthropic()) の形が ragas の docstring に書かれています。

まとめて実行して保存する（@experiment と Dataset）

0.4.3 では、evaluate() の代わりに Dataset と @experiment を使う形が勧められています。 評価データを CSV で保存し、評価結果も実験ごとに CSV で残せます。

import json
from ragas import Dataset, experiment

# 1. 評価データを CSV に保存する（リストは JSON の文字列にして入れる）
ds = Dataset(name="faq_v1", backend="local/csv", root_dir="./evals")
for s in samples:
    ds.append({**s, "retrieved_contexts": json.dumps(s["retrieved_contexts"], ensure_ascii=False)})
ds.save()

# 2. 1行ぶんの評価を書く
@experiment()
async def rag_eval(row):
    ctx = json.loads(row["retrieved_contexts"])
    f = await faith.ascore(user_input=row["user_input"], response=row["response"], retrieved_contexts=ctx)
    a = await ans_rel.ascore(user_input=row["user_input"], response=row["response"])
    p = await ctx_prec.ascore(user_input=row["user_input"], reference=row["reference"], retrieved_contexts=ctx)
    r = await ctx_rec.ascore(user_input=row["user_input"], retrieved_contexts=ctx, reference=row["reference"])
    return {"id": row["id"], "faithfulness": f.value, "answer_relevancy": a.value,
            "context_precision": p.value, "context_recall": r.value}

# 3. 全行を実行する
async def main():
    dataset = Dataset.load(name="faq_v1", backend="local/csv", root_dir="./evals")
    exp = await rag_eval.arun(dataset, name="baseline")
    import pandas as pd
    df = pd.DataFrame(list(exp))
    print(df.drop(columns="id").mean().round(3).to_dict())

{'faithfulness': 0.533, 'answer_relevancy': 0.304, 'context_precision': 0.667, 'context_recall': 0.8}

作られたファイルは evals/datasets/faq_v1.csv と evals/experiments/baseline.csv の2つでした。実験の結果は終わった順に追記されるので、CSV の行は S5・S2…の順で、評価データの順ではありませんでした。id の列を入れておくと突き合わせやすくなります。1行の処理で例外が起きると Warning: Task failed with error: ... と表示され、その行を飛ばして続きます（experiment.py）。

name を「baseline」「chunk500」「rerank」のように変えて実行すると、設定ごとの結果が別の CSV に残り、比べられます。

結果の読み方と改善のつなぎ方

4つの指標の組み合わせで、検索と生成のどちらに問題があるかを切り分けます。

この記事の5件では、S3 は検索、S4 は並び順、S2 と S5 は生成の問題と読めます。平均（Faithfulness 0.533 など）だけを見ると、どこを直すかが分かりません。指標ごとに点数の低いサンプルを並べて、中身を読むのが、改善につなげる近道です。

改善の手順の例です。

1. 評価データを固定する（同じ質問・同じ正解）。
2. 今の設定で実験を1回流し、baseline として保存する。
3. 1か所だけ変える（例：チャンクを 500 文字 → 300 文字）。
4. 同じ評価データで再実行し、指標ごとの差と、点数が変わったサンプルを見る。
5. 判定のぶれがあるので、差が小さいときは複数回流すか、件数を増やして確かめる。

RAG の原因の切り分け方と打ち手の一覧は、関連記事「RAGの精度改善の方法一覧｜原因の切り分けと評価指標の計算」で、RAG の作り方は、関連記事「RAGの作り方｜Pythonで動かす最小構成と精度の上げ方」で扱っています。

評価データの作り方

評価データは「本番で来る質問」に近いほど役に立ちます。 作り方の選択肢です。

件数の目安は、まず30〜50件で、検索の失敗・生成の失敗・答えのない質問（「資料にありません」が正解）・複数の資料が要る質問を混ぜます。答えが資料に無い質問を入れておくと、ハルシネーションを抑える設定の効果が測れます。

TestsetGenerator は 0.4.3 にもあり、generate_with_langchain_docs(documents, testset_size, ...) で LangChain の文書から質問と正解を作ります。以前の記事の ragas.testset.evolutions は 0.4.3 には無く、ModuleNotFoundError でした。質問の種類の割合は query_distribution で指定します。

テストケースの表の作り方は、関連記事「LLMの評価方法と評価指標一覧｜テストケース表のテンプレート付き」で扱っています。

そのほかの指標（0.4.3 の collections）

AnswerCorrectness の既定の重みは weights=[0.75, 0.25]（事実の一致 0.75、意味の近さ 0.25）でした（__init__ の引数）。LLM を使わない指標は、判定役の費用がかからず、結果がぶれないので、CI で毎回流す用途に向きます。

よくある質問

Q. 点数が何点以上なら合格ですか。 A. 判定役のモデル・プロンプト・評価データで点数の水準が変わるので、決まった基準はありません。最初の実験の点数を基準にし、変更の前後で下がっていないかを見る使い方が確実です。

Q. 本番のログで常に監視できますか。 A. Faithfulness と Answer Relevancy は正解が要らないので、ログの一部を抜き出して定期的に採点できます。1件ごとに判定役を数回呼ぶので、全件ではなく抜き出しで流すと費用を抑えられます。

Q. 社内の LLM（OpenAI 互換の API）を判定役にできますか。 A. AsyncOpenAI(base_url="https://社内のURL/v1", api_key=...) を llm_factory に渡すと、その URL に送られます（この記事の擬似エンドポイントと同じ仕組み）。JSON モードの response_format に対応しているかを先に確かめます。

まとめ

• 0.4.3 では ragas.metrics.collections の指標を llm_factory の LLM で作り、ascore で採点する。evaluate() は非推奨
• 2026年10月13日時点では langchain-community<0.4.2 にしないと import でエラーになった
• Faithfulness は回答の文が資料から言える割合、Context Recall は正解の文が資料から言える割合
• Context Precision は役立つ資料の順位を見る平均適合率。3位にあると 0.333
• Answer Relevancy は回答から作った質問と元の質問のコサイン類似度。はぐらかしは0
• 判定役には temperature=0.01・JSON モードで、英語の指示と例が毎回送られる。5件4指標で chat 39回・埋め込み10回
• 平均ではなく、指標の組み合わせで検索と生成のどちらの問題かを切り分け、低いサンプルの中身を読む
• RAGAS_DO_NOT_TRACK=true で使用状況の送信を止める

参考・出典

確認日はいずれも 2026年10月13日です。

• Ragas ドキュメント：https://docs.ragas.io/
• Ragas ドキュメント「Context Precision」：https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/context_precision/
• Ragas ドキュメント「Faithfulness」：https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/faithfulness/
• Ragas ドキュメント「Answer Relevancy」：https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/answer_relevance/
• Ragas ドキュメント「Context Recall」：https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/context_recall/
• Ragas ドキュメント「Experiments」：https://docs.ragas.io/en/latest/concepts/experiment/
• explodinggradients/ragas（GitHub）：https://github.com/explodinggradients/ragas
• ragas（PyPI）：https://pypi.org/project/ragas/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。