最初のRAGデモはいつもうまくいく。
きれいなPDFをアップロードし、当然の質問をする。モデルは該当する段落を見つけ、潤沢な資金を得たコンサルタントのような口調で答える。
ところが、ユーザーが間違った略語で質問したり、3週間前にポリシーが変更されていたり、答えが2つのドキュメントにまたがっていたり、システムが関連性はありそうだが主張を実際には裏付けない段落を引用したりする。
製品開発はそこから始まる。
検索こそが最初のプロダクト判断
RAGの品質は、モデルが何かを目にする前から始まっている。
検索層が、モデルに何を知らせるかを決める。間違ったチャンクが返ってくれば、答えはすでに損なわれている。より良いプロンプトが問題を隠せるかもしれないが、修正はできない。
私は検索を退屈な質問で評価する：
- 正しいドキュメントが上位結果に現れたか？
- 正しいファイルだけでなく、正しいセクションが現れたか？
- 新しい情報が古い情報より上位にランクされたか？
- 実際のユーザーが使うような言い回しでもクエリが機能したか？
- 正直な答えが「なし」である場合に、システムは何も返さなかったか？
最後の点は重要だ。常に何かを返す検索システムは、モデルに常に何かを言うことを教えてしまう。
回答の確信度より引用の忠実性
答えだけでは不十分だ。
あらゆる知識システムにおいて、引用されたソースが実際に主張されている文を裏付けているかどうかを知りたい。
つまり、応答レベルではなく、主張レベルで評価する必要がある。答えに4つの主張があり、そのうち2つしか裏付けられていない場合、その答えは「ほぼ正しい」わけではない。それは、見た目は洗練されているが危険なものだ。
シンプルな評価基準で十分だ：
- 裏付けあり：引用が主張を直接証明している。
- 部分的：引用は関連しているが、完全には証明していない。
- 裏付けなし：引用は主張を証明していない。
- 矛盾：引用が反対のことを述べている。
始めるのに凝ったベンチマークは必要ない。必要なのは30の実際の質問と、ミスを正直に記録する規律だけだ。
拒否は機能である
RAGシステムは、いつ答えるべきでないかを知る必要がある。
つまり、コーパスに答えが含まれていない質問をテストする必要がある。また、答えが機密情報だったり、古かったり、ユーザーが提供しなかった文脈に依存する質問もテストする必要がある。
良い拒否の振る舞いは次のようなものだ：
「利用可能なソースにはそれが見つかりません。最も関連性の高いドキュメントはXですが、質問に直接答えているわけではありません。」
悪い拒否の振る舞いは次のようなものだ：
「利用可能な情報に基づくと、どうやら…」
このフレーズこそ、幻覚が体裁を整えて現れるところだ。
役立つスコアカード
社内RAGシステムには、一つの印象的なベンチマークスコアよりも、5つの地に足のついた指標を追跡したい：
- 検索ヒット率：正しいソースが現れたか？
- 引用の忠実性：ソースが答えを裏付けていたか？
- 拒否の正確性：裏付けのない質問を断ったか？
- 回答の有用性：ユーザーは次のステップに進めたか？
- 編集距離：人間はどれだけ修正する必要があったか？
最後の指標が最も正直だ。ユーザーが答えを書き直し続けるなら、システムは彼らの時間を節約していない。監視しなければならない、丁寧な初稿を作り出しているだけだ。
測定できるほど小さく始める
適切な最初のRAGシステムは、たいてい「会社の頭脳」ではない。
それは、一つのコーパス、一つのワークフロー、一つのユーザータイプ、そして答えの後の一つの明確なアクションである。サポートマクロ、セールスイネーブルメント、ポリシー検索、社内エンジニアリングドキュメント、契約条項検索。
範囲を狭くすることで、評価が可能になる。
評価が信頼を可能にする。
信頼が拡大を可能にする。
この順序が重要だ。
