RAG：ローカルRAGの評価を、 chiffres

#「良さそう」だけでは不十分な理由

Ragasは、Apache 2.0ライセンスで提供されるオープンソースのPythonライブラリで、文書検索パイプラインの品質を数値化します。評価するのは、提供された文章に対する回答の忠実度、質問に対する関連性、取得したコンテキストの適合率と再現率です。これにより、検索側の誤りとモデル側の誤りを切り分けられます。Ollamaで提供するローカルモデルを評価役として動作させることもできます。ただし、そのモデルがRagasの要求する構造化出力形式に従い、コンテキストに質問、参照文章、回答のすべてを収められることが条件です。導入前に3つの点を押さえてください。スコアは同じシステムの2つのバージョンを比較するためのもので、絶対的な品質を採点するものではありません。テストセットはライブラリよりも重要です。そして、オンラインのチュートリアルには旧APIと新APIが混在しています。

回答が誤っている場合、同じ症状の背後にはまったく異なる2つの原因があります。取得した文章に情報が含まれていなかったか、情報は含まれていたのにモデルが的外れな回答をしたかのどちらかです。修正方法は同じではありません。前者ではチャンク分割と埋め込みを、後者ではモデルとプロンプトを調整します。測定しなければ手探りで修正することになり、3つの質問で改善しても、他の5つの質問では悪化していることに気づけません。

もう一つの落とし穴は比較です。「270億パラメータのモデルは、この場合、本当に優れているのか？」という問いに答えるには、議論するのではなく、同じ質問セットをもう一度実行します。それを可能にするのが、再現可能な評価です。RagasはGitHubで15,000を超えるスターを獲得しています。PyPIで公開されている最新バージョンは、2026年1月13日付の0.4.3で、リポジトリは別のGitHub組織（vibrantlabsai）へ移っています。使用するバージョンを固定してください。

#重要となる4つの測定項目

Ragasのドキュメントでは、回答の関連性は正確性を評価するものではないと明記されています。測るのは質問にどれだけ適合しているかだけで、不完全な回答や不要な詳細が多い回答は減点されます。そのため、回答の関連性は忠実性の代わりにはなりません。これらの数値は、組み合わせて読み解くことで役に立ちます。再現率が低く、忠実性が高い場合は、情報を捏造せずに答えているものの、十分な情報が与えられていないシステムを示します。検索・取得の部分を改善する必要があります。忠実性が低く、再現率が高い場合は、その逆です。情報はあったのに、モデルが話を作り足しています。この2つは、処理の流れのそれぞれ反対側にある段階で修正する必要があります。

#テストデータセットの構築

ここは手間のかかる部分で、何の影響もなく自動化できるわけではありません。有用なデータセットには、ユーザーが実際に尋ねた質問を、不器用な言い回し、独自の略語、入力ミスもそのまま含めます。ドキュメントを書いた人がきれいに言い換えた質問ではありません。

1. 01
   実際の利用で出てきた質問から始める

   実際の使用場面から得られる30〜50の質問は、作り出された200の質問よりも価値があります。失敗した質問も含めてください。それらが最も教育的です。
2. 02
   参照回答を記述

   各質問に対して、正解を一文または二文で記述します。Ragas はこれをコンテキストのリコール率を推定するために使用します。LLM ベースのバージョンでは、この参照を期待されるパッセージの代替として使用するため、パッセージを一つずつアノテーションする必要がありません。
3. 03
   回答のないケースを保持する

   コーパスに答えが含まれていない質問です。良いシステムは、答えがないことを明示すべきです。こうしたケースがなければ、その能力を測定することはできません。
4. 04
   評価用データセットを固定する

   システムを変更する際に、評価用の問題セットまで変更してはいけません。そうすると、時点間の比較ができなくなります。

