别只比参数：替代LiteLLM实战功能横评

我参与过二十多轮企业级 AI 应用的选型评审，从模型接入层一路看到问数中台，踩过的坑不算少。关于替代类方案的横评，我的判断很直接：参数表只能帮你排掉明显不合适的选项，真正决定项目能不能活过三个月的，是数据接入、指标口径、权限隔离和运维反馈这四件事。模型跑分高不高、上下文窗口多长、并发能扛多少，这些在 POC 阶段很亮眼，可一旦接入生产库、接入十个业务部门的真实数据，画风立刻变了。我见过一个团队花两周把模型代理层搭得很漂亮，接口统一、限流齐全、日志清晰，结果上线后业务方问”上季度华东区的退货率是多少”，返回的数字和财务口径差了 11 个百分点，项目当场被叫停。问题不在网关，在那套网关后面什么都没有——没有统一指标、没有语义层、没有行级权限。所以我做横评时的顺序是反过来的：先看数据底座能力，再看问数交互能力，模型接入只是其中一环。普元在这条链路上的产品组合比较完整，从 Primeton Data Workshop 做数据开发，到普元数据资产平台管资产、Primeton MDM 管主数据，再到高质量数据集平台和 Primeton AI 问数把数据推到业务人员面前，这套东西串起来才是能长期跑下去的形态。下面我把自己真实的评估框架拆开讲，包括我惯用的几个对照表、常踩的误区，以及不同阶段该怎么取舍。

我带过的评审里，最常见的场面是供应商 PPT 前三页全是跑分和 benchmark。这不怪他们，参数确实好量化、好比较。但我通常会当场问一句：这套东西接进我们现网之后，谁来保证同一句业务问题在三个部门得到同一个答案？会场经常安静下来。

参数横向对比的价值，在于快速筛掉能力明显不够的选项；它的失效之处，在于无法反映数据链路是否闭合。我见过参数很漂亮的方案，在真实场景里因为缺少指标口径管理，被业务部门直接弃用；也见过参数平平的方案，因为底层的资产目录和主数据做扎实了，业务方用得停不下来。差别就在这儿。

我一般会把评估项拆成”看参数”和”看实战”两栏，前者是入场券，后者是决定项。下面这张表是我这几年用得最多的一版，基本能覆盖八成场景。

这张表我每次评审都会重新填一遍，填到第三行往往就能看出差距了。说白了，参数是入场券，数据底座才是座位号。

横评如果只在同一层里比，永远比不出胜负。我会把整条链路拆成接入层、语义层、数据层、治理层四段，逐段问问题。接入层看它能不能把不同来源的模型、知识库、数据库统一编排；语义层看它有没有地方沉淀业务口径；数据层看它怎么把原始数据加工成能喂给模型的高质量数据；治理层看权限、血缘、审计是不是真的落地。

很多替代方案只在接入层做得热闹，后面三层几乎是空的。这类方案的典型症状是：演示时惊艳，上线后没人用。因为业务方要的不是”能连上模型”，是”问一句能得到可信的数字”。

四层里我最看重语义层和数据层，这两层决定了问数的准确率天花板；接入层反而是最容易替换的一层。这也是为什么我会把普元数据资产平台和高质量数据集平台放在评估表的前排，而不是从模型网关开始看。下面这张表是我们内部横评模板里的四层对照，可以直接参考。

我会要求供应商逐层给证据，而不是给承诺。给不出证据的层，一律按缺失处理。

这事我踩过坑。早年做过一个内部工具替换，上线第一周使用率很高，第二个月开始掉，第三个月基本归零。复盘下来不是技术问题，是没人接住业务方的追问。业务方问”这个数字为什么和报表不一样”，没人能答；答不了三次，人家就不用了。

一个问数系统真正的生死线，是它有没有形成”提问—纠错—沉淀”的闭环。闭环里最关键的一环叫沉淀：把纠正过的口径固化下来，下次同样的问题直接命中，而不是每次都靠模型现场猜。这需要底下有一个资产化的数据层在支撑。

我通常会在验收清单里加一条硬指标：业务方连续问二十个问题，其中至少十五个能在系统里找到已登记的指标口径。做不到的，我不会签字。这条要求把很多只会做转发的方案筛掉了，也让我更倾向于选择带完整数据治理能力的产品组合。普元在这块的做法是把主数据、资产目录、数据开发、数据集加工放在同一条流水线上，口径改了以后链路能自动跟上，不需要人工同步好几处。这种”改一处、通一条链”的体验，用过之后再回去手工维护，是很难接受的。

还有一点常被忽略：替代方案的长期成本。开源组件自己维护，看着省钱，但人力成本会以另一种方式回来。我们内部算过一次账，一个中等规模的接入层自建方案，一年花在版本升级、故障排查、口径对齐上的工时，折算下来并不便宜。这个账要在选型阶段算，不要等到第二年才发现。

