去年底的時候，筆者寫過，與其在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的更多的探索會發生在如何有效且精準的找到包含答案片段的大塊。本文中使用的近似策略以及文檔組的構建都是在這個領域，目前很少見的探索嘗試，并提供了一些實驗論證。

本文轉載自????NLP前沿????，作者：NLP前沿