本文为工程实践复盘，客户信息已脱敏；所述数据均为示意值，不对应任何具体合同或审计数字。

一、项目背景

我们接手一家集团的数据中台治理时，最直观的感受是"表太多、名太乱、血缘太糊"。数仓里有上千张表，字段命名五花八门，大量表没有业务描述，分析师要取一个数得先找熟人问"这张表是干嘛的、哪个字段是金额"。血缘靠人肉维护，ETL 改一处没人同步，久而久之没人敢信。传统治理靠数据管家逐表补元数据，进度慢、覆盖低，半年才补全不到一成，而且管家一忙就停摆。我们尝试用大模型辅助：让它读表结构、推断业务含义、自动补元数据与血缘，把人从重复劳动里解放出来，只做高价值判断。我们的定位很明确——模型是"初稿生成器"，人是"终审"，不是全自动替代。

二、落地场景

我们搭了一条"大模型辅助治理"流水线：扫描元数据仓库的表与字段，把建表语句、字段名、样例值、注释喂给模型，生成业务描述、标签、敏感等级建议，并基于 SQL/ETL 脚本推断上下游血缘。生成结果先进入"待审核"区，按模型置信度排序，高置信的自动入库、低置信的推给数据管家确认。治理看板汇总元数据完整率、找表平均耗时、血缘准确率等指标，让治理进度可见、可汇报。整个过程不改动生产数据，只在元数据层操作，安全边界清晰；生产链路的表结构与数据纹丝不动，模型只读元数据与样例，不碰真实业务数据。

三、关键技术挑战与解决思路

第一个难点是表结构语义理解。很多字段名是缩写或无意义拼音，单看名字模型也会懵。我们把"字段名+类型+样例值+邻近字段"一起作为上下文，并引入企业业务术语表做对齐，让模型把 amt_tot 之类映射到"订单总金额"而非字面猜测。第二个难点是元数据补全与校验。模型生成的描述先和已有术语表、历史工单对齐，冲突项标红而不是覆盖，避免以错纠错。第三个难点是血缘推断与误判。我们从 SQL/ETL 的读写关系抽取上下游，对跨库、动态 SQL 这类难推断的标注低置信，交由人工补。第四个难点是人在回路。我们不做全自动入库，而是把低置信项加权排到管家待办最前，让有限的人力只花在"模型拿不准"的地方，而不是平均分配到所有表上。

案例片段（已脱敏）：元数据补全的提示与输出结构片段：json {  "table": "dwd_ord_pay",  "suggest": {    "biz_name": "订单支付明细",    "tags": ["交易", "支付", "核心"],    "fields": [{"col": "amt_tot", "desc": "订单实付总金额(元)", "conf": 0.93}]  },  "lineage": {"upstream": ["ods_ord"], "downstream": ["dws_ord_stat"], "conf": 0.81} }

四、效果数据

以脱敏示意口径看：大模型辅助治理把元数据补全率（有业务描述的表占比）从约 12% 提升到约 78%，耗时从人工逐表的约半年压缩到约三周。分析师"找对表"的平均耗时由约 25 分钟下降到约 6 分钟，内部调研显示"找不到表"的抱怨工单下降约 64%。血缘推断的准确率（经人工抽检）约 88%，其中高置信项的准确率约 95%，低置信项通过人工补正后整体可信度达标。数据管家的重复性录入工时下降约 70%，精力转向口径标准与质量规则建设，人均治理表数提升约 4 倍。所有数值均为示意值，不对具体合同负责。

五、可复用经验总结

数据治理先补元数据——连表是干嘛的都说不清，谈血缘和口径都是空中楼阁。模型补全必须结合业务术语表对齐，缩写字段离开上下文就是天书，给足"字段名+类型+样例+邻近字段"上下文才准。血缘要可校验，跨库/动态 SQL 这类难推断的标低置信交人工，别让模型硬编上下游。人在回路不是摆设：把低置信项加权推到管家最前，让有限人力只花在模型拿不准的地方，自动化才有信任基础，也才不会"以错纠错"。

推动上我们花了很多精力在“变革管理”：数据管家最初担心模型抢饭碗，后来发现模型把重复录入做了、自己转向口径与质量，反而更有价值，便从抵触变共建。我们建立了一个正向回路——管家在审核台修正的错误补全，会回流成少量样本去优化提示词与术语表对齐，模型下一轮的准确率随之提升，形成“人纠错、模型进化”的飞轮。治理 ROI 我们也能量化：除了找表耗时下降，更关键的是“因口径不清导致的分析返工”明显减少，这部分隐性成本此前从没人统计。建议任何类似项目都把数据 owner 拉进共建，而不是 IT 单方面推工具；工具再好，没有责任人认领，元数据迟早又会腐烂。我们把“元数据完整率”纳入数据域月度考核后，治理从一阵风变成了持续运转的日常。

我们还把治理看板开放给业务方，让他们能自查“我的表被多少人用、找得到找不到”，把治理从“IT 的事”变成“大家的事”。当业务方自己看到某张核心表居然没有描述、被人反复问，推动补全的动力比任何考核都强。这套“可见即治理”的思路，后来被我们复用到指标口径管理上，效果同样明显，口径争议从扯皮变成了看板上的客观对照。

案例片段（已脱敏）：置信度分流入库片段：python if item.conf >= 0.9:    meta.upsert(item)              # 高置信自动入库 else:    review_queue.push(item)        # 低置信进人工待办 log_governance(item.table, item.conf)