企业官网建设流程全解析

最近被问得最多的一句话是：RAG架构里放一个AI网关，是不是脱裤子放屁？我一开始也觉得，RAG不就是把问题转成向量查一下知识库，再拼进prompt扔给大模型么，中间加一层网关能干嘛。直到我带的项目因为模型调用乱成一锅粥、账单对不上、A/B测试没法做，连续加班三个月之后，我才发现自己错得离谱。RAG不是一条链路，是一张越织越密的网，而这张网上每一个模型节点的切换、扣费、降级，都需要一个有脑子的大门卫来管。这就是MAI Gateway真正能发挥作用的地方。

这篇文章会把我们在企业知识库问答场景里，从零接入MAI Gateway的完整过程讲清楚：包括为什么RAG比你想的更依赖网关、MAI Gateway的几个核心机制怎么理解、落地时的架构和配置长什么样，以及上线之后我们踩过的缓存、灰度、成本归因的坑。如果你正在做RAG知识库、企业搜索、智能客服，或者团队里已经开始多人多项目共用大模型API，这篇文章至少能帮你少走两个月的弯路。

1. 为什么RAG项目上了生产之后，比开发期痛苦十倍

1.1 一条RAG请求背后，至少藏着三次模型调用

很多人对RAG的理解还停留在demo阶段：加载文档，切片，embedding入库，然后用户提问时检索top-k，连同上下文一起发给大模型。这套流程在笔记本上跑通只需要半天。但一旦上生产，你会发现“模型调用”这件事变得极其碎。

一条看似简单的用户问题“报销单审批流程是什么”，背后实际可能经历：先是可选的query改写（可能是小模型，也可能是LLM），然后把改写后的query过一遍Embedding模型，接着向量检索，再过一个重排模型，最后把命中片段拼进prompt，发给生成模型。如果做的是Agentic RAG，模型还有可能自主决定要检索第二轮、第三轮，每轮都是新的embedding和生成调用。

我算过一笔账：一个普通的内部知识库问答，一次用户请求平均会触发2.5到4次模型调用。这些调用可能来自不同厂商、不同模型版本、不同计费方式。开发的时候不在乎，因为一次两次调用花不了几毛钱。但生产环境的真实用户流量一上来，这2.5到4次调用就变成了成本失控、故障扩散、效果无法追踪的根源。

更难受的是供应商侧的不可控。我们有一次遇到Embedding服务商在夜里悄悄升级了模型版本，第二天早上检索结果全面飘移，相关文档一个都捞不上来。没有网关的话，你只能挨个排查各个业务方用的是哪个endpoint、哪个模型版本，查清楚之后还要通知所有人改配置。这种折腾我经历过一次就不想有第二次。

1.2 多模型并存的三大失控：成本、密钥、灰度

如果你的RAG项目只有你自己一个人用，那确实不需要网关。但稍微有点规模的团队，立刻就会撞上三堵墙。

第一堵墙是成本碎片化。每个业务方各自申请API key，各自对接模型厂商，月底账单出来是一堆来自不同账号的消费记录。你想知道“客服知识库”这一个应用上个月花了多少钱？查不出来。你想知道重排模型和生成模型谁才是成本大头？更查不出来。没有统一出入口，成本归因就是一笔糊涂账。

第二堵墙是密钥管理混乱。Embedding一个key，生成模型一个key，重排一个key，有的服务商还有独立的网关地址。新同事入职要挨个申请，离职之后key也没人回收。我见过最夸张的情况是一把key被贴在公司内部文档里，全部门共用，月底账单爆炸了都不知道是哪个应用在疯狂调用。

第三堵墙是灰度发布做不了。大模型效果好不好，不能靠拍脑袋，要靠数据说话。你想把生成模型从A版本切到B版本，最科学的做法是先放5%流量观察几天。但业务代码里硬编码了模型ID的话，这个灰度就变成了一次全量切换。切完效果不行，再全量回滚，用户已经被糟糕答案伤害了。

这三堵墙有一个共同点：它们都不是模型能力问题，而是模型调用链路的治理问题。RAG的瓶颈从来不只是“检索得准不准”“生成得好不好”，还有“这些能力节点之间怎么协作、怎么被统一管理”。

