给「RAG 答不了什么问题」列清单，「需要通读全库才能回答的问题」一定排在前面。「这份年报的核心风险是什么」——答案不在某个段落里，而在一百个段落的聚合里；「过去三个季度成本结构的变化趋势」——需要先分别找到三个季度的数据，再放在一起比较。常规切块检索对这类问题的处理方式很笨拙：查询向量与任何单个块的相似度都不高（查询是「整体性」的，块是「局部性」的），召回回来的块零散拼凑，模型只能管中窥豹。RAPTOR（Sarthi 等人，2024，Recursive Abstractive Processing for Tree-Organized Retrieval）给出的解法是：在「原始分块」之上，用聚类和摘要造出更高层的「可检索单元」，形成一棵从细节到主题的树。
构建方式：聚类、摘要、递归
RAPTOR 的建库流程自底向上三步循环。
第一步，叶子层：常规切块（几百字一块），这是树的底层，与所有 RAG 系统无异。第二步，聚类：把当前层所有块的嵌入向量聚成若干簇（论文用 GMM 软聚类，一个块可以属于多个簇——因为一段文字常常服务多个主题），每一簇就是一组「讲同一件事」的块。第三步，摘要：让大模型把每一簇的内容概括成一段摘要文本，这些摘要文本嵌入向量后构成上一层节点。对上一层重复第二步第三步，直到顶层只剩一两个节点——顶层摘要就是「全书摘要」。
查询时，摘要树的每一层节点都与普通块一样参与向量检索：问「年报核心风险」，顶层和第二层的摘要节点（它们本身就是对「风险相关内容簇」的概括）天然与查询高相似，直接命中；问「某条款的具体数字」，底层原始块命中。一次检索可以拿回不同层级的节点，高层给骨架、低层给证据，模型既有全局视野又有具体依据。
和 GraphRAG 的分工：两条不同的「上层建筑」
本系列之前讲过 GraphRAG（《GraphRAG 与知识图谱》）：从文本抽取实体与关系，构图后用社区摘要回答多跳问题。RAPTOR 和 GraphRAG 常被并列提及，因为都在「原始分块之上加了一层结构」，但上层建筑的材料不同，擅长的问题也不同。
GraphRAG 建的是「关系网」：它的强项是多跳——「A 公司的 CEO 投资过哪些做 B 技术的公司」需要沿实体关系走两三步。RAPTOR 建的是「主题树」：它的强项是聚合概括——「整份文档讲了什么」「这部分内容的主旨」不需要跳转，需要的是把散落的内容压缩成一个观点。一句话分工：问题需要「沿着关系走」，用 GraphRAG；问题需要「把散点收拢」，用 RAPTOR。两者不互斥，复杂系统可以并存，索引成本允许的话。
构建成本与维护代价
RAPTOR 的账单主要在建库。摘要生成的 token 费：每一层的每个簇都要一次大模型摘要调用，层数 × 簇数就是调用总量，十万级块的语料建一棵三层的树，摘要费用可能超过全库嵌入的费用好几倍——这是它和普通 RAG 最大的成本差异。聚类质量决定树质量：簇切得乱（一个簇横跨三个主题），摘要就成了大杂烩，上层节点反而引入噪声。簇数是关键超参：太多则每层退化成原块数量、摘要失去聚合价值；太少则单簇内容过杂、摘要失真。维护级联：文档更新时，受影响的簇要重新摘要、上层节点级联重建（《增量更新与模型迁移》讲的级联失效在这里被放大——动一个块可能牵动整条枝）。缓解办法是把树的粒度放粗：只对章节级建两层树，不做全书级深树，摘要成本和维护半径都可控。
聚类与打分的实现细节
建树的两个技术环节值得展开。聚类：论文用 GMM 软聚类（一个块可属多簇），开源实现里 k-means 硬聚类也够用——软聚类的优势在「边界话题」（一段同时讲两个主题），硬聚类会把它强行归一边，摘要失真。簇数的自适应比固定簇数好用：按层内块数动态定（如每簇目标 5～10 个子节点），浅层少簇、深层多簇自然形成宽底窄顶的树形。摘要 prompt 里要给聚合视角的指令（「概括这些片段共同讲述的主题与结论，不要逐条罗列」）——摘要的目的是「压缩出上一层概念」，逐条罗列产出的摘要只是把叶子层复述一遍，检索价值趋零。检索侧的层间混合：摘要节点与叶子块在同一次向量检索里直接比分数有个隐患——摘要的嵌入是「概括语义」，与「整体性查询」天然高相似，叶子块常被系统性压过；缓解是给两路分别召回（摘要节点路 + 叶子路各取若干），融合层合并（《混合检索》的 RRF 对此很友好），保证「骨架」与「证据」都进上下文。
两档轻量替代
完整 RAPTOR 之前，两档更便宜的替代值得先试。第一档：全库/章节摘要文档——离线生成一份「本知识库讲了什么」的摘要文档，连同各章节摘要，作为普通文档入库。它们会被常规检索自然命中（聚合型查询与它们的相似度天然高），实现成本是「几次摘要调用」，维护成本接近零（《增量更新》里它只是一份普通文档，定期重生成即可）。大量场景里这个土办法就能接住八成的聚合型查询。第二档：两层树——只对章节级建一层摘要节点（章节摘要 → 挂在该章节的块上，检索命中块时可顺带返回章节摘要作上下文），不做全书级递归。它放弃了「全书摘要节点」，但保留了「块命中时自带主题骨架」的主要收益，成本只有完整树的一小角。先土办法验证「聚合型查询确实高频且现有方案确实接不住」，再投入完整 RAPTOR——这是与 GraphRAG 同款的落地纪律。
与父子检索的组合
RAPTOR 的摘要节点和《父子检索》的父块在流水线里可以协同：摘要节点当「超父块」用——叶子块命中后，除了取父块（段落级完整上下文），还可以把所在簇的摘要节点一并带上（它概括了这一片内容讲什么），模型拿到「局部完整证据 + 全局主题定位」，对长文档的问答质量提升明显。组合的预算代价是每条证据多带一段摘要（几百字），用《上下文组装》的预算表管理：摘要节点放「补充证据区」，强证据仍以父块为主。这个组合本质上是「给证据配地图」，对手册、规章这类层级感强的语料尤其有效。
适用边界
三种情况值得上 RAPTOR。文档有「全局可问答性」：研究报告、书籍、长政策文件——用户真的会问「整体」「趋势」「主旨」类问题。检索评估里「聚合型查询」召回差：如果你的测试集里这类查询的命中质量系统性偏低（《评测集构建》的分型里就该有一类「聚合题」），RAPTOR 是对症药。上下文预算允许装下高层摘要：摘要节点本身是几百字的「高密度上下文」，性价比很高。
两种情况别上：FAQ 式语料——问题和答案一一对应，不存在「聚合」，建树纯属烧钱；语料高频更新——摘要树的级联维护成本会吞掉它的收益，先考虑更粗粒度的替代（比如定期离线生成一份「全库摘要」文档单独入库，同样能被检索，维护成本几乎为零——这是许多团队的务实折中）。
摘要的质控
摘要树的质量上限取决于摘要本身的质量，三个质控点。长度锚点：摘要 prompt 除聚合视角指令外要给字数区间（「控制在 150 到 300 字」）——无锚点的摘要要么啰嗦成第二份原文，要么短得丢失区分度。抽样人审：每层抽 5% 摘要人工过目，重点看「摘要是否真的比叶子更抽象」——逐条罗列的伪摘要是上层节点的常见病。层级语义梯度检查：顶层摘要与中层摘要的嵌入相似度过高，说明上层没有增量信息，纯属浪费索引与预算。质控不过的层宁可砍掉——一棵两层但每层都抽象到位的树，检索价值高于三层但上层是大杂烩的树。
建库的批处理调度
摘要树的构建是离线批任务，调度上有三个要点。成本封顶：聚类加摘要的调用费按「层数 × 簇数」估算后设硬上限，超限即停并告警——聚簇数失控（数据分布意外导致簇暴增）是建库成本失控的头号原因，预算闸门必须在。分章构建：全库一次建树不如按章节分别建子树——章节是天然的批处理单元，失败的章节单独重跑不影响全局，语料更新时也只有受影响章节需要重建（《增量更新》的级联半径从全库缩到单章）。产物校验：建树完成后跑结构校验（每层节点数、每簇子节点数、摘要长度分布），异常分布（某层节点数暴增、摘要全是超短句）直接暴露聚类或摘要 prompt 的问题——校验脚本几十行，省掉的是上线后「为什么顶层摘要答非所问」的排查日。三件事把摘要树从「一次性的大手笔」变成「可控的常规离线任务」。
小结
RAPTOR 补上了切块检索最深的短板：检索粒度永远是局部的，而用户的问题有时是全局的。递归聚类加摘要，把「散落的局部」压缩成「可检索的主题节点」，让「全书级问题」有了直接的命中对象。它的成本与 GraphRAG 同级（都贵在建库的结构化加工），两者按问题类型分工——收拢散点用树、沿关系跳转用图；轻量场景则可以先用「全库摘要文档」这种一折的土办法顶住聚合型查询，需求验证了再上完整的树。
参考资料
- Sarthi et al., RAPTOR (arXiv:2401.18059) —— 递归聚类摘要树的原始论文与 QuALITY 基准实验
- LlamaIndex: Document Summary Index —— 摘要索引的轻量实现形态
- 本系列前篇：《GraphRAG 与知识图谱》《RAG 切块策略实战》《评测集构建》《增量更新与模型迁移》
读者留言
COMMENTS 暂无还没有留言，来说第一句？