RAG 怎样保留检索片段来源以生成引用

RAG 想生成可靠引用，关键不是让模型“记住网址”，而是从文档切片开始就把来源元数据和文本绑在同一条记录里。检索时返回这条完整记录，拼接上下文时只暴露短小的引用标记，最后由程序把标记映射回标题、章节、原文位置和 URL。

官方地址：https://huggingface.co/docs/transformers/main/model_doc/rag

把来源当成检索记录的一部分保存，而不是生成回答后再根据相似文字反查。最小可靠链路是：chunk_id → 来源字段 → 上下文标记 → 引用映射。

Hugging Face 的 RAG 文档把检索文档 ID、检索后的上下文输入和文档分数作为独立输出字段说明，这也提醒我们：检索结果本身就应当保留可追踪的身份信息。下面用一个与具体向量库无关的 Python 结构，说明这条链路怎样落地。

切片时就把来源字段存下来

一段文本至少要有一个稳定的 chunk_id。它不应该只使用当前检索排名，因为排序会随着查询变化；可以由文档 ID、版本和切片序号组成。除此之外，保存标题、章节、来源地址、页码或字符区间，才能在展示引用时给读者足够的定位信息。

from dataclasses import asdict, dataclass

@dataclass
class Passage:
    # chunk_id 跨查询保持稳定，不能使用 top-k 排名代替
    chunk_id: str
    text: str
    source_url: str
    title: str
    section: str
    start_offset: int
    end_offset: int

def make_passage(doc_id: str, version: str, index: int, text: str,
                 source_url: str, title: str, section: str,
                 start: int, end: int) -> dict:
    # 版本进入 ID，文档更新后可以区分旧引用和新引用
    chunk_id = f"{doc_id}:{version}:{index}"
    return asdict(Passage(
        chunk_id=chunk_id,
        text=text,
        source_url=source_url,
        title=title,
        section=section,
        start_offset=start,
        end_offset=end,
    ))

这里的 start_offset 和 end_offset 不是必须字段，但在同一篇文档有很多相似段落时很有价值。如果原始数据来自 PDF，也可以把页码和版面区域放入元数据；原则不变：来源定位信息必须和文本一起进入索引，而不是等回答生成后再猜。

检索时不要只返回一列文本

向量库或搜索服务通常允许把业务元数据放在 payload、metadata 或 document 字段中。检索函数的返回值应该仍然是一组完整记录，例如 {"text": "...", "metadata": {...}, "score": 0.82}，而不是只留下字符串列表。

def retrieve(query: str, top_k: int = 4) -> list[dict]:
    # 这里用伪函数表示向量库查询；真实项目替换成自己的客户端调用
    hits = vector_store.search(query, limit=top_k)
    records = []
    for hit in hits:
        # 文本、分数和 metadata 必须来自同一条命中记录，避免错位
        metadata = hit.get("metadata", {})
        records.append({
            "chunk_id": metadata["chunk_id"],
            "text": hit["text"],
            "score": hit.get("score"),
            "source_url": metadata.get("source_url"),
            "title": metadata.get("title"),
            "section": metadata.get("section"),
        })
    return records

不要在这一步把 chunk_id 改成 1、2、3 并丢掉原始 ID。展示给模型的短标记可以重新编号，但程序必须保留“短标记 → 原始记录”的映射。

给上下文加短标记，引用详情留在程序侧

如果把完整 URL、长标题和所有元数据反复塞进提示词，上下文会变长，模型也更容易把地址当成普通文本改写。更稳妥的方式是：为本次请求的每条记录生成 [S1]、[S2] 这样的短标记，把完整来源放在服务端的 citation_map 中。

def build_context(records: list[dict]) -> tuple[str, dict[str, dict]]:
    citation_map = {}
    blocks = []
    for number, record in enumerate(records, start=1):
        marker = f"S{number}"
        # 只把短标记写入上下文，完整来源留在服务端映射中
        citation_map[marker] = {
            "chunk_id": record["chunk_id"],
            "source_url": record.get("source_url"),
            "title": record.get("title"),
            "section": record.get("section"),
        }
        blocks.append(f"[{marker}] {record['text']}")
    return "\n\n".join(blocks), citation_map

def make_prompt(question: str, context: str) -> str:
    # 约束模型只引用实际出现的标记，不能自行编造来源编号
    return (
        "只根据给定资料回答问题；每个可核实结论后附 [S1] 这类标记。"
        "没有对应资料时明确说无法从资料确认。\n"
        f"问题：{question}\n资料：\n{context}"
    )

这里的编号只在一次请求内有效。下一次查询即使命中了同一段，也可能得到新的 S1；真正稳定的身份仍然是 chunk_id。因此，日志或缓存应同时记录本次请求的标记映射和原始检索记录。

生成后把标记还原成可读引用

模型返回文本后，先提取它使用过的标记，再从 citation_map 取回来源信息。渲染时可以把 [S1] 显示成脚注、悬浮卡片或来源列表，但不要把未经映射的标记直接展示给用户。

import re

def resolve_citations(answer: str, citation_map: dict[str, dict]) -> list[dict]:
    # 去重并保留首次出现顺序，避免同一来源重复渲染
    markers = list(dict.fromkeys(re.findall(r"\[S(\d+)\]", answer)))
    resolved = []
    for number in markers:
        key = f"S{number}"
        source = citation_map.get(key)
        if source is None:
            # 模型可能编造编号；未知标记不能生成假链接
            continue
        resolved.append({"marker": key, **source})
    return resolved

如果应用需要把引用插回答案，建议使用结构化输出，例如让模型返回 answer 和 citations 两个字段，并在服务端检查每个 citation 是否存在于当前映射。不要只相信模型返回的 URL 字符串。

合并、去重和无依据回答要单独处理

多个相邻切片可能来自同一篇文档。可以在展示层按 source_url + section 合并，但不要在检索层把不同版本的 chunk_id 静默合成一个 ID，否则用户无法知道引用对应哪个版本。

• 同一事实由两个片段共同支撑时，保留两个标记或生成一个包含多个来源的引用组。
• 模型输出了不存在的 [S9] 时，删除未知映射并记录异常，不要自动猜测最相似的来源。
• 回答中的句子没有来源标记时，可以标记为“基于常识的说明”或要求模型重写，而不是强行附上最近的一条文档。
• 文档更新后重新切片时，改变版本号或内容哈希，让旧回答的引用仍能指向当时的材料。

这套做法解决的是“来源是否能被找回”，不等于自动证明回答一定正确。引用存在只能说明回答关联了哪些检索片段，仍需要对片段覆盖范围、冲突内容和模型是否真的依据它们进行单独评估。

常见问题

只保存 source_url 不保存 chunk_id 可以吗？

不建议。一个 URL 可能被切成很多段，只有 URL 无法说明回答引用了哪一段。至少再保存稳定的文档 ID、切片序号或内容范围。

为什么不让模型直接输出完整 URL？

完整 URL 会增加上下文长度，也可能被模型改写或拼接错误。短标记加服务端映射更容易检查，最终 URL 由程序生成。

检索结果重新排序会破坏引用吗？

只要排序变化不改变记录内部的 chunk_id 和来源字段，就不会。变化的只是本次请求中的 S1、S2 临时编号。

没有匹配片段时应该怎样引用？

不要生成看似合理的来源。让回答明确说明当前资料不足，或者返回需要补充检索的状态，这比给出一条无关链接更可靠。