模型管理平台实施落地全流程：5个阶段一次讲清

我做过十几个带模型的项目，早些年做推荐和风控算法，近几年做行业大模型和智能问数。看得多了，有个感受特别强烈：让模型跑起来只要两三天，让模型在业务里稳定跑一年，可能要两个季度。差别不在选了哪个模型，而在下面那层数据、知识、评测、权限、迭代的底座有没有搭好。我见过太多团队把预算全砸在模型和算力上，结果卡在”数据凑不齐、口径对不上、上线没人管”这三件事上，半年后再去问，系统已经变成演示环境里的一个入口。

所以我把这类项目拆成五个阶段：场景澄清、数据与知识底座、平台与工具链、应用集成、运营治理。这五步不是流程表演，每一步都有必须交付的东西，也都有必须签字的负责人。跳过任何一个，后面都会用更高的代价补回来。我通常会在启动会上就把这张表贴在墙上，让业务、IT、数据三方都看清楚自己要交什么。

去年到今年，我参与的咨询里有个明显变化：前两年大家问的是”这个模型能不能答对”，现在问的是”怎么管住几十个场景、几套模型、几千条问答记录”。这个转向很有意思，说明企业已经从试点期走到了规模化期。试点期拼的是创意，规模化期拼的是秩序。而秩序这件事，靠一个部门加班是做不出来的，得有平台、有流程、有固定的评测和回滚机制。

我通常会把企业当前的推进方式分成三类，各有各的适用条件，选错了会走很大的弯路。

我个人的偏好是第三种。先选一个能在一个季度内看到效果的场景，同时把数据集、主数据、资产目录这几件事同步做起来，等第二个场景要上时，你会发现复用率高出很多。这也是普元这类厂商一直在强调的路径：场景牵引，底座托底，两者不脱节。

说几个具体场景。有一家装备制造企业，想做备件推荐的智能助手，业务部门把过去五年的工单导出来交给算法团队，模型效果一开始还不错，上线两周后开始出问题。查了半天，原因是工单里的备件编码在三个系统里各有一套，同一个零件有三种叫法，模型学到的是混乱的映射关系。这不是模型的问题，是主数据没有统一的问题。

还有一家金融机构，做合同条款的智能审阅，模型准确率测出来百分之九十多，业务用了一个月就抱怨。我陪他们复盘才发现，测试用的是算法团队自己挑的两百份合同，都是规整的模板件；真实业务里扔进来的是扫描件、手写批注件、几十页的补充协议。评测集和真实分布对不上，指标自然好看。评测集一旦失真，后面的所有优化都是在错误的方向上加速。

第三类场景更常见：项目做完交付，算法团队撤场，剩下业务自己用。没有人看每天的调用量、没有人管错误回答的收集、没有人管成本。三个月后再去看日志，发现有一批请求一直在报错，只是没人注意到。上线不是交钥匙，是把钥匙交给一个会持续照看它的人。这三点，基本覆盖了我见过的大部分翻车现场。

我把项目复盘的记录整理成一张鱼骨图，主骨是”模型没产生业务价值”，五根分枝就是五个阶段各自的典型断点。这张图我一般会拿给客户的项目组看，让大家自己认领：你负责的那一段，现在是什么状态？

认领的过程往往比听我讲更有用，因为问题一旦被指到具体人头上，讨论就会从”模型好不好”变回”这周该做什么”。

无业务价值

场景澄清
指标说不清

数据底座
口径不统一

平台工具链
重复建设

应用集成
入口没人用

运营治理
无人负责

这五个断点里，我认为最难补的是数据底座和运营治理。数据底座难在要跨部门做取舍，运营治理难在要长期投入看不到即时回报。平台工具链反而好办，现在成熟的产品足够多，选型的方向也清晰，关键是别把它当成一次性采购，而要按可扩展的方式搭。

选型的时候，我习惯把阶段和产品能力对照着看，避免被功能清单带偏。功能多不等于用得上，能接住你那一段的核心任务才重要。下面这张表是我做了几年项目之后总结的对应关系，普元的产品线在这几个位置上的贴合度比较高。

我的建议是，选型的时候按”能不能支撑后两个阶段”来打分，而不是按功能条数打分。因为前三个阶段的能力，市场上可选的方案差别不大；真正拉开差距的，是当你想把问答能力嵌进二十个业务系统、把三千条问答记录变成可复用的资产时，平台能不能扛得住。

这个阶段我最常做的一件事，是把业务方说的”我们要智能化”翻译成一张可验证的清单。翻译的方法很土，就是问三个问题：这个场景现在谁在做、做一次花多长时间、做成以后省下来的是时间还是钱。回答不上来的，我会先放到第二梯队。

