RAG应用要如何吃到大模型长上下文的红利？-LongRAG

去年底的时候，笔者分享过一个观点：与其在RAG系统上雕花，不如重新思考一下，自己的业务场景是否真的非RAG不可？随着大模型在长度外推、更长上下文处理能力上的突飞猛进，尤其是中文底座大模型的表现越来越强，整个系统的压力其实可以更多地向生成部分迁移——这是系统设计思路的升级。

后来笔者又造了一个词：文档片段化。对于常规的PDF问答场景，单一的大模型现在已经能覆盖大部分情况了。但在知识库、文档库这样的真实场景中，RAG依然是必需品。不过，如果你的生成模型能力够强，与其纠结于如何更精确地解析文档结构、琢磨段落块的大小，不如换个思路：放大维度，把更大粒度的文本——比如整份文档——当作传统的“块”来用。这样做的好处是能省掉很多细碎的工作。

回到正题：RAG场景怎么才能真正吃到大模型长上下文的红利？最近有一项值得关注的研究——LongRAG，专门解决检索器和阅读器之间工作量不平衡的问题。它提出了一套新框架，核心是两个组件：一个“长检索器”（long retriever）和一个“长阅读器”（long reader，其实就是LLM本身）。显然，文档块变长之后，检索器的设计就成了关键——如何在更大块中保证召回效果？要知道，大块相比短块，里面包含的无关信息也多得多。

LongRAG的实验很讲究：他们将整个维基百科处理成4K token大小的chunks，这比传统chunk长了30倍。总chunk数从2200万锐减到60万。然后，他们用长上下文LLM来提取答案。结果怎么样？在NQ数据集上，答案召回率从52%提升到了71%（@1）；在HotpotQA上，从47%提升到了72%（@2）。而且，这些结果完全不需要微调，已经能和经过微调的RAG模型打个平手。

论文地址：
https://arxiv.org/html/2406.15319v1

框架对比图如下：

从左边的Vanilla RAG到右边的LongRAG，块大小明显变大了，这也意味着检索器需要一些特别的设计。

long retriever：大块头的检索挑战

传统RAG中，检索块是几百个token的小段落。但在LongRAG里，块可能和整份文档一样长，甚至更长。如果直接用传统方法算相似度，噪声会非常大。

所以第一步，不能把完全不相关的文档硬塞在一起——否则召回来的大块上下文质量堪忧。解决方案是做一个文档分组，算法类似于流式聚类（具体名称记不太清了）。判断文档是否相关，用的是“文档连边”的方式，类似于有结构层级的知识库中的大目录信息。直观地说，就是下图展示的样子：

接下来是相似度计算。传统做法的query-passage直接比较很难，所以采用近似策略：计算query和passage内部小块之间的最大相似度。这个小块的粒度是一个实验参数，可以是段落、文档、甚至文档组。

到这里，核心算法原理基本就讲完了。还有一个超参数值得注意：传统上，为了从小块中召回更多答案，一般会设较大的k。但在LongRAG这里行不通了——论文里设置的k是4到8。

核心实验：召回率的真相

下图展示了使用段落、文档、文档组三种召回方式时，真实答案的召回率（最右边一行）。毫无疑问，召回数量越多，召回率越高；而块越大，达到接近的召回率所需的top k就越小。这个趋势很直观。

最后

整体结论很清晰：块长度变长后，信息更多、更杂，很难用一个向量完整表达——所以LongRAG真正探索的关键在于，如何有效且精准地找到包含答案片段的大块。本文中使用的近似策略和文档组构建方案，是这片领域目前很少见的探索尝试，并给出了扎实的实验论证。

对于RAG整个框架的更多技术细节，PaperAgent团队RAG专栏做过系统性的归纳总结：包含高级RAG之36技 & 一些实战，以及RAG全景图：从RAG启蒙到高级RAG之36技，再到终章Agentic RAG！

• 专栏试看：https://docs.qq.com/aio/DR0dBWm9WYlJNckxw?p=dIxns4m9ounpDQ9pRCV7zu

-END-