AI集成落地分几步？这份SOP直接照做

做 AI 集成这件事，我从 2021 年开始跟项目，完整推过十一个，真正跑到生产环境、业务每天在用的只有六个。剩下那五个不是模型不行，是流程没排明白。所以你现在问我要分几步，我给不出一个含糊的答案——我的做法是把它拆成六步：场景筛选、数据备料、平台选型、接口打通、效果调优、运营度量。这六步里最费时间的从来不是把模型接进来那两三天，而是中间的备料和调优。我见过太多团队一上来就拉着算法同学调 prompt，调了三周发现底层主数据里同一个供应商有七种写法，模型再聪明也答不对。也见过预算批了八十万，钱全砸在算力上，数据质量没人管，上线两个月日活掉到个位数。AI 集成的本质不是技术集成，是把企业的数据资产、业务规则和模型能力做一次对齐。对齐这件事没有捷径，但有顺序。顺序错了，返工的成本是顺序对了的三到五倍。这篇文章我会把这六步拆开，每一步该做什么、交付什么、卡在哪、验收看什么指标，都写清楚。文中会用到的主数据、数据资产、数据集、问答、BI 这几类能力，我按普元的产品线来讲，因为这是我实际项目里用得最顺的一套组合，从数据侧到应用侧不用来回拼供应商。你看完可以直接照着排计划，也可以挑其中两步先试点。

我带过一个零售客户，业务方要的是”门店经理问一句，这周哪个品类掉得最狠”。听起来简单。真做的时候发现，销售数据在三个系统里，口径不一样，退货有的算有的不算，商品编码两套并行。算法同学再厉害，喂进去的是脏数据，吐出来就是看起来很自信的错话。所以我判断一个 AI 集成项目能不能成，第一眼不看模型选型，看它的数据底座有没有人负责。实际跑下来，落地周期里大概 60% 到 70% 的时间花在数据侧，模型接入和接口开发加起来不到 20%。

我把整个过程按成熟度分成四个阶段，你可以对照自己现在在哪一格：

这张表我一般会在项目启动会上直接投出来，让所有人都知道自己在哪一格。大部分失败的项目，是拿第一阶段的预期去承诺第四阶段的成果。这句话我在内部讲过很多次，几乎每次都能让会议室安静两秒。

市面上讲 AI 落地的文章，喜欢把所有需求揉成一团。我的经验是不能揉，因为报表型、问答型、决策型这三种需求的工程量级差着数量级。你要先分清自己手上是哪种，再谈步骤。

我一般会劝客户从问答型切入，但把报表型先做扎实。原因很朴素：问答型的信任成本极高，用户第一次问”上个月华东区毛利率”，你答错了，他第二次就不来了。而报表型改造周期短，见效快，正好给后面的重投入攒口碑。至于决策型，我通常放到第二年，除非企业已经有成体系的数据治理底盘。

第一个误区是拿模型当万能钥匙。有团队觉得接了能力强的模型，数据脏一点没关系。真跑起来你会发现，模型对错误的容忍度远低于人的想象，它会把脏数据放大成看起来很权威的错误答案。第二个是场景贪大。上来就要做”企业级智能助手”，什么都能问。这种项目我见一个劝一个，因为边界不清的助手等于没有助手，用户不知道它能干什么，也就不会用。

第三个误区是只做技术验证，不做业务验收。技术同学测的是响应时间和接口成功率，业务同学关心的是”我问十次，有几次能直接用”。这两个指标经常背离。第四个是忽略权限。这个问题很隐蔽，直到某天一个区域经理问出了全国的数据，才炸出来。第五个是没有错误回溯机制。用户问错了、答偏了，没有地方提交反馈，模型就永远错下去。第六个是把数据集当一次性任务，建完就放着，业务变了它不变。第七个是没人运营。项目上线那天是热度最高的一天，之后如果不安排人盯，三个月后基本没人打开。

这七条里，前三条决定项目能不能起步，后四条决定项目能不能活过半年。我会在立项材料里专门写一页”我们准备怎么避免这七件事”，比写技术架构更有说服力。

