京东大模型二面：RAG系统中如何进行query改写，以及如何基于检索结果构建有效prompt？

首页

热心网友

转载

2026-04-21

RAG 系统的效果优化，query 改写和 prompt 构建是两个最直接的手段，分别对应检索前和生成前的优化。query 改写要解决的核心问题是用户表达和知识库表述之间的语义鸿沟。

1. 题目分析

很多团队在搭建 RAG 系统时，容易陷入一个误区：把绝大部分精力都放在了 embedding 模型选型和向量数据库调参上。结果呢？系统跑起来效果总是不尽如人意——明明知识库里躺着正确答案，检索环节就是找不出来；或者好不容易检索出来了，大模型的回答依然不靠谱。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

问题出在哪儿？往往就出在两个容易被低估的环节上：一是用户的原始 query 未经任何处理就直接丢给了检索引擎，二是检索回来的文档片段未经有效组织就塞进了 prompt。这两个环节，恰恰对应着 RAG 管线中“检索前”和“生成前”的优化，是提升端到端效果最直接、也最有效的切入点。

1.1 原始 query 为什么不能直接用

先说一个最直观的感受：用户提问的方式，和知识库文档的撰写方式，常常是天差地别。用户可能随手输入一句“上次那个报错怎么解决的”，而知识库里对应的文档标题很可能是“ConnectionTimeoutException 的排查步骤”。这中间存在一道巨大的“语义鸿沟”——用户习惯用口语化、带省略和指代的方式提问，而知识库则倾向于结构化、规范化的专业表述。直接用原始 query 去做 embedding 检索，召回率自然上不去。

除了这种表述差异，还有几种典型的“难检索”场景。第一种是问题太笼统，比如“介绍一下你们的产品”，这种 query 的 embedding 向量在高维空间中指向一个非常模糊的区域，很难精准匹配到具体文档。第二种是复合问题，比如“对比 MySQL 和 PostgreSQL 在高并发写入下的性能差异，以及各自的锁机制有什么不同”，如果整体去检索，embedding 会被多个子话题“平均化”，导致每个子话题都检索不精准。第三种，也是多轮对话中的重灾区——指代问题。用户第一轮问“RAG 是什么”，第二轮接着问“它的检索阶段有哪些优化方法”，这个“它”如果不做处理，检索系统根本无从下手。

1.2 主流的 query 改写策略

明白了为什么要改写，接下来看看具体怎么改。实践中常用的策略，可以根据改写目标分成几类。

指代消解与上下文补全，这是多轮对话场景的刚需。具体做法是把当前轮的 query 和前几轮的对话历史一并提交给 LLM，让它输出一个语义完整、不依赖上下文的独立 query。例如，将“它的检索阶段有哪些优化方法”改写成“RAG 系统的检索阶段有哪些优化方法”。这一步看似简单，但在生产环境中几乎是必选项——没有它，多轮对话的 RAG 基本不可用。

查询分解，专门对付复合问题。思路是把一个包含多个子问题的复杂 query，拆分成多个独立的子 query，分别进行检索，最后再汇总结果。以前面那个对比问题为例，可以拆成“MySQL 高并发写入性能”、“PostgreSQL 高并发写入性能”、“MySQL 锁机制”、“PostgreSQL 锁机制”四个子 query。每个子 query 的语义更聚焦，检索精度自然更高。

多角度改写的思路则不同：针对同一个问题，用几种不同的说法去检索，最后把所有检索结果合并去重。背后的逻辑是，不同的表述方式可能命中知识库中不同的文档片段，多管齐下可以显著提升召回率。实现上，通常让 LLM 根据原始 query 生成 3 到 5 个语义相同但措辞不同的变体。

HyDE 是一种非常巧妙的思路。它不改写 query 本身，而是先让 LLM 根据 query “假想”出一篇可能的答案文档，然后用这篇假想文档的 embedding 去做检索。其原理在于：假想答案和真实答案在表述风格上更为接近（都是“文档体”），因此在 embedding 空间中的距离也更近。这个方法在 query 和文档之间表述风格差异巨大的场景下特别有效。

Step-back Prompting 则反其道而行之——不是让 query 变得更具体，而是让它变得更抽象。例如，用户问“Python 3.9 中 walrus operator 有哪些使用限制”，经过 step-back 后，问题可能变为“Python 赋值表达式的语法规则和限制”。更抽象的 query 能够检索到更全面的背景知识，适合那些需要先建立整体理解才能回答具体细节的场景。

1.3 改写策略的工程选型

需要明确的是，这些策略并非互斥，实际项目中往往需要组合使用。一个典型的组合流程是：先做指代消解保证 query 语义完整，再判断是否需要分解，最后对每个子 query 进行多角度改写或 HyDE 来提升召回率。

选型时的关键考量是成本和延迟。每多一步改写，就意味着多一次 LLM 调用，在高并发场景下，这笔开销不容忽视。因此，实践中通常采用分级处理策略：对于简单 query（单句、无指代、目标明确），直接检索不做改写；对于有指代的 query，进行消解；对于复合问题，进行分解；只有当前面步骤的检索结果质量不达标时，才触发 HyDE 或多角度改写这类更“重”的策略。这种“按需改写”的路由逻辑，本身可以通过一个轻量级的分类模型或规则集来实现。

1.4 基于检索结果构建有效 prompt

