LongRAG：长文档单元检索与阅读

什么是 LongRAG

LongRAG 是一种结合长文档单元检索与长上下文阅读的 RAG 方法。Jiang 等人提出的这套方法先将关联文档组成较长的检索单元，再由检索器选出少量相关单元，交给长上下文模型（reader，阅读器）提取信息并回答问题。

用于计算匹配分数的片段，与最终交给模型的资料范围可以不同。 LongRAG 可以为长单元内部的片段分别生成向量，用匹配度最高的片段给整个单元评分；选中后，返回完整长单元供模型阅读。因此，检索器负责找到相关资料组，阅读器负责从组内找齐具体依据。

整个过程可以分成建库与问答两部分：

建库：关联文档 → 合并成长单元 → 为单元内片段建立检索索引
问答：用户问题 → 检索片段并给长单元评分 → 取回排名靠前的完整长单元
                                                    ↓
                                           长上下文模型阅读并回答

为什么要返回长单元

用户问一台设备断网后怎样保存数据、重新联网时怎样补传。若“缓存”“容量限制”“恢复同步”分散在三份关联文档里，短块检索必须分别找齐它们。漏掉容量限制，生成的操作建议就可能忽略数据被清除的条件。

如果预先把这三份文档组成一个长单元，检索器选中该单元后，阅读器就能同时看到三部分内容。这样降低了检索阶段逐一找齐短证据的要求，但也增加了模型需要阅读的文本量。

LongRAG 仍会按问题选择资料。将完整知识库直接放入提示词，以及缓存这些输入的做法，见长上下文与 CAG。

长单元怎样形成

原论文在 Wikipedia 语料中利用文档超链接，将有关联的文档组成长单元。分组算法根据文档连接关系和最大组大小合并文档；论文实验的单元平均约为 4K token。这个数量是实验设置的结果，不是建议所有知识库统一切成 4K token。

前面的设备示例也可以设计一个长单元：

G1：边缘设备离线运行资料组
  D1：遥测队列与本地缓存
  D2：日志轮换及容量限制
  D3：重连后的补传与去重

G2：设备安装与接线资料组
  D4：电源接线
  D5：网络初始化

在这类设备知识库中，分组依据可以来自文档之间的引用或人工维护关系。仅因关键词相似就把不同产品手册混为一组，可能让 reader 同时读到互不适用的规则。没有显式关联时，也可以评估整篇文档作为单元，但必须测量其主题集中程度和长度。

长单元不一定只用一个向量

完整长单元可能超出 embedding 模型的输入上限，也可能包含多个主题。原论文因此用子片段评分近似长单元与问题的相似度：

长单元分数(q, g) ≈ max{点积(E_Q(q), E_C(g'))：g' 是 g 内的编码片段}

其中 g 是长单元，g' 是内部用于编码的片段，E_Q 与 E_C 分别表示问题和文本的编码器。它采用 MaxP 思路：以内部片段的最高匹配分数代表整个单元。因此，一个长单元可以对应多个用于检索的片段向量，返回时再按单元 ID 取回整组资料。论文也比较了不同的编码粒度。

设两个长单元的内部片段分数如下，取最大值作为单元分数：

长单元	内部片段分数	单元分数
G1	0.82、0.67、0.79	0.82
G2	0.40、0.45	0.45

若选择 G1，reader 读取的是 G1 内的完整文档集合，不能只留下得到 0.82 的那个片段，否则容量限制和恢复同步又可能被丢掉。执行检索时还要按单元去重：最高的几个片段若全部属于 G1，并不代表已经找到了几个不同的长单元。

这种实现与 Parent Document 都可能包含“子片段命中后返回大单元”。区别在于研究重点和整体设计：Parent Document 关注恢复某个小块的原文上下文；LongRAG 同时设计关联文档组、长单元检索和长 reader，评估检索器与阅读器之间的任务分配。两者在实现上可以重叠。

Reader 接下来负责什么

检索出的长单元会拼接交给长上下文模型。论文在 NQ、HotpotQA 等数据集上使用少量长单元，将数万 token 的输入交给现成模型完成问答。实际返回多少个单元，要同时考虑资料长度和 reader 能有效处理的上下文规模。

长 reader 需要在 G1 中找到缓存、容量限制和补传三项规则，并保留它们的关系。文档标题、边界和来源 ID 应随文本一起保留，否则即使回答正确，也难以判断哪一句来自哪篇资料。面向生产的段落引用或页码定位，可以在生成后校验，或增加单元内证据定位步骤；这些属于工程扩展。

论文中的长单元能减少短片段截断造成的语境缺失，也研究了大量短候选对 reader 的干扰。不过，更长输入并不保证更好：相关规则可能被放在中间位置，多个相似版本可能混淆，单次阅读费用也会增加。

什么时候值得采用这种分工

文档关联明确、问题需要读完整过程、生成模型能可靠处理相应长度时，可以评估 LongRAG。若用户主要查询错误码或单条数值，短证据通常已够用。若缺失来源根本没被分进检索单元，扩大 reader 窗口也无法补救。

构造长单元时尤其要检查权限和版本。一个可见片段的命中不能授权读取整组文档；2025 年和 2026 年制度也不应未经标识地拼接。文档删除后，任何包含它的长单元都需要重新发布或过滤，具体流程见企业 RAG 数据工程。

对照实验要同时约束返回 token 和生成模型。只比较固定 top-k，会让一个方案返回五个短块，另一个返回五个长文档组，难以解释质量差异。除了答案准确性，还应检查所需来源是否齐全、引用是否能定位，以及读长单元增加的延迟和费用。若长单元召回改善但最终答案没有改善，应先检查 reader 的证据定位能力，而不是继续增加输入长度。

原始参考：LongRAG 论文；作者项目页。