RAG 查询路由策略：何时走关键词、向量、结构化查询或直接拒答

把所有用户问题嵌入后做一次向量相似度搜索，是最常见的 RAG 起点，也是很多生产问题的根源。用户可能在问“我有哪些待处理工单”，这需要结构化且有权限约束的查询；可能在查某个精确错误码，关键词检索更可靠；也可能提出系统根本没有证据的问题，此时最好的行为是拒答或请求补充信息，而不是返回最相似的三段文本。

查询路由的目标不是追求更多分支，而是把不同数据语义放到正确路径。路由器的输入应是规范化问题、用户和租户上下文、数据新鲜度要求、可用数据源以及风险等级。模型可以提供意图候选，但最终路径必须由确定性策略和可验证特征决定。

先定义路径的适用条件

一个实用的最小集合包含四类。关键词或倒排索引用于标识符、报错、产品名和精确术语；向量检索用于概念性问答和同义表达；结构化查询用于用户数据、指标、库存和权限敏感事实；拒答或澄清用于缺少数据、跨租户、超出产品范围或高风险决策。每条路径都要声明允许的数据源、最大结果数、权限过滤位置和失败时的后备方案。

例如“订单 8472 为什么失败”可以先识别出结构化实体 ID，走受权限保护的订单查询，再把相关日志片段交给语言模型解释。若直接向量搜索，系统可能返回另一个用户的相似报错文档，既无用又有泄露风险。

让路由决策有证据而不是黑盒标签

记录路由器选择的特征和规则：检测到的实体、意图置信区间、要求的新鲜度、候选数据源、拒绝原因和最终路径。不要记录原始敏感问题全文，必要时保存脱敏摘要和哈希。这样在用户质疑答案时，可以区分“检索路径错了”“路径正确但数据缺失”“数据正确但生成解释错误”。

伪代码中的关键是先做确定性边界检查：

if (!policy.canAccess(user, requestedSource)) return { route: "DENY", reason: "source_not_authorized" };
if (looksLikeExactIdentifier(query)) return { route: "KEYWORD_OR_RECORD_LOOKUP" };
if (needsFreshMetric(query)) return { route: "STRUCTURED_QUERY" };
if (intent.confidence < 0.65) return { route: "CLARIFY" };
return { route: "SEMANTIC_RETRIEVAL" };

数值阈值不是永久真理，应通过标注样本和线上结果校准。不同租户、语言和领域可能需要不同规则；但即使使用模型分类，也应保留可审计的最终路径。

后备路径不能绕过权限与质量门

当向量服务超时，不能直接把未过滤的全文索引作为 fallback；当结构化查询无结果，也不能自动切到其他租户的知识库。后备路径必须继承原来的数据范围和授权上下文。对于低置信问题，澄清提问常比扩大搜索范围更安全，例如询问用户是在找产品文档、个人数据还是某项指标。

上线验证可以准备四类样本：带精确 ID 的问题、需要实时数值的问题、语义解释问题和无证据问题。检查路由是否一致、权限过滤是否在每条路径生效、拒答是否明确说明缺少什么。再将路径选择和答案满意度关联，逐步调整规则，而不是只优化向量模型。

路由规则必须支持回放与版本比较

路由器升级后，最难排查的不是单次错误，而是某类问题在新规则下突然走了不同数据源。因此每个决策都应带 routerVersion、策略快照和输入特征摘要。保留一小段时间的脱敏回放样本，可以在不重新访问用户数据的前提下比较新旧规则：哪些查询从语义检索变成结构化查询，零结果是否增加，权限拒绝是否符合预期。

不要把回放只用于提高命中率。对高风险问题，验证新版本是否错误地扩大了数据范围；对成本敏感问题，验证是否把简单问题送进昂贵重排路径。发布时采用影子模式和分租户灰度，异常时能按版本立即回退。这样路由策略从一段难以解释的分类提示词，变成具备发布、观测和回滚能力的基础设施。

延伸阅读

• RAG 高级实践
• RAG 检索调试
• RAG 延迟预算