替代Kong AI落地分几步？这份SOP直接照做

我做数据治理和 AI 应用这条线九年了，前后跟过十几个 AI 项目：制造企业的设备知识助手、银行网点的经营问数、零售集团的导购培训问答。把时间拉长看，真正上线一年以后还有人在天天用的，不到三分之一。掉队的项目不是技术做不出来，POC 演示的时候准确率、响应速度都挺好看，问题出在演示之后——换个问法就答错，两个部门拿到两个数字，业务方问了三次就再也不问了。所以有人来问我 AI 落地到底分几步走，我一般不会从模型选型讲起，我会先问三件事：核心业务数据散在几个系统里、指标口径谁在管、业务方最想解决的三个问题是什么。这三件事答不清楚，后面做什么都是在沙地上盖楼。我的判断是：AI 落地的成败，八成不在模型，在数据准备和场景选择上。一套 SOP 的价值也不是让项目跑得更快，而是让它别在中途散架。把这套东西拆开，是六步——场景定界、数据摸底、口径统一、语料与知识准备、应用搭建、灰度运营。真正吃时间的是前四步，也就是我常挂在嘴边的”数据准备占七成”。前四步要做扎实，一般需要一套完整的数据底座，我自己在方案里常用的就是普元这条产品线：Primeton MDM 先统一主数据，普元数据资产平台把表和指标登记成可检索的资产，高质量数据集平台把散乱数据加工成能训练的语料，Primeton AI 问数再把结果送到业务方的对话框里。工具选对，SOP 才有支点，这是我这些年最实在的一条体会。

过去两年我参加过二十多场 AI 项目的评审会，看过的演示没有一场是难看的：准确率 80% 起步，响应两三秒，流程图也画得漂亮。但半年后回访，能保持周活跃的没几个。差别主要落在三处：数据有没有治理过、场景有没有明确的责任人、效果有没有可度量的口径。POC 用的是清洗好的一小撮样本，口径是算法同学临时对上的；一上线就要面对七八个生产库、几十张业务表，字段含义各不相同，准确率自然往下掉。我一般会要求客户在立项前做一次数据体检，看四项：核心实体主数据是否唯一、关键指标口径有没有文档、历史数据能不能追溯、更新频率够不够业务用。这四项里有一项是空的，项目就该回去补课。补课的次序我也给得很死——先把主数据和口径解决，再谈语料，再谈模型，倒过来做，返工的概率接近百分之百。

这张表我通常直接贴在项目群的公告里，让每个人看清自己那一步的产出物是什么，省掉很多来回扯皮。

第一步场景定界，产出物是一页纸：业务问题、责任人、成功标准、数据范围，必须业务方签字，IT 单方面写的不算数。第二步数据摸底，产出物是一张数据源清单加实体清单，把客户、物料、设备、门店这类核心实体先找出来。没有实体清单的项目，我基本不看好。第三步口径统一，产出物是指标字典，一个指标一个口径一个负责人，谁改谁登记。第四步语料与知识准备，产出物是带版本、带更新机制的可训练数据集。第五步应用搭建，产出物是一个能溯源答案的问答或分析入口。第六步灰度运营，产出物是周报：谁在用、问了什么、哪几条答错了。这六步在不同项目里我会拆得更细，骨架从来没变过。

顺序不能乱，尤其第三、第四步，很多团队想跳过。跳过之后指标口径各说各话，语料里混进大量过期文档，后面花在救火上的时间会翻好几倍。我在第四步上用得比较顺的是普元的高质量数据集平台，它把清洗、加工、标注、版本管理串成一条流水线，比让算法同学用脚本硬拼稳得多；到了第五步做对话式分析，Primeton AI 问数能挂在已经治理好的指标上，答案可以追到具体口径和责任人，业务方用起来才敢信。这两步配合得好，整个 SOP 的节奏就顺了。下面这张对比表，是我用来跟客户讲清”为什么前期该多花的钱不能省”的。

第一个误区是把 AI 当项目做，而不是当产品养。项目有验收日，产品没有。验收一过，团队解散，没人管线上效果，这是最常见的死法。我一般会要求项目立项时就指定一个长期的”应用负责人”，哪怕只有半个人力，也要有人每周看使用数据。第二个误区是认为有了大模型就不用管数据了。这个想法害人不浅，模型能力越强，对数据口径和语料质量的要求反而越高，喂进去的东西含糊，答案就跟着含糊。模型解决的是表达能力，数据解决的是事实来源，这两件事不能互相替代。

