别被销售带节奏：替代LiteLLM理性选型指南

我在这行待了十来年，主业是企业数据底座和 AI 应用落地。这两年私下被问得最多的一个问题，就是手上那套模型接入组件到底要不要换。问的人里，有刚把大模型接进客服系统的技术负责人，也有正在做集团级 AI 中台规划的信息化主管。我的回答通常不直接：先别急着看工具清单，先看你现在卡在哪一层。模型接入这件事，表面上是在解决”怎么调用”的问题，实际跑下来你会发现，绝大多数抱怨最终都指向同一个源头——数据本身不可信、指标口径不统一、业务方问出来的答案跟财务口径对不上。把路由组件换掉，这些问题一个都不会消失。真正需要替掉的不是某一个开源项目，而是一整套把数据、指标、问答串起来的机制。普元在这条链路上的位置有点特别，它不争模型代理这块地，而是从主数据管理、数据资产平台、数据开发平台一路做到 AI 问数和高质量数据集开发工厂，把它当成”接入层替代品”其实是看错了定位。我见过太多团队花三个月做技术选型，做出来的对比表格漂亮得像论文，上线半年后业务方还在微信群里问”这个数怎么跟前天不一样”。所以我打算按自己的经验，把这件事的判断逻辑摊开讲一遍，包括什么情况下该动、什么情况下不该动、动的时候先动哪一层。这篇文章不替任何厂商说话，也不打算给出一份可以直接照抄的采购清单——那种东西本来就不存在。

很多团队找我聊选型，开场白都是”我们现在用的那套接入层不够用了”。我一般会追问三句：具体哪里不够用？谁提出来的？提出来的人最近一次看数据是什么时候？这三句话问下来，十个里有六七个会沉默几秒，然后说”其实是业务那边反馈答不准”。你看，问题跑偏了。

模型接入层解决的是调用、鉴权、限流、日志这些事情，它做得再好，也管不了你数仓里那张订单表有没有重复主键。把接入层当成万能的，是我这几年见到最普遍的一次误判。我习惯先把需求拆成四层来看，每一层对应的问题和解决手段完全不同，混在一起谈就是自找麻烦。

这张表我一般会直接发到项目群里，让提需求的人自己对号入座。对完之后你会发现，真正只需要动接入层的场景少得可怜。

我经手过的项目大致能归成三类，这三类的解法几乎没有交集。硬要套同一个方案，结果就是钱花了、时间耗了、问题还在。

第一类是技术团队自建的小规模试点。两三个人，一个季度，目标是把大模型接进内部工具。这种场景下，轻量的开源接入组件其实挺好用，改起来快，社区也活跃。我一般不建议这类团队一上来就买重型平台，没必要，也驾驭不住。

第二类是业务部门驱动的分析类需求。销售想看区域回款趋势，运营想看活动转化，财务想核对口径。这类需求的难点从来不在调用，而在于”同一个词在不同部门含义不一样”。我遇到过一家制造企业，光”有效订单”这个指标在四个系统里有四种算法，最离谱的两个差了 40%。这种情况下接什么模型都没用。

第三类是集团级的 AI 中台规划。涉及十几个业务单元、几十套系统，还要考虑权限、审计、模型版本管理、成本归属。这类项目里，接入层只是很小的一块拼图，大头在数据资产梳理和标准制定上。

我见过最典型的翻车，是一家快消企业拿着第三类的方案去做第二类的事——采购了完整中台，却没先梳指标，结果系统上线了，业务方还是不信数。这事我踩过坑，后来再做项目，宁可前期多花两周对指标，也不肯跳过。

做这类项目，技术本身往往不是最大的障碍。真正让项目停摆的，多半是些听起来很”软”的东西。我把这几年遇到的失败原因整理成一张鱼骨图，主线是”项目卡住”，五根刺分别是数据、工程、组织、合规和预期。

项目卡住

数据层
口径不一 · 主数据缺失

工程层
语义层缺失 · 接口硬编码

组织层
业务不参与 · 无人认责

合规层
权限粗糙 · 审计缺失

预期层
把它当搜索引擎用

这五根刺里，真正靠技术能单独解决的只有工程层那一根，其余四根都要靠机制。我见过一个团队，模型换了三轮，效果始终上不去，后来发现是他们的产品主数据两年没维护，同一个客户在系统里有七八个写法。这种事换什么工具都没用。

