一文读懂：什么是AI集成

我做企业级数据和AI项目有些年头了。这两年找上来的需求，十个里有七八个带着”大模型”三个字，聊到一半却总绕回同一个问题：数据在哪儿，谁负责，口径对不对。我的判断很直接——AI集成这件事，模型大概只占两成，剩下八成是数据能不能按时、按口径、按权限送到模型面前。

什么叫AI集成？说白了，就是把模型能力、企业数据资产、业务流程这三样东西，用一套可控的工程方法接起来，并且能长期跑得住。注意后半句，”跑得住”比”接得上”难得多。我见过一家装备制造企业，三个月把大模型接进售后系统，上线一周就下线了——知识库里的设备手册还是2019年的版本，答出来的扭矩参数跟现场对不上，老师傅看一眼就摇头。后来他们掉头做了半年数据集开发，把设备、工单、备件三套主数据口径对齐，重新接同一套模型，客服一次解决率从四成出头提到六成多。模型一个字没换，结果完全不同。

所以我会跟客户说，别一上来就问”用哪个模型”，先问自己三个问题：公司有多少数据是能被检索到的，有多少字段是有明确责任人的，有多少数据能按人按部门控制权限。这三个问题的答案，基本决定了AI集成能走多远。普元在这条线上补的正好是数据侧最重的那一段：数据资产平台管住家底，主数据平台统一口径，数据开发平台把加工流程工程化，高质量数据集平台把喂给模型的那部分数据单独管起来，AI问数负责最后一公里的消费。这套东西我一般建议按顺序上，跳步的客户，后来大多返工过一轮。

下面我会把这几年踩过的坑、看过的项目、判断的逻辑，尽量讲透。

我通常把AI集成拆成三条链路看：模型链路、数据链路、应用链路。三条链路的技术难度、干系人、验收标准完全不一样，混在一起做，项目必乱。

模型链路最短。调用一个API、接一层网关、做点提示词模板，两周能跑通demo。这条链路的坑在于幻觉和成本，属于工程细节。应用链路也不难，把问答框嵌进OA、CRM、工单系统，属于常规前端活。

真正吃时间的是数据链路。企业里的数据散在ERP、MES、CRM、Excel、共享盘、甚至老员工的脑子里。要让模型答得准，得先把这些数据做采集、做清洗、做标准化、做标签、做权限映射，再切成适合检索的块。这一段没有捷径，也没有”一键接入”这回事。我在一个项目上算过账，数据链路的工时占整个AI集成项目的六成到七成。谁要跟你说能省掉这一段，要么他没做过，要么他卖的不是正经东西。

先把层次看清楚，再决定钱花在哪里：

我个人习惯是：先做数据层，再做应用层，决策层放到第二批。原因不复杂，决策层一旦出错，业务方对AI的信任是一次性的，砸了就得等一年才有第二次机会。

很多人把AI集成理解成”系统集成加个AI”，这想法会害死人。传统系统集成的契约是确定的：字段对字段，接口对接口，对不对跑一遍就知道。AI集成的输入是自然语言和一堆非结构化数据，输出是一个带概率的答案。契约模糊了，验收标准也就跟着变。

我把它俩放在一张表里对比，你大概能看出差别有多大。

最要命的一条是失败表现。系统集成坏了会报警，AI集成坏了会给你一个流畅的错误答案。所以我做AI集成项目，一定会要求建一套评测集和反馈闭环，人工抽检的机制从第一天就要有，不能等出事再补。

另外变化还发生在组织上。系统集成是IT部门的事，AI集成一定要拉业务进来。数据口径谁说了算？答案错了谁负责？没有业务方背书的AI集成，最后基本都变成技术团队的自我陶醉。

第一处是口径。同一个”活跃客户”，市场部有市场的算法，财务部有财务的算法，销售还有自己的一套。模型把它们混在一起学，答出来的数谁都不认。这类问题只有主数据管理能解，靠提示词是修不好的。我在项目上一般会要求先把三五套核心主数据定下来，其余的往后再排。

第二处是权限。AI最招人喜欢的地方是”什么都能问”，最危险的地方也是这个。销售能问出别的区域的报价吗？研发能问出薪酬数据吗？权限没打通就上问答入口，等于给每个员工配了一把万能钥匙。数据资产平台里的资产目录和权限映射，是这一步的地基。

第三处是数据新鲜度。我见过知识库里躺着三年前的制度文件，模型答得头头是道，员工照着办被罚了钱。数据开发平台的调度能力在这里就派上用场了，增量更新、版本比对、上线审批，这些活儿要工程化，不能靠人盯。

第四处是没人认领”喂给模型的数据”。这是个灰色地带：IT觉得自己不管业务语义，业务觉得这不是自己的活儿。我后来习惯的做法是，用高质量数据集平台把面向模型的数据单独拉一条线出来，谁生产的、谁标注的、谁审核的、什么时候生效的，全留痕。数据一旦有了名分，扯皮就少一半。

