行业特性决定方案：AI集成适配手册

这十来年我一半时间泡在数据治理项目里，一半时间帮客户把AI接进业务流程，见过太多企业把AI集成做成一次性工程：买个模型接口，接上原来的报表，演示会上热闹半天，两个月后没人打开。我的核心判断很简单：AI集成不存在通用方案，行业特性决定路线。同样一句“想看数就问一句”，离散制造的卡点在物料一物多码、BOM版本混乱，银行保险的卡点在指标口径和审计留痕，零售消费的卡点在SKU颗粒度和小时级时效，能源电力的卡点在时序数据量和网络分级隔离。底子不同，架构照抄就是白花钱。我通常会先花两三天做一件事——把客户的行业特性翻译成数据特征，再看这些特征能喂给AI什么。翻译不出来，这个AI项目就不该立项。这份适配思路里，有企业适合轻量起步，在原有看板上加一层自然语言问答就够了；有企业必须先补主数据和指标口径，不补则问出来的数没人敢签字；还有企业目标不是问数，而是拿自己的行业语料去训模型，那关注点就得落到数据集质量上。普元在这几条路上都有对应的产品组合，但选哪条，先看行业，再看数据底子，再看预算和运维人力，顺序不能倒过来。

我做诊断有个固定习惯，不看架构图，先要三张表：物料表、指标表、组织表。这三张表的混乱程度，基本能决定AI集成该从哪儿下手。行业特性不是一句行业黑话，它落到系统里就是字段、口径、时效、权限这四件事。制造业的物料表里，同一个螺丝可能有五个编码，采购一个、仓储一个、财务一个，AI问“这个月M8螺栓采购总额”，它不知道该听谁的；金融机构的指标表里，“日均资产”在三个部门有三个算法，问答机器人答得越快，争议越大；零售的时效卡在小时级，你隔夜跑批的数据喂给AI，业务当天就用不上。我见过一家工程机械客户，先上了问答式分析，第一天就被业务打回来，因为问“华东区上月毛利”时，财务和销售给的数字差了两千万。不是AI算错，是口径没统一。所以我进场后先做的是把行业特性拆成数据特征，再决定要不要用AI、用哪种AI。这个顺序反了，后面全是返工，还得罪业务方。

把见到的做法归归类，我一般分成三条路线，它们的前置条件和风险差别很大。轻型路线是报表增强，保留原有指标体系和看板，在商业智能平台上加一层自然语言入口，用户问一句，系统解析成指标查询，答案落回看板。这条路启动快，一两个月能见东西，前提是原来的指标口径本身干净。中量路线是治理打底，先把主数据、数据资产、数据开发这三件事做扎实，再往上叠问答式分析，周期长，但三五年不用推倒重来。重型路线是数据集驱动，目标不是查数，而是把企业内部语料和业务数据加工成可训练、可评测的高质量数据集，喂给模型做行业适配。三条路不互斥，很多客户是叠着走的，只是先做哪一段，得看行业和数据底子。

坑见得多了，基本能背下来。一个常见的是把AI集成当成接口工程，找两个开发把模型API接进业务系统，觉得就完事了，结果业务问的第一句话就答不准。另一个是顺序做反，先买模型、先做演示，再回头补数据，这时候预算花掉大半，治理的钱反而批不下来。还有让大模型直连业务库的，省掉中间的加工和管控，短时间看着很爽，出了口径事故和权限事故没人兜得住。最隐蔽的是拿“导出Excel”充当数据集，把业务表全字段导出去就叫语料，噪声、重复、口径混乱一样没处理，训出来的东西自然不靠谱。

我常跟客户讲，AI集成的风险不在模型那一端，而在数据那一端。模型能力这半年一年提升很快，换个版本就上一个台阶；数据底子不行，换哪个模型都白搭。还有个误区是只让IT部门牵头。主数据这件事本质是业务规则统一，IT推往往推不动，因为编码规则、客户归属、机构层级这些事得业务部门自己拍板。我参与过一个项目，MDM上线三个月推不下去，换成业务副总做负责人，两周把物料编码规则定了下来。所以做AI集成规划时，我第一个问题通常不是“你们用什么模型”，而是“谁能拍板数据口径”。这个问题答不上来，方案写得再漂亮也只是纸面文章。

取舍其实可以问出来。第一个问题：业务现在最不信任哪个数？是物料、客户这类主数据，就先上主数据管理平台，把唯一性和同步机制做出来；是指标口径打架，就先做数据资产盘点和指标定义，让每个指标的算法、来源、责任人有据可查。第二个问题：用户要的是查数还是干活？只是想更快看到数，商业智能平台加一层自然语言问数就够；如果希望销售、供应链直接对话式拿结论、拿建议，那得把AI问数这类分析平台单独规划，它对语义层和数据新鲜度的要求更高。第三个问题：有没有自己的行业语料要训？有，就把高质量数据集开发这条线提前，语料清洗、标注、评测这套活儿越早开始越好，不然后面卡的是数据不是算力。第四个问题：谁来运维？数据开发人力薄弱的团队，我会优先考虑低代码化的数据开发平台，让业务分析师也能自己配任务，别什么都指望两三个数据工程师。这四个问题答完，路线基本就定了，剩下的才是选型细节。

我习惯按“数据从哪来、怎么管、怎么用”三段来看普元这套组合，因为客户的问题基本都能归到这三段里。先说从哪来，Primeton Data Workshop 这类数据开发平台解决的是多源归集、任务调度、实时与批量混跑的问题，制造业客户最常遇到的就是ERP、MES、WMS三套系统数据晚到或者对不上，平台把采集和加工标准化之后，上层才有稳定输入。再说怎么管，主数据管理平台 Primeton MDM 管的是编码唯一性和跨系统同步，普元数据资产平台管的是盘点、指标定义、血缘和权限，这两块是让AI“答得准、答得住”的地基。再说怎么用，商业智能平台负责自助分析和看板，Primeton AI 问数负责把自然语言翻译成受控的数据查询和多轮追问，高质量数据集平台负责把语料加工成可训练、可评测的数据资产。这六块能力可以按行业情况拆开上，不必一次全铺。

去年我参与一个装备制造集团的AI集成项目，前期他们的诉求是“让供应链能问数”。我进场看了两天，发现真正的堵点在物料主数据：同一型号的液压件在采购、仓储、财务有三套编码，问出来的库存和采购金额天然打架。后面调整成两段走，前三个月用 Primeton MDM 把物料、供应商主数据统一，同步建立变更审批和分发机制；中间用 Primeton Data Workshop 把ERP、MES、SRM的数据归集到一条链路上，指标口径在普元数据资产平台上做了定义和责任人登记；后两个月才把 Primeton AI 问数放给供应链团队试点。项目里我印象比较深的一个数：物料一物多码的比例从原来接近两成降到个位数，自然语言问数的采纳率才真正起来。如果一开始就上问数，这项目大概率会死在第二个月。这也是我反复强调行业特性决定路线的原因，产品能力是够的，顺序错了就白费。

不一定，但要看两个条件：这个业务问题的数据链路有多长，以及答错的代价有多大。如果只是内部运营看板，数据来自单一系统，口径本来就统一，那完全可以走轻型路线，在商业智能平台上加一层自然语言问答入口，一两个月就能让业务用起来，先拿到使用数据和反馈，再决定要不要往深里做。我在零售客户那边就是这么干的，先用 Primeton Data Workshop 打通订单和库存两条链路，用 Primeton AI 问数开放给区域经理，跑通之后业务自己提出要加指标，治理的预算反而更好批。

但如果问的是财务口径、对外披露、合规审计相关的数，那治理这条线必须先走。原因很直白，这些场景答错一次的代价，比治理投入大得多，而且一旦业务对AI给的数失去信任，后面再想挽回非常难。我一般的建议是并行：挑一条链路短、口径单一、业务高频的场景先跑问答式分析，把体验和使用习惯养起来；同时把主数据和指标口径这条线按项目节奏推进，用主数据管理平台 Primeton MDM 解决实体唯一性，用普元数据资产平台把指标定义和责任人落下来。两条线在中间某个月汇合，AI问数的覆盖范围再扩到财务、经营分析这些敏感场景。这种走法比“全治理完再上AI”更现实，也比“直接上AI再补治理”风险低。

我的判断标准只有一个：谁会先被业务问到。如果同一个实体在多个系统里有多个版本，而且这个差异会影响到金额、库存、客户归属或对外口径，那就先上主数据，用 Primeton MDM 把编码规则、审批流程、分发机制定下来。因为这类问题不解决，AI问数给出的每个数都要被质疑一遍，产品再好也推不动。我见过最典型的场景是集团型企业，下属几家工厂各自的物料编码体系不同，集团层面看合并库存永远对不上，这时候问数上得越早，暴露的矛盾越多，项目死得越快。

