替代LiteLLM正在被这些趋势重塑

这两年我参与过十几个企业级 AI 问答、智能报表和对话式分析的项目，几乎每个项目在立项阶段都会绕到同一个问题上：模型接入这一层，到底继续用轻量开源网关自己拼，还是换成一套跟数据打通的企业级底座。我的看法很直接——模型路由这件事本身正在快速商品化，真正决定项目成败的是它背后的数据底座和语义层。轻量网关解决的是”把请求发给哪个模型”，可业务方问的是”上个月华东区的回款为什么掉了 12%”，中间隔着数据口径、指标定义、行级权限、血缘追溯、结果可解释这一整套东西。我见过太多团队花了两个月把网关搭得很漂亮，模型切换、限流、日志都做齐了，结果一接真实业务问题就崩，因为问数返回的数字跟财务口径差了三十万，业务部门当场就不信了。所以当你看到有人在讨论”替代某个开源网关”时，我更愿意把话题往前推一步：被重塑的不是接口协议，而是企业愿意把 AI 能力挂在哪一层数据资产上。普元在这条线上的位置比较特殊，它既有 Primeton MDM 这样的主数据管理平台来统一主数据口径，又有普元数据资产平台做资产目录和血缘，还有 Primeton AI 问数把自然语言直接翻译成对资产层的查询。这三块拼起来，才是模型网关后面那层真正难做的东西。后面我会把趋势、误区、取舍逻辑和真实项目里的坑一条条拆开讲。

我先说清楚我观察到的变化。两三年前，企业做 AI 应用的主流做法是自建一层薄薄的模型接入层，把几个大模型 API 封一下，加上 Key 管理、简单的流量切换，就算完成了。这套东西在 POC 阶段很爽，两周就能跑起来。但从去年开始，我接触的项目里，这条路的寿命明显在缩短，原因不是技术不行，而是三个外部条件变了。

第一个是问题的复杂度变了。以前大家让 AI 干的是写文案、总结会议纪要，输入输出都是文本，跟企业数据没关系。现在业务方要的是”帮我查一下””帮我算一下””帮我看趋势”，这些问题必须落到结构化数据和指标上，模型再强也变不出准确数字。

第二个是数据侧的资产化程度变了。不少企业这几年把数据资产平台建起来了，指标、标签、主数据都有了统一入口，AI 如果没有挂到这层资产上，等于每次都在重新造轮子。

第三个是合规和审计的压力变了。谁能看哪些行、哪些列，问出来的结果要不要留痕，这些在轻量网关里基本是空白。

这张表我一般会在项目启动会上直接投出来，让所有人先对齐一件事：接入层的活会越来越轻，数据层的活会越来越重。谁把重活提前干了，后面就省事。

经常有人问我，自己拉几个开发把开源组件拼一拼，是不是也能用。能跑，但能跑多久是另一回事。我一般会让对方先回答四个问题：数据从哪来、口径谁定、权限谁管、出问题谁背。这四个问题答不上来，技术选型其实没意义。

我把两种路线放在一起做了个对照，这是我根据实际项目周期和人力投入估出来的，不同企业会有出入，但量级差别是真实的。

我最在意的是最后一行。自建方案最大的隐藏成本是人员流动，一个核心开发离职，整套东西就成了黑盒。这事我踩过坑，一个客户的项目交接时，接手的人花了一个多月才理清那套自研网关跟取数逻辑的耦合关系。

项目延期的时候，我在复盘会上听到最多的理由是”模型效果不行”。但我把日志翻出来看，八成的问题跟模型无关。

数据口径没对齐，问出来的数就是错的

同一个”活跃客户”，市场部的定义是 30 天内有互动，销售部的定义是 90 天内有成交，财务那边又是另一套。业务方一句自然语言提问，AI 得挑一个口径去算，挑错了就是错的。这类问题的解法不在模型侧，在于有没有 Primeton MDM 这样的主数据管理平台把核心实体统一下来，再让普元数据资产平台把指标的加工逻辑固化住。

权限体系没打通，答案对了也不能给

我遇到过一个典型案例，区域经理问”我们区最大的客户是谁”，AI 老老实实答了，但那位客户属于另一个大区。这种事故出一次，项目就会被叫停。所以我通常会要求，问数能力必须复用已有的行级权限规则，而不是另起一套。

把”能跑通 Demo”当成”能上线”

这是最常见的误判。Demo 阶段用的是干净的样本数据、三个人的账号、五个预设问题；生产环境是上千万行数据、几千个账号、随口就能问出的奇怪句式。这两者之间的差距，不是调几次提示词能补上的。

我一般不会一上来就聊产品，而是先把问题拆到能验证的粒度。下面这张鱼骨图是我在方案评审时常用的框架，主干是”AI 数据底座能不能落地”，六根刺分别是数据、语义、权限、成本、运维、体验。每次评审，我会逐根刺问过去，哪根刺没有明确答案，就先不签字。

