AI应用跑起来以后，数据就不只是"文件"了。一份合同进了系统，会被解析、切片、打标签、生成摘要、向量化，最后变成知识单元喂给RAG和Agent。问题来了：大模型给出的答案里引用了哪个文件的哪一段？Agent做的决策依据是哪条数据？数据从原始文件到最终生成结果，中间走了多少道加工，每一步谁干的、用了什么模型？

传统血缘管理只管文件来源和版本，管不了这条链路。多模态非结构化数据血缘治理要回答三个问题：数据从哪里来、经过了哪些治理与处理、被哪些应用使用了。血缘管住了，数据才敢交给AI。

一、数据来源追溯：数据有身份，来源可追溯

数据来源追溯是血缘体系的起点。平台记录每个文件及内容对象对应哪个业务系统、哪个应用单元，覆盖OA、ERP、MES、邮箱、网盘、扫描件等来源。上传人、上传时间、修改人、修改时间这些责任信息也一并记录，形成完整的来源主体链路。

采集层面，采集平台、SDK、CLI、接口服务和操作日志都纳入统一管理。文本、图片、音频、视频、图纸——每种多模态数据进入平台的瞬间就建立唯一身份和来源关系。后续治理、加工、调用，全链条都有据可查。

一句话：数据进平台的第一件事，不是存，是记账。

二、数据治理追溯：从文件到知识，步步都留痕

原始文件进来之后，先入内容库或非结构化数据中台，经过标准化治理，再迁移到知识库或高质量知识中台。这中间有移动、复制、更新、版本变化、治理规则执行，还有AI自动治理过程——自动分类、元数据补全、内容摘要、标签生成、知识加工。

平台需要记录每一步操作：哪个文件被加工了，用了什么治理规则，谁发起的任务，执行结果是什么。在AI for Data场景下尤其要记清楚。自动生成的分类、补全的元数据、抽取的标签，都必须能回溯到原始数据和执行条件。做不到这一步，知识数据就成了"生成后不可解释、出错后无法定位"的黑箱。AI给了一个错答案，你连是哪个文件的问题、哪个模型的问题、哪个治理环节的问题都拆不出来。

三、解析处理链路追溯：从解析到图谱，步步可查

多模态数据进AI应用之前，要过一系列解析和处理：文档解析、OCR文字识别、ASR语音转写、多模态理解、摘要生成、元数据抽取、打标签、图谱生成。这些能力不是线性的流水线，而是根据数据类型、治理目标和业务场景灵活组合的编排工作流。

血缘体系要记录每个处理模块的完整信息：输入对象是什么、输出了什么、运行了哪个算法或模型、用了什么参数、执行时间、运行状态、谁发起的。还要关联问答追溯、数据解析处理模块和编排工作流本身。有了这段记录，随便找一个知识单元、摘要或图谱关系，都能反向定位到它是从哪个文件来的、哪个任务跑的、哪个模型生成的。一