引用検証（インヨウケンショウ）
LLMが生成した引用（出典情報）が実際に正しいかを自動的に検証するプロセス。引用先URLの存在確認、引用先コンテンツと回答内容の整合性チェック、引用の網羅性評価などを含み、ハルシネーテッド・シテーション（架空の引用）を検出・排除する。
引用検証とは
引用検証（Citation Verification）は、LLMが出力した引用情報の正確性を自動的に検証する技術プロセスである。LLMは実在しないURLや論文タイトルを「もっともらしく」生成する能力を持つため、引用が付いているからといって信頼できるとは限らない。この問題は「ハルシネーテッド・シテーション（Hallucinated Citation）」と呼ばれ、引用検証はその対策として不可欠な後処理パイプラインとなっている。
引用検証の3段階
Stage 1: 存在検証（URL/文献の実在確認）
引用先のURL・DOI・論文タイトルが実在するかを確認する。
- URL検証: HTTP HEAD/GETリクエストで200応答を確認。リダイレクト先の最終URLも記録
- DOI検証: CrossRef API（
https://api.crossref.org/works/{doi}）でメタデータ取得 - 論文タイトル検証: Semantic Scholar API / Google Scholar で論文の存在を検索
- 書籍検証: Open Library API / Google Books API でISBN・タイトル照合
検出される問題：
- 完全に架空のURL（ドメインは実在するが該当ページが存在しない）
- 著者名や年号が微妙に異なる論文タイトル（GPT系モデルに多い）
- 存在するが内容が異なるURL（ドメインだけ正しく、パスが架空）
Stage 2: 整合性検証（内容の一致確認）
引用先のコンテンツを取得し、LLMの回答中の該当箇所と意味的に整合しているかを検証する。
手法：
- NLI（自然言語推論）: 回答文をPremise、ソース文をHypothesisとしてEntailment/Contradiction/Neutralを判定
- セマンティック類似度: 回答文とソースチャンクの埋め込みベクトルのコサイン類似度を計算
- ファクトチェック特化モデル: Google Research の FActScore、Meta の SAFE など
判定基準（実用上の閾値）：
| NLI判定 | 類似度スコア | 判定結果 |
|---|---|---|
| Entailment (確率>0.8) | cos>0.85 | 検証OK |
| Neutral (確率>0.5) | 0.65<cos<0.85 | 要確認（部分一致） |
| Contradiction (確率>0.5) | cos<0.65 | 引用不適切（矛盾・無関係） |
Stage 3: 網羅性検証（引用漏れの検出）
回答中の検証可能な主張のうち、引用が付与されていないものを検出する。
手法：
- Claim Decomposition: 回答を個別の主張に分解し、各主張に対する引用の有無をチェック
- Citation Gap Detection: 数値データ、固有名詞、統計情報を含む文で引用がないものをフラグ
自動検証パイプラインの構成
LLM回答（引用付き）
↓
[1] URL/DOI 存在チェック
↓ (存在しない → ハルシネーテッド・シテーション警告)
[2] ソースコンテンツ取得（Webスクレイピング/API）
↓
[3] NLI判定（回答文 vs ソース文）
↓ (Contradiction → 引用不適切警告)
[4] Citation Gap 検出
↓ (未引用の主張 → 追加引用候補を検索)
[5] 検証済み回答を出力
主要な評価フレームワークとツール
| ツール/フレームワーク | 開発元 | 手法 | 対象 |
|---|---|---|---|
| FActScore | MIT/Google | 主張分解 + Wikipedia検証 | 人物伝記 |
| SAFE | Google DeepMind | Search-Augmented Factuality Evaluator | 一般Q&A |
| TRUE | Google Research | NLIベース帰属判定 | 要約・Q&A |
| ALCE | Stanford NLP | Citation Precision/Recall | 引用付き回答 |
| MiniCheck | UW | 小型NLIモデル（7B） | コスト重視の検証 |
| Vectara HHEM | Vectara | Hughes Hallucination Evaluation Model | エンタープライズ |
実装上の考慮点
パフォーマンスとコスト
- URL存在チェック: 1件あたり100〜500ms（並列化で10件/秒程度）
- NLI判定: 文ペアあたり10〜50ms（GPUモデル使用時）
- 全体パイプライン: 引用10件の回答で2〜5秒の追加レイテンシ
スケーリング戦略
- 同期検証: ユーザーに回答を返す前に全引用を検証（レイテンシ増大）
- 非同期検証: 回答を先に返し、検証結果を後から更新（UX重視）
- 段階的検証: Stage 1（存在チェック）のみ同期、Stage 2-3は非同期
信頼度スコアの表示
検証結果をユーザーに伝える方法として、引用ごとに信頼度を色分け表示するアプローチがある。
- 緑: 検証OK（Entailment + URL存在）
- 黄: 部分一致（Neutral）
- 赤: 検証NG（Contradiction または URL不在）
FAQ
Q1: 引用検証のコストを抑えるには？
A1: Stage 1（URL存在チェック）は低コストで実装可能なため、まずこれだけ導入するのが費用対効果が高い。Stage 2のNLI判定はMiniCheck（7Bパラメータ）を使えばGPUコストを1/10に削減可能。全主張でなく数値・固有名詞を含む文のみ検証する選択的アプローチも有効。
Q2: 引用検証は日本語でも精度が出る？
A2: 英語に比べると精度は若干落ちる。多言語NLIモデル（mDeBERTa-v3-base等）の日本語性能はEN比で5〜10ポイント低い傾向。日本語ソースのWebスクレイピングも文字コードやJavaScript描画の問題で取得失敗率が高い。日本語特化のファクトチェックモデルは2026年時点でまだ研究段階。
Q3: 引用検証を通過しても誤情報の可能性はある？
A3: ある。ソース自体が誤っている場合（偽情報サイト、古い情報、誤報）は検証を通過しても回答が不正確になる。ソースの信頼性評価（ドメイン権威性スコア、発行日チェック、著者情報確認）を組み合わせることで、この問題を緩和できる。