RAG を組んだあと、精度が上がったかどうかをどうやって確かめていますか。
手元でいくつか質問を投げて「良さそう」と判断するやり方は、見る人によって結論がぶれます。
RAG の評価には、検索の良し悪しと生成の良し悪しを切り離して数値で見るという整理があるのです。
代表的な評価フレームワークの定義に沿って、その基本を並べてみました。
なぜ「体感」だけでは足りないのか
RAG の答えが悪かったとき、原因は大きく二つに分かれます。
ひとつは必要な文書をそもそも引けていない場合で、もうひとつは引けているのに答えがそれを無視している場合です。
前者は検索側の問題、後者は生成側の問題。
体感で「精度が低い」と言うだけだと、この二つが混ざったままになります。
混ざったままチャンクサイズをいじると、直したいのは生成側だったのに検索側を壊す、という遠回りが起きかねません。
評価を検索と生成に分けるのは、どこを直すべきかを先に決めるためでもあるのです。
検索の質は「取りこぼし」と「混ぜ物」で見る
検索側の指標は、代表的なものが二つあります。
ひとつがコンテキストリコール（context recall）で、答えるのに必要な情報が取ってきた文書の中に入っているかを見る指標。
低ければ「そもそも材料が足りていない」という話になり、チャンクの切り方や検索方式の見直しが先になる。
もうひとつがコンテキストプレシジョン（context precision）で、取ってきた文書のうちどれだけが実際に役立つ内容かを見ます。
こちらが低いと、関係のない文書がコンテキストを埋めてしまい、料金も遅延も無駄に増えてしまうのです。
リコールとプレシジョンは片方だけ上げても意味が薄く、取りこぼしと混ぜ物を同時に見るのが基本になります。
検索の並べ替えで後者を改善する話は、リランキングの記事で扱いました。
生成の質は「根拠に忠実か」で見る
生成側でよく使われるのが、忠実性（faithfulness）という考え方です。
これは、出てきた答えが取得済みの文書で裏づけられているかを測るもの。
裏づけのない主張が混ざるほどスコアが下がるので、ハルシネーションの検出に近い役割を持ちます。
もうひとつが応答関連性（response relevancy）で、答えが質問そのものに向き合っているかどうか。
内容は正しいのに質問とずれている、という失敗はここで拾えるわけです。
Ragas の公式ドキュメントでは、RAG 向けの指標としてこの二つに加えて、ノイズ感度やコンテキストエンティティリコールも並んでいます。
検索側で二つ、生成側で二つ、まずはこの四点セットから始めるのが分かりやすいはず。
Ragas 公式ドキュメント（利用できる指標の一覧）
評価を回すときの落とし穴
評価そのものを LLM にやらせる指標が多い、という点は先に知っておきたいところです。
Ragas のドキュメントにも、LLM ベースの指標はスコアを出すために一回以上の LLM 呼び出しを行うと書かれています。
つまり評価にも料金と時間がかかり、評価用モデルを変えると数値も動く。
もうひとつ、スコアの絶対値を追いかけないほうが安全です。
指標の実装やプロンプトが変われば値も変わるので、意味があるのは「同じ物差しで測った変更前と変更後の差」のほうになります。
そして評価用の質問セットは、実際に使われそうな質問に寄せて作るのが要点。
きれいに答えられる質問ばかり並べると、数字は良いのに現場では外すという状態を見逃します。
なお Ragas の論文は、人手の正解データに頼らずに評価する枠組みとして提案されたものです。
Ragas: Automated Evaluation of Retrieval Augmented Generation（arXiv）
最後に
RAG の改善は、まず検索と生成のどちらが足を引っ張っているかを切り分けるところから始まります。
検索側は取りこぼしと混ぜ物、生成側は根拠への忠実さと質問への関連性。
この四つを同じ物差しで測り続けると、チャンクサイズを変えた効果のような小さな差も見えるようになる。
数字を一発で良くする魔法は無いので、比較できる状態を先に作るのが近道だと感じます。
RAG そのものの仕組みは、別記事で整理しました。
AI に AI を採点させる評価方法そのものは、こちらの記事で扱っています。
以上です。
コメントを残す