Ragasは、コーパスそのものから合成テストセットを作るための生成支援機能も提供しています。ドキュメントでは、シングルホップの質問（単一の情報源）とマルチホップの質問（複数の情報源を結び付ける必要があるもの）を区別し、具体的な質問と抽象的な質問も扱っています。公式ガイドでは、英語以外の言語のコーパスに適応させる方法を、スペイン語を例に紹介しています。実際のユーザーの質問が十分に蓄積される前に、最初の評価を始めるためのものです。便利な出発点ではありますが、決して実際の質問の代わりにはなりません。すべて合成されたテストセットでは、不自然な言い回しや入力ミスが抜け落ちます。まさにそうしたものが、文書検索の実際の弱点を明らかにするのです。

#すべてをローカルで実行

Ragasは評価に2つのモデルを使用します。質問、文章の抜粋、回答を読む評価モデルと、類似度の測定に使う埋め込みモデルです。RagasのクイックスタートではデフォルトでOpenAIを使用しますが、Ollamaを使う方法も紹介しています。接続先をhttp://localhost:11434/v1に設定したOpenAI互換クライアントを、llm_factory関数に渡します。埋め込みモデルが必要なのは回答の関連性だけで、忠実度、コンテキストの適合率と再現率には評価モデルだけを使用します。

ローカルの評価モデルが信頼できるためには、2つの条件があります。1つ目は構造化出力です。現在の評価指標では、評価モデルに、指定された形式で中間的な判断を出すことを求めます（主張の抽出、判定など）。ローカルモデルが通常の文章で回答してこの要件を満たせないと、JSONエラーや空のスコア（NaN）が生じます。OneUptimeのガイドでは、一連の評価を始める前に、ごく小さな呼び出しで評価モデルをテストすることを勧めています。モデルの最小サイズを定めた公式情報はありません。ご自身で検証する必要があります。2つ目はコンテキストです。Ollamaは、VRAMが24 GiB未満の場合、デフォルトで4,000トークンのコンテキスト長を適用します。ドキュメントでは、負荷の高いタスクにはこの値（変数 OLLAMA_CONTEXT_LENGTH）を増やすことを勧めています。コンテキスト長を超えてしまう評価モデルは、実際には切り詰められたテキストを採点しています。

• 評価対象のRAGチェーンを構築する
• フランス語向けの埋め込みモデルを選択
• コンテキストの精度が低い場合、rerankerを追加する
• Langfuse：取得されたスコアを追跡・保存

# pip install ragas openai
from openai import AsyncOpenAI
from ragas.llms import llm_factory
from ragas.metrics.collections import Faithfulness, ContextRecall

# Client compatible OpenAI pointé sur Ollama (la clé est un simple libellé)
client = AsyncOpenAI(api_key="ollama", base_url="http://localhost:11434/v1")
juge = llm_factory("mistral", provider="openai", client=client)  # nom du modèle tiré avec ollama pull

fidelite = Faithfulness(llm=juge)
resultat = fidelite.score(
    user_input="Où se trouve la tour Eiffel ?",
    response="La tour Eiffel se trouve à Paris.",
    retrieved_contexts=["La tour Eiffel est située à Paris, en France."],
)
print(resultat.value)  # entre 0 et 1

#結果を正しく読み取る

これらは指標であり、点数ではありません

忠実性スコアが0.82でも、「回答の82％が正しい」という意味ではありません。この数値は、同じシステムの2つのバージョンを比較するためのもので、絶対的な品質を保証するものではありません。

ジャッジにはバイアスがあります

LLMを評価者として使う手法についての代表的な論文（arXiv 2306.05685）は、回答の提示位置、冗長さ、自己選好に関するバイアスを説明しています。評価を繰り返す際は、同じ評価者を使い続けてください。そうしないと、結果の差はシステムではなく評価者の違いを測ることになります。

1回の評価だけでは何も証明できません

生成結果は変動します。小さなテストセットで数百分の誤差はノイズと見なせます。

手動でいくつかの事例を確認してください

数値はどこに注目すべきかを示しますが、何が問題なのかまでは教えてくれません。一連の評価で結果が最も悪かった10件からは、全体の平均値よりも多くのことを学べます。

