RAG 检索怎样用 query rewrite 减少召回偏移

RAG 里出现“召回偏移”，通常不是向量库突然失效，而是原问题里的关键约束在进入检索前被稀释了：实体被换成泛称、时间范围被省略，或者用户真正要比较的对象被改成了另一个对象。query rewrite 的职责应当是整理检索输入，而不是替用户发明事实。

一个稳妥的做法是保留原问题，把改写结果作为检索专用查询，并在进入召回前检查实体、时间和范围约束。本文用一个最小小项目串起这条边界。官方资料入口：https://huggingface.co/docs

先把召回偏移拆成三类问题

先看一个具体问题：“请比较 2025 年之后支持流式输出的 Go RAG 框架，优先官方文档里有示例的方案。”这句话至少包含三个检索约束：技术实体是 Go RAG 框架，时间边界是 2025 年之后，筛选条件是流式输出和官方示例。

如果改写器只返回“Go RAG 框架对比”，检索范围会变宽；如果把“流式输出”改成“实时聊天”，语义看似接近，召回却可能偏向 UI 方案；如果删除“官方文档有示例”，最后的证据片段也会更难筛选。改写前先把偏移分成三类，后面才知道该检查什么：

先写改写契约，再让模型生成查询

改写提示词最重要的部分不是“写得更专业”，而是把允许做什么和禁止做什么写清楚。建议让模型只输出结构化对象：query 是给检索器的短查询，constraints 保存硬约束，changed 记录是否发生了改写。

from dataclasses import dataclass

@dataclass
class RewriteResult:
    # query 只服务检索，原问题仍然要保留给回答和审计。
    query: str
    # 硬约束用于阻止实体、时间和任务意图被改掉。
    constraints: list[str]
    # changed 让编排层决定是否需要做约束检查。
    changed: bool


def build_rewrite_prompt(question: str, constraints: list[str]) -> str:
    # 明确“不许补事实”，避免模型把缺失条件写成确定结论。
    rules = "；".join(constraints)
    return (
        "把用户问题压缩成检索查询，只保留可检索实体和用户限定条件。"
        "不得新增产品、时间、版本或结论；如果没有必要改写就原样返回。\n"
        f"硬约束：{rules}\n用户问题：{question}"
    )

这里的约束来自业务层，而不是改写模型自己猜出来的标签。比如“只看 2025 年之后”“必须包含流式输出”应该由请求解析或页面筛选条件传入；模型可以整理句式，但不能把“之后”改成“之前”。

把改写接到召回，而不是覆盖原问题

召回层可以使用 RewriteResult.query，回答层仍然使用原问题和召回证据。这样做有两个好处：一是改写结果只影响“找什么”，不会悄悄改变“用户问了什么”；二是日志里能同时保留两份文本，排查召回偏移时可以直接对比。

def retrieve(question: str, rewritten: RewriteResult, vector_store, keyword_store):
    # 只有改写结果通过约束检查，才允许它替代检索输入。
    query = rewritten.query if keeps_constraints(question, rewritten) else question

    # 两路召回互补：向量路找语义相关片段，关键词路保住专有名词。
    semantic_hits = vector_store.search(query, top_k=6)
    lexical_hits = keyword_store.search(query, top_k=4)
    return merge_unique(semantic_hits, lexical_hits)


def keeps_constraints(original: str, rewritten: RewriteResult) -> bool:
    # 生产实现应使用实体识别或业务字段比对，这里只表达回退边界。
    return rewritten.changed is False or all(item in rewritten.query for item in rewritten.constraints)

这个示例刻意没有把查询改写做成“越短越好”。短查询可能让向量召回更集中，但也可能丢掉版本、时间和对象等检索边界。实际系统应根据召回结果观察哪些约束最容易丢失，再调整结构化字段，而不是盲目增加提示词。

三种边界信号出现时应回退

第一，关键实体在改写结果中消失或被换成同类词。第二，时间、版本、地域、格式等硬条件数量变少。第三，用户意图从“比较”变成“推荐”，或者从“排查原因”变成“介绍概念”。这些信号说明改写已经越过检索整理的边界，应直接用原问题召回，并把这次改写记录下来供后续调整。

还要区分“改写失败”和“召回不足”。改写通过约束检查，只能说明输入没有明显漂移；它不保证向量库里存在答案，也不保证排序第一的片段就是最佳证据。召回数量、去重策略和重排模型属于后续问题，不应混在 query rewrite 这一步里。

小结：改写的目标是稳定输入

RAG 的 query rewrite 可以减少召回偏移，但前提是把它当成检索输入整理器：原问题负责保留用户意图，改写结果负责提供更适合检索的表达，约束检查负责阻止实体和限定条件被改掉，回退逻辑负责处理不确定结果。只要这四层边界清楚，后续更换嵌入模型、关键词引擎或重排组件时，问题也更容易定位。

相关问题

query rewrite 是否一定要调用大模型？不一定。固定的字段抽取、同义词表或模板已经能处理稳定约束；问题复杂、表达变化大时再引入模型。

改写后还需要保留原问题吗？需要。原问题是回答意图和审计依据，不能只保存改写文本。

为什么改写后召回仍然偏？可能是实体识别、索引字段、过滤条件或排序阶段的问题，应先对比原查询、改写查询和实际过滤条件。