大语言模型RAG vs. 长文本

在学习完大语言模型中最热门的两个概念大语言模型落地的关键技术：RAG和大语言模型上下文窗口初探后，关于RAG和长文本（long-context）的优劣比较引起了广泛的讨论，本文整理了大语言模型RAG vs. 长文本争论的5种类观点。

1、观点1：RAG 与长文本各有所长

人们普遍认为将文本切片，然后进行相应的检索是最节省资源的方式。但因为检索是速度检索，受到阈值的影响，可能要多次反复检索，反而会造成一些token 消耗的问题。在多轮对话过程中，特别是在金融分析和客服场景，需要使用长文本来解决问题。如果进行切片处理，可能会丢失上下文之间的相互依赖关系。

对于大模型厂商，选择长文本或者 RAG 应该考虑哪种方式最节省 token。
 

一位投资人分享了一个项目：国内有一个做代码生成工具的公司，相比仅仅生成代码，他们更注重软件工程。因为GitHub 或 Copilot 生成代码分析和代码片段的能力已经很完美，国内真正需要解决的是能够围绕多个指标进行策略生成。

以操作系统为例，当我们想在操作系统中增加 AI 助手时，大模型不仅能实现底层部署，还能生成交互界面。这种生成能力依赖于向模型输入的数据规模，可能涉及到的代码量会达到百万行、甚至千万行。如果仍然使用比较原始的一次性输入方式，可能会遇到很多问题。

对此，这位投资人分享了两个观点：

• 长文本是一种智力能力。拥有一个更好的上下文窗口，可以更好地解决代码的相互依赖和逻辑性问题。如果只是用 RAG 方式去分段代码，然后再连接起来，再分段提问，是无法满足需求的。
• RAG更像是能力的边界。如果只使用上下文窗口，而没有好好利用 RAG 基于检索的方式，很难解决同一个代码工程在多个模块，或者在多个功能上的问题。只能解决比较局部的问题，无法处理多个模块之间的相互关联，例如进行联调测试，而合理使用 RAG 辅助可以拓展模型的知识边界。

进一步说明：

• 长文本是一种智力能力：从认知科学的角度看，人类处理长文本信息的能力是高级智力的体现。阅读理解一本小说，写作一篇论文，都需要在大脑中维护一个宏大的上下文，同时进行逻辑推理、情节关联等复杂的认知活动。这种能力区别于对简单句子或短语的机械处理。对语言模型而言，长文本建模能力意味着更强的抽象和归纳能力。
• RAG更像是能力的边界：RAG 通过检索相关片段来辅助生成，在一定程度上弥补了语言模型在长文本建模上的不足。它提供了一种即时获取背景知识的机制，减轻了模型的记忆负担，但它并不能取代模型本身的语言理解和推理能力。

2、观点2：长文本将取代RAG

长文本相比于 RAG 在解码过程中检索具有明显的优越性，因此有人认为长文本正在取代 RAG。

爱丁堡大学博士付尧在评价Gemini 1.5 Pro 的帖子中写道：

“一个有 1000 万 token 上下文窗口的大模型击败了 RAG。LLM 已是强大的检索器，那为什么还构建一个弱小的检索器并花时间在解决分块、嵌入和索引问题上呢？”

他表示，1000 万 token 上下文杀死了 RAG。

Twitter地址：

https://twitter.com/Francis_YAO_/status/1758934303655030929

虽然当前上下文模型的计算成本很高，上下文窗口的消耗成本和时间消耗是非线性增长的，但有人认为未来可能会有更好的方式来重复利用缓存，从而释放压力。从 AI 的历史发展来看，现有模型的成本能降低90%，RAG可能会从现在的50%的应用场景缩减到10%。

在大规模语言模型中，重复利用缓存是一种优化策略，旨在提高模型的推理效率和速度。它的基本思路是：将模型在处理长文本时生成的中间结果（如隐藏状态、注意力矩阵等）存储在缓存中；当遇到相似的上下文时，直接从缓存中读取这些中间结果，而不是重新计算。比较常见的是Key-Value Cache、Hidden State Cache 等

对于长文本替代RAG，有人提出了一个很有意思的 idea：如果有一个无限长的上下文模型，直接将 wiki 里面所有的文本和相关信息全部输入，然后再去问问题。实际上就相当于大模型直接做 RAG，不需要有任何外部的知识库，再去进行上游检索。模型的推理成本是个门槛，即模型输入的信息越多，模型推理的时间越长，成本越高。

