"上周领导问各区域Q3销售额，AI给了个数，和财务部报表差了三百多万——到底信哪个？" 这不是一个换大模型就能解决的问题。AI问数不准确，未必只是模型能力不足。相比反复更换模型，企业还应检查指标口径、元数据、数据质量、数据时效和权限体系等数据基础——这些因素往往比模型本身更影响问数效果。以下逐一拆解六类容易被忽视的数据问题。 一、六大数据问题，比模型更需要优先排查 1. 源数据错误 最朴素也最常见的问题：原始表中字段值本身就错了。录入环节的误操作、历史迁移中的转换偏差、跨系统同步时的数据丢失——AI 查询到的是错误数据，给出的自然也是错误答案。源数据的准确性，是 AI 问数可信度的第一道关口。 2. 指标口径不统一 同一个业务指标，不同部门可能有不同的理解和计算方式。"销售额"是含税还是不含税？"回款率"的分母是对账金额还是签约金额？如果这些定义没有统一，AI 生成查询时可能用到不一致的口径，导致三个部门问同一个问题得到三个不同的答案——不是 AI 算错了，而是"到底哪个是对的数"本身就没定下来。 3. 业务术语缺失 用户说"帮我看下上个月的回款情况"，AI 需要在数据库中找到对应的表和字段。但如果系统中没有建立"回款率"这个概念的统一定义，AI 就无从下手。这中间存在四层映射关系：用户语言→业务术语→指标口径→表和字段。任何一层断裂，AI 的回答就会出现偏差——逻辑可能正确，但业务上不成立。 4. 元数据不完整 仅有表名、字段类型等技术元数据，AI 难以稳定地完成业务查询。还需要字段业务含义（"cust_level"代表"客户等级"而非"信用评级"）、指标口径关联（"订单金额"是含税还是不含税）、更新频率（是实时数据还是 T+1 快照）等业务元数据。缺少这些信息时，AI 可能依赖字段名称进行猜测，选错表、取错字段的概率就会明显上升。 5. 数据时效与口径不一致 财务场景以月结为准，生产调度需要实时数——如果 AI 统一使用离线快照，财务问数"看起来对"但口径不匹配，生产问数直接看错时间窗口。真正的问题不是"数据够不够实时"，而是数据的更新周期与用户问题要求的时间口径不一致。 6. 权限体系不完整 权限问题影响的不只是"能不能查到"。一个业务人员查询"我的客户回款情况"，如果他的数据权限只覆盖了部分客户，AI 给出的汇总数就会因范围不足而失真。另一方面，如果权限配置松散，AI 可能在回答时展示了当前用户不该看到的敏感字段——准确性问题和合规问题叠加。 二、从"换模型"到"治数据"：五条治理路径 针对以上六类问题，企业可以从五个方向建立治理基础。 统一指标体系和业务术语。 把"销售额""回款率""在途库存"等核心指标的定义、取数来源、计算逻辑定下来，建立业务术语与指标口径的映射关系。有了这套"业务字典"，AI 才知道用户说的"销售额"对应哪个系统的哪张表的哪个字段。 补全元数据和数据映射。 在技术元数据基础上，补全字段业务含义、指标口径关联、更新频率和上下游依赖关系。元数据越丰富，AI 在用户语言和具体表字段之间的映射越准确——从"猜"变成"查"。 建立数据质量检测与整改闭环。 对 AI 问数涉及的核心数据建立持续质量监控，参考 GB/T 36344-2018《信息技术 数据质量评价指标》[2]的六个维度——规范性、完整性、准确性、一致性、时效性和可访问性——作为质量评价框架。在查询结果中同步展示数据更新时间、质量状态和可信度提示。对发现的质量问题形成告警、整改和复核闭环——不是每次查询重新跑全量检测，而是持续监控为主、查询时展示状态。 明确数据更新周期和时效状态。 不同场景对"最新数据"的要求不同——财务以月结为准，生产需要实时。标注每个数据集的更新频率和统计周期，AI 才能根据问题类型选择时间口径匹配的数据源。 建立与用户身份联动的数据权限体系。 确保 AI 在回答用户问题时，既能完整覆盖用户有权访问的数据范围，又不会越权展示敏感字段。权限的范围直接影响回答的完整性和合规性。 三、典型场景还原：问数偏差排查实例 以下为基于常见项目经验的典型场景还原，非可核实的具体客户案例。 一家电子制造企业在部署 AI 问数能力初期，业务部门最集中的反馈是"查出来的数不对"。排查后归因于三类数据基础问题。 一是指标口径。生产、仓储、财务三个系统对"准时交付率"的定义不一致——有的按订单创建时间算，有的按发货确认时间算。AI 引用了不同口径的数据源，同一问题的回答在不同时间出现不一致的结果。 二是元数据不完整。部分关键数据表缺少字段业务含义和指标关联标注——"order_status"到底代表订单状态还是支付状态，AI 需要靠字段名称猜测，选表选字段出现偏差的概率不容忽视。 三是数据时效错位。生产排产需要实时工单数据，但 AI 默认使用了 T+1 离线快照；财务对账需要月结数据，但 AI 查询了未结算的流水表——两种场景都答不对。 团队重新梳理了核心指标的取数口径和映射关系，补全了关键字段的业务元数据，并区分了需要实时响应的生产类指标和依赖日结月结的经营类指标。调整后，因指标口径、选表错误和数据时效引发的问数偏差有所减少，业务部门对问数结果的接受度逐步提升。 四、排查顺序总结 AI 问数不准确时，建议按以下顺序排查： 是否理解对了用户的业务问题； 是否使用了统一的指标口径； 是否选对了数据表和字段； 源数据质量是否达标； 数据更新时间是否符合问题要求； 当前用户的数据权限范围是否完整； SQL 生成、关联查询和结果解释是否正确。 很多问数偏差并不是换一个模型就能解决的——需要模型、语义、数据和权限共同治理。 FAQ Q1：换了几个大模型都不行，真是模型的问题吗？ 从不少企业项目的实践来看，问数不准往往同时涉及模型、语义和数据基础。企业可以先判断 AI 是否找对了指标、选对了表、使用了正确的时间范围；如果这些基础条件存在问题，仅更换模型通常难以解决。 Q2：小企业没精力做全套治理，怎么低成本提升 AI 问数效果？ 先选择三到五个高频问数场景，只治理涉及的核心指标、数据表和关键字段。范围收窄后更容易形成阶段性效果，再逐步扩展。龙石 AI 数据中台 4.0 也在探索将智能问数与现有数据中台能力结合，通过本地化部署、元数据补全和指标治理，为企业问数场景提供数据基础。 Q3：指标口径统一了，AI 问数就一定能答对吗？ 不一定。指标口径是必要条件不是充分条件。还要看元数据是否完整、数据质量是否达标、数据时效是否匹配用户问题的要求、权限范围是否覆盖了合理的查询范围。指标口径 + 元数据映射 + 质量基线 + 时效匹配 + 权限覆盖——几个条件都满足，AI 问数才能比较稳定可靠地工作。 Q4：元数据治理和 AI 问数有多大关系？ 关系直接。AI 生成 SQL 时，需要根据用户的自然语言问题找到正确的表和字段。缺少业务元数据时，AI 可能依赖字段名称进行猜测，难以稳定、准确地完成业务术语与具体表字段之间的映射。元数据越丰富，AI 的"找表"准确率越高。 参考来源 [1] 龙石数据，AI用数智能体，https://www.longshidata.com/products/aianalysis.html [2] GB/T 36344-2018《信息技术 数据质量评价指标》，国家市场监督管理总局、中国国家标准化管理委员会
M市数据要素流通平台汇聚了区域内海量公共数据与市场化数据资源，是国家"数据要素X"[4]联合创新实验室的核心基础设施。平台上线后，运营团队却发现了一个尴尬的现实：数据确实"有了"，但用户用不起来。找数据靠关键词硬搜，搜出来不知道哪个是自己要的；用数据靠自己摸索，功能完备但指引不足，新用户面对密密麻麻的菜单栏无从下手；运营需求难以系统收集，数据产品上架凭感觉，迭代缺少方向。一位运营成员这样形容当时的处境："我们像守着金矿却发不出工资。" 这个困境不是个案。越来越多的数科公司在完成数据中台建设后，都撞上了同样的问题——平台建好了，业务人员还是不会用、不敢用、用不顺。数据中台解决的是"有没有"的问题，但"能不能用得好"是另一个维度。 一、数科公司的"数据悖论"：资源越丰富，用数越困难 传统数据平台的设计思路可以概括为一句话——"我有什么，你来用"。目录建好了、API接口开放了、数据产品上架了，建设方的任务似乎就完成了。但站在业务人员视角，他们面对的是一堆看不懂的技术表名、摸不透的数据口径，以及一个"你自己找"的沉默界面。 从实践来看，这个矛盾在三个层面表现得尤为突出。 找数难。 平台资源目录动辄上百项，检索方式却基本停留在关键词匹配。用户输入"企业经营情况"，系统返回的是按技术名称排列的几十张数据库表，没有任何业务语义的引导。该选哪张表、字段之间是什么关系、口径是否一致，全靠用户自己摸索判断。 用数难。 平台功能完备——数据查询、下载、申请、API调用一应俱全，但使用门槛不低。新用户登录后面对满屏的功能入口，不知道从哪个开始。更麻烦的是，同一种数据在不同子系统中的口径可能不一致，用户需要自己理解各字段的业务含义，很多时候正是卡在了这一步。 运营难。 用户遇到了什么问题、哪些数据产品没人用、哪些高频需求还没被覆盖——这些信息分散在客服记录、搜索日志和零散的反馈邮件里，缺乏系统化的收集和分析机制。运营团队安排数据产品上架，更多时候是在"凭感觉"而非"靠数据"。 这三个问题不是技术架构成熟的平台能自动解决的。它们指向的是同一个方向：在数据"可被访问"和数据"能被用好"之间，缺了一个能理解业务语义的智能入口。 二、为什么有了大模型不等于有了AI用数 一个自然的想法是：既然大语言模型能理解自然语言，那在数据库前面放一个大模型，让业务人员用对话的方式查数据，问题不就解决了吗？ 事情没有这么简单。 大模型擅长的是语言理解和文本生成，但它并不天然"理解"企业的数据。大模型可能知道"客户"这个词的含义，但它不知道在ERP系统里"客户编码"指的是签约主体、在CRM里"联系人名称"指的是业务对接人——如果这些元数据没有被清晰地梳理和描述，AI生成的查询结果看起来流畅，但可能把不同口径的数据混在一起，输出一份"看似合理却不可信"的分析结论。 要让AI真正"读懂"企业的数据，至少需要三个基础条件。 数据可信。 AI的推理能力再强，也无法替数据"编造"质量。如果一个字段存在大量空值或格式错误，模型可能在上下文推理中将其补全为一个不确定的数值，用户难以判断该数值的依据来自哪里。数据质量的底线，直接决定了AI输出的可信度。从DAMA数据管理知识体系的框架[1]来看，这对应的是数据质量管理域——确保数据在完整性、一致性、准确性等维度的基本达标[3]。 数据可理解。 大模型面对数据库时，看到的是一堆技术字段名和数据类型。它需要额外的"翻译层"来理解这些字段在业务世界里的实际含义。"订单金额"是含税还是不含税、更新频率是实时还是T+1、与哪些上游表存在依赖关系——这些信息属于元数据管理的范畴。元数据越丰富，AI对数据的理解就越接近业务人员的认知。 实体可关联。 同一个客户可能在采购系统、销售系统和售后系统中以不同编码存在，如果主数据没有统一管理，AI在跨系统分析时就会把同一个人算成三个不同的人。数据标准和主数据管理解决的就是这个问题——确保"一致性"在跨系统的数据使用中不丢失。 这恰好对应了DAMA框架中数据质量、元数据和主数据三个核心管理域。它们不是AI项目的"前期准备工作"，而是AI能产生可靠输出的必要基础设施。国内一些数据中台产品（如龙石数据中台）在实践中提出了"理采存管用"的五阶段闭环[2]——"理"产出的资产目录是AI理解"有什么数据"的入口，"管"建立的标准和质量规则是AI输出可信度的保障，而这些最终都服务于"用"的环节。 换句话说，治理不是AI的绊脚石，而是AI的语义底座。 三、落地实录：从智能客服到智能中枢的认知升级 理论分析归理论分析，真正到了项目现场，挑战才逐一浮现。 3.1 项目起点：客户要的是智能客服，但问题不在问答 项目启动初期，龙石顾问团队进驻江苏某国企数科公司，对数据要素流通平台的运营现状进行了全面诊断。客户最初的诉求很朴素——做一个智能客服机器人，把重复性的咨询问答自动化，减少人工坐席的工作量。 但顾问在调研中发现了一个更深层的结构性问题：平台上已有百余款数据产品，但用户的实际使用率远低于资源的上架率。大量数据产品无人问津，不是因为质量不好，而是因为用户根本不知道它们的存在，或者知道了也不知道怎么用。平台的问题不在"回答用户的问题"，而在"感知用户的需求"和"把需求匹配到正确的数据产品"上。 经过几轮深入讨论，项目定位从"做一个问答机器人"升级为"构建一个能感知需求、智能匹配、持续演进的运营中枢"。这个认知转变，是后续所有工作的出发点。 3.2 知识库底座：近三周的"笨功夫" 智能体的智能从哪里来？从知识库里来。平台中的资源目录、数据产品描述、使用流程说明、制度规范文档，构成了智能体理解业务世界的"教材"。 但把这些材料整合为统一的运营知识库，比预想的要耗时得多。出人意料的是，主要困难不在技术上，而在业务语义的统一。同一个数据产品——比如"企业经营画像"——在市场监管部门的口径里侧重合规，在经济发展部门的口径里侧重增长。不同部门对同一个字段的定义、同一个指标的算法，存在大量隐性差异。 项目团队花了近三周时间，逐一拉通核心数据资产的业务口径，才把知识库的语义层梳理清楚。一位参与该阶段的项目成员回忆："那三周是最枯燥的，但也是最重要的——如果没有这一步，智能体上线后给出的答案可能是'逻辑正确但口径错位'，那比不给答案更危险。" 3.3 感知与匹配：让智能体"看懂"用户 知识库就绪后，团队构建了"感知-匹配-演进"三位一体的智能体架构。这不是一个独立于平台之外的聊天机器人，而是深度嵌入数据中台治理成果之上的能力层。 在匹配机制上，团队采用了语义检索与模糊检索双模并行策略——用户用自然语言输入"看看本市上季度制造业的经营情况"，系统先在知识库中做语义匹配，定位到相关的数据产品和指标定义，再生成准确的查询路径。模糊检索作为补充，覆盖用户输入不精确、指标名称记不全等常见场景。 在感知机制上，团队引入了需求感知引擎。用户的搜索失败记录、浏览过程中的中断点、发起但未完成的申请——这些"沉默的信号"被系统自动捕获和分析，定期生成需求洞察报告。报告会告诉运营团队：最近一个月哪些数据产品被高频搜索但找不到、哪些已有产品上线后使用率为零、哪些用户群体有相似的需求模式但尚未被覆盖。 一位运营负责人后来总结："以前我们是闭着眼推数据产品，智能体给了我们一扇窗户，能看清楚用户真正在找什么。" 3.4 运营闭环：最意外的变化发生在流程层面 智能体上线后，最显著的变化不是技术指标，而是运营决策方式的转变。 过去，运营团队讨论"下一批数据产品上什么"，基本靠个人判断和经验。运营会议上经常出现的情况是：一个人觉得A重要，另一个人觉得B更紧迫，缺乏统一的数据依据来支撑决策。 智能体上线后，需求洞察报告成为运营会议的固定议程。报告中按需求强度排序的数据产品缺口清单，直接转化为上架优先级列表。团队从"凭感觉拍板"切换到"靠数据决策"，数据产品迭代周期从按月计缩短为按周计。一位客户方项目负责人评价说："以前推数据产品像蒙着眼睛打靶，智能体给了我们一杆瞄准镜。" 四、效果：从"数据可用"到"数据好用"的量化跃迁 智能体上线运行一段时间后，项目组对关键运营指标进行了复盘。以下对比基于实际运营数据（部分指标采用区间表述以保护商业信息）： 指标 上线前 上线后 基础咨询工单量 人工坐席处理为主 显著下降，高频重复咨询由智能体承接 用户检索耗时 多次关键词尝试，平均耗时较长 大幅缩短，自然语言直达目标 首次申请成功率 偏低，用户常因选错数据产品而退回重提 明显提升 数据产品迭代周期 按月计，上架决策凭经验判断 按周计，需求洞察驱动优先级排序 运营模式 被动响应，需求收集碎片化 主动感知，需求驱动、持续演进 从项目组的复盘来看，效果改善并非来自某一个"杀手级功能"，而是知识库梳理、感知机制、匹配引擎和运营闭环四件事叠加之后的系统性变化。智能体只是表面上的交互入口，真正起作用的，是背后被组织起来的治理成果和运营机制。 五、启示：AI用数在企业落地的三个关键前提 从江苏某国企数科的实践来看，AI用数智能体的落地路径，可以从三个维度来把握。 治理先行，但不求完美。 实践中最常见的两个极端是：要么"等治理全部到位了再上AI"，项目遥遥无期；要么"不管治理先上AI"，上线后发现输出不可信、用户不买账，项目搁浅。较为稳妥的做法是在核心数据域——通常是高频使用的业务主数据、核心指标和关键分析表——把元数据、数据标准和基础质量做扎实，然后在这些域上启动AI用数，边治理边验证，以用促治。治理不需要一步到位，但在AI开始"读数据"之前，核心域的语义和口径必须有一套经得起推敲的基准。 入口做简单，能力做深。 AI用数智能体的用户体验门槛，直接决定了它在组织内的扩散速度。衡量标准可以很朴素——一个没有经过培训的业务人员，能不能在不看任何说明的情况下，三分钟之内查到他想要的数据。自然语言查询、智能检索建议、自动图表生成，这些能力今天已经可以在现有数据中台之上叠加部署，关键是把体验做得足够轻。入口越简单，业务人员越愿意用；用得越多，平台治理成果的价值就越能被感知。 运营闭环比功能上线更重要。 智能体项目最容易犯的错误，是把它当成一个"交付即结束"的IT工程。从实践来看，智能体部署上线只是开始，真正的价值增长来自持续运营。需求感知→数据产品迭代→效果验证的闭环机制，是决定AI用数长期价值的关键变量。运营团队从"凭经验"到"靠数据"的决策方式转变，往往比技术方案本身更能说明项目的成功程度。 市场上已有部分产品（如龙石AI用数智能体）提供开箱即用的自然语言用数能力，集成DeepSeek和千问3等主流大模型，支持数据不出域的私有化部署。但工具本身不是关键——关键是企业是否做好了让数据"被AI读懂"的准备。治理是基础，入口是桥梁，运营闭环是持续引擎。三件事做到位了，AI用数才不是一次技术演示，而是一项可以持续生长的组织能力。 参考来源： [1] DAMA International，《DAMA数据管理知识体系指南（DAMA-DMBOK2）》，机械工业出版社 [2] 全国信息技术标准化技术委员会，《GB/T 36073-2025 数据管理能力成熟度评估模型》（DCMM 2.0） [3] 全国信息技术标准化技术委员会，《GB/T 36344-2018 信息技术 数据质量评价指标》 [4] 国家数据局，《"数据要素×"三年行动计划（2024—2026年）》 [5] 龙石数据，AI用数智能体，https://www.longshidata.com/products/aianalysis.html
"模型选好了，算力也到位了，但卡在数据上。"这是近两年AI项目中最常听到的一句话。 本文所称"AI数据集"，主要指企业将结构化业务数据经过治理后，形成可供模型训练、分析推理、智能问数等场景使用的数据集合。不同AI场景对数据的要求各有侧重——产品质量预测依赖传感器和工艺参数的完整性与准确性，智能问数更依赖元数据的语义映射和指标口径的统一——但底层的数据治理逻辑是共通的。 某制造企业的AI团队计划用AI模型做产品质量预测，思路很清晰：把ERP里的生产记录、MES里的工艺参数、LIMS里的检测数据喂给模型。但实际操作中，他们遇到了意想不到的困难——同一个物料在三个系统里用三种编码命名，部分历史检测记录缺少关键字段，跨系统的指标口径各说各话。数据确实"有"，但不在一个能用、可信的状态。 这不是孤例。越来越多的企业发现，从"业务系统里存着数据"到"AI能直接用这些数据"，中间隔着的不是技术问题，而是一整套治理功课。其核心不是简单"把数据喂给模型"，而是建立一套能够持续生产、更新和评价AI数据集的治理机制。本文逐一拆解这中间的十个关键环节。 一、为什么业务数据不能直接"喂"给AI 业务系统中的数据是为业务流程服务的——订单系统的数据负责记录交易，MES的数据负责跟踪生产执行，CRM的数据负责管理客户关系。这些数据在设计之初就没有考虑过"被AI模型消费"这个使用场景。 具体来说，业务数据在三个维度上天然不适合直接用作AI数据集。 口径不一致。同一个业务指标，不同系统可能有不同的理解和计算方式。例如"准时交付率"，有的系统按订单创建时间算，有的按发货确认时间算，数字自然对不上。华东某电子制造企业在数据治理过程中就遇到了这个问题：财务部算出来的产值和运营部算出来的产值对不上，月度经营会上管理层要先花时间确认"到底以哪个数字为准"。AI模型如果学到的是这种口径矛盾的数据，输出的结论也必然自相矛盾。 质量参差。业务系统中普遍存在数据缺失、格式错误、异常值超标等问题。这些问题在日常业务流程中可能被人工校验绕过，但AI模型会规模化使用数据——原本可以通过人工经验绕过的数据问题，可能在模型训练和推理过程中被持续放大。 语义缺失。数据库中的字段名是技术命名——"F_ORDER_AMT""T_PROD_CD"这类标识对开发人员不是问题，但对AI模型而言，它不知道这些字段在业务世界里的实际含义。没有元数据的"翻译层"，AI难以准确建立业务术语与表、字段、指标之间的映射关系。 综合来看，业务数据的三个短板恰好对应了AI数据集的核心要求：口径一致对应"可信"，质量达标对应"可靠"，语义完整对应"可理解"。补齐这三个短板的过程，就是治理全链路的核心任务。 二、治理全链路：十个环节逐一拆解 从业务数据到AI数据集，依次经过十个治理环节。这些环节可以参考龙石数据"理—采—存—管—用"的整体路径进行组织，但各环节之间并非严格割裂，在实际项目中往往交叉推进。以下按大致阶段展开。 理：摸清家底 1. 数据盘点 做什么：系统性地梳理企业有哪些数据、存在哪些系统里、归属哪个业务域、数据量级和更新频率如何。 为什么重要：如果连"数据在哪"都说不清楚，后续的归集、质量和安全工作就是无源之水。盘点是治理全链路的起点。 怎么做：从AI应用瞄准的核心业务域出发，逐系统盘点数据表、字段和关键业务对象。不要把范围铺得太广——先盯住AI会用到的那几套核心系统和核心表即可。产出物是一份数据资产清单，标明每个数据资源的来源系统、业务归属和基本状态。 2. 来源筛选 做什么：围绕明确的AI应用场景，判断哪些数据值得纳入AI数据集，哪些数据与场景无关或质量过低不值得投入。 为什么重要：不是所有数据都值得喂给AI。低质量、低相关性的数据只会增加噪音和治理成本。筛选的标准是"这个数据集对AI应用场景有没有直接价值"。 怎么做：基于第一步的盘点结果，AI团队和业务团队共同确认数据需求范围。质量过差、更新频率过低、与场景无关的数据暂不纳入，先聚焦核心数据源。 采：汇聚数据 3. 多源归集 做什么：将分散在不同业务系统中的数据统一汇聚到治理平台或数据底座中。 为什么重要：数据不汇聚，后续的清洗、标准和质量工作就无法集中执行。归集是打通数据孤岛的第一刀。 怎么做：根据数据类型和时效要求选择归集策略——结构化数据采用批量归集，龙石数据中台对单表精细化的场景可通过拖拽式画布设计数据流转，对需要一次同步多张表的场景可采用向导式批量勾选；需要秒级响应的场景采用实时归集（基于数据库日志的变更数据捕获）。归集过程需要处理数据库异构适配、字符集转换、字段映射等常见工程问题。 存：数据存储 4. 清洗转换 做什么：对归集后的存量数据进行格式统一、异常值处理、空值标记和数据类型转换。 为什么重要：原始数据中的脏数据如果不清理，后续的质量检测和AI训练都会受到影响。清洗是"让数据进入可用状态"的必要工序。 怎么做：格式化处理（日期格式统一、数值精度对齐）、异常识别（超出业务合理范围的值标记或剔除）、缺失值处理（按业务规则填补或标记为空）。清洗规则应当在治理平台中配置为可复用的模板，而非每次手工处理。 管：治理保障 5. 标准统一 做什么：统一数据的编码规范、命名规则、业务术语定义和指标计算口径。 为什么重要：这是AI数据集可信度的关键底座。如果同一个指标在不同系统中代表不同的含义，AI模型学到的是矛盾的信息——输出结果可能在语言上流畅，但在业务逻辑上自相矛盾。 怎么做：从核心主数据对象（如物料、客户、供应商、科目、项目等）入手，制定统一的编码规则和命名规范。然后扩展到关键业务指标的计算口径统一——明确每个指标的取数来源、计算逻辑和更新频率。标准制定后需要沉淀到治理平台中，作为数据接入和使用的强制校验基准。 华东某电子制造企业在治理过程中，从核心业务对象入手，逐一盘点各系统中的存量数据，统一编码规则和校验规范，产出了覆盖全集团的数据标准体系。这个过程的经验是：如果基础编码都没统一，再先进的AI模型也难以产出可信的结果。 6. 质量检测 做什么：依据国家标准定义的质量维度，对数据进行系统性的自动化质量扫描。 为什么重要：质量检测把"数据能不能用"从主观判断变成可量化的客观评价。只有经过质量验证的数据集，AI模型的输出才有可信度。 怎么做：以GB/T 36344-2018《信息技术 数据质量评价指标》[1]为框架。该标准定义了六个评价维度——规范性、完整性、准确性、一致性、时效性和可访问性。除可访问性侧重技术条件外，前五个维度直接影响AI应用效果：规范性决定数据是否按统一格式被模型稳定解析，完整性和准确性决定模型推理的信息基础是否可靠，一致性和时效性决定跨系统关联分析的结论是否可信。 在实操层面，质量检测通常采用旁路监测模式——数据正常入库，质量规则并行扫描，发现问题打标记、告警或生成工单，不阻断业务流程。这种方式在保证质量可见性的同时，不影响业务系统的正常运行。对于希望先开展质量摸底的企业，也可以通过支持 GB/T 36344 评价框架的数据质量工具，对核心数据源进行基线检测，在不影响原有业务流程的情况下识别主要质量问题。 7. 语义补充 做什么：为技术字段补充业务含义说明，让AI能够"读懂"数据。 为什么重要：数据库字段名是给开发人员看的，AI模型需要的是一层业务语义的"翻译"。一个字段叫"F_STAT_CD"，AI不知道它代表"订单状态"还是"客户级别"——除非元数据告诉它。语义补充的本质，是把数据库从"技术字典"升级为"业务字典"。 怎么做：通过元数据管理，为每个字段补充中文名称、业务定义、取值规则、关联关系等信息。这一步在技术上不复杂，但考验的是业务语义的统一能力——同一个业务概念在不同部门之间可能存在隐性差异，需要逐一拉通。在实际项目中，核心数据资产的业务口径梳理往往是投入时间较多的环节，但这一步一旦完成，AI就可以基于一致的语义进行查询和分析。 8. 安全处理 做什么：对AI数据集中可能涉及的敏感信息进行分类分级和脱敏处理。 为什么重要：AI数据集一旦形成，通常会被多个团队使用和分发。如果原始数据中包含个人信息、商业秘密或其他敏感内容，未经脱敏就进入训练流程，不仅存在合规风险，而且一旦泄露几乎无法追溯。安全处理是AI数据集在"可用"和"合规"之间的平衡点。 怎么做：结合 DCMM 2.0（GB/T 36073-2025）[2]的数据安全能力要求，以及现行数据安全和分类分级相关规范，对数据实施分类分级——区分一般数据、重要数据和敏感数据。对敏感字段实施脱敏处理（支持静态脱敏和动态脱敏两种模式），配置按角色、按数据级别的访问控制策略。安全策略还需要支持场景化配置——同一个数据集在内部AI训练、跨部门共享、对外合作三种场景下，脱敏策略和访问权限应当有所不同。 用：应用与交付 9. 版本管理 做什么：对AI数据集的每一次变更进行版本记录，确保训练过程可追溯、可回滚。 为什么重要：AI模型的迭代本质上是在数据上迭代。如果数据集的版本没有记录，当模型效果出现波动时，排查方向就少了一个关键变量——不知道是模型参数的问题还是训练数据变了。版本管理解决的是"这个模型到底是哪批数据训出来的"这个朴素但关键的问题。 怎么做：对数据集建立版本号机制，每次数据更新（新增数据源、调整清洗规则、补充语义标注等）生成新的版本快照。版本信息应至少包含变更时间、变更内容、变更人和变更原因。在治理平台中，版本管理通常与数据资产目录联动——同一份数据集的历史版本在目录中保持可查询、可对比。 10. 服务发布 做什么：将治理完成的AI数据集以标准化形式交付给AI团队或应用系统。 为什么重要：治理的终点不是一份质量报告，而是数据真正被用起来。服务发布是治理全链路从"内部工程"转向"对外交付"的最后一环。 怎么做：根据使用场景选择合适的交付方式——批量训练场景以数据集文件或数据表形式输出，实时推理场景通过API接口提供数据服务（龙石数据中台已支持一键发布API并配置访问控制），探索分析场景通过数据资产门户让AI团队自助检索和使用。交付时需要附带元数据说明文档（数据字典、字段含义、质量评估结果、更新频率），让使用方在做AI训练之前就知道数据的特点和边界。 三、持续治理机制：AI数据集不是一次性交付 走完十个环节，并不意味着治理工作结束。AI模型会迭代，业务数据会更新，数据集的治理需要从"一次性工程"转向"持续运转的机制"。 质量基线的持续监控。以十个环节走完时的质量状态为基准线，配置自动化监控规则，当质量指标偏离基线时自动告警。这相当于把质量从"一次性体检"变成"持续监测"。 数据集的版本追踪。每次数据集发布新版本时，同步记录变更内容和变更原因，确保任何一次模型训练都能对应到确定的数据集版本。这对AI项目中的问题排查和同行评审尤为重要。 反馈闭环。建立从AI应用效果回传到数据集优化的反馈链路——模型在特定场景下的准确率下降、某些特征在实际推理中表现不稳定——这些信号反向驱动数据集的改进策略。闭环一旦建立，数据质量就从"靠人盯"变成了"靠机制走"。 四、以"理采存管用"为框架看AI数据集治理 "理采存管用"五阶段方法论为这十个环节提供了一个结构视角。在"理"阶段搞清楚数据家底，在"采"阶段打通系统间的数据流转，在"存"阶段建立标准化基础，在"管"阶段落实质量和安全要求，在"用"阶段以产品化方式交付——各阶段层层递进，构成了从业务数据到AI数据集的完整价值链。 从DAMA数据管理知识体系（DAMA-DMBOK2）[3]的视角来看，这十个环节覆盖了数据质量管理、元数据管理、主数据管理、数据安全管理和数据集成与互操作等多个核心知识领域。AI数据集的治理不是凭空创造一套新规则，而是将成熟的数据管理实践聚焦到AI这一特定消费场景上。 从多数项目的实践经验来看，在核心数据域完成基础治理后再启动AI应用，比"边用边治"更可控。正如前述电子制造企业的实践所示——如果底层编码都没统一，上层分析就缺乏可靠基础。数据治理的深度，直接决定了AI数据集的最终可信度。 FAQ *Q1：十个环节听起来很多，小团队怎么入手？* 不需要一开始就追求全量覆盖。选取AI应用瞄准的一到两个核心业务域，从数据盘点和质量基线做起，先跑通一条完整链路。企业可以优先从质量基线检测和核心数据语义补充入手，这两项工作通常更容易形成阶段性成果。如果希望先低门槛地摸清数据质量现状，也可以通过免费的质量检测工具做一次基线扫描——例如龙石数据质量管理平台·社区版，部署后即可对核心数据源进行 GB/T 36344 标准框架下的自动化质量检测。 *Q2：已经有数据中台了，还需要专门的AI数据集治理吗？* 两者并非相互替代。数据中台为数据归集、治理和服务提供基础能力，AI数据集治理则进一步面向具体AI场景，对语义、质量、版本和使用反馈提出针对性要求。简单来说：中台把路修好了，但AI需要的路标、信号灯和定期养护需要专门设计。 *Q3：语义补充和元数据管理是一回事吗？* 元数据管理是基础设施——采集技术元数据和业务元数据。语义补充是在元数据基础上的"AI定向增强"——重点是为AI模型提供结构化、可查询的业务语义字典，确保模型能够正确地将业务术语映射到具体的表和字段上。两者的关系是：元数据管理搭框架，语义补充做精装。 *Q4：数据安全和模型安全是什么关系？* 数据安全关注"数据本身的敏感信息保护"——分类分级、脱敏处理、访问控制。模型安全关注"模型输入输出层面的攻击防护"——提示词注入、越狱攻击等。两者是上下游关系：数据安全做不好，敏感信息进入训练数据，模型安全就成了无源之水。结合 DCMM 2.0[2]的数据安全能力要求及现行安全规范，数据脱敏和访问控制是两者之间的衔接点。 参考来源 [1] GB/T 36344-2018《信息技术 数据质量评价指标》，国家市场监督管理总局、中国国家标准化管理委员会 [2] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0），全国信息技术标准化技术委员会 [3] DAMA International，《DAMA数据管理知识体系指南（DAMA-DMBOK2）》，机械工业出版社 [4] 龙石数据，AI用数智能体，https://www.longshidata.com/products/aianalysis.html
“用 AI 问数，业务人员不用学 SQL 也能查数据！”“几分钟出分析报告，决策效率翻三倍！”—— 几年前，当 AI 问数的推销话术第一次出现在企业会议室时，老板们眼中满是期待，仿佛找到了破解 “用数难” 的金钥匙。可如今，同样的场景再上演，得到的往往是高管们敷衍的点头，会后便石沉大海。 这像极了当初 “数据治理” 从热捧到遇冷的轨迹。为什么曾经被寄予厚望的 AI 问数，也渐渐提不起老板们的兴趣？是技术本身不行，还是企业对它的期待与现实脱了节？我们不妨顺着当初分析 “数据治理遇冷” 的思路，看看 AI 问数背后的困境与转机。 01 听腻的 “便利” 故事，撑不起真实需求 “不用技术人员帮忙，自己就能查数据”“不用等报表，实时出结果”—— 这些关于 AI 问数的 “便利” 故事，和当年 “数据治理是数字化基石” 的说法如出一辙，听多了便成了陈词滥调。 更让老板们失望的是，不少企业花了钱引入 AI 问数系统后，发现现实远不如宣传：业务人员确实不用写 SQL 了，但 “怎么问才能得到准确结果” 又成了新难题 —— 问得太笼统，系统答非所问；问得太具体，又和写代码一样繁琐；好不容易查到数据，要么格式混乱看不懂，要么和其他部门的数据对不上，最后还是得找技术人员兜底。 就像当年企业花大价钱做数据治理，结果数据依旧杂乱一样，AI 问数的 “便利” 停留在了口头上，没解决企业真正的用数痛点。老板们听多了 “画饼”，自然对这套说辞没了兴趣。 02 算不清的价值账，成了立项拦路虎 和数据治理面临的 “ROI 迷雾” 一样，AI 问数也躲不开 “价值量化” 的难题。老板们愿意花钱，但得知道花出去的钱能带来什么具体回报。 可实际情况是，企业引入 AI 问数后，很难说清它到底创造了多少价值：财务依旧用 Excel 做核算，因为 AI 问数导出的数据还得手动调整；运营分析指标，还是会因为部门口径不一产生争议，AI 问数没能统一标准；原本期待它能加速决策，结果业务人员还是得反复确认数据准确性，决策周期没缩短多少。 在 “降本增效” 成了企业经营核心目标的当下，AI 问数拿不出清晰的价值清单 —— 比如 “每月减少多少技术支持工时”“帮助业务部门多创造多少营收”，老板们自然不愿轻易点头立项，预算申请也屡屡卡在 “说不清楚价值” 这一关。 03 新技术分流注意力，AI 问数失了 “新鲜感” 就像当年 AI 兴起让数据治理失宠一样，如今生成式 AI、AI Agent 等新技术的火热，也分走了老板们对 AI 问数的关注。 相比 AI 问数 “只能查数据、做基础分析” 的定位，新技术的故事显然更吸引人：“AI 能自动写文案、做设计，直接减少人力成本”“AI Agent 能自动处理流程化工作，效率翻几倍”—— 这些说法听起来更 “颠覆性”，也更能让老板们看到 “快速见效” 的可能。 而 AI 问数呢？既没有数据治理 “数字化基石” 的宏大定位，也没有新技术 “颠覆业务” 的吸睛亮点，卡在中间成了 “尴尬的存在”。老板们的注意力被更前沿的技术吸引，AI 问数自然慢慢淡出了优先选项。 04 不是 AI 问数没用，是没找对价值打开方式 看到这里，或许有人会问：难道 AI 问数对企业来说，真的没价值了吗？其实不然。就像数据治理在 AI 时代依旧重要一样，AI 问数的价值，只是需要换一种更贴近企业需求的方式来呈现。 企业用数的核心痛点，从来不是 “不会写 SQL”，而是 “数据用得不顺畅”—— 数据看不懂、查不准、用不上。AI 问数要做的，不是单纯替代技术人员写查询语句，而是成为 “打通数据到业务的桥梁”。 比如，通过 “元数据增强” 给数据加 “说明书”，让业务人员能看懂 “yjje” 是 “应收账款金额”，知道 “销售额” 和 “订单量” 的关联逻辑，解决 “数据看不懂” 的问题；通过 “用数知识库” 收集常见问题，比如 “每月销售总额怎么算”“地区生产总值包含哪些范围”，让重复查询不用再反复计算，同时根据用户反馈不断优化，解决 “查不准” 的问题；再通过 “图表可视化”，把查询结果变成饼图、折线图，配上通俗的文字解读，让业务人员拿到数据就能直接用在汇报、决策里，解决 “用不上” 的问题。 更关键的是，要建立 “兜底机制”—— 万一 AI 问数给出的结果不准，有人工介入排查，把正确结果反馈给用户，同时更新知识库，避免下次再出错。这样一套组合拳下来，AI 问数才能真正解决 “数据用得不顺畅” 的痛点，而不是停留在 “不用写 SQL” 的表面便利上。 05 结语：回归业务本质，才是 AI 问数的出路 其实，不管是数据治理，还是 AI 问数，抑或是当下火热的新技术，企业选择它们的核心逻辑，永远是 “能否解决业务问题”。AI 问数之所以遇冷，不是技术不行，而是之前的价值主张偏离了业务本质 —— 只强调 “技术便利”，没解决 “业务痛点”；只谈 “概念”，没算清 “价值”。 未来，AI 问数要想重新赢得老板们的认可，不用去和新技术 “抢风头”，也不用刻意营造 “高大上” 的定位，而是要扎根业务：帮财务部门减少数据整理时间，帮运营部门统一分析口径，帮业务部门快速拿到能用的数据分析结果。 当 AI 问数能让老板们清晰看到 “每月帮公司节省 X 万元成本”“助力业务部门提升 Y% 的决策效率” 时，不用过多推销，它自然会成为企业用数的 “刚需工具”。毕竟，对老板们来说，能真正解决问题、创造价值的技术，永远不会被淘汰。
晚间 23 时许，某企业业务专员小李刚完成当日工作闭环，便收到部门负责人紧急需求：“明日上午需与客户开展业务复盘，需在 30 分钟内提供上季度 A、B 两款核心产品在华南、西南区域的销售额数据及同比增幅，用于汇报材料编制。” 接到需求后，小李迅速启动数据查询流程。在传统工作模式下，此类紧急需求需协调 IT 部门编写 SQL 语句、从数据库提取数据，再通过 Excel 进行格式规整与计算，全流程耗时通常超过 2 小时，加班已成必然。但依托当前企业部署的 AI 智能问数工具，小李仅在系统对话界面输入需求指令：“汇总上季度 A、B 产品在华南、西南区域的销售额，计算同比变化，以表格及柱状图形式呈现结果”。 指令提交后，系统响应耗时不足 3 秒，便生成结构化结果：不仅清晰展示各区域、各产品的销售额与同比增幅数据，同步输出可视化柱状对比图，还附带关键业务洞察 ——“A 产品在西南区域同比增长 23%，为当期增长最快的细分板块”。小李快速核验数据准确性后导出成果，高效完成需求交付，避免了额外加班。 然而，并非所有企业的 AI 智能问数项目均能实现此类价值。据2025年行业报告，约 65% 的企业在 AI 问数工具部署后，因数据准确性不足、业务适配性差等问题，未能达到预期效率提升目标。结合实践经验，企业若想让 AI 智能问数真正落地见效，需聚焦技术选型、基础准备、落地推广三大核心环节，规避常见风险。 一、技术选型：优先保障准确性，平衡灵活性与可靠性 当前 AI 智能问数领域存在两种主流技术路径，其应用效果差异显著，企业需结合业务需求审慎选择： 其一为 Text2SQL 技术路径，依托 AI 模型实时将自然语言转换为 SQL 查询语句，具备需求响应灵活性高的特点，可处理未预定义的查询场景。但实践中存在明显短板：模型易出现 “数据幻觉”，即生成逻辑看似合理但结果错误的 SQL 语句。例如某企业曾出现 “查询近 3 个月销售总额” 却返回 “近 3 年数据” 的情况，核心原因在于模型对时间维度的语义解析偏差。此类问题直接影响业务人员对工具的信任度，最终导致工具使用率不足 30%。 其二为 “知识库 + 自动查询” 技术路径，需先完成数据基础建设与知识库搭建：将企业分散于各业务系统（如 ERP、CRM）的数据汇聚至数据仓库，通过清洗实现数据标准化；明确数据字段的业务定义（如 “销售额是否包含运费”“区域划分标准为发货地或收货地”）；梳理高频查询需求（如 “月度销售对比”“库存周转分析”），构建标准化查询逻辑知识库。该路径下，系统优先匹配知识库响应需求，面对未覆盖的需求，自动触发查询流程，准确率超高；同时建立人工兜底机制，对查询误差进行修正并补充至知识库，实现系统能力持续迭代优化，更符合企业业务稳定性需求。 二、基础准备：筑牢数据、安全、呈现三重支撑 AI 智能问数工具的高效运行，需依托完善的基础支撑体系，核心涵盖三方面： （一）数据质量治理 数据准确性与一致性是工具应用的前提。某企业初期部署时，因财务系统与销售系统的 “客户名称” 字段格式不统一（如 “XX 科技有限公司” 与 “XX 科技”），导致数据查询出现遗漏，工具使用率不足 50%。后通过两周专项数据治理，完成字段标准化与数据校验规则搭建，工具响应准确率提升至 98%，使用率显著回升。企业需优先开展数据集成、清洗与标准化工作，确保数据 “可用、可信”。 （二）数据安全管控 企业数据涉及商业机密，需建立精细化权限管控机制。例如按角色划分数据访问范围：销售岗位仅可查询负责区域数据，财务岗位专属财务数据访问权限。某企业曾因权限设置疏漏，导致新入职员工误查全公司利润数据，引发数据安全风险，后续通过搭建 RBAC（基于角色的访问控制）模型，实现数据权限与岗位职责精准匹配，规避安全隐患。 （三）结果可视化与解读 业务人员对数据的核心需求是 “可理解、可直接应用”，需强化结果呈现能力：针对销售对比类需求，自动生成柱状图、折线图等可视化图表；针对预警类需求（如库存不足），通过颜色标注（如红色标识低库存产品）突出关键信息；同时附加简洁业务解读（如 “某产品库存仅满足 5 天销售需求，建议启动补货流程”）。此类设计可减少业务人员数据二次加工时间，将数据到决策的链路缩短 60% 以上。 三、总结 企业部署 AI 智能问数工具时，易陷入 “全覆盖、快推进” 的误区，导致资源分散、推广阻力大。建议采用 MVP（最小可行产品）模式，分阶段落地。 AI 智能问数是提升数据查询效率的核心工具，企业需避免 “一步到位” 误区：优先选 “知识库 + 自动查询” 路径，筑牢数据、安全、呈现基础，以 MVP 模式分阶段推广。工具稳定后，业务人员数据分析时间可减少 80% 以上，更聚焦业务策略制定，实现 “数据驱动决策”。
近年来人工智能技术加速创新发展，社会各界对“AI赋能千行百业”充满期待。然而，现阶段技术层面的热度与实际落地的冷态形成鲜明反差：一方面，AI大模型、智能算法等技术持续迭代，成为产业创新的热门方向；另一方面，当技术试图深入制造业、医疗、教育等具体领域时，却常陷入“不知需求在哪、不知如何适配”的困境。这种“供需双模糊”并非偶然，而是技术革命与产业转型不同步的阶段性产物——技术供给的泛化性与产业需求的特异性碰撞，传统供需对接逻辑失效，最终形成“需求说不清、供给不对路、匹配无标准”的三重困境。深入剖析这一困境的本质与成因，探索系统性破局路径，是推动AI从“技术概念”走向“产业价值”的关键。 供需双模糊的现实图景：三个维度的核心矛盾 供需双模糊的本质，是AI技术与产业需求在“表达-供给-对接”全链条中的认知断层与能力错位，具体呈现为三个维度的核心矛盾。 1 需求端--“抽象诉求”与“具体落地”的断层 需求端的模糊性，根源在于“需求表达能力”与“技术落地要求”的不匹配。产业界对AI的需求往往停留在“降本增效”“提升质量”等抽象目标，却难以完成从“要什么”到“怎么实现”的转化——既无法明确需求对应的技术边界（如“提升生产效率”需匹配“实时数据采集”还是“智能调度算法”），也难以界定落地的约束条件（如现有设备是否兼容、业务流程是否需重构）。这种断层的核心原因，在于行业主体缺乏对AI技术应用边界的认知，同时AI技术的复杂性又让“需求具象化”需要跨领域知识（既懂行业业务，又懂技术逻辑），而多数行业尚未形成这种跨领域的需求转化能力。此外，需求的动态性进一步加剧模糊性：产业需求随市场变化、政策调整持续迭代，而AI技术的研发与落地存在周期，静态的需求描述与动态的产业变化难以同步，导致需求与供给始终存在“时差”。 2 供给端--“通用技术”与“行业特异性”的错位 供给端的模糊性，源于技术研发的“通用导向”与产业需求的“场景特异性”之间的天然张力。当前AI技术供给多聚焦于基础能力建设（如大模型的通用推理、算法的精度优化），研发逻辑偏向“技术可能性”而非“行业必要性”——技术方常以“通用解决方案”推向市场，却忽视不同行业、甚至同一行业不同场景的差异化需求（如制造业的离散生产与流程生产，对AI的实时性、稳定性要求截然不同）。更关键的是，技术供给的价值评估体系与产业需求脱节：技术方倾向以“算法精度”“模型参数”等技术指标衡量价值，而产业方更关注“投资回报率”“与现有系统兼容性”“人员操作门槛”等实际效益指标，这种价值认知的偏差，导致技术供给看似先进，却难以满足产业的真实落地要求。此外，技术供给的“超前性”也加剧模糊：部分AI技术尚处于实验室验证阶段，离产业级的稳定性、可靠性要求仍有差距，却被过早推向市场，进一步放大“技术能做什么”与“产业需要什么”的错位。 3 匹配端--“传统机制”与“AI特性”的失效 供需匹配机制的模糊性，本质是传统对接模式难以适配AI技术的特性。过去产业供需对接多依赖“需求明确-产品开发-批量交付”的线性逻辑，而AI赋能的核心是“场景化适配”——需求需在技术落地过程中逐步明晰，技术也需根据场景反馈持续优化，这种“动态适配”逻辑与传统静态对接模式完全不同。同时，价值评估体系的缺失让匹配失去标准：AI对产业的价值不仅是效率提升，更包括业务流程重构、商业模式创新等深层影响，这些价值难以用传统量化指标衡量，导致供需双方对“匹配效果”缺乏共识。此外，行业知识壁垒进一步阻碍匹配：AI技术方缺乏对产业业务流程、痛点的深度理解，产业方也难以判断技术的实际适配性，双方陷入“无法有效对话”的困境，最终导致匹配效率低下，甚至出现“错配”（如为低需求场景投入高成本AI技术，或为高复杂度场景提供简易解决方案）。 从行业差异来看，供需模糊性的程度与行业的“信息化基础”“知识壁垒”呈正相关：互联网、金融等信息化程度高、业务流程相对标准化的行业，供需双方对AI的认知更清晰，模糊性较低；而制造业、医疗、教育等信息化起步晚、业务流程复杂、知识壁垒高的行业，需求更难具象化、技术更难适配，供需模糊性也更为突出。这种差异并非技术可行性问题，而是供需双方的认知协同、能力协同程度不同所致。 供需双模糊的深层成因：多因素交织的系统性矛盾 供需双模糊并非单一因素导致的问题，而是技术演进规律、产业发展特征、组织能力建设、生态体系构建等多维度矛盾交织的结果，其核心是“AI技术的突破性”与“产业体系的惯性”之间的冲突。 1 技术迭代与产业进化的节奏失衡 AI技术的迭代呈现“指数级”特征：大模型的参数规模、算法的推理效率持续突破，新的技术方向不断涌现，技术边界快速扩张。而产业需求的进化遵循“渐进式”逻辑：产业的业务流程、设备体系、组织模式是长期积累形成的，其变革需考虑成本、风险、人员接受度等多重因素，难以随技术迭代同步调整。这种“快技术”与“慢产业”的节奏差，导致技术供给始终领先于产业需求的消化能力——当技术方推出新一代解决方案时，产业方可能仍在消化上一代技术的落地难题，供需之间自然形成“时间差”。更关键的是，AI技术的“通用性”让其应用场景具有无限可能性，而产业需求的“特异性”要求技术必须聚焦具体场景，这种“泛在技术”与“特定场景”的天然张力，进一步放大了节奏失衡带来的模糊性。 2 技术方与产业方的认知鸿沟 供需双模糊的核心障碍，是技术方与产业方之间的“双向无知”与“语言壁垒”。一方面，AI技术方多出身于计算机、数学等领域，对传统产业的业务流程、核心痛点、操作习惯缺乏深度理解，往往从技术逻辑出发设计解决方案，而非从产业需求出发；另一方面，产业方对AI技术的原理、边界、落地条件认知有限，既难以判断技术的实际可行性，也无法清晰表达自身需求对应的技术要求。这种双向无知导致供需对话陷入“鸡同鸭讲”的困境：技术方谈论“模型精度”“推理延迟”，产业方关心“故障响应速度”“人员培训成本”，双方使用不同的“专业语言”，却缺乏统一的转换逻辑，需求无法精准传递，供给也难以有效匹配。更严重的是，这种认知鸿沟会引发“误判”：技术方可能高估产业的技术接受能力，产业方可能高估AI的实际效果，进一步加剧供需错位。 3 人才结构与产业需求的严重错配 人才是连接技术与产业的关键纽带，而当前AI领域的人才结构，恰恰难以满足供需协同的需求。一方面，AI人才多集中于技术研发（如算法设计、模型训练），缺乏既懂AI技术、又懂产业业务的“复合型人才”——这类人才需要同时掌握技术逻辑与行业知识，能够将抽象需求转化为具体技术指标，也能将技术特性转化为产业价值，而目前无论是高校培养体系还是市场人才供给，都难以满足这一需求。另一方面，产业内部的人才也存在“AI认知缺口”：多数行业业务骨干缺乏对AI技术的基础认知，无法判断技术与业务的结合点；IT人员虽懂技术，却缺乏对业务流程的深度理解，难以推动技术与业务的深度融合。这种“技术人才不懂业务、业务人才不懂技术”的结构矛盾，导致需求在产业内部传递时就出现损耗，更无法与技术供给有效对接。 4 标准缺失与生态碎片化的约束 AI赋能需要一套统一的“规则体系”来降低供需对接成本，而当前标准的缺失与生态的碎片化，进一步加剧了供需模糊性。从标准层面看，AI应用尚未形成统一的数据格式、接口规范、评估指标：不同技术方的系统接口不兼容，数据难以互通；缺乏行业公认的AI价值评估标准，供需双方对“落地效果”难以达成共识；技术适配的约束条件（如硬件要求、安全规范）也无明确界定，导致技术落地时需反复试错。从生态层面看，AI产业呈现“各自为战”的碎片化格局：技术提供商、行业解决方案商、基础设施服务商之间缺乏协同机制，技术研发、需求挖掘、场景落地等环节相互割裂，难以形成“技术-需求-落地”的闭环。这种碎片化不仅增加了供需对接的复杂度，也导致资源分散，无法集中力量解决共性问题（如跨行业的需求转化方法、通用的技术适配框架）。 5 组织认知与资本逻辑的双重干扰 组织内部的认知偏差与外部资本的短期导向，也在放大供需双模糊的效应。在组织层面，对AI的认知常陷入两个极端：一是“AI万能论”，认为AI可解决所有产业问题，盲目上马项目却不考虑实际需求，导致技术与业务脱节；二是“技术恐惧论”，因担心AI对现有流程、岗位的冲击而拒绝尝试，错失技术赋能机会。同时，多数组织仍沿用“技术驱动”而非“需求驱动”的决策逻辑，产品开发先考虑技术可能性，再寻找应用场景，而非先明确需求痛点，再匹配技术方案，这种逻辑倒置本身就容易导致供需错位。在资本层面，AI领域的资本多追求短期回报，倾向于投资“概念新、见效快”的通用技术研发，而非“周期长、见效慢”的行业场景落地，导致技术供给偏向“炫技式创新”，而产业真正需要的“实用化创新”却缺乏资本支持，进一步加剧技术供给与产业需求的脱节。 破解路径：构建“三阶破冰”的系统框架 破解供需双模糊困境，不能依赖单一环节的优化，而需构建“需求解码-技术适配-生态协同”的三阶系统框架，从需求、技术、生态三个维度同步发力，实现供需的精准对接与动态平衡。 1 需求解码--建立“跨域协同”的需求转化机制 需求解码的核心，是解决“需求从抽象到具体”的转化难题，关键在于构建“业务与技术协同”的跨域机制。首先，需建立“需求翻译”团队：由行业业务专家与AI技术专家组成跨领域小组，业务专家负责梳理核心痛点、明确业务目标，技术专家负责将痛点转化为技术指标（如将“减少设备故障”转化为“故障识别精度、响应时间”等可量化的技术要求），通过双向沟通弥合认知鸿沟。其次，需采用“场景化测试”方法：通过模拟产业实际场景（如搭建缩小版的生产流程、服务环境），让需求在动态测试中逐步明晰——先聚焦单一细分场景（如某一生产工序、某一类服务需求），通过技术验证反推需求边界，再逐步扩展至更复杂场景，避免因需求过于宽泛导致的技术适配困难。最后，需建立“需求迭代”机制：将需求视为动态变化的变量，定期收集技术落地后的业务反馈，根据反馈调整需求描述与技术要求，实现需求与技术的同步优化。 2 技术适配--打造“柔性灵活”的技术供给体系 技术适配的核心，是打破“通用技术”与“行业特异性”的壁垒，构建能够快速响应产业需求的柔性供给体系。其一，需推动技术“模块化”开发：将AI技术拆解为可独立组合的功能模块（如数据采集模块、算法推理模块、结果可视化模块），产业方可根据自身需求灵活选择模块组合，无需为通用解决方案支付额外成本，同时降低技术适配的复杂度。其二，需建立“标准化+定制化”的双重供给模式：针对行业共性需求（如数据格式、接口规范）制定统一标准，降低跨企业、跨场景的适配成本；针对行业特异性需求（如特殊生产环境、个性化服务流程）提供定制化调整，确保技术与实际场景的精准匹配。其三，需推广“轻量化”技术服务：针对中小企业技术能力弱、资源有限的特点，将AI技术封装为轻量化服务（如云端化工具、低代码平台），降低技术应用的门槛——企业无需投入大量资源进行技术研发与设备改造，只需根据需求调用服务，大幅降低AI赋能的启动成本与试错风险。 3 生态协同--构建“政产学研用”的共生发展网络 生态协同的核心，是解决“供需对接机制失效”与“资源分散”的问题，关键在于打造多主体协同的共生网络。从协同主体来看，需明确各方角色：政府负责搭建公共平台、制定标准规范、提供政策支持（如建设AI公共测试环境、出台行业应用标准）；高校与科研机构负责基础技术研发与复合型人才培养（如开设“AI+行业”交叉学科、开展跨领域研究）；企业（包括技术提供商与产业用户）负责场景落地与需求反馈，推动技术与业务的深度融合；金融机构负责提供长期资本支持，重点投向行业场景落地项目，缓解资本短期逐利的约束。从协同机制来看，需建立“多方联动”的对接平台：定期举办跨领域对接会、场景创新大赛，为技术方与产业方提供直接交流的渠道；建设行业AI知识库，汇总需求转化方法、技术适配案例、标准规范等共性知识，降低跨主体的认知成本；建立“风险共担”机制，通过政府补贴、保险支持等方式，分担技术落地的试错风险，鼓励技术方与产业方大胆尝试。 在实施三阶框架的过程中，还需把握三个关键原则：一是“小步快跑”的MVP（最小可行产品）原则，优先聚焦单一细分场景、推出简化版技术方案，通过快速验证与迭代降低风险；二是“价值导向”的动态评估原则，摒弃以技术指标为核心的评估逻辑，转而以业务价值（如成本降低、效率提升、体验改善）为核心，定期评估技术落地的实际效益，确保供需对接的价值导向；三是“能力培育”的长期原则，将人才培养、组织认知升级纳入破局路径，通过跨领域培训、实践项目锻炼等方式，提升产业方的AI认知能力与技术方的行业理解能力，从根本上解决供需协同的能力短板。 结语：从“模糊”到“适配”的产业进化逻辑 当下AI赋能过程中所面临供需双模糊困境，本质上是技术革命推动产业变革过程中的“必经阵痛”。回望历史，每一次重大技术革命（如电力、互联网）都曾经历类似阶段：技术的突破性发展打破原有供需平衡，新的供需逻辑在试错中逐步形成，最终实现技术与产业的深度融合。今天的AI赋能，正处于这一“平衡打破-新平衡构建”的过渡阶段，供需双模糊既是挑战，也是技术与产业相互适应、共同进化的契机。 未来，随着需求解码机制的完善、技术供给体系的柔性化、生态协同网络的成熟，AI供需关系将逐步从“模糊”走向“动态适配”——技术不再是孤立的研发成果，而是能够快速响应产业需求的“柔性工具”；需求不再是抽象的业务痛点，而是能够精准引导技术方向的“清晰目标”；供需对接不再是单向的“技术推送”或“需求拉动”，而是双向互动、持续优化的“协同进化”。最终，AI将从“技术概念”真正转变为“产业基础设施”，如同电力一样融入千行百业的日常运营，其价值不再需要刻意强调，而是自然体现于生产效率的提升、服务体验的改善、商业模式的创新之中。 对产业界而言，应对供需双模糊的关键，是跳出“技术崇拜”或“技术恐惧”的极端认知，以“务实理性”的态度拥抱AI——既不盲目追求前沿技术，也不拒绝技术带来的变革机遇，而是聚焦自身核心业务，通过跨域协同、柔性适配实现技术与业务的深度融合。对政策制定者而言，需在“鼓励创新”与“规范引导”之间寻找平衡，通过标准建设、平台搭建、人才培养，为供需对接创造良好环境，推动AI赋能从“单点突破”走向“系统落地”。 AI赋能的终极目标，不是技术的简单应用，而是产业价值的全面提升。当我们不再纠结于“AI能做什么”，而是聚焦“产业需要什么”，不再追求“通用技术的先进性”，而是关注“技术落地的实用性”时，供需双模糊的困境自然会逐步消解，AI也将真正成为推动产业高质量发展的新质生产力。 来源（公众号）：浙江数字经济
当前人工智能发展正从“模型为中心”转向“数据为中心”，高质量数据集成为大模型竞争的“护城河”。为此，基于《“数据要素 ×”三年行动计划（2024—2026 年）》以及《高质量数据集建设指南（征求意见稿）》，笔者系统性地解构行业级高质量数据集的建设路径，在 AI 时代具有典型意义。 高质量数据集的建设背景 在 AI 产业深度变革的浪潮中，高质量数据集建设呈现出三大显著特征——需求爆发、政策驱动、技术拐点，其发展态势深刻重构着行业格局： 需求爆发 通用大模型向垂直领域的渗透催生了场景化数据资源的井喷式需求。央企加速开放电网调度、核电诊断、金融风控等 30 余个行业核心数据集，推动产业数字化从单点探索迈向系统化升级。这种需求不仅源于技术落地的诉求，更来自 C 端用户对智能服务体验的升级期待，如手机端大模型通过场景重构实现功能跃迁，使普惠化智能服务覆盖数亿用户。市场规模的扩张态势已然明确，即行业共性数据资源库的构建正驱动千亿级市场形成。 政策驱动 国家战略层面对数据要素的系统性部署构成核心驱动力。2017 年国务院印发的《新一代人工智能发展规划》开启了政策先导，2020 年《关于构建更加完善的要素市场化配置体制机制的意见》首次将数据纳入生产要素，而国家数据局联合 17部门联合印发的《“数据要素 ×”三年行动计划（2024—2026 年）》更标志着政策体系的成熟。中央与地方形成协同推进机制。工信部 2016 年发布的《大数据产业发展规划（2016—2020 年）》强化产业支撑体系，贵州省以信用体系与大数据融合试点推动社会治理创新，浙江省通过构建“城市大脑”实现全域数据资源整合。这种“中央顶层设计—部委专项落实—地方场景创新”的三级政策框架，为高质量数据集建设提供了刚性制度保障。 技术拐点 底层技术的突破性演进正颠覆传统数据建设范式。Transformer 架构（一种深度学习模型架构）在推动大模型性能跃升的同时，也暴露出算力分散、领域数据稀缺等瓶颈。当前技术演进呈现两大特征，其一是模型效率革命，如 DeepSeek-R1 系列验证高质量推理数据可提升参数量效率 3 倍，使数据质量取代算力规模成为“新护城河”；其二是架构自主突破，如高质量数据集建设中 95% 国产化率的要求，推动自主芯片 /OS/ 云平台的技术适配。这些突破标志着 AI 发展从“模型优先”转向“数据优先”的新阶段。 高质量数据集的战略定位与意义 在人工智能技术从实验室走向产业化落地的关键转型期，高质量数据集的战略定位已超越基础技术资源范畴，升维为国家数字竞争力的核心基础设施。其战略意义深刻贯穿技术根基、经济引擎与安全壁垒三大维度，构成了支撑“人工智能 +”国家战略落地的系统性支柱。 奠定人工智能发展的技术根基 数据集质量直接决定了人工智能的“智商”水平，这是其最根本的战略定位。国家数据发展研究院院长胡坚波明确指出：“高质量数据集是人工智能真正的‘护城河’”。技术验证亦进行了证明，纽约大学研究发现，医学数据中含 0.001% 错误即会导致模型输出致命误判，而 DeepSeek-R1 模型证明高质量推理数据可使参数量效率提升 300%。此类数据犹如“智能燃料”，通过精准的特征供给驱动模型认知跃升，“数据集质量决定人工智能智商上限”，奠定其在技术生态中的基石地位。 驱动数字经济发展的核心引擎 高质量数据集通过构建“数据—算力—模型”的融合生态，催化出显著的 GDP 增长乘数效应。国家数据局实施的《“数据要素 ×”三年行动计划（2024—2026 年）》将数据集定位为“产业数字化转型升级的加速器”。这种引擎效应建立在数据资产化的创新机制上，主要包括：第一，短期价值释放。央企开放的 30 个行业数据集催生千亿级交易市场，其中金融风控数据集使银行不良贷款识别率提升 29%，直接拉动信贷资产质量优化。第二，长期生态共建。深城交主导建设的交通行业多模态数据集支撑多个大模型训练，有效带动智能网联、低空经济等新产业孵化。 中国信息通信研究院副院长魏亮的“石油炼化”理论深刻阐释其经济逻辑“原始数据需炼化成高质量数据集，才能驱动模型效能转化”，这种“数据炼油厂”角色使其成为新质生产力培育的关键载体。 构筑国家科技安全的战略屏障 在全球化技术竞争背景下，高质量数据集承载着维护科技主权的使命。数据集的国产化率是核心领域数据管控要求，国务院国资委规划发展局副局长胡武婕强调：“行业数据集加速汇聚共享是人工智能自主可控的基础保障”。国家数据局副局长夏冰的论断揭示了其战略本质：“数据集的质效提升是人工智能赋能实体经济的催化剂，需构建部际协同机制筑牢安全根基”。在芯片制程受限的现实环境下，高质量数据集已成为中国突破“算力围城”的核心战略资源。高质量数据集通过“技术根基—经济引擎—安全壁垒”的三角战略架构，确立了人工智能时代的国家基础设施地位。其战略意义不仅在于推动产业实效，更深层的在于构建了中国自主的 AI 发展范式——当算力鸿沟客观存在时，以数据质量优势实现“非对称超越”。随着《高质量数据集建设指南（征求意见稿）》的落地与国家数据要素市场的培育，这一战略支柱将进一步释放“数据 × 产业”的乘数效应，最终支撑中国在全球人工智能治理中实现从“规则接受者”向“标准制定者”的历史性跨越。 高质量数据集的定义和特征 高质量数据集的定义 根据全国数据标准化技术委员会发布的《高质量数据集建设指南（征求意见稿）》和国家标准草案定义，高质量数据集是指经过专业采集、加工处理可直接用于 AI 模型开发与训练，能显著提升模型性能的数据集合，其核心特征体现为“高价值 × 高密度 × 标准化”的三维体系。 高质量数据集的三大特征 高价值指数据集直接驱动模型性能跃升的战略属性。如金融领域数据集通过精准标注交易欺诈模式，使大模型风险误报率降低 55%，凸显其对决策效率的实质提升。高质量数据集需紧密关联应用场景，如工业设备故障预测、医疗影像诊断等，赋能模型在特定领域实现突破性表现。 高密度强调数据的精炼性与信息浓度。通过严格清洗去除冗余噪声，确保样本蕴含有效特征的最大化。典型案例如医疗影像数据集标注病灶边界精度达99.99%，这得益于自动化标注框架与领域专家核验机制的协同，如放射科医生参与审核，实现精准剔除无效样本与强化数据关键特征的统一。 标准化通过分级规范，保障数据可用性。具体可分为三类：一是整合社会通用知识（如基础教育、基础科学数据）的通识数据集，此数据集主要用于支撑通用模型训练；二是聚焦领域基础知识（如金融术语库、交通规则库）的行业通识数据集，理解这类数据需具备基础专业背景；三是面向深度业务场景（如电网故障诊断日志、核电设备运行数据）的行业专识数据集，构建这类数据集需要领域专家的参与。 从本质上来讲，高质量数据集是人工智能时代的“新型基础设施”——其战略价值已超越技术工具范畴，成为驱动产业智能升级、构筑数字主权、重塑全球 AI 竞争格局的核心支点。正如夏冰所强调的：“数据集的质效提升是人工智能赋能实体经济的催化剂，需部际协同构建多元生态”。 高质量数据集的典型建设思路 按照国家数据局关于高质量数据集建设的统筹部署，围绕“试技术融合、试场景支撑、试标准验证、试机制建设”四项工作任务，笔者提出高质量数据集典型建设思路（如图1 所示），以确保高质量数据集建设可持续、可复制、可推广，为创新领域和关键行业的智能化转型夯实基础。 图 1 高质量数据集典型建设思路 坚持“价值驱动，场景牵引”，实现数据集建设靶向聚焦 以行业真实业务痛点和应用场景为原点，构建从需求反推数据供给的闭环建设逻辑。这一路径通过深入挖掘垂直领域的核心诉求，精准定位数据资源的价值锚点，避免“为建而建”的资源错配，优先突破人工智能应用最迫切、最容易产生效果、最影响行业高质量发展的领域。在实践中体现为三重协同机制 : 业务需求精准映射、场景化数据供给和动态反馈调优机制。这种价值驱动的建设范式，从根本上改变了传统“数据先行、应用滞后”的粗放模式，使数据集成为破解行业瓶颈的战略工具。正如《“数据要素 ×”三年行动计划（2024—2026 年）》所要求的：需“围绕应用需求牵引、典型场景切入”，最终实现数据资源向生产力要素的高效转化。 强化技术牵引，构建先进敏捷的数据开发能力体系 以大模型、数据合成、超智融合算力等新一代人工智能技术为支撑，创新数据开发模式与技术路径。依托大规模异构算力平台，建立多模态并行处理与加速机制，全面提升数据处理效率与数据质量控制能力。引入大模型自动标注与人机协同能力，在图像、语音、视频等复杂模态上应用预训练模型进行智能标注与初步语义聚类，大幅减少人工成本、提升标注一致性。同步开展数据增强与生成技术研究，通过仿真生成、时序数据合成等手段扩展样本覆盖度，提高长尾问题覆盖能力。围绕高质量训练数据构建目标，集成清洗、脱敏、合规校验、标签审核等自动化工具链，建立敏捷迭代的“采—标—检—训”闭环开发体系，确保高质量数据集供给的稳定性与适配性。 突出数据支撑，夯实多模态、多源异构数据治理基础 构建覆盖数据采集、汇聚、管理、调用的全过程数据治理体系，支持结构化数据、图像视频、音频语音、传感数据等多种模态的统一接入、分级治理与标准转换，打通源系统与训练平台之间的“数据断点”。推进“原始数据—预处理数据—训练数据”三层架构设计，配套元数据管理、数据血缘追踪、数据质量监控等机制，确保数据资产可追溯、可评估、可调优。在全生命周期管理基础上，构建面向不同训练目标的主题化数据仓库，支撑预训练集、微调集、测试集、验证集四类数据集的按需编排与快速交付。 坚持标准引领，形成可迁移可复用的数据集建设规范 围绕数据集“可交付、可训练、可迭代”三大目标，同步推进采集、标注、元数据、注释、脱敏、安全等关键环节的标准体系建设，建立覆盖“源头—处理—交付—调用”的全链路高质量数据集建设标准，形成一整套可迁移、可扩展、可复制的操作规范体系。重点验证数据基础设施建设的接口规范、用户身份管理、接入协议、标识规则、目录描述要求等通用技术要求，并对数据格式、分类指南、质量评估、平台管理等关键领域的标准化要求进行实际对接和测试，打通构建、治理与共享之间的关键环节。 完善协同机制，保障高质量数据集长效运营与推广 构建多主体参与的数据集共建共享机制，形成“行业主导、平台承载、企业参与、多元共赢”的生态格局。以数据资产确权、使用授权、成果收益等机制为核心，推动建立多元共建、共享开放的数据供给模式，激发数据持有方参与积极性。构建基于项目制和联盟制的数据集协同开发模式，实现区域间、企业间的数据流动，促进高质量数据集的跨域融合与能力复用。同时，构建“共建 + 共评 + 共用”的联合攻坚机制，明确各参与方责任边界与数据权益分配方式，为高质量数据集的规模化建设与可持续运营提供保障。 推广建设模式，形成高质量数据集复制推广新范式 坚持“试点先行、模块化拆解、生态化复制”的原则，推动建设成果的广泛推广和应用。围绕“数据集建设技术体系、标准规范体系、平台工具体系、运营治理机制”四大方面，推动“数据采集—清洗标注—平台建设—模型训练—应用落地”的全流程闭环体系在行业内外复制部署。 高质量数据集的业务蓝图 高质量数据集的逻辑架构主要包括数据源、数据集构成，核心是持续生产能够匹配不同行业、领域的大模型进行训练，如图 2 所示： 图 2 高质量数据集的逻辑架构 参考国家高质量数据集建设指南和相关标准，高质量数据集的业务蓝图主要包括行业高质量数据集及场景应用、数据集开发运营平台、数据基础设施与安全设施、标准机制验证及提升推广体系、价值贡献与权益分配机制等五大部分，如图 3 所示： 图 3 高质量数据集的业务蓝图 笔者以某交能融合链主型企业申请的行业高质量数据集为例，阐述每一部分的建设内容： 高质量数据集及场景应用 该企业通过开拓新能源及车网互动、智慧交通等业态，在业务创新的同时，利用边缘计算、物联网、移动互联网等技术，采集沉淀了大量的数据。同时结合大数据、大模型、人工智能技术，探索了多个创新场景，从而具备了从数据到价值的链路闭环。一方面，这些数据源能够为高质量数据集提供源源不断的数据；另一方面，众多的应用场景又能支撑大模型的应用价值，从而构建了多模态、多行业和多功能数据集，并且赋能 N 个应用场景。 图 4 某交能高质量数据集及场景应用 数据集开发运营平台 高质量数据集的构建不是一蹴而就的，更不是一劳永逸的，而是一个持续性的运营业务，需要通过“数据需求—规划—采集—预处理—标注—模型验证”，形成一个端到端的闭环，并且利用运营真正吸引数据集的供需双方，从而实现从技术到商业、从数据到价值，打造可持续发展的健康商业模式，实现数据“供得出、流得动”。高质量数据集本质上是一个训练大模型数据的生产线，能够持续不断地获取、加工，给大模型训练供给高质量数据。这个生产线包括八大模块，即运营门户、数据需求、数据规划、数据采集、数据预处理、数据标注、数据验证和技术底座。 图 5 某交能高质量数据集开发运营平台 数据基础设施与安全设施 高质量数据集是战略项目，关乎国家信息安全，因此打造一个牢固坚韧安全的基础设施是重中之重。该企业构建了网络预调度体系、存储与计算资源池、数据采集与边缘处理设备为核心的基础设施，同时全链路配套数据脱敏与加密，权限分级与行为审计，安全边界防护、风控预警与应急响应机制，对关键数据进行分域分级保护，从而实现数据的“保安全”。 图 6 某交能高质量数据集基础设施与安全设施 标准机制验证及提升推广体系 高质量数据集的建设还处于早期阶段，尚未形成成熟可复制的统一模式，所以在遵循一些新标准的同时，还需要对这些标准进行验证，并且探索提升和推广体系，从而让后续的建设运营有章可循、持续优化。这方面主要包括从标准执行到标准验证、标准反馈和标准优化的全体系建设，从而能够在不断提升数据集质量的同时，也能够更好的赋能行业。 图 7 某交能高质量数据集标准机制验证及提升推广 价值贡献与权益分配机制 高质量数据集建成发布后，就会面临价值贡献如何评估、权益收益如何分配的问题。并且只有价值贡献评估客观、公平，权益分配机制遵循“谁贡献，谁受益”的原则，才能够让数据集保有持续的生命力，接入更多有价值的数据源，吸引更多大模型训练方。价值贡献与权益分配机制的建立主要包括三部分内容：数据使用授权机制、数据及服务交易机制、收益分配机制，这些机制能够推动高质量数据集可持续健康发展。 图 8 某交能高质量数据集价值贡献与权益分配机制 高质量数据集的典型建设路径 高质量数据集的建设路径是一项涵盖数据全生命周期的系统工程，需严格遵循规范化的流程框架并结合场景化落地策略，其,核心步骤可归纳为六个阶段，各阶段环环相扣且需动态迭代优化。 数据需求定义（战略锚定与标准构建） 该阶段需从业务场景出发，明确数据集的战略定位与技术规格。依据《高质量数据集建设指南 ( 征求意见稿 )》，需完成三项关键任务：场景化需求分析，针对行业痛点精准锚定数据价值，如金融风控数据集需聚焦欺诈交易特征识别。胡坚波强调需“从医疗、教育等亟需领域切入，避免盲目跟风”，此过程需联合领域专家建立数据质量模型，界定关键指标；数据可获得性评估，预判行业知识壁垒与技术难度，如核电诊断数据集需协调央企设备日志与安全规范；标准化框架设计，基于全国数据标准化委员会的“三类分级”规范（通识 / 行业通识 / 行业专识），定义数据结构与元数据标准。 数据规划（架构设计与资源调配） 本阶段需将需求转化为可执行蓝图，主要包括三大工作内容：一是架构设计，规划存储、计算、安全三大体系，例如深圳交通行业高质量数据集，采用信创云平台整合库表管理、任务调度功能，实现 607TB 视频数据的分布式存储；二是质量计划制定，设定数据清洗、标注精度等 KPI，如医疗数据清洗后错误率需压降至 0.001% 以下以规避模型误判风险；三是工作量预估与资源分配，测算采集标注成本，调配领域专家资源。苏州丝绸纹样数据集建设时整合 222 件文物数字化团队，工作量精确至样本 / 小时级。 数据采集（多源获取与质量控制） 采集过程需融合技术合规“双约束”，多模态采集技术应用，典型的数据集项目采用“前置交换 + 物联网感知 + 互联网爬取”复合方式，归集视频、GPS 等数据。在采集过程中要注意两大保障：质量保障，通过自动化校验规则（如交通视频帧重复率检测算法）拦截无效数据，原始数据清洗率超 30%；合规性保障，严格遵循《数据安全法》，核电数据采集采用“私有化部署 + 区块链溯源”机制阻断敏感信息泄露。 数据预处理（特征强化与噪声剔除） 本阶段决定数据集信息密度，主要的核心操作包括转换验证，例如统一时空坐标；聚合清洗，剔除冗余记录；特征工程，例如金融交易数据经特征选择后，欺诈特征维度浓缩至原始数据的12%，实现高密度表征；样本平衡，采用 SMOTE算法扩增工业设备故障样本。 数据标注（知识注入与精度控制） 标注环节是价值升华的关键，由多级标注体系构成，行业专识数据需领域专家介入，如核电设备诊断标注由工程师定义故障阈值；人机协同机制，采用“预标注 + 人工核验”模式；元数据绑定模式，例如丝绸纹样数据集中每样本关联织造年代、工艺等 32 项元数据，支撑跨产业复用。 模型验证与迭代优化（闭环反馈） 该阶段实现数据价值闭环：基准验证，数据集需通过模型性能测试，如金融数据集使风控模型误报率降幅≥ 55% 方达交付标准；持续优化机制，依托评测工具集监测数据漂移，如深圳交通数据集每季度更新 15% 样本以适配路网变化；跨域流通激活，运用隐私计算技术打通医保—交通数据壁垒，催生慢病出行预警等创新应用。 在当前人工智能从“模型优先”向“数据优先”转型的关键阶段，高质量数据集已成为赋能产业智能升级的战略基础设施和国家数字竞争力的核心支柱。通过系统化构建“价值驱动、技术融合、标准引领、生态协同”的建设体系，我国正加速打通从数据资源到智能应用的闭环路径——以《高质量数据集建设指南 ( 征求意见稿 )》为规范框架，以“数据要素 ×”三年行动计划为实施蓝图，推动金融、医疗、交通等高价值领域实现“原始数据炼化—特征提纯—模型赋能”的质效跃升。未来，随着全生命周期管理、多模态治理、权益分配三大机制的完善，高质量数据集将持续释放三大战略价值——筑牢人工智能技术根基的“护城河”，激活数字经济新质生产力的“新引擎”，以及构筑科技自主可控的“安全壁垒”，最终支撑我国在全球智能时代从数据规则的“接受者”迈向标准制定的“主导者”，真正实现数据要素向创新动能的系统性进化。 （作者史凯单位：精益数据方法论创始人、中国计算机学会数发委执行委员，作者杨慧娟单位：深城交数研智算 PDT、资深数字化顾问。本文刊发于2025年第8期《信息化建设》杂志。） 来源（公众号）：浙江数字经济
引言 数据驱动决策一直在各行各业中至关重要，业务分析师常常面临繁重的数据查询任务。通过自然语言生成结构化查询语言（SQL）的技术，即NL2SQL，业务分析师不再需要掌握复杂的编程技能，便能够轻松访问和处理数据。这篇文章将探讨如何利用NL2SQL技术来自动化处理常见的数据查询任务。 想象一个典型的场景：一位业务分析师需要提供上个月销售额最高的前10个商品。如果用传统方法，首先分析师需要知道销售额相关的基础数据表是哪些，接着得确认销售额的具体口径定义，最后需要按照一定方式编写复杂的SQL查询得到结果。这不仅需要对SQL语言有深刻的理解，还要对指标的定义、业务数据来源非常熟悉。 如果将NL2SQL技术和日常数据分析结合。可以帮助业务分析师显著减少完成数据分析所需的时间，同时还可以借助NL2SQL纠正发现语法问题减少人为错误，甚至即使没有技术背景的用户也能通过自然语言简单地进行复杂的数据查询，提高运营自助分析查询的效率。 技术背景与发展历程 ▐ 2.1 问题定义 什么是NL2SQL NL2SQL是"Natural Language to SQL"的缩写，指的是将自然语言查询转化为SQL查询语句的技术。它主要用于将用户以自然语言提出的问题自动转换成能够被数据库系统理解并执行的SQL查询，从而实现从数据库中检索相关信息的目的。 问题拆解 语义理解 自然语言通常具有很高的复杂性和多义性。语义理解要求系统能够准确地捕捉用户查询的意图，并处理自然语言中的模糊和歧义。这包括理解自然语言中的上下文、处理指代、识别关键实体和关系，以及解析复杂的句子结构。 Schema映射 Schema映射涉及将自然语言查询映射到数据库模式中的具体表和列。数据库的模式通常非常结构化，而自然语言查询可能没那么直接地指明这些结构。例如，一个查询可能使用同义词或间接提及而不是明示的列名或表名。系统需要具备将自然语言中提到的概念正确映射到数据库结构上的能力。 SQL生成 SQL生成是将处理过的自然语言意图和映射到数据库元素的信息转换为合法的SQL查询的过程。生成的SQL不仅需要语法正确，而且在语义上准确地代表原始的用户需求。挑战在于生成的SQL需要处理不同的查询形式和复杂度，包括聚合、嵌套查询、连接等功能。此外，生成的SQL必须满足高性能、合规性和安全性问题。 核心挑战 语法正确 数据库架构本身的复杂性和庞大体量的数据对NL2SQL构成了明显的挑战，比如数据库语法的多元性、表之间的关系复杂性、列名的相似性、以及大数据量的不完整性。 语义正确 自然语言可能因歧义和不明确性而含有不确定性，例如词义歧义、句法歧义、信息不足和用户错误。与此同时，当实际应用到业务场景时，不同团队对同一术语的定义也可能不同。比如“成交”可能意味着产生订单，也可能意味着必须支付。 效果稳定 NL2SQL与编程语言不同，因为输入的NL和输出的SQL查询之间通常存在一对多的映射。即使是完全一样的问题，也可能输出各种不同的SQL结果。 ▐ 2.2 发展历史 基于规则的方法 早期研究主要集中在使用预定义规则或语义解析器来理解自然语言查询并将其转换为SQL查询。 基于神经网络的方法 为了解决基于规则的方法的局限性，研究者开始利用神经网络来解决NL2SQL，例如使用序列到序列模型或图神经网络。 基于预训练语言模型的方法 随着BERT和T5等预训练语言模型的出现，基于PLM的NL2SQL方法在多个基准数据集上取得了显著的性能提升。 大型语言模型时代 随着LLMs的出现，NL2SQL技术取得了显著进展，LLMs具有卓越的语言理解和新出现的能力，例如使用提示来执行NL2SQL任务。 关键技术挑战与解决方案 ▐ 3.1 Schema Linking（模式链接） Schema Linking旨在理解自然语言查询与数据库模式（schema）之间的语义关系，以帮助生成准确的SQL查询。 自然语言问题 → 表选择器 → 相关表集合 → 列选择器 → 最终SQL 检索模块 用户提问—>含有小样本的命名实体识别prompt+LLM—>得到关键词和实体—>根据关键词的语义相似性匹配top k列 | 基于局部敏感哈希 (LSH) 和语义相似性的两阶段检索策略检索值—>得到最终列和值 表选择器 表选择器的作用是识别哪些表与查询最相关，并需要在SQL查询中用到。 表选择器通常通过以下几步实现： 自然语言理解：分析用户的查询，提取关键实体和操作动词。 Schema 分析：了解数据库模式中有哪些表、字段以及它们之间的关系。 语义匹配：将用户查询的关键部分与数据库的表和字段进行匹配，以识别相关的表。 表优先级排序：根据相关性对表进行排序，优先选择最相关的表参与SQL构建。 列选择器 含有小样本的prompt+LLM—>仅选择与用户提问最相关的最少列。 ▐ 3.2 复杂查询理解 Chain-of-thought（CoT） 思维链（CoT）与大型语言模型（LLM）相结合，能在复杂的推理任务上取得了不错的结果。 Divide and Conquer CoT（分而治之CoT）：让模型把查询任务拆解成更细粒度的任务，然后用SQL伪代码写出对这些子任务的查询，最终将结果合成一个完整的SQL。直接写SQL效果不好是因为模型可能没有见过这样的数据分布，但是它肯定见过简单任务的数据分布，在SQL子语句都写出来了的前提下，SQL的组合就显得没那么复杂了。 Query Plan CoT（查询/执行计划CoT）：让模型先把SQL的执行计划描述出来，再通过执行计划来生成SQL。这么做可以让模型换个角度思考问题，将数据分布切换到了另外一个领域，能让模型更多地关注具体要用的表、列，能补足“分而治之”方法对细节把控不足的缺点。 ▐ 3.3 提示词工程 在利用LLM完成NL2SQL任务时，提示工程的关键在于将自然语言问题与必要的数据库信息转化为适用于LLM的自然语言序列输入，即问题表示。同时，当允许输入一些样例以利用LLM的in-context learning能力时，还需要考虑如何选择样例以及如何将这些样例有机地组织到输入序列中。 基本提示 基本提示（Basic Prompt）是一种简单的Prompt模板，它由表模式、以 Q: 为前缀的自然语言问题、以及提示LLM生成SQL的响应前缀 A:SELECT 组成。之所以命名为基本提示，是因为它并未包含任何指令内容。 文本表示提示 文本表示法提示（Text Representation Prompt）相比于基本提示，在提示的开头添加了指导LLM的指令。 OpenAI范式提示 OpenAI示范提示（OpenAI Demostration Prompt）首次在OpenAI的官方NL2SQL演示中使用，它由指令、表模式和问题组成，其中所有信息都用“#”进行注释。与文本表示提示相比，OpenAI示范提示中的指令更具体，而且还有一条规则约束，“仅完成sqlite SQL查询，无需解释”。 代码表示提示 代码表示提示（Code Representation Prompt）是一种基于SQL语法实现NL2SQL任务的方式。具体来说，它直接将表创建语句“CREATE TABLE …”放到Prompt中。相较于其他的问题表示方法，代码表示提示的独特之处在于，它能够提供创建数据库所需的全面信息，例如列名、列类型、主键/外键等。 通用方案总结 综合考虑上述Prompt策略，可以总结出一套通用且有效的NL2SQL Prompt策略。这一策略由六个关键要素构成，每个要素在提升模型生成SQL的准确性和效率中发挥着重要作用。以下是各个要素的详细说明： 指令（Instruction）：为模型提供清晰而具体的指导方针。例如，"你是一个SQL生成专家。请参考如下的表格结构，直接输出SQL语句，不要提供多余的解释。" 数据结构（Table Schema）：类似于语言翻译中的“词汇表”，这是你需要嵌入到Prompt中的数据库表结构。由于大模型无法直接访问数据库，你需手动提供包括表名、列名、列的类型、列的意义，以及主键和外键信息。 参考样例（Sample）：这是一种启发模型生成SQL的可选技巧。你可以提供一个类似任务的SQL样例作为参考，以帮助模型更好地理解应该如何构建查询。 其他提示（Tips）/约束条件（Constraint）：这些是你认为必要的额外指示。例如，要求生成的SQL中不允许出现某些表达式，或者要求列名必须采用“table.column”的形式。 领域知识（Knowledge）：在某些特定问题中，这是一个可选要素。例如，如果用户的问题涉及“谁是这个月最厉害的销售”，你需要告诉模型，“最厉害”是指“销售单量最多”还是“销售金额最多”。 用户问题（Question）：这是以自然语言形式表达的查询需求，如“统计上个月的平均订单额”。这一部分用于明确用户的意图和需求，以便模型生成正确的SQL语句。 ▐ 3.4 多轮对话 SQL 候选生成和优选 候选生成（Candidate Selection）是为了从候选SQLs中选出最好、最正确的一个，常见方法包括： self-consistency。以N个候选SQL中最常见的（非空）答案为准 selection agent。用模型来挑选最好的SQL，可以用提示词或fine-tuning等技术 基于Unit test。参照AI coding，生成Unit Tests，用来评估每个candidate SQL的得分 SQL 语法微调 采用SFT方法，通过微调小参数量模型来生成可控的SQL查询。然而，参数限制使得复杂的推理和领域的迁移变得困难。此时可以聚焦于生成高精度、多样化的SQL候选语句。 基础语法训练：这一阶段专注于使用简单且通用的SQL模式和语法对预训练模型进行微调，不涉及具体SQL方言。其目标是开发一个能够激活SQL生成能力的基础模型。 生成增强训练：在基础训练后，通过多任务和句法偏好数据增强模型能力。除了标准的查询生成，还可以额外设计SQL转换任务以深化SQL与问题间的关系。这包括从SQL推断问题、从SQL选择证据及其优化任务。这些任务加强了SQL与上下文信息的关联性，提高了SQL生成的广泛性和多样性。通过不同风格的句法特征，扩展训练样本，使模型从多样化数据中学习，从而生成更丰富的SQL查询。 SQL 查询优化 生成的候选SQL查询不可避免地包含逻辑或语法错误。通过利用这些SQL查询缺陷中的线索，进行一定程度的修正。为此，可以引入一个SQL优化器来优化生成的SQL。在实际应用中，基于与架构相关的上下文、生成的SQL查询以及执行结果（包括潜在的错误信息），可以使模型能够进行第二轮的修正。原始SQL和重新生成的SQL还可以进一步通过选择模型进行最优选择，这一过程可以迭代执行。 ▐ 3.5 检索增强生成（RAG） 简单来讲，RAG技术就是通过检索获取相关的知识并将其融入Prompt，让大模型能够参考相应的知识从而给出合理回答。因此，可以将RAG的核心理解为“检索+生成”。而在上文的「提示词工程」章节我们可以看到，为了提高NL2SQL生成的SQL质量，需要在提示词中加入业务领域知识、表知识（Scheme）和列知识（Indicator），甚至是一些样例（Examples）问题便于query改写。而这往往又会造成提示词过多造成的上下文token不够的问题。因此，如果能将这些知识都转换成即时查询的方式，可以有效解决上下文token过大的问题。 在NL2SQL场景中，以下关键步骤可以借助RAG提高效率： 领域知识查询： RAG可以利用预训练模型和检索技术相结合，帮助理解用户的查询所涉及的领域或上下文。通过从相关文档或数据库检索信息，RAG可以为生成更精确的SQL语句提供背景知识。 具体应用包括根据领域特定的术语或概念检索相关信息，从而帮助系统更好地理解和处理复杂或专业的查询。 表查询： 在生成SQL查询时，正确选择和理解数据库中的表是至关重要的。 RAG可以通过检索数据库的元数据或相关文档，帮助识别合适的表及其结构。 指标查询： 对于用户查询中涉及的各种指标，例如计算平均值、总和、最大值等，RAG可以帮助检索相关的计算逻辑或历史数据。 RAG能够从过去的查询实例或相关文档中提取信息，帮助提高生成查询的准确性和效率，尤其是在复杂计算的场景中。 ▐ 3.6 NL2Semantic2SQL 除了从数据库和SQL层面思考如何提高NL2SQL的准确性，还可以从增加语义理解层来思考解决方案。因为如何将用户模糊、多变的业务意图如何精准、高效地映射到企业复杂的数据资产中？这一问题本身就是数据工程问题，而非单纯的 AI 问题。 可以通过如果额外引入一层语义层来更好的解决NL2SQL问题。语义层需要有以下特征： 统一的业务语义抽象层，作为Agent和开发人员共同理解的“数据语言”； 强大的元数据管理能力，确保指标定义的唯一性、透明性和可追溯性； NL2Semantic2SQL 技术路线通过引入语义层作为中间抽象，大幅提升了系统的灵活性和可解释性。指标平台采用"度量"和"维度"两大基础要素，并运用"基础度量"、"业务限定"、"时间限定"和"衍生方式"四大要素，灵活定义和组合具有明确业务含义的指标，打造了一个统一的语义模型。自然语言查询首先被转换为语义表示，然后由系统基于语义模型生成最优SQL查询。 这种语义与表结构的解耦设计，使系统能够理解指标的业务意义，而不仅仅是表结构，确保在不同场景下，同一指标的口径保持一致性。随着业务规则的变化，只需调整语义定义，无需修改所有相关表或查询，显著提高了系统的适应性。 语义层的引入是 NL2Semantic2SQL 相对于传统NL2SQL的核心优势。它不仅提升了查询的准确性，还增强了系统的可解释性，赋予业务人员更强的自助能力。通过构建统一的业务语义模型，指标平台有效地跨越了技术与业务之间的鸿沟，使业务人员可以直接理解和使用数据，而无需深刻掌握SQL语法。 ▐ 3.7 半结构化的数据库表达 scheme LLM专属注释 正如上文所说，在使用基于LLM的NL2SQL技术时，为了使模型能够准确理解数据表的含义和列名的表示，建议为常用的数据表及其列添加注释。 表注释有助于模型更好地理解表的基本信息，从而在生成SQL语句时准确定位相关表。注释应简单明了，概括表的核心内容，如订单、库存等，并建议控制在10字以内，以避免过多解释。 列注释通常由常用名词或短语构成，例如订单编号、日期、店铺名称等，以准确表达列名的意义。此外，可以在列注释中包含列的示例数据或映射关系。例如，对于列名“isValid”，注释可以写成“是否有效。0：否。1：是。”以清楚地表示该列的含义和数值对应关系。 但是传统的数据库表注释和列注释可能已有一定的含义和上下游对接规范，所以目前有些数据库可支持scheme维度LLM专属的注释，用于提供NL2SQL时获取表和列的提供便利。比如阿里的PolarDB，开源的M-Schema项目。 来源（公众号）：大淘宝技术
2025上半年，DeepSeek大模型以“免费开放+开源生态”迅速占领技术圈，其强大的自然语言理解、代码生成、数据推理能力，正在重塑企业数据仓库的运作逻辑。
来源（公众号）：大数据AI智能圈 周一早上，销售总监急匆匆跑到你办公室："我们需要分析一下华东区域的客户画像，制定下季度的营销策略。" 你打开CRM系统，发现客户信息不全。打开ERP系统，发现交易数据格式乱七八糟。再打开财务系统，发现同一个客户竟然有三个不同的编号。 这就是数据孤岛的真实写照。每个系统都在自己的小王国里称王称霸，互不往来。你想要的那个"完整的客户画像"，就像拼图游戏一样，碎片散落在各个角落。 数据孤岛的隐性成本，远比你想象的高 让我给你算一笔账。 某制造企业的采购经理小王，每次采购都要花2小时核对供应商信息。同样的供应商，在不同系统里有不同的编码、不同的名称、不同的联系方式。 小王说："我感觉自己不是在采购，而是在做侦探工作。" 这还不是最糟糕的。更要命的是，错误的数据会导致错误的决策。 去年，一家零售企业的市场部门，基于不准确的客户数据，投入了500万做精准营销。结果呢？转化率只有预期的30%。后来才发现，他们的客户数据有40%是重复的，30%是过期的。 你看，数据质量差不仅仅是技术问题，它直接影响的是你的钱包。 更可怕的是，在数字化转型的今天，数据已经成为企业的核心资产。 如果你的数据还在"各自为政"，那你的竞争力就会被严重削弱。 AI重新定义主数据管理的游戏规则 传统的主数据管理，就像是让一群人工编辑去整理图书馆。 他们需要逐本逐页地检查、分类、整理。工作量大，效率低，错误率高。 AI的出现，完全改变了这个游戏。 如果此时，你有一个超级智能的助手，它可以： 自动识别和清洗数据。它能瞬间发现"苹果公司"和"Apple Inc."其实是同一家公司，能自动修正"138****1234"这种不完整的电话号码，能识别出哪些是重复数据、哪些是异常数据。 智能关联不同系统的数据。它能像侦探一样，通过各种线索（姓名、电话、地址、交易记录等）找到散落在不同系统中的同一个客户信息，然后把它们完美地拼接在一起。 实时监控数据质量。它会24小时不间断地监控你的数据，一旦发现异常，立即发出警报。就像是给你的数据安装了一个"健康监测器"。 这已然不是科幻小说，这是正在发生的现实。 从案例看AI+主数据的真实威力 让我跟你分享几个真实案例。 案例一：全球消费品巨头的数据整合 这家公司在全球有200多个分支机构， 数据散落在几十个不同的系统中。传统方法需要几百个人工作一年才能完成数据整合。 AI介入后，3个月就完成了全球数据的统一管理。数据质量提升了30%，决策效率提高了15%，运营成本降低了10%。 更重要的是，统一的数据视图让他们能够更好地理解全球客户需求，制定更精准的产品策略。 案例二：零售企业的精准营销 某大型零售企业面临的问题是：客户数据质量差，营销效果不理想。 AI帮助他们整合了来自线上线下的所有客户数据，构建了完整的客户画像。系统能自动识别客户的生命周期阶段，并推荐相应的营销策略。 结果：营销转化率提高了20%，客户满意度提高了15%，销售额提升了10%。 案例三：金融企业的风险管控 金融行业对数据安全和合规性要求极高。传统的人工监控方式既费时又容易出错。 AI系统能实时监控所有数据访问行为，自动识别异常操作，确保数据合规性。这家企业的数据安全风险降低了20%，合规性提高了15%。 你看到了吗？ AI+主数据不仅仅是技术升级，它是商业模式的根本性变革。 结语 AI技术还在快速发展。 未来的AI+主数据管理会变得更加智能、更加自动化。 现在的问题是：你的企业准备好迎接这个变革了吗？
