高级 RAG 技术第 2 部分：查询和测试

从向量搜索到强大的 REST API，Elasticsearch 为开发人员提供了最全面的搜索工具包。探索 GitHub 上的示例笔记本，尝试新事物。您也可以立即开始免费试用或在本地运行 Elasticsearch。

所有代码都可以在 Searchlabs 软件仓库的 advanced-rag-techniques 分支中找到。

欢迎阅读我们关于高级 RAG 技术文章的第二部分！在本系列的第 1 部分中，我们建立、讨论并实施了高级 RAG 管道的数据处理组件：

在这一部分，我们将继续查询和测试我们的实现。让我们直奔主题！

搜索和检索，生成答案

让我们提出第一个问题，最好是主要在年度报告中找到的一些信息。怎么样？

现在，让我们运用一些技术来增强查询。

用同义词丰富查询

首先，让我们增强查询措辞的多样性，并将其转化为可轻松处理成 Elasticsearch 查询的形式。我们将借助 GPT-4o 将查询转换为 OR 子句列表。让我们来写下这个提示：

当应用到我们的查询时，GPT-4o 会生成基本查询和相关词汇的同义词。

在ESQueryMaker 类中，我定义了一个分割查询的函数：

它的作用是将这串 OR 子句拆分成一个术语列表，使我们能够对关键文档字段进行多重匹配：

最后得出了这个疑问：

这比原始查询涵盖的范围更广，有望降低因忘记同义词而错过搜索结果的风险。但我们可以做得更多。

返回顶部

HyDE（假设文档嵌入）

让我们再次利用 GPT-4o 来实现HyDE。

HyDE 的基本前提是生成一个假设文档--一种可能包含原始查询答案的文档。文件的真实性或准确性并不重要。有鉴于此，让我们写下下面的提示：

由于矢量搜索通常是通过余弦矢量相似性进行操作的，因此 HyDE 的前提是，我们可以通过文档与文档的匹配，而不是查询与文档的匹配，来获得更好的结果。

我们关心的是结构、流程和术语。事实性不强。GPT-4o 可以输出这样的 HyDE 文档：

它看起来非常可信，是我们希望索引的文档类型的理想候选者。我们将把它嵌入并用于混合搜索。

返回顶部

混合搜索

这是我们搜索逻辑的核心。我们的词法搜索组件将是生成的 OR 子句字符串。我们的密集矢量组件将是嵌入式 HyDE 文档（又称搜索矢量）。我们使用 KNN 来有效识别与搜索向量最接近的几个候选文档。我们将词法搜索组件默认称为TF-IDF 和 BM25 评分。最后，将采用Wang 等人推荐的 30/70 比例合并词性和密集向量得分。

最后，我们可以拼凑出一个 RAG 函数。我们的 RAG（从询问到答复）将遵循这一流程：

将查询转换为 OR 子句。
生成 HyDE 文档并嵌入。
将二者作为混合搜索的输入。
检索前 N 个结果，将它们倒转，使最相关的得分是 LLM 上下文内存中"最近的" （反向打包）反向打包示例：查询："Elasticsearch 查询优化技术" 检索文档（按相关性排序）： LLM 上下文的反向顺序：通过颠倒顺序，最相关的信息(1)会出现在上下文的最后，从而可能在生成答案时受到 LLM 的更多关注。
1. "使用 bool 查询可有效组合多个搜索条件。"
2. "实施缓存策略，缩短查询响应时间。"
3. "优化索引映射，提高搜索性能。"
4. "优化索引映射，提高搜索性能。"
5. "实施缓存策略，缩短查询响应时间。"
6. "使用 bool 查询可有效组合多个搜索条件。"
将上下文传递给 LLM 生成。

让我们运行查询并得到答案：

不错。没错。

返回顶部

实验

现在有一个重要问题需要回答。我们在这些实施中投入了如此多的精力和额外的复杂性，究竟得到了什么？

让我们来做个小小的比较。我们实施的 RAG 管道与基线混合搜索相比，没有任何增强功能。我们将进行一系列小测试，看看是否会发现任何实质性差异。我们将把刚刚实现的 RAG 称为 AdvancedRAG，把基本管道称为 SimpleRAG。

结果摘要

本表总结了两种 RAG 管道的五次测试结果。我根据答案的细节和质量来判断每种方法的相对优劣，但这完全是主观判断。现将实际答案转载于下表，供您参考。说了这么多，让我们来看看他们的表现如何！

