导读：Databricks 的最新研究给出了一个既令人振奋又带点警示的结论——长上下文确实能提升 RAG（增强生成技术）的准确性，但别指望“越长越好”。不同模型在处理长文本时，各有各的“死xue”和性能瓶颈。对开发者来说，关键是根据手头的模型和实际任务，找到那个恰到好处的上下文长度，才能把 RAG 应用的性能潜力榨干。

长上下文 LLM：RAG 应用的未来？

RAG 这种 AI 应用之所以强大，是因为它把信息检索和文本生成合二为一，等于给大型语言模型（LLM）装上了一双知识的翅膀。最近，Anthropic Claude（200k 上下文）、GPT-4-turbo（128k 上下文）、Google Gemini 1.5 Pro（200 万上下文）这些能处理超长文本的模型接连问世，一个老话题又被翻了出来：长上下文 LLM 迟早会干掉 RAG 吧？

支持者们的逻辑很简单：既然 LLM 能一口气吞下海量知识，那 RAG 的检索环节不就多此一举了吗？何必还费劲去搜来搜去？

但反对者也有充分的理由。他们强调 RAG 依然不可或缺，因为它能提供更精准、更可控的信息检索，避免 LLM 在信息的汪&洋大海里“迷失方向”。更何况，现有的研究已经暴露了 LLM 的两个老毛病：一是“迷失在中间”，二是有效上下文长度其实很有限。想单靠长上下文 LLM 包打天下，显然不现实。

为了搞清楚真相，Databricks 一口气测试了 13 种主流 LLM，在 Databricks DocsQA、FinanceBench、Natural Questions（NQ）和 HotpotQA 四个数据集上做了全面评估，并发布了一份深度分析报告。这份报告对开发者和研究者的参考价值，可以说相当高。

更多文档，更高准确性：长上下文 LLM 的天然优势

分析结果首先验证了一个直觉上的判断：对 RAG 应用来说，检索的文档越多，答案的准确性确实越高。

不妨这么理解：当你回答一个复杂问题时，如果能参考更多相关材料，是不是找到正确答案的概率更大？LLM 也一样。上下文窗口越大，能塞进去的文档就越多，它找到关键信息的机会自然也就越大。

数据也证实了这一点。随着检索文档数量增加，召回率明显提升，这意味着 LLM 能获取到更多相关信息，最终答案的准确性自然水涨船高。

举个例子，在 Natural Questions（NQ）数据集上，当上下文长度从 2k 扩展到 8k 时，召回率从 0.845 直接拉到了 1.0——所有相关文档都被模型一网打尽了。

[表格1：OpenAI text-embedding-3-large 嵌入模型在4个数据集上不同上下文长度下的召回率]

性能并非无限增长：上下文长度的甜蜜点

不过，别高兴得太早。Databricks 同时也发现，长上下文并不是多多益善。LLM 的性能并不会随着上下文长度增加而无限增长。一旦超过某个临界点，性能就开始停滞不前，甚至掉头向下。

这就好比一个人同时读好几本书，书一旦多到某个程度，反而哪本都读不进去。LLM 也面临类似困境。上下文窗口过大时，它也很难高效处理和整合所有信息，最终导致性能滑坡。

如图 1 所示，不同模型在数据集上的表现都呈现出“先上升后平稳或下降”的曲线。比如 Llama-3.1-405b，性能在 32k token 之后就开始走下坡路；GPT-4-0125-preview 则在 64k token 之后掉头。只有少数模型，比如 GPT-4o、Claude-3.5-sonnet 和 GPT-4o-mini，能在较长的上下文里稳住阵脚。

图1：不同 LLM 模型在4个精选 RAG 数据集上的长上下文性能表现

这说明，开发者必须根据具体模型和任务需求，找到那个最合适的上下文长度，才能把 RAG 应用的优势发挥到最大。

长上下文 LLM 的失败模式：知己知彼，方能百战不殆

除了性能饱和的问题，Databricks 还揭示了一个更有价值的发现：不同模型在长上下文处理中，各有各的独特“死法”。了解这些失败模式，对打造高效的 RAG 应用至关重要。

商业模型：能力越大，责任越大

• • GPT-4: 虽然生成能力顶尖，但 GPT-4 在长上下文里容易瞎给答案。举个例子，当被问到“谁在电影《沉睡魔咒》的结尾演唱了《Once Upon a Dream》？”时，它错误地把正确答案“Lana Del Rey”识别成了“Ariana Grande & John Legend”。这很可能是因为模型在训练时缺乏足够的监督信号，一到海量信息面前就很容易“跑偏”。

图2：GPT-4 在不同上下文长度下对 NQ 数据集的性能表现

• • Claude-3-sonnet: 这款模型则表现出对版权问题的过度敏感，经常因为担心侵权而拒绝回答问题。比如当被问到“谁在电视剧《One Foot in the Gra ve》中扮演了 Mrs. Warboys？”时，它直接拒答，理由是“我不能在未经许可的情况下复制或引用受版权保护的材料”。可能是训练时被过度灌输了版权保护意识，导致它一遇到涉及版权信息的文本就变得过分谨慎。

图3：Claude 3 Sonnet 在不同上下文长度下对 NQ 数据集的性能表现

开源模型：各有所长，也各有短板

• • Llama-3.1-405b: 和 GPT-4 类似，它也容易给出错误答案，可能和训练数据集的质量和规模有关。比如当被问到“《进击的巨人》第二季有多少集？”时，它把正确答案“12”错认成了“25”。

• • Mixtral-instruct: 这款模型在处理长文本时，容易输出重复或随机的内容，说明它在保持文本连贯性和逻辑性上存在问题。比如当被问到“谁写了《物种起源》？”时，它竟然输出了一连串重复的“梦”字，让人哭笑不得。

• • DBRX-instruct: DBRX-instruct 则倾向于概括内容而不是直接回答问题，因为它可能更擅长理解和总结文本整体，而不是提取具体信息。比如当被问到“2014年世界杯的最佳射手是谁？”时，它给了一段关于射手榜的描述，就是不肯直接说出“James Rodríguez”这个名字。

Databricks 的建议：如何打造高效 RAG 应用？

Databricks 的这份研究，为开发者如何构建高效的 RAG 应用提供了几条实打实的经验。

首先，必须根据所用的模型和具体任务，精心选择合适的上下文长度，在性能和效率之间找到一个平衡点。上下文窗口太短，信息不够用；太长，性能会掉，资源也会白费。

其次，要善用评估工具，持续监控 RAG 系统的表现，及时发现并解决问题。Databricks 提供的 Mosaic AI Agent Framework 和 Agent Evaluation 工具就是不错的选择。

最后，关注 LLM 模型在长上下文方面的训练和架构优化，才能为 RAG 应用提供更强大的底层支撑。比方说，可以用 LongAlign 这类方法来训练模型，让它更擅长处理长文本。