摘要索引与 RAPTOR：让跨章节主题也能被检索
什么是 RAPTOR
RAPTOR 是一种用于 RAG 的多层摘要检索方法，全称为 Recursive Abstractive Processing for Tree-Organized Retrieval。它将原文片段和逐层生成的摘要组织成树状索引，让检索器既能查找具体细节，也能查找跨段落、跨章节的概括性信息。
它主要做两件事：
- 建库时生成多层摘要。 将原文切块并生成向量，把内容相关的块聚成组，为每组生成摘要；再对摘要重复聚类和摘要，形成更高层的概括。原文块与各层摘要都保留在索引中。
- 提问时检索不同层级的内容。 根据问题，从原文块和摘要节点中选取相关内容，交给回答模型。具体问题可以匹配原文，综合性问题则可以利用摘要中已经整理好的跨段信息。
为什么需要多层摘要
假设一份设备运维手册有三个章节：断网时如何缓存遥测、磁盘不足时怎样轮换日志、恢复连接后如何补传数据。用户问“离线运行会带来哪些数据完整性风险？”答案需要把几章连起来，原文却未必有一段直接使用“数据完整性风险”这个概括。
直接检索原文块时，系统需要分别找到缓存、删除和补传的内容，才能凑齐回答依据。RAPTOR 在建库时把相关片段聚合成摘要，使“离线数据完整性”这样的主题也有可匹配的文本。
只为整份手册生成一段摘要，可能会省略某个风险或具体错误码。多层索引则同时保留原文细节、局部主题摘要和更高层概括，供不同问题检索。
RAPTOR 怎样建立摘要层
RAPTOR 把原文块作为最底层的叶子节点，先将内容相关的叶子分组，再为每组生成摘要。这些摘要成为新节点，继续分组、生成更高层摘要；反复执行后，就得到从具体段落到概括主题的多层索引。每一层节点都有自己的文本和向量，检索时都可以使用。
这几段运维说明可以形成下面的摘要层级：
原文叶子 L1：断网后遥测写入本地队列。
原文叶子 L2：磁盘不足可能清除尚未补传的数据。
原文叶子 L3：恢复连接后，按序号补传并去重。
摘要 S1 ← L1、L2：离线缓存受本地容量限制，可能发生数据丢失。
摘要 S2 ← L2、L3：补传依赖本地保留数据及序号去重。
上层摘要 S3 ← S1、S2：离线数据完整性涉及容量、保留和恢复同步。L2 同时参与了 S1 和 S2：同一段内容可能涉及多个主题，因此 RAPTOR 允许一个节点属于多个组。虽然方法名称使用“树”，保存来源关系时仍要允许多个父节点。每个摘要保存成员 ID，才能继续找到原始叶子。
这与按目录组织的父子块不同。父子块通常沿原有章节恢复上下文；RAPTOR 的簇由内容相似性形成，可能跨章节甚至跨文档，父节点内容则由模型生成。
相关片段怎样分组
分组依据来自文本的 embedding。论文使用 UMAP 降维，再用 Gaussian Mixture Model（GMM，高斯混合模型）聚类，并通过 BIC（贝叶斯信息准则）在候选聚类数中选择模型。UMAP 降低后续聚类的维度；GMM 给出节点属于各个簇的概率，系统按概率阈值确定归属，所以可以保留一个节点与多个主题的联系。这称为软聚类。
一轮聚类中还包含全局聚类和簇内局部聚类；某组内容超过摘要模型的输入预算时，会继续拆分。完成分组后，模型读取组内文本、生成摘要，下一轮便以这些摘要为输入重复处理，直到达到设定的层数或剩余节点无法继续有效聚合。
检索时可以沿层级走，也可以同时查各层
论文讨论两种策略。Tree traversal 从较高层开始，选相关节点，再在其后代中逐层筛选。它能缩小后续搜索范围，但上层摘要若漏掉关键主题，一次错误选择可能让相关叶子失去机会。
Collapsed tree 把所有层级节点放进同一个候选集合，直接按问题相关性选取，并受 token 预算约束。用户问容量上限时，原文叶子可以直接胜出；问离线风险时，主题摘要也可进入上下文。它不会强制每次查询先命中根节点。
| 问题 | 可能有用的节点 | 还需核查什么 |
|---|---|---|
| 离线运行有哪些数据风险？ | S1、S2 或 S3 | 摘要概括是否保留各条件 |
| 磁盘不足时哪些数据会被清除？ | L2 及相邻原文 | 清除规则的准确范围 |
| 补传为什么还需要去重？ | L3 | 原文给出的重试或重复来源 |
摘要与叶子一起入选可能产生内容重叠。工程实现可按来源覆盖去重，或者命中摘要后下钻验证具体事实。论文允许摘要节点直接进入回答上下文；在此基础上增加下钻回源，可以检查摘要中的具体结论是否有原文支持。
摘要带来了新入口，也引入了信息损失
如果原文说“容量不足时可能清除”，摘要写成“离线数据会丢失”，条件与不确定性就变了。更高层再次摘要，还可能继续放大这个错误。涉及数字、否定、例外的结论，应检查其对应叶子，不能仅因为摘要节点带了来源 ID 就认定引用正确。
跨叶子摘要的权限也来自全部贡献来源。不能因为某个可见叶子命中了摘要，就让用户读到同一摘要吸收的受限内容。工程上应在权限兼容的范围内聚类和摘要，或要求查询者有权访问所有贡献来源；否则需按可见来源重新计算摘要，不能只在回答末尾隐藏引用。
摘要生成和聚类也增加了离线成本。叶子修改后，它参与的多个簇都可能受到影响；重新聚类甚至会改变其他节点归属。更新频繁的知识库，可以先维护普通 chunk 实时索引，再周期重建摘要层，但这是需要明确新鲜度策略的工程折中。版本和依赖处理见企业 RAG 数据工程。
验证 RAPTOR 时，应把局部事实题和跨章节归纳题分开。与原文检索使用相同的生成模型和接近的上下文预算，观察新增摘要是否让必要来源更完整，同时抽查摘要是否错误合并主体或删除限定。若问题大多能由一段原文回答，额外摘要层未必值得维护。