#具体的なユースケース

分割サイズを選ぶ

チャンクのサイズを256、512、1024トークンの順に変えて同じテストセットを再実行すると、未検証の好みで選ぶのではなく、構成ごとの再現率を数値で得られます。

エンベディングモデルの変更を検証する

新しい埋め込みモデルであっても、一般ベンチマークで優れていると発表されても、あなたの特定のコーパスにおけるコンテキストの精度を低下させる可能性があります。その点は、ローカルでのテストによってのみ確認できます。

リランカーの追加を正当化する

リランキング前後のコンテキストの精度を比較すれば、改善の効果を数値化できます。そうしなければ、会議で共有される印象にとどまってしまいます。

コーパス更新後の性能低下を追跡する

新しいドキュメントの追加は検索の精度を低下させる可能性があります。毎回インポート後に固定されたテストデータを再実行することで、ユーザーが気づく前に性能の低下を検出できます。

2つのサービス提供業者またはアーキテクチャから選ぶ

同じ文書処理パイプラインを構築するための2つの競合案を比べる場合、同じテストセットと同じコーパスで得られたスコアを使えば、営業デモよりも早く優劣を判断できます。

#キャンペーンの管理

評価の実施頻度

分割方法、埋め込みモデル、生成モデルのいずれかを変更するたびに実施します。安定したシステムでは、毎日評価を実施する必要はありません。

テストコーパスのサイズ

質問セットは小規模なままです。一方、評価対象の文書コーパスは、本番環境のコーパスを現実に即して再現したコピー、またはそのコーパス全体である必要があります。

キャンペーンの実際のコスト

各メトリクスではジャッジが複数回呼び出されます（忠実度の場合：アサーションの抽出、および各アサーションの検証）。そのため、コストは質問数とメトリクス数の積に比例して増加します。50問の実行前に5問で計時を行い、その結果に基づいてキャンペーンを計画してください。

#この方法の限界

モデルを使った評価とは、ある人工知能に別の人工知能を評価させることです。この方法は有用で低コストですが、完全ではありません。性能の後退を検出し、複数のバリエーションを順位付けできます。ただし、事実誤認が責任問題につながる重要な分野では、人間によるレビューの代わりにはなりません。また、評価を実施するたびに計算時間を消費します。ユーザーへのサービス提供にも使っているマシンでは、利用が集中する時間帯を避け、夜間や週末など負荷が低いときに実行します。

冗長性バイアスについては、直感に反するため、もう少し説明が必要です。OneUptimeの記事では、長い回答の中では、評価役が評価基準のキーワードを引用し、網羅的に見せ、説得力のある根拠を示す機会が増えると説明されています。そのため、評価対象のモデルにより長い回答を促すプロンプトは、ユーザーへの回答を改善しなくても、スコアを上げる可能性があります。忠実性については、RagasのドキュメントでもHHEM-2.1-Openを使った別方式が紹介されています。これはVectaraが提供する、ハルシネーション検出用の小型で無料の分類器です。検証の段階を専用モデルに置き換えるもので、ローカルの評価役が不安定な場合に試してみるとよいでしょう。

最も簡単な対策は、測定方法をそろえることです。ある評価者で得た忠実度スコアを、別の評価者で得たスコアや第三者が公表したスコアと比較してはいけません。数値が意味を持つのは、同じ評価者、同じ評価プロンプト、同じバージョンの指標を使った、同一の測定条件の中だけです。これは内部比較のための道具であり、普遍的なランキングではありません。

• ソース：GitHub 上の Ragas オフィシャルリポジトリ
• 出典：自動評価器の冗長性バイアス
• 出典：忠実性指標の公式ドキュメント
• 出典：Ragasのクイックスタート（Ollamaを使用する版）
• 出典：Ollama のデフォルトのコンテキスト長
• 出典：無効なJSONを生成するローカルの評価モデルを使ったRAGの評価
• 出典：LLM ジャッジに関する参考記事

#FAQ