面试题 · Prompt
搜索「LLM 评测」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在RAG系统中，请详细说明query改写的策略方法，以及检索到相关文档后如何构建有效的提示词来生成最终答案。
1. 查询扩展（Query Expansion）
2. 查询分解（Query Decomposition）
3. 查询澄清（Query Clarification）
按学习路线查看教程、项目和面试题。
4. 伪相关反馈（Pseudo-Relevance Feedback）
1. 上下文组织
- 按相关性排序文档，高分在前
- 去重：相同内容只保留一份
- 截断策略：优先保留开头/结尾，中间用"..."省略
- 元信息标注：来源、时间、可信度分数2. 核心指令设计
3. 结构化模板示例
【系统指令】
你是一个严谨的问答助手，请基于提供的参考资料回答，必须标注引用。
【参考资料】
[1] {doc_content} (来源: {source}, 日期: {date})
[2] ...
【用户问题】
{original_query}
【要求】
- 直接回答，不要复述问题
- 不确定时明确说明
- 引用格式：[编号]4. 进阶技巧
| 策略 | 收益 | 成本 |
|---|---|---|
| HyDE | 召回+15-20% | 多一次LLM调用 |
| 查询分解 | 多跳问题准确率提升 | 延迟×N，需并行化 |
| 长上下文重排序 | 答案相关性提升 | 受限于模型长度 |
实际落地中，建议先做离线评测确定改写策略的收益，再逐步上线；提示词用A/B测试验证不同指令模板的效果。
场景切入
假设你在做一个智能客服系统，用户问‘我的订单为什么还没到’，你从知识库检索到一堆物流文档。你怎么把用户这个原始问题改一改，让检索更准？检索完之后，又怎么把这些文档拼成一个回答，让用户觉得靠谱？
层层追问
RAG里用户问的问题有时候很模糊，比如‘那个功能怎么用’，你会怎么处理这个query？……如果改成几个子问题去检索，效果会更好吗？……那检索到文档之后，你怎么组织提示词，才能让模型既引用原文又不照搬？
直球架构
请系统讲讲RAG中query改写的策略，有哪些主流方法？以及检索到文档后，构建提示词生成答案有哪些关键要点？可以结合工程权衡来说。
这道题问的是[[RAG]]系统里两个关键环节：一是怎么把用户的问题改得更适合检索，二是拿到文档后怎么组织提示词让模型好好回答。说白了，query改写的本质是弥合用户表达和文档表达之间的语义鸿沟，而提示词构建的核心是教会模型怎么用文档、怎么处理不确定性。
先说query改写。常见策略其实分几类，但真正落地你会发现很少只用一种，往往是组合着来。比如查询扩展，最简单的是用LLM生成同义词或近义词，把“退款流程”扩展成“退货退款步骤”“取消订单退钱”之类的，这样能提升召回。更高级一点的是HyDE，就是让模型先基于问题写一段“理想答案”，然后用这段答案去检索，而不是用原问题。这个在文档表述和用户问法差异大的时候特别有效。再一个就是查询分解，比如用户问“比较A和B的优缺点”，我会拆成“A的优点”“A的缺点”“B的优点”“B的缺点”四个子查询，分别检索再合并。这个适合多跳推理场景。另外还有查询澄清，当用户的query特别模糊，比如只说了“这个功能怎么用”，我会先让模型反问一下“您指的是哪个功能？”，等用户明确后再检索，这在对话式RAG里很实用。
这里有个边界要注意：HyDE适合语义差异大的场景，但代价是多一次LLM调用，如果系统对延迟敏感，可能就不合适。查询分解虽然能提升多跳问题的准确率，但子查询之间可能有信息重叠，需要去重，而且延迟会乘以N倍，所以必须并行化。真正落地时，我通常会根据业务场景选主策略，再辅以其他策略。举个例子，在客服退款场景里，用户可能说“我前天买的那个东西坏了”，这个query很模糊，我会先用查询澄清确定订单，然后用查询扩展把“坏了”扩展成“破损”“不工作”“有瑕疵”等，再检索。
说完改写，再讲提示词构建。拿到相关文档后，怎么组织成有效的提示词？核心是三点：上下文组织、指令设计、还有不确定性处理。上下文组织上，我会按相关性排序，高分在前，并且去重，相同内容只保留一份。如果文档太长，我会优先保留开头和结尾，中间用省略号，因为很多模型对中间内容的注意力较弱。元信息比如来源、时间、可信度分数也要标上，帮助模型判断。
指令设计上，我一般会强制要求模型标注引用，比如“根据[1]”，这样能减少[[Hallucination]]。同时明确告诉模型，如果文档不足以回答，就说不知道，不要编。如果文档信息矛盾，要列出不同观点并说明依据。这里有个坑：很多工程上线时只想着让模型多答，结果模型硬答导致错误，所以不确定性处理一定要在指令里写死。
进阶一点，我还会做[[重排序]]提示，就是把Rerank的分数作为文本提示注入，比如“文档A可信度0.95，文档B可信度0.4”，帮助模型判断哪些信息更可靠。另外，根据query类型动态选择提示模板，事实型问题用严格引用模板，观点型问题可以宽松一些。还有一个技巧是负样本提示，主动告知“以下文档与问题无关，请忽略”，这能过滤掉检索带来的噪声。
当然，实际工程中要权衡。比如HyDE能提升召回15%-20%，但多一次LLM调用，延迟和成本都上去了。查询分解也是，准确率提升但延迟翻倍。所以上线前我会先做离线评测，用[[RAGAS]]之类的框架评估不同策略的收益，再逐步上线。提示词模板也要用A/B测试验证效果。
所以整体上，我更倾向于把query改写和提示词构建看作一个系统来设计，先根据业务场景选主策略，再通过离线评测和A/B测试逐步调优，而不是一上来就堆所有策略。