ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;margin: 1.5em 8px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">导读：Databricks 最新研究表明，长上下文可以提高增强生成技术 (RAG) 的准确性，但并非越长越好。不同 LLM 模型在长上下文处理中表现出独特的性能瓶颈和失败模式。开发者需要根据具体的模型和任务需求，找到最合适的上下文长度，才能最大限度地发挥 RAG 应用的性能优势。
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;margin: 1.5em 8px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">增强生成技术 (RAG) 作为一种强大的 AI 应用，它巧妙地结合了信息检索和文本生成，为大型语言模型（LLM）插上了知识的翅膀。近年来，随着 Anthropic Claude (200k 上下文长度)、GPT-4-turbo (128k 上下文长度) 和 Google Gemini 1.5 pro (200 万上下文长度) 等能够处理超长上下文的 LLM 的问世，关于长上下文 LLM 能否最终取代 RAG 的讨论愈演愈烈。
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;margin: 1.5em 8px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">支持者认为，超长上下文 LLM 能够将海量知识囊括其中，使 RAG 的检索环节显得多此一举。毕竟，如果 LLM 能够直接访问所有相关信息，为什么还要费力地进行检索呢？
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;margin: 1.5em 8px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">然而，反对者则坚信 RAG 依然不可或缺。他们指出，RAG 能够提供更精准、更可控的信息检索能力，避免 LLM 在浩瀚的知识海洋中“迷失方向”。更重要的是，现有的研究表明，LLM 在处理长文本时存在着“迷失中间”问题和有效上下文长度受限等问题，这使得单纯依靠长上下文 LLM 来解决所有问题变得不切实际。
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;margin: 1.5em 8px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">为了探寻真相，Databricks 对 13 种主流 LLM 进行了全面测试，涵盖 Databricks DocsQA、FinanceBench、Natural Questions (NQ) 和 HotpotQA 四个数据集，并发布了长上下文对 RAG 性能影响的深度分析报告，为开发者和研究者提供了宝贵的参考。
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;margin: 1.5em 8px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">Databricks 的分析结果首先证实了一个直观的结论：对于 RAG 应用而言，检索更多文档确实能够提高答案的准确性。
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;margin: 1.5em 8px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">想象一下，当你需要回答一个复杂问题时，如果能够参考更多相关的资料，是不是更有可能找到正确答案呢？LLM 也是如此。上下文窗口越大，能够容纳的文档就越多，LLM 就越有可能找到正确答案所需的关键信息。
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;margin: 1.5em 8px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">Databricks 的分析表明，随着检索文档数量的增加，召回率也随之提高，这意味着 LLM 能够获取更多相关信息，从而提高答案的准确性。 例如，在 NQ 数据集中，当上下文长度从 2k 扩展到 8k 时，召回率从 0.845 提升至 1.0，这意味着模型能够检索到所有相关文档。
[表格1：OpenAI text-embedding-3-large 嵌入模型在 4 个数据集上不同上下文长度下的召回率]
性能并非无限增长：上下文长度的甜蜜点 然而，Databricks 也发现，长上下文并非多多益善，LLM 的性能并非随着上下文长度的增加而无限增长。超过一定长度后，性能反而会停滞不前，甚至出现下降趋势。
这就好比一个人同时阅读多本书，当书的数量超过一定限度时，他反而无法有效地吸收所有信息。LLM 也面临着类似的问题。当上下文窗口过大时，LLM 可能会难以有效地处理和整合所有信息，导致性能下降。
如图 1 所示，不同 LLM 模型在不同数据集上的性能表现都呈现出先上升后平稳或下降的趋势。例如，Llama-3.1-405b 的性能在 32k 标记后开始下降，GPT-4-0125-preview 的性能在 64k 标记后开始下降。只有少数模型，比如 GPT-4o、Claude-3.5-sonnet 和 GPT-4o-mini，能够在较长的上下文长度下保持性能稳定。
图1：不同 LLM 模型在 4 个精选 RAG 数据集上的长上下文性能表现
这意味着开发者需要根据具体的模型和任务需求，找到最合适的上下文长度，才能最大限度地发挥 RAG 应用的性能优势。
长上下文 LLM 的失败模式：知己知彼，方能百战不殆 除了性能饱和问题之外，Databricks 还揭示了不同 LLM 模型在长上下文处理中存在的独特失败模式。这些失败模式就像 LLM 的“阿喀琉斯之踵”，了解它们对于打造高效 RAG 应用至关重要。
商业模型：能力越大，责任越大 图2：GPT-4 在不同上下文长度下对 NQ 数据集的性能表现
图3：Claude 3 Sonnet 在不同上下文长度下对 NQ 数据集的性能表现
开源模型：各有所长，也各有短板 •Llama-3.1-405b : 与 GPT-4 类似，Llama-3.1-405b 也存在提供错误答案的倾向，这可能与其训练数据集的质量和规模有关。例如，在回答“《进击的巨人》第二季有多少集？”这个问题时，Llama-3.1-405b 错误地将正确答案“12”识别为“25”。
•Mixtral-instruct : Mixtral-instruct 容易输出重复或随机内容，这可能是因为模型在处理长文本时难以保持连贯性和逻辑性，导致其生成的内容缺乏意义。例如，在回答“谁写了《物种起源》这本书？”这个问题时，Mixtral-instruct 输出了一连串重复的“梦”字。
•DBRX-instruct : DBRX-instruct 则倾向于概括内容而不是直接回答问题，这可能是因为模型在训练过程中更注重于理解和总结文本的整体内容，而不是提取特定信息。例如，在回答“2014 年世界杯的最佳射手是谁？”这个问题时，DBRX-instruct 提供了关于世界杯最佳射手榜的描述，而不是直接给出答案“James Rodríguez”。
Databricks 的建议：如何打造高效 RAG 应用？ Databricks 的研究结果为开发者提供了打造高效 RAG 应用的宝贵 insights。
首先，开发者需要根据 LLM 模型和任务需求选择合适的上下文长度，找到性能与效率的平衡点。过短的上下文窗口会导致信息缺失，而过长的上下文窗口则会导致性能下降和资源浪费。
其次，开发者需要利用评估工具持续监测 RAG 系统的性能表现，及时发现并解决问题。例如，可以使用 Databricks 提供的 Mosaic AI Agent Framework 和 Agent Evaluation 工具来评估 RAG 系统的性能和稳定性。
最后，开发者需要关注 LLM 模型的长上下文训练和架构优化，为 RAG 应用提供更强大的性能支持。例如，可以使用 LongAlign 等方法来训练 LLM 模型，使其能够更好地处理长文本