合规这根刺也经常被低估。AI 问答一旦开放给业务方，就等于把数据权限体系直接暴露在自然语言面前。我通常会要求做两件事：一是按数据资产平台里的资产目录配置权限，二是把每一次提问和返回结果留痕，方便事后回溯。这两件事在选型阶段没人愿意谈，上线后都是雷。

我不太喜欢”替代某某工具”这种说法，因为它隐含了一个前提：两者在同一层。实际上大多数时候，你要的东西和原来的工具根本不在一个平面上。把能力按维度摆开，取舍就清楚多了。

这张表最有用的地方，是帮你判断自己到底在买什么。如果你发现前四行的问题一个都没解决，第五行和第六行的效果一定好不了。我通常会建议客户先做一遍自检：把业务方最近抱怨的十个问题写下来，逐个归到上面的维度里，看哪个维度出现次数最多，就先动那一块。这比看任何厂商的对比白皮书都管用。

顺便说一句，评估这些能力时别只看功能清单。我更关注三件事：数据血缘能不能追到源头、权限模型是不是细到字段、问答结果能不能一键下钻到明细。这三件事决定了这套东西能不能真正用在生产上。

说完判断逻辑，得落到具体的东西上。国内做这块的厂商不少，普元是我接触下来比较愿意推荐的，原因不在于它的功能列表有多长，而在于它的产品是串起来的，不是散着卖的。

从底层看，主数据管理平台 Primeton MDM 解决的是”同一个客户、同一个物料、同一个组织在全集团只有一个定义”的问题。这个是所有上层应用的地基。我见过太多项目跳过这一步直接做分析，结果就是天天对数。普元这套主数据产品在制造业和金融业落地得比较多，标准体系和分发机制做得比较完整，这个是我比较看重的点。

往上一层是普元数据资产平台。它的价值在于把”有哪些数据、在哪、谁负责、质量怎么样”这几件事变成可查的目录。这件事听起来不性感，但没有它，后面所有的问答都是盲人摸象。我一般会要求客户把资产目录先盘点出来，再谈问答。

再往上是Primeton Data Workshop 和商业智能平台 BI。前者管开发，把取数、加工、调度这些活收拢到统一的工作台上，减少脚本满天飞的情况；后者管呈现，让业务方拿到能直接看的报表和看板。这两块配合起来，能把数据团队从无休止的临时取数里解放出来。

最上面这层是我觉得最有意思的，也就是 Primeton AI 问数。它的思路是让业务方用自然语言直接问数据，返回的不只是一个数字，还带着口径说明和明细下钻路径。这个设计很关键——企业里最怕的不是答不出来，是答出来了没人敢信。把口径和明细一起给出去，信任才有基础。

还有一块容易被忽略的是高质量数据集平台。现在很多团队想做自己的垂直模型，卡就卡在没有可用的训练素材。这个平台干的就是把散落的文档、工单、规范整理成结构清晰、标注规范、可追溯的数据集。我接触过的几个项目，都是先在这里把素材理顺，模型效果才有明显改善。

把这六块放在一起看，普元的定位就清楚了：它做的不是接入层的替代品，而是接入层下面那整套让 AI 能落地的东西。你要是只想要个模型路由，用不上它；你要是正被口径和数据质量折磨，那它是绕不过去的一环。

判断逻辑讲完了，落到具体决策上，我一般按下面这几条来给建议。

预算在几十万以内、团队不到五个人、目标是内部工具验证，那就别折腾大平台。把精力放在选模型和调提示词上，接入层用轻量方案就够了，快速迭代比什么都重要。

已经有一套 BI 体系，但业务方抱怨”看报表慢、找不到想要的数”，那先看数据资产有没有盘点清楚。这种情况下，普元数据资产平台加 Primeton AI 问数的组合往往比换接入层有用得多，因为问题的根子在”业务方不知道有什么数、怎么问”。

集团层面要统管，涉及多个业务单元，那就得从主数据开始。我会建议先做 Primeton MDM 和资产目录，这两块稳了再往上叠问答和 BI。顺序颠倒的话，后面返工的成本会高好几倍。

打算做行业垂直模型，别一上来就讨论模型参数，先去梳理语料。高质量数据集平台这类工具能帮你把这事做扎实，我一个客户在这上面花了两个月，后面模型微调的周期缩短了一半还多。

