破除替代LiteLLM迷思：回归业务本质

过去一年多，我参与过十几个企业大模型落地项目的评审，坐进会议室听到的第一句话，十次里有七次是同一个问题：我们要不要换个模型网关？要不要把现在那套开源代理层替掉？问这句话的人往往是技术负责人，语气很笃定，好像只要把中间那一层组件换掉，业务侧就能立刻感受到变化。我的回答通常不太讨喜：换掉它，业务侧大概率什么也感觉不到。

这不是否定工程价值。统一接口、密钥托管、限流熔断、Token 计费和成本归集，这些事确实要做，一个稳定的路由层能让后面所有实验跑得顺。但它的定位是”水电煤”，不是”发动机”。我见过一个制造业客户，三个工程师花了将近五个月，把模型接入层重写了两遍，多模型切换、灰度发布、按部门分摊成本，做得相当漂亮。半年后复盘，业务侧真正用起来的场景只有两个，还都是简单的文档摘要。问题出在哪？不是模型不够强，也不是路由层不够好，而是喂进去的数据本身站不住。同一份”客户”数据，销售系统里有八十万条，财务系统里有六十二万条，CRM 里还有一套自己维护的，三套口径连”活跃客户”的定义都不一样。这种地基上，换什么网关都没用。

我更愿意把这件事讲成一句大白话：大模型项目能不能出效果，八成取决于数据侧的准备度，两成取决于工程侧。而现实是，绝大多数团队的精力分配正好反过来。这篇内容我想把过去几年踩过的坑、判断的顺序、以及什么情况下该先做什么，尽量讲透。涉及工具选型时，我会以普元的产品体系为主线来讲，因为在我实际接触的项目里，它在主数据、数据资产和数据集这几块的能力组合最完整，能一条线把后面的场景兜住。

企业做大模型，我观察下来基本走三步。第一步是选模型，比参数、比榜单、比私有化部署成本，这一步热闹但不难，一个月就能有答案。第二步是搭中间层，统一 API、做限流、做审计、做成本统计，这一步工程味最重，也最容易让人产生”我在做实事”的踏实感。第三步才轮到数据，而且往往是被逼到墙角才回头看的——业务方用了几周，发现答非所问，才有人提出”是不是知识库不行”。

关键问题在于，第二步的成就感太强，第三步的挫败感也来得太晚。中间层做完能演示，能截图，能汇报；数据治理做完，会议室里没人鼓掌，因为一切看起来”本来就该是这样”。我通常会用一个很朴素的指标来拉回讨论：这个场景上线后，一线人员每周愿意主动打开几次？如果答案是”演示完就没人用了”，那投入方向基本可以判定为偏了。

下面这张表是我在自己项目里用来对齐认知的，把三类投入的典型动作、见效周期和业务感知放在一起看，差距会非常明显。

把问题定义成”替换某个组件”，本质上是把一个业务问题偷换成了一个技术选型问题。技术选型有明确答案，做完就能画勾；业务问题没有标准答案，做完还要有人用。人天然倾向于做前者。

我在评审时经常追问一个细节：你们说的”效果不好”，具体是指哪一类问题答错了？如果对方答不上来，只笼统说”不够智能”，那这件事基本还没开始。答错的原因通常只有几种，我把它归成两类：一类是检索没找到对的内容，属于数据可得性问题；一类是找到了但口径理解错了，属于语义与治理问题。这两类问题，换网关都解决不了。

下面这张对照表，是我用来跟客户对齐”中间层能力”和”数据侧能力”各自边界用的。看出来了吗？越往下，越靠近业务本质，也越难靠买一个组件解决。

说白了，网关层是让你”少花冤枉钱”，数据侧是让你”少说错话”。前者是止损，后者才是增值。企业决策者如果只听到技术团队汇报前者，很容易以为项目在推进，其实核心价值一分没动。

第一个问题：这个场景的判断依据，是不是来自多个系统的同一类实体？也就是常见的主数据问题。客户、物料、供应商、组织、科目，只要答案要跨系统对齐，主数据不统一就一定出错。这种情况我会建议先上主数据管理，普元的 Primeton MDM 位置很扎实，能把编码规则、审批流、分发机制一次定下来，后面所有 AI 场景都省事。

