日本語RAGのテストケース設計 — 「文書にない」を正解にする

社内文書にAIを接続するRAG構成の導入検討では、デモ画面での説得力と、業務に投入してからの実際のトラブルは別物だ。技術好きな提案者が示す画面では、ほぼすべてが期待通りに動く。ところが本番に入ると、検索が外れ、根拠にない捏造回答が出て、部門を跨いだアクセス権限が守られず、敬語が崩れた日本語が返ってくる。この落差の正体は、何を測るかを決めていないまま導入前テストが済んでしまうところにある。記事の執筆者は日本企業のRAG導入を支援する立場から、これまでの運用で積み重ねたテストケース設計の方針を整理している。

AIの鬼が注目するのは、この落差を埋めるために「テストケースの設計」が完全に主役になっているという発見だ。通常のAI評価なら、精度スコアや正解率を追うことになるが、実運用では「簡単な質問に答えられるか」といった項目は本当は二次的だ。本当に怖いのは、文書にない情報を「あるらしい」と捏造するケース、越権して見えてはいけない情報を漏らすケース、日本語の細部（敬語の文体、氏名の順序、カタカナ表記ゆれ）が崩れるケースである。これらは「デモ画面では起きにくい」ケースだからこそ、意識的に用意して測る必要がある。記事が示した6軸の測定基準——検索精度、根拠忠実性、権限分離、表記ゆれ・同義語、要約忠実性、「文書にない」ことを認める能力——も、業務実装で実際に問題になる順序と優先度で並んでいる。テストケースを単なる問題集ではなく、構造化されたデータとして、測定対象ごとのウェイト付けと採点基準を含めて設計することで、初めて「本番に耐える製品」を見分けられるようになるのだ。

中小企業がRAGを導入するなら、ベンダーが示す「テストケース」の内訳を見るべきだ。簡単な質問だけで満点が出ているなら、まだ本運用の準備はできていない。「文書に書かれていない質問に『記載なし』と答えているか」「権限外の情報を引かないようフィルターされているか」「日本語の敬語や数値形式が正しく保たれているか」といった否定側と日本語特有のテストが充実しているかを確認してから導入判断を下ろす。それができていないRAGは、初回インシデント——就業規則の捏造回答や機密情報の漏洩——が評価の最初の機会になってしまう。テストケースの設計こそが、デモと本番の落差を埋める最後の砦だ。