Nullstead

AI

2026年版 RAG評価実践ガイド：それっぽい正解を卒業する個人開発Evals設計

RAGの品質を安定させるには、検索と生成を分離して評価する設計が不可欠です。2025〜2026年の最新情報をもとに、個人開発でも回せる評価データセット設計、主要メトリクス、CI導入、運用監視まで実践的に解説します。

約9分

2026年版 RAG評価実践ガイド："それっぽい正解"を卒業する個人開発のEvals設計

RAG（Retrieval-Augmented Generation）※検索拡張生成を作り始めると、最初はだいたい同じ壁にぶつかります。デモでは賢く見えるのに、本番で急に「惜しいけど違う」回答を出す問題です。私も最初は「モデルを強くすれば解決するはず」と思っていましたが、現実はそんなに甘くありませんでした。CPUファンの回転数だけが元気になり、私の心は静かに折れます。

この記事では、2025〜2026年時点の公開情報（OpenAI Cookbook、LangSmith、Ragas、LlamaIndex、NISTなど）を踏まえて、個人開発で回せるRAG評価（Evals）の設計をまとめます。ポイントはシンプルで、検索品質と回答品質を分離して測ること、そしてオフライン評価とオンライン監視をつなぐことです。

「雰囲気でRAGを運用する時代」に卒業証書を渡すつもりで書きます。はい、今日で“勘運用学部”は閉講です。

なぜRAG評価が難しいのか：1つの点数では事故るからです

RAGの失敗は大きく3系統あります。

  1. 取りに行く情報がズレる（Retrieval失敗）
  2. 取れたのに答え方がズレる（Generation失敗）
  3. 正しい情報を持っているのに説明が不親切（UX失敗）

ここで厄介なのは、最終回答の正誤だけ見ても原因が分からないことです。たとえば「回答が間違い」でも、原因が検索・プロンプト・モデル設定・コンテキスト長のどこにあるかが混ざります。

このため最近の実践ガイドは、だいたい次の分離を推します。

  • Retrieval系メトリクス（Context Precision / Recall など）
  • Generation系メトリクス（Faithfulness / Relevance / Correctness など）

Ragasのドキュメントでも、文脈取得の質と応答の整合性を別々に測る思想が明確です。LangSmithやPhoenix系の解説も、同じく「何が悪いかを切り分けるために分離評価する」としています。

要するに、RAG評価は総合点テストではなく、内申点テストです。体育（検索）と数学（生成）を同じ1科目にすると、進路相談が地獄になります。

まず作るべきは「評価データセット」：小さく、偏らず、再利用可能に

評価を始めるとき、いきなり1000件の正解データを作る必要はありません。個人開発なら、まずは30〜80問の小さなセットで十分です。重要なのは件数より、失敗パターンを含める設計です。

最低限入れておきたい問題タイプ

  • 事実照会（定義、仕様、数値）
  • 手順説明（ステップ形式）
  • 比較質問（AとBの違い）
  • 制約付き質問（「2025年以降のみ」「日本語情報のみ」など）
  • ノイズ耐性（紛らわしい語句を含む）

LangSmithのRAGチュートリアルでも、質問と参照回答（reference answer）を持つデータセットを先に作る流れが採られています。ここがないと改善比較ができません。改善したつもりで劣化していた、という悲しい出来事を防ぐには、固定データセットが必須です。

データセット作成時の実務メモ

  • 1問1意図（複合質問を避ける）
  • 参照回答は短く、判定可能な形で
  • 情報源のバージョン日付をメモする
  • 半年後に陳腐化する質問を混ぜすぎない

「評価用データを作る時間がない」は、よく分かります。私も何度も言いました。ただ、そのツケは必ず本番障害で返ってきます。未来の自分への分割払いは、利息が高いです。

主要メトリクスの使い分け：Faithfulnessだけでは足りません

RAG評価でよく使われる指標を、現場目線で整理します。

Retrieval側

  • Context Precision：取得した文脈のうち、実際に役立つものの割合
  • Context Recall：必要な情報を取り逃していないか

Precisionが低いと、関係ない文書を大量に渡してモデルを混乱させます。Recallが低いと、そもそも答える材料が足りません。検索器のk値やリランキング設定を調整する際は、この2つを見ると効果が分かりやすいです。

Generation側

  • Faithfulness：回答が取得文脈に忠実か（幻覚を抑えられているか）
  • Answer Relevance：質問に対して的外れでないか
  • Correctness / Accuracy：最終的に正しいか

OpenAI CookbookのRAG評価例でも、FaithfulnessとRelevancyを使った分解が紹介されています。Faithfulnessが高いのにCorrectnessが低いケースは、しばしば「間違った文脈を忠実に要約した」状態です。モデルは真面目、でも資料が違う。真面目なミスほど直しにくい、あの感じです。