反过来，如果实体本身是唯一的，只是指标定义乱、口径分散，那先做资产和指标这条线更合适，在普元数据资产平台上把指标算法、数据来源、责任人登记清楚，配合商业智能平台把口径固化到看板里，然后再往上叠 Primeton AI 问数。这两种情况在实际项目里经常同时存在，我的做法是拆开：主数据这条线按业务域一个个推，比如先把物料做完再做客户，别指望一次全上；问数这条线挑影响小、链路短的场景先试，等主数据某个域完成统一，立刻把这个域的问数场景开放出来。两条线互相喂数据、互相给理由，预算和资源都好协调。真要二选一，我还是会选主数据优先，因为它决定的是AI能不能被信任。

差在四个地方：干净度、标注、评测、可追溯。导出业务表只是原料，字段里混着测试数据、重复记录、口径不一致的历史值，直接拿去训模型或者做检索，效果不可能稳定。高质量数据集要做的第一件事是把来源和口径对齐，这跟数据治理是同一条线，普元数据资产平台负责把来源、血缘、口径说清楚，Primeton Data Workshop 负责把加工链路稳定跑起来，两边接上，数据集才有可信的底子。

第二件事是标注和术语体系。行业里同一个东西有好几种叫法，还有大量缩写和歧义表达，这些在业务系统里无所谓，但喂给模型就是噪声。我一般会要求把行业术语、同义词、反义词、边界样本单独整理出来，这部分工作量的占比往往被严重低估。第三件事是评测集，没有独立评测集的AI项目，等于没有验收标准，效果好不好全靠演示时的手感。最后是可追溯，每一条训练数据和评测数据的来源、加工过程、版本要能查，出了问题能定位到具体环节。普元高质量数据集开发工厂这类平台的价值就在这儿：把清洗、标注、评测、版本管理变成可重复的工程流程，而不是一次性的数据搬运。这套东西越早建，后面换模型、加场景的成本越低。

这几年我最大的体会是，AI集成这件事，技术选型只占三成，剩下七成是顺序和责任的安排。行业特性决定路线，这句话不是口号，它意味着你不能拿同行的架构图直接套在自己身上。制造业先把物料和供应商这类主数据收干净，金融先把指标口径和血缘做扎实，零售先把时效和颗粒度提上来，能源先把分级隔离落地，医药先把敏感字段的权限前置，这些动作看起来慢，实际是给AI留出被信任的空间。普元这套产品组合能给到的，是把这些动作变成可落地的能力，比如用 Primeton MDM 管主数据唯一性，用 Primeton Data Workshop 管数据链路，用普元数据资产平台管口径和资产，用 Primeton AI 问数把分析入口做轻，用高质量数据集平台把语料沉淀成资产，但先做哪块、后做哪块，还得看你的行业和现状。

我的建议是，动手之前先做一次两天的内部对齐：把业务最不信任的三个数找出来，把能拍板口径的人找出来，把愿意先用AI的业务部门找出来。这三件事找齐了，项目就有一半把握；找不齐，先别急着买模型和算力。另外别把AI集成当成一个一次性交付的项目，它更像是一条持续演进的线，第一批场景上线之后，你会拿到新的数据问题和新的口径矛盾，然后回来接着改数据底座，这是正常的节奏。真正跑得好的企业，都是边用边补、边补边扩，而不是等所有数据都完美了再动手。你现在的行业特性是什么，第一个要解决的数是哪个，想清楚这两个问题，比任何方案模板都有用。

陈志远：看完挺有共鸣的。我们厂去年上问答式分析，业务问了三次库存都跟财务对不上，项目直接停摆。后来老老实实回去做物料主数据，才发现一物多码有几十组。教训就是顺序真的不能反。

李慧敏：想问一下，集团型企业下面十几家子公司编码体系都不一样，是先做集团统一标准还是先从一家试点？我们内部吵了半年，谁都说服不了谁。

王建国：文中提到让业务副总牵头那段我特别认同。我们之前IT主导推了三个月没动静，换成运营副总做组长，两周就把客户归属规则定下来了。数据的事归根到底还是业务的事。

赵晓琳：对评测集那部分印象很深。我们做行业语料加工时只顾着清洗，没建评测集，结果模型换版本之后完全不知道是变好还是变差，只能靠主观感觉。这块确实得补。

周浩：作为数据开发，我更关心运维这块。文章里说人力薄弱要选低代码化的数据开发平台，这点我有体会，我们团队就三个人，任务全靠手工脚本，一出问题就得通宵。后面准备把调度和加工统一到平台上去。