見出し画像

RAGの性能評価にAWSが公開したRAGCheckerが良さそう

掛谷知秀

こんにちは、スクーティーという生成AIを活用したシステム開発が得意な会社の代表をやっているかけやと申します。

最近弊社で、オンプレミス環境でLlama3を使用してRAGを構築するという案件があり、RAGの性能を検証するために評価方法を色々調べていたのですが、AmazonのAWS AIチームからRAGCheckerというものが公開されていたため、論文を読んでみました。

本記事は、その論文の要約になります。


RAGCheckerとは

RAGChekerとは、RAGシステムの精度と信頼性を詳細に診断・評価するためのフレームワークです。

RAGChekerは、Retrieval-Augmented Generation (RAG)システムを詳細に診断し、リトリーバーとジェネレーターのモジュールごとのパフォーマンスを評価するためのフレームワークです。従来の評価指標（例：Recall@kやBLEU、ROUGE、BERTScoreなど）が短文応答に特化していたのに対し、RAGChekerはクレーム（RAGシステムによって生成される応答の中の個々の主張や情報断片のこと）ごとの精緻な評価を可能にし、RAGシステムの性能をより正確に評価します。

導入方法例

導入方法はGitHubに記載されています。

1. 環境設定

RAGCheckerをセットアップするために、まずPython環境を準備し、必要なライブラリをインストールします。

  • pipによるインストール:

pip install ragchecker
python -m spacy download en_core_web_sm

2. データフォーマット

RAGCheckerのチェッキングパイプラインを実行するには、データを特定のフォーマットに従って準備します。以下は、examples/checking_inputs.jsonの形式です。

  • フォーマット例:

{
  "results": [
    {
      "query_id": "<query id>",
      "query": "<input query>",
      "gt_answer": "<ground truth answer>",
      "response": "<response generated by the RAG generator>",
      "retrieved_context": [
        {
          "doc_id": "<doc id>",
          "text": "<content of the chunk>"
        }
      ]
    }
  ]
}

3. CLIでのパイプライン実行

以下のコマンドを使用して、チェッキングパイプラインを実行し、出力結果と中間結果を保存します。

  • コマンド例:

ragchecker-cli \
  --input_path=examples/checking_inputs.json \
  --output_path=examples/checking_outputs.json \
  --extractor_name=bedrock/meta.llama3-70b-instruct-v1:0 \
  --checker_name=bedrock/meta.llama3-70b-instruct-v1:0 \
  --batch_size_extractor=64 \
  --batch_size_checker=64 \
  --metrics all_metrics

4. Pythonでの実行

Pythonスクリプト内でRAGCheckerを実行することも可能です。

  • コード例:

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

# JSONからRAGResultsを初期化
with open("examples/checking_inputs.json") as fp:
    rag_results = RAGResults.from_json(fp.read())

# 評価器のセットアップ
evaluator = RAGChecker(
    extractor_name="bedrock/meta.llama3-70b-instruct-v1:0",
    checker_name="bedrock/meta.llama3-70b-instruct-v1:0",
    batch_size_extractor=32,
    batch_size_checker=32
)

# 評価の実行
evaluator.evaluate(rag_results, all_metrics)
print(rag_results)

5. 結果の出力

評価結果は、overall_metrics、retriever_metrics、generator_metricsに分類され、次のように出力されます。

  • 出力例:

{
  "overall_metrics": {
    "precision": 73.3,
    "recall": 62.5,
    "f1": 67.3
  },
  "retriever_metrics": {
    "claim_recall": 61.4,
    "context_precision": 87.5
  },
  "generator_metrics": {
    "context_utilization": 87.5,
    "noise_sensitivity_in_relevant": 22.5,
    "noise_sensitivity_in_irrelevant": 0.0,
    "hallucination": 4.2,
    "self_knowledge": 25.0,
    "faithfulness": 70.8
  }
}

6. LlamaIndexとの連携

