評価 (クライマックス) — RAGAs 4 指標で Part 1-3 の改善を客観評価する

2026-05-24 改訂: 本シリーズは Ollama + Qwen3 で完全ローカル再現できる構成に作り直しました。本記事のスコアはすべて judge = qwen3:8b (Ollama) で実測した 30 件 × 4 指標です。generation も judge も同じ qwen3:8b なので self-preference バイアスが構造的に乗ります — 絶対値ではなく Part 間の delta を信号として 読んでください。なお 30 件 × 3 pipeline の一括評価は Apple Silicon で 1 時間強かかります (Part 5 のコスト節で触れます)。

Part 1 で「動くけど使えない」失敗を 3 グループに整理し、Part 2 で hybrid+filter により旧版 (archived) を top-5 から追い出し、Part 3 で cross-encoder reranker と Anthropic Citations API で意味的 trap と引用喪失を縮めました。けれどここまでの「よくなった」はすべて 代表クエリ数件の眺め であって、客観評価ではありません。本記事 (Part 4) ではシリーズの宿題を回収します。30 件の golden set × RAGAs 4 指標 で、Part 1-3 の改善を 1 枚の表に翻訳します。

最初に正直なことを書きます。RAGAs のスコアは LLM-as-judge で算出されるため、judge LLM の偏りや幻覚がスコアに直接乗ります¹。本記事は「数字を絶対視する」のではなく、同じ judge / 同じ golden set で Part 1-3 を相対比較する 立場で書きます。そして本 Part には、シリーズ全体で最も大事な瞬間が含まれます — 測定が、eyeball では見抜けなかった失敗を炙り出す 瞬間です。

なぜ「評価」が連載のクライマックスなのか

Part 1 末尾で「測定は Part 4 で扱う」と約束しました。回収する理由は単純で、ここまでの 3 つの打ち手は trap rank / top-5 純度 / citation のような 個別の観測値 で語ってきたからです。

特に Part 3 の「trap が下がった」は要注意です。後で見るように、単一クエリの eyeball では「大勝利」に見えた reranker が、30 件の aggregate ではむしろ品質を下げていた — という逆転が、まさにこの Part で起きます。

評価視点の地図 — retrieval / generation / end-to-end

RAG の評価は 3 つの独立した層 に分かれます²。同じスコアシートでも「どの層を測っているか」を混同すると改善方向を誤ります。

Part 1-3 で見てきた trap rank や top-5 の眺めは Retrieval 層の断片 です。Generation 層に持ち込むと「retrieve できたが LLM が使わなかった」「使ったが間違って要約した」が新しい failure mode として出てきます³。RAGAs はこの 3 層のうち Retrieval 層と Generation 層をまとめて測る ことで、層を跨いだ回帰を捉えます²。

Golden set 30 件で十分の現実

「評価には 1000 件必要では」という直感は 間違い です。実務的なガイドラインは以下のような感覚です⁴:

本シリーズは 30 件 self-curated から始めます。理由は 3 つ: 手で全件レビューできる規模、5pp 以上の delta が run 間ノイズより大きい、1 件 5 分として 2-3 時間で作れる。「質を最優先」 にしてください。100 件の雑な golden より、30 件の正確な golden の方が改善判断の役に立ちます。

30 件の構成 — 何を意図的に入れるか

companion repo の corpus/v2/golden_set.jsonl は以下の意図で 30 件を組み立てます:

• Happy (15 件): 対応する doc が corpus 内に明確に存在し、retrieve も generation も成立する想定
• Sad (10 件): 答えが出にくい難ケース。複数 doc に部分的に答えが散る ambiguous、または corpus に答えがない negative (例: 「Project Lumen 今期リリース計画は？」← 顧客 NDA で非公開設定)。「資料からは判断できません」 を返すのが正解
• Edge (5 件): filler 文書が genuine になる端 (例: 「お菓子コーナーの支払い方法は？」) や、表層 trap が刺さるクエリ

Sad の negative を意図的に混ぜることで、「とりあえず何か返す」モード に堕ちていないかを Faithfulness が炙り出します。Part 1-2 で仕込んだ trap (ボードゲーム同好会の post-mortem 構造、LT 大会の評価基準、物流ロールバック) は、この edge/sad で評価対象になります。

