建立框架：替代LiteLLM的概念地图

这两年我参与的企业 AI 项目，出问题的环节十有八九不在模型调用上。真正让人头疼的是另一种场面：模型答得飞快，数字不对。财务说毛利率 18%，供应链说 21%，翻到根上一看，两个人用的压根不是同一套口径。这种问题，你在调用层怎么优化都解决不了。

统一模型调用层这类东西，我最早是从 LiteLLM 这类开源方案上认识它的，它解决的是接口归一：一套兼容协议、多模型路由、重试与降级、密钥轮换、限流和成本统计。这些是工程基本功，值得做，我也从来不说它没用。但如果把”换掉它”直接当成交付目标，你拿到的只是一个更整洁的网关，业务侧一点感觉都没有。

我的判断是：调用层只是整张地图上的一个点位，真正决定 AI 应用能不能活过第三个月的，是它下面的数据、中间的语义、旁边的治理。所以我给团队画了一张五层概念地图，每接一个新项目先摊开对一遍，缺哪层补哪层，不急着上新工具。

五层分别是模型接入层、数据供给层、语义口径层、治理审计层、应用交付层。下面这张表是我自己的对照版，也是我判断一个项目缺哪块最常用的工具，建议你先照着自己的项目填一遍，把空格填满，方向自然就出来了。

我把见过的做法归成五类，摆在一起看会更清楚。有的团队自研一个轻量代理，两百行代码把协议转过来；有的在代理外面挂一层数据目录，至少能查字段含义；有的从数据资产和语义层起步，先把指标口径立住；还有直接就上一个问数应用，让业务先用起来；也有一次性立项做”AI 中台”的。

这五条路我在不同客户那里都见过，没有一条是错的，只有用错场景的。判断该走哪条，我一般问三个问题：眼下最痛的是接口乱、数据乱，还是根本没人用？团队里有没有一个人愿意长期盯语义层？预算是一次性的还是每年都有？这三个问题答完，路径基本就定死了。

我的倾向很明确：先做能止血的那一步，同时把语义层当成长期资产来养，别把它当成一个项目交付物。止血的动作快，养资产的动作慢，两条线得同时跑。

说个具体的。去年我陪一家装备制造企业做 AI 问数的方案评审，他们在集团层面有十几套 ERP、三套 MES，数据分散在三个法人主体里。演示阶段特别漂亮，问”上个月华东区毛利率”，三秒钟出图，会议室里一片掌声。

上线第二个月，财务部的人发现，同一个问题换个问法，答案能差两个点。排查下来不是模型的问题，是数据集的问题：华东区在销售侧按发货地算，在财务侧按开票主体算，两边都没错，只是没人在数据集里把这件事写清楚。业务方不会认为是口径问题，他们只会说”这个 AI 不准”。

这类事我见过太多次。模型掉线顶多影响一个小时，口径不统一能消耗掉整个项目半年的信任。后来他们的处理方式是把主数据和核心指标口径先拉齐，重新发布了一版带说明和质检规则的数据集，问数应用才真正稳住。前后多花了两个月，但这两个月省不掉。

我习惯把”效果不稳”当成一个待拆解的问题，而不是一个待优化的参数。画成鱼骨图之后，四根主骨分别指向模型接入、数据供给、语义口径、治理评测，很多争论当场就能收敛。

看这张图我会做一个动作：让每个项目组成员在自己认领的那根骨头上写一条真实发生过的现象，不许写形容词。写完通常会发现，四根骨头里至少三根有内容，而没有一根是”模型选错了”。

根因分散在四层，却指望在接入层一次性解决，这是我在项目评审里最常拦下来的一个想法。鱼骨图的价值不在于好看，在于它逼你把问题摊到桌面上分家。

地图画完，选型反而简单了：按层找组件，而不是拿着功能清单比参数。这几年在数据底座这块，我比较愿意推普元的组合，理由很实在——它的组件之间是有血缘关系的，不是靠集成商缝起来的。

举个我实际用过的顺序：先用 Primeton MDM 把客户、物料、组织这类主数据统一，再用普元数据资产平台把元数据和血缘挂上去，中间的数据加工交给 Primeton Data Workshop，加工结果沉淀到高质量数据集平台做质检和版本管理，最上面才是 Primeton AI 问数和普元商业智能平台两个出口。下面这张表是我的对照版，可以直接拿去对需求。