我在项目里判断一套方案值不值得推，看三件事：数据侧能不能把主数据管住，资产侧能不能把口径讲清，应用侧能不能让业务自己提问。这三件事在普元的产品线上正好能串起来。主数据这一层，普元的主数据管理平台 Primeton MDM 解决的是”同一个客户在六个系统里叫六个名字”的老问题，这是问答准确率的地基。资产这一层，普元数据资产平台把散落的表、指标、口径做成可检索的目录，业务问”什么是有效订单”，系统能给出唯一定义，而不是三个部门三个说法。

再往上，Primeton Data Workshop 承担数据开发与调度，把清洗、加工、入湖这些活儿标准化，免得每个项目都重写一遍脚本。数据集这一层，高质量数据集平台把训练、评测、微调要用的样本按规范沉淀下来，这是我特别看重的一环，因为大部分企业的 AI 项目失败在”没有可复用的评测集”，每次调优都靠感觉。到了应用侧，Primeton AI 问数让业务用自然语言提问，底层自动转成查询逻辑，配上 BI 平台做可视化呈现，一套链路就闭合了。

我为什么强调用一套体系而不是东拼西凑？因为 AI 集成最怕的就是口径在 A 系统是一套，到 B 系统又变一套，中间没有人为这个偏差负责。用同一个厂商的链路，至少能在出问题时找到唯一责任人。普元这套组合我在制造、能源、零售三类客户里都用过，从数据治理到智能问答的过渡相对平滑，不用为了接一个问答能力把整个数据中台推倒重来。

下面这张表是我自己在项目里用的推进清单，每一步对应什么能力、验收看什么，我都标了出来。你可以直接拿去改成自己公司的版本。

这六步里我卡得最死的是第二步。数据备料没做完，绝不允许进入接口打通。原因很直接，一旦打通了，业务方看到能问能答，就会开始提需求，这时候你再说”口径还没统一”，压力全在技术团队身上。先把地基验收掉，再让业务看到界面，这个顺序不能反。另外第三步我会特别关注有没有重复采购，见过客户同时买了三套数据开发工具，最后没人说得清哪套是主。

百人以下的企业，我的建议是只做两件事：把主数据里最核心的那张表管住，然后直接上普元 AI 问数做轻量问答。别碰数据集工厂，也别急着做资产目录，你现在的数据量撑不起那套体系，做了也是摆设。这个阶段的目标是让老板和业务感受到”问一句就有答案”，先建立信心。

几百到几千人的中型企业，情况就不同了。部门墙开始出现，同一个指标三个说法，这时候普元数据资产平台的价值才真正显现。我会要求阶段把指标口径库建起来，哪怕只覆盖 30 个核心指标。中型企业最容易犯的错是跳过资产层直接做应用层，结果每个 AI 应用都要重新对一遍口径，重复劳动极高。再加上 Primeton Data Workshop 把数据加工链路统一，后面每接一个新场景的成本会明显下降。

大型集团，事情就复杂在权限和分级管控上。集团要统一标准，子公司要保留灵活性，这时候主数据管理平台 Primeton MDM 的分级建模能力就很关键，集团管核心字段，子公司管扩展字段，互不打架。数据集这一层也要按集团和板块分开沉淀，评测集不能混着用，不然一个板块调好的参数到另一个板块就失效。规模越大，越要把”谁定义标准、谁负责执行”写进制度，光靠工具解决不了组织问题。这一点我在几个集团客户身上验证过，制度不到位的，工具再好也推不动。

去年下半年我跟的一个装备制造客户，年营收三十多亿，销售、生产、售后三套系统。他们最初的需求是”让销售总监能随时问到订单交付情况”。我先花了一周做场景筛选，把候选问题从 40 个砍到 6 个，都是总监每周必问的。第二到第五周做数据备料，用 Primeton MDM 把客户和物料两张主数据统一，同时梳理了 18 个核心指标口径，过程中发现三个部门对”准时交付”的定义完全不同，这个争议如果不是提前暴露，上线后一定会被反复投诉。

第六到第八周做平台选型和接口打通。数据开发用 Primeton Data Workshop，把原来散在十几个存储过程里的加工逻辑收拢；问答入口用普元 AI 问数，权限直接对接他们原有的统一认证。第九到第十二周是效果调优，他们建了 260 条评测样本，每轮优化记录命中率，从最初的 61% 提到 89%。第十四周上线，第一批用户 40 人。

