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

我做过六七个大模型接入层的项目，开头几乎都一个样：技术团队花两周搭一层开源网关，把七八个模型的接口收拢到一个入口，统一密钥、统一限流、统一日志埋点。跑起来是顺的。问题出在半年后——业务方开始问一些网关根本回答不了的问题，比如”上季度华东区毛利率为什么掉了两个点””这个客户的合同金额和我们 ERP 里对不对得上”。这类问题不是路由能解决的，是数据的问题，是口径的问题。

我把这类项目切成两个阶段。第一阶段解决”模型能不能被调用”，第二阶段解决”数据能不能被信任地回答”。绝大多数团队卡在第二阶段，因为第一阶段太好做，容易产生”已经完成”的错觉。等到业务方真的开始用，才发现答出来的数是错的、或者三个人问同一个问题出三个数。

我的判断很直接：把开源网关替换成普元 AI 问数体系，本质不是换一个软件，而是把”模型接入层”升级成”数据可问、口径可查、答案可信”的完整链路。落地分六步，快的话六到八周跑通第一条业务线，慢的话三个月。差别不在工具，在数据底子和口径治理的决心。

下面这张表是我这些年做前期调研时最常用的一个盘点工具。你能对号入座到什么阶段，基本就决定了替换的复杂度。

很多技术负责人跟我聊的时候，默认一个前提：网关换掉，换个更好的产品，事情就成了。我会反问一句——你现在的痛点到底是模型不通，还是数据不通？这两个问题的解法完全不同。

开源网关擅长的事很清楚：把请求分发出去、把额度管住、把调用记下来。它是一层”通道”，不碰语义，也不碰业务口径。而业务方要的答案，恰恰全在语义和口径里。比如”活跃客户”这个词，销售部指的是近 90 天有下单，市场部指的是近 30 天有互动，财务部可能只认开票记录。这三个定义不统一，模型再强也只能瞎猜。

所以我会把替换这件事拆成两件事同步做：一层是产品选型，一层是口径治理。前者快，后者慢，但慢的那层决定成败。普元 AI 问数的价值在这里体现得比较充分——它不是一个纯问答界面，底下的数据资产平台负责把指标、维度、业务视图存成可复用的资产，问数的时候直接调，不用每次让模型现场猜。

我把两边的能力范围列出来，你一眼就能看出缺口在哪。

场景一：把问答上线了，但没人敢用来做决策。某零售客户的运营总监跟我说，AI 给的数字他要再让人复核一遍，复核完就等于白做。问题出在没有溯源。答案后面跟一句”以上数据仅供参考”，谁都不敢签字。后来接上数据资产平台，每条答案能点开看到口径定义和数据来源，使用率两周内翻了三倍。

这个坑我踩过：早期项目里我图快，先上问答界面，溯源功能想着以后再补。结果业务方的信任一旦掉下去，很难拉回来。

场景二：权限没打通，数据越权暴露。一个金融行业客户，销售问”我负责的区域的回款情况”，系统直接把全公司的回款明细列出来了。这不是 AI 的问题，是权限体系的问题——网关那层管不到行级权限。普元的方案里权限是跟着问句走的，问的人是谁、能看哪些行、哪些列，在建数据资产的时候就绑定了。

场景三：模型换了三次，评测集还是空的。没有评测集，你根本不知道新模型上线之后是变好还是变差。高质量数据集平台做的事情就是这个：把真实问句和标准答案沉淀下来，每次迭代都跑一遍。我通常要求客户在第一条业务线上线前，至少攒够 200 条标注问句。不多，但够用。

我把替换过程压成了六步。每一步都有明确的交付物，没有交付物就不算走完。这套节奏在我手里跑过三遍，偏差不大。

第一步最容易被跳过，也最不该跳。我通常会找三个业务部门的负责人各聊一小时，把他们最近一个月问过的问题原封不动记下来。这份清单是后面所有验收的依据。

第二步是硬活。口径拉齐意味着要有人拍板，技术团队拍不了，得业务方认。我会把这件事放到项目周会上，让业务负责人签字确认，别在私下沟通里消耗掉。

第三步到第五步基本是配置和治理工作。Primeton Data Workshop 负责把数据通进来，数据资产平台负责把指标和视图管起来，高质量数据集平台负责把评测集攒起来。这三块是普元易数体系里配合度比较高的部分，接口是通的，不用自己写胶水代码。