しきい値設計のコツ

  • いきなり厳格運用しない（初期は傾向把握）
  • リリースゲートは2〜3指標のAND条件で管理
  • 失敗サンプルを毎週10件レビュー

単一スコアで合否を切ると、Goodhartの法則※「指標が目標になると指標が壊れる」が発動しやすいです。スコア最適化だけ進んで、体験が悪化します。

LLM-as-a-Judge運用：便利ですが、判定者にも監査が必要です

LLM-as-a-Judge※別のLLMに回答品質を採点させる手法は、速度と規模で強力です。人手評価だけでは追いつかない個人開発には特に有効です。

ただし万能ではありません。判定LLMは次のバイアスを持ちます。

  • 冗長な文章を高評価しやすい
  • もっともらしい言い回しに弱い
  • 採点プロンプトに引っ張られる

そのため、人手評価との定期キャリブレーションが必要です。実務では「毎週ランダム20件を人が再採点し、乖離率を監視」する運用が現実的でした。

以下は、採点基準を明示する最小プロンプト例です（動作未検証。方針例として掲載）。

あなたはRAG回答の評価者です。
次の観点を0〜1で採点してください。
1) faithfulness: 回答は提供コンテキストに反しないか
2) relevance: 回答は質問意図に沿っているか
3) completeness: 必要な要点を欠いていないか
出力はJSONのみ: {"faithfulness":...,"relevance":...,"completeness":...,"reason":"..."}

「評価を自動化するために、評価の評価をする」構造はやや哲学的ですが、運用上は普通です。CIがテストを実行し、テストも定期点検するのと同じです。

実装テンプレート：CIで回す最小Evalsパイプライン

ここでは、日次で評価を回す最小構成を示します。LangSmithでも自前でも、考え方は同じです。

# 1) 評価データセットを読み込む
python scripts/load_eval_dataset.py --path evals/rag_eval_set.jsonl

# 2) 現行ブランチのRAGチェーンで推論
python scripts/run_rag_eval.py \
  --dataset evals/rag_eval_set.jsonl \
  --output artifacts/eval_results.jsonl

# 3) メトリクス集計
python scripts/aggregate_metrics.py \
  --input artifacts/eval_results.jsonl \
  --out artifacts/metrics.json

# 4) しきい値チェック（FailならCI停止）
python scripts/check_gate.py \
  --metrics artifacts/metrics.json \
  --min-faithfulness 0.90 \
  --min-context-precision 0.75 \
  --min-answer-relevance 0.85

加えて、GitHub Actions等でPRごとに差分比較を出すと便利です。

  • baseline（main） vs candidate（PR）
  • 指標差分（+/-）
  • ワースト劣化サンプル上位10件

この「悪化サンプルを自動で並べる」だけでレビュー効率が跳ねます。人は平均との差分より、具体例に強い生き物です。私もそうです。スプレッドシートの平均値を見ると、なぜか急に眠くなります。

オンライン監視とリスク管理：NISTの視点を足すと事故が減る

オフライン評価で合格しても、本番ではデータ分布が変わります。そこで必要なのがオンライン監視です。

最低限、次を観測してください。

  • 参照文書の取得率（0件回答の割合）
  • 回答拒否率（答えられませんの増加）
  • 引用付き回答率（根拠提示の有無）
  • ユーザー再質問率（1回で解決しない割合）

NIST AI RMF（Generative AI Profile）でも、生成AI運用は「測定して管理する」継続プロセスとして扱われています。RAGは特に、データソース更新・検索設定変更・モデル更新のどれでも品質が動くため、評価はイベントではなく習慣です。

実務では、以下の運用が安定しやすいです。

  • 日次：自動Evals（小セット）
  • 週次：人手監査（失敗例レビュー）
  • 月次：データセット更新（陳腐化対策）

「毎日筋トレは無理でも、毎週ストレッチはできる」設計にすると続きます。評価は継続こそ正義です。

2026年の現実解：個人開発ならこの順番で進めるのが堅いです

最後に、私が今の時点でおすすめする導入順をまとめます。

  1. まず30〜80問の評価セットを作る
  2. Retrieval/Generationを分離して計測する
  3. Faithfulnessだけでなく、Context Precision/Recallも見る
  4. LLM-as-a-Judgeを導入し、人手で定期校正する
  5. CIゲート＋本番監視を接続する

この順番なら、過剰設計になりにくく、個人開発でも維持できます。

RAGの品質改善は、派手な新モデル投入よりも、地味な評価基盤の整備が効く場面が多いです。ここは夢のない話ですが、現場の勝ち筋はだいたい地味です。派手さは登壇資料に任せて、運用は堅実にいきましょう。

参考リンク

Tags #AI #RAG #Evals #LLM #個人開発 #自動化
← 記事一覧に戻る ページの先頭へ ↑