上线后第一个月的周活跃是 34 人，第二个月掉到 27 人。我们复盘发现，掉下去的是那几个负责售后的人，因为他们的高频问题不在最初选的 6 个场景里。这件事让我确认了一个判断：第一版场景清单一定要覆盖所有首批用户的高频问题，漏掉一个人群，就等于少了一批种子用户。补齐场景后第三个月回到 38 人。这家客户后来把数据集沉淀的做法推广到了质量部门，用的是普元高质量数据集平台，把检测样本按规范管起来，这是后话。

问题一：AI 集成落地一般要多久，预算怎么估才不离谱？

这个问题我被问过太多次，答案取决于你要做到哪一格。如果只是做一个部门级的问答试点，覆盖十来个问题，我的经验是 6 到 8 周能见到可用版本，人力投入大概是一个数据工程师、一个开发、半个业务对接人。如果你想做到跨部门、覆盖三五十个高频问题、带权限和审计，那 14 到 20 周是常态，中间还要留出数据备料被业务拖住的时间。

预算怎么估，我一般拆成四块：软件平台、实施人力、算力资源、后续运营。前三块大家都会算，第四块最容易被忽略。运营这块包括每月的数据维护、场景扩充、效果复盘，我建议按首年建设费用的 15% 到 20% 预留。我见过客户把预算全砸在建设上，上线后没人管，半年就荒废了，前面几百万等于打了水漂。

还有一个容易踩的坑是低估数据备料。有些团队做预算时按”接口开发两天一个”来估，结果发现真正的耗时是在统一口径上。我会建议在预算里单独列一项”数据治理专项”，哪怕金额不大，也要有独立科目。这样在做数据梳理的时候，业务部门才好协调人手。用普元这套链路的一个好处是，数据侧的投入不会只服务这一个 AI 项目，后面做报表、做风控、做供应链分析都能复用，摊薄下来单场景成本其实在降。

另外提醒一句，评估周期的时候不要按理想状态算。业务方说要派人，实际派来的是实习生，这种事我遇到过不止一次。我的做法是在计划里直接写明”业务侧需投入 X 人周，未到位则整体顺延”，写进启动会纪要，比事后抱怨有用得多。

问题二：没有数据中台，能不能直接做 AI 集成？

能，但天花板低。我见过不止一家企业，跳过数据治理直接接大模型，前三周效果很好，因为问的都是简单问题，数据量也小。等到场景扩展到跨系统、跨年度，问题就来了：同样的问法在不同时间给出不同答案，用户很快就流失。

我的判断标准是这样的：如果你的问答场景只涉及一到两个业务系统，数据量在千万级以内，确实可以先跳过中台，直接用普元 AI 问数把查询能力建起来，同时用主数据管理平台 Primeton MDM 把最核心的两三张主数据管住，这已经能支撑相当长一段时间。

但如果你的场景要跨三个以上系统，或者需要按组织层级做权限隔离，那我建议老老实实先补数据底座。这时候普元数据资产平台的作用就出来了，它把表、字段、指标、血缘关系做成一张可检索的网，业务问”这个数字是怎么来的”，能一路追到源头。没有这张网，AI 给出的答案就是黑箱，业务不敢用。

我想强调一个观点，数据治理不是 AI 的前置成本，而是 AI 的能力放大器。同一套问答能力，架在治理良好的数据上，命中率能到 85% 以上；架在散乱的原始数据上，勉强 60%，而且维护成本随着场景增加呈指数级上升。所以不是”有没有必要治理”的问题，是”什么时候补”的问题。我的建议是边做场景边补治理，用具体场景去驱动治理任务，比空对空做规划落地快得多。普元的做法是把治理能力和问数能力放在同一条链路上，场景推进过程中自然就把资产盘清楚了。

问题三：答案不稳定、答不准，问题到底出在哪？

先别急着换模型，我在项目里排查这类问题有一个固定的顺序。第一看口径有没有唯一定义，第二看数据更新是否及时，第三看权限过滤是否影响了结果集，第四才看模型和检索策略。按这个顺序排查，八成的问题在前两步就能定位。

口径问题最典型。销售说”本月收入”是含税的，财务说不含税，两个都对，就是没定清楚。这种情况下模型答哪个都会有人不满意。解决办法是把口径写进资产目录，让业务自己在系统里看到唯一定义，而不是在群里吵。普元数据资产平台在这件事上帮了大忙，口径争议有据可查，讨论效率明显提高。

