获课：xingkeit.top/16367/

RAG的三种增强手段，别在查询入口处偷懒

做RAG应用这一年多，我观察到一个很普遍的现象：很多团队把80%的精力花在了文档解析、分块策略、向量检索这些中游环节上，而对用户输入的“入口处”却异常宽容——用户问什么，就原封不动地拿去检索。结果就是，底层的知识库再完善、向量模型再精准，检索出来的东西总跟用户想要的隔着一层。这个问题逼着我重新审视RAG的前端处理，也就是查询重写、查询路由和Text2SQL这三件事。

先说查询重写。这个词听起来挺专业，但本质就是把用户那句不那么讲究的口语，翻译成检索系统能听懂的书面语。用户实际问的问题是啥样，做过产品的人都懂——“那个上次说的项目咋样了”、“帮我找一下那个红色的”、“我记得有个文档来着”。这些表达里充满了指代、省略和歧义。如果直接把“那个红色的”拿去向量检索，鬼知道能吐出什么来。

我们在早期的一个知识库问答项目里做过一个简单的实验：把用户原始问题和经过改写后的问题分别跑一遍检索，召回结果的top5相关性差距大概在三成左右。改写这个动作本身没什么神奇的，无非是把指代消解掉、把省略补全、把模糊的概念明确化。但就是这点前置处理，能让后面的检索压力小很多。一个优秀的查询重写，不是要改变用户意图，而是要把意图表达得让机器更容易理解。 有点像翻译，原文的意思不能变，但语法要通顺，词汇要精准。

再说查询路由。这个东西的核心问题是：当你有不止一个数据源或者不止一种检索方式时，用户的问题到底应该往哪送。很多人把路由理解成一个分类器——判断问题属于哪一类，然后交给对应的处理链。但我越来越觉得，查询路由的价值不在分类本身，而在“拒绝”的勇气。

什么意思呢？就是说，路由模块应该有能力判断一个查询在当前的知识范围内有没有可能被回答。如果明显超出范围，与其硬检索出一堆不相关的东西让模型去编，不如直接告诉用户“这个问题我回答不了”。我们在一个客服场景里加上这个拒绝逻辑之后，用户的满意度反而上升了——因为之前幻觉带来的误导比“不知道”更让人恼火。路由不只是一个交通指挥，它更应该是一个守门员。

当然路由的另一个常见场景是区分“问事实”和“问观点”。事实类问题走精确检索，观点类问题走语义检索，这已经是一个比较成熟的模式了。但实际业务中更棘手的往往是那种“既不是事实也不是观点”的问题——比如用户的描述本身就有歧义，或者问题里包含了多个子意图。这种时候路由要做的事情不是二选一，而是把问题拆解开，分发给不同的处理链路，再把结果汇总。这种“查询拆分+结果合并”的模式，在某些复杂场景下比试图找一个万能的检索方式要靠谱得多。

接下来是Text2SQL，这是我认为三种方案里最难做但也最有价值的一个。难在哪里呢？难在自然语言到SQL的转换不只是一个翻译问题，它本质上是“用户意图”到“数据结构”的映射问题。用户的问法五花八门，但数据库的表结构是固定的，这个映射过程中信息损失是不可避免的。比如用户问“上个月卖得最好的产品是什么”，你要先把“上个月”转成日期范围，把“卖得最好”转成销量排序加limit1，同时还要知道“销量”对应的是订单表的哪个字段。这里面每一层都可能出错。

我们踩过的一个典型坑是：Text2SQL的准确率在开发环境用几十条测试用例看着还行，一到生产环境面对用户千奇百怪的问法就原形毕露。后来总结出的教训是，不要试图让模型从零理解数据库结构，应该预先构建好“语义层”——也就是把数据库的字段、表关系、常用查询模式先做一层语义化的封装，让模型的工作从“写SQL”变成“从预设模板里选择合适的填空”。这种方式虽然灵活性差一些，但稳定性高了一个量级。

关于这三种方案的组合使用，我的看法是：查询重写是基础，几乎每个RAG应用都应该有，成本最低收益最稳。查询路由是中间层，当你有多个数据源或多种检索方式时值得加。而Text2SQL是一个独立的赛道，不要把它当成RAG的附属品，它的场景很明确——用户需要从结构化数据里查精确数值时，才值得上。 很多失败案例就是因为在不需要结构化数据的地方硬塞了Text2SQL，最后搞得又慢又不准。

最后说一个最容易被忽视的问题：这些前置处理加得越多，端到端的延迟就越高，用户体验的损耗是实实在在的。 查询重写可能要多花几百毫秒，路由判断又要几百毫秒，Text2SQL生成再加一次模型调用，整个链路下来，用户等一个答案可能要五六秒。这不是不能接受，但必须有所取舍。我的原则是：对于高频、简单的查询，尽量走缓存和快速路径，跳过那些复杂的前置处理；只有对复杂、低频、高价值的查询，才走完整的增强链路。把计算资源花在刀刃上，比试图让每一次查询都尽善尽美要务实得多。RAG的入口优化，说到底是一场精度和延迟的平衡游戏，别在任何一个方向上走极端。