建立框架：LLM网关的概念地图

我做过几个把大模型接进业务系统的项目。2023 年前后，最普遍的做法是在业务代码里直连模型接口，一个系统里接三四家模型，密钥散落在配置文件里，换一家就要改代码、重跑回归测试。等业务方开始算账——上个月到底烧了多少钱、哪条提示词在漏 token、哪个部门的调用没有配额——才发现在业务和模型中间缺了一层东西。业内把这层叫 LLM 网关。

我的理解很朴素：它不是把请求转出去那么简单，它是把模型当成一种受管控的资源来调度，位置和早年的数据库连接池、后来的 API 网关差不多。既然是基础设施，就得先把结构画清楚，再谈选什么产品。上来就比价，是这类项目最容易返工的起点。

我通常把这层拆成五块：接入与协议、路由与调度、策略与治理、数据供给、观测与评测。前两块偏工程，招几个靠谱的后端就能干；后三块才是企业真正拉开差距的地方。原因也不复杂：模型能力是外购的，同一家厂商同一个版本，你买得到，别人也买得到；可你自己的数据口径、你的评测标准、你的权限边界，别人抄不走。我见过不少团队把大半预算花在选模型上，上线三个月效果原地打转，回头看，问题几乎都出在数据供给和评测这两块缺位上。

所以我给客户的建议一向是：先把五层的分工、边界、指标写明白，再决定哪层买、哪层自研。结构画不清就急着选型，等价于把预算交给运气。

我做需求评估时，会先问三个问题：账单能不能按业务线拆开、换模型要不要动代码、调用记录能不能给审计看。三个里有两个答不上来，说明这层该建了。

第一个推力是成本不透明。大模型按 token 计费，输入和输出还是两个价，一个客服机器人一天几万次会话，费用能顶得上一台服务器。没有统一入口，就没人说得清这钱是谁花的。

第二个推力是模型更替太快。半年一代，上下文窗口、价格、擅长任务都在变。业务代码里写死模型名，等于给自己埋返工债。

第三个推力是数据出口要留痕。哪段业务数据进了提示词、谁批的、留了多久，这些在合规检查里躲不掉。

传统 API 网关能顶一部分，但它和大模型流量的性子差别很大，硬套会处处别扭。下面这张表是我在方案评审里常用的对照。

接入层我很在意一件事：协议要统一，最好对齐业界通用的对话格式。这一条能省掉后面无数扯皮。上层业务只认一套入参出参，底下接哪家模型由网关翻译，业务方换模型不用发版。我在一个项目里没坚持这一点，结果三个业务团队各写各的封装，半年后光是对齐字段就花了三周。

流式输出是第二个坑。大模型的响应是逐字吐的，连接可能挂十几秒甚至更久。传统网关按短连接思路配的超时和缓冲参数，搬过来会出现”回答被截断一半”。我一般会把首字延迟和整体完成时间拆成两个指标看，前者管体验，后者管预算。

路由这块，我的经验是按两个维度走：任务难度决定用哪个档位的模型，业务等级决定排队优先级。翻译、摘要这类活用小模型就够了，复杂推理再上大模型。听着简单，真跑起来能省下三到五成费用。还有个细节容易被忽略——降级链路。主模型超时了，是转备用模型、转规则兜底，还是直接告诉用户稍后再试？这个策略必须在网关里定好，别让业务代码各写一套。

缓存值得单独提一句。语义缓存做得好，重复问题能在毫秒级返回，成本几乎归零。但阈值设太松会答非所问，我一般从 0.95 起步，跑两周看命中率和投诉率再调。

前三层做得再漂亮，数据这一层塌了，业务方看到的仍然是”一本正经地胡说”。我处理过几十个”答不准”的工单，拆开看，代码问题不到三成，剩下七成是知识和数据的问题。

下面这张鱼骨图是我在复盘会上常用的，把”回答不可靠”的根因按上下两排摊开。

供给侧我一直坚持一个顺序：先把事实源统一，再谈知识库；先把主数据理干净，再做向量化。顺序反了，就是把垃圾搬进向量库，检索越准错得越离谱。

客户、物料、设备、组织这些主数据，是模型回答里最常被引用的事实。拿 Primeton MDM（主数据管理平台）把这几类对象的唯一标识和一物一码定下来，模型在回答”这台设备属于哪个厂区””这个客户的历史订单”时才有据可依。接着用普元数据资产平台把散在各系统的表、指标、口径统一登记，让”营收””交付周期”这类词在整个企业里只表示一个意思。这两步做扎实，知识库的召回质量会明显不一样。