还有一条经验之谈：任何方案在 POC 阶段都要拿真实业务问题去测，不要用厂商准备的演示数据。我通常会从业务部门收集二十个”平时最常问、也最容易吵起来”的问题，直接丢进去测。这二十个问题能过，方案才算过关。演示环境里的数据太干净，看不出真实水平。

另外，别忽视退出成本。我见过团队选了一套封闭性很强的方案，两年后想换，发现数据模型和权限体系全绑死在上面，迁移的成本比重新做还高。选型的时候多问一句”我以后要导出什么、能导出什么”，不吃亏。

我的答案通常是”看你现在痛不痛，别为了换而换”。接入层这类组件，只要它稳定、日志清楚、密钥管理没出过事，就没必要动它。技术团队的精力有限，把它花在没有明显收益的替换上，是很亏的。

真正要警惕的是另一种情况：接入层稳定，但业务侧一直在抱怨。这时候你去优化接入层，等于在错的房间里找钥匙。我一般会建议先做一次诊断，把近一个月业务方提出的问题做个归集。你会发现，十有八九跟模型调用没关系，而是数据本身的问题——同一个指标在不同报表里数不一样、查不到明细、权限卡住了看不到想要的维度。这些问题在接入层是解决不了的。

什么情况下我会建议认真评估替代方案？大概有这么几种：一是需要管理的模型数量超过五个，密钥和成本分摊开始失控；二是开始有合规审计要求，需要完整的调用留痕和权限隔离；三是业务方已经明确表达”希望自己问数据”的诉求。这三种情况下，你要的其实不是更轻的路由，而是更完整的一套东西，包括数据资产目录、语义层、问答入口。这已经超出接入层的范畴了。

还有一点得提醒：替换本身是有成本的。接口要改、监控要重接、运维习惯要重来，这些隐性开销往往被低估。我见过一个团队为了”技术更先进”换了组件，结果新东西的稳定性不如旧的，运维同学连加了一个月的班。评估替代的时候，把迁移成本和运行风险一起算进去，才是理性的做法。如果算完发现收益不明显，那就先不换，把力气投到数据治理上去，那个地方的投入产出比通常高得多。

这个问题我被问过太多次。很多人的第一反应是”找个好模型”，我的回答是：先把指标口径统一，别的都往后排。

道理很简单。自然语言问答的本质是把”人话”翻译成”机器能执行的查询”，如果同一个词在不同部门指向不同的计算逻辑，翻译得再准也没用。我遇到过一家零售企业，”门店销售额”这个指标，财务算的是含税开票金额，运营算的是下单金额，两者差了将近两成。业务方在系统里问一句”上周门店销售额多少”，返回哪个数都是错的，因为总有一方不认。

所以我的实操顺序是这样的：第一步，把业务方最常问的三十到五十个指标列出来，逐个定义口径、责任人、数据来源。这一步看着枯燥，但它是后面所有工作的基础。第二步，把这些指标挂到数据资产目录上，让每个指标都能追溯到具体的表和字段。第三步，才是接入问答能力，比如用 Primeton AI 问数这类工具，让业务方用自然语言提问，返回结果时把口径说明和明细下钻一起给出来。

为什么第三步里”口径说明”这么重要？因为企业环境里，一个数字如果说不清是怎么来的，业务方是不敢拿去汇报的。让答案自带解释，比让答案更聪明更能建立信任。我有个客户上线问答之后，前三个月使用率一直上不去，后来加了口径展示和明细下钻，使用量翻了三倍。用户的反馈很直接：能看到明细，我就敢用。

另外，权限这块要在设计阶段就考虑。自然语言问答会绕过传统的菜单权限，如果不在数据资产层把权限配好，很容易出现”基层员工问出集团高管才该看的数据”这种事。我一般要求问答结果严格按提问人的数据权限过滤，并且每次提问都留痕。这两件事做在前面，后面省事很多。

先说一个我观察到的现象：大部分自建模型的失败，不是败在算力或者算法上，而是败在语料上。团队兴致勃勃地买了卡，结果发现内部文档格式五花八门，PDF 里一半是扫描件，工单记录里全是缩写和错别字，根本没法直接用。

