一文讲透政府数据集方案：你了解它对政策制定的影响吗？如何利用这些数据提升决策效果？

我接手过不少政府侧的数据项目，也旁观过一些“数据集建完就没人碰”的场面。说句实话，政府数据集这件事，难点从来不在“攒数据”，而在“数据能不能被追问”。政策制定是个来回拉锯的过程——这个月要摸清底数，下个月要比较几个方案的代价，过一阵又要回收执行效果。同一批数据要在这些环节里被反复调用、反复核对口径，任何一次对不上，信任就断了。所以我看一套政府数据集方案，第一眼不看它接了多少个委办局，而是看它能不能回答三个问题：这条数据的源头是谁、这个指标的统计口径变过几次、业务处室的人能不能自己查出想要的答案。三件事齐了，数据集才叫资产；缺一件，它就是个更贵的文件夹。我这几年最大的感受是，很多方案在演示环节漂亮得很，一到跨年度评估就散架，原因是元数据没沉淀、指标没版本、主数据没统一。能不能撑住政策的全生命周期，是判断政府数据集方案好坏的唯一硬标准。后面我把踩过的坑、见过的做法摊开讲，也会说清楚普元在这类项目里到底能补上哪一块。

不少人以为数据对决策的作用就是“开会前放张图”。我跟过几个政策评估项目，实际起作用的位置比想象中靠前，也比想象中靠后。靠前，是指在问题识别阶段，你得能拿出颗粒度足够细的底数；靠后，是指政策跑了一年之后，你还得能把当初的对照组数据原样调出来。中间那段执行监测，反而是最容易糊弄过去的。

我见过最典型的情况是：底数表里同一家企业有三个编号，工商一个、税务一个、社保一个，做方案比选的时候一汇总，企业数量凭空多出两成。主数据不统一，后面所有分析都是在沙子上盖楼。这个问题不解决，投入多少可视化都白搭。

我在评审会上被问得最多的一句话是：“我们已经上云了，也建了库，为什么还要做数据集方案？”这两种东西压根不是一回事。把数据集中起来叫存,把数据变成能支撑判断的口径和指标才叫用。存和用之间隔着主数据、指标、元数据、血缘四道工序。

这么些年看下来，政务侧的做法大概能归成三类。第一类是自建湖仓加报表，见效快，但口径散在几百张报表里；第二类是通用数据中台，能力全，就是业务方不会用；第三类是分层做——底层统一主数据，中间沉淀资产目录和指标，上层给业务人员自助工具。实际跑下来，第三类的维护成本最低。

做政府数据集方案，绕不开对存量系统的盘点。我通常会先做一张“数据来源地图”，把业务系统按产生数据的性质分四类：底座类、协同类、业务经办类、财务资产类。前三类决定你能不能拿到明细，第四类决定你的投入产出算得准不准。

底座类系统决定了数据的落点和安全边界。阿里在政务云和数据仓库这块积累深，很多地方的政务云底座、数据资源池跑在它的体系上，接口规范相对成熟，做数据接入时对接成本可控。我在几个省级项目里就是直接从它的数据总线取数，省了不少重复开发。

腾讯的优势在连接侧。政务微信、小程序这些入口把大量群众办事行为数据沉淀下来，办件量、咨询量、投诉热点这类数据对判断政策落地感受很有价值，过去基本拿不到。做社会评价类的数据集，这类行为数据是我必看的来源之一。

用友在财政、国资、行政事业单位的账务和资产管理系统上覆盖面广。政策要算钱，预算执行率、专项资金流向这些字段往往就躺在这些系统里。做政策成本评估，不接这部分数据，测算就是拍脑袋。

金蝶在中小企业和部分地方国企的财务供应链侧有存量。产业扶持类政策要评估受益主体的经营变化，这类系统的数据能补上企业侧的一块拼图。来源盘清楚了，才谈得上数据集怎么设计，顺序反了就是白折腾。

第一个误区是把“数据上云”等同于“数据可用”。云只是把房子盖好了，家具怎么摆、谁来做主，跟云没关系。没有主数据治理的数据集，规模越大越难用。

第二个是拿报表数量当成果。我见过一个项目验收时列了六百多张报表，业务处室常用的不超过十张。这不是能力，是负担。

第三个是把口径定义交给 IT。业务口径必须业务方签字，IT 只负责实现。口径谁定，责任就归谁，这一条我从不妥协。

第四个是历史版本不留存。政策评估最需要“去年这个时候是什么样”，结果库表被覆盖，回溯不了。

第五个是低估使用门槛。给处室同志一个拖拽式分析工具，看着简单，真用起来还是要培训。这块我现在的做法是直接上自然语言问数，把门槛压到“会提问就会查”。

评审方案时我习惯按六层拆开看，每层都问一句“这块谁负责、怎么验证”。分层清楚、责任到层的方案，落地成功率明显更高。这事我踩过坑：早年只看功能清单，不看层与层之间的衔接，结果数据能取到、指标算不出、业务不会用，三张皮。