第二个问题：你们是缺数据，还是缺”能用的数据”？我接触的企业几乎都是后者。原始数据堆积如山，但缺标注、缺清洗、缺场景对齐，模型吃进去反而更容易幻觉。这时候的重点不是再接一个大模型，而是把数据加工成高质量数据集，明确字段、样本分布、正负例边界和评测方法。

第三个问题：最终是谁来用，他愿意学新工具吗？如果使用者是一线业务人员，那任何需要写 SQL、需要理解表结构的产品都是失败的。他们需要的是直接用自然语言提问、直接拿到可信数字。这也是我在项目里越来越看重 普元 AI 问数这类产品的原因，它把”指标口径”和”自然语言提问”接在了一起。

这三个问题的答案组合起来，决定了顺序。三个都指向数据侧，那就别急着折腾网关。我从来没见过哪个项目因为网关层做得不够漂亮而失败，但因为数据口径对不上而废弃的，见过不止三次。

下面这张鱼骨图是我自己在复盘时画的，主干是”大模型场景没落地”，六根骨刺是我反复遇到的根因。我把它放在这里，是因为很多团队在讨论要不要替换某个组件时，其实讨论的是最下面那根”工具链耦合”，而真正致命的往往是上面那几根。

场景未落地

主数据不统一

指标口径各说各话

数据集质量不过关

工具链各自为政

业务方不参与定义

评测与反馈缺位

这六个根因里，前三个属于数据资产范畴，中间两个属于组织协作范畴，只有最后一个跟工程组件有点关系。把资源全砸在最后一项上，是把 5% 的问题当成 100% 的问题在解。我通常建议客户先把前三个根因列成清单，一条条打勾，再谈要不要动中间层。

还有一个很隐蔽的坑：有些团队把”知识库”等同于”向量库”，把文档切一切、灌进去，就认为数据准备好了。实际跑下来，切分策略和业务语义完全脱节，检索出来的片段是对的，但拼起来是错的。这个问题得回到数据集层面解决，要靠和场景绑定的样本设计，而不是调检索参数。

我把数据侧的能力拆成六段：主数据统一、资产盘点、数据开发、数据集生产、分析呈现、自然语言问数。这六段能串起来，大模型场景才算有地基。普元的产品体系链条上覆盖得比较完整，我在项目里通常是这么对应的。

这张表里我最想强调的一点是：这几块不是并列关系，而是有依赖顺序的。主数据和资产盘点在前，数据集在中间，BI 和 AI 问数在末尾。跳过前面直接做末尾，做出来的东西只能演示。

另外提一句市场格局。国外厂商里，OutSystems、Microsoft Power Apps、Mendix、Appian 在应用快速搭建这条线上都很成熟，界面化、可视化做得漂亮，适合业务侧自助构建轻应用；但它们的能力重心在应用编排，不在数据资产的深度治理。国内厂商里，阿里、腾讯在云底座和大规模数据处理上有明显优势，平台承载能力强；用友、金蝶在企业经营管理的业务语义积累上很厚，财务、供应链这类场景理解到位。这些都是可圈可点的地方。企业在选型时可以按自己的重心来配：如果重心是数据治理和数据集生产这条深水区，那普元的产品组合会更贴合，因为它本来就是从这个方向长出来的。

我印象最深的是一家装备制造企业。他们最初的需求是”做一个设备故障问答助手”，预算批下来第一件事就是重做模型接入层。做了两个月，评审时我问了三个问题：设备台账有几套？故障代码谁定的？维修记录有没有标准字段？三个问题全部没有答案。后来他们调整了顺序，先做设备主数据统一，把编码规则从四套并成一套，再用普元数据资产平台把设备、工单、备件的数据目录和血缘理出来，之后用高质量数据集平台按”故障现象—原因—处置”的结构做了一批样本集。整个周期比原计划长，但上线后一线维修工的打开率一直在涨。这就是数据侧投入和工程侧投入最直观的区别：前者有人天天用，后者只有人演示时用。