1.3 传统API网关为什么解决不了LLM场景的问题

听到“网关”两个字，很多人第一反应是：我们已经有Kong/Nginx/Spring Cloud Gateway了，再加一个AI网关是不是重复建设？

传统API网关解决的问题是HTTP层面的：路由转发、鉴权、限流、熔断。它不理解“语义”，不关心你的请求体里那个prompt和上下文是什么，更不知道“帮我查一下报销流程”和“报销怎么弄”其实是同一个意思。所以传统网关做不到三件RAG场景非常需要的事：语义级别的缓存、模型级别的路由策略、按token计量的成本观测。

AI网关和传统网关的关系，更像是在传统网关之上长出了一个懂LLM的专用层。它仍然做统一接入、鉴权、限流，但它的判断维度是模型维度、语义维度、成本维度。你可以把它理解成一个专门为LLM流量定制的“中间人”，对外提供统一接口，对内连接多个模型供应商，并在这个过程中做缓存、路由、计量、可观测。

所以答案很清楚：RAG项目需要的是AI网关，而不是普通API网关。MAI Gateway正是顺着这个定位设计的。

2. MAI Gateway核心机制拆解：从统一代理到语义缓存

2.1 统一接入层：一个endpoint、一套协议通吃所有模型

MAI Gateway给我最直观的感受，就是终于不用在代码里维护五六个模型API地址了。它做的事情很简单：对外暴露一个OpenAI兼容的endpoint，业务方只需要按OpenAI的协议格式发请求，至于这个请求实际被转发给哪家供应商的哪个模型，由网关内部决定。

这样做的好处是，模型供应商的API格式五花八门——有的是OpenAI兼容，有的是自家定义的JSON格式——如果没有一个中间层做协议转换，业务代码就得针对每一家写一套适配逻辑。接入一个新模型不光是改配置，还要写代码、发版、回归。有了统一接入层之后，新增一个模型供应商只是在网关里加一个provider配置，业务方完全无感。

我们当时的做法是把MAI Gateway部署在Kubernetes集群里，上游用Ingress接入业务流量，网关上配置了三个provider：Embedding服务、重排服务、生成模型服务。业务后端只认网关的一个endpoint，API key也只存网关的环境变量里。代码里原来那些散落各处的模型调用，全部收敛成对网关的调用，运维同学终于可以睡个整觉了。

2.2 语义缓存的原理与配置

语义缓存是我认为MAI Gateway最值钱的功能，没有之一。RAG场景里的真实用户问题，往往同一个意思会有十几种问法：“报销单怎么走流程”“差旅费报销步骤”“我要报销打车费怎么办”。传统缓存按文本精确匹配，这些问法一个都命中不了，每一遍都要重新embedding、重新检索、重新生成，钱花了一遍又一遍。

MAI Gateway的做法是：把一个用户query向量化，然后和缓存里已有的query向量做相似度比较，超过阈值就判定为语义等价，直接把上次缓存的结果返回。它的判断依据不是字面是否一致，而是语义距离是否够近。

在配置上，几个参数很关键：similarity_threshold（相似度阈值）、ttl（缓存有效期）、namespace（缓存空间隔离）。阈值不是越高越好，我们一开始设了0.95，结果命中率惨不忍睹，因为真实问法在向量空间里很难达到这么高的余弦相似度；后来调到0.86左右，命中率才到可用的水平。但阈值也不能太低，否则语义完全不同的两个问题也会互相误伤。这个值需要拿你们真实的用户问题数据去调，没有固定的最优值。

注意：语义缓存一定要和业务场景绑定。多轮对话、需要最新数据的查询（比如查库存、查价格）、个性化强的问题，都不适合开语义缓存。我们只对“制度类问答”“知识类问答”这种答案相对稳定的场景开了缓存，效果最好。

2.3 路由策略：把流量播给最合适的模型

