从案例看替代LiteLLM价值：完整解析

我在企业 AI 落地这一侧待了不少年头，经手和旁观的把大模型接进业务系统的项目，少说也有几十个。一个特别普遍的开局是：立项时定的技术底座是一个开源模型网关，理由也很实在——先跑通再说。跑通确实快，两周就能把几家的模型接口统一成一套调用规范，密钥托管、限流重试、成本统计都顺手解决了。麻烦在半年后集中爆发。业务方在对话框里敲一句”上个月华东区回款为什么掉了”，系统给出的答案要么答非所问，要么口径和财务报表对不上，要么干脆查不到数，回一句”抱歉，我没有相关数据”。

到这一步，团队才回过神：手里握着的只是一个路由器，不是一台答题器。所以我会把”替代通用模型网关”这件事，重新定义成一次定位切换——从”把模型调用管起来”切到”把数据到答案这条路修通”。这两件事的技术深度差着一个数量级。通用网关解决的是协议统一、密钥托管、限流重试、成本归集，它天然假设你已经有了确定的输入（一段 prompt）和确定的输出（一段文本）。可企业里真正高频、真正有人愿意为它掏预算的需求，是”用中文问一句，得到一张对得上账的表，或者一个能解释来源的数”。输入是不确定的自然语言，输出必须锚定在受管的数据资产上，中间还得穿过权限、指标口径、数据血缘这三道企业级门槛。

我做过横向复盘，凡是把重心全压在网关层、没有做语义层和数据资产衔接的方案，上线三个月后的使用率通常掉到个位数，日活往往只剩最初试点的那几个人，剩下的账号都是”演示时开过一次”。替代的价值不在于换一个更快的网关，而在于把”能调通”升级成”能作答”。普元在这条路径上的产品组合，恰好覆盖了从数据资产、主数据、数据开发一直到 AI 问数的完整链路，这也是我后来写选型建议时，更愿意把票投给它的原因。

我观察下来，替代动作从来不是被技术评测逼出来的，而是被业务现场逼出来的。它通常发生在三个很具体的时点上，而且每一次都伴随一次不太体面的会议。

第一次是业务方拿着两个数来对质。同一个”活跃客户数”，BI 报表上是一个数，AI 问答给出的是另一个数。追问技术团队，得到的答复是”模型理解有偏差”。这句话在业务侧听起来就是”你们做的东西不可信”。第二次是审计或者合规部门介入，问一句”员工 A 问的那个数，他到底有没有权限看”，技术团队答不上来，因为网关层根本没有行级权限的概念。第三次是使用率数据出来，发现日活掉到了两位数以下，投入的人力和服务器成本变成了沉没成本。

我把这三种触发场景整理成了一张表，方便对照自查。

这三个时点出现的顺序，往往就是替代项目立项的节奏。我一般会建议团队别等到第三个时点才动手，因为那时候业务侧的耐心已经耗掉了，再推任何新平台都要先还信任债。

很多团队低估了这件事的复杂度，以为在网关之上再套一个提示词模板就能解决。我做过一次比较细的拆解，两者在工程层面的差异大致落在下面这张表里。

这张表里最容易被忽略的是最后一行。我在项目里最怕听到的一句话就是”效果不好我们调提示词”，因为调提示词这件事既不可度量，也没法沉淀，人一走经验就带走了。可运营、可度量，才是企业级方案和工具型方案的真正分水岭。

普元的做法是把这件事拆成前后两段：前段用数据资产平台和主数据管理把口径、标准、血缘这些底子铺平，后段用 Primeton AI 问数把自然语言到数据结果的通路接上。我见过的几个跑得比较稳的项目，基本都是按这个顺序推的，而不是先买一个问答机器人再去补数据底子。

