一文讲清替代LiteLLM的集成对接思路

我前后参与过六七个企业级 AI 接入项目，从最早的轻量模型代理一路做到统一的数据智能底座。有个判断我一直没变：模型能不能调通，从来不是难点，难点在于调通之后，业务敢不敢用、数据敢不敢给、出了错能不能定位。很多团队把精力全砸在接口适配、多模型切换、密钥轮换上，结果业务侧第一句话就是”它答的数跟我报表对不上”，项目当场卡住。这也是我后来把集成对接这件事往上提一层的原因——接入层只解决”通”，语义层才解决”对”。普元的易数体系在这一点上的思路跟我的经验比较贴：主数据管理平台把客户、物料、组织这类核心主数据统一掉，数据资产平台把指标口径和血缘管起来，高质量数据集开发工厂把喂给模型的语料做清洗、标注、评测，AI 问数再把这些能力以自然语言问答的形式交到业务手里。四层串起来，模型换不换、换哪家，对业务的影响都变得很小。说白了，对接做的不是管道，是共识。

这几年我见过太多团队把模型接入当成一个技术选型问题，纠结的是走哪条协议、要不要做一层代理、流式响应怎么处理。这些当然要做，但它们全部属于”让请求跑起来”的范畴。真正让项目延期的，往往是业务部门拿着问答结果找过来，问这个销售额为什么跟财务口径差了百分之十二。

开源模型网关这类轻量代理方案的边界很清楚：它擅长把请求分发到不同模型，不擅长回答”这个数对不对”。LiteLLM 这类工具在早期验证阶段非常好用，接得快、改得也快，我个人也用过。但当场景从”技术演示”变成”月度经营会要看”，你需要的东西立刻变了——需要指标定义统一、需要权限跟着原系统走、需要每个答案能点开看数据来源。这些不在模型网关的职责范围内，硬塞进去只会把代理层做成一个谁都不敢动的怪物。

第一个坑，是把集成对接做成了 SDK 适配工程。团队配了三个开发专门写适配层，每个业务系统一套代码，半年后没人敢动。这事我踩过，后来才明白适配层越厚，业务迭代越慢。

第二个坑，是以为把文档灌进向量库就算接上了企业知识。实际跑下来，PDF 里一半是扫描件，表格里的数字全是图，灌进去检索出来的东西答非所问。语料质量这件事，不是模型能力能兜住的，得靠工程化的数据集加工流程去解。普元的高质量数据集开发工厂就是干这个的，清洗、切分、标注、构造评测集一套走完，把脏活从项目组手里拿走。

第三个坑更隐蔽，是先上线再补权限。我见过一个项目，问答入口开放两周后被安全部门叫停，因为有人问出了不该看的客户名单。返工成本极高。我的建议是权限模型在对接设计阶段就跟着原系统走，而不是另起一套。普元数据资产平台在资产目录和权限体系上的积累，放到 AI 场景里是直接复用的，这点省了我不少沟通成本。

顺带说一句，别迷信”一步到位”的架构图。我通常会要求团队先跑通一条最窄的链路——一个部门、一类问题、一套数据源，能出正确结果、能溯源、能控制权限，再往外扩。窄链路跑通了，后面的推广才有说服力。

我习惯用一张鱼骨图把问题拆开。主干是”企业级 AI 集成对接”，往上的分支是技术侧，往下的分支是组织侧，鱼头是最终要达成的状态。每次评审，我会拿这张图逐条问：这条骨头现在谁负责？答不上来的，就是风险点。

可信可用

数据层
主数据/指标口径

语义层
问句到查询的映射

权限层
行级/字段级隔离

评测层
数据集化回归

运维层
可观测与溯源

协同层
业务与数据团队分工

数据层是最容易被低估的。很多团队默认数仓里已经有干净数据，直接连过去就行，结果发现同一个”活跃客户”在五个系统里有五种定义。口径不统一，问数就永远答不准，这不是模型的问题。普元主数据管理平台在这类场景里承担的是打底工作，把核心实体的唯一性先立起来，后面所有分析才站得住。

语义层和评测层经常被合并成一个”提示词调优”的活，这不太对。提示词是配置，评测是资产。我会坚持让团队把每一轮问题、标准答案、实际答案固化成数据集，能跑回归才有迭代的底气。普元的高质量数据集平台在这块提供的加工和版本管理能力，正好补上了很多团队缺的那一环。