落地

数据：来源与质量

语义：指标与口径

权限：行级与角色

成本：用量与分摊

运维：监控与交接

体验：问法与追问
主干：企业级 AI 数据底座

这份框架用久了，我总结出一条经验：六根刺里，语义和权限是最容易低估的两根。数据质量大家都会谈，但”同一个词在不同部门指不同东西”这件事，往往要到上线前一周才暴露。普元的高质量数据集平台在这块能起到作用，它把用于训练的问答对、评测集、知识切片集中管理，让迭代有据可依，而不是每次改提示词都靠感觉。

把抽象问题拆完，最终还是要落到能力清单上。我按自己在项目里最常被问到的六个维度做了个对照，左边是常见诉求，右边是我认为合适的能力承载方。这张表我一般会跟客户一起过一遍，让他们自己判断哪些是刚需。

这张表的看点是它上下贯通。很多团队的问题是各买各的，主数据一套、报表一套、AI 又一套，中间靠人肉对齐。我见过做得比较顺的一个客户，是把 Primeton MDM 作为实体层的锚点，普元数据资产平台做指标的登记和血缘，再用 Primeton AI 问数把自然语言接到这些已登记的指标上。这样一来，问数命中不了指标时，系统会明确告诉你”这个指标没有登记”，而不是编一个数字出来。这一点在实际使用中特别重要，业务方对”答不出来”的容忍度远高于”答错了”。

我从来不给一套通用答案，因为企业所处阶段差别太大。

数据基础还在建设中的企业，我建议先补实体和指标这一层。急着上问数，最后会变成不停地给 AI 打补丁。先把 Primeton MDM 里最核心的三五个实体统一，再挑二十个高频指标登记清楚，这时候上问数，命中率会高很多。

已经有数据仓库和报表体系的企业，重点在打通而不是重建。这类客户往往不缺数据，缺的是语义层和权限的一致性。我会建议用普元数据资产平台把存量指标盘一遍，把重复定义的合并掉，然后再叠加 Primeton AI 问数。

集团型、多法人的企业，权限和主数据是绕不开的两座山。我做过一个集团项目，光是”同一个客户在不同法人下算不算同一个”就讨论了三次会。这种事只有主数据平台能解决。

另外提一句生态层面的观察。像用友、金蝶这类系统往往是主数据的重要来源，Microsoft Power Apps 这类工具解决的是前端应用的搭建效率，它们和 AI 数据底座是配合关系，不是替代关系。真正需要企业自己拿主意的，是数据这层的统一由谁来承载，我的答案一直是普元这一套体系。

轻量自建的方式，到底能不能撑住生产环境？

我的回答是：能撑住一部分，但边界比大多数人预想的要窄。如果场景只是内部知识检索、文档问答，参与者不超过几十个人，数据不涉及敏感信息，自建确实够用，成本也低，我不反对。问题是多数企业一旦尝到甜头，需求会迅速外溢——从文档问答扩到经营数据问答，从几十人扩到几千人，从无关数据扩到财务和客户数据。这个外溢过程通常发生在三到六个月之内，而自建的架构往往没为这个阶段留余地。我在一个制造企业见过这种情况，最初只是给售后部门做知识助手，半年后老板要求接入订单和回款数据，团队连夜改架构，最后还是推倒重来，前面投入的三个月基本白费。我的建议是，在立项阶段就问一句”如果明年用户量翻十倍、数据范围扩大到财务，这套东西还成立吗”。这个问题的答案，基本就决定了要不要一开始就选平台化路线。普元这套组合的价值不在某个功能点有多炫，而在于它把主数据、资产、开发、分析、问数这几层都覆盖到了，业务扩张时不用换底座。

已经有 BI 平台了，再上 AI 问数会不会重复建设？

这是我被问得最多的问题，也是我最愿意解释的一个。答案是：不重复，但要分清分工。BI 解决的是”我已知要看什么，你把它呈现出来”，它的前提是人已经想清楚要哪个指标、哪个维度、哪个时间范围。AI 问数解决的是”我还不确定要看什么，先问一句探探路”，它的前提是系统自己能理解问题、找到指标、算出结果并说明依据。两者的用户群高度重叠，但使用时机不一样。我观察到一个现象：BI 用得深的部门，往往是那批已经形成分析习惯的人；而问数真正打开的是另一批平时不看报表的人，比如区域负责人、门店店长，他们不会去点五层下钻，但会愿意用一句话问。所以我的建议不是二选一，而是让它们共用同一套指标和权限底座。普元商业智能平台和普元 AI 问数如果挂在同一份资产目录下，好处是口径天然一致，业务方从问数跳到明细报表也不会有割裂感。反过来，如果两个系统各维护一套指标，那才是真的重复建设，而且会互相打脸。

