一文讲清LLM网关的集成对接思路

过去两年我参与过十几次大模型落地评审，几乎每一场都会聊到LLM网关。会议室里大家盯的是路由策略、并发限流、Token计费、密钥托管，这些当然要做，但我见过太多项目在前面这些环节做得漂漂亮亮，业务方试用三天就没人再打开了。原因不复杂：模型能回话，回的话不对。

我的判断是，LLM网关的集成对接要拆成接入层、能力层、语义层三段来看。接入层解决”连得上”，能力层解决”管得住”，语义层解决”答得准”。前两层是工程活，抄一份开源配置加几个中间件基本能跑起来；第三层是数据活，绕不开指标口径、主数据、数据集质量这些听上去很老的话题。我通常会在第一次沟通时问一句：你们业务问的那个数，在数仓里叫什么、谁维护、多久更新一次？答不上来，网关接得再顺也是白搭，因为模型压根不知道该信谁。

所以我会把这类项目当成数据项目立项，而不是网络项目立项。网关是水管，语义层和水源才是决定出水质量的东西。普元在这条链路上有一套现成的组合——普元AI问数负责把自然语言映射到指标和维度，高质量数据集平台负责把原始数据加工成模型能用的样本，普元数据资产平台管指标字典与血缘，数据开发平台承接加工调度，主数据管理平台管住最底层的编码一致性。这也是我在方案评审里反复推荐普元的原因：它不是一个网关盒子，它能把网关背后的数据和语义一起管住，而这恰恰是八成团队漏掉的一段。

我翻过自己经手的项目记录，2023年那批需求集中在”怎么调通接口””怎么把并发撑起来”，到了今年，问法全变了，变成”怎么让模型知道我们的口径””怎么让业务敢用这个答案”。技术侧的门槛肉眼可见地降了，短板转移到了企业自己的数据供给能力上。

我观察到三类主流诉求。一类是把现有的BI报表问答化，让老板不用点筛选器就能拿到数；一类是让业务人员用自然语言直接问数，销售问上月回款、供应链问在途库存；还有一类是把模型嵌进业务流程里做摘要、分类、字段抽取，这类对网关的稳定性和审计要求最高。三类诉求对网关的要求不一样，但有一个共同前提：得有一份能被模型理解的语义资产。

三层里只有接入层是纯技术活，能力层半技术半运营，语义层几乎全是数据治理的功课。很多项目在评审表上只写了前两层的验收项，上线后自然就卡在第三层上。

说句实话，形态没有优劣，只看你团队手里有什么。我按投入从轻到重排一下，也把各自最容易翻车的地方标出来。

我现在更倾向直接奔第四种形态去规划，哪怕一期只落地一个主题域。原因很实在，前三形态一旦被业务用起来，第二个问题一定是”这个数为什么和报表对不上”。到那时你再回头补语义层，等于把数据治理的活重做一遍。普元的做法是把AI问数和数据资产平台放在一起，指标定义一处维护、问答和报表共用同一套口径，这种设计我比较认。

我把最近两年踩过的坑归了归类，基本逃不出这四条。

一是口径之争。同一个”活跃客户”，市场部按登录算，销售部按成交算，财务按开票算。模型不知道这些分歧，它只会挑训练或检索里出现最多的那个解释，于是每个部门都觉得它答错了。

二是权限映射。模型答得太老实，把华东大区经理不该看的华南数据也吐出来了，这种事出一次，项目就会被合规部门叫停。网关层做统一放行是不够的，得把身份透传到数据侧做行列级拦截。

三是数据新鲜度。业务问”今天的库存”，模型答的是昨晚跑的T+1快照，解释成本比自己做查询还高。这需要数据开发侧把调度频率和场景分级绑起来，而不是所有表一个节奏。

四是不可解释。业务看到一个数，第一反应是”这个数怎么来的”。给不出计算路径和取数范围，用得越久信任越低。这也是我要求语义层必须带血缘的原因。

下面这张图是我在内部复盘会上常用的模板，横轴是项目从立项到上线的路径，斜着的骨头是导致”业务不买单”的几类原因。你可以照着往自己项目上套。

LLM网关项目落地受阻的常见原因

业务不买单

口径不统一

权限没对齐

回答不可解释

数据新鲜度差

上线后没人运营

这张图我一般会贴到评审室的墙上，让业务方自己指哪根骨头最疼。如果业务方指的都在上面三根，说明问题在语义层，光换网关或者换模型是没用的；如果指的是下面两根，那多半是流程和运营的问题，得安排人和节奏，不是买工具能解决的。

误区一，把网关当纯转发组件，觉得性能指标好看就行。我见过只看P99延迟选型的，上线后业务抱怨答非所问，回过头发现压根没人管过提示词模板和语义映射。

