RAG 问题改写怎么落地，别只写一句「请优化用户问题」

摘要RAG 里的问题改写目标不是润色用户问题。它要把人的表达转换成检索系统更容易命中的查询入口。本文从工程实现角度拆解问题改写的触发时机、常见路线、代码落点、评估指标和踩坑点重点讨论如何提升召回同时避免把用户意图改偏。很多 RAG 项目刚接入知识库时常见问题并不在回答阶段而是检索阶段根本没拿到该拿的资料。用户问的是「这个政策今年还能用吗」知识库里写的是「2026 年差旅费用报销管理办法」。用户追问「那海外呢」检索器只看到三个字很难知道它继承的是上一轮的「差旅住宿标准」。用户问「RAG 问题改写怎么做效果好」文档里可能出现的是 query rewriting、query expansion、multi-query retrieval、HyDE。直接把原始问题丢进 embedding 模型很多时候是在赌。问题改写的价值就是在进入检索器之前把这次检索到底要找什么说清楚。问题改写在 RAG 里解决什么一个可用的 RAG 系统至少要把用户问题转成三类检索线索。原始问题里的困难改写后要补上的东西典型场景省略和指代当前问题的完整主题多轮对话、连续追问口语和文档语言不一致领域术语、实体名、同义表达企业制度、产品文档、技术知识库问题太宽或包含多个意图子问题、多个查询入口研究助手、复杂排障、方案对比查询缺少背景词假想答案、上位概念、相关术语概念解释、开放式问题约束不清时间、版本、租户、权限、地域合规、客服、内部系统这里最需要警惕的是改写不是越聪明越好。一个 rewriter 如果私自补入用户没说过的条件后面的检索和回答会在错误问题上显得很顺滑。线上排查时这类错误比普通幻觉更难发现。一条工程上更稳的改写链路我更推荐把问题改写拆成几层而不是让一个 prompt 同时做完所有事。用户原问题 - 会话上下文补全 - 约束抽取和保留 - 单查询或多查询生成 - 检索和重排 - 基于证据生成答案 - 记录原问题、改写问题、命中文档和答案这条链路里LLM 主要处理语言层面的改写规则和结构化逻辑处理边界。比如权限、租户、文档版本、时间范围最好不要让 LLM 自由发挥应该通过 filter 或 metadata 传给检索器。1. 会话问题先改成独立问题聊天式 RAG 最低配的改写是把当前轮问题改成脱离上下文也能理解的问题。例如历史对话是用户我们公司的差旅住宿标准是什么 助手国内一线城市、二线城市和其他城市有不同上限。 用户那海外呢更合适的检索查询是我们公司的海外差旅住宿标准是什么不要把上一轮助手的整段回答塞进去。历史带太多会把当前问题污染掉。一个简单的 prompt 可以这样写你是 RAG 系统中的查询改写器。 任务 根据聊天历史和用户当前问题改写成一个独立、完整、适合检索知识库的问题。 要求 - 只输出改写后的问题 - 保留用户明确提出的时间、地域、版本、产品、部门等约束 - 不要回答问题 - 不要补充用户没有表达过的新事实 聊天历史 {chat_history} 用户当前问题 {question}2. 复杂问题用多查询不要硬压成一句用户的问题经常包含多个入口。比如RAG 问题改写怎么做效果好HyDE 和多查询应该怎么选如果只改成一句很容易偏向某一种技术路线。更稳的方式是生成三到五个查询然后分别检索再合并和重排。fromdataclassesimportdataclassfromtypingimportIterable,ListdataclassclassRewriteResult:standalone_question:strqueries:List[str]filters:dictdefbuild_rewrite_prompt(chat_history:str,question:str)-str:returnf 你是 RAG 查询改写器。请输出 JSON。 字段要求 - standalone_question把当前问题改写成独立问题 - queries生成 1 到 5 个检索查询覆盖不同表达方式不要重复 - filters只提取用户明确给出的时间、版本、产品、地域、权限等约束 约束 - 不要回答问题 - 不要引入用户没有说过的新事实 - 如果问题非常明确queries 只保留 1 个 聊天历史{chat_history}当前问题{question}.strip()defreciprocal_rank_fusion(result_lists:Iterable[List[str]],k:int60)-List[str]:scores{}fordocsinresult_lists:forrank,doc_idinenumerate(docs,start1):scores[doc_id]scores.get(doc_id,0.0)1.0/(krank)return[doc_idfordoc_id,_insorted(scores.items(),keylambdaitem:item[1],reverseTrue)]这里的重点不在代码有多复杂而在输出结构。rewriter 输出的不应该只是一段自然语言最好是可记录、可回放、可评估的结构化结果。3. HyDE 适合补语义不适合补事实HyDE 的思路是先让模型生成一段假想答案或假想文档再拿这段文本去做向量检索。它对短问题、概念性问题、开放式问题比较有用。比如用户问合同终止赔偿直接检索可能太短。假想文档里可能出现「劳动合同解除」「经济补偿金」「N1」「违法解除」这些相关词向量检索会更容易靠近真实文档。但在制度、法律、医疗、金融场景里HyDE 要谨慎使用。它生成的是检索线索不是真实证据。比较稳的做法是HyDE 文本只参与召回不进入最终回答。最终回答只能引用真实检索文档。日志里记录 HyDE 文本方便排查它是否把方向带偏。对强事实定位问题优先使用原问题和结构化 filter。什么时候不该改写问题改写不是 RAG 的万能补丁。有些场景改写会增加风险。场景建议做法原因用户问题已经包含明确实体和编号直接检索或轻量规范化改写可能破坏精确匹配查询包含合同号、工单号、订单号保留原值走关键词或字段检索向量语义不适合精确 ID用户问某个版本的具体条款保留版本 filterLLM 容易补错时间范围权限、租户、部门条件很关键用 metadata filter不能靠自然语言改写保证边界高风险合规问答记录原问题和改写结果必须可审计、可回滚一个简单策略是先做 query routing。只有短句、追问、模糊问题、复杂问题、多跳问题才触发复杂改写。明确的编号查询、条款查询、实体查询可以直接进检索。defshould_rewrite(question:str,has_chat_history:bool)-bool:qquestion.strip()ifhas_chat_historyandlen(q)20:returnTrueexact_markers[合同号,订单号,工单号,编号,ID,id]ifany(markerinqformarkerinexact_markers):returnFalsevague_markers[这个,上面,刚才,怎么做,有什么区别,有哪些方法]ifany(markerinqformarkerinvague_markers):returnTruereturnlen(q)12这段规则很粗但它体现了一个原则。改写要按风险触发不要默认全量开启。评估别只看最终答案很多团队评估 RAG 时只看答案对不对这会漏掉问题改写的中间错误。建议至少拆成四层指标。层级看什么排查价值改写质量是否保留原意、是否引入新假设判断 rewriter 有没有改偏召回质量top_k 是否包含正确证据判断查询有没有找到资料重排质量正确证据是否排到前面判断 reranker 是否有效回答质量答案是否基于证据、是否引用正确判断 reader 是否忠于上下文线上日志建议至少保留这些字段{raw_question:那海外呢,standalone_question:我们公司的海外差旅住宿标准是什么,rewrite_queries:[公司海外差旅住宿标准,海外出差住宿费用报销上限],filters:{tenant_id:acme,doc_version:current},retrieved_doc_ids:[policy_2026_travel_03,policy_2025_travel_archive_01],reranked_doc_ids:[policy_2026_travel_03],answer_doc_ids:[policy_2026_travel_03]}有了这类日志排查会清楚很多。答案错了可以判断是原问题没表达清楚、改写漂移、召回失败、重排失败还是生成阶段没有按证据回答。常见踩坑把所有问题都改写成更正式的长句。长句不一定更适合检索。很多搜索和向量召回对短而准的实体词更友好。多查询数量开太大。召回面扩大以后噪声也会增加。没有 reranker 和去重多查询很容易把上下文塞脏。让 LLM 处理权限边界。权限、租户、部门、文档版本应该走结构化 filter。自然语言里的「只查当前用户可见文档」不能替代访问控制。HyDE 结果进入最终回答。HyDE 是检索辅助文本不是证据。最终答案应只基于真实文档。没有保存改写结果。问题改写是 RAG 中最容易制造隐性错误的环节之一。没有日志线上问题很难复盘。一个推荐默认配置如果是企业知识库或内部助手我会从这套配置开始会话问题统一做 standalone question 改写。明确实体、编号、条款号的问题不做复杂改写。模糊问题和复杂问题生成 3 个以内查询。多查询结果使用 RRF 融合再交给 reranker。时间、版本、租户、权限全部走 metadata filter。记录 raw question、rewrite query、filters、top_k 文档和最终引用文档。对高风险业务保留原问题检索结果与改写检索结果做对照。这套方案不会把 RAG 变得特别复杂但能解决大量真实项目里的检索前失败。后续如果流量足够、日志足够再考虑训练专门的 rewriter 或引入反馈式改写。收尾RAG 里的问题改写本质工作是把用户需求翻译成检索路径。它继承了传统搜索里的 query expansion也继承了会话问答里的上下文补全在 LLM-native RAG 里又扩展成多查询、HyDE、查询规划和反馈改写。真正落地时重点不在于 prompt 写得多漂亮而在于三件事改写是否保留用户原意。检索是否拿到正确证据。整个中间过程是否可记录、可评估、可回滚。只要这三件事没做好问题改写越复杂系统越难排查。把它当作一个受控的检索入口层来设计RAG 的稳定性会比单纯调大 top_k 或反复换 embedding 更容易提升。