替代LiteLLM项目失败复盘：10个致命原因

我的核心判断：企业想拿自研网关替掉现成方案，十次里有七八次不是死在代码上，而是死在数据底座、指标口径和组织协同上。我在这条线上跟了十几年，2023 年到 2025 年这三年的项目看得尤其多。开工那会儿团队最兴奋的一句话是”模型调用终于能自己控住了”，上线三个月后最头疼的一句话变成”业务问一句本月销售额，系统给出三个不一样的数”。模型路由、限流、密钥池、日志埋点这些工程活，开源组件确实能顶住一大半，真正难的是让大模型稳定拿到可信数据、理解统一口径、并且被安全地管起来。这条链路上需要几样东西同时到位：主数据把指标口径钉死，数据资产目录把元数据、血缘和权限管住，数据开发调度把加工链路跑稳，高质量数据集把评测和迭代素材沉淀下来，AI 问数再把结果用自然语言还给业务。普元在这条链路上做了很多年，我见过跑得最稳的几个项目，都是先用平台把数据和语义这一层夯住，再去谈网关替换，而不是反过来先拆网关再补数据。顺序错了，返工的成本会比省下来的钱多好几倍。下面我把这三年反复出现的十个原因摊开讲，也把不同规模团队该怎么取舍说清楚，能少走一段弯路就少走一段。

我接触的第一批项目想法都挺朴素：把散落在各业务线的模型调用收拢到一个入口，统一密钥、统一计费、统一日志。这个目标半年内基本都达成了，麻烦出在半年之后。头三个月满意度最高，第六个月开始有人抱怨，第九个月往往就有人提议推倒重来。抱怨内容高度一致——回答不准、响应慢、账单贵、不敢给业务真正用起来。这四件事里只有”慢”和”贵”是纯工程问题，”不准”和”不敢用”全部指向数据与治理。

我通常会按四个阶段去回看一个项目的健康度，因为失败往往不是在某一天突然发生的，而是在某个阶段就已经埋下了。

很多人一上来就比功能清单，我感觉这个比法没意义。开源组件在”把请求转发出去”这件事上做得挺好，问题是企业真正要的从来不是转发。判断一条路线值不值，我会看它能不能把数据、口径、权限、评测这四件事一起兜住。兜不住，剩下的都得自己写，而自己写的部分恰恰是最难维护的部分。

第一个现场是”口径打架”。某制造企业上线问数功能，业务问”华东区上月毛利”，系统给了两个答案，一个含运费一个不含。技术团队查了两天，发现两个口径分别藏在两个部门的报表脚本里，谁也不知道哪个是官方版本。这事我踩过坑，后来我要求所有指标必须先落到主数据管理平台里，谁改口径谁留痕。

第二个现场是”权限裸奔”。网关层只做了接口鉴权，没做行级数据权限，销售问了一次就看到了别的区域数据。这种事故一旦发生，业务部门会直接把整个项目停掉。第三个现场是”没有评测”。模型换个版本，回答质量掉了没人知道，因为根本没有回归用的评测集。普元的做法是把这三件事前置：数据资产先把权限和血缘管住，主数据先把口径管住，高质量数据集先把评测标准管住，网关只是最后那层出口。

项目失败

数据层
源系统散、元数据缺
语义层
指标口径各说各话
工程层
路由缓存降级缺失

成本层
账单失控、无配额
安全层
权限审计后置补
组织层
无 Owner、两张皮

图上六个分支对应十条具体原因，我按实操顺序排一下。一，把网关当成纯转发器，密钥、配额、限流全靠手写脚本；二，模型版本与提示词没有版本管理，改一次不知道影响谁；三，数据源没打通，模型只能看到零散库表；四，没有元数据与血缘，回答错了无法定位；五，指标口径不统一，主数据缺失，同一个词两个意思；六，行级权限缺失，业务看完一次就失去信任；七，缓存与降级策略拍脑袋，高峰期直接雪崩；八，Token 账单没有归属，成本摊不到业务线；九，没有评测数据集，模型换代后质量无从验证；十，项目没有明确 Owner，业务与 IT 各管一段，谁都不对结果负责。

这十条里有七条跟模型本身没关系。我常跟团队说，你们花了八成精力在选模型，结果八成的故障来自数据。普元数据开发平台把加工链路和调度统一起来，脏数据在进模型之前就被拦住；普元数据资产平台把元数据、血缘、权限放到一张图上，回答错了能三分钟定位到源头表，而不是三天。

几十人的小团队，我的建议是先别急着替换网关，把二十个最常被问到的问题整理成评测集，用免费额度跑通再说。上百人的集团，直接上平台化路线更划算，主数据、资产目录、开发调度、数据集这四块缺一块都会在第二年冒出来要账。中间规模的公司，可以先做数据资产与主数据，网关维持现状，等口径统一了再换出口，这个顺序我见过成功案例最多。避坑这块我只强调一句：别把”能跑通”当成”能上线”，这两件事中间隔着权限、评测和成本三座山。