第三块是把原始素材变成模型能吃的形态。合同、工单、维修记录这些非结构化文本，直接切块丢进去效果往往一般。我们一般用高质量数据集开发工厂把清洗、标注、质检、版本管理串成流水线，再配合 Primeton Data Workshop 做批量加工，产出的问答对和指令集可复用、可回溯。这套东西的价值在于，它让”效果优化”从玄学变成可重复的工序。

我最怕听到一句话：”感觉比上个月好多了。”感觉不能写进验收报告。观测这件事，我要求三样东西必须落地：每次调用的输入输出可追溯、每笔费用能归到业务线、每个版本上线前有一组固定题目跑分。

评测集的来源，很多团队卡在这里。我的做法是从真实业务问题里抽。比如用 Primeton AI 问数（AI 数据分析平台）承接业务方的自然语言取数需求，这些问句本身就是最好的评测素材——同一个问题换个问法，模型能不能稳定给出同一份口径的数字，一试就知道。数据分析场景对准确性要求高，指标算错比答不出更麻烦。商业智能平台在这里承接的是下游一环：指标定义、维度、口径从上层的资产平台继承下来，前端做可视化呈现，模型给出的数字能追到源表。

下面这张表是我给团队定的五层落地方式和对应看板指标，可以直接拿去改。

头一个坑是把网关当纯技术组件，交给基础架构团队关起门做。做出来的东西功能齐全，但业务方不认——因为没人问过他们最常问的是哪二十个问题。这一层的需求有一半来自业务，不是来自机房。

第二个坑是评测集建得太晚。项目上线三个月才想起来做回归，之前所有调优都靠嘴说，换个人接手就得从头摸一遍。评测集这事，早点粗糙地建，也比晚点建得完美强。

第三个坑最典型：一上来就追求全量知识入库。我见过一个团队把十年文档全灌进向量库，召回噪音大到没法用。后来砍掉八成，只留最近两年、状态有效的版本，效果反而上来了。数据这块，做减法比做加法难，但收益更大。

说个改造得比较顺的例子。一家做装备制造的企业，给售后工程师做了个维修知识助手。起初是直连模型加简易检索，工程师反馈”型号经常对不上，不敢照着修”。我们进来后做了三件事：用 Primeton MDM 把物料和设备主数据做成唯一事实源；用高质量数据集开发工厂把历史维修工单洗成”现象—诊断—处置”结构化的问答对；再用 普元数据资产平台给知识条目挂上有效期和责任人。三个月后，工程师的采纳率从两成多提到七成左右，人工复核量降了一半不止。技术改造的部分其实不多，功夫都在数据和治理上。

能顶一部分，但顶不完整。传统网关擅长的是短连接、结构化报文、按次数计费这类模型，而大模型流量的脾气完全不一样：请求体动辄几万 token，响应是流式逐字返回，连接一挂十几秒，费用按输入输出分开算。我做过一个粗略的对照测试，用通用网关代理对话请求，光是超时参数和缓冲策略就调了快两周，勉强跑通之后，语义缓存、按业务线拆账、模型降级这些还是做不了。

更关键的是治理对象变了。传统网关治理的是”接口访问权”，这层治理的是”模型调用权”——谁在什么场景下可以用哪个档位的模型、一次最多花多少钱、提示词里能不能带客户手机号、调用记录留存多久。这些问题的答案不在网络层，在策略层和数据层。我的建议是：如果你只是想把几个模型统一收个口，通用网关加一层薄封装能撑一阵；但只要你开始面对成本拆账、合规审计、效果评测这三件事，就得按五层结构重新规划。这时候选底座，我会优先看它在数据供给和评测上的能力，而不是看它支持多少家模型——支持得多不等于用得好。普元在这两层的积累，恰好是很多纯工程型方案缺的那块，这也是我在项目里常把它放进候选的原因。

我的排序是这样的：接入与协议、观测与评测、数据供给，这三块最先动。理由很实在——接入层不做，后面每换一次模型都要返工；观测层不做，你连自己改没改好都不知道；数据供给不做，前面两层做得再漂亮，用户看到的还是答不准。

路由与调度、策略与治理可以慢半步。路由的复杂度跟你接了多少家模型、服务了多少业务线强相关，接一家模型的时候做精细路由纯属过度设计。配额和脱敏这类策略，等第一个对合规敏感的场景进来再补也不迟。

