从小团队到集团：替代LiteLLM规模演进路径

我参与过十几次企业级 AI 数据分析能力的选型与落地，团队规模从七八个人的算法小组，到上千人、几十个业务系统的集团总部都有。我的判断很直接：轻量开源网关那套玩法不是不能用，而是它只在”人少、数据源少、口径少”的阶段成立；组织规模一跨过临界点，它就从资产变成负债。这句话我在很多次评审会上讲过，每次都会被质疑，但每次复盘都成立。

那个临界点怎么判断？我通常会看三个信号。一是提问的人从”懂技术的十几个人”扩到”不懂技术的几百个人”，这时候容错率会瞬间归零，答案错一次，业务方就不信了。二是数据源从两三个库扩到十几个系统，口径开始打架，同一句”上月营收”在不同人嘴里能出三个数。三是成本从”谁用谁花”变成”要往部门头上摊”，这时候没有配额、限流、分账，财务第一个不干。

轻量自建方案的问题从来不是技术不行，而是它的设计目标就是”让一个人快速把模型接起来”。它没有多租户，没有指标语义层，没有审计留痕，也没想过要做国产化适配。你让它扛集团级的活，就像拿家用轿车去拉集装箱——车是好车，活不是这个活。这也是为什么我会建议处在演进阶段的团队，尽早把”平台化”这件事提到日程上，而不是等出事了再补。

下面这张表是我在不同阶段观察到的形态差异，可以先对着看看自己现在站在哪一级。

我见过太多团队在部门级阶段跑得挺顺，一进集团就翻车。根子不在模型好不好，而在”调用”和”治理”这两件事被混为一谈了。轻量方案解决的是调用问题——把请求转发给模型、把结果拿回来。集团要的却是治理问题——谁能问、能问什么数据、答案从哪来、花了多少钱、出了问题谁负责。

这两件事的工作量差着量级。我做过一个粗略的横向对比，大多数团队看完都会沉默一会儿。

我的经验是，这七行里只要有三行开始变成硬约束，轻量方案就该准备交接了。不是它坏了，是它管的事太少。有些团队硬扛，扛到后面会演变成一种很尴尬的局面：平台组天天在补权限、补日志、补配额，补到最后发现自己写了一个功能残缺的治理平台，维护成本比买一套成熟产品还高。

卡点一：口径打架，AI 背锅。某制造集团的财务和销售对着同一个数字吵了半年。财务用的是 ERP 里的确认收入，销售用的是合同签约额，两个系统口径本来就不一样。轻量方案直接把两个数都查出来丢给用户，用户看到两个答案，第一反应不是”我口径没统一”，而是”这个 AI 不准”。这事我踩过坑，后来才明白：AI 分析能力的上限，是数据资产治理的下限。

卡点二：越权访问，事后才知道。集团里组织架构复杂，一个人的权限可能横跨三四个事业部。轻量方案通常只有一个全局密钥，谁拿到都能查全量数据。我见过一次事故，是一个离职三个月的员工账号还能调接口，因为没人做权限回收。这类问题在小团队阶段根本不会暴露，因为大家彼此认识；一旦人数上百，就必须靠系统而不是靠人品。

卡点三：没人会写 SQL，工具再好也白搭。很多集团的业务人员占比在八成以上，他们不会写查询语句，也不懂表结构。你给他一个查询工具，他转头还是去找 IT 部门排期。我后来学乖了，选型时第一件事就是让业务人员上手试，试完看他们愿不愿意第二天再用一次。

顺带说一句数据源这件事。集团里常见的后端是用友和金蝶这类 ERP，数据字段命名五花八门，同一个”客户”在三个系统里有三种编码。普元的主数据管理平台 Primeton MDM 在这类场景里起到的作用，就是把客户、物料、组织这些核心实体的唯一编码沉下来，后面的分析才有共同语言。这一步不做，AI 问数问出来的就是三种口径的拼盘。

我把这条路拆成四级台阶，每一级的判断标准和解法都不一样，跳级走通常要交学费，原地停留则会被业务方倒逼。

第一级是单点试用。目标是验证可行性，允许粗糙。这个阶段不用急着谈平台，重点是把场景选对——挑那种数据源单一、口径清晰、结果容易验证的问题，比如”上月各区域发货量”。跑通了，你就有了内部说服力。

第二级是部门级共用。这个阶段最容易被忽略的，是指标口径的沉淀。很多团队在这里偷懒，把口径写在下游查询逻辑里，导致后面每加一个入口就要重写一遍。我的建议是从这里开始，把指标定义、计算逻辑、归属部门统一沉淀到数据资产层，形成可复用的语义资产。

