能够大海捞针的LLM 会导致 RAG 消亡么？

自从24年2月以来在 AI 领域又连续出了很多重磅的新闻。我们没有蹭热点来对它们做跟踪和评述，一方面是因为目前正在紧锣密鼓的准备 Infinity 第一个release 版本的开发，另一方面，在过去的系列文章里，我们已经对 RAG 的必要性和未来的趋势进行了充分的阐述，相关的总结也在年初 InfoQ 以头条专稿的形式发表(可点原文查看链接)。因此在其余的时间中，我们主要有针对性地选择技术和产品分享观点。今天的文章，正是对这一个多月以来出现的新趋势和观察，给出我们的判断。

近期最火热的事情自然是 Sora，跟大多数人的认知不同，我们其实认为 Sora 会是引发多模态 RAG 热潮的一个先导，这不是今天讨论的重点。近期对于 RAG 场景产生较多影响的是另外一类新闻，这就是以Claude 3 ，Gemini 1.5，当然也包含国内的 Moonshot 为代表的系列多模态+长上下文的系列 LLM 发布，以及巨额融资和持续口碑发酵。这些大模型的上下文都很长，支持十万乃至百万级 Token ，并且在基于这些 Token 的“大海捞针”实验中表现优秀。 所谓“大海捞针”，意思就是针对这些长上下文窗口的细节提问，看 LLM 是否可以准确地回答。 用 RAG 来实现大海捞针是轻而易举的，然而目前列举的这些 LLM，它们不是基于 RAG 来提供这种能力，却也都可以达到很高的召回，同时它们也不是我们之前提到的 StreamLLM 这种基于滚动窗口实现长上下文注意力的机制——这种机制仅仅是增加了上下文窗口，但却仍然在细节召回上表现不佳。我们也试验了其中的若干产品，效果确实非常好，上传一个 PDF，甚至可以针对里边的复杂图表给出精确的回答。因此，引发了新的一轮关于长上下文 LLM 和 RAG 的争论。例如爱丁堡大学博士符尧这样评价：RAG 已死。

这当然也引起了很多 RAG 拥护者的反驳，围绕这些反驳，符尧博士进一步总结并反驳：

简单的把他的观点归纳一下：

1. RAG 的拥护者用成本来辩护。这是事实，但这只代表现状，让模型的成本降低并不难做到。

2. 长上下文 LLM 可以在上下文窗口内同时保证正确的召回和进行逻辑推理，而 RAG 只会检索一件事。

3. RAG 的拥护者认为即使上下文有一百万Token，这也不过1MB的文本，而 RAG 可以从大得多的文本来检索，没有限制。 在大多数情况下，用户的问题不会超过 1MB， 即使一本书，1MB文本也够了。

4. 性能问题，RAG 可以把数据缓存起来，而 LLM 的上下文每次都不能有效利用。这是不对的，LLM 也可以在推理的时候建立 KV Cache，缓存之前上下文的 Token，提升推理性能。

后边2点就不归纳了，因为 RAG 的拥护者给出的反驳观点更加不具备说服力。看起来，似乎 RAG 真的只是一种临时方案，随着 LLM 在长上下文能力表现的提升，特别是随着大海捞针能力的上升，好像确实不太需要 RAG 了。

其实这种争论从另一个角度来看待，就很容易得出结论了： LLM 的目标一直都是 AGI，它在未来是希望取代人的某些能力，主要包含学习，逻辑，推理，归纳等。 但是无论人的能力有多强，在他服务一家公司的时候，终归不能两手空空，至少需要配备一台电脑来访问公司的内部数据，信息系统等等。这台电脑，其实本质上就是以数据库为中心的信息系统。再看另一个类比，下图是 OpenAI 联创 Andrej Karpathy 给的一个图，他把 LLM 类比为一台计算机的 CPU， 把上下文类比为计算机的内存，那么以向量为代表的数据库，就可以看作是这台计算机的硬盘。

下边我们进一步讨论，为什么即使有了“大海捞针”能力，RAG 仍然必不可少。

