理解 RAG 第 V 部分：管理上下文长度
图片由 Editor | Midjourney & Canva 提供
请务必查看本系列的上一篇文章
传统的大型语言模型（LLMs）存在上下文长度限制，这是它们的主要局限性之一，限制了在单次用户-模型交互中可以处理的信息量。解决这一限制一直是 LLMs 开发社区的主要关注点之一，提高了增加上下文长度在产生更连贯和准确的响应方面的优势的认识。例如，2020 年发布的 GPT-3 的上下文长度为 2048 个 token，而它年轻但功能更强大的同类产品 GPT-4 Turbo（2023 年发布）在单个提示中允许高达 128K 个 token。毋庸置疑，这相当于能够一次交互处理整本书，例如对其进行摘要。
另一方面，检索增强生成（RAG）通过从检索到的文档（通常是向量数据库）中获取外部知识来增强 LLM 输出的上下文和相关性。然而，在 RAG 系统中管理上下文长度仍然是一个挑战，因为在某些需要大量上下文信息的场景中，需要高效地选择和摘要检索到的信息，以便在不丢失关键知识的情况下保持在 LLM 的输入限制之内。
RAG 中长上下文管理策略
RAG 系统有几种策略，可以在将信息传递给 LLM 之前，将尽可能多的相关检索知识整合到初始用户查询中，并保持在模型的输入限制内。以下从最简单到最复杂的四种策略：
1. 文档分块
文档分块通常是最简单的策略，它侧重于将向量数据库中的文档分割成更小的块。虽然乍一看可能并不明显，但该策略通过多种方式帮助克服 RAG 系统中 LLM 的上下文长度限制，例如降低检索冗余信息的风险，同时保持块中的上下文完整性。
2. 选择性检索
选择性检索包括对大量相关文档应用过滤过程，只检索最相关部分，从而缩小传递给 LLM 的输入序列的大小。通过智能地过滤要保留的检索文档的部分，其目标是避免包含不相关或无关紧要的信息。
3. 定向检索
虽然与选择性检索相似，但定向检索的本质是怀着非常具体的目标或最终响应来检索数据。这是通过优化检索器机制以适应特定类型的查询或数据源来实现的，例如为医学文本、新闻文章、最新科学突破等构建专门的检索器。简而言之，它是一种进化的、更专业的选择性检索形式，并增加了领域特定的标准。
4. 上下文摘要
上下文摘要是 RAG 系统中管理上下文长度的一种更复杂的实现方式，在该方式中，我们在构建最终上下文的过程中应用文本摘要技术。一种可能的方法是使用另一个语言模型——通常更小且经过摘要任务的训练——来摘要检索到的文档的大块内容。此摘要任务可以是提取式或生成式，前者识别并提取相关的文本片段，后者则从头开始生成摘要，重述和浓缩原始块。或者，一些 RAG 解决方案使用启发式方法来评估文本块（例如，片段）的相关性，丢弃不相关的部分。
| 策略 | 总结 |
|---|---|
| 文档分块 | 将文档分割成更小、更连贯的块，以保留上下文，同时减少冗余并保持在 LLM 限制之内。 |
| 选择性检索 | 过滤大量相关文档，只检索最相关的部分，最大限度地减少无关信息。 |
| 定向检索 | 使用专门的检索器优化特定查询意图的检索，并添加领域特定的标准来完善结果。 |
| 上下文摘要 | 使用提取式或生成式摘要技术来压缩大量检索到的内容，确保将关键信息传递给 LLM。 |
长上下文语言模型
那长上下文 LLM 呢？这样不是就足够了吗，还需要 RAG 吗？
这是一个需要解决的重要问题。长上下文 LLM（LC-LLMs）是“超大型”LLM，能够接受非常长的输入 token 序列。尽管研究表明 LC-LLMs 通常优于 RAG 系统，但后者仍然具有特定的优势，尤其是在需要动态实时信息检索和成本效益的场景中。在这些应用中，值得考虑使用一个封装在 RAG 系统中的小型 LLM（该系统使用上述策略），而不是 LC-LLM。这些都不是万能的解决方案，它们都将在适合它们的特定环境中发挥作用。
总结
本文介绍了 RAG 系统中管理上下文长度的四种策略，以及在这些系统中的 LLM 在单次用户交互中可能存在输入长度限制的情况下处理长上下文的方法。虽然使用所谓的长上下文 LLM（Long-Context LLMs）来克服这个问题已成为一种趋势，但在某些情况下，坚持使用 RAG 系统仍然是值得的，特别是在需要实时最新上下文的动态信息检索场景中。
暂无评论。