在政务数据治理项目里，最花时间的一环从来不是搭平台，而是让十几个部门坐到一起承认一件事：这些叫法说的其实是同一个东西。

一个"法人"，发改部门叫"法人单位"，市场监管叫"企业主体"，税务系统里是"纳税人识别主体"，到了某个老旧业务系统里，它干脆就叫"客户"。数据治理的人一半精力耗在这种"翻译"上，另一半精力用来解释为什么又得开会。

数据标准就是干这件事的——把散落各处的叫法收敛成一本大家认账的账本。而这本账怎么记、谁来记、记错了怎么办，过去十年基本靠人力硬扛。这篇讲的是我们在一省级政务数据治理项目里的做法：把大模型放进术语生成这条生产线，在可控的前提下把效率提上去。

一、政务数据标准为什么难在术语上

企业做数据标准，难在部门墙；政务做数据标准，难在墙更多、还分等级。

企业内部大不了老板拍板，政务场景里每个委办局都是一个独立法人主体，各自有上级主管部门、各自有行标要遵循、各自的系统建设年代不同。于是出现三个结构性问题：

第一，条块分割，各建各的词表。 每个部门都能拿出自己的一份数据集标准，格式不一、粒度不一、定义不一。你想做一个跨部门的口径，先得把十几份标准读一遍，读完发现它们之间根本没有映射关系。

第二，四层标准并存，互相不打电话。 国标、行标、地标、部门内部规范，四个层级同时有效，但彼此之间缺少对照表。同一个业务概念，国标里有个抽象定义，行标里有个业务口径，部门规范里有个字段级规定——三者指的是不是同一件事，没人说得清。

第三，历史遗留的名字毫无规律。 早期系统受字段长度限制，命名全靠拼音首字母和英文缩写。FRMC、QYMC、ZTDM 这类字段，光看名字猜不出业务含义，只能翻数据字典、翻代码、问当年的人——而当年的人可能已经调岗了。

把这几层标准摊开看，各自的定位和难点其实很不一样：

有句话说得好：标准之争，争到最后不是技术问题，是谁的定义算数的问题。所以做数据标准这件事，技术只占三成，剩下七成是组织协调。

理解了这一点，才能理解为什么"把大模型接进来"这件事，价值不在省人力，而在于把可讨论的对象先摆到桌面上——让会议的起点从"你觉得该叫什么"变成"这几条候选你选哪个"。

二、人工编标准的三个天花板

先说清楚传统做法为什么撑不住，才好判断技术方案该补哪一块。

成本天花板。 一个中等规模的省级政务数据治理项目，核心业务术语量普遍在 2000 到 5000 条之间。人工做法是一组 3 到 5 人的标准编制小组，配若干业务专家，逐条梳理、开会讨论、形成文档、征求意见、再修改。一轮下来，六个月是乐观估计。而且这只是第一版。

一致性天花板。 编制小组里每个人负责一部分领域，各自对"同义"的判断尺度不同。A 认为"法人单位"和"企业主体"可以合并，B 认为法人的外延更大不能并。结果同一份标准里，同类问题的处理方式前后不一致——这种不一致比漏收更难发现，因为它不影响使用，只影响信任。

时效天花板。 标准编完就静止了。业务系统在改、新的业务场景在长，而标准文档一年修订一次。等到下次修订，前面漏掉的术语已经变成了事实上的通行叫法，标准反过来要追认现实。

三个天花板叠在一起，就是很多人对数据标准的真实感受：投入很大，用时很短，改起来很慢。

三、技术路线：把大模型放进术语生产线的五个工位

我们的做法不是让模型"写标准"——那既不现实也不安全——而是把它拆成五个具体工位，每个工位只干一件可验证的事。

3.1 语料池：术语藏在哪里

这是整个方案的起点，也是最容易被低估的一步。很多人以为术语都在元数据里，其实元数据只提供"名字"，不提供"同义词"。

真正有价值的语料分三类：

