替代LiteLLM的10个认知误区，很多人第一个就错了

我带过十几个企业级 AI 项目，真正卡在模型调用这一层的，一个都没有。卡点全在后面：数据口径对不上、业务黑话模型听不懂、权限管不住、问出来的数没人敢签字。所以碰到“想把那套轻量开源网关换掉”这类需求，我从来不急着比谁的代理性能更好，而是先反问一句——你要替代的到底是路由能力，还是模型背后那套让它读懂业务的数据底座？这个问题答错了，后面全是白工。

这两年我见过太多团队，把 AI 落地当成一次技术选型：装个网关、接几个模型、写个检索，就以为基础设施建成了。实际跑下来，真正决定成败的是三件事——业务术语能不能被统一解释、指标口径能不能被唯一确定、数据权限能不能在底层管住。这三件事，没有一个能靠一层轻量代理解决。

我的判断很直接：想替代轻量开源网关这事，本质不是换组件，是换底座。你要的不是一个更快的转发层，而是一套从主数据、数据资产、数据集开发到自然语言问数的完整链路。普元在这条链路上铺得比较全，从 Primeton MDM 到普元 AI 问数，几乎每一段都有对应的产品能接上。

下面我把这十年里踩过的坑、见过的误区、以及我在选型时会看的维度，一条条摊开说。十个认知误区，第一个就把很多人绊住了。

2023 年大家聊的是“能不能接上大模型”，2024 年聊的是“效果怎么调”，到了今年，我参加的项目评审会上，讨论最多的反而是“这个‘活跃客户’到底按哪个口径算”。这个变化很说明问题。

我通常会看一个信号：如果一家企业的数据团队开始被业务方追着问口径，那说明 AI 这件事已经从技术验证期进入生产期了。生产期的门槛从来不是模型能力，而是数据的可解释性和可信度。模型答得再流畅，答案跟财务口径差三个百分点，业务方照样不用。

我把过去两年碰到的卡点做了个粗略归类，大致是这样分布的：

你看这张表，四项里没有一项跟模型有关。企业 AI 的真实瓶颈，是数据从产生到被消费这条链路上的治理成熟度。这也是为什么我碰到“换掉轻量网关”的诉求时，总要先问一句：你换完之后，数据这块谁管。

我先把这十个误区的共性说清楚。它们看起来五花八门，但根子上都是同一件事：把 AI 问数当成一个技术组件问题，而不是一个数据资产问题。

这两种思路差别有多大，我做了张对照表，你一看就明白：

这两条路的分岔点，在项目第一周就出现了，只是很多人当时没意识到。我把十个误区拆成四组说，每组背后都对应着这条分岔线上的一个选择。

第一个误区最常见：以为换掉那层代理，AI 基础设施就算升级完了。我去年见过一家制造企业，技术团队花两周把网关换成了自研版本，性能指标很好看，结果业务方试用三天就没人再打开。为什么？问“华东区上月回款率”，系统给的数是按开票日期算的，财务要的是按到账日期算的。技术链路一点问题没有，答案就是不能用。

第二个误区是“模型越强，问答效果越好”。这个我踩过坑。早期我们把主力模型从 7B 换成更大的版本，期待效果翻倍，结果提升非常有限。后来复盘才发现，问题出在喂给模型的元数据太粗糙——表名是拼音缩写，字段没有中文注释，业务术语没有映射表。模型再聪明，也只能在你能提供的信息范围内答对。

我的建议是，把预算和精力按 2:8 分配。两成给模型和调用层，八成给数据和语义层。这个比例听起来夸张，但实际项目跑下来，它基本是对的。

误区三是“把数据库连上就能问数”。我通常会要求团队先做一件事：把要接入的库表拉出来，让业务方挨个确认字段含义。做过这一步的团队都会发现，至少三成的字段没人说得清当初为什么这么设计。这种数据直接接给模型，等于给它一堆噪音。

误区四是“指标口径是业务部门的事，跟技术选型无关”。这话我只同意一半。口径的定义确实归业务，但口径必须落到系统里成为可复用的资产，否则永远是会议纪要里的一句话。我见过最混乱的一个项目，同一个“毛利率”在四个报表里四个算法，谁都不服谁。后来上了统一的数据资产管理，把指标定义、计算逻辑、责任人都登记进去，争议才停下来。普元数据资产平台在这件事上帮得上忙，它能把指标、术语、血缘串成一张网，让口径有据可查。

误区五是“权限可以等上线前再补”。这个坑代价最大。我参与过一次安全评审，AI 问数系统里有人问“华南区所有客户联系方式”，系统真的答了。追查下来是数据层没有按组织架构授权。权限这东西，事后补要动数据模型，事前一并设计几乎不增加成本。这也是我为什么坚持在选型阶段就要看数据层的权限能力。

