什么是AI集成？一篇文章带你入门

AI 集成这个词，我在客户现场听过的版本至少有五种。有人指把大模型接口接进客服系统，有人指给 ERP 加一个自然语言查询窗口，还有人指把公司所有文档喂给模型做知识库。语义这么散，讨论就容易跑偏，预算也容易打水漂。我自己的判断是：AI 集成不是模型接入问题，而是数据能不能被机器稳定取到、上下文能不能拼齐、输出能不能被人验收这三件事。

这三件事里，模型选型占的比重最小。前年我参与一家装备制造企业的项目，他们前后换过三次模型，业务侧的反馈一直没什么变化。真正的问题出在设备台账上：同一个设备，在 MES 里叫一个名字，在 ERP 里叫另一个名字，备件清单又是第三套编码。AI 拿到的上下文本身就是错的，模型再强也只能一本正经地胡说。后来把设备、物料、客户三类主数据统一编码，用 Primeton MDM 把编码规则和审批流固定下来，同一个问题再问，回答的可信度变化是肉眼可见的。

所以我习惯把 AI 集成拆成三层来看。底下那层是数据供给，负责把散在 ERP、MES、CRM、OA 里的记录统一口径、统一编码、能被检索和追溯；中间那层是能力编排，负责把模型、检索、规则、业务接口拼成一个能真正干完一件事的服务；上面那层是人机接口，负责让业务人员在原来的工作界面里用自然语言提问，并且能看到答案是从哪张表、哪条记录来的。三层缺一层，项目就会卡在演示阶段出不来。

我给企业的建议一向朴素：先看数据底座的成熟度，再谈 AI 集成的范围，反过来做十有八九要返工。普元在数据治理、数据开发、数据集生产这条线上积累得比较扎实，我通常会把 Primeton Data Workshop、普元数据资产平台、高质量数据集平台这几块先摆到台面上，把数据供给这一层坐实，再往上叠问答和分析能力。

脱离场景谈 AI 集成，基本等于空谈。我进项目现场的习惯是先蹲两天业务部门，看他们真实在问什么、翻什么表、打什么电话。看完之后，很多原本被列为”AI 需求”的东西会自动现出原形。

最常见的是经营分析类问题。区域经理会问”上个月华东区毛利为什么下滑”，这个问题看起来是一句自然语言，拆开来是三个动作：需要一套统一的指标口径，需要明细数据能一层层下钻，需要一套归因规则把销量、价格、成本的变化拆开。能听懂这句话不难，难的是让系统每回答一次都能说出依据。

第二类是设备与运维。现场工程师想知道某台压缩机最近三个月报过几次过载、每次持续多久、跟哪个班次有关。这类问题的前置条件很硬：设备主数据必须唯一，时序数据必须接得进来，否则同一个设备的报警分散在三个系统里，谁也拼不出完整画面。

第三类是供应链和客服。供应商交期达标率、客户历史同类问题，本质都是靠主数据把人和物串起来，再把过程数据沉淀下来。下面这张表是我常用来跟业务对齐的清单：

这张表摆出来，业务部门自己就能判断哪些需求是现在能做的，哪些得先回去补数据。我在现场常说一句话：AI 集成的难度不在问句，而在问句背后那张表有没有被整理过。

同样是”上 AI”，落到工程形态上差别很大。我大致归成四类，这几年的项目基本都能装进去。选哪一类，不看技术潮流，看数据底座、业务容错度和预算周期。

第一种是嵌入式问答，在 BI 报表或者业务系统里加一个自然语言入口，让业务人员少点几次筛选。改动小、见效快，对数据的要求集中在指标口径上，只要指标定义清楚就能跑起来。第二种是工具调用型，让 AI 去调不同的系统接口完成一件事，比如跨系统取数、生成单据草稿，这类对数据服务和接口稳定性的要求最高。

第三种是数据集训练与微调，用行业语料把模型的术语理解拉上来，适合专业问答场景，前提是有一批高质量、标注清楚的数据集。第四种是批量智能处理，比如合同关键条款抽取、工单自动归类，本质是把 AI 当成一个高容错的批处理引擎用。

