> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # RAG中的查询转换 - URL: https://www.hubwiz.com/blog/query-transformation-in-rag/ - Published: 2026-08-26T16:41:38.000Z - Updated: 2026-10-13T15:18:46.000Z - Description: 查询转换是RAG中在搜索前重写问题的步骤，这样措辞不匹配就不会让你失去答案。 - Author: admin - Tags: RAG, #Import 2026-10-14 14:41 查询转换是RAG中在搜索前重写问题的步骤，这样措辞不匹配就不会让你失去答案。 ## 1、介绍 你打开公司的内部人力资源门户，输入一个问题：*"新父母有多少休假时间？"* 没有返回有用的结果。可能有一个关于假期天数的无关结果。可能什么都没有。答案就在那里，用简单的语言写在实际的政策中。它说员工有权享受26周的带薪育儿假。你的搜索从未找到它。 政策说的是"育儿假"。你问的是"休假时间"。对于将单词作为数字进行比较的机器来说，这两个短语看起来完全不相关。 这是你在开始使用RAG构建时没有人警告你的部分。拥有向量数据库和工作的嵌入模型感觉就像是全部工作。 但只有当你的问题和答案使用紧密对齐的语言时，搜索才有效。当它们不对齐时，系统会静默失败。没有崩溃，没有错误，只有空的或错误的结果，以及假设信息不存在的读者。 ## 2、查询转换解决的问题 这就是为什么会发生这种情况。系统将你输入的每个问题和数据库中的每个文档块转换为称为嵌入的长数字列表。它比较这些数字，而不是单词本身，寻找与你的问题最接近的文档块。 **"新父母的休假时间"和"育儿假"**对你来说意味着同样的事情。对于嵌入模型来说，它们可能相距足够远，以至于正确的文档块永远不会进入候选名单。 这就是查询转换要弥合的差距。你不是将问题原样发送到数据库，而是先重塑它，使其更接近答案的实际写法。有多种方法可以做到这一点，每种方法都解决了同一个问题的略微不同的版本。 ## 3、HyDE（假设文档嵌入） 这是针对这种不匹配的一个奇怪的修复方法。你不是将确切的问题发送到搜索中，而是让AI先猜测答案，然后使用该猜测进行搜索。 AI不需要猜对。它只需要听起来像真实的文档。所以你给它这样的指令：写一段回答这个问题的短文，就好像它来自人力资源政策文件一样。 AI从未见过实际的政策。但它知道政策语言是什么样的：正式、声明性、充满资格规则和时间框架。 这是它可能写回的内容： > *"新父母在孩子出生或收养后有权享受几周的带薪休假。确切的持续时间取决于公司政策，通常在最低就业期限后获得。"* 这是虚构的。其中没有26周，没有提到30天的申请窗口。但看看它的形状：资格、持续时间、正式的语气。这与政策中实际段落的形状相同。因此，系统不是嵌入你的原始问题，而是嵌入这个虚构的段落并使用它进行搜索。 这就是**HyDE**，假设文档嵌入的缩写。虚构的答案在搜索运行的那一刻就被丢弃了。没有人会读它。 它唯一的工作是在向量空间中更接近真实答案的实际写法。它做到了。两段听起来像政策的文本比随意的问题更接近彼此。 真实的育儿假段落返回高匹配分数。不是因为AI知道答案。而是因为它知道如何听起来像一个答案。 查询转换以不同的方式解决同样的不匹配。它不是猜测一个答案，而是要求几种不同的方式来问同一个问题。 ## 4、查询转换 这种方法不是猜测单个假设答案，而是要求AI做一些更简单的事情：用几种不同的方式说同样的事情。 你将原始问题发送给AI，并给出这样的指令：使用不同的词汇生成这个问题的三个替代措辞。 它可能会返回： 1. "育儿假持续时间政策是什么？" 2. "产假或陪产假有多少周？" 3. "生育后的休假权利" 这些都没有丢弃原始问题的含义。这就是**查询转换**背后的核心思想：用足够多的不同方式说同一件事，其中一种方式很可能使用与真实答案相同的单词。 现在系统不是搜索一次。它分别嵌入所有三个变体，为每个变体运行搜索，然后合并结果并删除重复项。 看看变体一。它使用了确切的短语"育儿假"，与真实政策段落中的单词相同。即使你的原始问题从未接近到足以匹配，这个变体几乎肯定会匹配。 其他两个变体以不同的方式发挥作用。如果政策还有一段关于产假或陪产假的单独文档块，措辞又不同，变体二或变体三也可能捕获到它。你的原始问题完全会错过它。 一个问题进来，三种机会找到正确的单词。这就是查询转换所做的权衡：运行更多搜索，以换取更好的机会命中真实答案碰巧使用的任何措辞。 回退提示采用了相反的直觉。它不是以三种狭窄的方式问问题，而是首先问一个更广泛的问题。 ## 5、回退提示 这种方法不是专注于确切的措辞，而是缩小范围。这就是**回退提示**：在搜索之前，它向AI问一个不同类型的问题。这个问题背后隐藏着什么更大的问题？ 你将原始问题发送给AI，并给出这样的指令：这个特定问题背后更一般的问题是什么？ 它可能会返回类似这样的内容： > *"公司的员工休假政策是什么？"* 这比你实际问的问题要广泛得多。但它仍然相关。你关于育儿假的问题是休假政策这个更大主题的一个具体案例。 现在系统搜索两次：一次用你原始的、具体的问题，一次用这个更广泛的、回退的版本。然后它合并两个搜索找到的内容。 具体的搜索仍然找到育儿假段落，那个有26周的段落。但更广泛的搜索拉入了狭窄问题永远不会触及的内容。关于如何提前30天通过人力资源门户提交休假请求的一般文档块。 单独任何一个搜索都无法讲述完整的故事。狭窄的问题找到数字。广泛的问题找到周围的流程。结合起来，答案既涵盖了你获得多少时间，也涵盖了你实际如何申请它。 三种技术，三种对同一问题的不同重塑。真正的问题是选择哪一个，以及何时选择。 ## 6、选择哪一个？ 每种技术都解决了同一不匹配的略微不同的方面，所以正确的选择取决于实际出了什么问题。 如果你的问题很短，而真实答案的写法完全不同——冗长、正式、声明性——HyDE往往效果最好。它通过伪造已经听起来像来源的内容来填补这种风格上的差距。 如果不匹配确实是词汇问题——同一个想法的不同单词——查询转换是更直接的修复。更多的措辞意味着更多的机会，其中一种措辞与答案的实际写法对齐。 如果你的问题很狭窄，但答案需要周围的上下文才能理解，回退提示就派上用场了。它去寻找你的特定问题所在的大图景。 这些都不是非此即彼的选择。生产环境中的RAG管道通常同时运行多个，然后将合并的、更混乱的结果交给重排序器，以确定哪些文档块真正值得保留。 这种重塑就是这里的全部游戏：改变问题足够多，正确的文档块终于有机会被找到。 ## 7、结束语 某人输入的问题很少是应该被嵌入的问题，查询转换就是围绕这一观察建立的整个学科。无论你是伪造答案、增加措辞数量还是扩大范围，目标始终相同：在比较之前，给搜索提供一些更接近真实答案实际写法的内容。 这是一个小想法，但对你的RAG系统是感觉可靠还是只是运气不好有着巨大的影响。 --- 原文链接：[Query Transformation in RAG: Why Your Search Misses the Right Chunk](https://medium.com/@akshayvadsara/query-transformation-in-rag-why-your-search-misses-the-right-chunk-cdacc16aa7cc?source=home%5Ffor%5Fyou---------80-98--------------------e3a418a7%5F70f4%5F4139%5F9e3b%5Feba189ca5a9f-------15-------) 汇智网翻译整理，转载请标明出处 > **这是「RAG / 数据 / 文档智能」专题的一部分。**完整地图见：[RAG / 数据 / 文档智能完全指南](https://www.hubwiz.com/blog/rag-data-stack/)