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

直したつもりが、別の質問を壊している

チャンクの切り方を変えたら、苦情の来ていた質問がきれいに答えられるようになった。これで一件落着、と思ったら翌週、それまで問題なく答えられていた別の質問が壊れていた。

RAG の改善では、これが日常的に起きます。切り方も、取得件数も、プロンプトも、全部の質問に同時に効く設定だからです。目の前の 1 件を直すと、見ていないところで別の 1 件が崩れます。

しかも、崩れたことに誰も気づきません。ユーザーは文句を言わずに、ただ使わなくなるだけです。だから、直す前に測る仕組みを置きます。

先に 50 件の正解セットを作る

用意するのは、質問と、期待する答えと、その根拠になる資料の場所を並べた表です。ゴールデンセットと呼ばれます。50 件から 100 件あれば、まず足ります。

作るのは地味な手作業ですが、ここを飛ばすと以降の判断が全部あてずっぽうになります。設定を変えるたびにこの 50 件を流し直せば、良くなったのか、どこかを壊したのかが数字で出ます。1 件だけ試して「直った気がする」で進めるのと、決定的に違うところです。

質問は自分で考えるより、実際に来た質問を使ってください。開発者が思いつく質問は整いすぎていて、現場の「あれってどうなってましたっけ」という聞き方が入りません。答えられて当然の易しい質問と、資料に答えが無い質問も混ぜておくと、変な埋め合わせをしていないかまで見えます。

検索が悪いのか、生成が悪いのかを分けて測る

50 件を流したときに見る指標は、3 つに分かれます。

1 つ目が下がっているなら触るのは検索側、2 つ目と 3 つ目が下がっているならプロンプト側です。合計点を 1 つ出して「精度 72 点」と眺めても、次に何をすればいいかは出てきません。分けて出すことに意味があります。

とくに 2 つ目は、業務で使うなら最優先です。日本語として流暢でも、資料に書かれていないことが混じっていれば、RAG を入れた意味がなくなります。

判定を人手で全部やると回らないので、実務では別の LLM に採点させます。回答と資料を渡して、資料に書かれていない主張が混ざっていないかを問う形です。完璧ではありませんが、変更の前後で比べる用途には十分に使えます。

使われ方から、次の 50 件を作る

運用が始まったら、ゴールデンセットは現場から補充します。

ここで大事なのは、フィードバックの取り方です。「役に立ちましたか」の二択ボタンだけを置くと、押された理由が分かりません。検索が外したのか、資料が古かったのか、回答が長すぎたのかを、選択肢として用意してください。

あわせて、回答に付けた出典を画面に出しておくと、利用者が「この資料は関係ない」と指摘できます。これは検索が外したという、いちばん価値のある報告です。しかも、それを言えるのはその業務を知っている本人だけです。

集まった指摘は、そのまま次のゴールデンセットの行になります。この往復が回り始めると、RAG は使われるほど良くなっていきます。