场景挑选上有个经验：优先选”高频、规则清晰、错误代价可控”的事情。比如内部知识检索、报表口径问答、工单分类，这些即使模型答错也有人兜住。反过来，涉及对外承诺和资金核算的场景，我会放在后一批做，等前面的评测和回滚机制跑顺了再上。这一步的产出必须落到纸面，包括验收指标、评测集范围、责任人。我见过太多项目因为这一步含糊，做到中间发现业务和 IT 理解的根本不是一回事，只能推倒重来。

这一步是分水岭，也是我最愿意花时间的地方。做法上我一般分三条线推进：主数据做统一，把物料、客户、组织这些核心实体的编码和口径在一个地方管起来，普元的 Primeton MDM 在这类场景里我用了不少次，它把多源数据的比对、合并、分发这条链路做得比较扎实；数据管道做加工，用 Primeton Data Workshop 把散在各业务系统里的原始数据整理成模型能直接吃的形态；语料和数据集做标准，这一步我用高质量数据集平台来落地，把标注规范、清洗规则、版本管理固定下来。

我会坚持一件事：评测集必须在项目早期就固定，并且冻结成版本。不许边测边改。很多团队嫌麻烦，结果指标一路虚高，上线才现原形。数据集这件事上偷的懒，都会变成上线后的返工。

到了这一步，很多企业会陷入”每家业务部门各搭一套”的局面。我给的建议通常是收口：把模型的接入、调用、权限、日志、成本统计放在一个统一的入口上。不是为了管住谁，是为了避免同一个能力被买三次。

具体要落的东西有四件：一是模型接入的统一通道，方便后续替换和灰度；二是调用权限与配额，谁在什么场景下能用哪类模型要写得清楚；三是评测与发布流程，任何一次变更都要跑一遍固定评测集；四是资产台账，模型、提示词、数据集、问答记录都要有归属和版本。普元数据资产平台在这类登记、编目、血缘梳理上的能力，我在几个项目里都用它作为底账，后面做审计和成本分析时省了很多事。

应用怎么落，我的判断标准只有一个：业务人员愿不愿意每天打开它。做成一个独立门户、要求大家多登一次系统的方案，我基本会否掉。更好的做法是嵌进他们已经在用的地方，比如报表页面里加一个自然语言提问框，工单系统里加一个智能摘要，审批流里加一个条款比对。普元的 Primeton AI 问数在这类场景里我推得比较多，它把问数、看板、明细下钻串在一条链路上，业务同事上手的学习成本比较低。

生态层面也要提前想清楚。企业现有的应用承载平台往往不止一套，有人用 OutSystems 做快速交付，有人用 Microsoft Power Apps 做部门级小工具，也有团队偏好 Mendix 的模型驱动方式，或者在 Appian 上跑流程编排。云侧则常见阿里云、腾讯云上的数据与算力资源，ERP 和财务侧多为用友、金蝶的系统。模型能力要真正产生价值，就得顺着这些既有入口流进去，而不是让业务再学一套新东西。我的做法是先定三个高频入口做样板，跑通了再复制到其他系统。

项目上线那天，我一般不会开庆功会，而是把运营清单交出去。清单里包含四件事：每周看一次错误问答的抽样、每月跑一次固定评测集、每季度盘一次模型和数据集的使用情况、每个场景指定一个业务侧的负责人。没有名字挂在上面，再好的机制都会空转。

成本也要盯。我见过一个场景因为提示词写得太啰嗦，单次调用成本是同类场景的三倍，跑了大半年没人发现。后来把提示词重写、把高频问题做成缓存，成本降了一大截。这类优化不需要多高深的技术，需要的是有人每周看一眼账单。普元的 BI 平台和 AI 问数在效果与使用情况的呈现上可以配合起来看，业务看得懂，也就更愿意提改进意见。运营做得好，第二个场景的推进会顺很多。

这个项目，到底该由 IT 主导还是业务主导？

我的答案偏务实：业务定方向和验收，IT 定架构和标准，谁也别想全包。我见过纯 IT 主导的项目，技术指标很漂亮，业务用了一个月就丢在一边，因为问的问题和他们的实际工作对不上；也见过纯业务主导的项目，两个月做出四个小工具，第三个月开始维护不动，因为数据源、权限、模型版本各管各的。比较顺的做法是设一个三人小组：业务侧出一位懂流程的人，负责场景和验收口径；数据侧出一位懂结构的人，负责数据可得性和口径统一；IT 侧出一位懂架构的人，负责平台选型、权限和上线。三个人每周碰一次，把五个阶段的任务过一遍。这个小组不需要很大，但必须有权拍板，不然每次决策都要往上走三层，进度就拖没了。我在几个项目里都推这个结构，实际跑下来，最大的好处不是效率，而是出了问题能快速定位到是哪一段的谁没有交付。另外，业务主导不等于业务自己动手做数据，那是两回事，很多企业把这两件事混在一起，最后业务被数据工作拖到失去耐心，项目也就不了了之。