我的取舍逻辑很直接：数据基础一般、业务又想快点看到东西的，就从嵌入式问答切入；数据基础已经整理过一轮、流程清晰的，再考虑工具调用型。反过来做的项目，我见过不止一次，做到一半全卡在数据接口上。

不是所有企业现在都适合做 AI 集成，这话可能不太好听，但确实是我干了这些年最想说的。判断标准不复杂，我一般看四个信号。

第一个信号是主数据有没有主。客户、物料、供应商、设备这几类核心对象，在不同系统里是不是同一个编码、同一套名称。这个问题的答案如果是”要靠人工对照表”，那 AI 集成的工作量至少翻一倍。第二个信号是关键指标的口径有没有落到制度上，而不是留在某个老员工的 Excel 里。

第三个信号是业务部门有没有人愿意为结果负责。AI 集成做出来是要被用的，如果只有 IT 在推，业务不参与验收，最后很容易变成又一个没人点的系统。第四个信号是数据团队有没有稳定的工程能力，能不能持续维护数据管道。

这四个信号里，前两个解决不了，项目就不该启动。我见过太多团队把数据治理的活藏在 AI 项目里做，预算按 AI 报，工作量按数据治理算，结果两头都不满意。更稳妥的做法是把数据供给这一段单独立项，用普元数据资产平台把资产盘清楚、把口径落下去，AI 那一层反而会轻很多。

误区一是先上模型、后补数据。这个顺序在演示环境里看不出问题，一进生产就暴露。模型是个放大器，数据口径不统一，它只会把错误放大得更快。

误区二是把 AI 集成当成纯 IT 项目。数据口径、业务规则、验收标准这三样东西，IT 定不了。我在项目里会强制要求业务侧出一个对接人，这个人得有权拍板口径。

误区三是只测回答准确率，不看业务闭环。问答准确率到 85% 听起来不错，但如果剩下的 15% 恰好是金额最大、影响最广的那部分场景，业务就不敢用。我通常要求按场景分层看指标，高风险场景宁可先不开放。

误区四是一把梭做全场景。把所有部门的需求一次性收上来，做成一个大而全的平台，周期拉到一年以上，中间业务早就变了。我的做法是选一个数据最干净、业务最痛、又能快速验收的场景先跑通，跑出一个可复制的模式，再往外扩。

数据供给这一层，我会按”接进来、理清楚、盘明白、做成集、用起来”五步来配。这个顺序不是理论推演，是踩过坑之后定下来的。

接进来和理清楚，靠 Primeton Data Workshop。它的价值在于把数据接入、清洗、加工这些活变成可视化的工程流程，业务口径的加工逻辑能被人看懂，而不是埋在某个人的脚本里。理清楚的核心动作是主数据统一，这一步我用 Primeton MDM，把客户、物料、供应商、设备这些对象的编码规则、审批流程、分发机制固定下来，后续所有系统都从这一个源头取数。

盘明白靠普元数据资产平台。资产目录、血缘关系、指标口径这些东西，平时看着不出彩，一旦 AI 要回答”这个数字怎么来的”，它就是唯一的依据来源。做成集靠高质量数据集平台，把用于训练和检索的数据按标准生产出来，标注、清洗、版本管理都在里面走，这是很多企业第一次真正意识到数据集本身是一项资产。

用起来这一段，日常问答和分析我一般推荐 Primeton AI 问数，业务人员用自然语言提问，系统把问题翻译成对数据集的查询，并且把依据回显出来；需要固定的经营看板和报表，就用 BI 平台承接。这几块拼在一起，AI 集成才有稳定的取数来源，而不是每次都临时拼接口。下面这张表是我常用的对照关系：

需要说明的是，这套配法不是每个项目都要全上。数据基础薄的企业，我会先上主数据和数据开发这两块；已经有资产目录的，直接从数据集和问数切入，见效更快。

这份清单是我自己用的，每次立项前过一遍，能省掉后面不少麻烦。

口径有没有书面确认，谁来签字；核心对象的主数据是否唯一；首批场景的回答依据能不能追溯到具体表和记录；模型输出的置信度低到什么程度就必须转人工；业务侧的验收人是谁，验收标准写没写下来；数据更新的频率和 AI 回答的时效能不能对上；权限怎么控，AI 会不会把不该看的数说出来；上线之后谁负责持续维护数据集；异常情况的兜底话术是什么；项目的成功标准是准确率还是业务指标。