• 结构化语料：数据库元数据、DDL、字段注释、数据字典、接口文档。作用是拿到"术语的候选集合"和字段级上下文。
• 半结构化语料：历史标准文本、数据治理规范文件、业务调研纪要。作用是拿到"官方定义"和"已经达成过的共识"。
• 非结构化语料：业务工单、办事指南、政策文件、系统操作手册。作用最大——同一件事在不同业务文档里的各种口语说法，才是同义词的富矿。字段注释里只有"法人单位"，业务指南里才会同时出现"企业主体"“经营主体"“市场主体”。

做法上，把三类语料统一抽成文本、按业务域分桶、保留来源出处。每一段语料都要能回溯到原始文件和位置，这是后面"不许模型凭空造"的前提。

3.2 候选抽取：规则先筛，模型后判

不要一上来就全交给模型。政务语料的规整度比想象中高，规则能便宜地筛掉一大半噪音。

规则层负责三件事：

• 后缀词匹配：编号、代码、名称、日期、金额、状态 结尾的字段名，大概率是术语。
• 词表命中：已有标准词表、行业通用词表做精确匹配。
• 模式命中：形如"XX（YY）“的括号注释，往往就是"规范名（别名）“的写法。

模型层负责规则干不了的事，具体只让它输出三样东西：

1. 这一段里有哪些术语候选；
2. 每个候选的规范名建议；
3. 一句话定义，并且必须给出语料中的依据片段。

提示词里最关键的是最后一条约束。我们的要求是：没有原文依据的定义，一律不落库。 这一条把模型的发挥空间压得很小，但换来的是结果可审。

1
2
3
4
5
6
7

任务：从给定语料片段中抽取数据术语候选
输出要求（每条必须齐全，缺一不可）：
  术语候选 | 规范名建议 | 一句话定义 | 依据片段(原文摘录) | 置信度(高/中/低)
约束：
  - 依据片段必须是原文逐字摘录，不允许改写或概括
  - 无法在原文中找到依据的，不要输出该条
  - 不要引用任何未在语料中出现的标准编号

3.3 归一化聚类：把三十种叫法压成一个概念

抽出来的候选是一堆散点，下一步是合并同类项。

两条路一起走：

• 语义路径：把候选的"规范名 + 定义 + 上下文"做向量化，按相似度聚类。阈值以上的合并成一簇。
• 规则路径：缩写展开（拼音首字母、英文缩写还原）、别名归一（“管理"与"管控”、“主体"与"单位"这类近义后缀的统一）、全称缩写配对。

聚类完成后，每一簇要选一个主称谓，其余作为别名挂上去。主称谓怎么定？我们的规则是：优先取层级最高的标准里的说法；标准里没有的，取使用频次最高的；频次接近的，交业务专家裁定。

这一步的产出，就是跨部门的"翻译表”——它的实际用途往往比标准文档本身还大，因为开发同事更关心的是"这个字段和那个字段是不是一回事”，而不是定义写得多规范。

3.4 标准映射：对齐国标、行标、地标，且必须回链

术语有了规范名，接下来要回答"它在现行标准体系里对应哪一条”。

做法是把国标、行标、地标文本切分、入库、建立检索。每个候选术语拿去检索，返回最相近的 N 条标准术语和相似度，由人工确认对应关系。

这里有一条铁律：模型不允许生成标准编号，只允许从检索结果里挑选。 原因是这类错误代价极高——一个编造的标准号会被写进正式文件、被下游系统引用，等发现时已经扩散了。宁可标"暂无对应标准”，也不要给一个看起来很像的编号。

无对应标准的情况在政务场景非常常见，尤其是在地方特色业务里。这本身就是有价值的发现：它说明现行标准体系存在覆盖空白，可以反过来作为标准制修订的建议。

3.5 人工确认闭环：让业务拿终审权

整条生产线最后一道闸，是人。但不是让人从头看一遍，而是分层处理：

这个分层比例不是拍脑袋定的，是按"专家每小时能审多少条"倒推出来的：批量勾选每小时能处理两三百条，逐条评审每小时只能处理二三十条。把 15% 的高成本审查集中在真正需要判断的条目上，整体人效能提上来。

关键是最后一句：采纳权在业务部门，不在算法。 我们给业务方的定位是"终审"，给算法的定位是"起草"。这个定位一旦反过来，项目就会变成技术团队和业务部门拉锯——业务部门会质疑每一条，因为他们没有参与决策，只想证明机器不可信。

