处理大规模检索数据集时的长上下文

随着分布式检索增强生成（RAG）系统接收并处理文档语料库，大型语言模型（LLM）经常面临大量检索到的信息。尽管现代LLM拥有越来越大的上下文窗口，但简单地将这些窗口填满通常并非最佳做法，并可能带来显著的操作和性能问题。因此，有效处理来自大规模检索数据集的长上下文，是优化这些系统中LLM的一个主要内容。这不仅仅是将数据放入模型中；它需要复杂的策略，以确保LLM接收到最相关的信息，并以易于理解的形式呈现，同时平衡信息的全面性与计算效率和响应质量。

核心问题在于LLM有限的处理能力，无论是就令牌限制而言，还是就其从噪声中识别重要信息的能力而言。简单地连接大量检索到的文档可能导致以下问题：

• 信息稀释： 重要信息可能在不那么相关的内容中丢失或被忽略。
• 延迟和成本增加： 处理更长的上下文直接意味着更高的推理时间和计算费用。
• “中间丢失”问题： 某些LLM在回忆或使用位于极长上下文中间的信息时表现出性能下降。
• 幻觉加剧： 用嘈杂或仅略微相关的数据淹没LLM有时会增加生成与所提供上下文不符响应的可能性。

应对这些挑战需要多方面的方法，侧重于如何选择、组织上下文并将其呈现给LLM。

策略性上下文构建

与其将LLM的上下文窗口视为被动接收器，不如说专业的RAG实践者会主动地设计上下文。这包括几种技术：

1. 文档重新排序与优先级设置

检索到的信息呈现的顺序能明显影响LLM的性能。为抵消“中间丢失”效应，通常有利的做法是将最相关的文档或文本块放置于上下文的开头或末尾。

• 相关性排序： 使用检索分数（例如，来自向量相似度、BM25或重排序器）来排序文档。
• 混合方法： 在重新排序逻辑中考虑来源可信度、时效性或其他元数据。例如，一份高度相关但较旧的文档可能会被放置在一份相关性稍低但很新的文档之后，具体取决于查询的性质。

2. LLM前上下文压缩与摘要

对于极大规模的检索文档集，喂入完整文本可能不切实际。取而代之的是，中间处理步骤可以提炼信息：

• 抽取式摘要： 从每份文档中选取重要句子或段落。这种方式计算成本较低，但可能遗漏细节。
• 抽象式摘要： 使用较小、专门的LLM为每份主要文档或相关文档群生成简洁摘要。这种方式可能更具连贯性，但会增加计算开销，并可能增加信息丢失或更改的风险。
• 对文本块进行问答： 如果总体任务是问答，可以首先向检索数据的较小片段提出主要问题（或子问题），然后将这些中间答案综合成最终上下文，供主要LLM使用。

下面的图表显示了一种分层方法，在此方法中，来自大规模检索集中的单个文档首先被处理或摘要，然后再组合成一个更易于管理、供主要LLM使用的上下文。

一种分层处理流程，用于处理大规模检索数据集。每份文档（或文档组）都经过初步的处理或摘要步骤。然后将输出结果汇集起来，为主要LLM形成上下文。

3. “焦点窗口”或“提炼”技术

当检索到的上下文信息量极大时，可以为LLM构建一个更小、高度相关的“焦点窗口”。这包括积极地只选择最重要的数据片段。这可以与允许LLM在初始焦点窗口不足时“请求”更多细节或“放宽视野”到更广泛上下文的机制相结合，这种技术接近代理RAG行为。

运用LLM架构应对扩展上下文

选择LLM以及了解其架构优势和劣势也是长上下文管理的一部分。

1. 原生长上下文模型

一些LLM专门设计用于更高效地处理更长的序列。这些模型通常采用优化的注意力机制（例如FlashAttention、稀疏注意力变体）或其他架构创新，以减少标准Transformer注意力机制的二次复杂度。 尽管这些模型提供更大的原始令牌限制（例如32k、128k、200k甚至1M+令牌），但需要记住的是：

• 成本与延迟： 使用这些模型的完整上下文窗口仍然计算密集。上下文长度、延迟和成本之间的关系通常是非线性的，常表现出超线性增长。
• 上下文有效使用： 更大的窗口并不能自动保证模型会有效使用其中的所有信息。“大海捞针”评估有助于了解特定模型的能力。

