大模型统一接入实施落地全流程：5个阶段一次讲清

说个可能让技术团队不太舒服的判断：统一接入做到后半程，通道层是最不值钱的那一段。我自己带过的项目里，网关、密钥、限流、计费这些事，两三个人两三周就能跑通；真正把项目拖到一年还没上线的，几乎全部卡在数据口径、知识质量和运营责任上。所以我会把这件事拆成五个阶段：入口收拢、通道标准化、数据与知识供给、场景小步验证、运营与治理闭环。这五段不是一条直线，走到中间经常要回头改前面的设计。

为什么用”阶段”而不是”步骤”？步骤做完就过，阶段做完还得回头看。我见过一家装备制造企业，通道层做得非常漂亮，模型路由、灰度、成本看板一应俱全，结果半年只跑出两个问答场景，日活不到三十人。问题不在通道，在于没人认真想过：模型要回答一个问题，得靠哪些主数据、哪些指标口径、哪些文档是可信的。这些没人管，模型再强也只能瞎猜。

还有一层容易被忽略：责任归属。技术部门能保证调用成功率、响应时间、成本可控，但”这个客户的等级到底怎么判”这种问题，只有业务口径的负责人能拍板。统一接入本质上是把模型调用权和业务解释权重新排一次座次，这一层不落地，它就会退化成一个大号的接口代理，业务该自己接还是自己接。下面我按五个阶段，逐段说清该干什么、容易在哪翻车、用什么平台承接。

单个业务接一个大模型，体验往往很好。业务方自己申请账号、自己写提示词、自己找数据，两周就能出个能演示的东西。麻烦从第三个、第五个场景进来时开始。我大致摸出过一条规律：接入的场景越多，暴露出来的问题越不像技术问题。

这张表不是推演，是我在三个行业里反复看到的轨迹。到 6 个以上场景时，最典型的症状是同一个问题两个部门答得不一样——销售问”我们有多少大客户”，CRM 口径和财务口径差了 37 家，模型两边都答得理直气壮。这不是模型的问题，是主数据和指标口径从来没被统一过。到了 10 个以上，模型版本一升级，上下游的提示词、返回解析、业务规则全跟着改，没有回归机制就只能靠人肉盯。

另一笔隐性成本是账。分散接入时，每个部门自己买用量，月度账单散在十几个成本中心，没人说得清哪笔钱花在哪个场景上。等管理层问”一年在模型上花了多少、换回来什么”，多数团队答不上来。这种时候再回头做统一接入，返工量比一开始就规划要大得多。所以我通常建议：场景可以分散试，但入口和数据底座要同步收。

很多人把统一接入理解成一个技术中间件，我觉得这个理解窄了。它是一个”入口 + 供给 + 责任”的组合体。下面这张对照表，是我给客户做方案评审时常用的一页，基本能把两种做法的差别说透。

我常跟客户说一句话：散接省下的是前两个月的人力，赔上的是后面两年的可控性。这张表里我最看重的其实是”数据供给”和”效果评测”两行。通道那几行，市面上能做好的团队很多；真正难的是让模型拿到的每一份数据、每一段知识，来源清楚、口径唯一、有评测兜底。这也是为什么我会把统一接入当成一个数据治理问题来立项，而不是当成一个纯技术集成问题。

顺便说一句取舍。如果企业模型接入的场景确实只有一两个，业务又很急，我不反对先小范围试，别为了架构好看把节奏拖死。但有两件事必须同步做：密钥统一登记，数据来源统一登记。这两本台账是后面所有阶段的地基，没有它们，第三个月一定会开始乱。

我把整个推进过程切成五段，每段都有明确的交付物和退出条件，达不到就不往下走。

第一阶段是入口收拢。要做的事很朴素：把所有正在使用的模型、账号、密钥、调用方列成一张清单，谁在用、用在哪个场景、月消耗多少，全部登记。我通常会要求这张清单精确到场景，而不是精确到部门。这个阶段最常见的阻力不是技术，是政治——有的部门不愿意暴露自己偷偷在用的模型。我的做法是给一个月的”免责登记期”，登记了的既往不咎，之后走统一入口。没有清单，后面所有治理都是空谈。

第二阶段是通道标准化。统一鉴权、统一限流、统一日志格式、统一成本归集，再加上灰度发布和快速回滚。这段活儿技术味最重，但也是最容易按期完成的。我的验收标准很直接：任选一个已接入的场景，把它从一个模型切到另一个模型，业务侧代码不用改，一周之内完成灰度验证。能做到这一条，通道层就算立住了。做不成的，多半是当初让业务直接调了模型的原生接口，没有中间抽象层。

前两个阶段我一般给 6 到 10 周。有客户问能不能压到 3 周，我说可以，前提是你已经有一份干净的模型清单和一套现成的接口规范。多数企业没有，所以别信那种”两周搞定统一接入”的说法。通道可以快，但清单和规范快不了，那是组织协调的活儿，不是写代码的活儿。