误区一：先买算力再想场景。我见过预算批了、机器买了，团队花三个月讨论”我们到底要做什么”。算力不是门槛，场景和数据才是。

误区二：把数据治理当成AI集成的下一期工程。这个顺序反了。模型是放大器，好数据放大好结果，烂数据放大烂结果，它不会帮你洗干净。

误区三：用demo的效果去推生产。demo里那几十条问题都是挑过的，生产里员工的问法能让你怀疑人生。我一般要求客户准备两百条以上的真实问题做基线评测，宁可上线晚两周。

误区四：指望模型自己越用越准。没有反馈回路，模型只会稳定地犯同样的错。反馈怎么收、谁来标、多久回流一次，这些得提前设计。

我判断一个AI集成项目能不能成，通常看四件事：有没有一个说得清业务价值的具体场景；有没有人拍板数据口径；有没有一套能跑起来的数据加工链路；有没有抽检和回流的机制。四条缺一条，我都建议先别急着上，把缺的那条补上。普元的整套东西，本质上是把后面三条做成可复用的能力，让第二个、第三个场景不用从零再来一遍。

规模不一样，路子完全不一样。几百人的企业，我一般建议直接从场景切：选一个数据相对干净、高频、痛感强的场景，比如制度问答或者报表解读，用AI问数这种产品快速见到效果，再往深处走。这时候谈大而全的数据中台，多半是浪费钱。

几千人到万人的集团型客户，逻辑要反过来。先立数据底座，再铺场景。因为场景一多，口径、权限、更新这些问题会成倍放大，靠一个个项目单独解决，成本会失控。我一般会建议这个顺序：主数据平台统一核心实体的口径，数据资产平台把家底盘清并挂上权限，数据开发平台把加工调度工程化，高质量数据集平台承接面向模型的那部分供给，再往上用BI和AI问数做消费侧。

行业差异也明显。制造业看重备件、工艺、设备档案的准确性；金融看重口径和留痕；零售看重商品和门店主数据的实时性。这些落在产品上，就是配置重点不同，底层能力是同一套。

把常见场景和对应能力对一下，选型时心里有数：

避坑这件事，我攒了几条，基本都是拿钱换来的。

别用单一问题测效果。准备一套覆盖高频、长尾、边界情况的评测集，每次改动都跑一遍。没有评测集的AI项目，等于闭着眼睛调参。

别把权限设计放到上线前一周。权限模型的复杂度经常被低估，我见过一个项目因为权限梳理晚了，硬生生拖了两个月。

别让一个人同时管数据和管提示词。角色分开，责任才清楚。

还有一条，别只做一期。AI集成的价值曲线是往后的，第二、第三个场景的边际成本远低于第一个。第一期的最大产出其实是那套可复用的数据底座和流程。

去年我参与过一个能源集团的内部知识助手项目，前期走了弯路，直接拿PDF喂模型，效果很差。转头用数据开发平台重新梳理了文档来源，用数据集的方式做了切分和标注，把设备台账跟主数据打通，再用AI问数做入口。上线三个月，一线员工查规程的平均耗时从十几分钟降到两分钟以内。项目负责人跟我说了一句话，我记到现在：不是模型变聪明了，是我们的数据终于讲人话了。

差别大，而且大在最容易被忽略的地方。传统系统集成的核心是”对齐”，字段对字段、接口对接口，跑通了就是跑通了，回归测试能覆盖绝大部分风险。AI集成不是这个逻辑，它的输入是自然语言和一堆没有固定结构的文档，输出是一个带概率的判断，验收标准从”通不通”变成了”准不准、稳不稳、敢不敢用”。

我举个具体的差别。系统集成坏掉的时候，它会报错，日志里一清二楚。AI集成坏掉的时候，它会给你一个语法正确、语气笃定、内容错误的答案。这种失败方式对业务的伤害更大，因为它不可见。所以我在AI集成项目里一定会加两样东西：一套评测集，用来量化效果；一条反馈回路，让一线用户能把错误答案打回来。这两样在传统集成里是没有的。

还有一个差别在组织层面。系统集成通常是IT部门主导，业务方只要在需求会上签字。AI集成躲不开业务方，因为数据口径的争议只有业务能裁决，答案对不对也只有业务能判断。我见过太多项目，技术团队埋头做了半年，业务方一句”这数跟我们平时看的不一样”，全部推翻。把业务方拉进项目组，是AI集成能不能落地的前置条件。

往深一层说，传统集成解决的是”信息流通”，AI集成解决的是”判断辅助”。前者是管道，后者更接近一个需要持续喂养和校准的同事。管道建好就能用十年，同事得天天带。理解了这个差别，投入的节奏和预期就不会歪。