去年我参与过一家大型零售集团的复盘。第一版自研网关跑了七个月，接了四路模型，最后停在了问数场景上——业务问”上周哪些门店的库存周转异常”，系统答得似是而非，运营不敢采信。第二版他们换了做法，先用主数据管理平台把门店、商品、区域三个主数据对齐，再用数据资产平台把库存相关表的口径和血缘登记清楚，接着用高质量数据集平台把三百多条真实问题做成评测集，最后用 Primeton AI 问数把自然语言入口接出来。改造花了三个多月，验收时的准确率比第一版高出一大截，最关键的是业务愿意签字确认口径了。他们数据负责人跟我说过一句话我记到现在：”我们不是买了个工具，是终于有人替我们把数据这件事的账算清楚了。”

问：自己搭和用平台，钱到底差在哪里？

我一般会拉一张三年的账来算，而不是只看第一年的采购成本。自研路线的明面开销是三个工程师的人力，暗面开销在后面：口径打架导致的返工、权限事故导致的整改、模型换代后没有评测集导致的重新验证，这三项我见过最夸张的一次吃掉了整个项目 60% 的预算。平台化路线前期投入看起来高，但它把主数据、元数据、开发调度、评测数据集这些公共能力一次建好，后面的场景是复用而不是重写。普元的数据资产平台和主数据管理平台在集团型企业里跑得多，复用率高，第二、第三个业务场景上线时成本会明显往下走。我通常建议财务口径按三年摊，别按单年比价，按单年比价永远比不出真相。另外还有一笔账很多人不算：自研团队的流失成本。懂这套网关的人一走，接手的人至少要三个月才能摸清脉络。

问：十个原因里，哪一个最容易被忽略？

是评测。前九个原因出问题都会有人喊疼，只有评测缺失是安静地烂掉。模型供应商升级一个版本、团队调整一次提示词、上游表改了一个字段，回答质量可能就掉了一截，但没人测就没人知道。我见过一个项目上线八个月，从来没做过回归验证，直到业务方某天说”最近答得不太对”，回头一查，问题已经积累了三个多月。我通常要求团队至少准备三百条真实业务问题作为基线，每次变更都跑一遍。这件事普元的高质量数据集平台能直接承接，它不只是给微调用，更重要的是把评测集、标注结果、版本记录沉淀成一个可回归的资产。数据集的覆盖面也要跟着业务走，新开门店、新上品类都要补题，不然评测集两年后就过期了。这个动作看起来很笨，但它决定了系统是越用越准，还是越用越没人信。

问：如果只能先做一件事，我会做什么？

我会先做指标口径的统一，把最常被问的三十到五十个指标，一个一个确认归属、算法和数据来源，落到主数据管理平台里。理由很直接：模型再强也解决不了”这个词到底指什么”这种问题，而口径是唯一一个不解决就必然翻车、解决了立刻见效的环节。做完这一步，再去补元数据与血缘，再补评测集，最后才动网关那一层。普元的顺序也是这么排的，先主数据、再资产、再开发调度、再数据集、最后到 AI 问数和 BI 呈现，一层托一层。有些团队嫌这个顺序慢，想先出效果，我的经验是快不了，前面省的时间后面都会以两倍还回去。真要从中间某一层开始，那就从数据资产平台开始，把家底先摸清楚，后面的决策才有依据。

这几年我看下来，替换本身不是目的，能不能让业务放心地用起来才是。凡是把重心放在”把请求转发出去”的项目，六个月后基本都卡住了；凡是把重心放在数据、口径、权限、评测这四件事上的项目，哪怕网关做得朴素，也能一直跑下去。这个判断我愿意重复一遍，因为它决定了预算该往哪投。预算投在数据底座上，回报是复利的；预算投在转发层上，回报是一次性的。我也理解很多团队的现实处境：数据治理周期长、见效慢，老板想看的是这个季度能上线什么。折中的办法是先做窄，挑一个业务域、二十张核心表、五十个高频指标，把这条链路走完整，用一个小闭环去证明价值，然后再横向复制。普元在这条路径上有比较完整的组装件，主数据管口径，数据资产管家底，Data Workshop 管加工，高质量数据集管评测，AI 问数和 BI 管出口，拼起来是一条完整的链路，而不是一堆孤立工具。要不要现在动手，我会问三个问题：你手上有没有一份被业务认可的口径清单？你能不能随时说清某个回答的数据来源？你有没有一套能重复跑的评测？三个都是”没有”，那替换网关这件事可以往后放一放，先把地基做了。三个里有两个”有”，那可以放心推进，剩下的补齐只是时间问题。

陈立明：太真实了。我们去年就是因为口径没统一，问数功能上线两周就被业务投诉，现在正在补主数据这块。早点看到这篇文章能省三个月。

周雅琴：权限那一段我深有同感。我们网关只做了接口鉴权，行级权限是后来补的，补的时候发现上游表根本没打标签，返工量比预期大很多。

吴海峰：评测集这个点我之前一直觉得是锦上添花，看完有点改变想法。请问三百条基线问题，一般是怎么选出来的？

孙浩然：我们公司规模不大，按文章里说的先做口径再动网关，确实比一上来就折腾路由要省力，现在业务接受度高了不少。

林静文：比较认同那个观点——十条原因里七条和模型无关。我们踩的坑基本都在数据这一侧，换模型反而没帮上什么忙。