碎碎念
去年底的时候，笔者写过，与其在RAG系统上雕花，可以重新思考一下，自己的业务场景是否非RAG不可吗？随着去年大模型的蓬勃发展，长度外推、更长的上下文模型，更厉害的中文底座大模型，都可以让整个系统的压力往生成部分上迁移。
后来笔者造了一个词，文档片段化。对于常规的pdf问答档问答，基本上都能使用单一的大模型覆盖到了。但是对于知识库，文档库的问答，似乎RAG还是必不可少的。但是如果生成模型能力更强了，那与其在思考如何去更好的解析文档结构，去划分块大小，不如放大维度，把更大粒度的文本，如文档，当作传统的块，可以省掉很多细碎的工作。
回归主题，RAG场景如何吃到大模型长上下文的红利？本文主要是分享新出的一个研究工作LongRAG，为了解决检索器和阅读器之间工作量不平衡的问题，文中提出了一个新的框架，称为 LongRAG，它包括一个“长检索器” （long retriever）和一个“长阅读器”(long reader - llm)。文档块变长很显然，long retriever应该如何设计才能保证召回效果（正确答案的块相比与短块包含了更多的噪声），这个是本文的核心内容。
LongRAG 将整个维基百科处理成4K-token的chunks，这比以前的chunk长度长了30倍。通过增加chunk大小，显著减少了总chunk数，从22M减少到600K。使用现有的长上下文大型语言模型（LLM）进行答案提取，在NQ数据集上，LongRAG将答案召回率@1从52%提高到71%，在HotpotQA数据集上，将答案召回率@2从47%提高到72%。LongRAG在不需要任何训练的情况下，取得了与经过微调的RAG模型相当的结果。
文章地址如下：
https://arxiv.org/html/2406.15319v1
框架对比图如下，相比于vanilla rag的模式（下图左），longrag采样更大的块大小（下图右），所以理论上上对long retriever上应该需要一些特别的操作。
long retriever
传统的 RAG 中，检索块 g 通常是从文档 d 中分离出来的一小段段落，包含数百个标记。在这里，g 可能与整个文档甚至多个文档一样长，所以像传统那样算相似度可能就会有比较多的噪声干扰了。
因此首先能合并在一起的文档那不能不太相关联，不然召回之后作为模型的上下文噪声太大了。所以第一步需要先进行一个文档分组，这个算法类似于以前的那种流式聚类，还是什么聚类，名词记不太清了。文档是否相关使用的文档的连边，类似于那种有结构层级的知识库的大目录信息。细看就是如下图，很好理解：
然后计算相似度，传统那样query-passage计算比较有难度，所以使用近似，算query和passage中的小块的最大相似度，这个小块的粒度是个实验维度，可能是段落，也可能是文档级，也可能是上面的文档组。
到这里，核心的算法原理部分基本就结束了，对了，还有一个超参数，对于小的文档块召回为了提高召回率，一般用比较大的k。但是这里不行了，论文中设置的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-
右下角，帮忙点点
+
粤ICP备14082021号
免费POC，
零成本试错