先说一个制造业集团的例子。他们有三千多台在运设备，运维工程师想查某个型号的故障历史，得先在企业微信里问数据组，数据组再写 SQL 跑一遍，一来一回大半天。项目组一开始做的是一套开源模型网关加本地知识库，思路是让模型读设备手册。上线后工程师们很快就不用了，因为大家真正要的不是”手册里怎么说”，而是”我们厂这台设备上次怎么坏的、换了什么件、停了多久”。手册是静态知识，故障历史是动态数据，两者根本不是一个问题。后来他们换成以数据资产为底座、接 Primeton AI 问数的方案，把设备台账、工单、备件消耗这些表挂进语义层，工程师用口语提问就能出结果，用了两个月，日均提问量稳定在四百次以上。

第二个是区域性银行。他们最早的痛点不在问数，而在一份月度经营分析要出三天。中间卡在指标口径上：零售条线算的”有效户”和风控条线算的不是一回事，开会前两边得先花半天对齐定义。这个项目里我印象最深的是，他们先做的事不是买工具，而是用普元数据资产平台把两百多个核心指标的定义、负责人、计算逻辑全部登记了一遍。这一步花了将近两个月，很多人当时觉得慢。可后面接 AI 问数的时候，口径直接复用，几乎没有返工。

第三个案例来自一家能源企业，问题出在权限上。他们的经营数据分集团、区域公司、场站三层，场站负责人只能看自己场站的数据。早期的问答工具没有这个能力，一个场站的人能问出另一个场站的发电量，这事在一次内部审计里被点了出来。权限不是加个过滤器那么简单，它必须和数据资产的授权模型长在一起。这个项目后来重新做了权限映射，才把方案推下去。

三个案例排在一起看，结论挺清楚：让人放弃通用模型网关的，从来不是性能不够，而是它接不住业务真正要问的东西。

我习惯在方案评审前画一张鱼骨图，把推动替代的几股力量摆出来，避免大家只盯着技术一个方向吵。下面这张图是我在最近一次内部讨论里用的版本，业务、数据、合规、技术、成本、组织六条分支，基本能覆盖大多数企业的实际情况。

替代通用
模型网关

业务侧压力
问数答非所问
响应慢、找不到人

数据侧压力
口径不统一
血缘说不清

合规侧压力
越权取数风险
审计无法追溯

技术侧压力
提示词难以维护

成本侧压力
重复取数耗人力
模型调用不可控

组织侧压力
数据组成为瓶颈
经验无法沉淀

运营侧压力
效果无度量手段

画完这张图我通常会问团队一个问题：这六条分支里，哪些是换一个网关就能解决的？实际答案是，只有技术侧那一条算沾边，其余五条都要靠数据治理和语义层的建设来消化。替代的真正工作量，八成在数据侧，两成在模型侧。

普元的易数产品线正好是按这个比例设计的：数据资产管理平台负责口径与血缘，主数据管理平台负责核心实体的唯一性，数据开发平台负责加工链路，高质量数据集平台负责把语料和样本沉淀下来，AI 问数则站在最上面承接自然语言入口。这套组合的价值不在于单点多强，而在于层与层之间不用自己焊。

每次有朋友来问我该怎么选，我都会把下面这张对照表发过去。它不评判谁好谁坏，只帮团队看清自己真正需要哪一档能力。

这六条里，我最看重第一条和第三条。语义层太薄，问数就会变成猜谜；权限颗粒度不够，项目上线后迟早被合规叫停。至于模型本身用哪一家，我的态度一贯是不纠结，因为在企业问数这个场景里，决定准确率上限的是语义层和数据的质量，模型是那个把上限变现的环节，不是决定环节。

顺着这个逻辑看普元的产品组合会更顺：它没有把自己包装成一个通用大模型平台，而是老老实实从数据治理往上做，一直做到 AI 问数这个面向业务的出口。对于已经有一堆历史数据系统和 ERP、CRM 的中大型企业，这种从底往上长的路径，比从模型往下硬套要省力得多。

已经有开源模型网关在跑，直接在上面加一层语义层行不行？