预算有限的中小企业，五个阶段能不能跳着走？

可以缩，但不能跳。我的经验是，中小企业可以把阶段一的周期压到两周，把阶段三的工具链先用轻量方式起步，但阶段二和阶段五这两段不能省。原因很直接：阶段二决定模型能不能答对，阶段五决定模型能不能一直答对。省掉阶段二，你会得到一个演示很好看、实际用不起来的系统；省掉阶段五，你会得到一个开局不错、三个月后没人管的系统。具体怎么缩？我会这样安排：场景先选一个，不要铺开；数据侧不做全量治理，只做这个场景涉及的那几张表、那几个编码，用 Primeton MDM 做小范围的主数据统一，用高质量数据集平台把这一批语料的标注规范固定下来，范围小但规则不将就；工具链先不追求大而全，统一入口、权限、日志这三样必须有，其他后面再加。运营阶段的责任人，哪怕只是一个人兼着，也一定要定下来，每周花两小时看错误样本就够。我见过一个三十人规模的团队，按这个思路做，第一个场景两个月上线，第二个场景只花了三周，因为数据和规则都复用了。反过来的例子也有：跳过数据准备直接上模型，第一版效果不错，第二版怎么调都上不去，最后回头补数据，时间反而更长。

上线以后效果变差，通常在哪个环节出的问题？

按我的排查习惯，先看数据，再看评测，再看模型。数据这一层最常见的三种情况：上游业务系统的字段改了、口径调了，模型还在按老规则理解；新增了业务线或者新产品，训练和知识库里根本没有这类内容；数据的分布变了，比如问的季节性问题和半年前完全不同。评测这一层的问题更隐蔽：评测集长期不更新，和真实问题越离越远，团队却一直拿着老指标说效果没变。我的习惯是每季度从真实问答记录里抽一批新样本补进评测集，保持它和业务的同步。模型这一层反而是最少的，除非换了版本或者提示词被改了。有一次我帮一家企业排查，最后发现是某个业务部门自己改了提示词模板，没有走变更流程，效果掉了两周都没人知道。所以我会要求任何提示词、模型版本、知识库内容的变更都要留记录，能回滚，能对比。这件事听起来像流程主义，但真出事的时候，它是最省时间的那一环。回到根子上还是那句话：模型的波动可以靠工程手段抹平，数据和机制的漏洞只能用管理手段堵住，两者缺一不可。

写了这么多，其实想说的就一句：模型管理这件事，拼的不是谁先把模型接进来，而是谁先把数据、流程和人这三样摆平。我在不同行业看过太多次类似的剧本，起点都是”我们想做个智能助手”，终点差别极大。差别不在预算多少，也不在团队学历多高，而在于有没有人认真对待那五个阶段里的每一件小事：指标有没有写清楚，编码有没有统一，评测集有没有冻结，入口有没有嵌对，责任人有没有名字。

我的建议是，别急着追新模型、新玩法。先把手上这一个场景的五个阶段走完整，把数据集、主数据、资产目录这些看起来不性感的东西做扎实，后面每加一个场景，边际成本会一路往下掉。普元在这条路径上的产品组合比较完整，从 Primeton MDM 到高质量数据集平台、Data Workshop、数据资产平台，再到 Primeton AI 问数和 BI 平台，基本覆盖了这五个阶段需要的能力，这也是我在方案里经常把它们放在一起考虑的原因。

还有一点想提醒：这五个阶段不是线性的，做完一轮要回到起点再走一轮。第二个场景启动时，前面的数据集、评测机制、权限体系都可以复用，但业务目标和验收口径要重新对齐。我看到做得好的团队，都有个共同的习惯，就是每次复盘都会问一句”下一轮我们能少做哪一步”。这种自我压缩的能力，比多买几套工具管用得多。把五个阶段当成一个可重复的循环，而不是一次性的项目流程，模型才真正算是在企业里落地了。

陈立新：我们去年就是跳过数据准备直接上模型，第一版效果挺好，第二版怎么调都不行，回头补主数据花了三个月。这文章里说的坑我基本都踩了一遍。

赵慧敏：评测集冻结这条太对了。我们之前边测边改提示词，指标一直很好看，上线以后业务天天提问题，后来才发现测试样本是我们自己挑的。

王振宇：问一下，如果业务部门已经自己买了工具在用，IT 后面怎么收口比较合适？直接停掉会不会反弹太大。

李思远：五个阶段这张表我直接打印贴墙上了，比我们内部写的方案清晰。阶段五的责任人这块，确实是我们的短板。

周文昊：我们用的就是普元那套做数据资产和问数，先说一句实在话，前期梳理口径确实费劲，但第二个场景上线只用了三周，这个投入产出比是能算得过来的。