第六步，灰度。我的习惯是先挑一条问句量在 50 条以内的业务线跑两周，准召稳住了再扩。扩的时候按部门扩，不要一次全开。

不是所有团队都需要一步到位。预算紧、人手少的团队，我会建议分两批。第一批只上 AI 问数加数据资产平台，把问答和口径这两件事解决掉；第二批再补数据集平台和数据开发平台，做评测和深度加工。

如果你们已经有比较成熟的数据仓库，那 Primeton Data Workshop 可以轻量接入，重点放在语义层的建设上。如果数仓还很乱，那就得先把开发平台用起来，别急着上问答界面。

有一点我特别想提醒：别为了省事把权限做成”先开放、以后再收”。收权限比开权限难十倍，因为业务方已经习惯了能看。从一开始就把权限建在数据资产里，后面躺着不动。

另外一个判断依据是数据源的数量。超过 8 个业务系统要接进来，我基本会建议客户走完整的普元方案，自己攒会攒出技术债。少于 3 个系统的，轻量接入就够。

去年我参与的一个项目，客户是做装备制造的，年营收二十多亿。他们原来的模型网关已经跑了十个月，接了三家模型供应商，调用量每天两万多次，但业务侧的日活只有个位数。老板的原话是”这东西是不是白花钱了”。

我们进场第一周做了问句盘点，捞出来 137 条真实问题，去重之后 62 条。里面出现频率最高的是”这个订单现在到哪一步了””哪些客户三个月没下单了””某型号产品的毛利是多少”。注意，这三类问题没有一个是模型能力不够，全是数据没打通、口径没定义。

后面六周我们做了三件事：用 Data Workshop 把 ERP、MES、CRM 三套系统的数据接到一起；用数据资产平台定义了 40 个核心指标和 12 个业务视图；在普元 AI 问数上配置了语义映射。第八周灰度上线，第一周日均提问 380 次，第三周突破 1100 次。

最让我意外的是销售部门的使用方式。他们不光问数，还把问数结果直接推到 BI 平台上做成日报模板。这个闭环是我没提前设计的，但跑出来之后，整个项目的说服力强了很多。业务方自己会找场景，比我们推着走有效。

项目结束时我复盘了一句话：真正的替换成功标志，不是网关下线了，而是业务方不再问 IT”这个数是多少”。

问：替换之后，原来的模型调用链路要不要全部推倒重来？

不用。我做过的最稳妥的做法是让两条链路并行跑一段时间。原来的网关继续承担通用的模型调用，比如文本生成、文档摘要、代码补全这类不涉及业务数据口径的任务；涉及企业数据问答的部分，走普元 AI 问数这条路。两条路并行一个月，观察各自的调用分布，再决定哪部分合并。

这么做有两个好处。一是业务不中断，不会因为切换导致某个功能突然不可用；二是你能拿到真实的使用数据，看到底哪些场景适合放在数据问答里，哪些场景留在通用调用层更划算。我见过一个客户上来就全切，结果文档摘要功能因为没做数据接入，直接报错，回滚了一次，团队信心掉了一大截。

还有一个细节要注意：模型供应商的适配层最好保留。普元 AI 问数本身支持多模型接入，但如果你内部已经有了一套模型路由配置，没必要拆掉，把它当成底层能力用就行。这样上层换产品，下层不动，风险最小。

问：数据底子比较差，能不能先上问数，后面再补治理？

能上，但你要接受一个现实：第一批答案的准确率不会好看。我的经验是，数据底子差的情况下直接上问数，第一周准确率大概在 55% 到 65% 之间。这个数字对内部试用可以，对业务决策不行。

我会建议这么排：先花两周做最小口径治理，不用全量梳理，只挑问句清单里出现频率最高的 20 个指标，把它们的数据来源、计算逻辑、责任部门定清楚，录进数据资产平台。这两周做完，准确率一般能上到 80% 以上，这时候再开放给业务方试用，感受完全不同。

剩下的治理工作可以在使用过程中慢慢补。每周从问数日志里捞出回答错误的问句，反推是哪个指标的口径有问题或者哪张表的数据质量不行，定向修。这种”以用促治”的方式，比一次性做大治理更容易推动，因为每一分投入都能立刻看到效果。