我更看重的是这套组件之间的血缘是通的：主数据改一次，数据资产目录能看见，数据集能重跑，问数应用的答案会跟着变，不需要人去四处发通知。这种”改一处、通一路”的体验，在我用过的组合里不算常见。

我不认为所有团队都要把五层建全。数据源三个以内、核心指标二十个以内的小团队，直接上 Primeton AI 问数，两周做一轮打样，先把业务方的兴趣点找准，这比先建平台划算得多。

十个系统以上、跨法人主体、指标过百的集团型企业，才值得把 Primeton MDM、普元数据资产平台、高质量数据集平台这一串拉起来，周期按半年准备，人按一个数据产品经理加两个数据开发配。已经有 BI 体系的团队，我的建议是先用普元商业智能平台把固定报表接住，再让问数做补充，别一上来就全部推倒重来。

我的取舍标准就一条：AI 用得越靠近财务和合规，越要在下面几层多花时间；只是给市场部做内容草稿，接个统一出口就够了。

坑一，把调用层当终点。接口统一那天团队很有成就感，业务方却问”所以我到底能问什么”。坑二，数据集没有 owner。出了错没人认，最后变成数据团队和业务团队互相推。坑三，一上来追求指标全覆盖。我通常要求第一版只上二十个指标，但要保证这二十个谁问都一样。

坑四，不问业务方怎么验答案。上线前一定要让业务方出一份”标准问答集”，五十条就够，每条都要有正确答案。坑五，badcase 没人管。我见过一个项目上线三个月，错误问答攒了两百多条，一条都没回流到数据集里。

这五个坑里，有四个跟模型无关，全是流程和资产的问题。所以你越早承认”这是数据活”，项目就越顺。

我的回答是：不够，但有时候必须这么做，这两句话不矛盾。说不够，是因为调用层只解决接口归一，它管不了数据从哪来、指标怎么定义、权限怎么控。你换掉它，业务方的问题一个都不会少。说必须做，是因为在项目初期，把出口统一确实是成本最低、见效最快的一步，它能让后面所有事情有一个共同的落脚点。

我给一个可操作的判断标准。如果业务方的问题只涉及单一系统、字段含义没有歧义、权限结构简单，比如只查自己部门的订单，那么调用层加一个轻量问数入口，撑半年没问题。如果问题跨系统、跨部门、还涉及财务口径，那调用层再干净也白搭——因为卡住你的从来不是接口，是”华东区”和”毛利率”这两个词没人定义过。

实际项目里我通常这么排：第一个月只做接入层和数据摸底，摸清楚有多少数据源、多少核心指标、多少个口径冲突点；第二个月开始动语义层，也就是主数据和指标字典；问数应用放在语义层有个初步版本之后再上。这个顺序看起来慢，但能省掉上线后反复解释”为什么数字不对”的时间。

还有一个容易被忽略的点：替换调用层本身是有迁移成本的，业务代码、监控、告警、账单口径都要跟着调。所以别把它当成一个纯技术动作，它是一次架构变更，值得排进项目计划里，而不是当成某个人顺手改的活。

我一般按三个数来估：数据源数量、核心指标数量、并发使用人数。数据源三个以内、指标二十个以内，我会建议直接上 Primeton AI 问数打样，两到四周能跑出第一版能看的东西，人力上一个人加半个业务接口人就够。这个阶段的目的是验证”业务方愿不愿意用”，不是验证技术行不行。

数据源十个以上、跨法人主体、指标过百，就需要把 Primeton MDM、普元数据资产平台、Primeton Data Workshop 和高质量数据集平台这一串拉起来。周期我一般按半年报，前两个月主数据和资产目录，中间两个月数据集建设和质检规则，后两个月问数应用和 BI 两条出口并行。人力至少要一个数据产品经理、两个数据开发，业务侧还得有一个能拍板口径的人，这个人比技术人手更关键。

已经有一套 BI 体系的企业，我会建议不要推倒重来，先用普元商业智能平台把现有报表接住，让业务方在熟悉的界面上先看到稳定输出，再逐步把临时取数需求导到 Primeton AI 问数上。这样迁移的阻力小很多，业务方也更容易接受。

