1. RAG项目真正卡脖子的地方不是检索算法是治理问题我先说个可能有点扎心的结论绝大多数RAG项目做了一半就卡住不是因为Embedding选得不好、Chunk切得不对也不是因为没上GraphRAG这类新玩法而是因为整个链路处在一种失控状态。知识库越来越多、模型越接越杂、调用方从三五个涨到几十个谁在调哪个库、用的什么模型、检索质量到底怎么样、一次问答花了多少钱完全没有一个统一的视角。RAG成了能跑但不敢上生产的demo。热词里反复出现的rag hit raterag瓶颈解决了知识割裂 rag其实就是这个问题的侧面写照。大家拼命在调检索精度却忽略了一个更基础的问题当你有多个知识库、多套RAG服务、多个模型的时候请求到底应该怎么走出问题了怎么定位预算怎么控制权限怎么收敛今天这篇文章就是用AI网关这套思路来解决这些检索之外的RAG落地问题。我以团队基于MAI Gateway做行业落地的经验为主线拆解我们为什么引入网关、网关在RAG链路里到底承担什么职责、真实项目里怎么配置以及我们踩过的坑。内容偏工程实践适合已经在做RAG项目、但发现效果调不动、问题难定位、线上不敢上的团队参考。1.1 知识库割裂路由全靠写死代码做过企业级RAG的都懂真实环境几乎没有一个知识库打天下的情况。以我们服务的客户为例最常见的是三套库并行一套放正式制度文档和产品手册一套放历史工单和售后案例一套放实时抓取的公告或新闻数据。文档格式不一样、更新频率不一样、权限范围也不一样。传统做法是什么在业务代码里写死if-else检测到query里有保修就走售后库有价格就走产品库都没匹配上就默认走全量库。这种硬编码路由在初期够用但很快暴露问题——query表达千变万化规则根本写不完。比如用户问这东西坏了找谁没有保修两个字规则就懵了请求落到错误的知识库召回质量自然断崖式下跌。这就是知识割裂最直接的体现知识本身没打通路由逻辑也撑不住复杂语义。我们当时处理的方式是让MAI Gateway承担知识路由能力不再靠业务代码里的if-else而是让网关根据query的语义自动决定分发到哪个知识库对应的RAG服务。这个变化看着简单实际是架构思维的转变路由从业务逻辑的一部分变成了基础设施的职责。1.2 检索质量是黑盒线上问题无法定位第二个让人头疼的问题是检索质量在线上完全不可见。很多团队做RAG评估靠的是离线脚本准备几百条测试题算Recall、算Hit Rate觉得差不多了就上生产。结果一上生产用户反馈答非所问你连是哪一步出的问题都说不清——是意图识别错了是Chunk切分导致关键内容被截断是向量召回没召回到正确答案还是大模型生成时理解偏了没有线上请求的全链路数据这些问题只能靠猜。我们用MAI Gateway之后才真正解决这个黑盒问题。网关是所有RAG请求的必经之路每个请求从进来开始完整记录query原文、路由决策结果走了哪个知识库、用了哪个模型、检索返回的chunk清单、重排后的Top K结果、最终拼进prompt的内容以及模型生成的回复。任何一个用户反馈答得不对直接把这次请求的全链路日志拉出来回放问题出在哪一环一目了然。这个能力花不了多少代码量但能省掉的排查时间极其可观。1.3 成本与权限没有统一收敛点第三类问题偏管理与合规但往往最致命。企业里多个部门共用大模型和RAG能力是常态业务A用的模型和业务B用的模型可能完全不同有的任务需要调用贵的旗舰模型有的任务其实用小模型就足够。没有网关统一管控每个业务方各接各的月底账单出来根本没法分摊。权限问题更严重。很多RAG服务上线时只做了能调和不能调的粗粒度控制但企业真实诉求是这个库只有投研部能查那个库的合同数据只能给合规岗开放。这些细粒度权限散落在不同RAG后端里有的做了有的没做非常容易出越权事故。把权限收敛到网关层统一鉴权是我们在金融客户那里必须解决的事没有商量余地。2. AI网关在RAG链路里的定位不是API代理是应用感知的路由治理层2.1 先厘清一个概念网关不是负载均衡聊AI网关之前得先和传统API网关做区分。我们常见的API网关比如Kong、APISIX那一类核心能力是协议转换、流量控制、服务发现、负载均衡它不关心请求的业务语义。请求里带的是一串JSON它不管这个JSON是要算一道数学题还是查一段法律条文转发就完事了。但RAG场景下的AI网关完全不是这个逻辑。它必须理解请求的语义——至少是浅层语义——才能做好分发。同一个query目标是让金融法规库来回答还是让产品操作手册来回答这在转发前就必须判断清楚。这就是为什么通用API网关解决不了RAG的路由问题而必须有一个应用感知的AI网关站在前面。MAI Gateway的核心设计理念就是把它做成一个懂RAG的接入层它知道RAG请求长什么样知道一次问答由哪些阶段组成也知道哪些字段需要透传、哪些字段需要改写。它站在RAG服务和调用方之间一边对上游屏蔽多后端差异一边对下游提供统一的治理能力。2.2 MAI Gateway的三层结构我们落地时把MAI Gateway的逻辑架构拆成三层理解这个分层对排查问题帮助很大。第一层是统一接入层。所有业务方不管原来习惯用OpenAI的接口格式还是用各家模型厂商的私有格式到网关这里全部归一化成一套协议。这样做的好处是业务方只需要对接一次后续无论你后面接的是DeepSeek还是Qwen还是自研模型对调用方完全透明。多模型切换的成本从业务改代码变成了网关改配置。第二层是路由决策层这是整个网关的大脑。它接收解析后的请求做两件事一是模型路由判断这个请求适合用哪个模型来处理二是知识路由判断这个请求应该检索哪个知识库、或者走哪种RAG编排流程。这两层路由可以基于规则也可以基于模型。我们在生产环境用的方案是分类模型兜底规则双保险后面配置章节细说。第三层是后端适配层。网关背后可能连着好几个异构的RAG后端——有的是LangChain搭的有的是LlamaIndex搭的有的是自研的pipeline。适配层把统一请求转换成各个后端认识的结构再把各后端的返回统一包装成标准响应格式。此外适配层还负责把检索出的chunk、token用量、耗时等指标抽取出来送给观测模块。2.3 与RAG编排框架的分工网关不抢框架的活很多朋友第一次听说AI网关时会问它和LangChain、LlamaIndex这些框架是不是重叠了这个问题我们内部也争论过结论是完全不重叠各管一段。LangChain、LlamaIndex这类RAG编排框架解决的是怎么把检索和生成串起来的问题——它负责召回、拼prompt、调用LLM属于RAG链路的执行层。而AI网关站在这个执行层的外面负责请求往哪发、有没有权限、花多少钱、效果好不好这类治理问题。打个比方RAG框架是发动机负责产生动力AI网关是变速箱加仪表盘负责把动力分配到该去的地方、同时让你看清转速和油耗。你不可能让发动机自己去决定挂几档也不可能让变速箱自己去燃烧汽油。两者配合RAG链路才完整。3. 行业落地拆解金融投研和制造售后两类完全不同的RAG场景3.1 券商投研知识库合规审计、权限隔离、效果可溯先看金融行业。我们落地的第一个客户是某券商投研部门知识源结构非常典型外部公告库每天更新数据量大、内部研报库权限敏感仅投研人员可读、合规制度库全员可查但问题相对标准化。模型使用上也有明显分层简单制度问答用中小模型就够深度研报解读必须上旗舰模型。没接网关前这个项目的状态是三个知识库各搭了一套RAG服务调用关系由业务代码硬编码权限靠后端各自过滤成本各算各的。我们做了三件事都是围绕MAI Gateway展开的。第一知识路由统一。网关内部配置了基于意图分类的路由策略先用Embedding对query做向量化再用轻量分类模型判断它属于公告咨询、研报解读还是制度查询。分类置信度低于阈值时默认走全量检索宁肯多召回也不能漏召回。上线后知识路由的准确率大概在91%左右剩余9%里大部分是跨库问题这类请求网关会自动合并多个库的检索结果再按时间排序去重。第二权限收敛。网关接入客户统一身份体系每个请求带着用户角色标签。投研人员可以查研报库普通用户只能查制度库。后端RAG服务不再自己判断权限统一信任网关下发的鉴权结果。这让审计变得特别简单——合规要查谁看了哪份研报直接拉网关日志就行不用去翻好几个服务的散落日志。第三效果可度量。我们在网关层定义了核心指标无召回率检索阶段一个chunk都没召回的比例、Hit Rate人工标注的含义这里指问题在检索结果Top 5中能被命中的比例、引用准确率生成回答引用的内容是否真的来自检索chunk。上线两个月无召回率从8%压到2.6%Hit Rate从63%提升到83%。这个提升不完全来自网关但网关让提升方向变得清晰——每改一次Chunk策略线上指标第二天就能看到变化。3.2 制造企业售后工单口语化query下的agentic路由与降级容灾第二个案例是某大型制造企业的售后知识库场景特点完全不同。用户是全国的售后工程师和客服人员问的问题极其口语化而且大量夹杂着设备型号、故障现象、维修动作。比如三号机压力阀老是漏油咋整这种query直接做语义检索效果通常不好因为它本质上是一个排查链路——先识别设备型号再匹配故障现象然后拉出对应的维修手册段落和历史工单案例。我们为这个场景设计的是agentic RAG 网关路由的组合方案网关不直接把请求送给一个大而全的RAG服务而是先路由到工单意图识别服务该服务把query拆解成设备型号故障现象维修动作三元组再决定走哪条下游链路。这其实就是热词里常说的agentic rag——把一个大任务拆成多步决策每一步由不同的模型或服务完成。网关在这个架构里的价值体现在两点。一是多路RAG服务的统一接入这个客户同时有维保手册RAG、历史工单RAG和零件库问答RAG网关根据解析出的三元组自动分发需要时还可以并行调用多个RAG服务再聚合结果。二是故障降级如果历史工单RAG服务出现故障或超时网关自动把请求降级到纯维保手册RAG保证用户至少能拿到基础答案而不是直接报错。这个降级逻辑如果写在业务代码里会非常难维护放网关里就是一条策略配置的事。上线后工单首响解决率提升了大概22%这个数据一部分来自RAG检索质量的优化但更多来自路由选对了库——问维修的请求不再被错误的库干扰问零件库存的请求也不会被手册库带偏。3.3 两类场景的关键差异对照对比维度券商投研RAG制造售后RAG知识源特点文本规范、权限严格、更新频繁口语化工单、非结构化、跨库依赖路由难点区分公告/研报/制度权限敏感解析设备型号与故障现象链路复杂核心治理诉求合规审计、成本分摊、效果可溯多代理协同、故障降级、呼叫量控制网关侧重点鉴权收敛、观测审计意图路由、聚合分发、容灾切换这两个案例的共同结论是RAG项目做到一定规模瓶颈一定不在单个检索环节而在请求如何在多个知识源之间被合理分发和治理。这个问题的解法单纯靠改RAG代码越改越乱引入AI网关这层抽象反而是投入产出比最高的路径。4. 网关核心配置实录知识路由、模型路由与线上观测怎么配4.1 知识路由配置两条腿走路下面给一段我们实际在MAI Gateway里用的知识路由配置去掉了敏感信息只保留核心结构。这段配置对我们自己团队来说就是抄作业级别的参考。knowledge_route: strategy: hybrid # 混合策略向量召回 意图分类 规则兜底 embedding_model: bge-m3 # 用于query和库描述匹配 routes: - id: research_reports description: 内部研报、行业深度分析、公司研究报告 permission: [investment_researcher, compliance_officer] fallback_weights: 0.35 - id: public_announcements description: 上市公告、监管披露、公开市场信息 permission: [*] fallback_weights: 0.35 - id: compliance_policies description: 合规制度、操作流程、管理办法 permission: [*] fallback_weights: 0.3 rule_override: - match_keywords: [研报, 深度, 评级] force_route: research_reports - match_keywords: [制度, 合规, 办法] force_route: compliance_policies threshold: 0.62 # 低于该置信度时不单独路由走全库合并这套配置的思路很简单先用向量算query与每个库描述的相似度再用小分类模型给一个置信度两条路的结果加权。最后还有一层关键词规则覆盖处理那种意图很明确的query规则优先保证选错的概率被压到最低。4.2 模型路由与成本治理一个token都不白花模型路由的配置逻辑和目标用户是同一批人RAG技术负责召回生成费用的80%取决于选了什么模型。很多团队上行文没概念不管什么问题都上最强的模型一个月下来账单非常难看。我们给客户做的模型路由策略核心就一句话按任务复杂度分层按额度做上限。model_route: default: qwen-plus rules: - route_id: simple_faq selector: { task_type: faq, complexity: low } model: qwen-turbo max_tokens: 512 - route_id: report_analysis selector: { task_type: generation, complexity: high } model: qwen-max max_tokens: 2048 quota: per_tenant: daily_limit: 1000000 # 单租户每日token上限 per_route: report_analysis: monthly_limit: 8000000FAQ类的简单问题走小模型长文分析走旗舰模型每个租户每天有token硬上限超了自动降级到备用模型而不是直接拒绝。这个方案上线后客户的模型调用成本下降了约35%而回答质量的下降幅度几乎可以忽略。4.3 线上可观测性把每个RAG请求变成可回放的档案配置只是第一步真正让运维省心的是观测。我们在MAI Gateway里给每个请求生成了唯一的trace_id全链路记录的字段如下{ trace_id: rag-8f3a2c, query: 三号机压力阀漏油怎么处理, route_decision: { knowledge_route: maintenance_manual, model_route: qwen-plus, confidence: 0.87, route_reason: entity_match_device_model }, retrieval: { total_chunks: 156, top_k: 5, hit_ground_truth: true, latency_ms: 342 }, generation: { model: qwen-plus, prompt_tokens: 1280, completion_tokens: 186, latency_ms: 1902, content_preview: 建议优先检查压力阀密封圈... }, feedback: { user_rating: 4, flag: null } }这套日志格式上线后我们排查问题的速度提升了一个量级。以前用户说你们那个问答不准我们要开三个控制台挨个查现在直接把trace_id拿出来第一步看路由决策对不对第二步看检索召回有没有命中第三步看大模型生成有没有偏离。哪个环节有问题答案就在那张结构化日志里。5. 踩坑记录与排查思路网关不是银弹处理不好反而添乱5.1 坑一路由分类模型准确率不够引入网关后效果反而变差我们最初做知识路由时用了比较激进的方案——完全依赖意图分类模型没设阈值兜底。结果测试集上准确率有93%看起来很漂亮但线上真实query一进来就露馅了。口语化、嵌套意图、中英文混合分类器频频出错请求被送到错误的知识库。有一段时间整体效果比之前硬编码路由还差团队一度想回滚。排查思路我们先把网关日志里所有route_decisionwrong的请求捞出来逐个分析。发现错误集中两大类一类是跨域提问比如在售后场景问产品价格一类是边界语义比如这个功能在保修范围内吗既涉及产品库又涉及制度库。针对第一类光靠分类模型永远有盲区于是加了关键词规则覆盖针对第二类我们调整策略不强行单选而是允许多库并行检索、结果融合。改完之后路由准确率虽然只提升了三个点但完全选错库的错误率降了一半以上。5.2 坑二切换模型后回答质量崩了问题出在prompt和模型的绑定关系没跟上RAG项目里很多人会忽略一个细节prompt其实是跟模型强绑定的。你在A模型上调好的prompt模板直接切到B模型大概率效果会崩——因为每个模型的指令遵循能力、格式偏好、幻觉抑制能力都不一样。我们有一次为了降成本把一部分流量从旗舰模型切到中小模型结果系统整体效果掉了近20%。开始以为是中小模型能力不行后来排查网关日志才发现prompt里有一段很复杂的格式约束和few-shot示例中小模型根本理解不了。排查思路在网关的模型路由里增加prompt版本绑定——每个路由不仅指定模型还指定对应的prompt模板版本。切模型的同时自动切换prompt成本优化和效果保障才能同步生效。这次之后我们定了一个规矩任何模型升级或切换都必须先在网关的灰度策略里小流量跑一周对比Hit Rate和无召回率指标再全量放开。5.3 坑三网关鉴权了但后端RAG服务自己的权限校验又拦了一道这个坑特别隐蔽。我们把权限收敛到网关层之后信心满满地上线结果第二天就有业务方反馈有权限的用户查不到数据。排查后发现网关已经把用户角色正确解析并下发了但某个RAG后端服务代码里还留着一道写死的管理员才能看研报逻辑把网关放行的请求又拦了一遍。排查思路这就是典型的新旧权限逻辑叠加冲突。解决方式其实简单——后端服务统一改为信任网关鉴权结果模式删掉自己的冗余判断。但这件事得靠上线前梳理所有后端服务的鉴权逻辑把不统一的口径全部拉齐。我们整理了一张权限清单表每个库、每个角色、每个请求路径逐条核对花了整整两天才清干净。这里给个提醒网关收敛权限是好事但收敛前的权限现状盘点一定不能省。5.4 关于四类看似跟网关无关的RAG质量问题的排查思路最后补充一组排查思路汇总适合团队内部做复盘参考。网关日志只能定位问题发生在哪个环节但具体的修正动作还要回到各环节本身。问题现象优先排查环节网关日志里看什么回答与知识库内容不一致大模型生成环节prompt里最终拼进的chunk内容、生成tokens答案正确但来源不准重排/引用环节Top K结果和引用标注的位置复杂问题高频无召回向量化/Chunk策略retrieval.total_chunks是否过少路由环节高频选错库路由置信度和分类模型route_decision.confidence和route_reason6. 最后分享几点实操体会兜了一大圈说点实在的。把AI网关引入RAG链路不是一个装了就完事的动作它真正改变的是团队的排查习惯和迭代节奏。我个人的体会是网关最大的价值不是路由本身而是它逼着你把RAG链路里所有环节都显性化——路由决策有日志、检索质量有指标、模型成本有配额、权限边界有审计。这种显性化带来的确定性比任何花哨的RAG算法都更能支撑项目往前走。经验上建议先别急着上复杂策略。第一周只做两件事一是把日志埋点做好二是把现有RAG服务的路由和权限清点清楚。然后从最简单的知识路由开始配跑通一个业务场景再横向扩展。另外可以利用网关日志重建线上测试集——把真实用户问过的问题按效果好坏标注出来每次改动后灰度验证这套数据集比手工构造的测试题有价值得多。如果你现在的RAG项目也卡在多库多模型难打理、线上问题难定位这个坎上可以试着从网关这套思路切入慢慢你会发现很多困扰你的问题其实不是检索该优化而是链路该治理。