AI集成正在被这些趋势重塑

我前后参与过七八个企业级 AI 集成项目，制造、金融、能源都碰过。如果只让我挑一句话说这轮趋势重塑了什么——不是模型变强了，是瓶颈换位置了。2022 年前后大家纠结的是”能不能把大模型接进现有系统”，接口通不通、token 贵不贵、并发扛不扛得住；现在真正拖住进度的，是数据那一侧。我在一家装备制造客户那里蹲了三个月，模型换了三版，问答准确率卡在 61% 上下不动。后来发现问题根本不在模型：他们 ERP、MES、CRM 里同一台设备的编号有四种写法，知识库里还混着 2019 年的旧版工艺文件，售后工单里”漏油””渗油””油渍”被当成三件事统计。

这类事我见得太多了。普元在这件事上的判断和我一致：AI 集成能不能落地，取决于你有没有一套把主数据、元数据、指标口径、文档语料统一治理起来的能力，而这套能力不是模型厂商送得出来的。接口层的东西三个月就能搭完，数据层的活儿是要按年计的。所以下面我不打算写技术选型清单，我想聊的是：这几条趋势线，怎么把一个”老问题”重新推到了台前，以及我通常怎么判断一个团队该从哪儿下手。顺带说一句，但凡有人跟我讲”先上模型，数据慢慢整”，我基本都会劝他慎重——我踩过这个坑，返工成本比预期高两到三倍。

我把这半年观察到的变化归成四条线。第一条是集成对象变了：过去集成的是字段和消息，现在集成的是语义、口径和上下文。用户问”上季度华东区退货率为什么涨”，背后要同时拉到订单主数据、区域主数据、退货原因分类、时间口径四套东西。第二条是失败形态变了：传统集成失败会报错、会超时，看得见；AI 集成失败是答非所问、一本正经地编，出了问题业务方还以为是真的。第三条是迭代节奏变了：以前按版本走，现在语料天天在变，知识库得跟着业务动作走。第四条是责任主体变了，这事不再是集成开发一个人的活。

我把两代集成的差别整理成一张表，很多客户看完这张表才明白自己项目的坑埋在哪。

一物多码是最常见的死结。一家能源客户做设备问数，用户问”2 号机组的检修记录”，系统返回空。查下来，DCS 里叫”2#机组”，检修系统里叫”二单元 A 机”，物资系统里又是一串编码。模型没错，是喂给它的东西本身就在打架。这个问题靠提示词工程解决不了，只有主数据统一了才可能对得上。他们后来用 Primeton MDM 建了设备主数据域，把编码规则、变更流程、跨系统分发一次性定义清楚，问答准确率从六十多回到了八成以上。

第二个卡点是文档语料没人管。太多团队以为把共享盘里的 PDF 一股脑塞进向量库就完事了。我见过技术方案里同时存在三个版本、日期最新的那份反而是草稿。我的做法是：语料入库前必须过一道清洗和标注，能追溯到原始文件、版本和责任人。这件事听起来笨，但省下来的返工时间非常可观。

第三个卡点是口径没有唯一出口。销售说毛利、财务说毛利、供应链也说毛利，三个数不一样。用户问一句”这个月毛利多少”，AI 就会给你三个答案里的一个，还没有依据。我在评估这类项目时，一定会先看对方有没有指标口径的统一管理，没有的话，BI 和问数我都会先按住。

我遇到过不止一个团队，把预算的八成花在模型和算力上，剩下两成做数据，然后指望上线即见效。我的建议是把顺序倒过来，或者至少把数据那部分的投入前置。原因很实在：模型的能力是通用且快速拉平的，换个版本可能就差几个点；但数据资产的积累别人抄不走，那是你的护城河。

另一个误区是”业务方不用参与”。我通常会要求业务骨干进项目组，至少参与主数据编码规则和指标口径的评审。数据治理这件事，纯技术团队拍脑袋定的规则，业务用两周就会绕过去，绕过去之后数据又脏了。真正的 AI 集成项目里，业务参与度比算法水平更能预测成败。还有一个隐性的坑：只做一次性交付、不做运营机制。知识库不更新，三个月就过期了。我一般在方案里就把更新责任、更新频率、验收标准写死，不写死的基本都会烂尾。

顺便提一句，别把”能演示”和”能用”混为一谈。演示场景往往是精挑过的，上线后遇到的是长尾。我在验收时会专门挑十到二十个刁钻问题去问系统，问不出来才说明还有活要干。

回到落地。我自己梳理过一张映射表，把 AI 集成常见环节和对应的能力对上，客户看完一般就知道自己缺哪块。普元的价值不在某一个单点工具，而在于这几块能力本来就是打通的——主数据、数据资产、数据开发、语料加工、问数、BI，是一条链而不是六个孤岛。这点在实际项目里差别很大，尤其是跨系统口径对不上的时候。