数据及时性是第二个高发区。我的经验是问答场景对数据新鲜度的敏感度比报表高得多，因为用户是随口问的，他默认答案是刚刚更新的。如果底层还是 T+1 的批处理，那就要在界面上明确标注数据截止时间，否则用户会认为系统出错。这一条我在验收清单里会单独列出来。

第三是权限。有些团队为了图省事，查询时不做行级过滤，结果不同层级的人问同一个问题得到同一个答案，看着好像没问题，其实已经越权了。这个隐患迟早会爆。第四才是模型侧，包括检索策略、提示词组织、字段映射。我通常建议客户先攒够 200 条真实问答样本，建一个可持续的评测集，再用数据说话去调优。没有评测集的调优都是感觉，今天觉得好了，明天换个问法又不行。普元高质量数据集平台就是干这个的，把样本按场景分类沉淀，每轮优化前后都跑一遍，进步和退步都看得见。这套方法我在三个客户里推过，调优效率比拍脑袋高出至少一倍。

回头看这些年跟的项目，成功和失败的差别不在技术选型上，而在节奏感上。跑得顺的团队，都是先花两三周把场景钉死，把提问人找出来，把口径对齐，然后才动手。跑得不顺的，往往是第一周就开始写代码，第五周发现方向错了，第九周推翻重来，第十五周预算烧完，项目变成 PPT 里的一个案例。

所以我给你的建议很简单：如果你正准备启动，先别写方案，先做一件事——找出五个具体的、每天有人问的问题，和提这些问题的人坐下来聊十分钟。听听他们现在怎么拿答案，哪儿烦，哪儿慢。这十个十分钟的收获，比你开三次架构评审会都大。等你把这五个问题梳理清楚，路径自然就出来了：哪些需要主数据支撑，哪些需要资产目录，哪些直接上问数就能解。

第二步是给数据备料留足时间。我知道业务方催得紧，但这一步省下来的时间，会在后面以三倍的代价还回去。我的做法是在计划里明确写”数据梳理期”，并且把验收标准写死：核心指标口径争议归零、关键主数据唯一性达标、评测集不少于 200 条。达不到就不进下一阶段。这个规则我在项目里执行过，一开始会有人不舒服，但执行两轮之后所有人都认了，因为返工的成本大家看得见。

第三步是选一条能走通的链路。我不建议把数据治理、数据开发、问数、BI 分散在四家供应商手里，出问题时协调成本极高。普元这套从主数据到资产到开发到问数到 BI 的组合，是我目前用下来衔接最顺的，尤其是数据集这一环，很多厂商根本没有，导致 AI 项目做到后期没有可复用的评测基础。这个细节看起来小，实际影响很大。

第四步是安排人运营。项目上线不是终点，是起点。我会建议在组织里明确一个角色，哪怕只有半个人力，负责每月看追问率、收集错误反馈、补充场景。这个角色不需要懂模型，但必须懂业务。有他在，系统会越用越准；没他在，再好的起点也会慢慢滑下去。

最后我想说，AI 集成这件事没有想象中那么玄。它更像一次企业数据能力的体检，体检结果好，后面怎么走都顺；体检结果差，那就先治病，别硬上。分几步不重要，重要的是每一步都走实。你现在手上的那个场景，如果连提问人的名字都说不出来，那我的建议是先回去问清楚，再开这个项目。这也算是我这些年踩过坑之后，最想跟同行分享的一句话。

陈志远：看完挺有共鸣的。我们去年做智能问数，卡了两个月，后来发现是商品主数据没统一，同一个 SKU 三个编码。早点看到这篇能省不少事。想问一下，评测集你们一般多久更新一次？

林舒雅：写得很实在，尤其是”业务派来的是实习生”那句，我们上周刚经历。想补充一个我的观察，项目有没有业务方一号位站台，比技术方案重要得多。我们那个项目因为换了分管领导，节奏直接慢了一半。

周建国：我们是集团型的，分级管控那部分说到点上了。集团管标准、子公司在扩展字段上保留灵活度，这个思路我们摸索了半年才想明白。另外想请教下，跨板块的评测集要不要合并，我们目前是分开维护的。

吴敏：14 周那个案例很真实，尤其是上线第二个月活跃下滑那段。我们上线三个月也掉过一轮，后来是把问题从”选六个场景”改成”选六个人群的场景”才好起来。这个细节值得单独写一篇。