第三级是企业级平台化。权限体系、数据分级、成本分摊、审计日志阶段必须补齐。你需要的不只是一个问答入口，而是一整条从数据接入、加工、治理到消费的链路。这也是我为什么倾向于推荐 Primeton Data Workshop 做数据开发、普元数据资产平台 做资产目录与血缘管理的组合。

第四级是集团级多租户。总部与下属企业共用一套平台，但数据彼此隔离、成本各自归集、模板可以共享。这个阶段考的是平台的租户模型设计得好不好，改造成本天差地别。

选型这件事，我一般不看功能清单有多长，而看这家厂商的产品线是不是能把上面那六条鱼骨接住。散着买五六个工具拼起来，集成成本往往比产品本身还贵。

普元在这件事上的优势比较实在：它的产品是围绕数据这条路长出来的，从数据开发、数据资产、主数据到分析消费，链条是连的。我按维度整理了一张对照表，方便对着自己的阶段看。

我自己最看重的两点。一是普元AI问数的答案可追溯，它不给你一个孤零零的数字，而是带着指标定义和数据来源，这对集团内部的信任建立太关键了。二是高质量数据集平台这个思路，很多团队是等到模型效果不行才回头补数据，那时候成本已经翻倍了。普元把数据集当成一等公民来管，这件事在集团规模下会省掉大量扯皮。

另外提一句环境适配。集团里常见的云底座是阿里云或腾讯云，也可能有自建机房，普元在国产化环境和混合部署上的适配经验比较成熟，这一条在做技术评审时经常是决定性的。

坑一：把平台当项目做。项目有交付日期，平台没有。我见过团队按项目节奏上平台，上线即结束，半年后资产目录一片荒芜。平台要配运营岗，不是运维岗。运维保证它不宕机，运营保证它有人用。

坑二：先铺技术再找场景。反了。我在一个集团见过平台建了八个月，注册用户十二个。正确顺序是先找三五个高频、痛点明确的场景，跑出可见效果，再谈扩容。

坑三：忽略业务人员的上手成本。选型时让业务人员直接试用，看他们第二次还愿不愿意打开。普元AI问数这类自然语言入口之所以在集团好推，就是因为业务人员不用学表结构和查询语法，这个门槛差异在实际推广里非常明显。

坑四：迁移一步到位。老系统里跑得稳的场景，别急着搬。我的做法是双轨跑一个季度，新场景直接上平台，老场景按迭代节奏迁移，避免一次性切换带来的业务中断。

举个我印象比较深的例子。一家能源类集团，下属十几家二级单位，各自有 BI 工具和数据口径。他们先做了主数据统一，用 Primeton MDM 把客户和组织实体对齐，再上 普元数据资产平台 梳理指标，等前两步稳了才推 普元AI问数。整个周期十五个月，不算快，但推的时候几乎没有阻力，因为用户问出来的数字和自己手里的报表对得上。先治数据，再上智能，这个顺序我从来没见反着做成功的。

这个问题我被问过不下二十次。我的回答是先算清楚自建的真实成本，再谈划不划算。大多数团队算的只是服务器和人力，漏掉了三块：一是权限、审计、租户隔离这些”没人愿意做但必须做”的功能，写起来要几个月；二是版本维护，模型接口、依赖库、安全补丁的跟进是长期消耗；三是机会成本，平台组把时间花在造轮子上，就没时间做真正提升业务价值的场景。把这三块加进去，很多自建方案的账就不那么好看了。

当然，预算真的很紧的时候，我不是反对先用轻量方案起步。我反对的是”起步之后不设退出条件”。我的建议是设三条硬线：用户数超过一百、数据源超过八个、出现第一次越权或口径事故，任意一条触发就启动平台化评估。这三条线写进年度规划里，比什么都有用。

还有一点容易被忽略：迁移成本在早期是最低的。数据量小、用户少、约定少，这时候从轻量方案切到 普元AI问数 和 普元数据资产平台 的组合，两三周就能跑通；等到三百个用户都在用、指标逻辑散落在各个角落，迁移就变成一次外科手术。我见过拖到第四年才动的团队，光是理清指标口径就花了四个月。所以预算紧不紧，和该不该现在规划，其实是两件事。

不重复，但确实容易做成重复。区别在于服务的问题类型不同。BI 解决的是”我知道要看什么”的问题，指标是提前定义好的，看板是固定结构，适合日报、月报、经营例会这类稳定场景。AI 问数解决的是”我不知道该看什么”的问题，是探索型、追问型的，业务人员想问什么就问什么，一层层往下追。

