RAGを「根拠付きの回答」にするには？引用（citations）とグラウンディングの実務

結論（Conclusion）

RAGの精度は、ユーザーが **「どの文書が根拠か」**を確認できて初めて上がる。 最小で必要なのはこれ。

• 事実主張には引用を必須化
• 引用は安定した doc_id + chunk_id に紐づける
• 根拠が弱い/無いなら拒否または質問に切り替える
• retrieved_doc_ids をログして、後で「なぜそう答えたか」を説明できる

グラウンディングが無いRAGは、ただ“上手に幻覚する”だけ。

背景（Explanation）

• グラウンディング：回答を取得ソースに制約すること
• 引用：その制約を可視化し、監査可能にすること

RAGの典型的な失敗：

• ソースを使わずに回答する
• 引用を捏造する（source laundering）
• ソースが矛盾しているのに黙って片方を採用
• retrievalがズレていて、足りない部分を埋める

解決策は“プロンプト”より、パイプラインとUX。

実務手順（Practical Guide）

手順1：引用必須の条件を決める（10分）

守りやすいルールにする。

• 事実主張は最低1つの引用
• 数字/日付/ポリシーは引用必須
• 推奨や提案は無引用でもOKだが、提案だと明示

ルール：

• 引用なし = ungrounded として扱う

手順2：引用オブジェクトを設計する（10分）

URLだけの引用は避ける。 検証できる引用を返す。

• doc_id
• chunk_id（またはページ/byte offset）
• title
• source_type（wiki, ticket, upload など）
• retrieval_score

手順3：引用を必ず出力させ、検証する（10分）

実務パターン：

• JSONで answer + citations[]
• 本文に [1][2] のマーカー + citations一覧

ハード検証：

• 参照したcitation IDが存在しなければNG
• citations が retrieved set に無いならNG

これで引用捏造を抑える。

手順4：ソースの矛盾を明示して扱う（10分）

矛盾があるとき、黙って“勝者”を決めない。 選択肢：

• 両方を提示して、どちらが適用か質問
• ポリシーで新しいdocを優先（安全な場合のみ）
• 高リスクは人間レビューへエスカレーション

docメタデータも持つ：

• updated_at
• owner
• version

手順5：回答モードを分ける（10分）

• grounded mode（引用必須）
• summary mode（引用任意）
• draft mode（行動しない、慎重表現）

重要フローは grounded をデフォルトに。

手順6：証跡ログを残す（5分）

最低限：

• request_id
• retrieved_doc_ids + chunk_ids
• retrieval scores
• 返した citations
• ungrounded claim の検証失敗

争点になったとき doc_id で説明できる。

落とし穴（Pitfalls）

• 取得していない文書を引用できてしまう
• URLだけで引用（更新で壊れる）
• chunk識別子がない（検証できない）
• scoreが弱いのに回答してしまう
• 矛盾ソースを隠す

チェックリスト（Checklist）

• [ ] 引用必須の主張タイプを定義した
• [ ] 引用は doc_id + chunk_id に紐づいている（URLだけじゃない）
• [ ] 出力フォーマットに citations[] がある
• [ ] citations は retrieved set からのみ許可
• [ ] ungrounded claim はブロック/質問に変換する
• [ ] 矛盾ソースの扱いが明示されている
• [ ] docメタに updated_at と owner がある
• [ ] 機能ごとの grounded mode がある
• [ ] ログに retrieved_doc_ids と citations が残る
• [ ] 10分以内に doc_id で説明できる

FAQ

1) 引用があれば正しい？

正しさの保証ではなく、追跡可能性の保証。事実は「引用なしで主張しない」を徹底すると精度が上がる。

2) 最速の改善は？

retrieved_doc_ids をログし、数字/日付/ポリシーだけでも引用必須にする。

3) 引用はユーザーに見せるべき？

エンタープライズ/社内ツールは基本YES。コンシューマーは「Sources」ドロワーに隠すのもあり。

内部リンク（Internal links）

• Hub: AI開発
• 関連記事：
  • RAGのデータ汚染対策チェックリスト
  • LLM可観測性の最小ログ設計チェックリスト
  • プロンプトインジェクション対策チェックリスト

免責

一般的なエンジニアリングガイドです。