RAPTOR递归摘要检索评测：层次索引如何降低Token开销

一、评测概述

检索增强生成（RAG）系统在落地过程中常遇到一对矛盾：为了提升召回率而增大检索范围，会推高上下文Token消耗；为了控制成本而压缩上下文，又容易丢失跨文档的宏观语义。递归抽象检索（RAPTOR，Recursive Abstractive Processing for Tree-Organized Retrieval）针对的正是这一矛盾——它不改变查询侧的交互方式，而是通过构建层次化索引，让知识库同时保留细节块与高层摘要，从而在检索阶段按需取用不同抽象层级的内容。

本文的评测对象是RAPTOR这一索引构建与检索范式，而非某个具体产品。评测目标是回答三个问题：该方案的索引结构是否真正覆盖典型RAG需求；它在什么条件下可能降低Token开销；引入它的构建成本与运维复杂度是否可接受。本文适合开发者、系统架构师、技术负责人及负责RAG系统选型与容量规划的运维人员参考。

需要强调的是，本文不做“好/不好”的绝对判断。RAPTOR的价值高度依赖语料特征、查询分布和成本结构，脱离场景的结论没有意义。下文给出的是一套可复现的评测框架，读者应结合自有数据完成验证。

二、评测对象说明

RAPTOR的核心思想可概括为“聚类—摘要—递归”三步循环：

1. 叶节点构建：将原始文档切分为细粒度文本块，作为树的叶子节点，保留最基础的细节信息。
2. 聚类与摘要：对同层文本块按语义相似度聚类，为每个簇生成摘要，形成更高一层的抽象节点。
3. 递归向上：对新生成的摘要重复聚类与摘要，直至形成能代表整个语料的根节点。

最终得到一棵多层知识树，检索时可同时命中叶子细节与高层摘要。其宣称的收益是：在不增加查询复杂度的前提下提升检索性能，并可能显著减少生成阶段所需的Token量。评测需要验证的，正是这些收益在何种条件下成立。

三、评测维度设计

评测框架应覆盖以下维度，每个维度都需给出可观察指标，而非笼统印象。

维度	关注点	可观察指标
功能完整性	树构建、多层检索、摘要质量	层级是否完整、检索是否可指定层级
检索有效性	召回与答案相关性	命中率、答案正确率、跨文档问题表现
Token成本	上下文开销	单次查询平均输入Token、总消耗对比
构建复杂度	索引生成成本	构建耗时、摘要调用次数、人工调参量
稳定性	长周期与异常输入	构建失败率、检索超时、摘要漂移
易用性	接入与调试	配置项数量、日志可读性、改造成本
可维护性	增量更新	新文档插入后的重建范围、一致性

其中Token成本是最需要谨慎对待的维度。原始材料提到“可能少用70%Token”，这是一个依赖语料与查询分布的相对值，不能直接当作通用结论。评测时应以自身基线为准。

四、评测环境与前提

在开始测试前，需要固定以下条件，否则对比结果不可信：

• 语料规模与结构：记录文档数量、平均长度、主题集中度。主题越分散，聚类效果越难保证。
• 切块策略：固定块大小与重叠比例，避免切块差异干扰结论。
• 摘要模型与参数：摘要质量直接决定上层节点可用性，需记录所用模型类别与生成长度约束。
• 检索配置：固定向量化方式、相似度度量、返回条数Top-K。
• 基线系统：准备一个仅使用扁平切块的常规RAG作为对照，所有对比在同一硬件与网络条件下进行。
• 查询集：准备三类查询——单文档细节型、跨文档归纳型、宏观概念型，分别观察表现差异。

五、评测方法

5.1 功能验证

先验证树结构是否按预期生成：检查层级数量、每层节点数分布、是否存在空簇或退化簇。可用如下伪代码记录结构指标：

for level in tree.levels:
    record(level.id, node_count(level), avg_cluster_size(level))
    assert node_count(level) > 0

若某层节点数骤降或摘要长度异常，说明聚类参数或摘要约束需要调整。

5.2 检索有效性测试

对三类查询分别统计：命中叶子节点比例、命中上层摘要比例、最终答案正确率。跨文档归纳型查询是RAPTOR的主要受益场景，应重点观察其相对基线的提升幅度。若提升不明显，需检查摘要是否丢失关键实体。

5.3 Token成本测量

记录每次查询送入生成模型的上下文Token数，分别统计基线与RAPTOR方案的平均值与分位数。注意区分“检索阶段消耗”与“生成阶段消耗”，前者包含摘要构建的离线成本，后者才是查询侧的直接开销。70%这类数字若出现，应核对其统计口径是单次查询还是含构建摊销。

5.4 稳定性与异常测试

• 输入含大量重复或极短文档时，观察聚类是否退化；
• 模拟摘要服务超时或返回空内容，验证构建流程是否有重试与降级；
• 长时间运行后检查索引一致性，尤其是增量插入场景。

5.5 易用性与可维护性评估

记录接入所需改动点数量、配置项复杂度、日志是否能定位到具体层级节点。增量更新是常见痛点：新文档插入后是否需要全量重建树，直接影响长期运维成本，应作为独立测试项。

六、结果解读

解读结果时需注意因果归因。Token下降可能来自两个不同机制：一是高层摘要替代了长上下文，二是检索更精准导致返回条数减少。两者对系统的影响不同，前者依赖摘要质量，后者依赖检索精度，应分别分析。

检索有效性的提升若主要集中在跨文档查询，说明层次索引确实补足了扁平检索的短板；若细节型查询反而下降，可能是摘要层干扰了排序，需要调整层级权重。任何结论都应标注适用条件，例如“在主题集中、文档较长的语料上观察到成本下降”，而非推广为普遍规律。

七、适用场景与风险边界

较适配的场景：文档量大、主题有成簇结构、查询中包含较多归纳与跨文档问题、生成成本占比较高的RAG系统。

需谨慎的场景：语料频繁变动导致重建成本高、查询以精确细节为主、摘要模型能力不足导致上层节点失真、对延迟极敏感且无法接受多层检索开销的场景。

主要风险包括：摘要漂移造成信息损失、聚类参数敏感导致结构不稳定、构建阶段的离线成本被低估、增量更新引发索引不一致。这些风险应在选型前通过小规模试点量化，而非直接全量上线。

八、选型与使用建议

建议采用“基线对照+分场景验证”的方式推进：先在代表性语料子集上构建RAPTOR索引，与扁平基线在相同查询集上对比Token与正确率；再针对增量更新与异常输入做稳定性压测；最后根据自身成本结构判断收益是否覆盖构建与运维投入。若摘要质量是瓶颈，可优先优化切块与摘要约束，而非盲目增加层级。是否引入应基于实测数据做条件化决策，而非依赖单一百分比结论。