无限的上下文窗口会扼杀LLM微调和RAG吗？_rag 上下文扩展

文章来源：llm-infinite-context-fine-tuning-rag

2024 年 4 月 26 日

近年来，前沿的人工智能公司与实验室在扩展大型语言模型（LLM）的上下文窗口方面取得了显著的成果。这个所谓的上下文窗口，实际上就是模型能够处理的输入文本的长度。随着窗口的不断扩大，模型能够接收并处理的指令和信息量也相应增加，这让LLM的功能更加强大。

短短几年间，我们见证了GPT-3的2048个标记的上下文窗口，发展到了Gemini 1.5 Pro的惊人的100万个标记。如今，新技术更是有望将LLM的内存扩展到无限标记，这样的进步真是令人叹为观止。与此同时，改进的注意力技术也让LLM能够更准确地回应文本中的具体信息，这就像是“大海捞针”般精准。

然而，随着LLM支持更长的上下文，人们开始思考：我们是否还需要进行微调或使用检索增强生成（RAG）呢？这些技术虽然有效，但往往需要大量的工程工作。

对于这个问题，答案并非绝对。就像LLM的许多其他方面一样，这既可以说“是”，也可以说“否”。在项目的早期阶段，LLM确实能够减少许多工程工作。但是，当模型的应用规模扩大时，我们可能需要重新审视那些经过验证的优化技术。

说到无限上下文与微调，微调LLM确实是一个复杂的过程。首先，需要收集和标记训练数据。然后，选择适合的模型，设置计算集群，并编写和运行微调代码。虽然现在有微调服务，可以通过API进行模型微调，无需自己设置GPU，但控制训练过程，如迭代次数和模型评估，仍然是必要的。

相比之下，有了无限上下文的LLM，我们可以通过提示工程来调整模型的行为。例如，谷歌DeepMind最近的研究显示，通过在提示中多次插入输入输出示例，模型能够执行以前需要微调的任务。这种技术的入门门槛相对较低，任何人只要能够访问模型，都可以使用。

再来说说无限上下文与RAG。RAG的技术难度甚至超过了微调。它需要将文档分解成小块，计算嵌入，并存储在向量数据库中。然后，创建一个提示管道，计算用户请求的嵌入，从向量存储中检索相关文档，并将其添加到提示中再传递给模型。为了改进RAG管道，还需要使用更高级的技术，如重新排序、多步检索和创建自定义嵌入模型。

但有了无限注意力，我们可以简单地将所有文档放入提示中，通过尝试不同的指令，让模型挑选出相关信息并用于回应。如今的前沿模型已经能够处理几本书的数据量，并擅长定位特定信息来回答问题。

这意味着，例如，我们可以将整个编程库的文档插入到提示中，让模型帮助我们编写代码。

总的来说，LLM的发展趋势是降低创建机器学习系统的门槛。它们具有零样本学习、小样本学习和多样本学习的能力，使得以前需要数天或数周工程工作才能完成的任务，现在只需少量编码工作即可完成。更长的上下文将继续这一趋势，进一步减少复杂任务对工程工作的需求。

然而，我们也不能忽视长上下文和无限上下文LLM的局限性。创建成功的产品和应用不仅需要概念验证，还需要构建能够大规模运行的系统。在处理大量推理请求时，即使是提示中的微小改动也可能对计算、内存和成本产生显著影响。

因此，微调、RAG以及为支持它们而开发的技术和工具仍然具有重要意义。例如，低秩适应（LoRA）允许我们创建数百或数千个微调后的LLM，而无需为每个模型存储大量参数。这些技术在高使用率的应用程序中具有颠覆性的潜力。

随着前沿实验室继续推动LLM的能力，它们将简化AI应用概念的创建。产品团队将能够更独立地创建和迭代原型，减少ML团队的参与。这将加速产品与市场契合度的达成过程。然而，当我们超越概念验证阶段时，我们不能低估良好的工程技能和能够构建可靠且可扩展的ML管道的人才团队的价值。

正如HyperWrite AI的CEO马特·舒默所言：“通过提示找到产品市场契合度，然后微调以扩展规模。”这一观点深刻地揭示了LLM在AI应用发展中的重要作用，同时也提醒我们，在追求技术创新的同时，不能忽视工程实践和人才团队的价值。