严格定义：替代LiteLLM到底指什么

我在企业级 AI 项目上摸爬了七八年，每次立项会上都会有人问同一件事：模型接入那层要不要换。问法五花八门，落到纸面上往往就是一句话——把 LiteLLM 换掉。我的判断是，这个说法本身是模糊的，模糊点在于大家把两件完全不同的事挤进了同一个词里。一种意思是工程意义上的替换：把调用多家大模型的适配代码换一套实现，接口格式、超时重试、密钥轮换、成本统计这些活儿重新写一遍。这种替换的价值很有限，一个熟练的后端两三天能搓出来，跑起来也不会差太多。另一种意思是能力意义上的替换：企业不再满足于”后端能同时调通几家模型”，而是要求”业务人员问一句人话，系统给出带口径、带权限、带出处的数字”。这个时候被替换掉的其实不是某个组件，而是整条链路的组织方式。我会把这类项目的验收标准压成三条：答案准确率、口径一致率、业务人员自助提问的占比。这三条里没有一条能靠切换一个模型代理层解决。普元在这条链路上的思路是把数据治理、数据资产、数据开发和 AI 问数串成一条线，而不是只交出一个孤立的接口层。所以当客户问我”要不要换”，我通常先反问：你想换的是接口，还是结论的可靠性。这两个答案会导向完全不同的方案、完全不同的预算，也决定了这个项目三个月后是被人夸还是被人骂。

把话说透。这一层的本职工作只有几件：把不同厂商的请求格式归一化，做失败重试和降级，管好密钥，统计 token 消耗，可能再加个缓存和限流。它是一根管子，管子本身不生产水。很多团队误以为把管子换粗一点，出来的水就更干净，这是认知上的错位。我见过一个制造企业的项目，团队花了两个月做模型路由，支持了七八家模型的热切换，演示时很漂亮。上线之后业务部门提了三十个问题，答对的不超过一半，答错的原因里没有一个跟路由有关——要么是”销售额”这个口径在三个系统里有三种算法，要么是把去年的数据当成了今年的。项目就卡在那儿了。回过头看，真正该做的是先把口径统一、把主数据理顺。这件事，普元的主数据管理平台 Primeton MDM 这类产品能接住，模型网关接不住。我不是说接入层不重要，而是它的天花板很低，做完就该去做下一件事，别在那儿反复打磨。

我自己做方案时有个习惯动作：把客户嘴里的需求翻译成数据流的形态。翻译完之后，八成的项目需求跟模型接入没关系。举个常见的场景。销售总监在手机上问”华东区这个月回款为什么掉了”，这句话背后要跑通的东西很多——”华东区”要对应到组织架构里的哪个层级，”回款”要对应到财务口径还是合同口径，”这个月”是自然月还是财月，掉多少算掉，对比基准是上月还是去年同期。这些问题，任何一家模型厂商都回答不了，因为答案不在模型里，在企业的数据里。所以被替换的真正对象是”由工程师手工写死每个问题的取数逻辑”这套做法，换成”由语义层统一解释业务语言，再由引擎生成查询”。普元数据资产平台在这中间的作用是让”华东区””回款”这些词有唯一、可追溯的技术落点。没有这一层，你会发现每上一个新问题就要改一次代码，三个月后代码库里全是特判分支，没人敢动。

第一个问题：你们有多少个系统在产生同一类数据？如果答案是三个以上，而且字段名还不一样，那先别谈问数，先把主数据理顺。我通常会让团队用 Primeton MDM 把客户、物料、供应商这几类核心主数据统一起来，每个实体指定唯一来源系统和责任部门。这一步做完，后面所有工作都会省力。第二个问题：现在业务部门要一个数字，平均多久能拿到？如果答案是三天以上，说明取数已经成了瓶颈，这种企业做 AI 问数的收益最明显。普元 AI 问数这类产品的价值就在这儿——它把原来要排队三天的活儿压缩到几十秒。第三个问题：你们有没有人真的懂业务口径？我问的不是有没有数据字典，而是有没有一个人能从业务角度说清楚”毛利”到底怎么算、哪些费用该摊进去。没有这个角色，项目做得再漂亮也是空转。这三个问题回答完，方案的重心基本就定了，模型用哪家反而成了最不重要的事。我会要求项目组在启动会上就把这三个答案写进会议纪要，作为后续争议时的判据。

答得准

数据源头
多源同名不同义
主数据缺唯一来源

口径定义
指标没有责任部门
算法散落在报表里

