StartSpace Tech BlogPublicationへの投稿
🙄

RAGが伸びない本当の原因は評価にある | RAGASで作る改善サイクル

StartSpace代表｜AI・フルスタックエンジニア
に公開
評価
RAG
Langfuse
Ragas
LLMOps
tech

はじめに：RAGが伸びない現場の共通点

近年、多くの企業がRAG（Retrieval-Augmented Generation）を活用した様々なAIシステムのPoC → 本番化を進めています。

しかし、その中で必ずと言っていいほど耳にするのが、
「初期版は作れたが、そこから精度が伸びない」
という悩みです。

実務では次のような切り分けが非常に難しくなります。

  • チャンクの切り方が悪いのか？
  • 埋め込みモデルの性能不足なのか？
  • ドキュメントの前処理に問題があるのか？
  • そもそも検索結果が質問に合っていないのか？

多くの現場ではこれらが複合的に絡み合い
「何を改善すれば精度が伸びるのか分からない」状態に陥ります。

この問題こそが、RAG開発の本質的な難しさであり、評価の重要性が急速に高まっている理由です。

そしてこの改善の問題を解消するために登場したのが、
本記事で扱うRAG専用の評価フレームワーク「RAGAS」です。

なぜRAGは評価が難しいのか

RAGを「評価する」と一言で言っても、その対象は一つではありません。
RAGのパイプラインには複数のステップがあり、それぞれに別の評価軸が存在します。

例えば、以下のように評価すべき観点は大きく4つに分かれます。

  1. 検索の適切性（Retrieval）
  • 関連するドキュメントが引けているか
  • 重要な情報が抜け落ちていないか
  1. コンテキストの妥当性（Context Quality）
  • チャンクの切り方は適切か
  • ノイズや余計な情報は混ざっていないか
  1. 回答の忠実性（Faithfulness）
  • 引いたドキュメントに基づいて回答しているか
  • ハルシネーションが混ざっていないか
  1. 回答の有用性（Answer Relevance/ Correctness）
  • 質問に対する答えになっているか
  • ユーザーにとって意味のある回答か

実務ではこれらが複雑に絡み合うため、どこが悪いのかを切り分けるのが非常に困難になります。

さらに評価を人手で行おうとすると、

  • 100件以上のQAを人が目視で判断する必要がある。
  • 同じ回答でも、人によって「良い」「悪い」の判断が分かれる
  • 評価基準が属人化し、改善の指針にならない
    と言った問題が生じます。

結果として多くの現場では、
「精度が低いことは分かるのに、どこを直していけばいいのかわからない」
という状態に陥るのです。

RAGASとは何か | RAG専用の評価フレームワーク

RAGASはRAGの品質を定量的に評価できるフレームワーク

  • 評価の属人性を排除し、客観的な指標でRAGを評価できる
  • Retrieval/ Context/ Faithfulness/ Answer Qualityなど、RAGの指標が揃っている

人手では難しいRAG評価を自動化できる

  • 100件規模のQAでも自動でスコアリングできる
  • 人間による判断のブレが存在しない
  • 定期的に評価する運用を組み込める

なぜRAGASが必要なのか

  • RAG評価は「どこが悪いか」が見えにくい
  • RAGASはRAGの各工程毎に点数を出せる

指標の簡単な例

  • Retrieval・・・関連文書が取得できているか
  • Context・・・チャンクが適切か
  • Faithfulness・・・回答が文書に忠実か
  • Answer Relevance・・・質問に答えているか

フレームワークとの統合

RAGASは既存のLLMアプリケーションの開発フレームワークとも統合しやすいのが特徴。

  • LangChainやLlamaIndexと簡単に連携できる

RAGASで評価できる主要メトリクス

Context Precision

Context Precisionは、RAGパイプラインが取得したコンテキストの中に、質問に本当に必要な情報がどれだけ含まれているか(不要な情報がどれだけ混ざっていないか)を示す指標です。

低い場合

  • 取得したチャンクにノイズが多い
  • 回答に関係のない文言が混ざっている
  • 前処理/ チャンク設計の見直しが必要

Context Recall

Context Recallは、RAGパイプラインが取得したコンテキストが、質問に答えるために必要な情報をどれだけ取り漏らさずに取得できているかを示す指標です。

