趋近智
大型语言模型(LLMs)尽管具备出色的能力,但其注意力范围是有限的,通常被称为上下文窗口。这个窗口代表着模型在处理输入和生成输出时,一次性可以考虑的最大文本量(以标记衡量,大致对应单词或单词的一部分)。这相当于模型的短期记忆。
在标准的LLM交互中,这个限制适用于用户的提示和模型生成的响应。然而,在RAG系统中,我们特意在提示中加入更多信息:从我们的知识来源检索到的上下文片段。这立刻带来了一个难题:原始用户查询加上检索到的文本段落的总长度,可以轻松超出LLM的上下文窗口容量。
想象一下,如果你试图把太多文档塞进一个小文件柜。你不是得把一些文档放在外面,就是得把一些文档剪掉一半,或者设法对其进行总结。同样,当增强型提示(查询 + 检索到的片段)对LLM来说太长时,我们需要方法来管理溢出。如果我们只是简单地发送一个超出限制的提示,模型可能会随意截断输入,忽略溢出部分,或者返回错误,从而导致不完整或不准确的回答。
以下是RAG中管理上下文长度限制的常用方法:
最直接的方法就是简单截断。如果组合文本超出限制,就截掉最不相关的一部分。这通常意味着移除稍后检索到的片段(假设检索器返回的前几个片段最相关),或者截断最后一个包含的片段的末尾。
除了仅仅根据初始检索得分选择前N个片段,你还可以采用更精细的选择过程。这可能包括:
更严格的限制: 只包含绝对的前K个片段,即使检索到更多,并确保K足够小以便适应。
重新排序: 使用一个辅助的、计算量可能更大的模型(一个“重排器”)来重新评估最初检索到的前N个片段的相关性,特别是在查询的上下文中。然后,选择重新排序后得分最高且能适应窗口的片段。
以查询为中心的筛选: 优先考虑那些与用户查询语义相似度最高,而非仅仅具有一般相关性的片段。
优点: 旨在保留最相关的信息,与简单截断相比,减少了截断重要上下文的可能性。
缺点: 可能会增加复杂性和延迟(特别是重新排序时)。仍然涉及丢弃可能有用的信息。
另一种方法是在将检索到的片段注入提示之前对其进行摘要。你可以使用另一个LLM调用(或一个专门的摘要模型)来创建一个检索到信息的简洁摘要,而不是插入多个完整的文本段落。这个摘要,连同原始查询,然后馈送给主生成器LLM。
一个工作流程图,展示了检索到的片段如何在传递给生成器LLM之前进行摘要,以管理上下文长度。
在数据准备阶段(第三章),文档如何分块在这里起到作用。使用较小的片段大小意味着每个单独的上下文片段更小,可能允许更多不同的片段适应窗口。然而,较小的片段自身可能缺乏足够的上下文。找到合适的片段大小通常需要反复尝试,并根据LLM的上下文限制和源文档的性质进行调整。
选择正确的方法取决于几个因素:
通常,可能会使用多种方法的组合。例如,检索比所需略多的片段,对其进行重新排序,然后截断重新排序列表中最不相关的片段,以适应上下文窗口。
管理上下文长度是构建有效的RAG系统中的一个实际工程难题。它需要在为LLM提供全面上下文的愿望与模型架构的硬性限制之间取得平衡。反复尝试和评估(我们将在后面介绍)对于找到适合你特定使用场景的最佳方法是必不可少的。
简洁的语法。内置调试功能。从第一天起就可投入生产。
为 ApX 背后的 AI 系统而构建
这部分内容有帮助吗?
© 2026 ApX Machine Learning用心打造