我们所说的 RAG，实际上包含完整的链路，包括数据的准备，数据写入，乃至多路召回和最终的 Rerank 重排序。在整条链路中，最大的难点来自于两方面：其一是如何应对复杂多变的数据，这些数据包含各种格式，更复杂的还包含各类图表等，如果在没有理解这些语义的基础之上直接提供 RAG 方案，就会导致语义丢失从而让 RAG 失败。其二是如何多路召回，综合各种搜索和召回手段并排序。整条链路中最大的痛点，则在于 LLM 无法实现真正对齐，缺乏可控而胡说。关于第一个技术难点，一般的做法是引入文档智能模型，对复杂多变的数据进行目标检测识别文档的整体布局，然后按照文档布局的不同结果进行相应处理，如下图所示。

关于这些，我们试验了一些支持长上下文，乃至部分多模态能力的 LLM，在某些情况下，效果确实不错。但事实上，它们也仍然是以类似的方式进行了相关工作，只不过这类工作并不是我们通常用所谓的小模型来嵌入到 RAG 体系，而是直接用 LLM 来解决相关问题。类似的做法，其实已经有很多学术工作来做相关的事情，去年底国内也有大模型公司推出专用OCR大模型，试图用一个大模型解决所有文档理解的问题，在当时我们进行了试用，发觉在垂直领域，文档布局的智能识别能力，还是距离专用小模型差距比较大。类似的场景，在今天的长上下文 LLM 也有出现， 例如 Google 的 Gemini 1.5，官网已经宣称提供 OCR 能力，但它的 OCR 结果在很多时候仍然是不对的，其效果还是无法赶上一些专用模型。 下边是我们对一个长上下文表现优异的 LLM 月之暗面进行的视觉测试，下图是原始图表：

下图是 LLM 回答转换成表格的结果：

可以看到，虽然说很多数字和单元格都识别出来了，但是整体布局还是有很多对不上，而这类数据，用专用文档智能模型，可以很轻松的识别出来，而且甚至可以在CPU机器上跑得飞快。例如我们近期采用为 CPU 和移动端设备优化的传统视觉目标检测算法 YOLO 而开发的文档智能模型，不仅识别精度很高，而且可以在任意桌面机器上执行，大大降低了整体的实施成本。因此，在当下，一个哪怕是对各种复杂文档都能理解的完美模型，不论是大模型，还是小模型，都是不存在的，所以，轻言某项技术会被 Kill，是非常标题党的行为。要知道，YOLO 可是将近十年前提出的，它的 backbone 网络，依然是最传统的 CNN 而非 Transformer。这部分工作，我们也将很快开源，让更多企业受惠于 RAG 这项技术，逐渐解锁 LLM 在企业端的使用。

以上只是举了个非常简单的例子。在当前，RAG 在企业的使用还处于婴儿阶段，因此大量的使用场景还没有被解锁出来，例如用户的数据可能远非文档这种非结构化数据，在未来则更有可能是跟内部各种信息系统来对接，从数据库，日志中同步大量的数据过来，经过加工，由 LLM 给出最终答案。 在这些场景里， LLM 上下文窗口，真的只能当作计算机的内存来使用，而远非硬盘了。所以，前边符尧博士的观点，更多是站在最简单的 RAG 场景——知识库的角度来谈论，却没有站在整个产业的角度。1M 上下文 Token对于个人知识库确实足够了，几十年前比尔盖茨也说过 640K 内存足够这样的话，两相对比，何其相似。那么， LLM 的内存，会无限增长乃至彻底不需要硬盘么？从原理角度[1]，这是无法做到的。长的上下文在技术上并不神奇，一个必备的技术叫做旋转位置编码 RoPE 。简单的扩大上下文窗口的方案： 假设训练窗口大小为 2000， 在推理时希望扩展到 5000，那么对于一个位于 3000 的位置，原本是无法有效预测的，但通过一个编码和内插方案，可以将其位置设置在一个1200，例如通过 3000 * 2000/5000 来做内插。这样的弊端是，以前 0-1000 的位置，被压缩到更小的范围，导致辨识度下降。以 RoPE 为代表的旋转位置编码，就是试图缓解分辨率下降的问题。在工程实现中，随着上下文窗口的增加，会大大加重 Transformer 中K V 缓存的开销，且这些K V缓存对于带宽的需求很大，因此难以用普通的 RAM 乃至数据库系统为其服务，这就导致 LLM 的上下文窗口，真的是受限于硬件体系的。既然如此，为何不用价格低得多的 RAG 来实现同等的效果乃至更大的支撑体系呢？