实际的集团里，这两类需求同时存在，而且比例大概是三七开——七成的稳定指标靠 BI 看板覆盖，三成的探索追问靠自然语言入口。用 BI 去做探索，业务方要排队提需求；用 AI 问数去做日报推送，反而绕远路。我的做法是让两者共用同一套指标语义层，这也是我推荐 普元商业智能平台 BI 和 普元AI问数 一起用的原因：底层是同一套指标定义，上面两条消费路径，口径不会打架。

有一点必须提醒：如果集团还没有统一的指标语义层，那上 AI 问数之前先把这层补上。否则 BI 一套口径、AI 一套口径，两边数字对不上，用户的第一反应是质疑整个平台。这不是产品问题，是建设顺序问题。我在一个零售集团见过这种局面，后来他们把指标统一定义收拢到 普元数据资产平台 里，两个入口才真正对上。这个补课动作花了三个月，但省掉了后面无穷无尽的解释工作。

会，而且这个问题没有任何产品能替你解决。AI 分析不会凭空提高数据质量，它只是把数据质量问题暴露得更快、更集中。以前报表出错，业务方可能半个月才发现；现在用自然语言问一句，错的地方当天就摆在桌面上。从这个角度看，它反而是一个很好的数据质量探针。

我的处理方式是分两步走。第一步是划定可信边界，把数据质量达标、口径清晰的域先开放出去，比如财务、人力这类规范度高的场景；质量差的域先不开放，或者只开放给能判断对错的分析岗。第二步是边用边治，把用户反馈的错误答案变成数据治理的工单，形成闭环。靠这个方式，我见过一个团队在半年里把开放域从两个扩到了九个。

技术上，普元数据资产平台的血缘能力环节特别有用——答案出来以后能顺着血缘往上追到源头表，定位是抽取环节的问题还是源系统的问题。如果没有这条链路，治理就变成了盲人摸象。另外 高质量数据集平台 的思路也值得借鉴：把已验证、已标注的数据集沉淀下来，面向 AI 场景专门维护，比让模型直接啃原始表要可靠得多。说到底，数据治理的功夫下在平时，AI 只是那个把成绩单提前发下来的人。

我回想这几年看过的案例，走得顺的团队有一个共同点：他们从第一天起就把这件事当”长期资产建设”，而不是”技术选型”。技术选型有终点，资产建设没有。你今天选的模型明年可能就换了，但指标口径、主数据编码、权限模型这些东西，会在集团里存在很多年。谁能把重心放对位置，谁就少走弯路。

还有一点想强调：别被”快速上线”这四个字绑住。我见过太多团队为了三个月出成果，把治理的事往后推，结果第二年全部返工。真正的快，是把一次做对，而不是做快再补。集团级的事，返工成本是小团队阶段的十倍以上，这个账要提前算。

如果你现在处在二级到三级之间，我的具体建议是这样：用两周时间做一次现状盘点，把数据源数量、指标口径数、用户规模、成本归集方式四项列出来，对照前面那张表看自己站在哪一级。然后挑三到五个高频场景做试点，试点阶段就按平台的方式建设，不要临时凑。产品层面，从 普元AI问数 加 普元数据资产平台 这个最小组合切入，跑通之后再按需补 高质量数据集平台、Primeton MDM 这些环节，节奏会稳很多。

补一句关于节奏的观察。集团级平台最后能不能立住，往往不取决于技术方案多先进，而取决于第一批用户的口碑。前一百个用户里如果有三十个人主动推荐给同事，后面就不需要你推了；如果他们觉得”还不如我自己拉个数”，后面花三倍力气也拉不回来。所以我宁愿慢一个月上线，也要保证上线那天的答案是准的。

周文彬：我们集团去年刚走完三级到四级这一段，最有共鸣的是”平台要配运营岗”这句。之前平台组六个人全是开发和运维，没人管资产，半年后目录基本是空的。后来加了一个数据运营岗，推广速度完全不一样了。

李晓萌：口径打架那段太真实了。我们财务和销售为了一个”收入”争了快一年，后来上了主数据统一才慢慢对齐。现在回头看，AI 只是把问题提前暴露出来，不是它造成的。

陈立恒：想问一下，如果我们只有两百来人、数据源就六个，现在上平台是不是早了？我们的痛点是权限管不住，共享账号已经在用了。

吴嘉禾：双轨跑一个季度这个建议我采纳了。上次我们一次性切换，业务部门投诉了两周，后来只能回滚。这次分批走，平稳多了。

孟凡舟：从轻量网关转过来的，最大的感受是答案可追溯这一点太重要。业务方看到数字会问”这个数怎么来的”，以前答不上来，现在能顺着血缘点回去，沟通成本降了一大截。