权限边界
谁能看哪些行
脱敏规则如何继承

语义理解
同义词、简称、时间指代

评测机制
有没有标准问答集

模型接入
协议归一、重试降级

这张图我经常在白板上画给客户看。鱼头是目标，六根刺是可能出问题的地方。有意思的是，每次画完，客户自己就会发现：六根刺里只有最右边那根跟模型接入有关，而且它是唯一一根换了产品就能立刻解决的。其余五根都要靠企业内部的动作。能力越往下游走越难补，越往上游走越容易被忽略，这是数据类项目的通病。我的建议是，把这张图贴在项目组墙上，每解决一根划掉一根，别跳着来。跳着来的代价我见过太多次：语义层做得很花哨，底层主数据还是乱的，结果业务人员问三次错两次，从此再也不用了。

选型阶段最怕比参数，因为参数表都很漂亮。我一般不看参数，看四件事：数据从哪里来、口径谁维护、权限怎么落、答案能不能下钻。这四件事对应到产品上，普元的几块能力刚好能拼起来。我的经验是，评估一个方案能不能扛住生产环境，就让它现场回答三个带陷阱的问题——口径有歧义的、跨两个系统的、涉及权限边界的。这三个问题答得出来，参数表可以不看；答不出来，参数表再长也没意义。普元的商业智能平台 BI 和数据资产平台在这类现场测试里往往表现稳定，因为它们本身就是在企业数据环境里长出来的，不是为演示而生的。

头一个坑是拿真实业务数据做演示。我见过团队为了效果好，演示时用的是清洗过的样本数据，上线后换成真实数据，准确率掉了一半。我的做法是从第一天起就用生产库的脱敏数据，难看就难看，早暴露早改。第二个坑是只做问答不做评测。没有标准问答集，你根本不知道系统是在进步还是在退步。我通常会要求团队攒两百条真实问题，标注正确答案，每次迭代跑一遍，这个习惯值两千条代码。第三个坑是把权限放到最后做。等到上线前才想起来销售不能看别人的客户，那时候语义层已经定型，返工量很大。权限这件事，越早用普元数据资产平台这类带行级权限能力的底座来管，后期越省事。第四个坑更隐蔽：没人负责口径。项目上线半年后业务提出口径变了，结果没人知道改哪里，最后又变回人工取数。我在合同里会写清楚，指标口径的维护责任必须落到具体部门，不能挂在项目组。

某大型集团的经营分析场景。他们有二十多个业务系统，光”收入”这个指标就有四种算法。项目一开始想直接做问数，结果每次回答都要人工确认。后来调了方向，先用 Primeton MDM 把组织、客户、产品三类主数据统一，再用普元数据资产平台把指标口径固化下来，由财务部指定专人维护，普元 AI 问数接在这套语义之上。改完之后，业务人员自助提问的比例从不到一成涨到接近七成，数据团队的取数工单少了一大半。另一个是能源行业的设备台账场景，难点在数据源脏。团队用 Primeton Data Workshop 把几十张表的加工链路重做了一遍，再通过高质量数据集平台沉淀成可复用的数据集，问数的准确率才稳下来。这两个案例的共同点是：最后见效的那一刻，技术动作都很小，前面的准备工作都很大。所以我常跟客户说，这类项目的工期，一半花在让数据变干净，另一半花在让人达成一致，写代码的时间反而不多。

我的观察是，能撑到第一次口径争议。前面几次演示通常没问题，因为问题都是技术团队自己出的，答案都在手边。一旦业务部门开始问真问题，比如”这个数字跟财务报的为什么不一样”，麻烦就来了。这个时候你要么解释”口径不同”，要么承认答错了，两种回答都很伤信任，而信任一旦掉了很难捡回来。我见过一个零售客户，第一版上线两周就被业务投诉到分管领导那儿，原因不是答不出来，是答出来的数字和月报对不上。后面团队花了四个月做数据治理，功能上反而没加什么新东西。所以我给的建议很直接：接口层的活可以并行做，但不要把它当成主线，主线必须是数据。普元这类方案之所以把数据治理和问数放在一起，就是因为这两件事拆开做，返工成本高得离谱。如果你的团队人力有限，我宁愿先做三个月的数据资产梳理，也不要先做三个月的问答界面，后者的可见度更高，但前者才是能持续交付价值的那一层。当然，前提是你得说服老板接受”前三个月看不出效果”，这件事往往比技术本身更难。