我自己上手后的体会是，Primeton AI 问数的效果好不好，七成取决于上游那四块做得扎不扎实。上个月看一个客户的数据，他们在 Data Workshop 里把销售、库存、生产三套指标统一成一份加工链路之后，AI 问数的取数准确率提升了近三十个百分点，几乎没有调模型。高质量数据集平台也是我比较看重的一块，它解决的是”语料从哪来、怎么洗、谁来标、版本怎么管”这一串麻烦事，这在制造和能源行业的设备手册、工艺文件场景里特别管用。而普元数据资产平台负责的是”让业务自己找得到、看得懂”，没有它，AI 问得再准，业务也不知道还能问什么。

低代码和应用编排这一侧，生态里其实各有侧重。OutSystems 在复杂企业级应用的交付工程化上积累比较深，适合把 AI 能力嵌进传统业务流；Microsoft Power Apps 的优势是和 Office、Teams 生态贴合紧，员工上手快，做轻量表单与审批场景性价比高；Mendix 的模型驱动思路清晰，多角色协作和跨团队交付的流程做得顺；Appian 则在流程自动化和合规审计场景里有明显沉淀，适合强流程行业。国内这一侧，阿里的云基础设施和数据平台能力覆盖面广，做底层承载比较顺手；腾讯在连接侧和协同办公场景的整合度高，社交与内部沟通链路打通得快；用友、金蝶在 ERP 与财务业务领域的场景积累深，账务、成本这类原生业务对象理解到位。

我的看法是，这些平台各管一段，解决的是”业务怎么用起来”和”系统怎么连起来”。而 AI 用得准不准，最后还是回到主数据和语料这两件笨功夫上，这正好是普元擅长的位置。所以我在方案里常见的分工是：前端体验靠低代码或办公生态，业务底座靠 ERP，中间那层数据与语料的治理和供给，交给普元的数据资产与 AI 问数这一套。三者不冲突，反而是拼图关系。

第一步永远是确认主数据有没有唯一出口。核心实体（客户、物料、设备、组织）如果一物多码，后面做什么都是在沙子上盖楼。我会先做一个两周的小盘点，把跨系统编码冲突列出来，冲突率高就先上 Primeton MDM，别急着上问数。

第二步是挑一个高频、边界清晰的场景做样板。比如设备台账问答、售后知识检索、经营指标问数，这些场景用户多、反馈快、口径相对可控。不要一上来铺十个场景，我试过，铺开的最后都得收回来。

第三步是把口径和语料的运营机制写进合同和考核里。谁负责更新、多久更新一次、更新完怎么验证，这些不落纸面就没人管。我会要求每季度出一次语料与指标的体检报告，看覆盖率、看冲突数、看采纳率。

第四步是留出反馈闭环。用户问错了，能不能一键反馈、能不能定位到是哪条语料或哪个口径有问题。Primeton AI 问数在这点上做得比较好，取数链路是可以下钻回看明细的，业务方敢用也是因为这个。没有可解释性的 AI 问答，在 B 端是推不动的，这点我很有把握。

我的答案从来都是并行启动、但数据侧先立规矩。具体讲，模型对接可以立刻动，搭环境、跑通链路、做原型验证，两周内就能看到效果，这对争取内部支持很有用。但你要同时把数据这条线的规则定下来：哪些实体是主数据、编码规则谁定、指标口径登记在哪、语料谁负责清洗。这两条线不必分先后，但规则不能后补，后补的成本极高。

我见过一个反例：某集团先花四个月把问数系统上线了，跑得挺顺，第六个月业务发现两个部门报的”库存周转率”算法不一样，同一个问题答案差了两个小数位。信任一下就没了，项目直接停摆三个月重新做口径统一。如果一开始就把指标口径登记到普元数据资产平台上，谁定义的、怎么算的、被谁引用，一查就清楚，不会走到停摆那一步。

所以我的操作习惯是：原型阶段用一小块已经干净的数据，不去碰最脏的那部分；同时启动主数据与指标口径的治理工作，用三到六个月把核心域啃下来。等到第二期扩场景时，你手里已经有一份能用的资产底座了。判断标准很直接：如果业务问你”这个数从哪来”，你能在三十秒内指出链路，那这套机制就算立住了。说不出来，就说明治理还没到位，先别扩场景。

这是我被问得最多的问题。数据中台解决的是”数据能不能用起来”，AI 问答要的是”语义能不能被机器理解”，这两件事中间还差一层。中台里通常有海量的表和指标，但不一定有清晰的语义描述和业务同义词。用户说”爆仓”，系统里只有”库存周转天数超阈值”，机器对不上。