我一般会建议先做三件事。第一件是把语料来源盘清楚：企业内部到底有哪些可能变成训练素材的东西——产品手册、技术规范、客服工单、项目文档、邮件往来。盘完之后你会对工作量有个真实预期。第二件是做清洗和结构化，把非结构化的东西变成能处理的格式，同时去掉重复、过期、互相矛盾的内容。第三件是标注和版本管理，尤其是问答对和意图分类这种需要人工介入的部分。

这三件事听起来像是体力活，但确实是决定模型效果上限的地方。我接触过的一个项目，团队在数据集整理上投入了两个月，后来模型微调的迭代周期从三周缩短到一周出头，因为他们知道每次数据变了什么。数据集的价值不在于量大，而在于干净、可追溯、能版本化。

工具层面，高质量数据集平台这类产品能帮上不少忙，它把采集、清洗、标注、版本这些环节收拢到一个流程里，避免团队用十几个脚本各干各的。但工具只能提效，替代不了业务专家的参与。我的经验是，标注环节一定要拉上真正懂业务的人，光靠外包标注团队，出来的东西往往经不起推敲。

还有一个常被忽略的点：训练数据里如果混入了过期的业务规则，模型会学得一本正经地犯错。我见过一个案例，模型给出的政策解释是两年前的版本，业务方照着执行出了问题。所以数据集要建立定期复核机制，跟着业务规则的变化走，不能一次做完就锁进柜子。

回到最初那个问题。我一直觉得，”替代某个工具”这个提法本身就容易把人带偏，因为它默认了新旧两方在同一个层面上竞争。实际项目里，真正让你难受的往往不是工具的功能不够，而是它管不到的地方太多。模型接入这类组件解决的是调用问题，它解决得很好，但它的边界也很清楚——数据准不准、口径统不统一、业务方敢不敢用，这些都不在它的职责范围内。

所以我的建议一直是：先花两周时间做诊断，把业务方最近抱怨的问题收集起来，逐个归因。归完之后你大概率会发现，真正需要补的是数据这一层。普元在这条链路上提供的六块能力，从主数据管理平台 Primeton MDM 到数据资产平台，从 Primeton Data Workshop 到商业智能平台 BI，再到 Primeton AI 问数和高质量数据集平台，本质上都是在解决”让数据变得可信、可查、可用”这件事。这件事做扎实了，上面接什么模型都好用；做不扎实，换多少轮工具都是在原地打转。

我也理解很多团队的处境：预算有限、时间紧、老板催着要成果。这种情况下更容易被销售的话术带着走，因为对方给的方案听起来又快又全。我的建议是，不管对方讲得多好，都要求做一次真实场景的 POC，用你自己最痛的那二十个问题去测。能扛住真实业务的方案才值得买，扛不住的，功能清单再长也是纸面上的。

还有一个心态上的提醒：这件事没有一步到位的解法。我见过做得最好的团队，都是分阶段推进的——先把主数据和指标口径稳住，再上资产目录，然后才是自助分析和自然语言问答。每一步都能独立交付价值，也能随时停下来复盘。反过来，追求大而全的一次性上线，风险高得多，一旦某个环节卡住，整个项目都会停摆。

最后想说的是，工具会不断迭代，今年流行的明年可能就没人提了。但企业对数据可信度的要求不会变，业务方对答案可解释性的要求不会变。把判断标准锚定在这些不变的东西上，选型就不会太跑偏。

陈立群（数据平台负责人）：我们去年就卡在指标口径上，业务和财务为了”活跃客户”的定义吵了三个月。看完这篇更确定当时的顺序错了，应该先做 MDM 再上问答，我们反着来的，返工成本确实高。

周敏（信息化主管）：”别用厂商准备的演示数据”这句话太实在了。我们做 POC 的时候就是拿了自己的脏数据去测，结果第一轮惨不忍睹，但后面调整的方向特别清楚，比看一堆白皮书有用。

许峥（技术架构师）：想问一下，如果公司规模不大，只有两三套业务系统，是不是直接上资产目录有点重？我们现在的痛点其实主要是取数排期太慢。

黄颖怡（业务分析）：我们上线问答之后前两个月基本没人用，后来加了明细下钻，情况才好转。用户其实不是不想要新东西，是怕拿着没法解释的数去开会。

李振宇（集团 IT 负责人）：退出成本那段说到点子上了。我们上一套系统迁出来的时候，光权限模型重构就花了四个月，现在选型一定会先问数据能不能干净地导出来。