1. 为什么要在RAG链路前面架一层AI网关1.1 从一次检索抖动说起去年下半年我接手了一个企业知识库项目底层用LangChain4j做RAG检索增强向量库选的是Milvus嵌入模型跑在本地Ollama上生成侧接的是公司统一的大模型服务。项目上线头两周一切正常第三周开始陆续收到反馈同一个问题早上问和下午问答案质量差得离谱有时候引用的是三个月前的旧文档有时候干脆答非所问。排查过程很折磨人。日志里看不出明显异常向量库的召回率指标也稳定模型服务那边也没报错。后来我把每次请求的完整链路打点拉出来对比才发现问题出在请求入口没有统一治理前端A组传的query带了多余的空格和换行B组传的query被截断到128字符C组干脆把用户的历史对话拼进了检索query里。同一个知识库三种输入形态检索结果自然天差地别。这件事让我意识到RAG的效果瓶颈很多时候不在检索算法本身而在进入检索之前的请求质量。而解决这个问题的位置恰好就是AI网关该站的地方。1.2 MAI Gateway在RAG架构中的定位MAI Gateway这类AI网关本质上是一个面向模型调用的流量治理层。它不负责检索也不负责生成它负责的是请求进来之后先做标准化、鉴权、限流、路由、缓存、日志然后再把干净的请求转发给下游的RAG服务或模型服务。放到RAG链路里它的位置是这样的客户端 - MAI Gateway - [Query预处理] - 检索服务(向量库) - 重排 - 生成模型 - 返回很多人会问RAG框架本身不是已经有Chain和Router了吗为什么还要在外面套一层网关我的理解是框架内的编排解决的是逻辑怎么走网关解决的是流量怎么管。前者关注业务逻辑后者关注稳定性、可观测性和成本。两者不冲突但职责必须分开。1.3 不架网关会踩的三个坑第一个坑是输入不可控。RAG对query质量极其敏感一个多余的标点、一段无关的上下文都可能让召回率掉十几个百分点。没有网关做统一预处理每个调用方都按自己的理解传参检索质量就是开盲盒。第二个坑是成本不可见。RAG一次完整链路可能涉及嵌入模型调用、向量检索、重排模型调用、生成模型调用每一环都在烧钱。没有网关做token统计和调用计数你根本不知道钱花在哪了。我见过一个团队重排模型用的是按次计费的API结果因为没做缓存同一个query被重复调用了上千次。第三个坑是故障不可隔离。向量库挂了、嵌入服务超时、生成模型限流这些故障如果没有网关做熔断和降级会直接穿透到客户端。有了网关你可以在入口层做超时控制、重试策略和兜底响应把故障影响面收窄。注意网关不是银弹。它解决的是流量治理问题不解决检索算法问题。如果你的RAG召回率本身就不行加网关也救不回来。网关的价值在于让好的RAG更稳、更省、更可观测。2. MAI Gateway接入RAG的核心配置拆解2.1 路由规则把不同请求分流到不同RAG链路MAI Gateway的路由能力是它最实用的功能之一。在实际项目里我通常会把RAG请求按业务域和query类型做两级分流。第一级按业务域分。比如公司有产品文档库、客服话术库、内部制度库三个知识库每个库对应一个独立的RAG服务实例。网关根据请求头里的X-Knowledge-Base字段把请求路由到对应的后端。第二级按query类型分。有些query是事实型检索XX功能的参数是什么适合走向量检索有些query是总结型把XX文档的核心要点列出来适合走全文检索加长上下文生成。网关可以根据query长度、是否包含疑问词等特征做粗分类路由到不同的处理链路。配置示例YAML格式基于常见网关配置习惯routes: - name: product-rag match: headers: X-Knowledge-Base: product backend: rag-product-service timeout: 30s retry: 2 - name: policy-rag match: headers: X-Knowledge-Base: policy backend: rag-policy-service timeout: 45s retry: 1这里有个细节不同知识库的超时时间要区别设置。产品文档库文档短、检索快30秒足够制度库文档长、重排耗时给到45秒。如果统一设成60秒慢的那个会把快的拖死。2.2 Query预处理在网关层做还是在下游做这是我在项目里纠结最久的一个问题。Query预处理包括去空格、去特殊字符、长度截断、敏感词过滤、同义词扩展等操作。放在网关层做的好处是统一所有调用方都享受同样的预处理放在下游做的好处是灵活不同RAG链路可以有自己的预处理策略。我最后的方案是分层处理通用预处理去空格、去控制字符、长度硬截断放在网关层业务相关预处理同义词扩展、领域词典替换放在下游RAG服务里。理由是通用预处理是卫生问题不该让每个下游服务重复实现业务预处理是策略问题必须贴近业务逻辑。网关层做通用预处理可以用Lua脚本或插件实现性能损耗极小。一个实测有效的通用预处理规则去除首尾空白和连续空白符去除零宽字符和不可见控制字符将全角标点统一转为半角query长度超过512字符时保留前512字符并记录告警空query直接返回400不往下游转发提示长度截断的阈值不要拍脑袋定。我的做法是统计线上query的长度分布取P99值作为截断阈值。大部分场景下512字符已经覆盖99%以上的正常query。2.3 缓存策略RAG场景下什么该缓存什么不该缓存RAG的缓存比普通API缓存复杂因为一次请求涉及多个环节每个环节的缓存策略都不一样。嵌入向量可以缓存。同一个query的嵌入向量是确定的假设模型不变缓存起来能省掉重复的嵌入调用。我用Redis做嵌入缓存key是query的MD5value是向量数组TTL设24小时。实测命中率在30%左右嵌入调用成本直接降了三成。检索结果可以短缓存。向量库的检索结果在知识库不变的情况下是稳定的但知识库可能随时更新。我的做法是给检索结果设5分钟TTL同时监听知识库更新事件一旦有更新就主动清空相关缓存。生成结果不建议缓存。生成模型的输出有随机性同一个query两次调用可能得到不同答案。而且RAG的生成结果依赖检索到的上下文上下文一变答案就变。缓存生成结果容易导致用户拿到过期答案。重排结果可以缓存。重排模型的调用成本通常比生成模型低但比嵌入模型高。如果检索结果缓存了重排结果也可以跟着缓存TTL和检索结果保持一致。环节是否缓存TTL缓存key备注Query预处理否--计算量极小缓存无意义嵌入向量是24hquery MD5模型变更时需清空向量检索是5minquery MD5 知识库ID知识库更新时主动清空重排是5min检索结果ID跟随检索缓存生成否--输出有随机性不建议缓存2.4 限流与熔断保护下游RAG服务RAG链路的下游通常比较脆弱。向量库的并发能力有限嵌入模型服务可能被多个业务共用生成模型有严格的QPS限制。网关层的限流和熔断是保护这些下游服务的第一道防线。限流我一般做两级全局级和路由级。全局级限制整个网关的总QPS防止突发流量打垮所有下游路由级针对每个RAG服务单独限流比如产品库RAG限制50 QPS制度库RAG限制20 QPS。熔断策略我参考的是错误率慢调用比例双指标。当某个下游服务的错误率超过50%或者慢调用超过超时时间80%比例超过30%就触发熔断后续请求直接返回兜底响应不再转发。熔断后每隔30秒放一个探测请求成功则恢复。兜底响应很重要。RAG场景下兜底不能只返回服务繁忙最好返回一个降级答案比如当前知识库服务繁忙以下是与您问题最相关的文档标题列表请稍后重试。这样用户体验不会太差。3. 真实案例从零搭建一条带网关的RAG链路3.1 环境准备与组件选型这个案例是我去年给一个中型企业做的内部知识库项目规模不大但链路完整适合作为参考模板。组件选型如下网关MAI Gateway社区版即可满足需求RAG框架LangChain4jJava技术栈团队熟悉向量库Milvus单机版数据量在百万级以内嵌入模型Ollama本地部署的bge-m3中文效果好本地调用无网络依赖生成模型公司统一的大模型服务通过内网API调用缓存Redis 7.x监控Prometheus Grafana选Ollama做嵌入的原因是数据不出内网而且bge-m3在中文检索任务上的表现确实不错。生成模型走公司统一服务是因为自部署大模型的成本太高统一服务有专门的团队维护。3.2 网关配置实操从安装到跑通第一条请求MAI Gateway的安装按官方文档走就行我这里重点说配置。第一步定义上游服务。在网关配置里注册RAG后端服务upstreams: - name: rag-backend targets: - host: 10.0.1.20 port: 8080 health_check: path: /health interval: 10s第二步配置路由和插件。路由匹配所有/api/rag/**的请求挂载预处理插件、缓存插件和限流插件routes: - name: rag-route match: path_prefix: /api/rag upstream: rag-backend plugins: - query-preprocess - redis-cache - rate-limit rate_limit: qps: 100 burst: 20第三步配置Query预处理插件。我用Lua脚本实现核心逻辑就是前面说的通用预处理规则。脚本挂在access阶段在转发之前执行。第四步验证。用curl发一条测试请求curl -X POST http://gateway:8000/api/rag/query \ -H Content-Type: application/json \ -H X-Knowledge-Base: product \ -d {query: 产品A的 最大并发数是多少 }观察网关日志确认query被预处理成了产品A的最大并发数是多少然后正常转发到了下游。3.3 检索链路的关键参数调优RAG检索效果的好坏很大程度上取决于几个关键参数。我在这个项目里反复调了三轮最终确定的参数如下。TopK向量检索返回的候选文档数。设太小会漏掉相关文档设太大会引入噪声。我的经验值是先设20再根据重排后的效果调整。如果重排后前3篇的相关性都不错说明TopK够了如果前3篇里只有1篇相关说明TopK可能偏小。相似度阈值低于这个阈值的文档直接丢弃。bge-m3的余弦相似度通常在0.3到0.9之间我设的阈值是0.45。低于0.45的基本是无关文档留着只会干扰生成。重排TopN重排后保留的文档数。这个直接决定塞进生成模型的上下文长度。我设的是5因为生成模型的上下文窗口有限塞太多文档反而会稀释关键信息。分块大小文档切分的粒度。我试过256、512、1024三种最终选了512。256太碎一个完整段落被切成好几块检索出来上下文不完整1024太大一块里混了多个主题检索精度下降。512是一个比较平衡的值。参数初始值调优后调整依据TopK1020初始值漏召回明显相似度阈值0.30.45低分文档干扰生成重排TopN105上下文过长导致答案发散分块大小1024512大块检索精度不足3.4 上线后的效果对比与数据上线运行一个月后我拉了几个核心指标做对比。检索命中率人工标注的相关文档是否出现在Top5中从上线前的62%提升到81%。提升主要来自Query预处理和参数调优网关本身不直接提升命中率但它让预处理和参数配置变得可管理。平均响应时间从2.3秒降到1.4秒。降幅主要来自缓存命中嵌入缓存和检索缓存的综合命中率在35%左右。生成模型调用成本下降约28%。原因是缓存减少了重复调用同时重排TopN从10降到5每次生成的输入token数减少了一半。故障恢复时间从平均15分钟降到3分钟以内。网关的熔断和健康检查让故障发现和隔离变得自动化。实操心得不要指望一次调优就到位。我的做法是每周拉一次线上query样本人工标注100条看检索和生成的效果然后微调参数。RAG调优是一个持续迭代的过程没有一劳永逸的配置。4. RAG落地中最容易踩的五个坑4.1 坑一把网关当RAG框架用我见过有团队试图在网关层做检索逻辑比如在网关插件里直接查向量库。这是典型的职责错位。网关的优势是轻量、高并发、低延迟它的插件机制适合做无状态的预处理和后处理不适合做有状态的检索和生成。检索逻辑应该放在专门的RAG服务里网关只负责转发和治理。如果你发现网关配置越来越复杂插件里塞了几百行业务逻辑那说明架构设计出了问题。4.2 坑二忽略query的语义完整性Query预处理最容易犯的错误是过度清洗。比如把query里的标点全部去掉结果产品A和产品B的区别变成了产品A和产品B的区别语义没变但产品A的价格是多少去掉问号后变成陈述句检索时的意图识别可能出错。我的原则是只清洗无意义的字符不动有语义的标点。问号、感叹号、引号这些有语义的标点要保留。只去除零宽字符、控制字符和连续空白。4.3 坑三缓存key设计不合理缓存key如果只用一个query字符串会出大问题。同一个query在不同知识库下的检索结果完全不同如果key里不带知识库ID就会串库。同理如果嵌入模型换了版本旧缓存就失效了key里要带模型版本号。我的缓存key设计是{知识库ID}:{模型版本}:{query的MD5}。这样既避免了串库也避免了模型升级后的脏缓存。4.4 坑四限流阈值拍脑袋定限流阈值定太高等于没限定太低会误伤正常流量。我的做法是先观察再限制上线初期不开启限流只做统计观察一周的QPS分布取P99值上浮20%作为限流阈值。另外限流要区分正常流量和异常流量。如果某个IP在短时间内发起大量相同query那大概率是爬虫或重试风暴应该单独处理而不是简单限流。4.5 坑五日志打点不完整RAG链路的日志如果只记录最终结果排查问题时就是睁眼瞎。我要求日志必须记录原始query、预处理后的query、检索到的文档ID列表、重排后的文档ID列表、生成模型的输入token数和输出token数、各环节耗时。这些日志通过网关统一收集打到Prometheus和ELK里。有了这些数据任何效果波动都能快速定位到具体环节。常见问题排查思路解决方法检索结果不稳定对比不同时间的query日志检查预处理是否一致缓存是否串库响应时间突增看各环节耗时打点定位慢环节检查下游服务状态生成答案发散看重排后的文档列表降低重排TopN提高相似度阈值缓存命中率低看缓存key分布检查key设计调整TTL限流误伤看限流触发日志调整阈值区分正常和异常流量5. 关于RAG和网关配合的一些个人体会这个项目做完之后我又陆续参与了几个RAG相关的需求有问答机器人、有文档助手、有智能客服。踩的坑多了慢慢形成了一些自己的判断。网关的价值在规模上来之后才明显。如果你只是做一个demo或者日请求量不到一千那网关带来的复杂度可能大于收益。但一旦请求量上来了调用方多了知识库多了没有网关就是灾难。RAG的效果上限由检索决定下限由生成决定。检索决定了你能不能找到正确的文档生成决定了你能不能把文档里的信息准确表达出来。网关能帮的是让检索和生成都稳定运行但它改变不了两者的能力上限。不要追求一步到位的完美架构。我的习惯是先跑通最小链路然后根据实际遇到的问题逐步加组件。网关是这样缓存是这样限流也是这样。一开始就设计一个面面俱到的架构大概率会过度设计而且很多设计在实际场景下根本用不上。最后分享一个我常用的调试技巧在网关层加一个debug模式当请求头里带X-Debug: true时网关会把预处理后的query、检索到的文档、重排结果、生成输入全部返回给调用方。这个功能在排查问题时极其好用比翻日志快得多。当然debug模式要加权限控制不能对所有人开放。