RAG项目里不同请求对模型能力的要求完全不一样。有的用户问的是“报销金额上限是多少”这种确定性极强的问题，标准模型就够用；有的用户问的是“你觉得我们这个报销制度有什么优化空间”这种开放式问题，必须上最强模型。如果所有流量都走同一个模型，要么成本浪费，要么效果不够。

MAI Gateway支持按优先级配置多级路由。我们当时的策略很简单：优先走效果最好的主力模型，当它触发限流、超时或5xx错误时，自动降级到备用的标准模型。对大流量的知识库问答场景来说，这个fallback机制带来的稳定性提升是立竿见影的——就算主力模型厂商出故障，用户的问答服务也不会完全中断，只是答案质量稍微降一点，但至少人在线。

更进阶的路由是基于成本或延迟的规则：比如夜间定时任务类的批量处理，指定走便宜模型；白天实时用户请求，指定走高质量模型。这些规则都可以在网关层配置，不需要业务方感知。灰度发布也依赖这块能力：把新模型的流量权重设成5%跑几天，看指标没问题了再逐步放大。

2.4 可观测性设计：从“不知道谁调了模型”到全链路日志

没有网关之前，我们连“今天全公司多少人在调大模型”都答不上来。接入MAI Gateway之后，每一条请求从进入网关开始就带上了trace_id，网关会记录它调用了哪个Embedding模型、哪个重排模型、哪个生成模型，各花了多长时间，各自消耗了多少token。

成本这块是重点。MAI Gateway会把token消耗按请求维度聚合，再按你自定义的维度拆分——按业务应用、按部门、按模型、按时间周期。我们后来每月的模型成本报表就是从网关后台导出的，再也不会出现财务问“这个月为什么AI支出翻倍”时我们面面相觑的场面。

3. 从0到1的落地实操：企业知识库接入MAI Gateway全流程

3.1 先定义需求场景和选型边界

我们当时做的项目是“集团内部规章制度百问百答”，后端技术栈是Java Spring Boot，知识库大约有两千多份制度文档，目标是让员工用自然语言快速查到制度依据。同时，客服团队也想复用这套知识库来应答客户常见问题。

选择MAI Gateway而不是自研网关，原因很务实：业务价值需要快速验证，我们没有时间从零去写一套语义缓存和token计量系统。AI网关本身不产出答案，但它是让RAG系统可规模化运营的基础设施，买现成的是当时的最优解。如果你也是第一次给RAG项目上网关，我也建议不要一上来就自研，先把网关的治理能力用起来，等规模大了再考虑按需定制。

3.2 整体架构与流量路径

整个系统的数据流是这样的：

用户从企业微信或客服系统发起提问，请求进入业务后端；业务后端负责对话管理和上下文拼装，然后把当前问题发送给MAI Gateway；MAI Gateway根据配置先查语义缓存，命中就直接返回，未命中则调用Embedding服务把query向量化，向量检索在向量数据库完成，随后可能调用重排服务精排，最后把top结果和prompt一起发给生成模型；生成结果原路返回并写入语义缓存。

这里有一个很容易被忽略的点：向量检索本身不一定经过网关。因为向量数据库的客户端通常要维护连接池，正常的架构是把检索放在业务侧或者独立检索服务里，网关主要负责管理AI模型调用节点。换句话说，MAI Gateway管的是“模型层”，不管“数据库层”。这个边界从一开始就得划清楚，否则后面排查链路易出错。

3.3 分步接入：Embedding、重排、生成三个节点的配置

第一步是配置provider。在MAI Gateway里声明三个上游供应商，并指定每个供应商使用的模型。以我们的配置为例：

# MAI Gateway provider配置示例 providers: - name: embedding_provider type: openai_compatible base_url: https://api.embedding-example.com/v1 api_key_env: EMBEDDING_API_KEY models: - name: embedding-v3 max_input_tokens: 8192 - name: rerank_provider type: openai_compatible base_url: https://api.rerank-example.com/v1 api_key_env: RERANK_API_KEY models: - name: rerank-v2 - name: llm_provider type: openai_compatible base_url: https://api.llm-example.com/v1 api_key_env: LLM_API_KEY models: - name: plus-model - name: standard-model

