引用与可追溯

一句话理解：引用让答案里的每个关键结论都能指回具体的原文位置；它是用户信任的基础，也是发现幻觉、定位检索问题的工具。

客服专员问 Agent：“订单已经开了发票，退款前要先把发票作废吗？”Agent 回答：“是的，需要先作废。”

这个答案对不对？专员无从判断。如果答错了，后果是一批退款被重复发起或被卡住。于是她只能自己再去翻一遍政策——Agent 省下的时间全部归零。

如果回答变成“需要先作废发票【《退款政策》v3 第 4.2 条：“已开具发票的订单，应先完成发票作废，再发起退款”】”，她点开链接看一眼原文，10 秒钟就能确认。引用把“相信 Agent”变成了“验证 Agent”， 这是企业场景中知识类 Agent 能被真正使用的前提。

引用的作用与粒度

三个作用

作用	对谁	说明
建立信任	用户	用户可以快速核实，而不是盲信或全部重查
暴露幻觉	用户与系统	没有引用、或引用与结论对不上的内容，就是需要警惕的内容
定位问题	团队	答错时能看出是引错了文档（检索问题）还是读错了原文（生成问题）

第三点常被忽视。有了引用，RAG 的错误归因从“模型又胡说了”变成“它引用了 v2 版本的条款，说明版本过滤没生效”，修复方向立刻清晰。

四个粒度

引用可以做到四个不同的粒度：

图 1 · 四个粒度：越往下越细，用户核实成本越低

面向业务用户的知识 Agent，建议至少做到 粒度 2 + 粒度 3：能定位到条款，并展示支持结论的原文摘录。涉及资金、合规、赔付等高风险结论时，考虑粒度 4。

两种实现方式

方式一：通过提示词要求模型引用

在组装上下文时给每个片段编号，并在指令中要求模型引用编号：

<source id="S1" doc="退款政策" version="v3" section="4.2" effective="2026-08-01">
已开具发票的订单，应先完成发票作废，再发起退款。
</source>
<source id="S2" doc="发票管理规范" section="7">
已交付给客户的发票，须由客户确认作废后，才能重新开具。
</source>

回答要求：
- 每个事实性结论后用 [S编号] 标注依据
- 引用原文时必须逐字摘录，不得改写
- 如果资料中没有依据，明确说明“未在知识库中找到依据”，不要推测

这种方式通用、灵活，但模型可能编错编号，或者“摘录”时悄悄改了原文。所以必须配合下文的程序校验。

方式二：使用模型平台的原生引用能力

部分模型 API 提供原生的引用功能。以 Claude 为例，官方文档说明：

可以把文档作为带引用开关的文档块传入，支持纯文本、PDF 和自定义内容三种类型。纯文本和 PDF 会被自动切分到句子级，自定义内容则按你提供的内容块作为引用单位，不再细切。
在 RAG 场景中，可以把检索结果作为“搜索结果”内容块传入（直接放在消息中，或作为工具的返回值），每个结果带有来源和标题，模型回答时会自动附上引用。
返回的引用包含被引用的原文和位置信息（字符位置、页码或内容块编号），被引用的原文由 API 直接从文档中提取，因此一定指向真实存在的内容。
被引用原文字段不计入输出 Token。
需要注意：该能力目前不能与结构化输出同时使用。

原生引用解决了“编造引用”和“改写原文”的问题，但 不能保证引用的内容真的支持结论。模型仍可能引用了一段真实存在、却与结论不相干的原文。

引用存在，不等于引用正确

引用的校验可以分成三层，从便宜到昂贵：

图 2 · 引用存在，不等于引用正确：三层校验从便宜到昂贵

第 1、2 层应该在线上每次都执行，失败时拦截或降级（例如去掉该结论、提示“未能核实”）。第 3 层通常用于离线评测和线上抽检，对应 RAG 效果评估中的“忠实度”指标。

从文档到界面

不只是文档：工具数据也需要可追溯

Agent 的结论往往同时依赖知识和实时数据。“ORD-1024 退款失败是因为发票未作废”这一结论，依据是 订单系统在某一时刻返回的数据 加上 某份政策的某一条。两者都应该可追溯：

**结论**：ORD-1024 退款失败，原因是订单已于 9 月 10 日开具发票，但发票尚未作废，退款单被系统驳回。

**依据**
1. 订单系统（查询于 2026-09-17 10:32）：已开具发票 INV-2291，开票时间 2026-09-10，状态“有效”
2. 退款记录（查询于 2026-09-17 10:33）：退款单 RF-88120 状态为“已驳回”，错误码 E-4031
3. 《退款政策》v3 §4.2：“已开具发票的订单，应先完成发票作废，再发起退款”

**建议**：先作废发票 INV-2291，再重新提交退款（需售后主管审批）

证据如何在界面上呈现，参见证据与可解释。

界面上的引用设计

就近展示：引用标记紧跟在对应结论之后，而不是在文末堆一个“参考资料”列表。
悬停或展开即见原文：不需要跳转就能看到摘录；需要时再打开原文并定位到具体位置。
显示版本与日期：让用户一眼看出引用的是不是最新规则。
区分“有依据”和“推断”：Agent 基于多条依据做出的推断，应该标明是推断，而不是伪装成原文结论。
找不到时坦诚说明：“知识库中没有找到关于试用期订单的特殊规定，以下是通用规则”比强行给出答案更有价值。

常见误区

“有引用就说明答案可靠。” 引用可能真实存在但与结论无关，或者引用的是过期版本。引用要校验，不只是展示。
“引用越多越好。” 每句话挂五个引用，用户根本不会看。只为关键结论提供最直接的依据。
“让模型自己写出处就行。” 不加校验的提示词引用会出现编号错误、改写原文甚至编造出处。至少要做程序层面的存在性校验。

产品经理检查清单

引用做到什么粒度？高风险结论是否要求原文摘录？
使用提示词引用还是平台原生引用？与结构化输出是否冲突？
线上是否校验引用的存在性、版本与权限？失败时如何处理？
是否定期评估“引用是否支持结论”？
实时数据类依据是否记录了来源系统和查询时间？
找不到依据时，Agent 的回复和界面表现是什么？

练习

为公司知识库 Agent（贯穿项目 02）设计引用方案：

写出组装上下文时每个片段的格式（包含哪些属性），以及指令中关于引用的要求。
准备 5 个问题及回答，其中故意制造 2 个“引用存在但不支持结论”的错误，请一位同事尝试找出来，记录他花了多长时间。
画出答案界面的草图：结论、引用标记、原文摘录、版本日期、“未找到依据”的状态。

下一步

引用会暴露一个现实问题：引到的规则是不是最新的？这个用户能不能看？下一课「知识保鲜与权限」专门讨论这两件事。

引用与可追溯