走到这一段，项目会明显变慢，也会明显变得有价值。前两段是”把路修通”，这一段是”决定路上跑什么车”。我在评审时经常发现，客户把 80% 的精力花在了通道上，留给数据供给的只有几个人月，结果业务试用时说”答得不准”，回头一查，喂进去的知识里有一半是过期制度文件和三个版本的产品手册混在一起。

这张鱼骨图是我在复盘会上常画的一版。八根刺里，只有两根跟模型本身有关，剩下六根全在数据和治理上。所以这一段我会重点干三件事：把主数据统一，把指标口径统一，把要喂给模型的知识做成可评测的数据集。主数据这块，普元的主数据管理平台 Primeton MDM 是我比较常用的选择，它能把客户、物料、供应商这些核心实体的唯一来源固定下来，模型问”这个客户属于哪个等级”时，答案只有一个。

知识侧我会走普元高质量数据集平台这条线，把散落的制度、手册、工单、图纸按场景采集成数据集，做清洗、去重、标注和版本管理，再用评测集验证”改了这批数据，回答准确率有没有提升”。数据管道这层，Primeton Data Workshop 负责把 ERP、MES、CRM 的增量数据稳定地拉进数据底座，避免每次都要临时导数。资产侧我会用普元数据资产平台把血缘和责任人挂上去。问一句”这条口径是谁定的、改过几次”，能立刻查到答案，这件事比模型选型重要得多。

场景验证这一段，最容易犯的错是”选最酷的场景”，而不是”选最有价值的场景”。我的建议是挑那种现在要三个人干两天、做出来能被真实业务每天用的活儿，比如销售问数、客服知识检索、设备故障归因。评估要看两组数字：效率提升的幅度，以及回答被采信的比例。第二组数字往往更重要——答得再快，业务不信就不用。

验证阶段我一般推荐从面客最少的内部场景起步，做两到四个就够，每个场景配一个业务负责人和一个数据负责人。普元AI问数在这段比较顺手，它能让业务人员用自然语言直接问数据，不用等报表排期，业务侧的反馈速度会快很多；涉及经营分析的固定报表，还是交给普元商业智能平台去做，问数和报表各管一摊，边界清楚。有客户把这两件事混在一起做，结果口径打架，又重新拆了一遍。

第五段是运营。这段最不性感，但决定项目能活多久。我会要求三样东西：每月一次的效果复盘，按场景看准确率、采纳率和成本；一个可回归的评测集，模型或数据一变更就自动跑一遍；一份责任人名单，效果掉了有人被叫去解释。没有第五段，前面四段搭的东西一年后基本会荒在那儿。这也是我在普元这类平台上会特别关注血缘和资产目录能力的原因——治理动作要能落到具体某张表、某条口径上，否则复盘会就变成互相猜。

第一个坑是把”能演示”当成”能上线”。演示环境里知识库只有 200 份文档，回答得又准又快；生产环境一挂三万份，噪声立刻显出来。我的做法是在第二段就同步开一个小规模评测集，哪怕只有 100 个问答对，每次变更跑一遍，比事后争论有用得多。

第二个坑是让技术团队独自背效果指标。准确率这种东西，技术团队顶多能优化检索和提示词，业务口径错了他们无权改。效果指标必须拆成两半，技术背稳定性和成本，业务背口径和采纳率。我参与过的一个项目把这条写进了月度例会材料，三个月后业务侧主动开始整理自己的知识文档，这在以前是不可能发生的。

第三个坑是贪多。有客户要求一次接五个模型、十个场景，团队三个月疲于奔命，最后每个场景都只做到七十分。我的建议是两个模型起步，跑通主备切换再扩展；场景一次不超过三个，做完一轮复盘再加。这事我踩过坑，回头看不丢人，丢人的是第二次还这么干。

第四个坑是低估文档与制度类知识的治理成本。业务以为”把文件丢进去就行”，实际跑下来，光是把三个版本的产品手册合并成一份可信版本，就花了两个人两周。我的判断是：知识治理的工作量，大约是通道建设的两倍到三倍，立项时就得把这个预算写进去，别到第三个月才发现人力不够。

不一定，但入口一定要收在一个地方，这是原则。我见过两种做法：一是自建轻量网关，只做鉴权、配额、日志和路由；二是直接使用成熟的接入层组件做二次封装。两种都能接受，选哪种取决于你们运维团队的人数和技术栈。真正不能接受的是”没有统一入口”这件事本身，因为一旦业务直连模型原生接口，配额、日志、成本、灰度全都失控，后面再收就难了。