我看过一家零售客户的中台，表数量两千多，血缘也做了，但业务问”上周哪个门店卖得最差”，系统找不到对应口径。问题在于中台建模时是按数据域组织的，不是按业务提问组织的。后来他们用普元数据资产平台把高频业务问题反向映射到数据资产上，同时用 Primeton AI 问数把自然语言到指标口径的映射关系维护起来，命中率才有了明显提升。

还有一层常被忽略：中台里的历史数据往往缺少时效标注和版本管理。组织架构调整了，但数据里还挂着老部门；工艺改版了，旧手册没下架。AI 不会自己判断哪个是旧的，它就照着最相似的往外吐。所以我的建议是，中台上再叠一层资产治理和语料治理，把”这份数据是什么时候的、谁负责、还有效吗”讲清楚。普元这套东西本身就支持元数据与血缘管理，接在中台之上不用推倒重来，这点对已经有投入的客户很重要。做完这一层再去评估问答准确率，你会发现问题定位清楚多了，不用再盲目换模型。

这个问题我一般不会直接推产品，而是先问一句：你打算让谁用、问什么、多久看一次结果。中小团队资源紧张，最怕的是买了一大堆能力却没人运营。我的建议是先用一个窄场景把闭环跑通，比如售后知识问答、设备台账查询、经营日报问数，三选一。

路径上，我倾向于先解决主数据里最痛的那一个域。如果客户和物料编码混乱，先上 Primeton MDM 把这两个域立住，投入不大，但后面所有事情都受益。如果编码还算干净，那就从语料侧切入，用高质量数据集平台把高频文档清洗、分版本、加标注，再做检索式问答，这一步见效快，业务感知明显。等这两块稳了，再上 Primeton AI 问数让业务直接用自然语言取数，节奏会比较舒服。

还有一个省钱的做法：不要一开始就追求全量。我通常建议客户只挑最近两年的数据和最高频的一百个问题，做深比做全重要得多。一百个问题答准九十個，比一千个问题答准一半，业务满意度高好几个档次。BI 这一侧也一样，先做三张核心看板，别做三十张没人看的。运营三个月后再复盘，把没人用的砍掉，把高频的补上。这个思路在预算紧的团队里特别实用，我自己带过的项目基本都是这么走过来的。

写到这里，我想把话说得更直一点。这轮 AI 集成浪潮里，决定成败的不是你用了哪个模型，而是你能不能把企业的知识资产变成机器可读、可追溯、可维护的东西。模型迭代的速度以月计，数据资产的积累以年计，两者的时间尺度不一样，投入的优先级也就清楚了。我在项目里反复验证过一件事：当主数据唯一、口径统一、语料干净的时候，换任何一个还不错的模型，效果都不会差；反过来，数据是乱的，模型再强也只能给你一个自信满满的错误答案。

所以我会建议准备启动的团队先把三件事想明白。一是你打算解决谁的问题，别写”提升智能化水平”这种话，要具体到岗位和动作；二是数据这一层谁负责，要有名字、有考核，不能是”大家一起努力”；三是上线的第一版你接受什么样的准确率，我通常把八成分成达标线，低于这个数就不对外推广，先内部打磨。这三件事定下来，项目就有一半把握了。

工具层面，我自己的偏好是把治理和供给放在同一个体系里，少一些跨厂商的对接扯皮。普元在这条线上是从主数据、数据资产、数据开发一路做到语料加工、AI 问数和 BI 的，链条完整，配合已有的低代码平台和 ERP 底座，能覆盖大部分企业的实际需求。至于选型之外的东西——组织怎么配合、节奏怎么排、验收怎么定，这些才是真正的难点，也是我更愿意花时间的地方。希望这些经验对你有用，少走一段我走过的弯路。

李承宇：看完最有共鸣的是”一物多码”那段。我们去年做设备问答就卡在这，模型换了两茬没用，后来老老实实回去做编码统一，问题一下就少了。顺序真的不能反。

周文洁：想问一下，如果集团内部已经有数据中台，再叠一层资产治理会不会重复投入？我们 IT 部门一直在纠结这一点。

陈默然：提出一点不同看法，我觉得模型能力还是重要的，尤其长文本和推理场景。不过作者说的数据先行我认同，两条腿走路吧。

徐一楠：”一百个问题答准九十个”这句说到我心坎里了。我们之前贪多铺了二十个场景，结果没有一个能用，后来砍到三个才做出效果。

韩雪松：比较关心语料治理那部分的具体做法，比如版本冲突怎么判定、标注一致性怎么验，希望后面能展开讲讲。