第二步配置路由和缓存。我们对生成模型做了两级路由，正常情况下优先走plus-model，遇到限流或5xx时降级到standard-model。语义缓存只开在知识库问答这个namespace，限定ttl为1小时，Embedding模型指定成和知识库向量化时完全一致的版本。

routing: - name: rag-generate criteria: - priority: 1 model: plus-model - priority: 2 model: standard-model fallback_on: ["timeout", "rate_limit", "5xx"] semantic_cache: enabled: true embedding_model: embedding-v3 similarity_threshold: 0.86 ttl: 3600 namespace: rag_qa

第三步改业务代码。这一层改造其实比我预想的简单：业务后端原来直接调用各家模型SDK的代码，全部替换成调用MAI Gateway的OpenAI兼容接口。Java侧用现成的OpenAI SDK把base_url指向网关地址就行，request和response结构和原来基本一致。

3.4 验证与上线

上线前我们做了一轮严格的回归测试：拿过去三个月里真实的用户问题构造了一组验证集，分别记录直连各模型和走网关两种方式下的答案一致率。因为网关本身不改变模型行为，只是多了一层转发，所以理论上答案应该完全一致；唯一可能产生偏差的地方是语义缓存命中后返回的是历史结果，和重新生成的答案在措辞上会略有不同。

实测数据上，走网关的端到端延迟比直连多了大约30到50毫秒，主要开销在网关的转发和埋点上报。这个数字在知识库问答场景里完全可以接受，毕竟一次检索加生成的耗时通常在2秒以上。最开始我担心网关会成为性能瓶颈，后来发现相比模型自身动辄几百毫秒到几秒的响应时间，网关这几十毫秒的开销几乎可以忽略。

3.5 上线后的第一周数据变化

接入网关后的第一周，我们干了三件事：把全公司所有直连模型的应用都迁到网关，给每个业务方分配独立的API key和namespace，再打开全量语义缓存。你猜结果怎么着？整个集团的模型调用总成本下降了大概35%，这个数字主要来自语义缓存命中了大量重复的、语义相近的咨询问题。员工问“年假怎么休”和“我有几天年假”，本质上是在问一件事，第一次生成完后，后面的类似问题全部直接命中缓存。

这个结果让我彻底改变了对AI网关的态度。它可能不会直接提升单次问答的质量，但它让同一份答案不再被反复“付费生成”，让团队的每一分模型预算都花得明明白白。

4. 上线后的血泪经验：缓存命中率、灰度切换与成本归因

4.1 语义缓存命中率上不去——排查链路记录

第一周我们看到了成本下降，但第二周复盘时发现缓存命中率只有12%，远低于预期。这个数字意味着大部分流量其实都没有享受到缓存红利。

我第一反应是阈值太高，把阈值从0.86一路调到0.82，命中率只涨了两三个点，不解决问题。后来详细翻网关日志，发现了一个隐蔽的坑：知识库向量化时用的Embedding模型版本是embedding-v3的旧快照，而网关语义缓存计算query向量时默认加载的是新版本。两个版本的向量空间分布有轻微偏移，导致同一个问法的语义相似度被拉低了。

修复方式很直接：把网关语义缓存的embedding_model固定成和知识库索引一致的模型版本快照，然后清掉缓存重跑。命中率从12%跳到了31%。这还没完——我又发现不少用户提问自带前缀，比如“你好我问一下报销流程是什么”“请问年假规定是怎样的”，这些前缀虽然在语义上不影响核心意思，但会拉低向量相似度。最后我们在进入缓存判断前加了一步query改写，把口语化前缀和停用词清洗掉，命中率最终稳定在40%以上。

注意：语义缓存和知识库索引必须用同一个Embedding模型版本，这是命中率的生命线。模型厂商升级版本后，如果不强制网关走旧版本，缓存计算和检索的一致性就会被破坏。

4.2 模型灰度切换后，生成效果“跳变”的教训

成本问题解决后，我们开始折腾路由灰度。团队当时拿到了一个新版生成模型，内部评测分数比旧版高不少，于是我们按老套路在网关上把新模型的流量权重调到5%，准备观察几天。

