当大模型应用从“能回答”走向“能决策”，系统对答案来源、数据流转路径和中间推理步骤的可解释性要求急剧上升。数据血缘（Data Lineage）正在从传统数据治理领域的一个技术概念，演变为 RAG 与 Agent 架构中不可或缺的基础能力。本文基于现有公开技术认知展开讨论，不涉及具体产品版本与实测数据。

一、从“检索增强”到“决策链路”：问题变了

RAG（Retrieval-Augmented Generation）早期的核心命题是“让模型答得更准”。典型链路是：用户提问 → 向量检索 → 拼接上下文 → LLM 生成。这条链路相对线性，关注点集中在召回率和生成质量。

但当 RAG 与 Agent 结合后，链路形态发生了根本变化：

多跳检索：Agent 可能先检索一次，根据结果决定是否再检索、检索什么。

工具调用：Agent 会调用外部 API、数据库、代码执行环境，产生新的中间数据。

多轮决策：每一步的输出都可能成为下一步的输入，形成有向的依赖图，而非一条直线。

多源融合：最终答案可能同时来自向量库、结构化数据库、实时接口和模型自身参数知识。

链路一旦变成图，一个直接问题就出现了：最终输出的这句话，到底是从哪来的？中间经过了哪些加工？如果它是错的，错在哪一环？

这正是数据血缘要回答的问题。

二、数据血缘是什么，为什么在 LLM 场景下更棘手

在传统数据工程中，数据血缘描述的是数据从源头到消费端的流转路径：表 A 经过 ETL 变成表 B，表 B 又被报表 C 引用。它通常是静态的、基于 SQL 解析和元数据管理的。

在 RAG 与 Agent 场景中，血缘的形态发生了变化：

粒度更细：血缘不再只到“表”或“文档”级别，而需要到 chunk、段落甚至句子级别。

动态生成：检索路径和工具调用顺序是运行时决定的，血缘图无法完全预先静态定义。

语义参与：中间步骤包含 LLM 的生成与判断，血缘不仅要记录“数据从哪来”，还要记录“模型基于什么做了这个决定”。

跨模态：文本、向量、结构化字段、工具返回结果混合在一起。

依据现有技术认知判断，这意味着传统血缘工具难以直接套用，需要在应用层重新设计血缘采集与表达机制。

三、数据血缘在 RAG 链路中的关键作用

1. 可追溯性：让每个答案都有“出处”

RAG 的一个基本承诺是降低幻觉。但“有引用”不等于“引用正确”。血缘能记录：

最终答案的每个片段对应哪个检索 chunk；

该 chunk 来自哪个文档、哪个版本、哪个数据源；

检索时的相似度分数与过滤条件。

这样，当用户质疑答案时，系统可以回溯到具体证据，而不是只给一个笼统的“根据知识库”。

2. 可调试性：定位是检索错还是生成错

RAG 出错时，常见归因有两类：检索没召回正确内容，或召回了但模型没用对。血缘把这两段分开记录后，排查效率会显著提升——可以判断问题出在检索阶段、上下文拼接阶段，还是生成阶段。

3. 可评估性：为评测提供结构化依据

离线评测往往只看最终答案对错。有了血缘，可以进一步评估检索命中率、上下文利用率、引用准确率等中间指标，让优化有抓手。

四、数据血缘在 Agent 决策链中的关键作用

Agent 比 RAG 更复杂，因为它会“做决定”。血缘在这里的价值体现在三个层面：

1. 决策可解释

Agent 的每一步动作（调用哪个工具、传什么参数、是否继续）都应有依据。血缘记录“这一步基于上一步的哪个输出”，使决策链可被复盘。

2. 错误传播阻断

在多步链路中，早期一步的错误会被后续步骤放大。血缘能帮助识别错误首次出现的节点，而不是只在最终输出处发现问题。

3. 权限与合规

Agent 可能访问多个数据源，其中部分数据有访问限制。血缘可以辅助判断：某个输出是否间接使用了不该被使用的数据，从而支持合规审计。

Agent 场景下的血缘采集难度高于 RAG，因为工具调用和运行时分支使链路高度动态，需要框架层面的埋点支持。

五、落地时的几个现实挑战

性能开销：全量记录血缘会增加延迟和存储成本，需要权衡采样粒度。

标准化缺失：目前 LLM 应用层的血缘表达尚无统一标准，不同框架各有一套。

动态链路的表达：如何用图结构稳定表达运行时才确定的检索与工具调用路径，仍是工程难点。

与可观测性体系的融合：血缘需要和日志、追踪（tracing）、指标结合，才能形成完整的可观测能力。

结论

RAG 与 Agent 让大模型应用从单点生成变成了复杂链路。链路越复杂，“这句话从哪来、这个决定凭什么做” 就越难回答。数据血缘正是回答这个问题的机制。它不只是治理工具，更是 RAG 与 Agent 走向可信、可调试、可合规的基础设施。对于正在构建这类系统的团队而言，尽早把血缘纳入架构设计，比事后补救更划算。

生成标记：本文由 ITPUB 文章生成平台基于已选素材整理生成。