RAG 这个词在过去一年里被聊得太多多到很多人以为它已经是个成熟方案了。但真正在生产环境里跑过 RAG 的人心里都清楚检索质量不稳定、多路召回难编排、模型调用成本失控、权限和审计无从下手——这些问题一个都没少。于是最近半年一个原本属于基础设施层的角色被重新推到台前AI 网关。它不再只是做 API 转发和限流而是开始承担 RAG 链路里的编排、路由、缓存、观测和安全职责。这篇就围绕 MAI Gateway 这类 AI 网关在 RAG 场景下的行业落地方案把我在实际项目里踩过的坑、做过的取舍、验证过的配置尽量完整地摊开讲一遍。如果你正在做企业知识库、Agentic RAG、或者想把 RAG 从 Demo 推到生产这篇内容应该能帮你少走不少弯路。我会从为什么 RAG 需要网关这个最容易被忽略的问题讲起一路讲到检索编排、缓存策略、观测体系和上线后的调优中间穿插具体的配置思路和实测数据。1. 为什么 RAG 项目跑着跑着就绕不开 AI 网关1.1 从能答出来到敢上线之间隔着什么大部分团队做 RAG 的路径都差不多拿 LangChain 或者 LangChain4j 搭个原型接一个向量库塞几十篇文档跑几个问题效果惊艳然后信心满满地准备上线。结果一进真实环境就发现原型阶段那些看起来没问题的地方全是雷。第一个雷是检索链路的复杂度爆炸。原型阶段你可能只有一路向量检索上线后业务方会不断提需求要支持关键词精确匹配、要支持多知识库路由、要支持按部门做权限过滤、要支持 GraphRAG 那种基于本体的关系推理。每加一个需求检索链路就多一层编排逻辑这些逻辑如果全塞在应用代码里很快就会变成一团无法维护的意大利面。第二个雷是模型调用的成本和稳定性。RAG 一次问答可能触发多次 LLM 调用——查询改写一次、重排一次、生成一次Agentic RAG 场景下甚至可能循环调用十几次。没有统一的调用层你根本不知道钱花在哪、哪个模型在拖慢整体延迟、某个供应商挂了怎么降级。第三个雷是观测和审计的缺失。RAG 的 hit rate 上不去到底是 embedding 模型不行、切分策略有问题、还是重排把好结果排掉了如果每次排查都要改代码加日志再重新部署这个迭代速度根本跟不上业务。这三个雷指向同一个结论RAG 需要一个独立的、位于应用和模型/检索组件之间的控制层。这就是 AI 网关在 RAG 场景下的核心价值——它把编排、路由、缓存、观测、安全这些横切关注点从业务代码里抽出来做成可配置、可观测、可复用的基础设施。1.2 AI 网关和传统 API 网关的本质区别很多人第一反应是我直接用 Nginx 或者 Kong 不就行了。不行因为传统 API 网关处理的是无状态的 HTTP 请求转发而 RAG 场景下的网关要处理的是有语义的、多阶段的、带状态的编排。举个具体的对比。传统网关看到的是一个 POST 请求它关心的是路由到哪个后端、限流多少 QPS。而 AI 网关看到的是用户问了一个关于报销政策的问题它需要决定这个问题要不要先做查询改写改写后去哪个知识库检索检索回来的 20 个 chunk 要不要重排重排后取 top-5 送给哪个模型这个模型返回的内容要不要做敏感词过滤整个链路的 token 消耗记在哪个租户头上这些决策依赖的是对请求语义的理解而不是对 HTTP 头的解析。所以 AI 网关的核心能力是链路编排 语义路由 全链路观测这三样传统网关一个都不具备。我在实际选型时总结过一个判断标准如果你的 RAG 系统满足以下任意两条就该考虑上 AI 网关——知识库超过 3 个、模型供应商超过 2 家、有明确的成本核算需求、需要按租户做权限隔离、检索链路超过 2 个阶段。满足得越多网关的价值越明显。1.3 MAI Gateway 在 RAG 链路里的定位MAI Gateway 这类产品的定位可以理解成 RAG 系统的中枢神经。它不替代向量库也不替代 LLM而是站在它们前面统一接管所有进出流量。具体来说它在 RAG 链路里承担四个角色。编排者把查询改写、多路召回、重排、生成这些阶段串成一条可配置的 pipeline。路由器根据查询意图、租户身份、成本预算把请求分发到不同的模型或知识库。缓存层对高频查询、embedding 结果、检索结果做多级缓存直接砍掉重复计算。观测点记录每一次检索的命中情况、每一个模型的延迟和 token 消耗为后续调优提供数据。这四个角色里我认为编排和观测是最容易被低估的。编排决定了你的 RAG 能不能快速响应业务变化观测决定了你的 RAG 能不能持续优化。很多团队只把网关当成一个转发器用那就浪费了它 80% 的价值。2. 检索编排把多路召回和重排串成一条可配置的流水线2.1 查询改写为什么必须放在网关层而不是应用层查询改写是 RAG 里性价比最高的一个环节但也是最容易被做错的地方。我见过太多团队把改写逻辑硬编码在应用代码里结果就是每换一个改写策略就要改代码、重新测试、重新部署。放在网关层的好处是改写策略变成配置。你可以针对不同的知识库配置不同的改写模板可以 A/B 测试两种改写策略的 hit rate可以在不改代码的情况下回滚一个有问题的改写 prompt。具体配置上我一般会设三档改写策略。轻量档只做指代消解和省略补全比如把它的报销标准是多少补全成差旅费的报销标准是多少适合对延迟敏感的场景。标准档在轻量档基础上加同义词扩展和关键词提取适合大多数企业知识库。增强档做多查询生成Multi-Query把一个原始问题扩展成 3-5 个不同角度的子查询分别检索后合并结果适合召回率要求高的场景。实测下来增强档能把 hit rate 提升 15-25 个百分点但延迟会增加 300-500mstoken 成本增加约 2 倍。所以我的建议是默认用标准档对召回率有硬要求的核心知识库单独开增强档而不是全局开满。2.2 多路召回的合并策略RRF 不是万能药多路召回听起来很美好——向量召回一路、关键词召回一路、GraphRAG 一路合并起来效果肯定更好。但实际做的时候合并策略选错效果可能比单路还差。最常用的是 RRFReciprocal Rank Fusion它的逻辑是只看得分的排名不看绝对分数公式是score Σ 1/(k rank)k 一般取 60。RRF 的好处是天然解决了不同召回路径分数不可比的问题——向量相似度是 0-1 的余弦值BM25 是几十上百的分数直接加权平均就是灾难。但 RRF 有个致命问题它假设每一路召回的质量是均等的。如果你的关键词召回质量明显高于向量召回RRF 会把两路的结果平等对待反而拉低了整体质量。我踩过这个坑一个技术文档知识库关键词召回准确率很高但向量召回因为文档里术语太多、embedding 效果差召回了一堆语义相近但主题不对的内容RRF 合并后 hit rate 反而掉了 8 个点。后来我改成加权 RRF给每一路召回配一个权重权重根据离线评测的 hit rate 动态调整。配置上大概是这样retrieval: routes: - name: vector_search weight: 0.6 top_k: 20 - name: keyword_search weight: 0.4 top_k: 20 fusion: strategy: weighted_rrf k: 60权重的调整不能拍脑袋我的做法是每周跑一次离线评测用固定的测试集算每一路的 hit rate 和 MRR然后按比例调整权重。这个流程跑顺了之后整体 hit rate 能稳定在 85% 以上。2.3 重排模型的接入位置和成本权衡重排Rerank是提升 RAG 精度的关键一步但它的接入位置很有讲究。放在网关层做好处是统一管理、可以按租户配置不同的重排模型坏处是增加了一次网络往返。我的经验是重排一定要放在网关层但要做成本控制。因为重排模型比如各种 cross-encoder的计算成本比向量检索高一个数量级如果对每一路召回的 20 个结果都做重排成本会失控。具体做法是两阶段重排。第一阶段用轻量级重排可以是小模型也可以是简单的规则打分把 20 个结果砍到 10 个第二阶段用重量级重排把 10 个砍到 5 个。这样既保证了精度又把重排成本控制在了可接受范围。还有一个细节重排的输入长度要控制。cross-encoder 的计算复杂度和输入长度是平方关系如果把整个 chunk 都塞进去延迟会很难看。我的做法是只取 chunk 的前 512 个 token 做重排实测精度损失不到 2%但延迟降低了一半以上。3. 缓存策略RAG 成本控制里最被低估的一环3.1 三级缓存的设计和命中率实测RAG 的缓存不能只做一层。因为 RAG 链路里有三种性质完全不同的计算embedding 计算、检索计算、LLM 生成。它们的缓存特性完全不同必须分层设计。第一级是 embedding 缓存。同一个 query 的 embedding 结果是确定的缓存 key 就是 query 文本的 hash。这一级的命中率取决于用户提问的重复度在企业内部知识库场景下实测命中率能到 30-40%因为大家问的问题高度相似。第二级是检索结果缓存。这里要注意缓存 key 不能只用 query还要带上知识库 ID、权限过滤条件、top_k 参数。因为同一个 query 在不同知识库、不同权限下的检索结果是不一样的。这一级的命中率比 embedding 缓存低一些大概 20-30%。第三级是完整回答缓存。这一级最省成本但命中率也最低因为稍微改一个字回答就可能完全不同。我的做法是对 query 做归一化去标点、去停用词、统一大小写后再做缓存能把命中率从个位数提升到 15% 左右。三级缓存叠加起来整体能砍掉大约 40% 的重复计算。这个数字看起来很朴素但换算成成本一个月能省下的 token 费用相当可观。3.2 语义缓存什么时候用什么时候是坑语义缓存Semantic Cache是最近很火的概念逻辑是把 query 做 embedding然后在缓存里找语义相似的 query如果相似度超过阈值就返回缓存结果。这个东西用好了很香用不好就是灾难。我踩过的坑是阈值设得太松0.85结果差旅费报销标准和差旅费报销流程被判定为相似返回了错误的缓存结果。用户问的是流程系统答的是标准这种错误在知识库场景下是致命的。我的经验是语义缓存的阈值不能低于 0.92而且只对事实型查询开启对流程型、操作型查询关闭。怎么区分可以在网关层做一个简单的意图分类或者干脆维护一个白名单只对特定类型的问题开启语义缓存。还有一个细节语义缓存的 embedding 计算本身也有成本。如果 embedding 缓存没命中语义缓存基本也不会命中这时候语义缓存就是纯浪费。所以语义缓存一定要建在 embedding 缓存之后先查精确缓存再查语义缓存。3.3 缓存失效和一致性怎么处理缓存最大的坑不是命中率是失效。知识库更新了缓存里的旧答案还在返回用户就会觉得系统胡说八道。我的做法是基于文档版本号做缓存失效。每个知识库有一个版本号文档增删改的时候版本号递增。缓存 key 里带上版本号版本号一变旧缓存自然失效。这个方案简单粗暴但有效缺点是版本号一变整个知识库的缓存全部失效会有一次缓存雪崩。为了避免雪崩我会做渐进式失效版本号变更后旧缓存不立即删除而是标记为待淘汰新请求优先查新版本缓存查不到再查旧版本同时异步预热新版本缓存。这样既保证了数据新鲜度又避免了缓存雪崩导致的延迟飙升。4. 观测体系没有数据支撑的 RAG 调优都是玄学4.1 必须埋点的几个核心指标RAG 的观测不能只看响应时间和错误率这种通用指标必须埋业务相关的指标。我在每个项目里必埋的指标有这么几个。检索命中率Hit Rate检索回来的 top-k 里有多少是真正相关的。这个指标需要人工标注或者用 LLM 做相关性判断成本高但必须做因为它是 RAG 质量的核心指标。上下文利用率送给 LLM 的上下文里有多少被真正用到了回答里。这个指标能反映检索精度——如果检索回来 10 个 chunkLLM 只用了 1 个说明检索精度不够或者 top_k 设太大了。首 token 延迟和总延迟RAG 的延迟要拆开看检索阶段、重排阶段、生成阶段分别耗时多少。只有拆开看才知道瓶颈在哪。Token 消耗分布按租户、按模型、按链路阶段统计 token 消耗。这个指标直接关系到成本核算也是发现异常调用的关键。这些指标里我认为上下文利用率是最被低估的。很多团队只看 hit rate但 hit rate 高不代表检索精度高——如果 top_k 设成 20hit rate 自然高但 LLM 要处理大量无关内容成本和延迟都上去了。上下文利用率能帮你找到 top_k 的最优值。4.2 用网关日志反推检索瓶颈的实战案例讲一个真实的排查案例。有个客户反馈 RAG 回答质量不稳定同一个问题有时候答得好有时候答得差。因为网关层有完整的日志我们直接把最近一周的日志拉出来分析。第一步看 hit rate发现整体在 75% 左右不算差。第二步看上下文利用率发现只有 30%——检索回来 10 个 chunk平均只有 3 个被用到。这说明检索精度有问题top_k 设太大了。第三步看具体是哪些 chunk 没被用到发现大量是目录页修订记录版权声明这类内容。问题定位了文档切分策略有问题把很多无意义的页面也切成了 chunk。调整切分策略过滤掉这些低价值内容后上下文利用率提升到 55%hit rate 提升到 88%同时因为 top_k 可以从 10 降到 6延迟降低了 20%。整个排查过程没改一行应用代码全靠网关日志。这就是观测体系的价值——它让调优从拍脑袋变成看数据。4.3 从观测数据到调优动作的闭环观测数据本身没有价值有价值的是从数据到动作的闭环。我一般会建一个简单的调优看板把核心指标和对应的调优动作对应起来。指标异常可能原因调优动作Hit Rate 低切分策略差 / embedding 模型不匹配调整 chunk size / 换 embedding 模型上下文利用率低top_k 过大 / 检索精度差降低 top_k / 加重量级重排首 token 延迟高检索阶段慢 / 重排模型太大加缓存 / 换轻量重排Token 消耗异常查询改写过度 / 上下文过长降级改写策略 / 压缩上下文这个表格看起来简单但它把看数据和做动作连起来了。团队里任何人看到指标异常都能对照表格找到第一步该做什么而不是干瞪眼。5. 权限、安全与多租户企业落地的硬门槛5.1 检索阶段的权限过滤为什么比生成阶段更可靠企业 RAG 和开源 Demo 最大的区别就是权限。Demo 里所有文档对所有人可见企业里不行——财务文档只有财务能看HR 文档只有 HR 能看。权限过滤有两个位置可以做检索阶段和生成阶段。生成阶段的做法是检索时不过滤生成时让 LLM 判断这个内容该不该给这个用户看。这个方案听起来很智能但实际不可靠——LLM 会犯错而且一旦犯错就是数据泄露性质很严重。我的做法是权限过滤必须在检索阶段做而且要在向量检索的查询条件里就带上权限过滤。具体来说每个 chunk 在入库时打上权限标签部门、角色、密级检索时把用户的权限信息转成过滤条件在向量库层面就过滤掉无权访问的内容。这样做的好处是双重的一是安全无权的内容根本不会进入后续链路二是效率过滤后的候选集更小重排和生成的成本都降低了。5.2 多租户下的资源隔离和成本核算多租户场景下网关要解决两个问题资源隔离和成本核算。资源隔离的核心是限流和配额。每个租户有自己的 QPS 配额和 token 配额超过配额就降级或者拒绝。这里要注意限流不能只按请求数限还要按 token 数限——因为一个请求可能消耗 100 个 token也可能消耗 10000 个 token只按请求数限流会失控。成本核算的核心是全链路打标。每个请求从进入网关开始就带上租户 ID后续所有的模型调用、检索调用都记录这个租户 ID。这样月底出账单的时候能精确算出每个租户消耗了多少 token、调用了多少次检索。我踩过的一个坑是早期没做全链路打标只在入口处记录了租户 ID结果异步的查询改写和重排调用丢失了租户信息成本核算对不上账。后来改成在网关层用 context 传递租户信息所有下游调用都从 context 里取才解决了这个问题。5.3 敏感内容过滤放在链路的哪个位置敏感内容过滤有两个方向输入过滤和输出过滤。输入过滤是防止用户问敏感问题输出过滤是防止 LLM 答出敏感内容。我的经验是两个都要做但位置不同。输入过滤放在网关入口在查询改写之前做这样能避免敏感 query 进入后续链路浪费资源。输出过滤放在生成之后、返回用户之前做最后一道防线。输出过滤要注意一个问题流式输出下的过滤。如果 LLM 是流式返回的你不能等全部返回完再过滤那样用户会感觉卡顿。我的做法是滑动窗口过滤——维护一个缓冲区每次收到新 token 就和缓冲区拼接检查是否有敏感内容没有就放行前面的部分。这样既保证了过滤效果又不影响流式体验。6. 上线之后那些只有跑起来才会遇到的问题6.1 冷启动阶段的缓存预热系统刚上线时缓存是空的所有请求都要走完整链路延迟会很高。如果不做预热第一批用户的体验会很差。我的做法是用历史 query 做预热。如果是从旧系统迁移过来的直接把旧系统的 query 日志拉出来批量跑一遍把 embedding 缓存和检索缓存填满。如果是全新系统就用业务方提供的高频问题清单做预热。预热的时候要注意控制并发。如果一次性把几千个 query 打进去会把下游的向量库和模型服务打挂。我的做法是分批预热每批 50 个 query批间间隔 1 秒慢慢把缓存填满。6.2 模型供应商切换时的平滑过渡生产环境里模型供应商切换是常态——可能是成本原因可能是稳定性原因也可能是合规原因。切换时最大的风险是效果回退。我的做法是双跑对比。新模型接入后不立即切流量而是让一小部分流量比如 5%走新模型同时记录两边的 hit rate、延迟、token 消耗。跑一周后对比数据如果新模型各项指标都不差再逐步放大流量。这个过程中网关的灰度能力是关键。要能按租户、按 query 类型、按流量比例做灰度而不是一刀切。MAI Gateway 这类产品一般都有灰度配置用起来比较顺手。6.3 长尾 query 的处理策略上线一段时间后你会发现 80% 的请求集中在 20% 的高频 query 上剩下 20% 是长尾 query。长尾 query 的特点是缓存命中率低、检索效果差、但单个 query 的调用成本高。对长尾 query我的策略是降级处理。具体来说长尾 query 不走增强档改写不走重量级重排直接用标准档改写 轻量重排 快速模型生成。这样虽然单个 query 的质量可能略低但整体成本和延迟可控。怎么识别长尾 query可以在网关层维护一个 query 频次统计频次低于阈值的就判定为长尾。这个统计可以滚动更新比如按最近 7 天的数据算。6.4 我踩过的三个真实坑第一个坑是缓存 key 设计不当导致的串数据。早期缓存 key 只用了 query 文本没带租户 ID结果 A 租户的检索结果被 B 租户命中了。虽然内容本身不敏感但这是严重的设计缺陷。后来在所有缓存 key 里都强制带上租户 ID 和权限标识。第二个坑是重排模型版本升级导致的效果回退。有一次重排模型升级没做灰度直接全量切换结果 hit rate 掉了 5 个点。回滚后发现是新模型对短文本的处理有问题。教训是任何模型变更都要灰度没有例外。第三个坑是限流配置过严导致的误伤。早期限流按 IP 做结果一个公司内网出口 IP 相同一个用户的高频请求把整个公司的配额用完了。后来改成按租户 ID 用户 ID 做限流才解决了这个问题。这三个坑的共同点是都不是技术难题而是设计时没考虑周全。所以我现在做 RAG 网关配置时会强制自己过一遍检查清单——缓存 key 是否带全维度、模型变更是否有灰度、限流维度是否合理、权限过滤是否在检索阶段、观测指标是否覆盖全链路。这个清单帮我避免了很多重复踩坑。RAG 这件事Demo 阶段拼的是 prompt 和模型生产阶段拼的是工程和基础设施。AI 网关在 RAG 里的价值本质上就是把那些看起来不重要但一出问题就要命的工程问题用可配置、可观测、可复用的方式解决掉。MAI Gateway 这类产品能不能用好取决于你有没有想清楚自己的 RAG 链路里哪些环节需要编排、哪些环节需要缓存、哪些环节需要观测。想清楚了配置就是水到渠成的事没想清楚再好的网关也只是个转发器。