この記事で分かること／分からないこと
- 分かること: 「前提条件を捏造・取り違える」失敗(F7表のU4)がどのような仕組みで起きるか
- 分かること: 自社検証でU4に該当するテストが何件実施され、結果がどうだったか
- 分からないこと: 前提条件の種類や組み合わせが増えた場合にも同じ結果が再現するか
- 分からないこと: 業界全体でこの失敗がどの程度の頻度で起きるか
前提条件を捏造・取り違えるとは何か
RAGへの質問の中には、「AをするにはBが必要」のように、ある事柄の前提条件を尋ねるものがある。RAGがこの前提条件を、実在しない条件にすり替えたり、別の事柄の条件と取り違えたりして回答してしまう失敗がある。前提条件は多くの場合、その後の判断や手続きの起点になるため、他の失敗型と比べても、誤りが後工程に波及しやすい性質を持つ。編集部の自社RAG基盤の検証では、これをF7分類の「U4: 前提条件の捏造・誤り」として扱っている(出所: services/verifier/out/univ-demo.report.json の layer1.failureModes、確認日2026-09-06)。
なぜ関係そのものが検査から漏れやすいのか
自社の2層検査のLayer1(実体: services/verifier/src/grounding-gate.ts)は、応答から事実主張を取り出し、正規化したうえで真実集合(grounding fact)と照合する。判定は「主張中の全トークンが真実集合のテキストに含まれるか」という、トークン単位の一致で行われる。前提条件の誤りは、AとBという2つの事柄それぞれは実在の語であっても、「AにはBが必要」という関係そのものが誤って結び付けられているケースがあり、この関係の正誤はトークンの存在確認だけでは判定しにくい。U4はこの種の失敗を狙ったテストケースにあたる。
自社検証における実績:U4は1件
53件のテストクエリのうち、前提条件の捏造・取り違えを狙ったU4のテストは1件実施され、結果は合格(実在しない前提条件を答えることはなかった)だった(出所: out/univ-demo.report.json、確認日2026-09-06)。
1件の合格で言えること・言えないこと
標本数が少ない場合にどこまで言えるかという考え方(F6、確認日2026-09-06)では、n=12でも真の発生率の95%上限は22.1%とされている。U4のテスト件数はこのn=12よりもさらに少ない1件であり、1件の合格は「その1つの前提条件の組み合わせでは捏造しなかった」という事実にとどまる。前提条件が複数連なるケースや、条件同士が似ているケースについては、この検証だけでは確認できていない。
導入前に何を確認すべきか
対象業務に「何かをするには何かが必要」という前提条件・依存関係の説明が含まれる場合は、その組み合わせを変えたテストケースを複数用意することが望ましい。前提条件は利用者がそのまま行動の起点として使う可能性があるため、1件のテストで合格したという結果だけをもって運用に入れるのではなく、条件の種類ごとに件数を積み増してから判断する必要がある。
よくある質問
Q1. 前提条件の捏造・取り違えは、他の失敗型と比べて何が問題なのか
前提条件は、その後の判断や手続きの起点として使われやすい。個々の語(AやB)自体は実在していても、「AにはBが必要」という関係が誤っている場合、利用者はその誤った関係に基づいて行動してしまう可能性がある。
Q2. U4の1件はどのような検証か
自社の53件のテストクエリのうち、前提条件を捏造・取り違えるかを狙った質問が1件含まれており、結果は合格だった(出所: out/univ-demo.report.json、確認日2026-09-06)。
Q3. トークン単位の機械照合では、なぜこの失敗を見抜きにくいのか
Layer1は主張中の各トークンが真実集合に含まれるかを確認する仕組みであり、2つの事柄それぞれの実在は検査できても、その間の関係(前提条件)が正しく結び付けられているかまでは判定しない。
Q4. 1件の合格はどこまで一般化できるか
標本数が少ない場合の考え方(F6)では、n=12でも真の発生率の95%上限は22.1%とされる。U4の1件はそれより少ない標本であり、そのテストケースで捏造しなかったという事実以上には一般化できない。
自社のRAG検証全体の枠組みについては幻覚率の記事で扱っている。RAGの精度評価やテスト設計について相談したい方は、お問い合わせから編集部までご連絡いただきたい。
- ハブ記事: RAGサービス比較15選
- 関連記事: RAGの幻覚率をどう測るか
- 関連記事: 属性（評価方法・時期）を誤る型
- 関連記事: 未知への断定・片側断定で失敗する型