企业做 AI，为什么应该先治理数据而不是先买模型

企业 AI 的数据治理：治什么、治到什么程度、谁来治

数据治理是企业 AI 项目里最枯燥的一段，也是唯一没有技术捷径的一段。

没有任何模型能自动判断三份价目表里哪一份是现行的——那需要业务知识。所以这一段的工作量，最终一定要落到懂业务的人身上。

问题只在于：治到什么程度算够，怎么让这件事不变成无底洞。

---

先分清三件不同的事

"数据治理"这四个字在企业 AI 语境里，通常混着三件事。它们的处方完全不同。

	治的是什么	谁来做	做不好的后果
内容治理	资料有没有过期、重复、缺上下文	懂业务的人	AI 一本正经地用旧规则回答
结构治理	数据字段的含义、口径、质量	业务 + 数据人员	统计口径对不上，数字互相矛盾
权限治理	谁能看到什么	业务 + 安全	越权信息泄露

大部分项目卡在第一件事上，却在第二件事上投了最多资源——因为第二件事看起来更"技术"，更容易立项。

---

内容治理：四道工序

一、去重

同一份制度可能有三个版本散在不同地方。只留一份有效的，其余移出检索范围（不是删掉，是移出——归档留痕）。

判断哪份有效不难，难在没人认领。所以这一步的前置动作是：给每一类资料指定一个负责人。

二、去过期

明确标注失效日期，或直接移出检索范围。

最危险的不是明显过期的文件（那种一看就知道），而是没有时间标记的文件——它会被当成永远有效。

三、补上下文

这是最容易被跳过、后果最严重的一道。

很多文档只有正文没有背景。一份价目表如果没写：

适用时间段
适用客户类型
是否含税、是否含运费
有没有例外条款

那 AI 检索到之后，会把它当成通用规则回答任何人。这类错误特别难发现，因为回答听起来完全合理。

补上下文的最低要求：每份资料开头加三行——生效时间、适用范围、负责人。这三行的价值超过任何模型调优。

四、拆分混合文档

一份 80 页的手册里可能包含十个不相关的主题。整份塞进去，检索时相关度会被严重稀释——问 A 主题，检索到的是包含 A 但主要讲 B 的那一大块。

按章节、按条款、按问答对拆开，效果的差别是量级上的。

一组可以直接起步的切分参数（不是最优解，是"先跑起来不至于太差"的默认值）：单块 300–800 字，相邻块重叠取块大小的 10–15%，每次检索返回 3–8 块，表格和代码整块不切。每调整一次参数，都要用同一批固定问题重新量一遍四个指标，否则就是在盲调。

---

治到什么程度算够

这是最实际的问题。答案不是"全部治完"，而是：

围绕一个具体任务，把这个任务会用到的资料治干净。

一个可以直接用的验收方法：随机抽 20 份该任务范围内的资料，逐份问业务方两个问题——

1. 这份现在还有效吗？

2. 它适用于什么情况？

两个问题都答得上来的超过三分之二（约 67%），就可以开工了。低于这个比例，先别上系统。

参考区间：答得上来的比例在 80% 以上属于状况良好，可以直接进试点；50%–67% 说明要先补一轮上下文；低于 50% 意味着这批资料本身需要重新梳理，此时上系统只会把混乱放大。

为什么是抽样不是全查：全查的成本太高，而且没必要。抽样的目的是判断整体状况处在什么水平，不是找出每一个问题。

---

三个能提前发现问题的信号

不用等上线才知道治理没做够。下面三个信号随时可以自查：

1. 说不清谁负责更新。

问一圈没人认领，或者答案是"IT 部门"——IT 不懂业务，判断不了哪份文档过期了。这是最强的预警信号。

2. 同一个问题问三个人，得到三个答案。

这说明真相源本身就不统一。资料还没治理，先统一口径。

3. 找不到"现行版本"在哪。

如果业务方自己都要翻半天才能确认哪份是最新的，那 AI 也一样找不到。

---

质量怎么量：分开量，不要混着看

治理做完了，效果怎么判断？必须分开量四个指标，口径直接沿用开源评测框架 RAGAS（docs.ragas.io），不用自己发明：

指标	量什么	低了该修哪里
上下文召回率	该被找到的资料，找到了几成	切分方式或检索策略
上下文精确率	找出来的资料里真正相关的占几成	检索噪声，或资料里混了无关内容
答案忠实度	每句话能不能在资料里找到依据	模型在编，需要加约束和拒答
答案相关性	有没有真的在回答问题	问题理解或提示词

为什么必须分开：答错了到底是"没找到资料"还是"找到了但答歪了"，处方完全不同。混在一起看永远定位不了——这是企业 AI 项目最常见的调试死循环。

关于最后那个"模型在编"：Vectara 维护着一个公开的持续评测（HHEM 榜，github.com/vectara/hallucination-leaderboard），测的是有文档做依据时主流模型的幻觉率——也就是最有利的条件。企业场景通常更难，所以工程上必须有兜底：给出处、答不上时明确拒答、关键结论要求人工确认。

---

权限治理的一条硬要求

如果不同的人权限不同，有一条设计要求必须在开工前定，上线后补不上：

检索必须在权限范围内进行，不能先全量检索再过滤结果。

后者的问题不在于会直接泄露内容，而在于会从回答的措辞里泄露"存在某份你看不到的文件"这个信息本身——比如系统说"关于这个问题我不能回答"，这本身就是信息。

这个要求会影响架构选型，所以属于必须前置的决定。

---

谁来治：一条不能让步的原则

治理工作必须由懂业务的人做，技术方只能提供工具和流程。

常见的错误分工是：把整理资料的活全部外包给供应商。结果是供应商能做的只有格式转换和机械去重，真正需要判断的部分（哪份有效、适用什么范围）他们做不了，最后要么卡住，要么猜着做。

合理的分工是：

企业方：判断有效性、补上下文、指定负责人
技术方：提供治理工具、设计切分与检索策略、搭建评测
共同：定验收标准，跑评测，看结果

企业方要投入的人力必须写进项目预算。这一项最常被漏掉，也最常成为项目延期的原因。

---

治理不是一次性工程

上线那天不是终点。至少要定下来四件事：

谁负责更新：具体的人，有明确时间承诺
多久更新一次：跟着业务节奏，不是固定周期
更新后谁验证：改完要重跑固定测试集，确认没把原来对的改错
用户反馈答错了流向谁：有人接、有时限、修完通知反馈的人

最后一条决定了用户会不会继续反馈。反馈了没下文，第二次就没人反馈了——而用户反馈是质量退化最早、最便宜的预警信号，失去它等于关掉了唯一的监控。

---