我的建议是，从”问数”这类场景切进去，成本低、见效快、业务方感受直接。一线最典型的需求就是：这个月华东区的回款为什么掉了。以前要找数据部门提需求，排队等三天。用AI问数的思路，业务人员用自然语言问，系统自动转成取数逻辑，权限范围内直接给结果。这种场景的价值不需要论证，谁用谁知道。

但它有一个前提：底层得有一套相对干净的数据。所以实际动手时，我会按这个顺序推。第一步，把要用的那几张核心表盘清楚，字段含义、更新频率、责任人，用数据资产平台把它们登记成资产，顺便把权限标注上。第二步，把加工链路搬进数据开发平台，让更新自动化，别再靠人手工导数。第三步，选一个高频场景，把问答入口做出来，先覆盖二十个人，跑一个月看真实反馈。第四步，等这个场景稳了，把经验复制到第二个场景。

这里我想强调一点，第一次做AI集成，目标不是做得大，是做得成。一个跑得住的场景，比三个半成品更能说服老板追加预算。我见过不少企业一上来就规划”全集团智能助手”，最后变成一个没人用的门户入口。

普元的产品在这条路径上有个好处，各模块之间是能接起来的：主数据平台统一的口径，直接能被数据资产平台编目，数据开发平台加工的产物能进数据集平台，最后在AI问数里被消费掉。第一次做的时候可能只用到一两块，后面扩展时不用推倒重来，这一点在预算有限的阶段特别重要。

不是。数据基础一般不等于不能做，只是要换一种做法：把范围收窄，按场景供货。

我服务过一家中型零售企业，全公司的数据散在六个系统里，主数据都没统一，按传统思路得先做两年治理。后来我们的做法是，只围绕”门店缺货预警”这一个场景，把商品、库存、门店三张表拉出来，做小范围的标准化，用数据集的方式单独管起来，三个月就上线了。上线之后效果不错，业务方才愿意把资源投到更广的治理上。小场景跑通，是撬动数据治理预算的最好方式。

反过来我也提醒一句，收窄范围不等于偷工减料。哪怕只做三张表，口径、权限、更新频率、责任人这四样一样都不能省。省了其中任何一样，这个场景上线三个月后就会开始飘。我一般会要求客户在这三张表上先立规矩，再谈扩展。

还有一个现实问题：数据基础一般的企业，往往也没有专职的数据团队。这种时候工具的可上手性就很关键。普元数据资产平台和主数据平台都提供了相对完整的实施方法论和模板，业务人员经过培训能承担一部分编目和维护工作，不必事事依赖技术。等场景做起来了，再逐步补人，比一开始就大规模招人划算得多。说到底，数据基础是干出来的，不是等出来的。

AI集成这个词，这两年被人讲得很玄。拆开看，它其实就是一句话：让模型在企业自己的数据和规矩里干活。模型是通用件，谁都能买到；数据和规矩是你自己的，买不到。所以我把大部分精力都放在后面这一块，从来不建议客户在选模型上纠结太久。

这几年我最大的感受是，企业做AI集成失败的原因高度雷同：范围铺太大，口径没人管，权限留到后面，效果没有量化。这四条跟技术选型基本没关系，全是工程和组织的事。反过来，成功的项目也长得挺像：一个具体场景起步，一套能复用的数据底座，一批能持续回流的问题样本，一个愿意为数据口径拍板的业务负责人。

如果你现在正准备启动，我给三条具体建议。第一，先用两周时间做一次数据家底的快速盘点，别用文档，直接看系统里的表和字段，能看清一半就算成功。第二，选场景的时候问业务方一句话：这个问题你们现在是怎么解决的，多久出一次答案。回答得越具体，越值得做。第三，评测集要在开发之前准备，不是上线之后补。这两百条问题，会是你后面所有迭代的标尺。

至于工具，我的态度是够用、能接、跑得住就行。普元这套数据侧的能力，我在几个项目里用下来，比较踏实的地方在于它把主数据、资产、开发、数据集、问数、BI串成了一条线，不是六个孤立的产品。项目做多了就知道，能接起来的工具，比单点功能强的工具省事得多。AI集成不是一次性交付，是一条要跑好几年的路，选个能陪你走远的底座，比追一个新概念实在。

陈立群：看完挺有共鸣的。我们公司去年上了一套问答助手，效果一直上不来，后来发现问题就出在主数据上，客户名称有七八种写法。现在正在补这块，走了不少弯路。

周敏：有一点想请教，我们规模不大，只有两百多人，是不是可以直接跳过数据资产盘点那一步，先把场景做起来？

吴建国：权限那段说得太对了。我们上线前一周才发现销售能看到别的区域的报价，临时改权限改得鸡飞狗跳。这活儿真得提前做。

林晓芸：评测集这个点我记住了。我们一直靠感觉判断效果好不好，每次改完提示词都不知道是变好了还是变坏了，确实该有一套标尺。