再来看 RAG 的第二个难点——没有多路召回的 RAG 是几乎肯定会失败的，那么有了大海捞针能力强的 LLM ，其实会进一步缓解 RAG 实施的复杂度。RAG 作为一个计算机的硬盘，它必定是要承载复杂业务和数据的，当下的各种多路召回，其实质是因为 LLM 能力不足而提供的各种补救措施。 当 LLM 不再需要这些补救，RAG 的实施就会更加方便起来。比如 RAG 的开发人员，不用再担心如何精确地调整文字分块策略，只要以大概的方式，把可能答案附近的文字全部召回，由 LLM 负责最后的大海捞针，甚至进一步的逻辑推理。只是当前的技术，距离到这一步，还有很长的路要走。

RAG 本质上代表的是一个产业，而非只是一个应用，RAG 的大量使用场景还没有被解锁出来，主要原因是受限于搭配 RAG 的数据库，以及 LLM 本身。对于前者，这是我们致力于解决的问题，我们希望能够让包含文档的各类数据，都能参与到以 LLM 为中心的 RAG 体系中，在这个体系里，数据库承担的作用，是把一切可以提供给 LLM 的数据，都能快速高效地提交，举几个典型场景：

• 把符合要求的简历筛出，筛选条件包含工作技能（需要向量 + 全文搜索），某类行业的工作经验（基于向量的分组聚合），期望收入，学历，地域（结构化数据）。

• 基于对话推荐符合个人要求的产品 。可以采用多列向量来描述个人偏好，比如不同的列代表了用户对不同类目产品的过往使用偏好。在推荐过程中，除了采用基于用户的偏好向量进行搜索之外，还需要结合产品的过滤条件：包括是否过期，是否有优惠券，是否符合权限要求，是否有合规要求，该用户是否近期已经购买或者阅读过，等等。 这些信息，如果仅仅拿所谓“标量”字段这种方式来表征，那么产品的开发是极其复杂的：因为这需要引入额外的 ETL ，带来了维护性，以及更严重的数据一致性的问题。要知道，RAG 面临的是最终用户使用场景，它是需要业务乃至 LLM 发起请求，就立刻得到答案的，因此不能像数据中台一样仅仅为了一张报表就可以搭建一整套数据管道体系去做宽表这种额外逻辑。

• 从监控日志近期的表现，来给出导致近期日志某些指标异常的原因。这些指标过往的关联案例在对应的知识库中。

这样的案例能举很多，企业中实际面临的场景只会比这些更复杂。伴随这种复杂的多路召回能力，就能把 LLM 真实需要的数据，源源不断地送过来，而最后的瓶颈，就是 LLM 本身了。 在今天，我们看到系列长上下文的 LLM 在快速演进，这是给我们的惊喜而绝非惊吓，因为前述，我们丝毫不担心这会取代 RAG 的存在，而是看到 RAG 面临的最大痛点，正在我们预期的道路上逐渐被解决： 在这些长的上下文中， LLM 除了提供基本的摘要能力，也提供了一定的推理能力，这毫无疑问是让 RAG 更快为企业所接纳，而不仅仅停留在简单知识库的重大推手。

欢迎感兴趣的读者Star、关注我们专门为 RAG 开发的数据库 Infinity：GitHub - infiniflow/infinity: The AI-native database built for LLM applications, providing incredibly fast full-text and vector search

参考文献

[1] LLM时代探秘100K上下文背后的密码 - 知乎