四、效果与口径：37% 是怎么算出来的

数字必须说清口径，否则就是自嗨。

我们做的评测集是 2000 条人工标注术语，来自该项目四个核心业务域。评测口径是 Top-1 完全匹配——即系统推荐的规范名与专家标注的规范名完全一致才算对，部分一致不计分。

62% 到 85%，绝对提升 23 个百分点，相对提升约 37%——标题里的那个数字就是它。

需要强调的是，这个 62% 的基线不是"人不行"，而是"纯人工在规模化之后必然掉的一致性"。人工在单条术语上的判断质量很高，但到 2000 条量级、跨四个业务域时，尺度不一致带来的损耗会吃掉相当一部分准确率。模型的价值不是比人聪明，是在一万条上和在第一条上表现一样稳定。

同时也要说实话：85% 意味着每 100 条里还有 15 条需要人改。把它当成"减少 80% 工作量"是合理的，当成"替代人工"会翻车。

五、政务场景特有的五个坑

这四个坑加一个坑，是我们在项目里实打实踩到的，跟企业场景差别很大。

第一个坑：数据不能出门。 政务数据涉及公民信息、法人信息、业务敏感信息，绝大多数情况下不允许调用外部 API。这意味着模型必须私有化部署，走内网调用。这一条会直接改掉技术选型——参数量、显存、推理速度、能否用开源模型，全部要按"内网单机/小集群"重新算账。项目启动前先确认这一条，比什么都重要。

第二个坑：模型会"造标准"。 它会把常见的国家标准编号格式学得很像，然后自然地补出一个并不存在的编号。解决办法不是反复叮嘱，而是结构上不给机会——检索之外不给输出通道，落库前校验编号是否存在于标准库，不存在直接拦掉。

第三个坑：长尾术语召不回来。 高频术语抽取效果很好，低频术语（整个语料里只出现一两次的）召回率会明显掉下来。这类术语恰恰可能是某个部门的核心业务概念。补的办法是规则与词表兜底：把各部门上报的词表全部并进来做精确匹配，再用缩写规则做一轮召回。

第四个坑：版本漂移。 模型升级、提示词微调，都会让同一批语料的输出发生变化。政务场景对"可追溯"要求高，今天出的清单和三个月后出的清单对不上，是没法接受的。我们的做法是固定模型版本、冻结提示词、维护一份回归评测集，任何变更先在回归集上跑分，达标才允许上线。

第五个坑：组织阻力比技术阻力大。 最早的一版清单拿去评审，业务部门的反应是"机器生成的，不可靠"。后来我们改了做法：不再展示"系统结论"，而是展示"这几条候选你选哪个"。当人的角色从"审核者"变成"决策者"，接受度立刻不一样了。这不是话术技巧，是权限设计——把最终判断权真的交出去，信任才建立得起来。

六、落地节奏：别指望一步到位

我们的路径是三阶段，供参考：

• 阶段一：打地基（约 1 个月）。 建语料池、抽黄金评测集、搞定私有化部署环境。这一阶段没有可见产出，但决定了后面能不能度量效果。跳过它，后面所有"效果提升"的说法都是空话。
• 阶段二：跑通闭环（约 2 到 3 个月）。 把抽取、聚类、映射、确认四个环节串起来，先在一个业务域里跑通，跑出真实数据再横向复制。不要一上来就铺满所有部门。
• 阶段三：持续运营（长期）。 标准库版本化，业务确认的反馈回流成训练和规则改进的输入。数据标准本质上是个活物，一版定终身是不现实的。

政务数据标准这件事，过去卡在"改不动"和"用不起来"之间。大模型带来的变化，不是让这件事变得简单了，而是让"起草"这一步的成本大幅下降，从而把人的精力腾出来放到真正需要判断的地方——口径怎么定、争议怎么裁、标准体系往哪走。

术语自动生成的定位应该始终清楚：它是起草工具，不是裁判。把它当裁判用，项目会死在信任危机上；把它当起草用，标准编制这件事第一次有了可持续的节奏。