上了灰度第二天，客服团队就反馈用户投诉变多：新模型对某些企业内部的简称理解有偏差，在回答涉及“OA审批”“HR系统”这些词时会给出更泛化的解释，而不是直接指向内部制度文档。我一度怀疑是新模型本身质量不行，但翻网关日志后发现，那个5%的灰度流量是全局乱撒的，新模型被均匀地撒到了所有业务方，其中就包括对准确性要求极高的客服场景。

后来我们调整了灰度策略：把路由规则从“按流量比例灰度”改成“按场景和用户维度灰度”。客服场景继续走老模型，内部员工问答场景先放新模型的10%流量给白名单用户。这样即使新模型有偏差，影响面也完全可控。这个改动让我意识到，AI网关的灰度粒度不能只看比例，还要能切场景、切用户、切内容类型。

4.3 token成本归因为什么总是对不上云厂商账单

第三个月我们对账时发现一个问题：MAI Gateway后台统计的成本和模型厂商账单误差超过15%。这不是网关的问题，而是模型调用场景本身藏了很多容易被忽略的消耗点。

第一是重试和fallback。路由配置里设置了主模型报错后自动降级到备用模型，降级产生的token消耗会记在备用模型头上；如果主模型已经消耗了一部分上下文token才报错，这部分token同样要计费。第二是多轮对话的历史记录。RAG项目只要做多轮会话，每一轮生成都会把之前的对话历史重新发送给模型，历史token会被重复计量。第三是最容易被忽略的：Embedding调用。一次检索看起来只是请求了向量数据库，但它前面的文本向量化也是要花钱的，很多团队在做成本核算的时候根本没把Embedding算进去。

我们的解决办法是给网关的每一笔请求都打上trace_id，再按trace_id把一次完整的用户请求涉及的Embedding、重排、生成、重试、降级全部聚合成一条成本记录。月底和云厂商账单核对时，只需要对trace级别聚合的token总数，误差基本控制在2%以内。

4.4 当RAG走向Agentic RAG、GraphRAG，网关的角色会怎么变

最后聊聊演进方向。今年以来RAG这个词已经从最朴素的“向量检索加生成”扩散到了很多变体：有人用GraphRAG做实体关系的知识组织，有人用Ontology RAG做领域本体约束，还有人把Agentic RAG做成了让模型自己决定“要不要查第二轮、要不要调工具”。不管上层怎么变，一个趋势是很明确的：一个用户请求背后的大模型调用次数只会越来越多，且调用路径越来越动态。

这对AI网关提出了更高要求。朴素RAG阶段，网关做好Embedding、重排、生成这三个固定节点的治理就够了；到了Agentic RAG阶段，模型可能在一个会话里自主发起多轮工具调用，每一步都需要被记录、被计费、被限流。网关的角色会从“请求转发器”变成“AI流量的治理面”：它需要识别工具调用的链路，对模型自主行为设置预算上限，甚至在不同agent之间做策略隔离。

所以我的建议是，现在就开始用网关来管理AI调用，别等项目规模大了再补课。一开始不需要把功能全打开，先把统一接入、密钥管理、成本计量这三件事做了，就足以回本。缓存的调优、路由的灰度这些能力，等有真实流量了再慢慢加，一步步来就好。

我个人体会最深的一点是：AI网关解决的是工程治理问题，不是模型效果问题。它不会让RAG的答案变好，但它能让你的RAG系统从“几个人能用”变成“整个组织稳定依赖”。如果你正在做的RAG项目还停留在单机demo阶段，网关看起来确实多余；但凡是走上生产、接上真实用户、面对预算审计的RAG系统，网关都不是选择题，而是必答题。

最后再分享一个小技巧：在接入MAI Gateway时，先别急着配花哨的路由规则，把语义缓存打开并调好阈值，这是回报最快的一步。它的成本几乎为零，但能把你的模型账单直接砍掉三分之一。我见过太多团队一上来就折腾灰度、A/B测试，结果连最基础的重复问句缓存都没开，模型预算烧得飞快。先把最简单的事做到位，比什么都强。