RAGAs 4 指標 — 何を測り、何を測らないか

RAGAs⁵ は LLM-as-judge ベースの評価ライブラリです。本記事では 4 つの中核指標を扱います。

Faithfulness — claim と context の整合性

Faithfulness は「生成 answer 内の claim が retrieved context で裏付けられる割合」です⁶。judge LLM は answer を「事実 claim」に分解し、各 claim について context 内から evidence を探し、見つかれば 1、見つからなければ 0 を付けます。Part 3 で Citations API を導入したことが直接効くのは ここ です。

Answer Relevance — query と answer の対応

Answer Relevance は「answer が query の問いに答えているか」を測ります⁷。judge LLM が answer から「逆問い」を N 件生成し、元 query とのコサイン類似度の平均を取ります。「query と全く関係ない正論」を返すと低スコアになります。

Context Precision — retrieved の中で本当に有用な割合

Context Precision は retrieved chunks のうち、reference を導くのに 実際に役立つ chunk の比率 を順位重み付きで測ります⁸。順位重みがついているので 「上位に relevant を集める」 ことを評価します。Part 3 の cross-encoder rerank で top-3 に relevant を集中 させたことが、この指標を直接押し上げます。

Context Recall — reference の claim を context がカバーしているか

Context Recall は reference answer 内の claim のうち、retrieved context が裏付けられる割合です⁹。「retrieved chunks に答えがそもそも含まれていない」状態をここで検出します。Part 2 の hybrid 検索が top-5 の純度を上げたことは Context Recall を押し上げる方向の打ち手です。

4 指標の相関と直交

4 指標は独立ではありません。特に 「Faithfulness ↑ + Answer Relevance ↓」(context にあることは正しいが聞かれた問いに答えてない) の組み合わせは、Faithfulness だけ追いかける危険性 を示します。4 指標を必ず併記 してください。後で見る実測でも、まさに Answer Relevance だけが他と逆の動きをします。

RAGAs を Part 1-3 に当てる (Ollama judge)

実装は companion repo の examples/evaluate.py にまとまっています。RAGAs 0.4.x の collections API を、judge も embedding も Ollama に向けて使います¹⁰。

from openai import AsyncOpenAI
from ragas.llms import llm_factory
from ragas.metrics.collections import (
    Faithfulness, AnswerRelevancy, ContextPrecision, ContextRecall,
)

# Ollama の OpenAI 互換エンドポイントに向ける
client = AsyncOpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
llm = llm_factory("qwen3:8b", client=client, temperature=0)

実装でハマった 2 つの罠 (Qwen3 を judge にする時)

ローカルの thinking 系モデルを RAGAs の judge にすると、素朴には動きません。2 つ実機で踏みました:

1. reasoning leak: Qwen3 は既定で思考を reasoning フィールドに吐き、content が空のまま max_tokens に到達 → instructor が JSON を parse できず retry 枯渇で落ちます。Ollama の OpenAI 互換経路では /no_think も chat_template_kwargs も効かず、reasoning_effort: "none" だけが思考を抑止 しました (実測で確認)。
2. 反復 degeneration: それでも稀に "当社の当社の当社の…" の無限反復に陥り token を食い潰します。frequency_penalty=0.3 で抑止し、加えて 1 指標が落ちても run 全体を止めない per-metric ガードを入れました。

「ローカル LLM を評価器にする」は、API を叩くより一段地味な落とし穴があります。これも 0 円再現の代償の一部です。

gen も judge も qwen3:8b — self-preference は避けられない

v1 の本記事は generation=Claude / judge=gpt-4o-mini と 別ベンダ にして self-preference バイアスを回避していました。けれど 16 GB Mac の 0 円経路では、generator も judge も同じ qwen3:8b を共用します。judge は自分が書きそうな answer を高く評価する傾向¹¹があるので、絶対値は構造的に高めに出ます (この後 Faithfulness が naive でも 0.97 になるのはこのため)。

これは「バグ」ではなく このシリーズの再現条件そのもの です。だからこそ繰り返します — 絶対値を信じず、同じ judge で測った Part 間の delta を読む。self-preference を読者が自分の Mac で観測できる、とも言えます。

30 件回した結果 — 測定が逆転を炙り出す