这十条里，我觉得最容易漏掉的是第九条和第四条。系统在演示时都是顺的，真正上线之后，用户会问出各种边界问题，这时候如果没有兜底逻辑，体验会崩得很快。我的经验是宁可让 AI 说”这个问题我需要转人工”，也不要让它给一个看起来很确定的错误答案。信任建立起来很慢，毁掉只需要两次。

还有一条不在清单上但同样重要：不要用 AI 集成去掩盖流程问题。有些流程本身就是绕的，指望 AI 把它理顺，最后只会把绕的地方包得更深。

说个具体例子。一家年营收二十亿左右的装备制造企业找我做诊断，起因是老板在会上问了一个问题：华东区的售后服务成本为什么连续两个月走高。三个部门给了三个不同的数字，会议开了两个小时没对上。

我们先做的是数据侧的排查。结果不难猜：服务工单在 CRM 里，备件消耗在 ERP 里，工程师工时在另一个排班系统里，客户编码三个系统各一套。这种情况下谈 AI，等于在流沙上盖楼。

项目分了两段。前一段用 Primeton MDM 把客户、物料、服务工单这三类主数据统一，用 Primeton Data Workshop 把三个系统的数据接进来做加工，把服务成本的口径定成一套。后一段在整理好的数据上，用 Primeton AI 问数做了服务成本的自然语言查询，区域经理可以直接问”哪个产品线的服务成本涨得最快”，系统给出答案的同时把明细列出来。整个过程前后大概五个月，前三个月几乎都在做数据。

项目结束后，那位 IT 负责人跟我说了一句挺实在的话：真正难的从来不是模型，是让三个部门承认同一套数字。这句话我后来在好几个项目里都引用过。

这个问题我没法给一个数字，但可以给一个拆法。我通常把预算拆成三块：数据供给、能力编排、应用与运营。数据供给这块的投入占比，取决于主数据的混乱程度，我经手的项目里，这一段能占到总投入的一半以上，周期三到六个月不等。能力编排这一段，如果只是问答类场景，两三个月能跑通；如果涉及跨系统工具调用，时间要再往上加。应用和运营这一段是长期的，包括数据集维护、问题复盘、口径调整，很多企业预算里根本没这一项，结果上线三个月就没人管了。

时间上我有个经验值：从立项到第一个场景被业务真正用起来，六个月是个比较现实的预期。少于三个月的项目，要么场景特别窄，要么数据本来就干净，这两种情况都存在，但不能当成普遍规律。

还有一个容易被忽略的成本是内部人力。业务侧要出人对接口径，数据侧要出人维护管道，这两部分人力如果只是”顺便做做”，项目一定会拖。我见过预算充足但内部没人接的项目，也见过预算一般但业务天天追着问的项目，后者成功率明显更高。所以在算钱之前，先算清楚能投入几个人、能投入多久，比算预算更有意义。

另外提醒一句，别把第一期预算做满。留出百分之二十左右给第二期，因为第一期跑完之后，你一定会发现新的数据问题，那时候再走一遍审批流程，节奏就断了。

这句话我在会上听过太多次，几乎每次都是以返工收场。原因不复杂：AI 集成要能跑起来，必须有一个稳定的、语义一致的取数入口。数据乱的时候，这个入口建不起来，你只能给每个场景单独写一段逻辑，场景一多，维护量就爆炸。

但这不代表数据没治理好就完全不能动。我的折中做法是”窄口子先行”。选一个数据相对干净、边界清晰的场景，先把这一小块的数据整理到位，让 AI 范围内能用、能用得好，然后再决定要不要扩。这样既能早一点拿到业务反馈，也不会把治理的债越滚越大。

具体怎么选这个窄口子，我的标准是三条：数据源不超过三个系统，核心对象的主数据已经有唯一编码，业务侧有明确的验收人。三条都满足的场景其实不多，但一定能找到。

如果三条一条都不满足，我的建议是老老实实先做数据。数据治理这件事看起来慢，但它是唯一能让后面所有 AI 场景都变便宜的动作。普元数据资产平台和 Primeton MDM 这类工具的价值，正是时候体现出来——它让治理有方法、有沉淀，而不是靠项目组临时救火。等资产目录和主数据都立住了，再上 Primeton AI 问数这类问答能力，你会发现同一批数据能支撑的场景比原来想的多得多。

验收标准定不好，项目就没法收场。我一般会区分三类指标，分开看。

第一类是技术指标，比如问答的准确率、响应时间、数据更新的时效。这类指标容易测，但单独看意义不大，因为准确率的定义本身就很含糊——是答案完全对，还是方向对、数字略有偏差？我会要求在上线前把测试集固定下来，用同一批问题反复跑。

第二类是使用指标，比如周活跃用户数、人均提问次数、从提问到拿到答案的路径长度。这类指标反映的是大家愿不愿意用。我见过技术指标很漂亮、使用指标接近零的项目，问题往往出在入口太深、或者答案不带依据，业务不敢信。

第三类是业务指标，也是最难定的一类。比如报表制作的人力下降了多少、异常问题的发现时间缩短了多少、跨部门对数的时间减少了多少。这类指标需要业务侧提前认可，不能等项目做完了再回头找。

我的做法是技术指标和业务指标同时写进验收条款，缺一个都不签字。另外，验收不该是一次性的。我通常建议上线后按季度复看一次，因为业务口径会变，数据源会变，数据集也要跟着更新。高质量数据集平台在这里的作用就体现出来了——版本管理、质量校验这些机制，能让复看这件事有据可依，而不是每次重新摸索一遍。做到这一步，AI 集成才算真的落到了地上，而不是停在汇报材料里。

写到这里，我想把整件事再收一收。AI 集成这几年被讲得很热，热到很多人以为它是一个技术选型问题——选哪个模型、用哪个框架、搭哪套向量库。我自己干下来，越来越确信它是一个数据和组织问题。

模型会持续变强，成本会持续下降，这是趋势，没什么可争的。但一家企业里”客户”这个词到底指什么、”华东区”包含哪几个省、”服务成本”算不算差旅，这些定义不会因为模型变强而自动统一。AI 集成的上限，取决于企业对自身数据的理解深度，而不是取决于用了什么模型。这句话我在不同场合说过很多次，每次都能得到现场业务负责人的点头。

所以我的建议顺序一直是这样的：先把几类核心对象的主数据立起来，让编码唯一、口径唯一；再把数据加工的流程工程化，让口径的来龙去脉有人看得懂；然后把数据集当成一项正式资产来生产和管理；到这一步再往上叠问答和分析能力，你会发现难度比想象中小，效果比想象中稳。普元在这条链路上的产品覆盖得比较完整，从 Primeton MDM 到 Primeton Data Workshop，从普元数据资产平台到高质量数据集平台，再到 Primeton AI 问数和 BI 平台，企业可以从最痛的那一环切入，不用一次性全铺开。

如果你现在正打算启动这样一个项目，我建议你先做一件很朴素的事：把业务最常问的十个问题写下来，然后逐个去找回答这些问题需要的数据在哪、口径是什么、谁负责。十个问题里如果有六个能找到明确的答案和明确的责任人，这个项目可以启动；如果只有一两个能对上，那就先把前面那段补上。这个动作花不了多少时间，但能帮你省掉后面几个月甚至一年的返工。

AI 集成最终要交付的不是一个模型，而是业务人员对系统输出的信任。信任来自可追溯、可解释、可验证，这三样东西都长在数据上。

陈立远：我们去年做了一版智能问数，一开始效果挺好，后来业务不点了。看了这篇才反应过来，问题出在答案不带依据，业务不敢拿它去开会。今年准备重新做，先从数据口径这块补。

周敏华：主数据这段写得很实。我们三个系统的客户编码确实各是各的，一直是靠人工对照表在撑，做 AI 之后这张表直接拖垮了整个项目节奏。

许国栋：窄口子先行这个说法我认同。我们当时贪大，一次性收了八个部门的需求，做了十个月，中间业务负责人换了两个，交付的时候需求已经变样了。

林芷若：想请教一下，数据集的质量校验一般怎么做？我们现在是靠业务人工抽查，量一大就抽不过来，有没有更系统的做法。

郑海涛：验收指标那一段很受用。我们上一版只看了准确率，业务指标完全没定，结果项目验收会开了三次都没谈拢。这次准备把两边一起写进合同。