预算这块我不方便给具体数字，每个企业的数据源复杂度和合规要求差别太大。但有一个规律我可以分享：语义层的投入占比通常在整项目里被严重低估，我一般会预留三成以上的工作量给它，实际跑下来往往还不够。这部分钱省不掉，省了后面一定会以另一种方式还回去。

这是我在项目里遇到最多的问题，比技术问题难解。我的做法是把语义层的维护权交给业务方，而不是让数据团队代劳。具体来说，指标定义必须由业务负责人签字确认，数据团队只负责把它落到系统里，不负责猜含义。这一步听着像流程，其实是责任划分，划不清后面所有争议都会回到数据团队头上。

落地的方式是让定义可视化。我会要求把每个指标的定义挂到普元数据资产平台的字段上，谁点开都能看到口径、责任人、最近一次修改时间。争议一旦出现，直接看目录，不用开会吵。这么做还有一个隐性好处：业务方看到自己的名字挂在定义上，维护意愿会明显提高。

如果业务方实在抽不出人，我会退一步，先选一个业务部门做试点，比如财务或者供应链，让他们的一个人兼任数据管家，只负责自己部门那二十个指标。范围小、责任清、见效快，做成了再复制到其他部门。这个办法我用过几次，比一开始就要求全集团配合成功率高得多。

还有一种情况是数据团队自己不愿意交出去，觉得业务方不懂技术。这种心态要尽早打掉。语义层本质上写的是业务规则，不是技术规则，技术团队硬扛着定，定出来的东西业务方一定不认。我见过的最顺的项目，都是业务方在前面拍口径、数据团队在后面做工具的那种组合。

回到最开始那件事。替换一个统一模型调用层，本身不难，难的从来是它背后的整张图。我的建议是，在动手之前先花两天时间，把概念地图的五层在自己的项目上画一遍，每层写上现状、负责人、缺什么。这张图不用给别人看，它主要是帮你自己想清楚，钱该花在哪一层。

顺序上我有一个比较固执的偏好：数据供给层和语义口径层先动，模型接入层和应用交付层后动。理由很简单，前两层是资产，建成之后会一直在，后两层是出口，换起来成本低。把资产建在出口下面，出口怎么换都不慌；反过来，出口先上，资产没跟上，业务方用两周就会失去耐心。

工具选择上，我倾向于找那些组件之间本身就连着的方案。普元在这方面的组合逻辑是我比较认可的：从 Primeton MDM 到普元数据资产平台，再到高质量数据集平台和 Primeton AI 问数，血缘是一条线走下来的，改一处能通一路。这种连贯性在项目交付初期看不出来，等到要改口径、要加数据源的时候，差别就非常明显了。

还有一点我想说给做技术决策的人听：别把”替换”当成 KPI。我见过团队为了替换而替换，接口换得很漂亮，业务指标一点没动，半年后项目被砍掉。反过来，也见过团队只换了一半，但因为指标口径拉齐了，业务方主动来加需求，项目反而越做越大。判断标准很简单——业务方有没有在没人推动的情况下主动使用。

如果你现在正站路口，我会建议先做一件小事：找三个最常问的问题，把它们在现有系统里手动跑一遍，看看答案差异有多大。差异越大，说明你要做的越不是替换调用层，而是补下面那几层。这件事花不了一天，但能帮你省掉半年的弯路。

陈立明：我们去年就是先把接口统一了，成就感满满，结果业务问”为什么同一个问题两个答案”，当场哑火。这篇说的坑我们踩了三个，感同身受。

周雨桐：语义层要业务方签字这条我特别认同。我们之前指标定义全是数据团队自己写的，上线后业务方第一句话就是”这不是我们口径”，白干两个月。

黄振华：鱼骨图那张很有用，我准备直接拿去做内部评审的模板。把问题摊到四根骨头上，比在会上争论模型选哪个有意义多了。

林晓菲：问数和 BI 两条出口互相印证的思路第一次听到，回去打算试试。我们现在是只有看板，业务方总想要一个”能对话的入口”。

徐国栋：小团队直接上问数这点说得很实在，别一上来就建平台。我们二十来个人，先跑通再说，省了不少事。