RAGの精度改善が止まる原因は、評価を「正答率」1本で見てしまうことです。2026年の実務では、評価データセットを先に設計し、取得品質と回答品質を分けて追う運用が成果を分けます。
なぜ正答率だけではRAGの失敗を見逃すのか？
LangSmithのRAG評価チュートリアルでは、評価を「質問と期待回答を持つデータセット」「実行結果」「評価指標」の3段階で扱います。ここで重要なのは、見るべき項目が answer relevance、answer accuracy、retrieval quality に分かれている点です。つまり、誤答でも原因は1つではなく、検索失敗・文脈不足・生成失敗を切り分ける必要があります。
正答率だけを週次KPIにすると、たまたま答えられたケースで数値が良く見え、検索の抜け漏れが放置されます。特に社内ナレッジ検索やFAQでは、「答えは合っているが根拠文書がズレている」状態が本番事故の入口になりやすいので、取得結果の妥当性を別指標で持つ設計が安全です。
→ RAG評価設計や社内AI導入を短期間で整えたい方はご相談ください
評価データセットは何問・どんな粒度で作るべきか？
OpenAIのEvalsガイドは、評価を作るときに data_source_config で入力項目と正解ラベルを定義し、testing_criteria で判定ルールを分ける流れを示しています。最初の運用では、1ユースケースにつき30〜50問を目安に、質問、期待回答、参照すべき文書ID、難易度、業務部門を持たせると改善ポイントが見えやすくなります。
LangSmithのデータセット管理ドキュメントでも、examples に inputs、outputs、metadata を持たせて一括登録する形が推奨されています。Ragasも、理想的なテストデータセットの条件として「高品質」「実世界の幅広いシナリオ」「統計的に意味のある件数」「継続更新」を挙げています。FAQだけでなく、長文規程、表を含む文書、答えが存在しない質問も混ぜるのが実務向きです。
正答率以外に追うべき3つの運用指標は？
1つ目は取得適合率です。上位3件の検索結果に正解根拠が何件入ったかを見るだけで、チャンク分割や埋め込みの問題を早く見つけられます。2つ目は回答根拠率で、生成した回答の各主張が取得文書で裏付けられている割合を確認します。3つ目は未回答許容率で、答えがない質問に対して無理に生成せず「不明」と返せた比率を追います。
この3指標を見れば、正答率が同じ80%でも改善の打ち手が変わります。取得適合率が低いならインデックス設計、回答根拠率が低いならプロンプト、未回答許容率が低いならガードレールを優先すべきです。数字を分けるだけで、週次レビューが「精度が悪い」から「どこを直すか」へ変わります。
運用で崩れない評価テンプレートはどう作る？
実務では、①業務シナリオを5分類する、②各分類で6〜10問ずつ作る、③質問ごとに期待回答・根拠文書・禁止事項を書く、④毎週5問だけ差し替える、というテンプレートが回しやすいです。これなら初回でも30〜50問で開始でき、モデル変更や文書更新の影響も追跡できます。評価シートはスプレッドシートでも良いですが、最終的にはコード管理できるJSONLやデータセット管理基盤へ寄せると再現性が上がります。
→ 評価テンプレートの整備、RAG改善の伴走、AI研修のご相談はこちら
よくある質問：自動生成データだけで十分ですか？
十分ではありません。Ragasのような生成系ツールは初期セットを素早く作るのに便利ですが、実運用で詰まるのは固有名詞の表記揺れ、部署ごとの略語、更新された規程への追随です。最初は合成データで土台を作り、その後に実際の問い合わせログや検索失敗ログを混ぜる運用が、2026年時点でもっとも堅実です。
RAG評価は「点数を出す作業」ではなく、改善順序を決める仕組みです。正答率だけで悩むより、データセット設計、取得品質、回答根拠率の3層に分けて管理したほうが、短いスプリントでも精度が上がります。
