大模型API调用越来越便宜但你的RAG系统可能越来越贵。这是我给几家企业的知识库项目做技术咨询时最常看到的现象大家把精力全砸在向量检索、Prompt编排、切片策略上唯独把模型调用入口当成普通HTTP客户端来用。结果呢密钥散落在各个服务里换一家模型供应商要改一坨代码线上用户一多连最基本的限流都只能靠运气。其实这不是RAG方案本身不行而是它缺了一道“门”。这道门就是AI网关。传统API网关负责南北向流量、认证、限流AI网关还要额外理解语义、管控Token、感知模型能力。把AI网关用在RAG场景里并不是简单在前面挡一层而是要解决RAG生产化的几个核心矛盾多模型切换、成本失控、知识库隔离、链路可观测。我在内部把这套能力沉淀成了一个代号叫MAI GatewayModel-AI Gateway的入口层前后在三个行业项目里落地过今天把这套思路和踩坑经历完整写出来。1. 先盘一盘RAG项目上线半年后问题往往出在“调用层”很多团队在Demo阶段跑RAG跑得飞起但一进入生产环境就发现不对劲。我拆过几个真实案例最大的问题恰恰不在检索质量而在模型调用这一层。1.1 从“连得通”到“管得好”调用层的隐形成本RAG服务直连模型API是最常见的起步姿势文档切好、向量库建好、检索逻辑写好后直接在后端代码里调大模型接口。这套做法在小流量下没问题可一旦涉及多个团队协作问题就开始冒头。首先是密钥管理。不同环境、不同知识库对应不同的模型账号生产环境的Key可能被写在配置文件里也有可能被前端偷偷拿走刷量。其次是模型供应商切换。今天这家模型便宜、明天那家效果好业务希望快速比较但你的代码里到处都是某个供应商的SDK切换成本足够拖慢一个迭代周期。再就是用量统计。每个知识库每天消耗多少Token、花了多少钱这些数据在直连模式下几乎是一笔糊涂账。这些成本不会在第一天暴露但会在上线三到六个月后集中爆发。我见过一个客服从0到日活两万的RAG项目上线三个月后老板要成本报表技术负责人硬是熬了两天从各个日志里手工汇总Token消耗。这种事情只要在入口挂一道网关一分钟就能查出来。1.2 你的RAG足够好但你的“入口”还不够安全再说安全。RAG服务对外暴露的接口如果直接是模型API的透传那么用户的输入会原封不动进Prompt业务方通常还会在其中拼接知识库内容。如果入口层不做审计出问题后你根本说不清某段回答到底基于哪次检索、哪个提示词。合规审计一来整个链路都是黑盒。MAI Gateway在这里的定位不是替代RAG服务而是把“模型调用”和“用户请求”这两类流量统一收口。用户请求先过网关做认证、限流、审计网关再把请求转发给RAG服务RAG服务内部去检索、拼Prompt、调模型这次模型调用同样可以从网关走。这样“谁在调、调了什么、花了多少钱、返回了什么”全部有迹可循。2. RAG链路里那道“门”AI网关到底应该挡在哪一层这是我在交流时被问得最多的问题网关到底应该放在RAG服务前面还是放在模型API前面我的答案是两个位置都需要但职责不同。2.1 前置、旁路、内嵌三种接入方式的取舍先给结论。RAG项目的网关接入方式大致有三种前置、旁路、内嵌。前置Front Proxy是最容易理解的用户请求先到网关网关做认证、路由、限流然后转发给RAG服务。这种方式适合对外提供统一API入口比如客服问答、内部知识助手。好处是接入成本低坏处是网关不理解RAG特有的检索和生成流程精细化管控能力有限。旁路Sidecar/Base URL是让RAG服务的模型调用层指向网关。现在大多数LangChain/LlamaIndex项目都支持自定义模型接口地址你只需要把base_url改成网关地址就能在不改业务代码的情况下接管所有模型调用。这种方式特别适合Embedding模型和LLM的流量治理。内嵌Embedded是把网关的客户端SDK集成到RAG编排代码里在代码中明确拆分“检索阶段调用”和“生成阶段调用”。这种方式最灵活但要求团队有较强的工程能力也需要预留改造时间。我在实际项目里推荐“前置旁路”的组合用户入口走前置网关模型调用走旁路代理。两条路径都收口后续任何策略调整都不需要动RAG业务代码。2.2 网关在检索阶段与生成阶段的不同职责RAG链路里其实有两类完全不同的模型调用一类是Embedding模型负责把Query和文档转成向量另一类是生成模型负责根据检索结果生成答案。它们的特征差异很大。Embedding调用通常是短请求、高并发、对延迟极敏感。网关对这类请求不应该做太重的语义分析但要保障高并发下的稳定性比如连接池复用、独立的限流配额。生成模型调用则是长连接、流式输出、对超时极度敏感。网关如果还按普通HTTP请求的套路去设置超时大概率会在生成中途把连接掐断。MAI Gateway在RAG场景里最重要的一个设计就是按请求特征区分这两类流量。判断依据不靠猜而是依靠路由规则比如路径里带/embed的走Embedding策略带/chat的走LLM策略。这样出来后端的超时、重试、限流配置才能真正贴合RAG的运行规律而不是一刀切。3. 路由与语义缓存MAI Gateway让RAG成本降一半的两个关键设计如果说统一入口是地基那么路由和缓存就是RAG场景下最能直接产生收益的两面墙。一个负责把请求送到对的地方一个负责让重复请求不再花钱。3.1 语义路由把不同知识域和模型能力分到不同的后端RAG项目做到一定规模后不可能只有一个知识库。法务一个库、客服一个库、研发一个库每个库背后可能还有不同的Embedding模型、不同的切片策略甚至不同的生成模型。如果让用户请求直接打到某一个RAG服务就会要么串数据、要么漏数据。网关层的语义路由可以解决这个问题。简单做法是网关内置一套分类向量先对用户Query做Embedding再和知识域的路由规则向量算相似度命中哪个域就转发到哪个RAG后端。更轻量的做法是利用请求头里的租户ID直接路由比如X-Tenant-ID: legal就进入法务库。生成模型的路由又会复杂一档。简单问题用7B小模型足以回答复杂业务问题需要70B甚至更大参数的模型。网关可以把“是否涉及多跳检索”“是否需要代码生成”这类信号作为路由条件。比如Query里出现“代码”“函数”就优先路由到代码增强模型。这在agentic RAG场景尤其有用因为Agent会自己决定调哪些工具入口如果没有路由约束整个系统很容易失控。3.2 语义缓存与精确缓存结合检索结果和生成结果都能复用RAG场景存在大量相似提问比如客服系统里“怎么退款”和“退款流程是什么”就是同一个意图。如果每次都重新检索、重新调用大模型成本相当可观。语义缓存是把Query先做Embedding再与历史缓存的Query做余弦相似度比较相似度超过阈值就直接返回缓存答案。但这里有个很容易栽的坑语义缓存的Key必须包含知识库版本。否则知识库文档更新了缓存还在回旧答案。我在MAI Gateway里的做法是双缓存。第一层是精确缓存缓存完整请求的MD5适合完全相同的字符串请求。第二层是语义缓存为Query向量建索引阈值设在0.86到0.92之间。同时网关从请求头里提取X-KB-Version把它和Query向量的组合作为缓存命名空间。只要知识库版本变化旧缓存自动失效。缓存命中后网关会在响应头里加X-Cache: HIT。前端拿到这个标记后可以提示员工“该回答来自缓存可能滞后于最新文档”这样就避免了“答案很顺滑但内容过时”的尴尬。4. 照着抄的落地配置MAI Gateway在RAG场景的接入步骤不少朋友看完前面的思路还是会问一句到底怎么接下面给一份可以照着改的真实配置骨架不依赖某个商业产品思路迁移到任何API网关都成立。4.1 配置在最前面一份真实可落的网关配置示例MAI Gateway的配置我习惯用YAML管理核心分为四块对外路由、模型路由、缓存策略、限流策略。gateway: listen: :8080 routes: # 外部入口统一接收RAG请求 - name: rag-ingress match: path_prefix: /v1/rag upstream: http://rag-service:8000 auth: type: jwt issuer: https://sso.internal.example.com rate_limit: qps: 100 burst: 20 model_routes: # Embedding模型走独立策略 - name: embedding-mini match: path_prefix: /v1/embeddings upstream: http://embedding-service:11434 timeout: read: 10s write: 10s retry: max: 2 condition: idempotent # LLM生成走流式长连接策略 - name: llm-flagship match: path_prefix: /v1/chat/completions upstream: http://llm-service:8001 timeout: read: 300s write: 300s stream: enabled: true forward_headers: [X-KB-Version, X-Tenant-ID] semantic_cache: enabled: true similarity_threshold: 0.88 namespace_from_headers: [X-KB-Version] ttl: 3600 redis: addr: redis:6379 cluster_mode: false observability: metrics: - request_total - cache_hit_total - model_token_total trace: provider: otlp endpoint: http://jaeger:4317注意这里有几个关键点。/v1/rag走JWT认证但/v1/embeddings和/v1/chat/completions不一定需要重复认证因为它们属于RAG服务内部的模型调用安全由内网环境保障。限流是分路径做的用户入口整体QPS控制在100但Embedding模型独立限流避免检索高峰把生成流量挤死。4.2 接上RAG服务链路压测与超时参数配置写完别急着上线。我建议先做三轮压测重点看三个指标P99延迟、Token吞吐、缓存命中率。第一轮是纯RAG服务压测不经过网关拿到基线。第二轮是RAG服务加网关转发看网关带来的额外延迟正常情况下应该在1到3毫秒以内超过5毫秒就要检查网关是否做了太多串行逻辑。第三轮是语义缓存开启后的压测重点看重复Query的缓存命中率和后端负载变化。超时参数也很有讲究。生成模型调用务必开启流式转发并设置300秒的读超时。很多人第一次部署时用的是默认60秒结果大模型思考稍久网关就直接504用户还以为是RAG检索坏了。另外重试逻辑只对幂等请求开放。Embedding请求是幂等的超时后可以重试但LLM生成请求一旦发送模型端可能已经烧了一部分Token盲目重试会造成重复计费。MAI Gateway的默认策略是对LLM请求做“最多一次”传输不自动重试。5. 生产环境踩坑实录从SSE超时到缓存误命中这一节写几个真实踩过的坑都是那种“日志里看不出来、业务上很要命”的问题。5.1 坑一SSE流式连接总是在两分钟后断开现象很典型用户在问答页面看到回答生成到一半界面就报“连接已断开”。排查链路是这样的先看RAG服务日志发现LLM响应还在正常输出再看网关日志发现网关向上游发起了超时断开。根因就是代理层的读超时太短。很多网关默认的proxy_read_timeout只有60秒或者180秒而RAG场景一旦遇到长文档、多跳检索生成时间很长SSE连接就很容易被网关掐断。解决办法不复杂开启流式转发确保网关不会在SSE达到一定长度后自动压缩或缓冲同时把读写超时统一设为300秒。另外客户端断开时网关要及时取消上游请求否则模型还在继续生成浪费Token。5.2 坑二语义缓存给出了“看起来很对”的错误答案这个坑我印象最深。客服系统上线语义缓存后突然有用户反馈“明明文档里写了新的退货政策为什么机器人还在说老政策”。查了半天问题不在检索而在缓存。原因是语义缓存的命名空间里没有知识库版本。知识库更新后新Query的Embedding和老Query的向量距离很近语义缓存直接返回了旧答案。因为答案本身语句通顺、逻辑完整很多员工根本看不出它已经过时。解决方法是给每个知识库的更新操作分配一个版本号比如文档集合的哈希值网关把它作为缓存命名空间的一部分。只要版本变化旧缓存全部失效。另外建议把缓存命中标记暴露到响应头这样前端可以做视觉提示。如果你的业务对时效性极其敏感语义缓存只缓存“检索结果”而不是“最终答案”或者干脆对某些问题走强制穿透。5.3 坑三多租户写入的Header在路由层被吞掉了企业内部多人共用一套知识库平台时经常会出现“A部门的用户问出了B部门的答案”。表面上看是知识库隔离没做好实际上根因在网关路由。排查链路是这样的用户请求带上了X-Tenant-ID: a网关按前面的语义路由转发到了A部门的RAG后端响应正常。可当网关内部又把请求转发给LLM服务时有的网关实现会把原始Header清空或者只转发白名单里的Header。结果LLM服务接收到的X-Tenant-ID为空Prompt拼接时走了默认知识库自然就把B部门的文档也带了进来。解决办法是在网关的模型路由里显式声明需要透传的Header白名单并在转发前强制校验如果租户ID缺失直接拒绝转发不要让请求打到模型层。这类问题靠日志很难发现因为你看到的每一次检索都是正常的只有最终返回内容串了才知道出了事。6. 从问答机器人到知识平台MAI Gateway的多租户治理进阶网关在单项目里解决的是请求调度问题在多个团队的场景里解决的是治理问题。下面说两个已经落地的方向。6.1 客服问答与研发辅助的落地效果对比我拿两个真实项目做个横向对比。客服问答场景把MAI Gateway部署在用户入口后端挂了三个知识库客服政策库、产品文档库、工单历史库。网关先做租户路由再做语义缓存最后把模型调用统一接入审计。上线两个月后日请求量约2万语义缓存命中率稳定在31%左右模型调用成本下降约四分之一同时因为所有请求都有审计日志客服质量抽检不再依赖人工翻聊天记录。研发辅助场景不太一样它要的是严格的代码库隔离。不同项目组的知识库必须完全隔离不能因为一个语义相似的问题就串到别的项目文档。MAI Gateway在这里就不做语义路由了而是直接用X-Project-ID强路由同时只允许项目管理员对应的密钥访问该路由。隔离要求高的时候语义灵活性要适当放弃。6.2 灰度与回滚网关让RAG升级不再“一锤子买卖”过去升级知识库或换模型都是全量操作一上线就影响所有用户。有了网关层以后可以按权重做灰度路由比如把5%的流量切到新模型或新知识库观察回答质量和错误率后再逐步放量。MAI Gateway的模型路由里加权重非常简单model_routes: - name: llm-flagship-v2 match: path_prefix: /v1/chat/completions upstream: http://llm-service-v2:8001 weight: 5 - name: llm-flagship-v1 match: path_prefix: /v1/chat/completions upstream: http://llm-service-v1:8000 weight: 95灰度过程中网关会按权重把流量打到不同上游并在指标里记录每个版本的Token消耗和错误码。一旦新版回答质量明显下降直接把权重改成0就能回滚。这个过程不需要重新发版也不需要业务方改代码。7. 一些实在话适合用网关的场景和不适合的场景最后说点反常识的。不是所有RAG项目都要上一套AI网关。如果你只是本地跑一个知识库Demo或者在Notebook里做原型验证直接写代码调模型是最高效的没必要自找麻烦。另外如果团队规模小、只有一条模型调用链路、也没有多租户和成本分摊的需求那么网关带来的额外运维成本反而会拖慢进度。我建议至少出现下面三个信号之一再上网关第一模型调用链路超过一条比如有Embedding、重排序、大模型生成并且需要差异化治理第二业务上开始要求按部门/项目做Token成本分摊第三需要频繁对比不同模型供应商的效果但又不想每次改代码。这三个信号出现任意一个都说明直连模式已经到边界了。最后分享一条个人体会网关本身不会让你的RAG回答更准确它只是让系统的边界更清楚。真正让RAG变好的仍然是你的切片策略、检索排序和Prompt质量。但网关可以让你更加从容地去调整这些东西——因为你知道无论后面怎么改入口、成本、审计这些事都有人替你兜住了。先把调用矩阵盘清楚再把网关放上去这是我推荐的最稳路径。