迈向长上下文RAG
输入“/”快速插入内容
迈向长上下文RAG
迈向长上下文RAG
2024年8月20日修改
作者：向量检索实验室 | AI 搜索引擎
谷歌最近发布了具有100万上下文窗口的 Gemini 1.5 Pro [1],只面向有限的开发者和企业客户。它的表现激发了 AI Twitter [2]的想象。它在 Greg Kamradt [3]推广的**"大海捞针" [4]实验中 达到99.7%的召回率** [5] 。早期用户分享了同时输入数十篇研究论文、财务报告的结果,并报告了在综合大量信息方面令人印象深刻的结果。
自然地,这引发了一个问题——RAG消失了吗? 一些人认为是这样 [6],而其他人 不同意 [7]。那些持第一种观点的人提出了有效的论点。大多数小型数据用例可以适应100万到1000万个标记的上下文窗口。随着时间的推移,标记的处理速度会变得更快、更便宜。与天真的RAG中存在的一次性检索相比,拥有原生交错检索/生成注意力层的LLM可以获得更高的响应质量。
我们有幸预览了Gemini 1.5 Pro的能力,并通过使用它开发了一个关于上下文增强LLM应用程序将如何发展的论点。这篇博文阐明了 我们作为数据框架的使命 以及 我们对长上下文LLM架构会是什么样子的看法 。我们的观点是,虽然长上下文LLM将简化RAG管道的某些部分(例如分块),但需要进化的RAG架构来处理长上下文LLM带来的新用例。无论出现什么新范式,我们在LlamaIndex的使命都是为这个未来构建工具。
我们的使命超越RAG
LlamaIndex的目标非常简单: 使开发人员能够在其数据之上构建LLM应用程序 。这个任务超越了单纯的RAG。迄今为止,我们已经在推进现有LLM的RAG技术方面投入了大量精力,我们这样做是因为它使开发人员能够解锁数十个新的用例,例如对半结构化数据的问答、对复杂文档的问答以及多文档设置中的代理推理。
但我们也对Gemini Pro感到兴奋,我们将继续推进LlamaIndex作为长上下文LLM未来的生产数据框架。
LLM框架本身就有价值 。作为开源数据框架,LlamaIndex为从原型到生产构建任何LLM用例铺平了道路。与从头开始构建相比,框架使构建这些用例变得更容易。我们使所有开发人员能够为这些用例构建,无论是使用我们的核心抽象设置适当的架构,还是利用我们生态系统中数百个集成。无论底层LLM的进步如何,以及RAG是否继续以其当前形式存在,我们都将继续使该框架准备好投入生产,包括严密的抽象、一流的文档和一致性。
我们上周还推出了LlamaCloud [8]。我们对LlamaCloud的使命仍然是构建数据基础设施,使任何企业都能使其庞大的非结构化、半结构化和结构化数据源做好生产准备,以便与LLM一起使用。
最初对Gemini 1.5 Pro的观察
在我们最初的测试中,我们尝试了一些PDF:SEC 10K文件、ArXiv论文、这个庞大的 示意性设计活页夹 [9]等等。一旦API可用,我们将进行更多深入分析,但同时我们在下面分享观察结果。
Gemini的结果令人印象深刻,与我们在技术报告和社交网络上看到的一致:
•
**Gemini对特定细节有惊人的记忆力:**我们输入了10万到100万标记的上下文,并询问了有关这些文档(非结构化文本和表格数据)中非常具体的细节的问题,在所有情况下,Gemini都能够回忆起细节。请参阅上面Gemini比较2019年Uber 10K文件中的表格结果。
•
Gemini具有令人印象深刻的总结能力。 该模型可以分析跨多个文档的大量信息并综合答案。
此图显示了Gemini对2019年Uber 10K文件的一个问题-回答对。问题和答案显示在顶部,源表格显示在底部。Gemini能够返回正确的答案。
我们注意到Gemini在某些部分还有些吃力。
•
Gemini无法正确读取所有表格和图表。 Gemini Pro仍然难以正确读取图形和复杂表格。
•
Gemini可能需要很长时间。 在Uber 10K文件(约16万字)上返回一个答案需要约20秒。在LHS示意性设计活页夹(约89万字)上返回一个答案需要60多秒。
•
Gemini可能会虚构页码。 当被要求给出摘要但同时包含页码引用时,Gemini虚构了来源。
Gemini 1.5 Pro仍然会产生幻觉的一个例子。当被问及所有细分市场的总预订量时,该模型虚构了一个数字——该数字可见于图表中,也可以从表格中拼凑出来。
尽管定性来看，这算得上是对未来的激动人心的一瞥，值得更广泛地讨论哪些RAG范式将会消失以及新兴的架构。请见下文！
长上下文解决了一些痛点,但仍然存在一些挑战
Gemini 1.5 Pro只是众多长上下文LLM中的第一个,它们将不可避免地改变用户构建RAG的方式。
以下是我们认为长上下文LLM将解决的一些现有RAG痛点: