增强 Haystack 中的 RAG 流水线：引入 DiversityRanker 和 LostInTheMiddleRanker

就在几年前，自然语言处理（NLP）和长文本问答（LFQA）领域的最新进展听起来还像是科幻小说。谁能想到，如今我们拥有的系统能够以专家般的精确度回答复杂问题，同时还能从海量来源中实时整合出答案？LFQA 是一种检索增强生成（RAG）技术，它利用大语言模型（LLM）的最佳检索和生成能力，近期已取得了显著进展。

但如果我们能进一步优化这种配置呢？如果我们能优化 RAG 选择和利用信息的方式以提升性能呢？本文基于最新研究和我们的经验，介绍了两种旨在通过 LFQA 具体示例来改进 RAG 的创新组件——DiversityRanker 和 LostInTheMiddleRanker。

将 LLM 的上下文窗口视为一道美味佳肴，其中每个段落都是一种独特且美味的配料。正如烹饪杰作需要多样化、高质量的食材一样，LFQA 问答同样需要一个充盈着高质量、多样化、相关且不重复的段落的上下文窗口。

在 LFQA 和 RAG 的复杂世界中，最大限度地利用 LLM 的上下文窗口至关重要。任何浪费的空间或重复的内容都会限制我们提取和生成答案的深度与广度。合理安排上下文窗口的内容是一种微妙的平衡艺术。本文提出了掌握这种平衡的新方法，这将增强 RAG 提供精确、全面响应的能力。

让我们探索这些令人兴奋的进展，以及它们如何改进 LFQA 和 RAG。

背景

Haystack 是一个开源框架，为实际的 NLP 构建者提供端到端的解决方案。它支持从问答和语义文档搜索一直到 LLM 代理等多种用例。其模块化设计允许集成先进的 NLP 模型、文档存储以及现代 NLP 工具箱中所需的各种其他组件。

Haystack 的核心概念之一是“流水线”（pipeline）。流水线代表了特定组件执行的一系列处理步骤。这些组件可以执行各种类型的文本处理，用户只需定义数据在流水线中的流动方式以及执行处理步骤的节点顺序，即可轻松创建强大且可定制的系统。

流水线在基于 Web 的长文本问答中起着至关重要的作用。它以 WebRetriever 组件开始，该组件从 Web 上搜索并检索与查询相关的文档，自动将 HTML 内容剥离为原始文本。但在获取到相关文档后，我们该如何充分利用它们？如何填充 LLM 的上下文窗口以最大化答案质量？如果这些文档虽然高度相关，但却存在重复且数量过多，有时甚至超出了 LLM 的上下文窗口，该怎么办？

这就是我们今天要介绍的组件——DiversityRanker 和 LostInTheMiddleRanker 发挥作用的地方。它们的目的是解决这些挑战，并改进由 LFQA/RAG 流水线生成的答案。

DiversityRanker 增强了为上下文窗口选择的段落的多样性。LostInTheMiddleRanker 通常放置在流水线中 DiversityRanker 的后面，有助于缓解当模型必须访问长上下文窗口中间的相关信息时所观察到的 LLM 性能下降问题。接下来的章节将深入探讨这两个组件，并展示它们在实际用例中的有效性。

DiversityRanker

DiversityRanker 是一种新颖的组件，旨在增强 RAG 流水线中为上下文窗口选择的段落的多样性。它的运作原则是：多样化的文档集可以提高 LLM 生成具有更高广度和深度的答案的能力。

DiversityRanker 使用句子转换器（sentence transformers）来计算文档之间的相似度。Sentence-transformers 库为创建句子、段落甚至整个文档的有意义表示提供了强大的嵌入模型。这些表示（即嵌入）捕获了文本的语义内容，使我们能够衡量两段文本的相似程度。

DiversityRanker 使用以下算法处理文档：

它首先使用句子转换器模型计算每个文档和查询的嵌入。
然后，它选择语义上最接近查询的文档作为第一个选定的文档。
对于每个剩余的文档，它计算其与已选定文档的平均相似度。
然后，它选择与已选定文档平均相似度最低的那个文档。
此选择过程持续进行，直到所有文档都被选中，从而得到一个按贡献度从高到低排列的文档列表。

需要注意的一个技术细节是：DiversityRanker 使用贪心局部方法来按顺序选择下一个文档，这可能无法找到文档的最优总体顺序。DiversityRanker 更侧重于多样性而非相关性，因此应将其放置在流水线中 TopPSampler 或其他更侧重于相关性的相似度排序器之后。通过在选择了最相关文档的组件之后使用它，我们确保可以从一组已经相关的文档中挑选出多样化的内容。

LostInTheMiddleRanker

LostInTheMiddleRanker 优化了所选文档在 LLM 上下文窗口中的布局。该组件旨在解决近期研究 [1] 中发现的一个问题，即 LLM 在处理长上下文中间的相关段落时表现不佳。LostInTheMiddleRanker 交替将最佳文档放置在上下文窗口的开头和结尾，使 LLM 的注意力机制能够轻松访问和使用它们。要了解 LostInTheMiddleRanker 如何对给定文档进行排序，请想象一个简单的例子，文档由 1 到 10 的单个数字按升序组成。LostInTheMiddleRanker 会将这十个文档按以下顺序排列：[1 3 5 7 9 10 8 6 4 2]。

尽管该研究的作者专注于问答任务（从文本中提取答案的相关片段），但我们推测，在生成答案时，LLM 的注意力机制在处理位于上下文窗口开头和结尾的段落时也会更加轻松。

Figure 2. LLMs struggle to extract answers from the middle of the context, adapted from Liu et al. (2023)[1] — 图 2. LLM 难以从上下文中间提取答案（改编自 Liu et al. (2023)[1]）

LostInTheMiddleRanker 最适合作为 RAG 流水线中的最后一个排序器，因为给定的文档已经基于相似度（相关性）进行了选择，并按多样性进行了排序。

在流水线中使用新的排序器

在本节中，我们将探讨 LFQA/RAG 流水线的实际用例，重点介绍如何集成 DiversityRanker 和 LostInTheMiddleRanker。我们还将讨论这些组件如何与流水线中的其他组件进行交互。

流水线中的第一个组件是 WebRetriever，它使用程序化搜索引擎 API（SerperDev、Google、Bing 等）从 Web 上检索与查询相关的文档。检索到的文档首先被剥离 HTML 标签，转换为原始文本，并可选择预处理成更短的段落。然后，它们依次传递给 TopPSampler 组件，该组件根据与查询的相似度选择最相关的段落。

在 TopPSampler 选择了一组相关段落后，它们被传递给 DiversityRanker。DiversityRanker 反过来根据段落的多样性对它们进行排序，从而减少 TopPSampler 排序文档的重复性。

所选文档随后被传递给 LostInTheMiddleRanker。正如我们之前提到的，LostInTheMiddleRanker 将最相关的段落放置在上下文窗口的开头和结尾，同时将排名最差的文档推向中间。

最后，合并后的段落被传递给 PromptNode，它会根据这些选定的段落来引导 LLM 回答问题。

Figure 3. LFQA/RAG pipeline - Image by author — 图 3. LFQA/RAG 流水线 – 图片由作者提供

新的排序器已经合并到 Haystack 的主分支中，并将包含在预计于 2023 年 8 月底发布的 1.20 版本中。我们在项目的示例文件夹中包含了一个新的 LFQA/RAG 流水线演示。

该演示展示了 DiversityRanker 和 LostInTheMiddleRanker 如何轻松集成到 RAG 流水线中，以提高生成答案的质量。

案例研究

为了证明包含这两个新排序器的 LFQA/RAG 流水线的有效性，我们将使用一小部分需要详细解答的问题。这些问题包括：“俄罗斯与波兰之间长期敌对的主要原因是什么？”、“全球和地方层面的气候变化的主要原因是什么？”等等。为了很好地回答这些问题，LLM 需要广泛的历史、政治、科学和文化来源，这使它们成为我们用例的理想选择。

比较 RAG 流水线（包含两个新排序器的优化流水线）与不包含它们的流水线（非优化）生成的答案，需要涉及人类专家判断的复杂评估。为了简化评估并主要评估 DiversityRanker 的效果，我们计算了注入 LLM 上下文的上下文文档的平均成对余弦距离。我们将两个流水线中的上下文窗口大小限制为 1024 个单词。通过运行这些示例 Python 脚本 [2]，我们发现优化后的流水线在注入 LLM 上下文的文档的平均成对余弦距离上增加了 20–30% [3]。成对余弦距离的这种增加本质上意味着所使用的文档更加多样化（且重复性更低），从而为 LLM 提供了更广泛、更丰富的段落来源来构建其答案。我们将把对 LostInTheMiddleRanker 及其对生成答案的影响的评估留给以后的文章。