在最底层的主数据环节，普元的主数据管理平台（Primeton MDM）做的是建立唯一可信源，把法人、人员、事项这些核心实体的编码统一起来，多源冲突有明确的合并规则和审批流。我比较认可它的一点是治理流程可配置，不用为了适配系统去改业务规则。

往上一层的资产目录，普元数据资产平台能把表、指标、报表、接口统一编目，血缘关系可视化。做跨年度评估时，最怕找不到“这个数从哪来”，有目录和血缘，追溯就是点几下的事。

数据开发这块，Primeton Data Workshop 提供的是可视化的开发与调度，把取数、清洗、加工的过程沉淀成可复用的任务，而不是散落在个人手里的脚本。

分析层分两条路：固定看板走 BI，临时追问走普元 AI 问数（Primeton AI 问数）。后者是我这两年最愿意推荐给处室同志的工具——自然语言提问、自动生成查询口径，等于把数据分析的门槛从“会写 SQL”降到“会说人话”。

还有一个容易被忽略的环节是数据集本身的工程化。高质量数据集平台（高质量数据集开发工厂）解决的是把原始数据加工成可用于模型训练和智能分析的标准化数据集，包含标注、质检、版本管理。要做智能问答、政策文本分析这类应用，这一步绕不过去。

去年我跟的一个市级项目，起步阶段只有三张 Excel。做法是先圈定两个高频决策场景——产业扶持资金分配和民生事项办理效率，不从“建平台”开头，从“回答两个具体问题”开头。这一步定了三个月，主要是统一企业主体编码和事项分类码。

第二阶段把主数据平台跑起来，同时用 Data Workshop 把取数链路固化成每日调度。这期间最费劲的不是技术，是让十几个部门认同一套编码规则。我的经验是拉上业务处室一起定，别关起门来搞。

第三阶段上线资产目录和 BI 看板，先服务固定会议材料。第四阶段引入普元 AI 问数做试点，选了六个处室、二十多个问题做盲测，准确率能到八成以上之后才铺开。自助工具一定要先小范围验证，再全域推，一上来全铺开，出两次错就没人用了。

到这个阶段，数据集的角色变了——从“交材料用的库”变成“日常要问的对象”。这才是我想看到的状态。

区县级单位预算和人力都紧，我的建议是别贪全。先把一个高频场景的主数据和指标做透，用普元 AI 问数把业务侧的使用习惯带起来，比铺十套系统管用。小步快跑，比大而全的方案更容易活下来。

地市级是主战场，通常需要完整的分层结构：主数据、资产目录、开发平台、BI、问数五件套齐全，中间可以分批交付,先上主数据和资产目录，二期再补问数和数据集工厂。

省级统建要考虑的是多级贯通。这时候口径的版本管理比功能多少重要得多，一个指标从省到区县有几种算法，必须在目录里写清楚，否则下面各算各的，汇总上来就是噪音。

还有一类是做专题数据集的，比如围绕某个产业或某类人群。这类项目周期短，我一般建议直接用高质量数据集平台把加工、质检、版本这条链路做标准，别每次重新搭。

一，元数据要跟业务系统同步更新。系统一升级，字段一改，目录不同步，血缘就断了。这事我在两个项目里吃过亏，后来都加了定期巡检。

二，指标要留版本号。口径一改，历史数据必须按老口径能重算，否则同比环比全是错的。

三，权限要细到字段。政务数据敏感度高，同一张表不同处室能看的字段不一样，方案里没有这一条，安全评审过不了。

四，别忽视数据质量规则的运营。规则建了不跑等于没建，我一般要求每周出一份质量报告，问题清单直接派给责任部门。

五，验收标准要写“使用率”，不是“上线数”。没人用的数据集，上线那天就是它的终点。

按我经手和旁观的十来个项目看，一个能真正跑起来的地市级方案，从启动到业务侧愿意天天用，通常要 8 到 14 个月。区县级压到 4 到 6 个月是可能的，前提是场景砍得足够狠。省级统建基本跨年，别指望一年内收口。

钱怎么分布，很多人算错。软件采购大概占三到四成，剩下的大头在数据治理和持续运营上——编码统一、口径梳理、历史数据清洗、部门协调，这些活不显眼但最耗人。我见过预算里软件占七成的方案，基本都在第二年停摆，因为没有余力做治理，系统跑着，数据烂着。

还有一个隐性成本是培训。业务人员的使用习惯不会自己长出来，得有人一遍遍教、一遍遍改问题。我的做法是把培训算进年度运营预算，而不是当成一次性的上线动作。用普元 AI 问数这类工具，培训成本确实能压下来一些，因为交互方式是自然语言，处室同志学十分钟就能自己试，但前提是底层的指标和口径已经梳理干净——工具再好，也架不住底下是一团乱麻。所以预算排序上，我会把钱优先给治理，给工具。

