引用溯源是什么
让模型在每段结论后面标注用了哪条资料，前端把标记映射回原文片段与链接。它一次解决三件事：用户能核对答案、产品能压低幻觉率、合规方能看到依据。落地关键是两条硬约束：提示词层面「没有资料就不下结论」，工程层面引用必须由后端程序化校验，因为模型完全可能引用一个不存在的编号。
基本信息
| 输出形态 | 行内标记加文末来源列表，或结构化 JSON 的 citations 字段 |
|---|---|
| 提示约束 | 只依据给定资料回答，无法得出时固定回复「资料中未提及」 |
| 后端校验 | 检查编号是否越界、chunk_id 是否真实存在，校验通过再渲染 |
| 唯一键 | 以 chunk_id 而非序号作为引用主键，避免顺序变化导致跳错 |
| 展示层 | 点击标记跳转原文并高亮对应段落 |
| 留存字段 | 文档标识、页码或偏移、命中时间，便于审计追溯 |
典型使用场景
- 企业内部知识库问答：员工需要点开原文核对，而不是只看到一段总结
- 合同、法规与标准检索：结论必须能定位到具体条款原文
- 客服对外答复：有出处才允许直接发给客户，无出处转人工
- 医疗、金融等高风险问答：留痕是审计与合规的前提
- 内容生产环节：编辑依据引用逐条核对事实，降低返工
结构化引用输出
结构化引用输出
只依据给定资料回答；每个结论后面用 [n] 标注来源编号。 # 强制逐句标注
无法从资料中得出结论时，只回答“资料中未提及”。 # 留出拒答出口
资料片段自带编号，例如 [1] ……（此处为召回文本）
输出 JSON，字段固定，便于后端解析：
{"answer": "……[1]",
"citations": [{"idx": 1, "chunk_id": "kb-8123#p7"}]}
# 后端拿到 chunk_id 后核对存在性，再渲染为可点击链接引用异常与处理
| 异常 | 表现 | 处理 |
|---|---|---|
| 幻觉引用 | 引用了不存在的编号 | 后端按 chunk_id 校验，不存在则剔除或标注 |
| 引用与结论不符 | 来源里没有该说法 | 抽检加逐句标注，把不符样本加入评测集 |
| 跳错文档 | 序号与来源列表错位 | 以 chunk_id 为唯一键，不依赖顺序 |
| 结论无引用 | 整段没有一个标记 | 提示词强制无来源不下结论 |
| 引用堆砌 | 一句挂五六个来源 | 限定每句最多一到两个来源 |
上下文越长，模型引用错位的概率越高：把召回片段的编号写进文本里，并在提示词中要求先复述编号再作答，准确性通常明显好于只给顺序列表。
引用能降低错觉但不能消除：标注了出处的一段话仍可能与原文含义相反，高风险领域必须保留人工抽检环节，不能把校验完全交给模型自检。