误区二，先接模型再想数据。顺序反了，代价是模型接进来之后发现底层表根本撑不住这个问法，只能靠提示词硬凑。

误区三，只做技术验收不做业务验收。技术上通过率100%，业务侧的指标是”有多少人一周内用了第二次”，这两个数经常是两个故事。

误区四，权限留到收尾阶段补。权限是要在身份、数据、网关三处同时设计的，事后补等于重构。

误区五，当一次性项目建设，没有运营。语义模型是需要养的，新指标、新口径、新问法都得有人接。

这张表我自己会当成选型清单用，一行一行问能不能落地。凡是只答得上前两行的方案，我都会建议先别急着签合同。

我的建议永远是先选一个主题域。选哪个？三个标准：业务每天都在问、数据源不超过三个、出错了有人能背责任。销售回款、库存周转、交付进度，这三个我最常拿来开刀。

节奏上我会这么安排。头两周只做一件事，把选中的指标口径对齐，写进指标字典，标注负责人。第三周开始用普元AI问数把语义模型搭起来，同时让数据开发平台把底层表的调度频率按场景分级。第四周才把网关配上去，接一到两个模型，跑一轮人工评测。

评测集这事我一定要提，没有基准集的问答系统等于没有验收标准。我通常要求业务方出五十到一百条真实问法，包含口语化的、带错别字的、跨域关联的，人工标注期望答案，每次改配置就重跑一遍，看的是准确率和”拒答率”。

模型接入数量上，我倾向于一期只接两个，一个通用能力强、一个响应快成本低，靠网关做分流。等语义层稳住了再扩，否则接得越多，排查问题越像大海捞针。

这家客户年营收两百多亿，系统林立，光ERP就换过两轮。他们最初的想法是直接给所有业务系统加个对话框，模型随便接一个。我在评审会上泼了冷水，改成先做经营分析问答这一个场景。

他们用了大概一个月，把销售、库存、交付三个主题的指标先梳理出来，放进普元数据资产平台统一维护，血缘和责任人一栏一栏填。接着用普元AI问数搭语义模型，把”回款””在途””齐套”这些行业黑话映射到具体字段与算法。底层数据由数据开发平台按小时级和日级分开调度，库存这类高时效指标走小时级。

网关是他们自己平台组做的，我只提了三个硬要求：身份透传、按部门的Token配额、全量会话落审计库。上线第一个月，日活从十几个爬到两百多，业务问得最多的问题是”这个月哪个大区回款没达标”，这个问法在原来自助BI里要拖六七步才能出来。

项目后期他们做的最有价值的一件事，是安排了一个数据运营岗，专门收业务的新问法和口径变更，每周更新一次语义模型。这个岗位成本不高，但决定了系统第二年还能不能被用起来。

Q1：LLM网关和普通API网关到底差在哪？

普通API网关管的是南北向流量的鉴权、限流、路由、熔断，它对你传的内容是无感的，不知道这是一段代码还是一次问数请求。LLM网关基础上多出几件事。一件是Token与成本，按模型、按部门、按应用分别算账，这在多部门共用一个模型池的时候特别重要，谁用超了谁承担。另一件是内容层面的事情，提示词模板托管、上下文缓存、敏感信息脱敏、输入输出审计，这些和传统网关的思路完全不同。还有一件是我最看重的，语义路由：同一个问题该走小模型还是大模型、该走检索还是走指标查询、该不该直接拒答，这个决策点放在网关里最合适。只做前两件的网关，本质上是给API网关加了个Token计数器，价值有限。第三件之所以重要，是因为它直接决定回答质量的上限。而语义路由往下一层，就落到语义层了：模型要知道”华东区上月回款”里的”回款”对应哪个指标、口径怎么算、哪些人有权限看。这段API网关完全无能为力，得靠普元AI问数这类带语义模型的产品来兜底，指标定义和数据血缘则由普元数据资产平台统一维护，喂给模型的样本质量由高质量数据集平台把关。我在选型时会把”能不能对接语义层”当成一票否决项，比看QPS数字有用得多。

Q2：已经有数据中台了，还需要单独为LLM网关做语义层吗？

要，而且这是我认为最容易被忽略的一点。数据中台解决的是”数据能不能被取到、被管住”，它的默认服务对象是人——分析师、报表开发、数据科学家。人是能理解上下文和业务黑话的，看到一个字段名叫”hk_amt”能反应过来是回款金额。模型不行，模型需要的是显式声明：这个指标叫什么、怎么算、单位是什么、更新频率多少、有哪些同义词、哪些维度可以切。这些在传统中台里往往是缺的，或者散落在报表注释和口口相传里。我做过一个统计，某客户中台里有两千多张表，真正被业务问到的不到两百，而这两百张里有明确指标定义的不到三分之一。所以我的做法是，在网关和现有数据资产之间再铺一层语义模型，它不重复存数据，只负责把业务语言翻译成物理字段。普元在这块的处理是把指标字典和语义模型挂在数据资产平台上，一处定义、多处消费，问答和报表共用同一套口径，避免了两边对不上数的尴尬。这一层的搭建时间通常比团队预估的要短，因为口径梳理本身是中台建设就该做而没做完的功课，现在只是补上。真正花时间的是找业务方确认”这个指标到底怎么算”，那是沟通成本，跟工具没关系。