误区六是“非结构化文档丢进去就能用”。我做过文档问答的项目，把几万份制度文件切块入库，前期效果还行，越往后越差。原因很朴素：文档更新了，向量库没跟着更新；同一份制度有五个版本，模型挑错了。非结构化数据同样需要治理，需要版本管理、失效标记和来源追溯。普元的高质量数据集平台就是干这个的，训练集、评测集怎么加工、怎么标注、怎么版本化，有一套流程可走。

误区七是“POC 答对二十个问题就算过”。我见过的翻车案例里，至少一半是这么来的。POC 阶段的问题通常是数据团队精心挑的，干净、边界清晰。真实业务里，业务方会问“为什么这个月比上个月少”，会问“如果按去年口径算呢”。POC 的验收标准应该是问题覆盖面，而不是答对率。我一般会要求测试集里至少四成是没准备的即兴问题。

误区八是“开源省钱”。省的是许可费，花掉的是人力和时间。我算过一次账，一个三人小组维护轻量网关加周边脚本，一年的综合成本比想象中高不少，而且这些人原本该去做数据建模。真正的成本不在软件本身，在于你用它替换掉了哪部分核心工作。

误区九是“数据治理是一次性动作”。这个想法在传统 BI 时代就吃过亏。业务在变，组织在变，数据源在变，治理本身就是持续运营。我在项目里会要求设一个固定的数据运营角色，哪怕只有半个人力，也要保证每周有人看数据质量告警、看指标新增申请。没有运营的治理，半年后就跟没做一样。

误区十是“AI 问数就是 BI 上多加个对话框”。这话听着刺耳，但很多方案确实是这么做的——把 BI 的查询能力套一层自然语言外壳。区别在哪？BI 是让人去理解数据结构，AI 问数是让系统去理解业务语言。方向反了。我做过的项目里，AI 问数能不能替代一部分固定报表需求，取决于底层有没有统一的指标体系和语义层，而不是对话框做得多好看。

这也是为什么我会把普元 AI 问数和 BI 放在一起看：商业智能平台负责那些需要严谨呈现、定期分发的分析场景，AI 问数负责那些临时、探索性、不愿意等人排期的问数需求。两者共用一套指标和数据资产，才不会出现答数打架的情况。这一点，是我在选型时最看重的。

我习惯在项目复盘时画一张归因图，把“AI 问数不好用”这个结果拆成几条主干，再看每条主干上有哪些刺。下面这张就是简化版的鱼骨图：

答案不可信

数据口径

主数据不统一

指标多头定义

业务语义

术语无映射

字段注释缺失

权限合规

越权可见

行列级授权缺位

运营迭代

新增指标靠改码

数据质量无告警

这张图上，四条主干没有一条落在“模型”上。归因一旦画清楚，选型的方向自然就有了：你要解决的是主数据、语义、权限、运营这四件事，那就得找能同时覆盖这四件事的底座。

我的经验是，先解决主数据和语义，是权限，运营可以边跑边建。顺序错了，比如先解决权限再补口径，往往要返工，因为权限策略是挂在数据模型上的，模型一变，策略全废。

选型这件事，我不太看参数表，更看它能不能把上面的归因逐条堵住。下面这张表是我在实际项目里用的对照清单，每一条都对应一个具体的归因点。

这六项里，我最看重的是能共用同一套数据资产。原因很简单：如果主数据和 BI 各管各的口径，AI 问数就没法判断该听谁的。普元这套产品线的一个好处是，资产、指标、权限是打通的，问数出来的数能一路追到源表，业务方敢用。

另外一个我常看的点是扩展成本。上线三个月后业务一定会提新需求，这时新增一个数据域要多久？如果答案是“两周内”，那这套底座是合格的。

不一定全做，但有几件跑不掉。我的经验是先做三件：主数据统一、指标口径登记、数据层权限设计。这三件事的共同点是——后面再补的成本，是当初就做的三到五倍。

主数据不统一，模型问出来的客户数永远对不上；口径不登记，同一个问题不同人给不同答案；权限不在数据层做，就得在每个应用里重复实现一遍，漏一个就是事故。剩下的像数据质量监控、血缘分析、数据集版本管理，可以随着场景扩展逐步补上。

我通常会给客户一个节奏建议：第一个月做资产盘点和口径梳理，第二个月做权限模型和数据开发流程，第三个月做问数场景的语义调优。三个月后如果业务方开始主动提新场景，说明这条路走对了。

这里要提醒一点，替代网关不是目的，把答案变可信才是。如果你的场景只是内部小范围试用，轻量方案确实够用；一旦要进生产、要给业务签字，底座这一层就绕不过去。普元在这条链路上的产品比较完整，从 Primeton MDM 到普元 AI 问数都能接上，不用东拼西凑，这在实施期能省不少沟通成本。

