RAG入門：AIに知識を与える技術

RAGの評価と継続的な改善サイクル

生田 陸人
監修
LuaGate エンジニア / 現役エンジニア
編集 LuaGate編集部

このレッスンで分かること

  • この記事では「RAGの評価と継続的な改善サイクル」を RAG 実装 の現場で使える形で整理します
  • RAG評価の重要性と精度の定義 → なぜ改善サイクルが必要なのか？ をおさえれば、現場で迷ったときに立ち戻れる
  • RAG評価の主要フレームワーク → RAGASとRAGトライアド をおさえれば、現場で迷ったときに立ち戻れる
  • LLM-as-a-judge（評価者としてのLLM） をおさえれば、現場で迷ったときに立ち戻れる
  • 改善サイクルの回し方 → データ収集からパラメータ調整まで をおさえれば、現場で迷ったときに立ち戻れる

RAGの評価と継続的な改善サイクル とは

RAG（検索拡張生成）の精度を維持・向上させるための評価手法と改善サイクルを学びます。RAGASなどのフレームワークを用いた自動評価や、ユーザーフィードバックを活用した品質管理の具体例を詳しく解説します。

RAG評価の重要性と「精度」の定義 → なぜ改善サイクルが必要なのか？

RAG（検索拡張生成）システムを構築し、プロトタイプが動くようになると、次に直面するのが「この回答は本当に正しいのか？」という問いです。RAGは外部知識を参照するため、単純なLLMよりも正確な回答が期待されますが、実際には「参照データを見つけられない」「見つけたデータが間違っている」「回答がデータに基づかない（ハルシネーション）」といった課題が頻繁に発生します。

RAGを業務で実用化するためには、一度作って終わりではなく、常に精度を測定し、継続的な改善サイクルを回し続けることが不可欠です。本レッスンでは、RAGの精度をどのように定義し、どのような指標で評価し、具体的にどう改善していくべきかを詳しく解説します。

RAGの精度は「検索」と「生成」のどちらが原因で落ちているかを切り分けることが先決です。原因を特定しないまま全体を触ると、別の指標を壊して堂々巡りになります。

まず、RAGの精度は大きく分けて2つのフェーズで考える必要があります。

  1. 検索フェーズの精度（Retrieval Accuracy） → ユーザーの質問に対して、適切な知識ソースを正しく検索できているか。
  2. 生成フェーズの精度（Generation Accuracy） → 検索した知識をもとに、ユーザーの質問に対して正確で自然な回答を生成できているか。

これらを切り分けて評価することで、システムが抱える「弱点」がどこにあるのかを明確に特定できるようになります。

RAG評価の主要フレームワーク → RAGASとRAGトライアド

人間がすべての回答を目視でチェックするのは、膨大なコストがかかります。そこで、LLM自身にRAGの精度を評価させる手法や、フレームワークが活用されています。特に有名なのが「RAGAS (RAG Assessment)」と、TruLensなどが提唱する「RAGトライアド (RAG Triad)」です。

RAGトライアドでは、以下の3つの関係性を評価します。

指標名評価する内容目的
Context Relevance質問に対して、検索されたコンテキスト（知識）が適切か検索アルゴリズムの評価
Groundedness / Faithfulness回答が、提供されたコンテキストに完全に基づいているかハルシネーションの検知
Answer Relevance回答が、ユーザーの元の質問に直接答えているか生成品質の評価
diagram (will load when visible)

これらの指標を用いることで、「検索はうまくいっているが、生成で嘘をついている」といったボトルネックが可視化されます。特に Faithfulness（忠実性） は、企業利用において最も重要な指標の一つです。たとえ流暢な日本語であっても、社内ドキュメントに記載されていない嘘を答えてしまっては、RAGを導入する意味がなくなってしまうからです。

LLM-as-a-judge（評価者としてのLLM）

最近では、GPT-4などの高性能なモデルを「評価者」として使い、各指標を1.0〜5.0などのスコアで自動算出させる手法が一般的です。これにより、開発中のコード変更が精度に与えた影響を、数分で数値化することが可能になります。

改善サイクルの回し方 → データ収集からパラメータ調整まで

評価の仕組みが整ったら、次は具体的な改善サイクルを構築します。RAGの精度を向上させるためには、場当たり的な修正ではなく、以下のフローを繰り返すことが重要です。

改善サイクルの起点はゴールデンセットです。再現可能なテストデータがあって初めて「直った/壊れた」を客観的に判断できます。先にPDCAの計測軸を整えましょう。

diagram (will load when visible)

1. 評価用データセット（ゴールデンセット）の作成

まず、正解がわかっている「質問・回答・参照ドキュメント」のセットを50〜100件程度作成します。これをゴールデンセットと呼びます。システムのコードを変更した際、このセットに対してテストを実行することで、精度が向上したのか、あるいは他の回答を壊してしまったのか（デグレ）を客観的に判断できます。

2. ユーザーフィードバックの収集