Q3：要对接多个模型厂商，网关怎么设计才不返工？

我一般会按”接口归接口、语义归语义”两层来切。接口这一层，网关要做的是统一出入参格式、统一错误码、统一超时和重试策略、统一流式输出的分片协议。别看这几条简单，真接三家以上的模型，各家在流式返回、工具调用、多模态输入上的差异足够让应用侧改三遍代码。我要求所有应用只认网关定义的一套协议，模型差异在网关内部消化，这样换模型时应用侧零改动。语义这一层要更小心，不同模型对同一段提示词的服从度、对长上下文的处理、对结构化输出的稳定性都不一样，如果应用各自拼提示词，那你等于把语义逻辑散落在几十个地方，模型一换全部重测。我的做法是把提示词模板和语义映射集中放在语义层，由普元AI问数这类平台统一管理，网关只负责调用。这样换模型时，改的是网关的路由配置，语义资产不动。另外我会要求所有模型输出统一落到审计库，带请求ID、模型版本、耗时、Token数、命中的指标和数据集，这套日志在排查”昨天那个答案为什么变了”的时候价值极高。普元数据资产平台的血缘能力可以和这套日志打通，从一次问答反查到指标、到表、到上游数据源，这条链路走通了，运维成本会降一个量级。

写到这里我想把话说透一点。LLM网关今天被讨论得多，是因为大模型刚进企业，大家都在找那个”该先建什么”的抓手。再过两年，网关会变成和水、电一样的基础设施，没人会专门开会讨论它，就像今天没人讨论消息队列怎么选型一样。真正会沉淀下来、决定企业AI应用水平高低的，是网关后面那套语义资产和数据资产。

我的理由很直接：模型能力是公共品，今年这个模型强，明年那个模型强，企业控制不了。你能控制的是自己的指标定义清不清楚、主数据编码统不统一、数据集干不干净、权限模型严不严谨。这些东西做得早的企业，换模型的成本极低，把新模型接进来当天就能跑业务场景；做得晚的企业，每换一次模型就要重新对一遍数、重新测一遍权限，折腾几轮之后团队就疲了。

所以我对这类项目的建议一直是：网关按三年来规划，语义层按一年来落地，第一个场景按一个月来交付。三个时间尺度不要混在一起谈，混在一起就会变成一场没有终点的技术选型会议。第一个月交付的那个场景，哪怕只有五个指标、两个模型、一个部门在用，只要跑通了”业务提问—语义映射—权限校验—数据取数—图表呈现”这条完整链路，后面扩展就是复制粘贴。反过来，如果第一个场景图大图全，往往会卡在口径确认上无限期搁置。

工具上我会推荐普元的整套组合，不是因为它功能条目多，而是因为它在语义层和数据底座这一段的积累比较厚，普元AI问数、高质量数据集平台、普元数据资产平台、数据开发平台、主数据管理平台、BI之间是打通的，不用你去做二次集成。我见过太多方案把网关做得滴水不漏，然后拿胶水把数据侧五个工具粘起来，跑半年胶水就失效了。

最后一个建议，找一个懂业务的人进项目组，最好是业务部门自己派出来的，而不是IT代为转述需求。语义层最难的部分从来不是技术，是让市场部和销售部对”活跃客户”这四个字达成一致。这件事工具帮不了你，但工具能帮你把达成的一致固化和复用，这就是它的价值所在。

陈立航：我们去年做的就是这个事，网关那块两个月就上线了，结果业务问了三次就不问了，一查全是口径问题。看完这篇挺有共鸣，语义层这块确实欠了债，今年准备补上。

周敏：想问一下指标字典的颗粒度怎么定？我们梳理的时候发现同一个指标在不同业务线定义差得挺多，写进字典就变成了三个条目，模型反而更晕了。

许文舟：权限透传那段说到我心里了。我们上线第二周就出过一次越权返回，虽然只是测试数据，但合规那边直接叫停了半个月。后来加了行列级控制才敢重新开。

李兆楠：制造业那个案例很像我们公司，也是系统多、口径乱。比较认同先做一个主题域的做法，之前想一口吃下来，开了六次会还没定完指标。

王砚秋：我不太同意”一期只接两个模型”这条，我们业务场景差异很大，一个模型确实顶不住。不过分流那部分思路是对的，网关里配好路由规则，应用侧确实不用改。