溯源检索税：可信来源的成本
AI Signals & Reality Checks（2026 年 2 月 25 日）
信号
溯源（provenance）正在变成一种产品级刚需——而不只是研究功能——因为“信任”现在首先是一个 UI 问题。
一年前，“加引用（citations）”往往意味着：在文末放几个链接，然后祈祷没人点。
现在的变化在于，团队逐渐意识到一个很硬的现实：在高风险工作流里，用户不信“答案”，他们信“收据（receipts）”。 这正在把溯源从后端能力推到产品表层：要看得见、点得到、能快速核对。
你可以在三个地方看到这种转向：
- 以收据为中心的交互（Receipts-first UX） 输出不再是一坨文本，而是被包装成：
- 一组可枚举的“主张/结论（claims）”，
- 每条主张都映射到证据（evidence），
- 用户一键即可“查看原文片段（show me the snippet）”，
- 以及一个小型的调用轨迹/工具链路图（trace graph）。
这不只是为了合规。更根本的原因是：人希望能以“阅读速度”完成审计。
- 围绕来源的“契约式保证” 越来越多团队把规则写进产品体验本身：
- “只允许从这些知识库/仓库回答。”
- “找不到证据就明确说不知道。”
- “信心不足时，先给出核对清单而不是硬答。”
这其实比“提示词更好”更重要：它是 受限认识论（scoped epistemology） 的开始——模型被允许知道什么，被要求展示什么证据，边界开始清晰化。
- 可追溯性正在成为差异化卖点 当多个产品在“生成文本”上都已足够好时，溯源会成为决胜因素。胜出的不一定是底座模型最聪明的系统，而是能解释清楚的系统：
- 用了哪个数据集/哪个版本，
- 应用了哪些策略约束，
- 为什么执行（或拒绝执行）某个动作。
这里的市场信号很简单：信任正在被产品化。
现实校验
溯源不是免费的。你会为它支付“检索税（retrieval tax）”——体现在延迟、成本和用户体验上；而且很多引用系统只是在制造“看起来被 grounding 了”的幻觉，并没有真正的保证。
三个坑会很快出现：
- 检索税是真实存在的 每一个“收据”功能都会增加开销：
- 更多的检索调用，
- 更多 token 用于引用、结构化与对齐，
- 更多 UI 组件，
- 更多边界情况（重复来源、文档冲突、页面过期）。
实际落地时，团队会发现：不可能以同样强度为所有内容提供同级别的溯源。更合理的设计通常是分层：
- 低风险：轻量引用；
- 中风险：主张→证据映射；
- 高风险：强制“无证据不作答” + 人工审批。
- 引用很容易变成“舞台效果” 引用的 UI 可能看起来很可信，但仍然会误导：
- 片段是真的，但并不支持主张；
- 片段只是在旁边擦边，结论是编出来的；
- 模型挑一行支持自己的句子，却忽略了相反证据。
如果你希望溯源真的“算数”，需要可度量的规则：
- **证据覆盖率：**有多少主张被证据支持？
- **支持正确性：**片段是否真的蕴含该主张？
- **冲突处理：**当来源相互矛盾时系统如何表现？
否则你交付的是“信任氛围（trust vibes）”，而不是信任。
- 只有可追溯性、没有可问责性，意义不大 再漂亮的 trace graph 也只是日志，除非你能回答：
- 这个工作流谁负责？
- 允许哪些动作？回滚触发条件是什么？
- 哪些可以自动审计，哪些必须抽样/人工复核？
最有效的落地模式往往很朴素，但很管用：
- 定义少量主张类型（事实、建议、动作），
- 对事实与任何不可逆动作强制要求证据，
- 当证据缺失或冲突时设置升级路径。
**结论：**溯源正在成为应用型 AI 的“安全带”——用户会默认它存在。但安全带只有在被工程化、被测试、被强制执行时才有用。如果你不为检索税做预算，也不审计“支持质量”，引用会变成下一个看似必要、却在压力下悄然失效的勾选项功能。