生产环境中的 LLM 给出了一个错误的答案。一张支持工单到来。你翻查日志，只看到提示词、补全内容和延迟指标——却没有任何信息说明检索系统到底拉取了哪些文档、哪些块进入了上下文窗口，或者模型在综合答案时最依赖的是哪段内容。你只能像做考古一样：重新对一个已经更新过的语料库跑一次查询，祈祷结果还和之前一样，同时不知道问题究竟出在检索、分块、文档本身还是模型推理上。
这就是数据溯源的缺口，而大多数 AI 团队直到掉进去才意识到它的存在。
溯源——记录输出结果的完整来源链——在数据工程领域并不是新概念。数据管道多年来一直在追踪数据血缘，因为下游消费者需要知道数字的来源，才能信任和调试它们。同样的逻辑适用于 AI 系统，但故障模式更为严重：数据库返回一个过期值令人恼火；而语言模型从过期或相互矛盾的来源中自信地综合出一个答案，则是一次信任危机事件。
三个需要溯源来解决的核心问题
工程师往往把数据溯源视为合规话题——某个法律团队在产品出货到欧洲之前才会提的需求。这种定位过于狭窄。溯源实际上解决三类截然不同的问题，而其中只有一类是监管要求。
调试：当基于 RAG 的功能给出错误答案时，故障可能潜伏在任何地方。检索模型可能拉取了无关的块；这些块可能被正确检索，但来自一个本身就有误或已过时的文档；模型可能忽略了好的证据，却依赖了较弱的检索文本。如果不知道每个响应对应的具体情况——检索了哪些源文档、哪些块实际进入了上下文窗口、模型生成答案时在关注什么——你就无法区分这些故障模式。没有这条链，调试就是猜谜。
合规：《欧盟人工智能法案》第 10 条对高风险系统的要求将于 2026 年 8 月生效，明确要求记录 AI 训练数据的溯源文档。GDPR 的透明度义务覆盖范围更广：对于任何处理个人数据的 AI 系统，组织必须能够回应数据主体访问请求，具体说明系统接触了哪些数据、何时接触、用于何种目的。对于自主调用工具、在一个会话中跨步骤摄取数据的智能体系统，监管机构现在要求提供执行轨迹——涵盖每个被观察的数据类别、每次工具调用、每次状态更新的持久化、可检索记录。"我们运行一个 LLM"不是能回答第 15 条问题的答案。
信任：AI 功能用户采纳率的实际天花板，往往不是整体准确率——而是用户第一次发现一个自信表述的幻觉的那一刻。带引用的响应直接解决了这一问题，给用户提供了验证声明的途径。但引用只有在准确的前提下才有帮助：引用一个并不包含所声称信息的文档，比没有引用更糟糕，因为它制造了接地的表象，却没有实质。溯源基础设施使得在向用户展示引用之前先验证其准确性成为可能，而不是信任模型自我报告。
推理时溯源的真正含义
训练数据血缘（追踪哪些来源构成了模型权重）和推理时溯源（追踪哪些来源促成了特定响应）之间存在重要区别。两者都重要，但它们存在于不同的系统中，需要不同的埋点方式。
训练数据血缘是模型治理问题。它涉及来源注册表、转换日志和数据集版本控制——与模型构建者以及需要证明训练数据依法获取、准确记录的受监管行业相关。大多数部署第三方基础模型的产品团队在这里的可见性有限，只能依赖模型提供商的披露信息。
推理时溯源是产品工程问题。每个在 LLM 之上构建的团队——无论通过 RAG、工具调用还是多步骤智能体——都可以且应该拥有这一层。它需要对每个面向用户的响应追踪：
- 哪些文档或数据源是候选项（已检索但不一定被使用）
- 哪些块被包含在上下文窗口中
- 哪些源标识符出现在模型输出中或影响了最终答案
- 每个来源在检索时的时间戳和版本
这一层是团队可以掌控的，也是调试和信任问题真正得以解决的地方。
血缘标记模式
推理时溯源的基础是随每个块在管道中流动的元数据。当你索引一个文档时，每个块至少应携带：
- 一个稳定的来源 ID（与文档绑定的哈希值或标识符，而非其位置）
- 一个版本或时间戳，表明文档最后修改的时间
- 一个位置引用——URL、文件路径或数据库记录 ID
- 一个块跨度——在源文档中的字符或章节偏移量
当检索查询运行时，系统记录返回了哪些源 ID、排名顺序，以及哪些被包含在最终上下文中。当模型生成响应时，系统记录哪些源 ID 存在于它被给予的上下文中。
这种模式不要求模型引用任何东西。它在基础设施层面被动记录溯源，无论模型说什么都会执行。这是关键洞察：你不希望溯源依赖模型的自我报告，因为模型会误归因。你希望管道维护一条监管链，能够在不重新运行推理的情况下重建"这个答案生成时哪些内容在范围内"。
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- 完整文章，包含未公开存档的部分
- 可落地的工作框架，附带权衡与决策依据
- 新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部