30 件を回した実測値です。judge = qwen3:8b × 1 seed の単一 run であり、絶対値ではなく Part 間の delta を信号として読んでください。

読み取れること:

• Context Precision が 0.76 → 0.84 → 0.91 と単調上昇: rerank の本領。top-3 に relevant を集中させた効果が aggregate で +14.5pp として確認できる。本シリーズで最も綺麗に効いた指標
• Faithfulness が 0.97 → 0.99: 既に高いが単調上昇。Citations の grounding が claim-evidence 紐付けを微改善 (絶対値が高いのは self-preference)
• Context Recall は P2 が最良 (0.87)、P3 で微減 (0.85): top-3 まで絞った副作用。許容範囲だが、k=3 がトレードオフを生むことが数値で見える
• Answer Relevance だけ横ばい〜微減 (0.53 → 0.53 → 0.51): 唯一改善しない指標。answer は全 pipeline で同じ「chunk 連結」スタブなので、retrieval 品質が上がっても answer の言い回しは変わらず、ここは判定ノイズ範囲。4 指標を併記しないと「全部良くなった」と誤読する 好例

測定が捕まえた失敗 — 英語 reranker の罠

ここが本 Part のクライマックスです。Part 3 で触れた通り、最初は reranker に 英語の ms-marco-MiniLM-L-6-v2 を使っていました。単一クエリ (コードレビュー) の eyeball では、trap を rank 2 → 9 まで突き落とし、大勝利に見えました。

ところが同じ 30 件を ms-marco で測ると:

英語 reranker は、日本語の chunk をほぼランダムに並べ替えて関連 chunk を取りこぼし、P3 を P2 より大幅に悪化 させていました (CR 0.87 → 0.66)。単一クエリの eyeball test では絶対に気づけなかった回帰です。これに気づけたのは 30 件を測ったから で、多言語 bge-m3 に切り替えて初めて P3 が P2 を上回りました (上表)。

これが「評価」が連載のクライマックスである理由 です。retrieval を真面目にし、引用を付け、reranker を足し — どれも「良くなった気がする」打ち手でした。けれど 測って初めて、その 1 つが実は品質を下げていた ことが分かる。offline 評価は、自分の改善を疑うための装置です。

P3 の Faithfulness 0.99 を「絶対的に良い」とは読めません。Stanford 2025 の legal RAG 研究では purpose-built システムでも 17-34% の hallucinate が報告されています¹²。self-preference で高く出た 0.99 を真に受けず、delta と相対順位 で読むのが正しい姿勢です。

LLM-as-judge の良いところと悪いところ

RAGAs のスコアは LLM-as-judge です。注意点を整理します。

• 同型バイアス (self-preference): gen=judge=qwen3:8b の本構成では構造的に乗る¹¹。絶対値を内部比較にしか使えない。別ベンダ judge (gpt-4o-mini 等) を使えば緩和できるが、それは 0 円経路を捨てることを意味する
• 位置バイアス: 複数 answer を比較する時は順序 swap して平均¹³。本記事は指標単独 scoring なので影響小
• Verbosity / Style bias: 長い・整然とした answer を高評価しがち¹⁴。answer 長を pipeline 間で揃える (本記事は同じスタブ)
• Cost / Latency: 30 件 × 4 指標 × 3 pipeline = 360 judgement / run。Ollama qwen3:8b で Apple Silicon 1 時間強。CI 毎 PR は非現実的で、nightly cron + 主要 PR 手動 trigger が現実解

Offline → Online への橋渡し

Part 4 で組んだ「30 件 × 4 指標」は offline batch 評価 です。本番では別の現実があります。

Offline が「変更前後で回帰がないか」を見るのに対し、Online は「現実が想定通り動いているか」を見ます。本 Part で英語 reranker の回帰を捕まえたように、両方が揃って初めて RAG は production-ready です。

Part 5 では online 側で必須になる Logging の設計と PII redaction、embedding drift 検出、古い文書の freshness 退役 (Part 2 の宿題)、コスト構造、インシデント対応とロールバック を扱います。本 Part の 4 指標 dashboard が、Part 5 で online metrics に 接続 されます。

シリーズ全体: 今更聞けない RAG の作り方、評価の仕方

次回 Part 5 (完結): 「本番運用 — Logging Safety / Drift / Cost / Rollback」

参考文献