在科技领域的前沿，长上下文语言模型（Long Context LLMs）和新兴检索方法如RAPTOR 正在引发广泛关注。本文将围绕这些技术展开讨论，并探讨它们在实际应用中的创新性和科技性。

长上下文语言模型的崛起

近几周来，随着新型长上下文语言模型（如Gemini、Claude 3）的出现，关于“RAG（Retrieval-Augmented Generation）是否已经过时”的讨论甚嚣尘上。这些新模型能够处理高达百万个tokens的上下文，这无疑为我们提供了前所未有的机会。

我最近在某些项目中使用了这些长上下文LLMs，例如我上周发布的代码助手，它使用长上下文LLM回答关于我们文档中L表达式语言的问题。在这个项目中，我们处理了大约60,000个tokens的上下文，将问题和文档结合起来生成答案。这种方法非常简洁，不需要检索，只需将所有文档加载到上下文中并直接生成答案。我个人非常喜欢这种使用长上下文LLMs的方法，但在实际应用中，我们需要考虑一些问题。

评估与性能

为了进行评估，我设置了20个问题并生成了相应的答案。通过LangSmith仪表板，我观察到P50延迟（即50百分位延迟）在35到46秒之间，而P99延迟则高达420秒。这种延迟因试验而异，但总体上是可以预期的。更有趣的是，生成每个答案的成本约为1到1.3美元。

在考虑使用长上下文LLMs时，我们必须权衡这些因素，尤其是与传统的RAG系统相比，后者通过检索更小、更定向的片段来回答问题。

本地LLMs的替代方案

很多人问我是否可以用本地LLM来替代这种方法。我的首选本地LLM是Mistol 7B V2，它具有32,000个token的上下文窗口。然而，这仍然不足以处理我约60,000个tokens的文档。因此，虽然本地LLM在某些场景下是一个可行的替代方案，但在处理超大规模文档时，仍存在一定的局限性。

轻量级检索策略的探索

这些考虑促使我思考是否存在适用于长上下文模型的轻量级检索策略，这些策略既能利用大量上下文，又能解决上述限制。

其中一个观点是可以在文档级别进行索引，将完整的文档直接嵌入，然后利用KNN（K近邻）算法进行检索。这种方法无需对文档进行任何拆分或分块。

另一个有趣的想法是构建文档树。传统的KNN方法在需要整合多个文档的信息时可能不够灵活，而文档树可以通过聚类和递归总结信息来解决这个问题。

RAPTOR 方法的介绍

最近，一篇关于RAPTOR 方法的论文引起了广泛关注，其代码也已开源，这使得Llama Index团队推出了一个相应的Llama包RAPTOR r方法的核心思想是通过递归总结和嵌入文档来构建文档树，从而提高检索性能。

首先，我们将一组文档嵌入，然后对它们进行聚类。接着，我们对每个聚类中的内容进行总结，将这些总结作为更高层次的抽象。这个过程递归进行，直到只有一个聚类为止。最终，我们将这些总结和原始文档一起嵌入并进行检索。

实验与实现

为了验证这个方法的有效性，我使用了Claude 3来进行文档总结，并使用OpenAI的嵌入模型。通过递归聚类和总结，我们构建了一个包含原始文档和总结的向量索引。

实验结果表明，这种方法能够有效地提高检索性能，尤其是在需要整合多个文档信息的情况下。通过结合原始文档和总结，我们可以在不同粒度的抽象层次上进行检索，从而提高答案的准确性和全面性。

总结

长上下文LLMs和RAPTOR 方法为我们提供了新的可能性，特别是在处理大规模文档和复杂信息整合任务时。虽然直接使用长上下文LLMs是一种有效的解决方案，但在某些情况下，结合轻量级检索策略RAPTOR r方法，能够进一步提高性能和灵活性。