LLMアプリで社内規程や技術ドキュメントを検索し、回答を生成する場合、「その回答はどこに書いてあるのか」を利用者が確認できることが重要です。
回答文だけを表示すると、内容が正しくても検証できません。逆に、検索結果をそのまま並べるだけでは、利用者が必要な箇所を読みにくくなります。
この記事では、RAG（Retrieval-Augmented Generation）型のLLMアプリに引用元表示を実装する際の設計パターンを紹介します。実装のポイントは、検索段階で出典情報を失わず、生成段階では引用IDを明示させ、表示前に引用の妥当性を検証することです。
1. 引用元情報を検索結果に持たせる
まず、ドキュメントを分割して検索インデックスに登録する際、本文だけでなく出典情報も一緒に保存します。
最低限、次のようなメタデータを持たせます。
-
source_id: 文書内で一意なID -
title: 文書タイトル -
url: 元ページへのリンク -
pageまたはsection: ページ番号や見出し -
chunk_id: 検索対象チャンクのID
実際に試した構成では、LLMに渡すコンテキストと、画面表示用のメタデータを別々に管理しました。本文にURLを直接埋め込むより、IDで紐付けたほうがプロンプトを簡潔に保てます。
from dataclasses import dataclass
@dataclass
class SearchResult:
chunk_id: str
text: str
title: str
url: str
section: str
score: float
results = [
SearchResult(
chunk_id="chunk-001",
text="パスワードは90日ごとに変更する必要があります。",
title="社内セキュリティ規程",
url="https://example.com/security-policy",
section="第3章 パスワード管理",
score=0.91,
)
]
この時点で、検索結果を単なる文字列に変換してしまわないことが重要です。後続処理で引用リンクを作るため、メタデータは回答生成が終わるまで保持します。
2. コンテキストに引用IDを付ける
検索結果をLLMへ渡す際は、各チャンクに [S1] のような引用IDを付けます。
def build_context(results: list[SearchResult]) -> str:
blocks = []
for index, result in enumerate(results, start=1):
blocks.append(
f"[S{index}]\n"
f"タイトル: {result.title}\n"
f"セクション: {result.section}\n"
f"本文: {result.text}"
)
return "\n\n".join(blocks)
生成用プロンプトには、回答ルールも明記します。
あなたは検索結果に基づいて回答するアシスタントです。
ルール:
- 検索結果に根拠がない内容は断定しない
- 事実を述べる文の末尾に、根拠となる引用IDを付ける
- 引用IDは [S1] の形式で記載する
- 根拠が複数ある場合は [S1][S2] のように記載する
- 回答できない場合は「確認できませんでした」と答える
検索結果:
{context}
質問:
{question}
回答例は次のようになります。
パスワードは90日ごとに変更する必要があります。[S1]
ここで大切なのは、LLMにURLそのものを書かせないことです。URLを生成させると、存在しないURLや誤ったURLが出力される可能性があります。LLMには引用IDだけを生成させ、実際のリンクはアプリケーション側で解決します。
3. 引用IDから表示用リンクを生成する
LLMの回答に含まれる引用IDを抽出し、対応する検索結果から出典一覧を組み立てます。
import re
def extract_source_ids(answer: str) -> list[str]:
ids = re.findall(r"\[S(\d+)\]", answer)
return sorted(set(f"S{source_id}" for source_id in ids))
def build_citations(
answer: str,
results: list[SearchResult],
) -> list[dict]:
source_ids = extract_source_ids(answer)
citations = []
for source_id in source_ids:
index = int(source_id[1:]) - 1
if 0 <= index < len(results):
result = results[index]
citations.append({
"id": source_id,
"title": result.title,
"section": result.section,
"url": result.url,
"chunk_id": result.chunk_id,
})
return citations
APIレスポンスは、本文と引用を分けて返す設計にすると、Web UIやモバイルアプリで扱いやすくなります。
{
"answer": "パスワードは90日ごとに変更する必要があります。[S1]",
"citations": [
{
"id": "S1",
"title": "社内セキュリティ規程",
"section": "第3章 パスワード管理",
"url": "https://example.com/security-policy",
"chunk_id": "chunk-001"
}
]
}
画面上では、本文中の [S1] をクリック可能なバッジに置き換え、回答の下に「出典」一覧を表示する形が分かりやすいです。長いURLを本文に表示せず、タイトルとセクションを見せると、可読性も保てます。
4. 引用の妥当性を検証する
引用IDが存在するだけでは、十分な品質とはいえません。LLMが検索結果にないIDを出力したり、回答の主張と関係ない出典を付けたりする可能性があるためです。
まずは、存在しない引用IDを除外します。
def validate_citations(
answer: str,
results: list[SearchResult],
) -> tuple[str, list[str]]:
valid_ids = {
f"S{index}"
for index in range(1, len(results) + 1)
}
referenced_ids = extract_source_ids(answer)
invalid_ids = [
source_id
for source_id in referenced_ids
if source_id not in valid_ids
]
return answer, invalid_ids
本番運用では、次のようなチェックも有効です。
- 引用IDが1つもない回答を検出する
- 検索結果にない引用IDをエラーとして記録する
- 引用元チャンクのスコアが低い場合に注意表示する
- 回答の各段落に引用があるか確認する
- 出典ページが削除されていないか定期的に確認する
引用が不正な場合は、無理にリンクを表示せず、「出典を特定できませんでした」と扱うほうが安全です。引用機能は回答をもっともらしく見せるための装飾ではなく、利用者が検証するための機能だからです。
5. 実装時に注意したこと
チャンクを細かくしすぎない
チャンクが短すぎると、主語や条件が別チャンクに分かれてしまいます。たとえば「管理者は申請できる」という文と、「緊急時に限る」という条件が分離すると、LLMが条件を落とす可能性があります。
見出し、段落、箇条書きの単位を意識し、前後の文脈が残るように分割します。
引用は主張単位で付ける
回答全体の末尾に引用を1つだけ付けるより、主張や段落ごとに引用を付けたほうが検証しやすくなります。
通常の申請は平日の営業時間内に受け付けます。[S1]
緊急申請は管理者の承認が必要です。[S2]
出典の版を保存する
同じURLの内容が更新される場合、後から見たページと回答生成時の根拠が異なることがあります。文書の更新日時、版番号、取得日時もメタデータとして保存しておくと、監査や問い合わせ対応に役立ちます。
「出典付き」と「正しい」は別
引用元が表示されていても、LLMが出典内容を誤って要約する可能性は残ります。そのため、重要な業務では、回答生成後に検索チャンクとの一致を確認する処理や、人による確認フローも必要です。
まとめ
引用元表示の処理全体の流れを図にすると次の通りです。
LLMアプリの引用元表示は、次の流れで設計すると実装しやすくなります。
- 検索結果にURLや文書位置などのメタデータを持たせる
- コンテキストに
[S1]のような引用IDを付ける - LLMにはURLではなく引用IDを生成させる
- アプリ側で引用IDを実際の出典リンクに変換する
- 不正な引用や根拠のない回答を検証する
私が検証した範囲では、引用をLLMの自由生成に任せず、検索結果のメタデータとアプリケーションロジックで管理する構成が最も扱いやすいと感じました。利用者が回答の根拠をすぐ確認できるようになると、LLMアプリを業務で使う際の安心感と運用性が大きく向上します。