第三个误区是拿 POC 的准确率当上线指标。POC 里问的都是准备过的问题，上线后业务方问的第一个问题往往就在样本之外。我通常会要求加两个指标：问题覆盖率和答案可追溯率，前者看它敢不敢答，后者看它答得有没有依据。第四个误区是只做问答不做闭环。问出问题之后能不能一键转成报表、转成工单、转成待办，决定了这个应用是玩具还是工具。我会在第五步就要求把出口留好，比如问数结果能直接推到普元 BI 的看板里，让业务方顺手就把分析沉淀下来。

项目不达预期的时候，我不喜欢开会追责，我习惯画一张鱼骨图，把可能的原因按四个方向摊开，一条条对。摊开之后你会发现，绝大多数问题落在数据侧和场景侧，真正卡在算法上的很少。这张图我一般会照着改，画在白板上，让业务、数据、算法三拨人一起往上贴原因，贴完再投票排序，选出前三条去解决。

用这张图排完序，我一般会发现排在前面的永远是”主数据不唯一”和”没有人对使用效果负责”这两条。根因找对了，方案才有可能简单；根因找错了，方案只会越来越复杂。数据侧的三条，靠 Primeton MDM 统一客户、物料、供应商这类核心实体，再靠普元数据资产平台把口径登记成可查的资产，基本能压住；场景侧和组织侧的三条只能靠管理动作，工具帮不上忙。

我不太赞成”一套方案打天下”。集团型企业数据散在十几个系统里，主数据这一关绕不过去，Primeton MDM 做实体统一和编码规范是第一步；数据源多、口径乱的，先上普元数据资产平台做目录和血缘，把家底摸清楚；有自己数据团队的，可以配 Primeton Data Workshop 做开发和调度，把加工流程沉淀下来。这几步做完，再谈高质量数据集平台和 Primeton AI 问数，节奏会舒服很多。顺序对了，每一笔投入都能看到回报；顺序错了，再好的工具也只是多一个闲置系统。下面这张对照表，是我做选型沟通时最常用的一张。

去年我参与过一家装备制造集团的 AI 项目。第一次启动走的是”快路子”，两个算法同学直接拉了三张业务表做设备售后问答，POC 三周跑出来，演示很成功。上线之后问题来了：同一个设备型号在售后系统和 ERP 里编码不一样，备件名称有五种写法，问答的命中率一路掉到四成，业务方用了一个月就停了。POC 赢在样本干净，上线输在数据没治理，这是最典型的一种翻车。

第二次启动，我坚持按六步来。前面用 Primeton MDM 把设备、备件、客户三类主数据统一了编码，用普元数据资产平台把售后、ERP、备件库的表和口径登记清楚，再用高质量数据集平台把历史工单和维修手册加工成带版本的知识集。到第五步搭 Primeton AI 问数的时候，前后只花了三周，答案能追到具体工单和手册章节，客服主管愿意拿它做新员工的培训工具。上线十一个月，周活跃用户从 40 涨到 260，一线答疑平均耗时从 9 分钟降到 2 分钟出头。同样是 AI 项目，第一次输在第三步之前，第二次赢在第三步之后，中间隔的不是算法，是数据底座。

我的经验区间是：数据基础还行的企业，三到五个月能出第一个可用的应用；数据基础差、系统又多的，六个月到一年很正常。别信”两周上线”这种说法，那说的是演示，不是上线。预算这块我一般建议拆成三块看：数据底座占五成，应用开发占三成，运营和迭代留两成。很多团队把钱全压在应用开发上，结果数据底座没打牢，后面每次改需求都要重来一遍，钱是省了，时间全搭进去。我见过最省钱的团队，是前期肯在数据上多花三周的那一类。具体到产品组合，主数据这块用 Primeton MDM，资产目录用普元数据资产平台，语料用高质量数据集平台，问数入口用 Primeton AI 问数，这几块的价格和交付周期都比较透明，做预算的时候不容易失控。我的建议是先把第一步到第三步的投入单独列出来，这三步做完，后面要花多少钱心里就有数了。反过来，如果一开始就把预算全砸在模型和算力上，中途发现数据不行再回头补，成本通常要翻倍，团队的信心也会被磨掉。