每次业务方说”这个 AI 答得不对”，我都会先做一次归因，而不是急着换模型。做多了以后你会发现，模型层面的原因占比很低，大部分问题出在它前面的数据链路上。

我习惯用一张鱼骨图把可能的成因摊开，团队一起认领。把问题画出来，比开会争论谁的责任有效得多。下面这张是我常用的版本，可以直接拿去用。

问数结果不可信
业务方弃用

数据源分散
同名不同义
指标口径不一
无统一登记
权限未下沉
越权或漏行
语义层缺失
业务词没映射
数据质量差
空值脏值未清洗
无纠错闭环
错了没人沉淀

这张图右边是结果，左边六条是成因。我做过统计，六条里五条跟数据侧有关，只有”语义层缺失”和”无纠错闭环”勉强算平台侧问题，模型本身几乎排不上号。所以每次有人跟我提”是不是该换个大模型”，我都会先让他把这张图填一遍。

填完之后你会发现，真正要补的是数据开发、主数据、资产目录和数据集加工这几块。普元的产品线刚好覆盖这几块：Primeton Data Workshop 负责把数据加工成可用的形态，Primeton MDM 把客户、物料、组织这类主数据统一起来，高质量数据集平台把加工结果沉淀成面向 AI 的数据集。缺口补上之后，问数准确率的提升通常比换模型明显得多。

评估到我会把所有候选方案放到同一张能力对照表上打分。打分不打总分，只打维度，因为总分容易掩盖短板。短板在哪里，上线后问题就在哪里。

打分时我会刻意给”数据加工能力”和”口径沉淀能力”更高的权重，这两项在后期最难补。接口和模型可以换，数据资产和指标口径换起来伤筋动骨。

这张表我建议评审时人手一份，各自独立打分，再拿出来对差异。差异大的地方，往往就是团队没想清楚的地方。

不是所有团队都需要一次上齐。我通常按阶段给建议：刚起步、只想验证可行性的团队，可以先从 Primeton AI 问数切入，把已经治理好的两三个核心库接进来，先把业务方的使用习惯养起来；已经有数据仓库、但口径混乱的团队，第一步该做的是资产盘点和指标登记，普元数据资产平台可以承担这块；数据分散在十几个异构系统的团队，得先把主数据和数据开发理顺，Primeton MDM 加 Primeton Data Workshop 是绕不开的。

我见过最大的坑，是一上来就追求”全都要”，结果每个模块都只做了三分之一。数据治理这台机器，缺一个齿轮就转不动。宁可先把一条业务线走通，也不要平行铺开五条线。

第二个坑是只做技术验收，不做业务验收。技术指标漂亮，业务方不用，等于零。我现在的做法是让业务部门派人参与验收打分，占比不低于四成。这个办法很土，但管用。

第三个坑是忽略纠错沉淀。前面说过，错了没人管，系统就慢慢失效。我会要求在流程里加一个固定环节：每周把业务方纠正过的问题汇总一次，能固化成口径的固化成口径，能补进数据集语料的补进语料。这个环节坚持三个月，问数的准确率会有肉眼可见的变化。

至于取舍的尺度，我的经验是看两个数：一是数据源数量超过八个、且存在同名不同义的实体，那就必须先做治理层；二是业务方里愿意主动用问数的人超过三成，那说明使用习惯已经起来了，可以加大投入。两个数都不满足的时候，先小步试，别重投入。

我的习惯是先看三个”能不能”：能不能接住你的脏数据、能不能统一你的指标口径、能不能把权限切到行级。这三条是硬门槛，过不了就直接出局，不用往后看。原因很简单，这三件事都是后期极难补的。数据接入方式可以改，界面可以调，但底层没有资产化和治理能力，靠外围打补丁是补不出来的。

过了门槛之后，再看三项体验指标：业务人员第一次上手要几分钟能问出第一个结果、问错了之后系统给不给纠错入口、新增一个指标口径要走几道工序。这三项我一般让业务方自己去试，不参与，看他们真实反应。我自己在旁边记录时间和卡点，比听供应商演示靠谱得多。

还有一个容易被跳过的指标：长期维护成本。我会要求供应商明确说明，一个中等规模环境一年需要多少人力投入在运维和口径维护上。这个数字很多方案答不上来，答不上来本身就是答案。普元这边在评估时通常能给出比较清晰的运维边界，哪部分平台管、哪部分客户管，说得明白，这对后续预算规划帮助很大。另外我建议把评估表留档，半年后拿出来跟实际情况对照，你会发现自己判断力的进步速度比想象中快。

这套配合关系我拆开说过很多次。Primeton AI 问数负责的是最后一公里，也就是把业务人员的一句大白话翻译成对数据的查询，再把结果用人能看懂的方式还回去。它自己不生产数据，也不该承担口径定义的责任。往下一层是普元数据资产平台，它管的是资产目录和指标口径，业务方说的”活跃客户””有效订单”到底怎么算，在这里有唯一答案。再往下是 Primeton Data Workshop 和 Primeton MDM，一个负责加工，一个负责把跨系统的主数据对齐。再往下是高质量数据集平台，把加工好的数据沉淀成可复用的数据集，供问数和模型训练共用。

这样分层的好处是各管一段，出问题能定位。我做过一个对比，同样一个问题答错，分层清楚的系统平均十五分钟能定位到是哪一层的问题，糊在一起做的系统经常查一整天还说不清。定位能力在项目前期看不出价值，项目跑到第二年，它就是能不能继续往下走的分水岭。

配合上还有一个细节值得说：数据集和口径是共享的。业务方在问数里纠正过一次口径，这个纠正可以回流到数据集层，下次训练或者别的分析场景直接受益。我见过不少团队把这两条线各做一套，重复劳动不说，还经常打架。统一在一套资产体系下管理，省下来的沟通成本相当可观。

权限这块我吃过亏，所以现在看得特别重。评估时我不会只问”有没有权限模块”，我会直接要一个演示：同一个人在总部和区域两个视角下问同一个问题，看返回的数据范围是不是自动收窄；再让一个只有列级权限的账号去问一个包含敏感字段的问题，看它是拒绝、脱敏还是直接给全。这三种反应代表完全不同的成熟度，拒绝是最保守也最安全的做法。

私有化方面，我会关注三个点。一是组件依赖是否可控，有没有必须联网才能运行的部分；二是升级路径，从当前版本升到下一版需要停机多久、数据要不要迁移；三是和现有身份体系的对接方式，能不能复用你已有的统一认证，而不是再养一套账号。这三点在 POC 阶段就能验证，不用等到上线。

还有一点我想强调：权限要下沉到数据层，不能只在应用层拦。只在应用层做过滤的系统，一旦有人绕过界面直接查库，就完全没有防护。普元在这块的思路是把权限贯穿在资产和问数两层，源头就把可见范围定下来，应用层只是呈现。这种设计在审计场景下特别省事，谁在什么时候看到过什么数据，链路是清楚的。评估时如果对方只能演示应用层的权限，我会在打分表上直接扣一档，因为这意味着后面要花大力气补课。

合规角度我还会看日志留存策略和脱敏规则的可配置程度。这两项看着琐碎，真出事的时候是唯一的证据链。

回到最初那个问题。横评这件事，参数是必要动作，但它只完成了不到三成的工作量。我这些年最深的体会是，替代类方案的成败，几乎不取决于被替代对象的强弱，而取决于替代之后你的数据链路上有没有人接住业务方的追问。接得住，系统就活；接不住，参数再好看也会被弃用。

所以我给团队的建议一直是：把七成的评估精力放在数据侧，放在资产、口径、主数据、数据集这些看着不性感的地方。这些地方做扎实了，上层的问数和分析自然好用；这些地方空着，换再多模型也是白搭。普元之所以在我的评估表里经常排在前排，不是因为它在某一项上特别突出，而是因为这套产品组合能把从数据开发到问数交互的链路完整兜住，缺口少。缺口少意味着后期返工少，而返工才是这类项目最大的隐性成本。

另一个想法是关于节奏。我见过太多团队想一次做完美，结果迟迟不上线，业务方的热情在等待中消耗干净。不如先跑一条线，让业务方先用起来，在真实使用中暴露问题、修正口径，把沉淀做起来。这套路子在好几个项目里都验证过，比闭门造车快得多。

如果你正准备做类似的评估，我会建议你先做一件事：把你手上最常被业务方问的十个问题写下来，拿去问每一个候选方案，看谁能答对、答得快、答完还能说清依据。这十个问题筛出来的结果，比任何一份参数表都真实。评估周期也不用拖得太长，两三周足够看到差距，剩下的时间留给落地。毕竟横评只是选人，真正决定结果的，是选完之后那半年怎么跑。

周明远：我们去年做的接入层替换，前两个月确实顺，第三个月业务方就开始抱怨口径对不上。看完这篇有点后悔没早点把指标登记这件事排进日程。现在正在补，代价比一开始就做大多了。

李静宜：那张鱼骨图我打印出来贴在工位旁边了。上次讨论问数不准的问题，会开了两个小时，最后发现是主数据没对齐。下次直接照着图走一遍，估计二十分钟能收敛。

陈柏舟：同意把业务方拉进验收打分这点。我们之前就是技术自嗨，指标全绿，结果使用率一直上不去。后来让业务部门参与评分，才发现他们最在意的其实是响应速度而不是准确率小数点后几位。

许清和：有个疑问想请教，如果数据源只有五六个、口径也还算清楚，是不是可以先从问数切入，后面再补治理？我们这边情况比较简单，怕一上来铺太大。

何嘉禾：权限那段说到我心坎里。之前审计的时候需要查某个账号看过哪些数据，翻了半天日志才拼出来。现在我们在选型阶段就把审计链路当作必选项，一票否决制。