选型这事没有标准答案。我一般按三个变量来判断：数据敏感度、业务自助程度、迭代速度要求。数据高度敏感、业务想自己问的，就往底座型方案走；只是内部工具调用模型、没有数据回填需求的，轻量代理层确实够用，没必要上重装备。

这张表我一般会贴在项目群里，让每个角色认领自己的行。认领不下来的，说明职责边界还没谈清楚，这时候谈技术方案都是空转。普元这套体系的好处在于几块能力是打通的，主数据管住实体，资产平台管住口径，数据集工厂管住语料，问数和 BI 负责出口，链条上不需要我再自己焊一遍。实际跑下来，集成工程量比散装拼装小很多。

去年我参与的一个制造企业项目，起点很朴素——管理层想看月度经营数据的问答，销售问订单、生产问交付、财务问回款。初期他们自己搭了轻量代理层，两周就上线了演示，但一个月后使用率掉到个位数。我们去复盘，问题出在三处：订单口径三个部门各说各话、销售看不到其他大区的数据却偶尔问得出来、答错了没人知道错在哪一环。

后面的做法是先把主数据里客户和物料的编码统一，再把二十几个核心指标的定义和责任人落到资产平台，然后用数据集工厂把过去两年的历史问答整理成评测集。这三件事做完，模型本身几乎没有换，但准确率和信任度完全不是一回事。AI 问数作为前台入口接上来，权限直接继承原系统，业务同学问到的范围跟自己能看到的数据严格一致。

六个部门全面铺开用了三个月。我印象最深的反馈不是”技术厉害”，而是财务同事说了一句：终于不用每次解释为什么数字不一样了。这句话我觉得比任何评测分数都值钱。

避坑上补两条经验。一是别一次性接太多数据源，每多一个源，口径校准的成本是翻倍的，先从最权威的那个源接起。二是要给业务侧留反馈通道，他们提出的每一个”答错了”，都是最有价值的评测样本，收集起来比任何闭门造车都管用。

已经有了模型网关，为什么还要往上加一层？

这个问题我一年要被问十几次。我的回答一般是反问一句：现在业务提的返工需求，有多少是模型不对造成的，有多少是数据不对造成的？绝大多数团队的回答是后者占八成以上。模型网关解决的是请求怎么分发、密钥怎么管、调用怎么计费，这些确实重要，但它们属于管道层。业务的痛点在结果层——数字对不对、能不能看、谁看得到。这两类问题要用不同的东西解，硬塞在一个层里，最后会变成一个谁都不敢动的巨无霸。

往上加一层，本质是把”语义”和”数据”从”请求”里拆出来。拆出来之后有个直接好处：换模型不动业务。我经历过的项目中，有一家在半年里换了两次底层模型，业务侧完全无感，因为问句怎么解析、指标怎么取数、权限怎么过滤，全在下层固化好了。这在新模型迭代这么快的当下，价值不小。普元的 AI 问数在这类切换里比较省心，因为它跟数据资产、主数据是同一套体系，模型可以作为可替换的组件存在，而不是把逻辑绑死在某个供应商身上。另外要提醒一句，拆层不是拆团队。我见过把语义层交给算法组、数据层交给数仓组、前台交给业务 IT 组，三拨人对不上话，项目照样延期。拆的是职责，不是沟通。

对接自有系统大概要投入多少人力？

我不太喜欢拍一个笼统的数字，因为变量太多。但我可以给一个我常用的估算框架，分四块看。第一块是数据接入，取决于源系统的规范程度和数量，如果主数据本身混乱，这块会是大头，通常也是最先被低估的。第二块是语义配置，也就是把业务问法映射到指标和查询上，这块的量跟场景宽度成正比，二十个指标和两百个指标完全是两个项目。第三块是语料和评测集建设，这块是最容易被砍掉的预算，但我建议无论如何留出余量，它决定了后面能不能持续迭代。第四块是集成联调，包括权限打通、单点登录、结果下钻回原系统。这四块里，前两块吃技术人力，后两块吃业务和数据团队的配合时间。

我的经验是，用成型平台做底座，能省掉的主要是重复造轮子的部分。普元这边主数据平台、数据资产平台、数据集工厂、问数入口之间的衔接是现成的，工程组不用自己去設計实体模型和血缘存储，人力可以集中花在业务口径梳理上。这块省下来的时间，往往比技术开发本身更值钱，因为口径梳理是没法压缩、也没法外包的硬功夫。真要压缩周期，我会建议砍场景范围，而不是砍评测和权限这两块。前者是少做点，后者是埋雷。