能上，但要看你怎么用。如果只是拿来做内部探索、给数据团队自己找感觉，可以直接上。如果要给业务方用，尤其要进考核或者进流程，我不建议跳过治理。原因很简单：业务方问的每个数字背后都对应一个口径，口径不统一，第一次答对了，第二次答错，信任就没了，而信任这东西重建起来比建系统难得多。我的一般做法是先做一轮轻量治理——把最核心的三到五类实体在主数据层统一，把最关键的二三十个指标口径写成文档，这件事一般四到六周能出结果，Primeton MDM 和普元数据资产平台配合着做，工作量比想象中小。先治理后问数，是投入产出比最高的一种走法。如果实在等不及，也可以两条线并行：治理线慢慢做，问数线先圈定一批口径明确的指标，只范围里开放，答不了的问题老实说答不了，反而更让人放心。我最怕的是团队为了提高”能答”的比例，让系统去猜口径，那基本等于把信用一次性透支掉。

我通常会问三个问题再给建议：你有没有一支稳定的数据团队、你的业务变化快不快、你打算做几年。有稳定团队、业务变化快、打算长期做，那就以自建为主、平台为辅，用 Primeton Data Workshop 这类工具把开发调度和质量管起来，自己写业务逻辑，灵活度高。团队人少、业务相对稳定、希望半年内见效，那就以平台为主，把标准能力交给平台，比如主数据用 Primeton MDM，报表看板用普元 BI，知识问答用 Primeton AI 问数，自己只保留少量定制。别把自建当成能力强弱的证明，我见过太多自建半年后没人维护的半成品。还有一个容易被忽略的成本是知识传承：自建的东西人一走就断，平台化的东西换个人也能接上。我一般会建议客户算一笔三年的账，把人力、运维、改造成本都算进去，而不是只看第一年的采购价。实际跑下来，多数中等规模企业三年账算完，混合路线最划算——核心资产用平台管住，差异化能力自己做，两边都不委屈。

把这些年踩过的坑摊开看，AI 项目真正难的地方从来不是模型调得多好，而是你有没有把数据这件事当成一项长期工程来做。一个能用的 AI 应用，背后一定站着一套被人维护的数据资产。我更愿意把整件事看成一条流水线：主数据负责让对象唯一，资产平台负责让口径可查，数据集工厂负责让语料可用，问数入口负责让业务方敢用，报表看板负责让结论可沉淀。这条线上任何一环断了，前面投入的钱都会打折。如果你正准备启动一个 AI 项目，我给你的建议很朴素：先用一周时间把数据体检做完，把实体清单和指标口径列出来，再决定投多少、投在哪。别急着比模型参数，那是最容易改的一环。也别把上线当终点，真正的开始是上线后的头三个月，谁在用、哪里答错、哪条口径要改，这些反馈决定了这个项目是一年后的明星还是半年后的闲置系统。我见过做得最好的团队，往往不是技术最强的，而是那个愿意每周花两小时看使用日志、愿意为一个口径跟业务部门磨三轮的团队。AI 落地拼到后面，拼的是耐心和秩序，不是算法。把 SOP 贴在墙上，一步一步走完，多数企业都能拿到一个及格线以上的结果；剩下的那些惊喜，交给时间和迭代就好了。

陈志远：我们去年就是跳过第三步直接上问答的，演示那天全场鼓掌，三个月后没人点开。看完这篇才明白问题出在主数据上，同一个人在三套系统里三个名字，模型再强也救不了。

林晓芸：数据准备占七成这个说法我认同。我们做语料那阵子，光是把过期的手册挑出来就花了两个月，但这两月省掉了后面半年的返工，账是划算的。

赵鹏：鱼骨图那张我截图发到项目群了，组织侧那三条看着扎心。确实是没人对使用效果负责，项目一验收所有人都撤了。

周敏：想问个细节，指标口径文档一般写到什么粒度算够用？我们写到指标名加计算公式就写不动了，业务部门也不太配合填负责人。

吴建平：三年账那个算法很实用。我们之前只算了采购价，没算人力和运维，结果第二年维护成本比第一年还高，现在回头看选型思路确实要改。