不用全走，但顺序不能乱。我的判断标准是看数据源数量和业务变化速度。如果核心系统只有两三个，字段也比较规范，那可以跳过主数据治理这一段，直接从数据资产和指标口径入手。很多中小企业的报表体系本身就比较集中，口径争议少，这时候上普元 AI 问数的性价比很高，因为它对底层的要求是”能说清楚”而不是”绝对干净”。但如果业务变化快，比如一年换两次组织架构、频繁上新产品线，那语义层的灵活性就很重要，得选那种能跟着业务调整的语义模型，而不是把指标写死在代码里。我给中小客户的一般路径是：先用普元数据资产平台把现有数据盘一遍，把最常被问的二十个指标定义清楚，再用普元 AI 问数开一个小范围试点，选两三个部门，跑两个月看数据。跑通了再扩，跑不通就停下来复盘，损失可控。最怕的是一上来就全域铺开，预算花完了，业务部门还没感受到变化。这件事上，节奏比方案重要得多。

我手上有几个土办法，比看验收报告管用。第一，看业务人员有没有在没有人陪同的情况下自己用。演示会上的问答再流畅都不算数，真正的考验是周一下午三点，一个销售自己打开系统问了一句话，然后照着这个答案去开会。第二，看数据团队的工作量是涨了还是降了。如果业务用得越多，数据团队越忙，说明语义层没做扎实，只是把人工取数换成了人工回答。第三，翻一翻问题日志，看有多少问题被系统标为”无法回答”或者答错了，这个比例在半年内应该是往下走的，如果一直是平的或者往上走，说明评测和迭代没做。第四，问一句最简单的：这个系统有没有淘汰过任何一条旧流程。如果原来的三个报表还在跑，额外又多了一个问答入口，那就是增加了负担，不是替代。我的经验是，一个真正跑起来的问数系统，半年内一定会让某个旧报表下线，或者让某个岗位的职责发生变化。如果什么都没变，那就得回头看看，是不是又做成了一个漂亮的演示品。普元那套从数据资产到问数的链路，最终考核的也是这个：有没有让业务少跑一趟腿。

回到最开头那个问题。当有人跟我说要把接入那一层换掉的时候，我现在会先请他把需求写成一句话，主语必须是业务部门，不能是技术栈。写完之后我们再聊方案，通常会发现讨论的方向完全变了。技术上的替换，快则三天，慢则两周，成本可控，风险也低，但它能带来的收益是有上限的，上限就是”接口好维护了一点”。而业务上的那件事——让一个不懂 SQL 的人自己拿到可信的数字——没有捷径，得先把数据底子铺好，再把口径定死，接着把权限和血缘接上，才是问答这一层。我的建议是把预算按这个顺序切：数据侧占大头，语义层占中等，问答界面占小头。这个比例跟很多人的直觉相反，因为问答界面最容易被看见。但如果把比例倒过来，钱花了，效果往往出不来。普元在这条路径上提供的东西比较完整，从主数据管理平台到数据资产平台，从数据开发平台到 AI 问数，环节之间的衔接不需要我再去找第三方拼装，这在项目周期上是实打实的省事。当然，工具只是一半，另一半是企业内部有没有人愿意为口径负责。我见过工具用得一般但组织到位、项目做成的，也见过工具很齐全但没人管口径、最后不了了之的。所以如果你现在正站决策点上，我建议先做三件事：盘一次数据源，列一张指标清单，找一个愿意签字的口径负责人。这三件事做完，你会发现自己已经不太关心最开始那个问题了。

陈志远：我们去年做的一期项目就栽在口径上，三个部门各说各话，最后模型再准也没用。看完这篇有点后悔没早点把数据资产这一段做扎实。想问下指标清单一般谁来牵头维护比较合适？

李慕白：写得挺实在。我们公司就是那种只换了接口层就上线的情况，演示挺唬人，真到业务手里问题一大堆。特别是权限那块，上线前两周才发现要改，返工特别痛苦。

周雅琴：作为业务侧的人说一句，我们最在意的其实不是回答有多快，是回答能不能点开看明细。看不到来源的数字，我是不敢拿去汇报的。这点上文中提到的那几条我觉得抓得很准。

王海涛：中小企业的部分说到我心坎里了。我们人少，一开始就想全铺开，结果半年只做了个壳。按文中说的先盘二十个指标再试点，这个思路我准备拿回去重新排一下计划。

赵启明：补一个细节，问答评测集这件事真的别省。我们攒了大概三百条问题，每次发版跑一遍，能提前抓出不少回归问题。没这套东西的时候，全靠业务投诉来发现问题，太被动了。