Attributed Language Model（アトリビューテッドランゲージモデル）
生成するテキストの各主張に対して情報源を自動的に紐づける機能を持つ言語モデル。通常のLLMが「何を言うか」に最適化されるのに対し、Attributed LMは「何を言い、その根拠は何か」を同時に出力する設計となっている。
Attributed Language Modelとは
Attributed Language Model（帰属付き言語モデル）は、テキスト生成と同時に各主張の情報源（Attribution）を出力する言語モデルアーキテクチャである。2023年にGoogle Researchが発表した論文「Attributed Question Answering: Evaluation and Modeling for Attributed Large Language Models」で体系化された概念で、LLMの信頼性向上における重要な研究方向となっている。
通常のLLMとの違い
| 特性 | 通常のLLM | Attributed LM |
|---|---|---|
| 出力 | テキストのみ | テキスト + ソース参照 |
| 学習目標 | 次トークン予測 | 次トークン予測 + ソース選択 |
| ハルシネーション | 検出困難 | ソース照合で検出可能 |
| 推論コスト | 1パス | 1パス〜2パス（方式による） |
| 学習データ | テキストコーパス | テキスト + メタデータ（出典情報） |
主要なアーキテクチャ
Retrieve-then-Generate（検索後生成型）
最も実用的なアプローチ。外部知識ベースから関連ドキュメントを検索し、そのコンテキストとともに回答を生成する。検索されたドキュメントが自動的にAttributionとなる。
代表的な実装：
- REALM（Google, 2020）: 検索エンコーダとジェネレータを end-to-end で学習
- ATLAS（Meta, 2023）: Fusion-in-Decoder + Contriever 検索器。Few-shot性能でGPT-3に匹敵しつつ50倍少ないパラメータ
- Self-RAG（2024）: 自己反省トークンで検索の要否・ソースの関連性・回答の妥当性を動的に判断
Generate-then-Attribute（生成後帰属型）
まず通常のLLMで回答を生成し、次に別のモジュールが各文に対応するソースを検索して紐づける。生成品質への影響が最小だが、帰属の正確性は2段目のモジュール性能に依存。
代表的な実装：
- RARR（Google, 2023）: Retrofit Attribution using Research and Revision。生成後にソースを検索し、ソースと矛盾する部分を自動修正
- Post-hoc Citation（各社独自実装）: NLI（自然言語推論）モデルで文とソースの含意関係を判定し、スコア閾値以上のソースを引用として付与
Joint Generation（同時生成型）
テキストとAttributionを単一のデコーディングプロセスで同時に生成する。特殊トークン（例: <cite>source_id</cite>）を語彙に追加し、学習データにソース参照を埋め込んで学習する。
研究段階の実装が多いが、以下の利点がある：
- 生成と帰属の一貫性が最も高い
- 推論コストが追加モジュール不要で最小
- ソースの内容に基づいた生成が可能（ハルシネーション抑制効果）
評価フレームワーク
AIS（Attributable to Identified Sources）
Google Research が提案した基本指標。生成された各文が、付与されたソースによって「帰属可能」かどうかを人手または自動評価する。
判定基準：
- Fully Attributable: ソースの内容から論理的に導出可能
- Partially Attributable: 一部はソースで裏付けられるが、追加情報を含む
- Not Attributable: ソースでは裏付けられない主張
AutoAIS
AISの人手評価を自動化したもの。NLIモデル（TRUE、T5-XXL-NLI等）を使用し、文とソースの含意関係を自動判定する。人手評価との相関は0.82〜0.90（タスク依存）。
ALCE（Automatic LLMs' Citation Evaluation）
Stanford NLP が開発した包括的評価フレームワーク。Citation Precision、Citation Recall に加え、回答品質（Fluency、Correctness）も同時に評価する。3つのデータセット（ASQA、QAMPARI、ELI5）で標準化されたベンチマークを提供。
実用上の設計判断
引用粒度の選択
- 文レベル: 精度は高いが引用数が多くなりユーザー体験を損なうリスク
- 段落レベル: バランスが良く、多くの商用サービスで採用
- 主張レベル: 最も精密だが、主張の切り出し自体が難しい（Claim Decomposition が必要）
ソース信頼性のランキング
全てのソースを等価に扱うと、低品質なWebページが一次情報と同列に引用される。ソースの信頼性スコア（ドメイン権威性、発行日、著者情報）で重み付けするフィルタリングが実用上必須。
FAQ
Q1: Attributed LMはハルシネーションを完全に防げる？
A1: 完全には防げない。ソースの内容を曲解して引用する「Misattribution」や、ソース自体が誤っている場合には対応できない。ただし、検証可能性を提供することで、ユーザーが誤りを発見・修正するコストを大幅に下げる効果がある。
Q2: Attributed LMの推論コストはどれくらい増える？
A2: 方式による。Retrieve-then-Generate型は検索コスト（50〜200ms）が追加される。Generate-then-Attribute型は後処理でNLIモデルを回答文数×ソース候補数だけ実行するため、回答が長いほどコスト増。Joint Generation型は追加コストがほぼゼロだが、学習コストが高い。
Q3: 社内ドキュメントでAttributed LMを構築するには？
A3: RAGパイプライン + チャンクメタデータの整備が最短経路。社内ドキュメントをチャンク分割しベクトルDBに格納する際、各チャンクにソースファイル名・セクション名・更新日を付与する。LLMへのプロンプトで引用フォーマットを指定すれば、最低限のAttributed LMが構築可能。