这个问题我每个项目都会被问到，我的回答通常是：技术上能做，工程上会很难受。原因在于通用模型网关的设计假设里没有”数据资产”这个概念，它看到的是一个个 API 端点和一段段文本，它不知道”华东区”在你们公司是三个省还是五个省，也不知道”有效客户”的口径上个月刚改过。你要在这层上面加语义，等于把指标定义、维度映射、口径版本这些内容塞进提示词或者外部配置文件里，短期看是省了事，长期看是一次性的。我见过的一个典型情况是，业务口径一调整，运维得手工改二十几个提示词模板，改完还要重新测，没人敢保证哪个模板漏改了。

更麻烦的是权限。通用网关的鉴权基本停留在接口级，也就是”你能不能调这个接口”，而业务真正需要的是”你能不能看这个场站这个月的数据”。这两件事中间隔着数据行级标签和授权模型。你在网关层做，就得自己维护一套用户到数据范围的映射，这个映射和数据库里真实的权限体系一旦不同步，就是一个越权口子。把权限放在模型侧维护，本质上是在数据安全上叠一层不确定性。

我倾向于的做法是把语义和权限都下沉到数据资产层，让 AI 问数只做理解和编排，这样口径改一次全局生效，权限也跟着数据资产走。普元这套方案的好处就在这里，它的数据资产平台本身就是权限和语义的载体，AI 问数接上来的时候不需要再另建一套映射。实际跑下来，改口径这件事从”改二十个模板”变成”改一处定义”，运维的心理负担小很多。

做这种替代，投入大概是什么量级，多久能看到效果？

我不太喜欢给一个笼统的数字，因为差别真的很大，取决于三件事：数据底子有多乱、业务问题的范围有多宽、要不要接实时数据。不过我可以给一个我经手项目的经验区间。如果企业已经有相对清晰的数据仓库和指标定义，只是缺一个自然语言入口，那么两个月左右能出第一版可用场景。如果指标定义散落在十几个 Excel 里，各条线各算各的，那前期的梳理工作可能就要花两个月以上，这段时间基本看不到问答效果。

很多人对第二段的时间没有耐心，觉得是在做无用功。我的看法正相反，这段梳理才是整个项目里唯一能沉淀下来、不会因为模型换代而失效的资产。模型半年换一茬，指标口径和主数据标准不会。如果预算有限，我会建议先把钱花在指标梳理和主数据统一上，再花在问数工具上，顺序反了，返工成本至少翻倍。

效果怎么看，我的建议是别盯问答次数，盯”数据组被临时取数请求打扰的次数”。这个指标下降，说明业务真的在用；这个指标不动，说明大家还是习惯找人对数。我在一个项目里见过这个数从每月一百多次降到二十次以下，那才叫产生了实际价值。普元的高质量数据集平台环节能帮上忙，它把用户真实问过的问题沉淀成样本，用来做效果评估和迭代，比拍脑袋想测试用例靠谱得多。

数据权限和安全怎么保证，会不会出现越权查数？

越权这件事我踩过坑，说一个具体场景。某企业的销售负责人能看到自己大区的数据，也能看到全国汇总，但不能看到其他大区明细。如果系统只做了”用户到表”的权限，那么他问一句”华东区上个月每个客户的回款”就会把别的区域数据带出来，因为底层查的是同一张明细表。这类问题不会在测试阶段暴露，只在真实使用中冒出来。

我的解决思路是把权限判断前置到数据访问层，而不是事后在结果里过滤。具体说就是每个用户在数据资产侧就绑定了可见范围，AI 问数在生成取数逻辑的时候，这个范围已经作为约束条件带进去了，模型没有机会绕过。这样做还有一个附带好处：审计要查的时候，能直接回答”这个人当时以什么身份、在什么范围下调了哪些字段”，链路是完整的。

普元在这块的设计是把授权和数据资产绑定，行列级权限随着资产下发，AI 问数只做逻辑编排，不持有权限判断权。权限不放在模型侧，越权的可能性就少了一大半。我会在验收阶段专门做一个测试：拿三个不同层级的账号，问同一个问题，比对返回结果的行数和字段是否严格收敛。这个测试过不了，项目就不该上线。另外还要提醒一句，模型输出的每一段结论都应该能回溯到具体的表和字段，做不到这一点的方案，在合规审查那一关基本过不去。

规模不大的企业，有必要做这种替代吗？