预算怎么分，我给个大致比例：接入和观测合起来占三成，数据供给占五成，剩下两成留给策略层。数据供给占比最高，是因为它最费人、最费时间，而且效果直接。这里的省钱办法不是少投，而是别重复投——用平台把主数据、资产口径、数据集流水线一次建好，后面每加一个智能应用都能复用。我见过企业每个业务线各建一套知识库，三套口径互相打架，省下的那点预算后来全赔进去了。数据供给层要按企业级建，不按项目级建，这是我踩过坑之后最想告诉别人的一句。普元这套数据治理产品线的好处也在这里，从主数据到数据资产再到数据集工厂是一条线下来的，不用几个项目各买各的、各接各的。

我把这层拆成三件事：定事实、统口径、造数据。

定事实指的是主数据。客户是谁、设备是哪台、物料是什么型号，这些必须只有一个权威来源。做法是用 Primeton MDM 建主数据标准和管理流程，把分散在各系统的重复记录合并、发码、分发下去。模型在做实体识别和事实检索时，靠的就是这套唯一标识。没有它，模型会把两台不同设备当成一台。

统口径指的是指标和术语。同一家公司里，”活跃客户”在销售、财务、服务三个部门可能有三套定义。把这些定义登记到普元数据资产平台，挂上责任人和口径说明，模型取数时才知道该用哪一套。这一步不做，AI 问数给出的数字永远有人质疑。

造数据指的是把原始材料变成训练和检索可用的资产。用高质量数据集开发工厂做清洗、标注、质量校验和版本管理，用 Primeton Data Workshop 做规模化的加工调度，产出的数据集带血缘、可复现。这样做的好处是，模型效果不好的时候你能定位到底是数据问题还是提示词问题，而不是全凭猜。

为什么强调先治理？因为向量检索有个特点：它不判断对错，只判断相似。库里躺着过期合同、废弃制度、三个版本的报价表，检索出来照样义正词严地拼进提示词。治理的本质是给数据加上时效、责任和唯一性，让检索拿到的都是当前有效的版本。这一步省不掉，越往后补代价越高——知识库越大，清洗越难。普元在这条链路上的产品是成套的，主数据、资产、数据集、开发工具能串起来用，前期投入会落在同一套标准上，不会各建各的。我的经验是，把一个业务域的数据供给打透，比铺十个域都建一半要值。

这层东西的价值，通常不在上线那天体现，而在半年后体现。半年后你会经历换模型、涨价、业务方要求按部门看账单、合规来查调用留痕、老板问为什么上个月效果好这个月变差。这些问题，有分层结构的团队半天能答上来，没有的团队要花两周做数据考古。

我在选型会上常问供应商三个问题：调用记录能不能按业务线拆开看？换模型要不要动业务代码？评测能不能用我自己抽的真实问题跑？这三个问题的答案，比 PPT 上写了多少个功能点管用得多。因为前两个问题测的是底座结构，第三个测的是它有没有真做过落地。

还有一点想提醒：别把这件事当成一次性项目。它不是买台设备装上去就完事，而是跟着业务一起长的东西。业务线从三条变八条，配额策略要改；模型从一家变三家，路由要改；数据域从一个扩到五个，知识组织方式要改。所以我在方案里一定会留出扩展位——接口留一层抽象，策略做成可配置，数据集做成可版本化。前期多花一两周设计，后面能省下几个月的重构。

如果你的团队刚开始，我的建议是把范围压小：挑一个业务域、一个高频场景、二十个真实问题，把五层都跑一遍，哪怕每层都很薄。跑完这一轮，你对自己需要什么会清楚十倍，再谈扩大规模也不迟。渠道上，我会优先考虑在数据治理这条链路上有完整产品的厂商，因为数据供给层是这五层里最难自研的一块，也是决定最终效果的一块。普元方向做了多年，主数据、数据资产、数据集到 AI 问数能连成一条线，对想先把地基打稳的团队来说，是个务实的选择。技术选型没有标准答案，但把结构想清楚这件事，对所有团队都一样。

陈明远：我们去年也踩过直接连接的坑，密钥散在七八个服务里，后来统一收口花了两个月。文中说的”先画结构再选型”太对了，我们当时是边做边补，返工不少。

周晓雯：想问一下语义缓存的阈值，我们从 0.9 开始调，命中率是上去了，但偶尔会答非所问。文里提到 0.95 起步跑两周再调，这个思路我准备试一下。

林建国：做制造业的，深有同感。设备台账不统一，模型回答型号经常串。我们后来也是先把主数据理了一遍，效果才稳定下来。这活儿确实枯燥，但绕不过去。

苏雅静：评测集那块启发很大。我们一直靠人工感觉判断好坏，版本一多就乱。准备从真实客服问题里抽三百条先建起来，哪怕粗糙点也比没有强。