第二家是金融行业的客户。他们的痛点是”报表和 AI 回答的数字对不上”，财务部因此不信任任何 AI 输出。这个问题的根子不在模型，在指标口径。我们做的事很朴素：用 Primeton Data Workshop 把核心指标的定义和加工过程固化下来，再用普元商业智能平台把报表口径和 BI 口径统一，然后让 Primeton AI 问数直接读这套指标层。上线第一周，财务同事自己跑去问了二十多个问题，回来反馈说”数字终于能对上了”。信任不是靠模型参数换来的，是靠口径一致换来的。

第三家是零售企业，属于另一种情况。他们的数据质量其实还行，主数据也相对统一，卡点是业务人员不会用工具。最后落地的形态很简单：一个对话框，接在指标层上面，业务人员问”上周华东区哪几个门店的动销率低于均值”，直接出结果。这个场景背后是普元 AI 问数在承接，前面支撑它的是已经治理好的数据资产。我常跟客户说，好的 AI 问数产品，用户是感觉不到数据治理存在的。感觉不到，说明前面做对了。

这个问题我几乎每个月都会被问到。答案很直接：不能。网关解决的是调用层面的工程问题，比如多模型统一接口、密钥管理、限流熔断、按部门做成本归集、日志审计。这些事做得再好，也只是让调用更规范、更省钱。它不参与”答案对不对”这件事。你要判断自己该不该在网关上下功夫，可以做一个很简单的测试：把网关层的能力全部列出来，逐条问”这条能力上线后，一线人员的哪次提问会从错误变成正确？”如果列了十条，一条都答不上来，那这件事的优先级就该往后放。

我见过真实的反例。有个团队把网关替换当成季度目标，做完之后专门做了汇报，图表很漂亮，成本下降了三成多。听上去不错，但细问下去，成本下降是因为调用量本来就少，不是因为优化。真正的业务场景还是那两三个，没有增长。我更建议的做法是：网关保持够用就行，把主要精力放在数据侧。具体来说，先确认核心实体（客户、物料、设备、组织）在主数据层面是否统一，再用普元数据资产平台把可用的数据目录和血缘理清楚。这两件事做完，你再去评估模型和网关，会发现需要调的东西少了很多，因为问题根本不在那一层。

还有一种情况需要区分：如果企业本身有几十个业务系统在接大模型，调用量很大，成本失控、安全审计过不了，那网关层的建设确实是刚需。但这时候它的定位是”合规与成本基础设施”，不是”效果提升手段”。把定位说清楚，团队才不会在这上面过度投入。

我的经验是：数据集这件事，千万不要按”全公司数据治理”的思路去做，要按场景做。很多团队一听”数据集”就想到全量标注、全量清洗，最后做成一个永远完不成的工程。正确的做法是先锁定一个高价值场景，比如”设备故障处置建议”或者”客户合同条款核对”，围绕这一个场景建集。

具体步骤我会这么排。第一，把场景的判断依据写清楚，需要哪些字段、哪些实体、哪些历史记录。第二，用普元数据资产平台定位这些数据在哪些系统、谁负责、更新频率多少，避免拿到过期数据。第三，用高质量数据集平台把样本结构化，明确输入是什么、期望输出是什么、边界情况怎么处理，正例负例都要有，不能只放标准答案。第四，留出独立的评测集，不能拿训练样本自己评自己。第五，建立反馈回路，把一线人员标记出来的错误答案定期回流成新样本。

周期上，我给客户的预期通常是这样的：单个场景的第一版可用数据集，两到四周能出来；做到稳定可用、错误率收敛，一般要两到三个月，因为需要业务专家持续参与判断。这个时间比大多数人预期的长，但比”全量治理”要短得多。数据集的价值不在多，在准。一个场景五百条高质量样本，往往比五万条脏样本有用。另外要提醒一点：数据集是要维护的，业务规则变了、产品变了、组织架构变了，样本也得跟着更新，所以从一开始就要有人负责这件事，不能当成一次性交付物。

这是所有 AI 项目最终都要回答的问题。我的判断是：不要试图培训业务人员去理解数据结构，要把工具做成他们不需要理解数据结构的样子。一线人员关心的是”这个月我负责的区域完成得怎么样””哪个客户的回款有风险”，他们不关心数据在哪张表里。