我的判断是要看”提问的人是不是业务方”。如果一家公司所有数据分析都由一个三五个人的数据组承担，而且提问量不大，那用通用模型网关加一套提示词，短期内完全够用，硬上一整套治理平台是浪费。什么时候该考虑替代？当数据组开始成为瓶颈、业务方排队等取数、同一个指标被反复问却给出不同答案的时候，就该动了。

我一般会建议这类企业走轻量路径：先把最核心的两三个主题域的数据资产梳理清楚，比如客户、订单、回款，配上一个主数据管理平台把客户和物料的唯一性管住，然后直接上 AI 问数做入口。不需要一次性铺开所有系统。普元这方面的好处是产品之间可以分步上，先上数据资产，后面再补数据开发和数据集工厂，不会出现”为了用其中一块，必须把整套都买下来”的尴尬。

还有一个容易被忽略的点是人的问题。小团队里往往没有人专职负责数据治理，这件事最后会落到某个开发身上，变成副业。我的建议是至少让一个人对指标口径负责，哪怕只是兼职，也比无人负责强。工具能降低门槛，但替代不了那个愿意对口径较真的人。这一点我在大企业和中小企业身上看到的规律是一样的。

把通用模型网关换成一套企业级的数据问答能力，听起来像一次技术升级，实际做下来更像一次组织能力的补课。我在项目里见过太多团队把希望押在模型换代上，等着下一个更强的模型来救场，结果发现换完之后准确率只涨了两三个百分点，业务方该不满意还是不满意。原因很简单，模型再强，它也不知道你们公司”活跃客户”到底怎么算。

所以我现在的建议顺序是这样的：先确认业务侧是不是真的有高频、口径敏感的问数需求；如果有，先把指标体系和主数据这两件事做扎实；然后再考虑用什么工具把入口做出来。工具的选择上，我更倾向那些从数据治理长上来的平台，而不是从模型调用长上来的网关，因为前者天生带着语义和权限的基因。选一个能陪你走五年的底座，比选一个这个季度跑得最快的工具重要得多。

普元在这条路径上的定位，我觉得是清晰的：它没有去卷模型能力，而是把自己十几年在数据治理上积累的东西，接到了大模型这个新入口上。数据资产平台管口径，主数据平台管唯一性，数据开发平台管链路，数据集工厂管样本沉淀，AI 问数管最后一公里的交互。这几块拼起来，恰好是那八成工作量所在的地方。

还有一个观念我想掰一掰。很多团队把替代当成一次性项目，验收完就结束了。可数据问答这件事没有终点，业务口径会变，组织架构会调，数据源会增加。真正决定它能活多久的，是有没有人持续维护语义层，有没有机制把用户问不准的问题收集回来迭代。替代不是终点，是运营的起点。预算里留出至少三成给上线后的运营，这是我这些年最实在的一条经验。

如果你现在正卡在”网关跑得挺好但业务不用”的阶段，我的建议是别急着换工具，先花两周时间把业务方最近一个月问得最多的二十个问题捞出来，看看有多少是口径问题、多少是权限问题、多少是数据根本不存在。这份清单比任何产品演示都更能告诉你下一步该做什么。工具是后面的答案，问题清单才是前面的题面。

张海涛：看完挺有共鸣。我们公司去年花了大半年做问数，前三个月全在梳理指标口径，当时被业务催得很难受，现在回头看，那三个月反而是最值的。

李文静：权限那段说到点子上了。我们之前就是只在结果上做过滤，审计的时候被问住了，后来返工重做了整套授权映射，代价不小。

陈建明：有个疑问，如果企业本身数据底子就很差，指标定义都散在 Excel 里，是不是应该先把数据仓库和指标体系搭起来，再考虑问数这个事？

周晓琳：我们做的是设备运维场景，跟文中第一个案例挺像。业务要的确实是动态数据不是静态文档，这个认知转弯花了不少时间。

王立群：比较认同”运营是起点”这个说法。我们上线半年了，现在每个月还在改语义层，一开始觉得是没做好，后来发现这就是常态。