RAGCheckerはLlamaIndexと統合されており、LlamaIndexを使用するRAGアプリケーションに対して、包括的な評価ツールを提供します。詳細な使用方法については、LlamaIndexのドキュメントを参照してください。

評価方法と計測項目の定義

1. 全体的な評価指標

Precision（精度）

  • 定義: 生成された応答の中で、正しいクレーム（正解応答と一致するクレーム）の割合を評価します。Precisionは、RAGシステムがどれだけ正確に情報を生成しているかを評価するための指標です。高いPrecisionは、生成されたクレームの多くが正しい情報に基づいていることを示します。

  • 計算式:

Recall（再現率）

  • 定義: 正解応答の中で、生成されたクレームの割合を評価します。Recallは、システムがどれだけ完全に正解情報を再現できているかを評価する指標であり、システムのカバレッジを評価する際に重要です。

  • 計算式:

F1スコア

  • 定義: PrecisionとRecallの調和平均を測定します。F1スコアは、PrecisionとRecallのバランスを取る指標であり、一方に偏ることなくシステム全体の性能を評価するために使われます。

  • 計算式:

2. リトリーバーの評価指標

Claim Recall（クレームリコール）

  • 定義: リトリーバーが返したチャンクの中で、正解応答に含まれるクレームがどれだけカバーされているかを測定します。Claim Recallは、リトリーバーがどれだけ多くの正確な情報を引き出せたかを評価する指標です。高い値は、リトリーバーが適切な情報を選択していることを示します。

  • 計算式:

Context Precision（コンテキスト精度）

  • 定義: リトリーバーが返したチャンクの中で、正解クレームを含むチャンクの割合を評価します。Context Precisionは、リトリーバーがどれだけ関連性の高い情報を返したかを評価します。高い値は、リトリーバーが正確な情報を抽出できていることを示します。

  • 計算式:

3. ジェネレーターの評価指標

Faithfulness（忠実度）

  • 定義: ジェネレーターが生成したクレームが、リトリーバーから返されたチャンクにどれだけ忠実であるかを評価します。Faithfulnessは、ジェネレーターが正確な情報に基づいて応答を生成しているかを評価する指標です。高い値は、誤った情報の生成が少ないことを示します。

  • 計算式:

Relevant Noise Sensitivity（関連ノイズ感度）

  • 定義: 正しい情報を含むチャンクに混じったノイズに対する感度を評価します。この指標は、ジェネレーターがノイズ（不要な情報）に影響される度合いを評価します。低い値は、ジェネレーターがノイズに対して耐性があることを示します。

  • 計算式: ​

Irrelevant Noise Sensitivity（無関係ノイズ感度）

  • 定義: 無関係なチャンクに含まれるノイズに対する感度を評価します。この指標は、無関係な情報に影響されやすいかどうかを評価し、システムの堅牢性を測定するのに役立ちます。低い値は、無関係な情報に影響されにくいことを示します。

  • 計算式:

Hallucination（ハルシネーション）

  • 定義: ジェネレーターが、リトリーバーから返されていない情報に基づいて生成した誤りの割合を評価します。Hallucinationは、ジェネレーターが自ら生成する誤ったクレームの頻度を測定し、モデルの信頼性を評価する指標です。低い値は、誤った情報の生成が少ないことを示します。

  • 計算式:

Self-knowledge（自己知識）

  • 定義: ジェネレーターが自身の知識に基づいて生成した正しいクレームの割合を評価します。Self-knowledgeは、ジェネレーターがリトリーバーからの情報に依存せず、自身のトレーニングデータに基づいて正確な応答を生成できる能力を評価する指標です。高い値は、ジェネレーターが信頼性のある自己知識を持ち、それを適切に活用できていることを示します。

  • 計算式:

Context Utilization（コンテキスト利用率）

  • 定義: ジェネレーターが取り出されたコンテキスト情報をどれだけ効果的に利用しているかを評価します。Context Utilizationは、ジェネレーターがリトリーバーからの情報を適切に活用し、正確なクレームを生成する能力を評価する指標です。高い値は、リトリーバーから取得した情報を正確に反映した応答が生成されていることを示します。

  • 計算式:

本論文での実験結果の分析

本研究では、BM25とE5-Mistralという2つのリトリーバー、およびGPT-4、Mixtral-8x7B、Llama3-8B、Llama3-70Bという4つのジェネレーターを組み合わせた8つのRAGシステムを対象に、4162件のクエリを10分野にわたり評価しました。

1. リトリーバーの影響

E5-MistralはBM25よりも優れたリトリーバー性能を示し、クレームリコール（Claim Recall）がBM25の67.2%に対し、E5-Mistralでは83.5%に達しました。この大幅な改善は、E5-Mistralがより多くの関連情報を正確に取得できることを示しており、F1スコアもBM25システムの平均42.7%に対して、E5-Mistralシステムでは53.0%へと向上しました 。
これは、より強力なリトリーバー（例: E5-Mistral）を使用することが、クレームリコールを向上させ、F1スコアを改善する有効な手段であることを示唆します。

2. ジェネレーターの影響

ジェネレーターのサイズが性能に直接影響しました。特にLlama3-70Bは、コンテキスト利用率が57.6%と最も高く、Llama3-8Bの54.9%を上回りました。さらに、Llama3-70Bのハルシネーション率は6.8%に低下し、Llama3-8Bの8.3%よりも改善されました 。大規模ジェネレーターは、正確なコンテキストの利用とハルシネーションの減少に貢献することが確認されました。

3. コンテキスト利用の重要性

コンテキスト利用率は全体的なF1スコアと強く相関し、コンテキスト利用率が1%向上するごとにF1スコアが0.9ポイント向上することが観察されました。このことは、リトリーバーから得られたコンテキスト情報の質がシステム全体の性能に与える影響を示しています。
これはつまり、より多くのコンテキスト情報を提供することで、ジェネレーターの忠実度を向上させ、ハルシネーションを減少させるということになります。k値やチャンクサイズを増やすことで、リコールやF1スコアの改善が期待されますが、ノイズ感度が上昇する可能性があります​。

4. 信頼性とハルシネーションの削減

E5-Mistralを使用することで、忠実度（Faithfulness）はBM25システムの88.1%からE5-Mistralシステムの93.7%に向上し、ハルシネーション率もE5-Mistralシステムで1.5%低下しました 。これにより、リトリーバーの精度がジェネレーターの信頼性を向上させることが確認されました。

5. ノイズに対する感度のトレードオフ

リトリーバーのクレームリコールが向上すると、ジェネレーターのノイズ感度もBM25システムの28.5%からE5-Mistralシステムでは31.7%に増加しました 。クレームリコールが向上するにつれて、ノイズ感度も増加します。リトリーバーが関連する情報とノイズを一緒に取得するため、ジェネレーターはノイズへの感度が高くなります。ノイズ感度を軽減するには、適切なコンテキスト処理が必要です。

6. オープンソースモデルの課題

GPT-4は、コンテキスト利用率が62.3%、ノイズ感度が27.1%であり、他のオープンソースモデルに比べて優れたパフォーマンスを示しました 。オープンソースモデルはコンテキストを盲信する傾向があり、ノイズの識別が難しいことが課題として残っています。

最後に

最後までお読みいただき、ありがとうございます！

​弊社では、LLM（大規模言語モデル）やアーキテクチャの選定、技術検証、生成AIを使用したプロトタイピングやシステム開発、お客様社内での啓蒙活動等を対応させていただく「生成AIコンサルティング」サービスを提供しています。

また、業務利用できるChatGPTのような仕組みである「セキュアGAI」や、生成AIとOCRを組み合わせた「AI文書読み取りサービス」といったAIソリューションも提供しています。

ぜひお気軽にお問い合わせください！

いいなと思ったら応援しよう！