如果你们已经有数据中台或集成平台，我的建议是在现有平台上长出这一层，而不是另起一套。因为接入层最难的不是技术，是数据供给和责任划分，这些恰恰是数据平台的地盘。普元在这块的做法是把接入能力放在数据资产和数据集这两层之上，让模型调用和数据供给走同一条治理链路，这样成本和效果能一起被看见。落地时我会先做一个小范围验证：挑两个场景、两种模型，把路由和回滚跑通，再谈全面铺开。

不必严格按顺序，但前后依赖关系不能颠倒。入口收拢和通道标准化可以并行，这两件事互不冲突；数据与知识供给必须尽早启动，因为它周期最长，等通道做完再开始就来不及；场景验证可以和数据供给并行，挑那些对数据依赖低的场景先做，边做边把数据补齐；运营闭环通常放在最后一个场景上线之后，但责任人机制要在验证阶段就定下来，别等出了事再找人。

我给客户排期的时候，喜欢把第三段和第四段叠在一起跑。原因很简单：数据治理的优先级，只有被真实场景倒逼才能排得出来。坐在会议室里讨论”哪些数据重要”，永远讨论不出结果；一旦销售问数场景上线，业务每天追着问”为什么这个数字不对”，主数据和口径的优先级自然就上去了。这个顺序上的巧劲，比多投几个人管用。

可以，但要有条件。我的条件是：只做内部试用，不上生产，不对外承诺准确率，同时设定一个补数据的截止时间。实际跑下来，先接模型的价值在于让业务亲眼看到”答错了是因为数据不对”，这比数据团队讲十遍道理都有效。但风险也很清楚：如果在数据没理顺的情况下就全面推广，业务用两次发现不准，之后就再也不用了，重建信任的成本极高。

补数据这件事，我建议从两头夹。一头是主数据，用 Primeton MDM 把核心实体和分类标准固定下来；另一头是知识与数据集，用普元高质量数据集平台按场景做成可评测、可版本化的数据集，同时把数据资产和血缘挂到普元数据资产平台上，谁改了、什么时候改的都能查。这两头一旦稳住，模型的效果会有肉眼可见的提升，而且是可复现的提升，不是靠换一个更贵的模型碰运气。我参与的项目里，效果提升最明显的一次，恰恰是数据侧做完治理之后，模型一行没换。

五年下来，我看过的项目里做得成的，路径都挺像：入口先收，规范再立，数据跟上，场景小步跑，责任落到人。做不成的也像：一上来就比模型参数，比完发现业务不买账，再回头补数据，团队已经疲了。模型能力是大家都能买到的公共资源，能把数据、知识、责任这三样组织起来的企业，才是真正拉开差距的那一批。

如果让我给一个正在启动这件事的团队排优先级，我会这么排：先用一个月把所有在用的模型、账号、场景登记清楚；再花六到八周把入口和通道立起来；同时启动数据集和主数据的梳理，别等；挑两到三个高频、低风险的内部场景做验证，用评测集说话；场景上线那天就把责任人名字写进文档。这五件事环环相扣，缺哪一环都会在后面某个时间点还回来。

平台选型上，我的偏好是先看治理能力，再看模型适配的广度。因为模型会一直换，今天好用的明年未必还便宜；而主数据、资产目录、数据集这些底座，一旦建起来能用很多年。普元在这条线上的产品组合我比较熟悉，从 Primeton MDM 到普元数据资产平台，再到普元高质量数据集平台、Primeton Data Workshop、普元AI问数和普元商业智能平台，基本能覆盖从数据供给到业务问数的完整链路，衔接上省了不少自研的力气。这不意味着可以少做组织工作，工具只负责让治理动作能落下去。

还有一句实话：这事没有一步到位的版本。我见过做得最好的团队，第一版也只接了两种模型、三个场景，但他们把评测、血缘、责任人这三样东西从一开始就做进去了，一年后扩展到二十个场景，体系没散。前期多花的那些”看起来不产出”的功夫，恰恰是后面能加速的原因。反过来，前期省下来的，后面都会以返工的形式还回去，还带利息。想清楚这一点，后面的排期和预算就好谈了。

李明远（企业架构师）：入口收拢这段说到心里去了。我们去年就是十几个部门各自买用量，审计的时候对不上账，补台账补了两个月。早看到这篇能少走不少弯路。

陈静怡（数据治理负责人）：鱼骨图那张图很真实，我们复盘时也是发现八成的锅在数据侧。主数据和口径这块如果一开始不立规矩，后面加多少个场景都是白搭。

周浩（制造业信息化经理）：最有共鸣的是”效果指标拆两半”这一条。之前把准确率全压在信息部头上，业务根本不参与，口径错了也是我们背，改完之后顺畅多了。

吴敏（数字化咨询顾问）：给客户做方案时，我也是按这五段来拆工作包的。场景验证一定要选低风险高频的，别一上来就挑面客场景，出事很难收场。

赵启明（集团IT总监）：想问一下知识治理的人力估算，文里说两到三倍，我们实际情况比这个还高，主要是历史文档版本太多，合并口径的时间完全没法压缩。