この記事で分かること／分からないこと
- 分かること: 検索が外れた時に「再検索させる」設計と「諦めさせる」設計、それぞれの効き所
- 分かること: 自社実装が経路(確定配信/確認応答/自由生成)ごとに幻覚リスクをどう切り分けているか
- 分からないこと: 再検索(クエリの言い換えや追加検索)そのものの精度を単独で測った数値
- 分からないこと: 諦めさせる閾値をどこに置くのが最適かという一般解
「引けなかった時」に取りうる2つの方針
一般的な設計として、検索で十分な根拠が見つからなかった場合には大きく2つの方針がある。一つは、クエリを言い換えたり追加の検索を行ったりして、もう一度根拠を探しにいく再検索である。もう一つは、無理に答えず「分からない」と伝える、あるいは質問の確認を促す諦めである。再検索は答えられる範囲を広げられる一方、根拠の薄いまま生成に踏み込む機会も増える。諦めは幻覚のリスクを抑えられる一方、本来答えられたはずの質問まで取りこぼす。
自社実装は経路によって幻覚リスクを切り分けている
編集部が検証に使っている自社RAG基盤は、応答を経路ごとに分けて扱う(実体: services/verifier/src/grounding-gate.ts)。あらかじめ用意した項目に一致した場合は確定配信で、事実主張を検索元からそのまま返すため構造上幻覚が生じない。一致しない場合の確認応答は、そもそも事実主張をしない前提で設計されており、幻覚リスクを持たない。自由入力に対して自由生成で答える経路だけが、幻覚のリスクを持つ経路として扱われている。
確認応答は諦めの一種であり、コストの面でも合理的
確認応答は、事実主張をしないという点で諦めに近い振る舞いである。実行時にLLMを呼ばずに済む確定配信の実測コストは0.12円/セッションであり(出所: docs/STORAGE_AND_BILLING.md、確認日2026-09-06)、再検索のたびに新たなLLM呼び出しを重ねる設計に比べて、構造上のコストと幻覚リスクの両方を抑えられる。
汎用的なRAGの比較対象は「諦めを持たない」設計
自社実装と並べて比較するために用意されているベースラインRAGの実装(実体: services/verifier/src/baseline-rag.ts)は、上位k件の文書を文脈に入れて自由生成させる素朴な構成で、意図的に幻覚を作らないという指示を課していない。つまりこの比較対象には確認応答のような諦める経路がなく、根拠が薄くても常に何かしらの答えを生成する。自由生成だけに頼る設計が、それっぽいが幻覚しうる典型的な挙動になりやすい理由は、この諦めを持たない構造にあると考えられる。
諦めなかったことが誤りにつながった実例
編集部の検証では、12種の失敗モードのうち、曖昧な質問に確認せず断定してしまったパターンが1件記録されている(出所: 検証レポート、確認日2026-09-06)。これは、質問の意図を確かめる(諦めて聞き返す)べき場面で、確認せずに断定してしまった例であり、件数は1件しかないため一般化はできないが、諦める判断を挟む設計の必要性を示す実例として記録されている。
再検索と諦めのどちらに倒すかは、出典を求める設計とも関わってくる。出典が示せない生成をどう扱うかは出典提示の限界の記事、複数の候補を突き合わせて矛盾を見つける仕組みは複数候補の突合の記事で扱っている。幻覚率という指標そのものの読み方はこちらの記事で解説した。RAGの設計について相談したい方は、お問い合わせから編集部までご連絡いただきたい。
よくある質問
Q1. 再検索と諦め、どちらを優先すべきか
一律の正解はない。自社実装では、あらかじめ用意した項目に一致する場合は確定配信、一致しない場合は事実主張をしない確認応答という形で、まず諦める側に倒し、自由生成に踏み込む範囲を限定する設計を取っている。
Q2. 確認応答は幻覚を起こすか
起こさない設計になっている。確認応答は事実主張をしない前提で設計されており、実行時に事実の主張自体が発生しない。
Q3. 確定配信のコストはどれくらいか
実測で0.12円/セッションである(出所: docs/STORAGE_AND_BILLING.md、確認日2026-09-06)。実行時にLLMを呼ばない構成のため、再検索を重ねる設計に比べてコストを抑えやすい。
Q4. 「諦めなかった」ことが原因の失敗は記録されているか
ある。曖昧な質問に確認せず断定してしまったケースが1件記録されている(確認日2026-09-06)。ただし1件のみであり、一般化できる件数ではない。
- ハブ記事: RAGサービス比較15選
- 関連記事: RAGの幻覚率をどう測るか
- 関連記事: 出典を示させる設計とその限界
- 関連記事: 複数候補を突き合わせて矛盾を見つける