低い場合

  • 必要文書が取得できていない
  • チャンク分割により、重要な情報が分断されてしまっている
  • 検索クエリ生成や埋め込みモデルの見直しが必要

Context Entities Recall

Context Entities Recallは、質問に含まれる重要な固有情報（エンティティ）が、RAGパイプラインが取得したコンテキストの中にどれだけ漏れなく含まれているかを測る指標です。

低い場合

  • 検索で重要なエンティティを部分的にしか取得できていない
  • チャンク分割によってエンティティが別チャンクに分断されてしまっている

Noise Sensitivity

Noise Sensitivityは、RAGパイプラインが取得したコンテキストに意図的にノイズ（不要情報）を　混ぜた時、回答品質がどれだけ影響を受けるかを測る指標です。

低い場合

  • 取得したコンテキストが比較的クリーンで、ノイズ混入に強い
  • チャンク設計が適切で、不要情報の影響を受けにくい
  • LLMがノイズに左右されにくい構造（指示やプロンプト含む）になっている

Response Relevancy

Response Relevancyは、生成された回答がユーザーの質問にどれだけ適切に答えているかを測る指標です。
※この指標は、質問と回答のみを比較して評価され、取得したコンテキストは使用しません。

低い場合

  • Retrievalの精度不足により必要情報が取得できていない
  • 質問意図の誤解
  • 回答生成プロンプトが弱く、質問と関係ない回答になっている

Faithfulness

Faithfulnessは、生成された回答が、RAGパイプラインが取得したコンテキストの内容にどれだけ忠実に基づいているかを測る指標です。

低い場合

  • LLMがコンテキストにない情報を回答している
  • コンテキスト内の情報が不足している
  • コンテキスト選択が間違っている

RAGASで作る改善サイクルの全体像

  1. 質問・回答・コンテキストのログを集める
    →RAGASを回していくためのログを収集を実施していく
    ※事前に質問・回答・取得コンテキストをすべて紐づけて保存する(Langfuseや自作ログでも可)

  2. RAGASの評価
    →1で取得したデータを元に、上記で記載された各指標毎に評価を実施していく

  3. 何が悪いのか特定
    →2で評価した項目で指標が悪いものの原因を調査する

例)

  • Context Recallが低い → チャンク分断の可能性
  1. 改善(チャンク/検索/埋め込み/プロンプト)
    →3で特定した原因に対して、改善のアプローチを取る

例)

  • チャンク化の調整(構造ベース → ハイブリッドへ)

  1. 再評価して効果を可視化
    →現状の状態が改善されたかどうかを再評価する

  2. RAGの安定
    →評価と改善のループとして機能し、検索精度・回答品質が安定する
    →本番運用で継続的に高品質な回答を維持できる

失敗パターン毎の改善方法がわかるRAGASの最強ポイント

ケース1: Context Recallが低い → 「必要情報を拾えていない」

原因の典型パターン

  • チャンク分割で重要な部分が別チャンクに分断されている
  • 検索(ベクトル検索)が質問の意図を正しく拾えていない
  • 埋め込みモデルの性能不足
  • クエリ生成がうまく機能していない

改善方法

  • チャンクの粒度調整(細かすぎる/粗過ぎる)
  • 埋め込みモデルの変更
  • 検索トップkを調整し、取り漏れを防ぐ
  • 必要に応じてRerankingを導入して順位の最適化を行う

ケース2： Context Precisionが低い → 「関係ない情報が混ざる」

原因の典型パターン

  • チャンクの粒度が粗く、関係ない情報が混ざっている
  • top-kを増やしすぎて、関連度の低いドキュメントまで取得している
  • 埋め込みモデルが質問とコンテキストの類似度を正しく判別できていない

改善方法

  • top-kを減らし、関連性の低いドキュメントの混入を防ぐ
  • 埋め込みモデルをより性能の高いモデルへ変更する
  • ハイブリッド検索等で検索精度を上げる

ケース3： Faithfulnessが低い → 「幻覚 or 文脈外回答」

原因の典型パターン

  • コンテキストに必要な情報が含まれておらず、LLMが補完しようとして事実と異なる回答をしている
  • 必要情報が取得できておらず、誤ったコンテキストが渡されている
  • プロンプトの制約が弱く、LLMが推測で回答してしまう
  • コンテキストの品質が悪い