SimpleRAG 无法回答问题 1& 5。AdvancedRAG 对问题 2、3 和 4 的回答也要详细得多。基于更多的细节，我认为 AdvancedRAG 的答案质量更高。

测试	问题	高级 RAG 性能	SimpleRAG 性能	AdvancedRAG 延迟	SimpleRAG 延迟	优胜者
1	谁审核 Elastic？	正确确定普华永道为审计员。	未能确定审计员。	11.6s	4.4s	AdvancedRAG
2	2023 年的总收入是多少？	提供了正确的收入数字。包括往年收入的补充情况。	提供了正确的收入数字。	13.3s	2.8s	AdvancedRAG
3	增长主要依靠什么产品？多少钱？	正确指出弹性云是关键驱动因素。包括总体收入情况& 。	正确指出弹性云是关键驱动因素。	14.1s	12.8s	AdvancedRAG
4	说明员工福利计划	全面介绍了退休计划、医疗计划和其他福利。包括不同年份的具体捐款额。	提供了很好的福利概览，包括薪酬、退休计划、工作环境和 Elastic Cares 计划。	26.6s	11.6s	AdvancedRAG
5	Elastic 收购了哪些公司？	正确列出了报告中提到的近期收购（CmdWatch、Build Security 和 Optimyze）。提供了一些收购日期和收购价格。	未能从提供的上下文中检索到相关信息。	11.9s	2.7s	AdvancedRAG

测试 1：谁审核了 Elastic？

AdvancedRAG

SimpleRAG

摘要：SimpleRAG 没有将普华永道确定为审计机构

好吧，这其实挺让人惊讶的。这看起来像是 SimpleRAG 的搜索失败。没有检索到与审计有关的文件。让我们在下一个测试中降低难度。

测试 2：2023 年总收入

AdvancedRAG

SimpleRAG

摘要：两个 RAG 都得到了正确答案：2023 年总收入为 1,068,989,000 美元

他们都在这里。看来，AdvancedRAG 可能获得了更多的文件？当然，答案会更加详细，并包含往年的信息。考虑到我们所做的改进，这是意料之中的，但现在下结论还为时过早。

让我们提高难度。

测试 3：增长主要依赖于什么产品？多少钱？

AdvancedRAG

SimpleRAG

摘要：两个 RAG 都正确地将弹性云确定为主要增长动力。不过，AdvancedRAG 包含更多细节，将订阅收入和客户增长考虑在内，并明确提及其他 Elastic 产品。

测试 4：说明员工福利计划

AdvancedRAG

SimpleRAG

摘要：AdvancedRAG 更深入、更详细地介绍了美国员工的 401K 计划，以及美国以外地区的缴费计划。报告还提到了 "健康与福利计划"，但没有提到 SimpleRAG 提到的 "Elastic Cares 计划"。

测试 5：Elastic 收购了哪些公司？

AdvancedRAG

SimpleRAG

摘要：SimpleRAG 无法检索到任何有关收购的相关信息，导致回答失败。AdvancedRAG 正确地列出了 CmdWatch、Build Security 和 Optimyze，它们是报告中列出的主要收购项目。

返回顶部

结论

根据我们的测试，我们的先进技术似乎增加了所提供信息的范围和深度，有可能提高 RAG 答案的质量。

此外，可靠性也可能有所提高，因为 AdvancedRAG 可以正确回答Which companies did Elastic acquire? 和Who audits Elastic 等措辞含糊的问题，而 SimpleRAG 则不能。

不过，值得注意的是，在 5 个案例中的 3 个案例中，基本的 RAG 管道（包括混合搜索，但不包括其他技术）设法得出了能够捕捉到大部分关键信息的答案。

我们应该注意到，由于在数据准备和查询阶段加入了 LLM，AdvancedRAG 的延迟一般是 SimpleRAG 的 2-5 倍。这是一笔不小的费用，可能使 AdvancedRAG 只适用于优先考虑应答质量而不是延迟的情况。

在数据准备阶段，使用 Claude Haiku 或 GPT-4o-mini 等更小巧、更便宜的 LLM，就能减轻巨大的延迟成本。将高级模型留待生成答案时使用。

这与 Wang 等人的研究结果一致。结果表明，任何改进都是相对渐进的。简而言之，简单的基线 RAG 就能让您获得大部分体面的最终产品，而且成本更低，速度更快。对我来说，这是一个有趣的结论。对于速度和效率至关重要的使用案例，SimpleRAG 是明智的选择。对于需要榨取每一滴性能的使用案例，AdvancedRAG 中包含的技术可能会提供一条出路。