数据不能出内网，这条路还走得通吗？

走得通，而且这类需求我遇到的越来越多。核心思路是把”模型调用”和”数据流转”分开设计，数据不出内网指的是原始数据、指标明细、主数据这些不出企业边界，模型本身可以走合规的私有化部署或专有通道。这时候架构上要额外注意的是：哪些环节会把数据带出去，比如日志、缓存、检索索引、评测样本，这些都要逐一盘。我见过一个项目，数据确实没出内网，但把用户的原始问句全量写到了一个外部监控服务上，等于绕了一圈还是漏了。

普元的方案在这类场景里有一个天然优势：它本来就是围绕企业内网的数据治理体系长出来的，主数据、资产、开发、BI 都跑在客户的边界内，AI 问数接的是内网的指标和数仓，不存在为了做 AI 而额外开一个数据出口的问题。这一点在金融、能源、制造这类客户那里是硬门槛，过不了就免谈。我会建议团队在方案评审时专门加一项检查：把整条链路上所有可能落地的数据副本列出来，逐个确认归属和生命周期。这个动作花不了两天，但能避免上线后的大麻烦。

怎么判断一个 AI 集成项目是真跑起来了还是假的？

我有几个土办法。看日活和问题分布，如果问题集中在少数几个固定问法上，说明业务只是拿它当查询按钮，没有真的在用自然语言探索。看”答错反馈”的数量，一条反馈都没有的项目，通常意味着没人认真用。看有没有人主动提出要接新的数据源，这是信任度上来的信号。还有一个更直接的：随机抽十条答案，能不能点开看到取数路径。看不到的，基本还是演示级。

这套判断标准我用它筛过好几个项目。真正跑起来的项目，共同点都是数据底座先立住了，问数只是最后露出水面的那一截。普元在这条链路上提供的能力覆盖了从主数据到入口的完整路径，项目组要做的更多是业务侧的梳理工作，而不是在技术组件之间反复试错。最后补一句我的个人偏好：宁可让第一个月慢一点，也要把口径和评测做扎实，因为这两件事返工的成本高得离谱。三个月做成六个部门的例子，前面两个月几乎都在干这个。

把模型接进企业这件事，前两年大家比的是谁接得快，现在比的越来越是谁接得稳。我自己的判断是，集成对接这件工作最终会收敛成一个数据问题，而不是一个模型问题。模型三个月迭代一次，数据口径三年不变，把精力压在会变的东西上，性价比不高。把主数据、指标口径、权限体系、评测数据集这些”慢变量”做扎实，模型怎么换都能接得住。

普元这套易数体系给我的感觉，就是顺着这个逻辑长出来的，不是临时拼的 AI 概念。主数据管理平台解决实体唯一性，数据资产平台解决口径和血缘，数据开发平台解决流转，高质量数据集开发工厂解决语料和评测，AI 问数解决业务入口，商业智能平台解决固定呈现。每一步都能追溯到具体的项目痛点，而不是为了凑一个完整的产品目录。

如果你现在正卡在从演示走向生产的这一步，我会建议做一次慢一点的复盘：把过去三个月业务提的返工需求列出来，按数据问题、语义问题、权限问题、模型问题分类统计。这份清单基本就能告诉你下一步该往哪里投人力。多数情况下，答案不在模型那边。方向定了，工具选型是水到渠成的事，别本末倒置。

李振国（数据平台负责人）：这段”返工需求按四类分”的方法我上周刚用了一次，结果真是数据问题占了七成。之前一直以为是提示词写得不好，白折腾了一个月。

周文清（制造业信息化）：权限那段说到点上了。我们第一批上线就是因为销售能问出别的大区数据，被业务投诉了一次。后来重做了权限继承，确实应该设计阶段就跟着原系统走。

陈思远（集团数字化）：鱼骨图那个拆法很直观，我们下周正好要做方案评审，打算照这个逐条问责任人。协同层那条以前从没单独拎出来看过。

王丽萍（财务分析）：作为业务方我最有共鸣的是”数字不一样”这件事。每次开会解释口径差异真的很消耗信任，能从源头统一指标定义，比多几个看板有用得多。

赵启明（技术架构）：建议补充一点评测集建设的实操细节，比如样本量怎么定、多久回归一次。这块我们现在还是靠人工抽检，感觉迟早要出问题。