RAPTOR 是什么？树状摘要检索和普通向量 RAG 有什么区别？

知识点详解：一份长资料，为什么需要几种阅读尺度？

原文片段擅长回答局部问题

假设知识库里有一本部署手册，分别介绍网络、存储、备份和故障处理。

用户问“备份文件保留几天”，检索到对应条款就能回答。但用户问“整套方案如何在故障后恢复”，可能需要把多个章节联系起来。

将所有资料切成很小的片段，能保留局部细节，却可能让整体关系分散在很多候选里。把 Chunk 全部放大，又会增加噪声和上下文成本。

RAPTOR 的思路不是只调切分长度，而是在原文之上增加不同尺度的概括。这个教学例子用于解释需求，不是论文中的实测案例。

从片段到摘要，再从摘要到更高层概括

假设底层有网络、存储、恢复等片段。

系统先根据内容表示，将相关片段聚集起来，为每组生成摘要。随后再把这些摘要作为下一轮处理对象，继续聚类和生成摘要。

这样，底层接近具体条款，中间层概括一组相关内容，更高层覆盖更大的主题。构建过程中保留关联关系，后续可以沿这些关系找到支撑摘要的内容。

论文采用的聚类机制允许内容与多个主题相关，不能把它简化成“每个段落严格属于一个目录”。这也不是知识图谱：摘要层级不等于实体和关系的三元组。RAPTOR 原论文

查树，不只有从树根一路往下走

一种思路是从较高层开始，逐层寻找有关的下层内容。另一种思路是把多个层级的节点放在同一检索空间，直接检索合适的节点；论文讨论了树遍历与折叠树检索。

所以，“建立了树”不代表每次查询都必须从根节点开始。

用户问整体恢复策略，可以取得较高层概括；问某条具体限制，就可能直接拿到底层片段。选哪种检索方式，要看问题类型和实际结果，而不是树画得多漂亮。

摘要能帮助检索，不能替代所有证据

假设原文写“只有启用某项配置后，才支持自动恢复”，摘要却只留下“支持自动恢复”。

检索到摘要后，模型可能把有条件的能力说成默认能力。这类错误未必能通过提高向量相似度解决，因为摘要本身已经漏掉条件。

因此，要保存摘要到原文的追溯关系。回答精确数值、权限规则和操作限制时，核对对应原文；无法找到支撑内容，就不要把摘要当成充分证据。

更新也更复杂。一条底层规则改变，相关上层摘要可能过时。需要记录资料版本，识别受影响的摘要并重建，而不是只替换底层向量就结束。

面试官继续追问

把整个文件只总结一次，可以算 RAPTOR 吗？

不能把所有“原文加摘要”都叫 RAPTOR。这里的关键是递归聚类与摘要产生的多层结构，单次整文摘要只是另一种组织方式。

高层摘要检索很准，是不是只返回摘要就够了？

要看问题。概览问题可以使用概括，但精确事实仍需原文支撑。高层节点相似，并不证明它保留了回答所需的所有条件。

怎样评测是否值得用？

分别准备局部事实题和跨段综合题，再比较正确证据、答案完整性、错误概括、查询延迟和更新成本。不能把某类问题的收益当成所有问题的收益。

面试速记卡

• 构建：片段嵌入、聚类、摘要，再递归形成多层结构。
• 检索对象：既有原文片段，也有不同尺度的摘要。
• 查询方式：可以逐层遍历，也可以跨层检索。
• 风险：摘要可能丢失条件，精确回答要追溯原文。
• 维护：原文更新可能影响相关上层摘要和索引。