query 改写解决了“检索得准”的问题，接下来要面对的是：如何把检索到的文档片段有效地组织进 prompt，让 LLM 能够充分利用它们？

这个环节的核心矛盾，是信息量与可用性的冲突。检索回来的文档可能数量多、篇幅长，并且包含冗余甚至矛盾的信息，而 LLM 的上下文窗口有限，注意力分配也不均匀（即“Lost in the Middle”现象）。因此，prompt 构建的本质任务，就是在有限的 token 预算内，将最相关、最有用的信息，以最容易被模型理解和利用的方式组织起来。

重排序是连接检索和 prompt 构建的桥梁。向量检索的相关性评分是基于 embedding 相似度的“粗排”，而 Reranker（通常是交叉编码器模型）则会将 query 和每个候选文档片段拼接在一起，进行更精细的相关性打分。经过重排，真正相关的文档才会被筛选到前列。Cohere Rerank、bge-reranker 等都是常用的选择。重排之后，还需要考虑文档在 prompt 中的放置顺序——研究发现，把最相关的内容放在 prompt 的开头和结尾，中间放置次相关的内容，其效果优于严格按分数降序排列，这正是为了应对“Lost in the Middle”问题。

上下文压缩是一个被严重低估的技术。检索回来的文档片段中，真正与 query 直接相关的可能只有几句话，其余都是噪声。上下文压缩的做法，是使用 LLM 或专门的压缩模型，从每个片段中提取出与 query 直接相关的核心信息，过滤掉无关内容。LangChain 的 ContextualCompressionRetriever 就体现了这一思路。压缩之后，同样的 token 预算可以容纳更多有效信息。

Prompt 模板的设计直接影响模型的回答质量。一个优秀的 RAG prompt 模板通常包含几个关键要素：明确的角色指令，告诉模型必须基于给定的参考资料回答，切勿自行编造；对检索文档的引用格式做出规范，例如要求模型用 [1][2] 这样的格式标注信息来源，这既增加了答案的可追溯性，也在一定程度上“迫使”模型去真正阅读参考文档；以及对“不知道就说不知道”的显式约束，这是控制幻觉最直接的手段之一。

还有一个经常被忽略的细节：文档片段之间的冲突处理。当多个片段包含矛盾信息时（例如来自不同版本的文档），prompt 中需要显式告知模型“以下文档可能存在冲突，请优先参考标注为最新的信息”，并附上时间戳。如果片段之间存在逻辑递进关系，那么按照逻辑顺序而非单纯的相关性分数来排列，效果会更好。

图片

1.5 检索结果不够好时怎么办

现实情况中，检索结果不可能总是完美的。有时候检索回来的文档关联度很低，有时候知识库里压根就没有相关信息。如何处理这些“边缘情况”，是区分玩具系统和生产级系统的关键。

一个实用的做法是在 prompt 构建前，增加一个相关性判断环节：使用 Reranker 或 LLM 对检索结果进行二次打分，如果最高分都低于预设的阈值，就启动降级策略——例如，让模型基于自身知识生成回答，但明确标注“以下回答未基于知识库验证”；或者直接告知用户“未找到相关信息”。

另一个策略是采用混合检索。不单纯依赖向量检索，同时进行关键词检索（如 BM25），然后通过 Reciprocal Rank Fusion 等方法融合两者的排序结果。混合检索在实践中几乎总是优于纯向量检索，因为向量检索擅长语义匹配，关键词检索擅长精确匹配，两者形成了有效互补。

2. 参考回答

总的来说，优化 RAG 系统效果，query 改写和 prompt 构建是两个最直接、最有效的抓手，分别对应检索前和生成前的关键优化。query 改写的核心使命，是弥合用户自然表达与知识库规范表述之间的语义鸿沟。实际操作中，首要步骤是指代消解，这在多轮对话中是刚需，目的是将代词和省略补全为语义完整的独立 query；其次是查询分解，将复合问题拆分为多个子 query 分别检索再合并；还有多角度改写，利用 LLM 生成同一问题的多种表述以提升召回率；以及 HyDE 这种巧妙方法，让 LLM 先生成一篇假想答案文档，再用其 embedding 去检索，因为文档与文档之间的语义匹配，天然比 query 与文档的匹配更精准。工程实现上，这些策略并非全部堆砌，而是需要做分级路由——简单 query 直接检索，有指代的做消解，复合的做分解，仅在检索质量不达标时才触发更复杂的改写策略。

在 prompt 构建方面，核心矛盾在于有限的 token 预算与庞大的检索信息量。几个关键处理手段包括：一是使用 Reranker 对检索结果进行二次精排，交叉编码器在相关性判断上比向量相似度准确得多；二是实施上下文压缩，从每个文档片段中只提取与 query 直接相关的内容，剔除噪声；三是在模板设计上，将最相关的内容置于 prompt 的开头和结尾，以应对“Lost in the Middle”问题，同时显式约束模型在信息不足时如实告知。此外，在检索层面，通常采用混合检索策略，结合向量检索和 BM25 关键词检索并通过 RRF 融合排序，其效果普遍优于单一的向量检索。

来源:https://www.51cto.com/article/841100.html

免责声明：游乐网为非赢利性网站，所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系youleyoucom@outlook.com。

上一篇：Impactor APP 下一篇：归元S平台赋能魏牌V9X：硬核实力与原生AI重塑豪华智能新标杆