AI网关治理RAG落地难题：知识路由、模型路由与成本观测实践

1. RAG项目真正卡脖子的地方：不是检索算法，是治理问题

我先说个可能有点扎心的结论：绝大多数RAG项目做了一半就卡住，不是因为Embedding选得不好、Chunk切得不对，也不是因为没上GraphRAG这类新玩法，而是因为整个链路处在一种"失控"状态。知识库越来越多、模型越接越杂、调用方从三五个涨到几十个，谁在调哪个库、用的什么模型、检索质量到底怎么样、一次问答花了多少钱，完全没有一个统一的视角。RAG成了"能跑但不敢上生产"的demo。

热词里反复出现的"rag hit rate""rag瓶颈""解决了知识割裂 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代码越改越乱，引入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: 8000000

FAQ类的简单问题走小模型，长文分析走旗舰模型；每个租户每天有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_decision=wrong的请求捞出来，逐个分析。发现错误集中两大类：一类是"跨域提问"（比如在售后场景问产品价格），一类是"边界语义"（比如"这个功能在保修范围内吗"既涉及产品库又涉及制度库）。针对第一类，光靠分类模型永远有盲区，于是加了关键词规则覆盖；针对第二类，我们调整策略，不强行单选，而是允许多库并行检索、结果融合。改完之后路由准确率虽然只提升了三个点，但"完全选错库"的错误率降了一半以上。

5.2 坑二：切换模型后回答质量崩了，问题出在prompt和模型的绑定关系没跟上

RAG项目里很多人会忽略一个细节：prompt其实是跟模型强绑定的。你在A模型上调好的prompt模板，直接切到B模型，大概率效果会崩——因为每个模型的指令遵循能力、格式偏好、幻觉抑制能力都不一样。我们有一次为了降成本，把一部分流量从旗舰模型切到中小模型，结果系统整体效果掉了近20%。开始以为是中小模型能力不行，后来排查网关日志才发现，prompt里有一段很复杂的格式约束和few-shot示例，中小模型根本理解不了。

排查思路：在网关的模型路由里增加prompt版本绑定——每个路由不仅指定模型，还指定对应的prompt模板版本。切模型的同时自动切换prompt，成本优化和效果保障才能同步生效。这次之后我们定了一个规矩：任何模型升级或切换，都必须先在网关的灰度策略里小流量跑一周，对比Hit Rate和无召回率指标再全量放开。

5.3 坑三：网关鉴权了，但后端RAG服务自己的权限校验又拦了一道

这个坑特别隐蔽。我们把权限收敛到网关层之后，信心满满地上线，结果第二天就有业务方反馈"有权限的用户查不到数据"。排查后发现，网关已经把用户角色正确解析并下发了，但某个RAG后端服务代码里还留着一道写死的"管理员才能看研报"逻辑，把网关放行的请求又拦了一遍。

排查思路：这就是典型的"新旧权限逻辑叠加冲突"。解决方式其实简单——后端服务统一改为"信任网关鉴权结果"模式，删掉自己的冗余判断。但这件事得靠上线前梳理所有后端服务的鉴权逻辑，把不统一的口径全部拉齐。我们整理了一张权限清单表，每个库、每个角色、每个请求路径逐条核对，花了整整两天才清干净。这里给个提醒：网关收敛权限是好事，但收敛前的权限现状盘点一定不能省。

5.4 关于四类"看似跟网关无关"的RAG质量问题的排查思路

最后补充一组排查思路汇总，适合团队内部做复盘参考。网关日志只能定位问题发生在哪个环节，但具体的修正动作还要回到各环节本身。

6. 最后分享几点实操体会

兜了一大圈，说点实在的。把AI网关引入RAG链路，不是一个"装了就完事"的动作，它真正改变的是团队的排查习惯和迭代节奏。我个人的体会是，网关最大的价值不是路由本身，而是它逼着你把RAG链路里所有环节都显性化——路由决策有日志、检索质量有指标、模型成本有配额、权限边界有审计。这种显性化带来的确定性，比任何花哨的RAG算法都更能支撑项目往前走。

经验上建议：先别急着上复杂策略。第一周只做两件事，一是把日志埋点做好，二是把现有RAG服务的路由和权限清点清楚。然后从最简单的知识路由开始配，跑通一个业务场景再横向扩展。另外可以利用网关日志重建线上测试集——把真实用户问过的问题按效果好坏标注出来，每次改动后灰度验证，这套数据集比手工构造的测试题有价值得多。

如果你现在的RAG项目也卡在"多库多模型难打理、线上问题难定位"这个坎上，可以试着从网关这套思路切入，慢慢你会发现，很多困扰你的问题其实不是检索该优化，而是链路该治理。