運用開始後は、ユーザーからのフィードバックをログとして蓄積します。ここで重要なのは、「良かった・悪かった」の2択だけでなく、なぜ悪かったのかを分析できる仕組みにすることです。

避けたい例 悪い評価の集め方

  • 「この回答はどうでしたか？」というボタンだけを置く。
  • どこが間違っているのかを記述する欄がない。
  • ユーザーが「役に立たなかった」と押しても、検索が悪かったのか生成が悪かったのか区別がつかない。

良い例 良い評価の集め方

  • /ボタンに加え、「内容が不正確」「情報が古い」「回答が長すぎる」などの選択肢を用意する。
  • どのドキュメントを参考にしたか（引用元）を表示し、そのドキュメントが適切だったかをユーザーが判定できるようにする。
  • ユーザーからの指摘内容をそのままゴールデンセットに反映させるフローを作る。

実践！RAGの精度を高める具体的な改善手法

評価の結果、精度が低いことが判明した場合、具体的にどこを修正すべきでしょうか。【代表的な改善ポイント】をいくつか挙げます。

検索精度の改善（Context Relevanceの向上）

  • チャンク分割の最適化は文章をぶつ切りにするのではなく、意味の区切り（段落ごとなど）で分割するように調整します。
  • メタデータフィルタリングは文書の種類や日付で検索範囲を絞り込むことで、ノイズを減らします。
  • ハイブリッド検索の導入はベクトル検索（意味の近さ）だけでなく、キーワード検索（用語の一致）を組み合わせることで、専門用語や固有名詞への対応力を高めます。

生成精度の改善（Faithfulness / Answer Relevanceの向上）

  • プロンプトエンジニアリングは「必ず提供されたコンテキストのみに基づいて回答してください」「わからない場合は正直にわからないと答えてください」といった制約を強化します。
  • Few-shotプロンプティングは回答の好ましい例をいくつかプロンプトに含めることで、出力形式やトーンを安定させます。

やってみよう 自社のRAGシステムで「回答がいつも簡潔すぎて、詳細な手順を教えてくれない」という課題が見つかりました。あなたなら、どの指標（トライアド）に注目し、どのような改善策を試みますか？

まとめ → 評価は終わりのない旅

RAGの精度管理は、一度構築して終わりではありません。扱うドキュメントの変化や、ユーザーのニーズの変化に合わせて、継続的にサイクルを回していく必要があります。まずは、評価指標の可視化から始め、小さな改善を積み重ねていきましょう。確実な評価に基づく改善こそが、ユーザーに信頼されるAIシステムへの唯一の道です。

「完璧な回答」を最初から目指すのではなく、まずは「どこが悪いか」を数値化できる体制を作りましょう。改善のプロセスそのものが、自社のドキュメント資産をより深く理解することにもつながりますよ！頑張りましょう！

現場でよくある具体例

  1. 業務ケース 1 — 社内規程 200 ページに RAG を導入。チャンクサイズ 512、top-k=5、Re-ranker 有りで Recall@5 が 0.62 → 0.81
  2. 業務ケース 2 — エンジニア向け技術文書では「コードブロックを 1 チャンク」にしたら検索精度が大きく改善
  3. 業務ケース 3 — 営業 FAQ では BM25 + Embedding の Hybrid Retrieval で、固有名詞検索の取りこぼしが減った

次にとるべきアクション

  1. 手元の社内 PDF / FAQ 10 件で RAG ミニ版を作る — LangChain か LlamaIndex で構築し、「RAGの評価と継続的な改善サイクル」の論点を試す
  2. チャンクサイズと検索件数を 2 通り試す — 256 / 512 トークン × top-k=3 / 5 など、定量比較する
  3. 評価指標を 1 つ決める — Recall@k / 回答正答率 / コストのいずれかをチームで KPI 化する

次のレッスン

次は 第4章まとめクイズ で、第4章まとめクイズ を学びます。

事前確認 — 進む前に次の 3 つができることを確認しましょう。

  1. RAG評価と改善 の要点を自分の言葉で説明できる
  2. このレッスンの最小コード (または操作手順) を見ずに書ける
  3. 練習問題やクイズで間違えた箇所を読み直して理解した

理解度チェック (30 秒)

Q. RAG評価と改善 とは何か、1 文で説明してください。

この章のポイント

A. 本文の「このレッスンで分かること」または冒頭の説明文を見直し、自分の言葉で要約できれば OK。詰まったら本レッスンの最初の H2 セクションを読み返してみましょう。

関連レッスン

参考にした出典

学習を加速したい方へ

RAG (検索拡張生成) 入門ガイドを体系的にマスターするなら、chotdekiru の無料学習ポータル で実際に手を動かして学習を始めるのがおすすめです。質問・つまずきも現役エンジニアが伴走します。

復習ミニクイズ

RAGシステムの評価において、「回答はユーザーの質問に対して自然で的確に答えているように見えるが、実際には参照したドキュメントには書かれていない架空の情報（ハルシネーション）が含まれていた」という状況が発生しました。この場合、RAGトライアドのどの指標を最も優先的に確認し、改善すべきですか？

参考リンク