改善方法

  • コンテキストの品質を上げる
  • Retrievalを改善する
  • プロンプトの強化し、「必ずコンテキストに基づいて回答する」制約を明示する
  • few-shotで適切な回答スタイルと文脈に基づく回答ルールを提示する

ケース4： Response Relevancy

原因の典型パターン

  • 質問の意図をLLMが正しく解釈できていない
  • プロンプトの品質が悪く、質問の焦点がずれてしまう
  • LLMのモデルの性能不足で、意図理解が不十分

改善方法

  • 質問の正規化で意図を明確化する
  • 回答生成プロンプトを強化し、「質問に簡潔かつ直接答える」制約を追加する
  • 必要に応じて、より性能の高いLLMモデルへ変更する

RAGASの実装例

ステップ1: 必要ライブラリのインストール

pip install ragas openai

本記事の実行環境（バージョン）
- Python 3.11.6
- ragas 0.3.9
- openai 2.8.1

ステップ2：事前準備

os.environ["OPENAI_API_KEY"] = "your_openai_api_key"

RAGAS：ContextPrecision

import os
from openai import AsyncOpenAI
from ragas.llms import llm_factory
from ragas.metrics.collections import ContextPrecision

# Setup LLM
client = AsyncOpenAI(api_key=os.environ["OPENAI_API_KEY"])
llm = llm_factory("gpt-4o", client=client)

# Create metric
scorer = ContextPrecision(llm=llm)

# Evaluate
result = await scorer.ascore(
    user_input="RAGにおけるチャンクとは何ですか？",
    reference="チャンクとは、長い文章を検索しやすくするために小さな単位に分割したものです。",
    retrieved_contexts=[
        "チャンクとは、RAGで長い文書を分割するための基本単位であり、検索精度を上げるために利用されます。",
        "フランスのパリにはエッフェル塔があり、多くの観光客が訪れます。"
    ]
)

print(f"Context Precision Score: {result.value}")

# 実行例（参考値）
# Context Precision Score: 0.99

RAG評価を運用に乗せるためのTips

RAGASは単なる評価ツールではなく、RAGシステムの品質を維持するための運用基盤LLMOpsとして活用できます。

RAGは時間と共に劣化するため、運用プロセスに評価を組み込むことが必須です。

ログを集める仕組みが必要

RAGASは「質問・回答・取得コンテキスト」が揃わないと評価できません。
また、RAGは複数工程で構成されるため、これらを紐づけてログ化しないと問題の切り分けができません。

そのために、LangfuseやLangSmithを用いて以下をログに残す必要があります。

  • user_input
  • model_output(回答)
  • retrived_contexts
  • ground_truth(あれば)
  • メタ情報(top-k、モデル名など)
    これらを揃えることで、RAGASが常に正しく評価できる状態になります。

定期評価

商用サービスでは、RAGの品質は時間と共に劣化します。
その為、以下のタイミングで定期的にRAGAS評価を回すことが重要です。

  • 週次などの定期チェック
  • ドキュメント更新時
  • embeddingモデルのバージョン変更時
  • LLMの変更時

閾値設定と自動アラート

CIやLLMOpsパイプラインにRAGASを組み込み、一定の品質スコアを下回る場合にリリースを止めることが可能です。

例)

  • Faithfulness < 0.8 → リリース不可

まとめ

RAGの最大の課題は「どこが悪いのかが分からない」ことです。
RAGASはその問題を解消し、RAG改善の最短ルートを示してくれる羅針盤です。

  • RAGASはRetrieval/ Context/ Faithfulness/ Relevancyを定量化し、改善すべき工程を特定できる。
  • RAGASは、CI/CDやLLMOpsなどと組み合わせることで、本番運用でも品質劣化を防げる。
  • Langfuse・LangSmithなどのログ基盤と併用すれば、評価→改善のサイクルを安定して回せる。

あなたのRAGシステムにも、ぜひRAGASによる評価サイクルを組み込んでみてください。

StartSpace Tech Blog
StartSpace Tech BlogPublication

StartSpace公式アカウントです。 RAG・AIエージェント・マルチモーダルといった分野の研究/開発で得た知見を中心に、 エンジニアが気軽に発信していくためのPublicationです。

Discussion