数据项目经理哭诉：大模型数据中台上线，数据血缘全失效

引言｜庆功宴散场那天，血缘图先塌了

2026 年 6 月，一家中型零售集团的数据中台完成大模型化升级——向量库、RAG 问答、Agent 编排三件套一次性上线。

庆功会开完不到 48 小时，业务方开始追问一个看似简单的问题：

新客经营指标口径的上游，到底是什么？

项目经理打开血缘图，屏幕上原本密密麻麻的红蓝连线，此刻只剩几个悬空节点，像被砍完的森林。血缘覆盖率从上线前的 92.7% 一路跌到 61.3%。
而跌掉的这三十多个百分点，恰恰都长在新上线的 AI 资产上。

一、事故切片｜血缘图从满屏红线变成孤岛

事故不是一次爆发，而是分三天渐次显形。

第一天，标签口径开始漂移。同一个“高潜新客”人群，昨天圈出 8 万人，今天变成 3 万。业务方在群里连问三遍，无人应答。

第二天，RAG 助手回答的毛利率与月报差了 1.8 个百分点。追查发现，向量库前一周做过一次重建，embedding 模型也从 v1
 升级到了 v1.2
——但这些变更，在血缘图上一个字都没有留痕。

第三天，营销 Agent 自主决策发出去几十万张券。风控追问决策依据，血缘图上只有一个孤零零的 agent_run
 节点，四周一片空白。

上线前后血缘拓扑对比（示意）

二、三刀伤｜大模型到底砍掉了血缘的哪几节

把事故拆开看，冲击可以归为三刀。

🔪 第一刀：向量化

传统血缘的最小单元是字段——每个字段的来源、加工逻辑、下游依赖，都可以画线追溯。
向量化把十几个结构化字段一次性压成一列 768 维或 1536 维的浮点向量，输入端多对多，输出端只剩 embedding
 一列。
字段级血缘，从物理上就画不出来了。

更棘手的是，同一批原始数据在不同模型版本下压出来的向量并不一致。血缘系统必须额外记录模型指纹与生效窗口，而这两个栏位在多数血缘平台里根本不存在。

🔪 第二刀：RAG

传统报表的上游是静态写死的 SQL。
RAG 则不同——每次问答由检索器从向量库里实时挑选 top‑k 片段。同一张“问答报表”的上游，每一次响应都可能不同。

血缘到底该记录设计时的理论范围，还是每一次运行时的实际路径？在多数团队里，至今没有明确答案。

🔪 第三刀：Agent

Agent 一次调用可能跨越 SQL、HTTP、gRPC、模型推理与条件分支，每一次运行路径都由上下文动态决定。
传统父子链式的血缘拓扑，撑到第三层就会断裂——血缘从一条链，被彻底炸成一张动态网。

大模型对血缘的三刀冲击（结构示意）

三、老三样为何失灵｜不是工具不行，是战场变了

事故之后，很多团队第一反应是找工具。但过去十年赖以生存的三条老路，在这里都走不通了。

血缘采集能力矩阵（覆盖度示意）

四、四步补救｜先止血，再续命，后升级，终立规

面对系统性失效，需要分阶段、有节奏地重建能力，而非一蹴而就。

四步补救时间线（12 周甘特示意）

结尾｜血缘不会消失，只会换一种形态

大模型不是数据血缘的终结者，而是把血缘推入下半场——
从记录 SQL 语法，走向记录语义、模型指纹与运行时上下文。

真正能穿越这轮技术切换的团队，往往具备三个共同点：

立项即血缘 · 上线即签字 · 季度即审计

本周就能落地的三件事

1. 盘家底：列清所有 AI 资产，逐条打勾血缘是否可追；
2. 划红线：把 MVL 六项写入下一次立项模板；
3. 开复盘：把最近一季度的争议事件全部翻出来，逐条追问：

   若血缘完整，此事是否会不发生？

一个思考题留给同行

未来三年，血缘会消失，还是会长成 AI 系统的神经系统？

#数据血缘     #大模型     #RAG     #Agent     #数据治理     #元数据管理