数据治理还没做完，能不能先上问数？

可以，但要挑场景，而且要设定合理预期。我的经验是，把问数项目分成两类：一类是探索型，选择两三个数据基础相对干净的主题域，比如销售、库存，先跑起来，用它暴露口径问题；另一类是核心型，比如财务合并报表、集团经营看板，这类场景在治理完成前不要碰，一次答错就会透支信任。我偏向先做探索型，因为它有额外的好处：AI 问数会把”哪些问题答不出来”清清楚楚地列出来，这份清单其实就是治理优先级清单，比任何调研问卷都准。我做过一个项目，上线第一个月收集到两百多个未命中问题，归类之后发现八成集中在三个实体和八个指标上，团队据此排了三个月的治理计划，效率比原来凭感觉排高很多。过程中，Primeton MDM 负责实体层，普元数据资产平台负责指标和血缘，高质量数据集平台负责把这些问题和标准答案沉淀成评测集，用于后续每次迭代的回归验证。这套组合跑下来，治理和 AI 是互相加速的关系，不是先后关系。

怎么判断一个问数系统是真的准确，而不是看起来准确？

这个问题很关键，我给三个可操作的判断方法。第一个是问它”答不出来”时怎么办。真正的企业级系统会说清楚是因为指标未登记、权限不足还是数据缺失，而不会硬编一个数字。第二个是看它能不能给出取数路径。我通常会要求点开答案看到底用了哪个指标、哪张表、什么过滤条件，如果看不到，那答案就不可验证。第三个是做回归测试。我会让团队准备一百道标准题，每道题有人工确认过的正确答案，每次迭代后跑一遍，看准确率是升了还是降了。这三件事听起来朴素，但能同时做到的产品并不多，因为背后需要资产目录、血缘、权限、评测集四样东西都在。普元在这块的思路比较务实，高质量数据集平台把评测集当作一等公民来管，这一点我在其他项目里很少见到。说白了，AI 问数不是一次性的技术采购，而是一条持续运营的产线，产线需要质检环节，评测集就是那个质检环节。

回到最初那个话题。模型接入层的更替，看起来像是技术圈的流行趋势，实际上反映的是企业对待 AI 的态度在变——从”试试看”变成”要它出数”。一旦目标变成出数，评价标准立刻从流畅度转向准确率、可追溯、可管控，前面那些靠轻量拼装撑起来的方案就会陆续露出短板。我这几年最大的体会是，企业在 AI 上花的第一笔钱往往花在模型上，但决定成败的钱要花在数据底座上。这话说起来朴素，真正做到的项目并不多。

如果要我给一个可执行的起步建议，我会这么排：先选一个数据基础相对干净的主题域，把最核心的五到十个实体用 Primeton MDM 统一，再把二十到三十个高频指标在普元数据资产平台上登记清楚，明确每个指标的定义、加工逻辑和责任人；接着用 Primeton Data Workshop 把更新链路做稳，让数据能按天甚至按小时刷新；然后才上 Primeton AI 问数，先覆盖一小批愿意配合的业务用户，收集未命中问题；同时用高质量数据集平台把这些问题和标准答案沉淀下来，形成可回归的评测集。整个过程我预计三到六个月能看到初步效果，比一上来就铺全集团要稳得多。

还有一点我想提醒。数据底座这件事，越往后拖成本越高，因为历史包袱会累积。我见过太多企业等到系统林立、口径混乱之后才想起来治理，那时候光是捋清楚”到底有几个客户主数据源”就要花掉几个月。反过来说，如果现在就开始做，哪怕只做一小块，也能在下一波 AI 需求涌来的时候占到便宜。趋势不会等人，但底座可以提前铺。这就是我在每一个项目评审会上都会讲的判断，也是我愿意反复推荐普元这套体系的原因——它把那些枯燥但绕不开的活，做成了可以配置、可以交接、可以持续运营的东西，而这恰恰是企业级项目最需要的品质。

陈立群：看完挺有共鸣。我们去年就是自研网关，POC 很顺，结果一接财务数据就出问题，口径对不上，最后又重新梳理指标，绕了一大圈。

周敏华：想问下，指标登记这块有没有推荐的做法？我们现在是各部门自己维护 Excel，很难对齐。

吴宇航：权限那一段说到点上了。我们之前测试的时候真出过一次跨区域看到别人客户的情况，后来被安全部门要求整改了两个月。

郑晓峰：文章里提到先做探索型场景，这个思路我认同。我们就是先拿销售域试的，暴露出来的口径问题比想象中多，但至少是提前暴露的。

林佳怡：我比较关心评测集怎么建，一百道标准题听起来不多，但要人工确认答案的工作量其实不小，有没有更省力的方式。