但依旧存在可行的解决方案，即信息压缩：交给 RAG 或在线数据库处理的信息，本质上是可以被压缩的。比如检查 GitHub 里的 Star 数量，或者 wiki 上的访问量，贡献的数量等，都是可以被压缩的，进而转化为结构化的信息。但此方法的前提条件是，需要找出哪些数据真的可以被压缩，并且它的压缩失真情况在接受的范围内。

3、观点3：RAG 和长文本分工已经明确，不存在争议空间

对于一些严肃的场景中，如法规条文、保险或教育等，RAG可以更好解决的问题。在进行向量化的初期，开发者设计的就是认为里面的内容是法定正确的；或者至少为大模型提供向量数据库时，我们认为这些是客观事实，不应该对这些事实进行歪曲或改变。如果将其交给大模型的幻觉或者概率去判断，实际上可能会出现问题。如果完全依赖长文本，结果一定是不准确的。

对于多轮对话的场景，RAG能解决的问题并不是很清晰。如客服场景，很多大模型会出现与它对话的时候，会做一些后端的成本精简，不需要动用全部算力来解答一个问题。如果反复去确认，要给一个真实答案，这个时候只能交给长文本去解决这个问题，而 RAG 只是去把它向量化。此外，对于软件工程领域，涉及到代码的补全、翻译或重构时，输入 token 会非常大，只交给滑动窗口去处理，会存在理解的障碍。

4、观点4：长文本和 RAG 需要结合

RAG的特点是准确、事实性和时效性。用 RAG 的方式，可以将原有系统的元素变成多维标签，甚至将系统本身做成一个端到端的向量，或是一个标签化的端到端的实体，以防信息损失。但如果只用 RAG 的方法去做模型，可能在多轮对话后，它就不知道说什么了。长上下文在解决问题时，是一个泛化和上下文理解的过程，避免信息丢失。

长文本和RAG 都比较依赖于上游检索的输出。如果大模型对上下文的容纳程度比较低，那对检索的要求就更高，必须把最重要的信息检索出来。但是，如果大模型可以接受更多的上下文，那么对检索的要求就相对降低，而对数据准备的要求就会相对提高。

对于大模型厂商来说，无论是做大模型基座还是其他，未来最终都是要转向消费端。只有当消费端起来之后，大模型才可能有一个大的爆发。从消费端来看，一般考虑的是成本性能、泛化能力以及信息丢失。在消费端应用的场景下，最终是希望成本越来越低，性能越来越快，泛化能力越来越强。

• 如果不能接受信息损失，需要在系统里面投入更高的 RAG 成本。
• 如果只是进行角色扮演，或者是给出一个笼统的回答，那么长文本比较合适。

长文本和RAG 的结合更像是一种趋势，在输入大模型之前，我们不仅可以通过向量库去做文本检索；还可以通过一些 function 去获取更多的文本来做集中的召回，通过大模型做能力整合再做 RAG。长上下文能够代表所有情况，但 RAG 系统仍然会存在。

5、观点5：RAG 是大模型发展的中间态，短期内长文本无法替代 RAG

无论是传统还是新架构，不断扩大模型的处理长度后，其性能必然会有所损失。目前的大模型而言，可能较合适的处理窗口是4K到8K，因为预训练是在这个长度范围内。RAG 相当于我们把模型的存储扩展到了无限，我们要做的是把有用的、最重要的信息给大模型。

因此，RAG 一定是很重要的，只不过它未来可能会有多种形态，不一定是现在这种大模型和向量检索分开的形态，它的形态可能会有所不同。但是，这种通过一些方法提前对信息进行精炼和提取的思想，一定会在大模型的发展中长期发挥重要的作用。

长文本处理和RAG 这两个技术会共同发展。对长文本处理已经有一些优化的方法。比如，通过微调的方法把训练的参数量已经提升到了十亿或者是百亿；在推理上的话，减少长文本的处理开销也有一些优化方法，比如 MIT 的韩松实验室有一个 Streaming LLM 的方法，可以识别出长文本中哪些是重点的 Context 或者 Token；然后保留这些部分和最近的一些信息，可以进行推理长度的优化，从而降低推理的成本。

除了长文本处理在不断进步之外，RAG 最近也有很多新的技术，未来可能会结合 agent，在其他方面提高模型解决具体实际问题的能力。

以目前的推理成本来看，RAG必不可少，可能会隐藏在产品里。比如说网易的逆水寒，它里面做了很多 AI 的具体应用，比如 NPC 对话。MiniMax 的模型有一个功能叫做 Glyph，它可以去控制模型输出的结果，可以标准化它的格式，对于很多场景来说，它的推理是非常有帮助的。