下面的图表显示了推理延迟和相对成本可能随上下文长度增加的普遍趋势。具体数字是示例性的，并因模型和硬件而异。

LLM上下文长度、推理延迟和相对运营成本之间的示例性关系。随着上下文长度增加，延迟和成本都倾向于明显上升。

2. 分层与Map-Reduce式处理

对于可分解的任务，map-reduce模式可以高效。

• Map（映射）： 将LLM（或更简单的模型）应用于单个文档或大型文本块，以提取特定信息、回答子问题或生成摘要。
• Reduce（归约）： 使用另一个LLM调用综合“映射”阶段的输出，以生成最终答案。这种方法将一个大的上下文问题分解为更小、易于处理的部分。

动态上下文管理与截断

当精心整理的上下文仍然超出LLM的实际限制时，截断是必需的。然而，简单的截断（在令牌限制处切断文本）通常并非最佳做法。

1. 智能截断

• 保持文档完整性： 避免在句子或段落中间截断。在自然边界处截断。
• 分段感知截断： 如果文档具有结构（例如，摘要、引言、结论），优先保留信息量更大的部分。
• 令牌预算感知选择： 实施明确管理“令牌预算”的逻辑，选择和安排文本块或摘要，使其在此预算内最佳适配，同时最大限度地提升信息价值。这通常涉及根据相关性迭代检索到的文档，将其内容（或摘要）添加到上下文中，直到预算几乎用尽。

2. 带记忆的滑动窗口

对于处理极长单个文档或在持续对话RAG系统中保持上下文，可以使用滑动窗口方法。

• LLM处理文档/对话的一个片段。
• 当新信息加入时，旧信息会滑出活动上下文窗口。
• 为避免过去信息的完全丢失，可以生成“被遗忘”片段的摘要，并将其添加到新窗口的开头，作为一种浓缩的记忆。

对系统性能和质量的影响

有效长上下文管理直接影响分布式RAG系统的几个重要方面：

• 延迟： 更短、更集中的上下文会带来更快的LLM推理。上述策略旨在减少令牌数量，而不牺牲过多必要信息。
• 计算成本： LLM处理的令牌越少，意味着计算成本越低，这是大规模部署中的一个重要因素。
• 生成质量： 首要目标是提升LLM输出的质量。
  • 减少噪声： 通过过滤掉不那么相关的信息，LLM可以更好地专注于有效信号。
  • 提升连贯性： 结构良好的上下文有助于LLM生成更具连贯性和逻辑性的响应。
  • 减轻幻觉： 提供更清晰、更相关的基础数据可以减少LLM生成无依据陈述的倾向。反之，管理不善、嘈杂的长上下文有时会通过信息过载模型而增加幻觉。

长上下文的进阶考量

几个进阶要点与专业实践者相关：

1. “大海捞针”评估

通过经验评估您选择的LLM和上下文管理策略能多好地识别并使用嵌入在长上下文（“干草堆”）中的特定信息（“针”）是重要的。这涉及创建合成测试用例，已知事实被放置在长文档内的不同位置，然后查询RAG系统，看它是否能检索并使用该事实。此类测试的结果可以为模型选择和上下文工程决策提供信息。

2. 上下文边界与信息分割

当多个文档或来源组合成单个上下文时，明确划分这些来源可能有利。这可能涉及使用特殊分隔符令牌或结构化格式（例如，类似XML的标签、Markdown），以帮助LLM区分来自不同来源的信息。这可以防止“信息混淆”，即一个文档的属性或事实被错误地关联到另一个文档。

3. 对查询类型的适应性

最佳上下文长度和构成可以根据用户查询的性质而变化。

• 特定事实查询： 可能受益于包含精确答案的更短、高度集中的上下文。
• 摘要或比较查询： 可能需要包含多个观点或文档的更广泛上下文。 RAG系统可以包含逻辑，根据查询分析动态调整上下文构建策略。

在分布式RAG中管理长上下文并非一概而论的问题。它需要充分理解LLM的行为、对输入LLM的数据管道进行细致的工程设计以及持续评估。通过策略性地整理、压缩和组织检索到的信息，工程师可以大幅提升大规模RAG系统的性能、效率和可靠性，确保LLM组件即使面对大量数据也能最佳运行。