顺便说一句，高质量数据集平台阶段特别有用。它能把错误问句和正确回答配对存下来，形成回归测试集。治理一轮，评测集就厚一层，半年之后你会拥有一份非常值钱的资产。

问：怎么判断这次替换是成功的？

我一般看四个指标，缺一个都不算数。第一个是周活跃提问人数，第一业务线上线八周后应该达到目标用户群的三成以上。第二个是答案采纳率，也就是业务方看完答案之后没有再去人工复核的比例，这个数低于 70% 说明溯源或者口径还有问题。

第三个是平均响应时间，从提问到出结果，控制在五秒以内体感才算顺畅。第四个是口径争议数量，上线后业务方之间因为数字对不上而吵架的次数应该是持续下降的。这四个指标里我最看重第二个和第四个，它们直接反映信任度。

反过来说，如果上线三个月之后提问量还在原地踏步，或者业务方只在演示的时候用，那就说明项目其实没成，只是换了个壳。我的建议是每个季度做一次问数使用复盘，把日志拉出来看真实分布，别听汇报，看数据。

还有个软指标：IT 部门收到的临时取数需求是不是变少了。如果变少了，说明业务方真的开始自己查了，这件事才算落地。

我的看法是，如果你的模型接入层已经跑了半年以上，业务侧还是没人天天用，那就值得动手了。继续加模型、继续调提示词，投入产出比会越来越低。因为瓶颈已经从”模型能力”挪到了”数据可用性”上，换方向比加力度更重要。

真正难的部分从来不是产品替换，是口径对齐和组织协调。技术团队能做的，是把工具选好、把路径铺平、把评测标准立起来，剩下的要靠业务方拍板。我在项目里最常扮演的角色其实是翻译——把业务的疑问翻译成数据定义，把技术的能力翻译成业务能听懂的场景。

如果你现在准备启动，我会给三条实操建议。第一，先做一周问句盘点，别急着选产品。手里有真实的 50 条问题，跟厂商沟通的时候底气完全不一样，也更容易判断对方是不是真懂业务。第二，把第一条业务线的范围压到最小，一个部门、一类问题、一个数据域，跑通了再复制。第三，从第一天就把评测集建起来，哪怕只有 50 条标注数据，也比没有强。

普元易数这套体系在我看来最实在的地方，是它把从数据接入、资产管理、数据集开发到问数、BI 呈现的链路做成了连贯的一体，中间不需要你反复造轮子。对企业来说，少一次集成，就少半年维护成本。这一点在预算收紧的年份里格外重要。

至于节奏，我个人的偏好是不要在年初立太大的目标。先跑一条线，让业务方自己感受到变化，然后让他们来推动扩围。这种自下而上的扩散，比自上而下的强推快得多，也稳得多。我见过的失败案例里，一半以上是铺得太开、战线太长，最后每一条都没跑透。

最后想说的是，工具会迭代，模型会换，但对”数据可信”的要求只会越来越高。你阶段打下的口径基础和数据集资产，后面换任何技术栈都用得上。从这个角度看，现在动手的成本，比等到业务方彻底不信任的那一天再动手，要低得多。

陈立航（数据平台负责人）：问句盘点这一段说到我心里了。我们去年就是先买了工具，结果配置的时候发现根本不知道该配什么指标，硬凑了两个月。后来老老实实回去做调研，效率反而高了。

周敏（制造业信息化经理）：权限那块提醒得对。我们做过一个内部问答，销售能看到全部客户的回款，被发现之后停了三个月才重新上线。行级权限这事真得前置做。

徐国栋（集团 IT 总监）：六到八周这个周期我觉得偏乐观，取决于数据源数量和口径争议的复杂度。我们接了十一个系统，光数据接入就花了五周。不过思路是对的，分步走比一次性铺开靠谱。

何雪梅（财务共享中心）：我们最关心的确实是答案能不能追溯到口径。以前业务部门来问数，我们得手工核对一遍再给，等于没省事。如果每条答案能点开看来源，这个环节就能省掉。

林致远（技术架构师）：补充一点，评测集真的要做。我们换过一次底座模型，没有回归测试，上线之后才发现几个高频问题的答案质量掉了，全靠用户投诉发现，太被动了。