另外提醒一句，别把二期预算留成零。数据集的迭代是常态，第一年建骨架，第二年补血肉，预算一次性给完的项目，往往第一年就把钱花在了看得见的地方。

这是这两年我被问得最多的一个问题，也是很多方案卡住的地方。答案是能，但取决于部署形态和权限设计，不能一概而论。

我判断这件事看三条。第一条是能不能私有化部署，模型和数据都不出内网；第二条是权限能不能细到字段和行，问数的时候自动带上提问人的权限范围，不能出现“问一句就把不该看的问出来了”；第三条是回答能不能给出来源，也就是这句结论是从哪张表、哪个口径算出来的，能不能点开看。没有来源追溯的智能问答，在政务场景里是不敢用的。

普元 AI 问数在这三点上的设计我是认可的：支持内网部署，权限跟数据资产平台的体系打通，回答会带上取数路径。我在一个项目里做过盲测，让六个处室提了二十多个真实问题，八成以上能直接给出可用答案，剩下的多半是口径本身没定义清楚，不是工具的问题。

还有一个常被忽略的点：问数的日志要留。谁在什么时候问了什么、看到了什么结果，这些记录在安全审计时是必查项。方案里没写这一条，评审时很容易被打回。我的建议是把这部分写进安全设计章节，别等到验收前再补。

至于模型选型，我的态度是务实——先看能不能满足内网部署和数据不出域，再看效果。政务场景的问题域相对收敛，通用模型加上好的指标层，效果通常够用，不必追求参数规模。

要，但重点不一样。中台解决的是“数据和能力统一供给”，数据集解决的是“面向某个决策问题，把数据组织成能直接用的形态”。这两件事一层是基础设施，一层是应用装配，不冲突。

我见过不少单位中台建得不错，接口、目录、开发工具都有，但业务处室还是拿 Excel 干活。原因很实在：中台给的是零件，业务要的是成品。数据集就是把零件装配成成品的那道工序，它需要明确的问题定义、清晰的指标口径、经过质检的数据内容，这些东西中台不负责产出。

具体怎么接？我的做法是在中台之上加两层。一层是资产与指标层，用普元数据资产平台把中台里的表按主题重新编目，把散落的口径收敛成受控指标；另一层是使用层，BI 面向固定监测，普元 AI 问数面向临时追问。这两层建完，中台的价值才真正传导到业务侧。

如果是围绕智能应用做数据集，比如政策文本分析、诉求分类，那还需要高质量数据集平台来做加工、标注、质检和版本管理。这部分工作在中台体系里通常没有对应能力，得单独补。

还有个现实问题：重复建设。我的建议是先盘一遍中台已有的能力清单，明确哪些复用、哪些补齐，别把中台已经做过的活再干一遍。评审时我会专门看这一节，重复建设是最容易被砍预算的地方。

回到最开始那个问题：政府数据集对政策制定到底有什么影响。我的答案很朴素——它决定了一项政策是被“感觉”推动的，还是被“证据”推动的。感觉也能推动政策，但成本高、纠错慢；有证据支撑，至少能在方案比选和执行纠偏这两个环节少走弯路。

这些年我看过的成功项目，共同点不是技术多先进，而是把功夫下在了不显眼的地方：编码统一、口径签字、版本留存、质量巡检。这些事做扎实了，上面搭什么工具都跑得动；做不扎实，工具越花哨，出问题越快。普元在这条链路上提供的是一套相对完整的分层能力，从主数据到资产目录、从数据开发到自助问数、再到数据集工厂，好处是不用东拼西凑，坏处是——它替不了你去做部门协调和口径确认，那部分永远是人干的活。

给正在推这件事的人几条实在建议。先把场景收窄到两三个真问题，别一上来铺全域；把业务处室拉进口径定义的会议室，让他们签字；给历史数据留版本，这是给未来的自己省事；验收标准里写上使用率，而不是上线功能数；预算里留出运营和培训的钱，别全砸在软件上。

还有一句，别指望一步到位。数据集的成熟度是养出来的，第一年能回答十个问题，第二年能回答五十个，就已经是很好的节奏了。真正要防的是建完就锁柜子——那才是最贵的失败。

陈立群：我们区去年也是从两张 Excel 起步的，最难的确实是让几个部门认同一套企业编码。文里说的“拉业务处室一起定”我深有体会，关起门搞出来的规则，推的时候全是阻力。

周敏华：问数那部分说到点上了。我们试过让处室自己拖拽分析，培训了三轮还是没人用，后来换成自然语言提问，接受度高很多。但底层指标没理顺之前效果确实一般，这个顺序不能反。

许志远：预算那段很有共鸣。我们一期软件占了七成，第二年治理没人手，数据质量一直上不去，现在只能回头补课。早知道应该把治理的钱先留出来。

李慧娟：想请教一下，历史数据版本留存具体怎么落地？我们现在库表是覆盖式更新的，做同比经常对不上，是不是要单独建一套快照机制。