数据血缘（Data Lineage）就是记录一份数据从哪来、路上被谁改过、最后流进了哪些模型和报表的完整链路档案。
打个比方：它像快递的物流记录。一个包裹从卖家发货，经过中转仓、分拣中心、配送站，最后谁签收，每一步都有时间戳和经手人。数据也有自己的物流单——原始网页、用户上传、内部文档，先做清洗去重，再做脱敏和有害内容过滤，然后交给标注团队打标签，打包成训练集，最后喂给某个模型。这条链上的每个节点，就是血缘图上的一条边。
它要回答三类问题
- 向上游查：模型为什么在某些输入上表现异常？训练数据里是不是混进了错误、过时或有偏见的内容？
- 向下游查：某批数据被判定有问题，需要下架或重训，哪些数据集、哪些模型、哪些线上服务会跟着受影响？
- 合规场景：用户要求删除自己的数据，能不能定位到它的所有副本和衍生数据集？
实现方式大致两种。一是人工维护：数据字典、字段映射表、流程文档。二是自动采集：在 ETL（Extract-Transform-Load，抽取-转换-加载）任务和训练流水线里埋点，解析任务依赖关系，自动生成血缘图。前者容易过期，后者前期投入大，但规模一上来基本只能靠自动。
和相邻概念的区别
| 概念 | 关注点 | 它回答的问题 |
|---|---|---|
| 数据血缘（Data Lineage） | 数据从哪来、到哪去 | 这条数据影响了谁 |
| 数据质量（Data Quality） | 数据本身好不好 | 准不准、全不全 |
| 模型版本管理（Model Versioning） | 模型参数与代码 | 这个模型是哪次训练出来的 |
| 数据目录（Data Catalog） | 有哪些数据 | 去哪找数据 |
简单说，血缘管“关系和影响”，质量管“好坏”，版本管理管“模型本身”，目录管“索引”。
对不同人的实际意义
对算法工程师，改一条清洗规则时，能立刻知道要重跑哪些训练任务，而不是靠记忆和口头交接。对平台和运维团队，线上出故障，先看血缘图缩小排查范围，比全链路瞎找快得多。对普通职场人，你在表单里填的信息、上传的照片，可能被用于训练；有血缘记录，才谈得上知情、撤回和追责。对管理层，它是 AI 治理和合规审计的底座——没有血缘，所谓“可解释”“可追责”基本是空话。
最后提醒一句：血缘只记录“事实链路”，不保证数据正确。它能让你快速找到问题，但问题不会自动消失。具体工具支持到什么程度，以官方页面为准。