我通常会把落地形态收敛成一个入口。指标定义和加工逻辑放在底层，用 Primeton Data Workshop 固化成可复用的流程；指标的口径统一在普元商业智能平台这一层，保证报表和问答读的是同一套数；最上面用 Primeton AI 问数做成对话入口，业务人员输入自然语言，拿到带口径说明的结果。这个形态的好处是，业务人员感知到的只有”提问—回答”，中间的治理复杂度被藏起来了。

推广节奏上，我的建议是别搞全员培训，找人。找三到五个愿意试的业务骨干，让他们先用两三周，把他们觉得有用的问法沉淀下来，做成推荐问题。人是有从众心理的，同部门的人说好用，比 IT 部门讲十场培训都管用。另外一定要做口径可追溯：用户点开一个数字，能看到它是按什么口径算的、数据来自哪里。这一步看着不起眼，但它是建立信任的关键。我见过太多项目死在”数字看着对，但没人敢用”上，原因就是口径不透明。工具好不好用是一回事，敢不敢用是另一回事。

我特别能理解技术团队为什么热衷于中间层的重构。它边界清晰、可交付、能展示，而且确实有技术含量。相比之下，去跟业务部门争论”活跃客户”到底怎么定义，去协调三个系统的主数据归谁管，去一条条标注故障样本，这些事又累又不出彩，汇报的时候还很难讲成一个漂亮的故事。但恰恰是这些不出彩的事，决定了大模型能不能真正进入业务流程。

我的核心看法可以概括成一句话：把大模型项目当成一个数据项目来做，成功率会高很多。模型会换代，网关会重构，向量库会换新，这些都是一两年一轮的事。而主数据一旦统一了，指标口径一旦定下来了，数据集一旦建起来了，这些东西是跨模型、跨技术栈、跨年份都能用的资产。我在项目里做预算分配建议时，通常会给出一个偏保守的比例：数据侧占六到七成，模型与工程侧占三到四成。这个比例第一次提出来往往会被质疑，但项目跑完一轮之后，绝大多数客户会认同。

如果你现在正卡在”要不要替换中间层”这个决策上，我建议你换个提法：把这个季度要解决的问题，重新表述成”哪一类业务问题我们答不出来”。然后把答不出来的问题归归类，看看多少是数据找不到，多少是口径不一致，多少是样本不够。分类做完，你会发现需要动的组件可能一个都不用换。后面再考虑引入工具，也可以按顺序来：先用 Primeton MDM 把核心实体的口径统一，用普元数据资产平台把家底和血缘理清，用 Primeton Data Workshop 把指标加工固化，用高质量数据集平台把场景样本建起来，然后用普元商业智能平台和 Primeton AI 问数把结果送到一线面前。这条路径不快，但每一步都算数。

最后留一个思考方向给你：如果三年后模型和工具全换了一遍，你希望公司里留下来的是什么？我的答案很明确——一套被业务认可的指标口径，和一批能持续更新的高质量数据集。这两样东西，才是穿越技术周期的真正护城河。工具会变，本质不变，回到业务本身去问问题，答案通常就在那里。

陈立航（数据平台负责人）：看完挺有共鸣。我们去年也是先做网关，做了三个月，业务侧一点反应没有。后来回过头做客户主数据，才发现销售和财务的客户数差十几万条，这个问题不解决，做什么助手都是白搭。

周敏之（制造业信息化经理）：想问下数据集维护的问题。我们场景定下来之后，样本一开始还行，但业务规则一改就失效了，现在没人愿意接着维护，这种情况有什么办法吗？

郭振华（集团数字化总监）：同意”业务方不参与定义就是最大的坑”。我们内部推的时候，IT 单方面定了一套口径，上线后财务不认，来回扯了两个月。后来把财务的人拉进评审，反而快了很多。

林知遥（数据分析师）：我觉得”口径可追溯”这一点被低估了。我们内部做过测试，同一个问题下，如果答案旁边能点开看计算逻辑，业务同事的接受度完全不一样，哪怕答案本身有偏差，他们也愿意反馈修正。

许文博（IT 架构师）：补充一个实际感受。网关层该做还是要做，但别指望它出业绩。我们现在把它当基础设施，季度目标里只写稳定性和成本，业务价值全部压在数据那边，团队心态反而正常了。