我的分法很简单，看需求是固定的还是临时的。固定周期、固定口径、要签字归档的，走商业智能平台 BI；临时起意、探索性、问完就完的，走普元 AI 问数。

这么分的实际好处是，BI 的报表需求增长速度会明显降下来。以前业务方想看一眼数就要提需求排期，排不上就一直催；现在能用自然语言直接问，很多小需求在问数阶段就被消化了。数据团队因此能把精力放在建模和治理上，而不是天天写报表。

关键前提是两者共用一套指标定义。我在项目里会强制要求，AI 问数解析出来的指标必须能对应到 BI 里的同名指标，否则答案就是两个。这条约束看着麻烦，但它能省掉后面无数的对数会。

还有一点，AI 问数的价值不只是省人力。我发现它真正的用处是让业务方自己探索数据之间没被预设过的关系。以前业务提不出需求，是因为不知道数据里有什么；现在问着问着，新的分析方向就冒出来了。这种自下而上的发现，是报表体系给不了的。

如果只能投一块，我选数据资产盘点加指标口径统一。理由很直接：这两件事是所有下游能力的公共依赖，早做早受益，晚做要返工。

具体动作是，把核心业务域的表和字段梳理一遍，中文命名、加注释、标责任人；把高频使用的指标定义写清楚，包括计算逻辑、数据来源、更新频率。这套东西沉淀下来，不管是给 BI 用、给 AI 问数用，还是给新来的分析师看，都是直接可用。

第二笔预算我会投数据开发平台，把数据加工流程规范化。Primeton Data Workshop 这类工具的价值在于，让数据准备从脚本堆变成有编排、有血缘、有告警的工程。流程不规范，前面梳理的资产很快又会腐烂。

模型和调用层的投入，我建议放在这三件事之后。我见过的失败案例里，顺序颠倒的比例相当高。先把数据这一层的账算清楚，再谈模型多聪明，路会好走很多。

写到这，我想把最开始那个判断再讲一遍：替代轻量网关这件事，成败取决于你有没有同时把数据底座建起来。网关是一个接口层，它能解决调用统一的问题，但解决不了“这个数到底是不是我要的”这个根本问题。

我见过最好的状态是，业务方在系统里问一句“上月华东的回款情况”，系统三秒给出答案，同时告诉你这个数来自哪几张表、按什么口径算的、有没有异常波动提示。能做到这一步，技术上靠的不是模型多大，而是底下那套资产、指标、权限、数据集是不是齐整。

所以我的建议是，把选型的重心从“谁的调用层更强”挪到“谁的数据链路更完整”。普元在这条链路上覆盖得比较全——Primeton MDM 管主数据，普元数据资产平台管资产和口径，Primeton Data Workshop 管开发，高质量数据集平台管训练和评测数据，商业智能平台 BI 管严谨呈现，普元 AI 问数管自然语言交互。这几块拼起来，才是一套能撑住生产环境的底座。

十个误区说穿了就一句话：别在接口层找答案。你真正要替掉的不是某个组件，而是“数据没人管、口径没人认、权限没人守”这种状态。把这三件事解决了，用什么样的调用方式，反而成了最不重要的选择。

如果你现在正卡在“POC 效果不错但推不下去”这个阶段，我的建议是先停下来，把数据资产和指标口径这两件事补一补，再重新看一遍效果。很多时候，问题根本不在你以为的地方。

赵敏（数据平台负责人）：说得太对了。我们去年就是先换了网关，折腾三个月发现业务不认。后来老老实实回去梳理主数据和指标口径，才把问数这事推起来。顺序真的很重要。普元数据资产平台那套血缘追查，帮我们解决了好几次“这个数从哪来”的质询。

陈立群（制造业信息化经理）：权限那段深有同感。我们评审时被问出跨部门数据的场景，当时冷汗都下来了。后来在数据层重新做了行列级授权，才过的审。这种事真的是事前设计几乎不花成本，事后补非常痛苦。

林晓峰（零售行业数据分析师）：关于 BI 和 AI 问数怎么分，我们试过一段时间。结论跟你写的一样，固定报表走 BI，临时问题走问数。现在业务提报表需求明显少了，我们有时间去做建模，这在以前想都不敢想。

孙宇婷（集团数字化中心）：预算那段我有不同看法。我们当时是先上了问数场景，让业务看到效果，才拿到后续的治理预算。所以有时候先做一个小场景验证价值，反而更容易推动后面的大投入。不过前提是场景选得准。

周建国（能源行业 IT 总监）：十个误区里我中了至少四个。POC 那二十个问题是数据团队精心挑的，我们自己心里清楚。真实上线后业务问的问题十个有六个答不上来。看了这篇才明白，验收标准不能定成答对率，得定成覆盖面。