在大语言模型（LLMs）主导的AI时代，“检索增强”早已成为提升模型事实准确性、降低幻觉的核心技术。然而，当前主流的检索方法仍面临一个关键瓶颈：无论是传统的BM25、基于深度学习的DPR，还是新兴的LLM检索器，大多依赖“文本分块+单一维度匹配”的模式，难以捕捉长文本（如学术论文、书籍章节）中的层次化语义结构——要么因只取片段丢失上下文，要么因过度抽象遗漏关键细节。
斯坦福大学团队在2024年ICLR提出RAPTOR（Recursive Abstractive Processing for Tree-Organized Retrieval），用“递归树状检索”的新思路打破了这一困境。通过构建多层级的文本语义树，同时保留高层主题框架与低层细节信息，在NarrativeQA、QASPER等多个权威数据集上刷新SOTA，为长文本检索提供了全新范式。
01、检索增强的“痛点”：为什么现有方法处理长文本力不从心？
在深入RAPTOR之前，我们先梳理当前检索技术的发展现状与核心局限，理解RAPTOR解决的核心问题。
检索方法的演进与瓶颈
检索增强语言模型（RALMs）的发展可概括为“从词项匹配到语义理解”的跃迁：
- 传统阶段：依赖TF-IDF、BM25等基于词频的技术，仅能捕捉字面匹配，无法理解语义关联；
- 深度学习阶段：DPR（密集段落检索）等模型用BERT类编码器将文本转化为向量，通过余弦相似度匹配语义，但仍需将长文本切分为固定长度的片段（如512token）；
- LLM检索阶段：部分研究直接用LLM作为检索器（如GPT-4作为重排序器），但仍未解决“片段化检索”的本质问题。
尽管技术不断升级，现有方法的核心局限始终存在：
对语料库“分块编码+单一层次匹配”的模式，无法捕捉长文本的层次化语义。例如，一篇学术论文包含“摘要-引言-方法-实验-结论”的结构，一个技术文档包含“总览-步骤-注意事项”的逻辑，现有检索若只取其中一个片段，要么丢失整体框架（如只取“实验结果”却不知对应的“方法设计”），要么因片段孤立导致理解偏差（如断章取义的技术描述）。
摘要技术的补位与不足
为解决长文本理解问题，摘要技术（尤其是递归抽象摘要）曾被寄予厚望：通过将长文本拆分为小块、分别摘要，再整合为更高层次的摘要，形成“片段→局部摘要→全局摘要”的递进。
但这种方法的缺陷同样明显：过度追求“浓缩”而丢失细粒度细节。例如，一篇论文的“方法部分”摘要可能只提到“用了GMM聚类”，却遗漏“用UMAP降维缓解高维问题”的关键细节——而这些细节恰恰是回答“该方法如何处理高维数据”这类问题的核心。
正是这些痛点，催生了RAPTOR的设计：能否用一种结构，同时保留长文本的“高层主题框架”与“低层细节信息”，让检索既能匹配整体语义，又能定位关键细节？
02、RAPTOR核心设计：用“递归树”重构长文本语义
RAPTOR的核心思想非常直观：长文本天然具有层次化结构（如“书→章节→段落→句子”），因此可以用“树”这种数据结构来建模其语义关系。树的叶子节点对应原始文本片段，中间节点对应片段的摘要，根节点对应全局摘要。通过这种结构，检索时可根据问题的粒度，灵活匹配不同层级的节点，实现“宏观主题”与“微观细节”的兼顾。
四步构建RAPTOR树：从文本片段到语义层次
RAPTOR树的构建是一个“分块→嵌入→聚类→摘要”的递归过程，直到无法继续聚类为止，具体步骤如下：
步骤1：文本分块，保证语义连贯
首先将原始语料库分割为100token的短文本块（长度可调整），但有一个关键优化：若某句话超过100token，不截断句子，而是将整句话移至下一个块。这种处理避免了“句子被劈成两半”的问题，确保每个块的语义完整性。
步骤2：SBERT嵌入，生成语义向量
用multi-qa-mpnet-base-cos-v1（SBERT家族中检索性能最优的模型之一）对每个文本块进行编码，生成768维的语义向量。这些文本块及其向量，构成了RAPTOR树的叶子节点。
步骤3：软聚类，按语义分组
对叶子节点的向量进行“软聚类”（节点可属于多个簇），而非传统的“硬聚类”（节点仅属一个簇）。原因很简单：一个文本块可能包含多个主题（如“实验结果”块可能同时涉及“数据集A”和“指标B”），软聚类能更真实地反映语义关联。
聚类过程中，RAPTOR解决了两个关键问题：
- 高维向量聚类难：用UMAP对768维向量降维，平衡局部与全局语义结构（通过调整n_neighbors参数，先找全局簇，再在全局簇内找局部簇）；
- 簇数如何确定：用贝叶斯信息准则（BIC） 选择最优簇数——BIC既考虑聚类拟合度，又惩罚簇数过多导致的过拟合，避免“为了聚类而聚类”。
步骤4：LLM摘要，生成父节点
对每个聚类后的簇，用GPT-3.5-turbo生成摘要（摘要长度可控制），再将摘要用SBERT编码，作为该簇的“父节点”。
递归循环，构建多层树
将生成的父节点视为新的“文本块”，重复“嵌入→聚类→摘要”的过程，生成更高层级的父节点，直到某个层级的节点数过少（无法继续聚类）为止。最终形成的树结构，从下到上是“原始片段→局部摘要→全局摘要”，从上到下则是“全局主题→局部细节→原始片段”。
下图清晰展示了RAPTOR树的构建过程，左侧为文本块，右侧为聚类后的摘要节点，层层递进形成层次：
值得注意的是，RAPTOR的构建效率很高——构建时间和token消耗均呈线性扩展，即使处理百万级token的大型语料库，也不会出现指数级耗时。
两种查询策略：按需匹配语义粒度
有了树结构，如何根据问题找到最相关的节点？RAPTOR设计了两种互补的查询策略，适配不同的问题类型：
策略1：树遍历（Tree Traversal）——从宏观到微观的精准定位
适合需要“逐步聚焦”的问题（如“RAPTOR的聚类方法如何处理高维向量？”），步骤如下：
- 从树的根节点开始，计算查询向量与所有根节点的余弦相似度，选择Top-k个最相关节点（如k=3）；
- 进入这k个节点的子节点，再次计算相似度并选Top-k；
- 递归向下，直到到达叶子节点；
- 将所有选中的节点（根→中间→叶子）的文本拼接，作为检索上下文。
这种方式的优势是“可控性强”——通过调整遍历深度（d）和每步的k值，可以精准控制“宏观主题”与“微观细节”的比例，例如深度越大、k值越大，越偏向细节。
策略2：折叠树（Collapsed Tree）——全局匹配，灵活选优
适合需要“跨层级匹配”的问题（如“灰姑娘故事中，玻璃鞋是如何帮助王子找到灰姑娘的？”），步骤更简洁：
- 将RAPTOR树的所有层级节点“摊平”为单层（无论根节点、中间节点还是叶子节点，都放在同一集合中）；
- 计算查询向量与该集合中所有节点的相似度，按相似度排序；
- 依次选择节点，直到总token数达到预设阈值（如2000token），停止选择。
这种方式的核心优势是“灵活性”——无需固定层级顺序，直接从所有节点中选最相关的，自动适配问题的粒度。例如，回答“故事主题”可能选根节点，回答“具体情节”可能选叶子节点，回答“章节概要”可能选中层节点。
哪种策略更好？实验给出答案
斯坦福团队在QASPER数据集的20个案例上测试发现：折叠树策略的性能始终更优。原因在于，树遍历的“每层Top-k”模式会固定“主题-细节”比例，而折叠树能根据问题灵活调整——例如，一个需要细节的问题，折叠树会优先选叶子节点；一个需要框架的问题，会优先选根节点，无需人工调整参数。
不过，折叠树需要对所有节点计算相似度，看似耗时，但通过FAISS等快速近邻库优化后，效率可满足实际需求。因此，RAPTOR在后续实验中默认采用折叠树策略。
03、实验验证：刷新3大权威数据集SOTA
为验证RAPTOR的有效性，斯坦福团队在NarrativeQA（书籍/剧本问答）、QASPER（学术论文问答）、QuALITY（长文本多项选择） 三个代表性数据集上进行了全面实验，对比了BM25、DPR等传统检索方法，并与当前SOTA模型（如CoLT5、CoLISA）对标。
核心结论1：RAPTOR与任何检索器结合都能提升性能
首先对比“有无RAPTOR树结构”的差异——将SBERT、BM25、DPR分别作为基础检索器，在“直接检索”和“结合RAPTOR树”两种模式下测试：
结果非常明确：无论基础检索器是传统的BM25，还是深度学习的DPR/SBERT，结合RAPTOR树后性能均有显著提升。其中，SBERT+RAPTOR的组合表现最优，说明RAPTOR的树结构能更好地与语义嵌入检索器结合，放大语义匹配的优势。
将RAPTOR与BM25和DPR进行比较，使用三种不同的LLM：GPT-3、GPT-4和UnifiedQA。如表3所示，RAPTOR在QASPER数据集上的所有三种语言模型中始终优于BM25和DPR。QASPER要求综合NLP论文中的信息，因此RAPTOR的高级摘要节点使其能够超越只能提取前k个最相似原始文本块的方法，这些原始文本块可能单独不包含正确的响应。
核心结论2：碾压传统检索，刷新SOTA
在对照比较的基础上，比较RAPTOR相对于其他最先进模型的性能。
- QASPER：如表5所示，带有GPT-4的RAPTOR在QASPER上设定了新的基准，F-1分数为55.7%，超过了CoLT5 XL的53.9%的分数。
- QuALITY：如表7所示，与GPT-4配对的RAPTOR以82.6%的准确率设定了新的最先进水平，超过了之前的最佳结果62.3%。特别是在QuALITY-HARD子集上，RAPTOR比CoLISA高出21.5%，这代表了人类需要异常长的时间才能正确回答的问题，需要重读部分文本、困难的推理或两者兼而有之。
- NarrativeQA：如表6所示，与UnifiedQA配对的RAPTOR设定了新的最先进的METEOR分数。与同样使用UnifiedQA的Recursively Summarizing Books递归摘要模型相比，RAPTOR在所有指标上都优于它。虽然Recursively Summarizing Books仅依赖于树结构顶部根节点的摘要，但RAPTOR受益于其中间层和聚类方法，这使其能够捕获从一般主题到特定细节的一系列信息，有助于其整体强劲表现。
定性分析：RAPTOR如何处理复杂问题？
为更直观理解RAPTOR的优势，我们以“灰姑娘故事问答”为例，对比RAPTOR与DPR的检索结果：
- 问题：“灰姑娘是如何找到幸福结局的？”
- DPR检索结果：返回与“幸福结局”字面匹配的2-3个片段（如“王子与灰姑娘结婚”），但缺少“南瓜马车、玻璃鞋、午夜时限”等关键情节，导致回答不完整；
- RAPTOR检索结果：自动选择3个节点——1个根节点（故事主题：“善良终将获得回报”）、2个叶子节点（“王子用玻璃鞋找到灰姑娘”“仙女教母提供帮助”），拼接后形成“主题+细节”的完整上下文，回答更全面。
这一案例完美体现了RAPTOR的核心价值：通过树结构整合不同层级的信息，既不丢失全局逻辑，又不遗漏关键细节。
树结构的贡献
检查树的每一层节点对RAPTOR检索能力的贡献。假设上层节点在处理需要对文本有更广泛理解的主题或多跳查询时起着关键作用。
通过定量和定性方法验证了这一假设。使用QuALITY数据集的故事进行定量分析，为每个故事构建RAPTOR树。然而，在检索期间，将搜索限制在不同的层子集。例如，专门从叶节点和每个上层检索，以及从不同的连续层子集检索。在表8中展示了针对一个故事的具体发现，揭示了使用所有层的全树搜索优于仅关注特定层的检索策略。
这些发现突出了RAPTOR中全树结构的重要性。通过为检索提供原始文本和高级摘要，RAPTOR可以有效处理从高阶主题查询到面向细节的问题的更广泛的问题。
04、总结与展望：RAPTOR的价值与未来方向
RAPTOR的创新之处，在于跳出了“分块检索”的传统框架，用“递归树”建模长文本的层次化语义，为长文本检索提供了新范式。其核心贡献可概括为三点：
- 结构创新：通过“聚类-摘要”递归构建语义树，平衡“宏观主题”与“微观细节”；
- 策略灵活：折叠树查询自动适配问题粒度，无需人工调整层级参数；
- 性能卓越：在3大权威数据集上刷新SOTA，尤其擅长复杂多跳问答。
当然，RAPTOR仍有可探索的方向：
缺乏 “简单任务” 与朴素 RAG 的对比，适用性边界不清晰
RAPTOR 的实验集中于 “复杂多跳问答”，但未与朴素 RAG（如 “分块 + DPR+LLM”） 在 “简单任务” 中进行对比 —— 所谓简单任务，指无需跨片段推理、仅需定位单一信息的场景，例如：
- FAQ 问答（如 “企业报销流程的截止日期是什么？”）；
- 事实提取（如 “某篇论文使用的数据集样本量是多少？”）；
- 短文本匹配（如 “查找与‘Transformer 结构’相关的段落”）。
对于这类任务，RAPTOR 的层次树结构可能存在 “冗余”：
- 构建树需要额外的聚类、摘要步骤，增加了预处理时间；
- 折叠树查询需遍历所有层级节点，可能比朴素 RAG 的 “直接匹配片段” 更耗时；
- 若问题仅需单一细节，RAPTOR 检索到的 “中层 / 顶层摘要” 反而可能干扰 LLM 的判断（如回答 “样本量” 时，摘要中的 “数据集概况” 可能引入无关信息）。
缺乏这一对比，导致我们无法明确 RAPTOR 的 “适用性边界”—— 它究竟是 “复杂任务专属优化”，还是 “所有检索场景都适用”？这一问题对实际落地（如企业知识库选型）至关重要。
未与 “图结构检索（如 GraphRAG）” 对比，结构优势未充分验证
RAPTOR 的核心是 “树结构”，而当前检索领域另一重要方向是 “图结构检索”（如 GraphRAG）——GraphRAG 将文本中的实体、关系（如 “论文作者→使用方法→数据集”）建模为图，通过图遍历实现跨实体的信息检索，尤其擅长处理 “多对多关系”（如 “某方法在哪些数据集中被验证过？”）。
然而，RAPTOR 的论文未将 GraphRAG 作为基线进行对比，无法回答以下关键问题：
- 当任务需要捕捉 “实体间复杂关联” 时（如 “学术领域中，Transformer 与 BERT 的技术演进关系是什么？”），树结构（RAPTOR）与图结构（GraphRAG）哪个更优？
- 树结构的 “层次化” 优势（如快速定位全局主题）与图结构的 “网络化” 优势（如灵活捕捉跨层级关系），是否存在互补空间？
这一缺失不仅影响了 RAPTOR 性能评估的全面性，也未能探讨 “树 - 图融合” 的可能性，是实验设计中的一大遗憾。
落地企业知识库场景，解决实际业务痛点
RAPTOR 的层次树结构天然适配企业知识库的需求 —— 企业知识库通常包含两类内容：
- 结构化知识（如组织架构、流程规范），需要层次化理解；
- 非结构化知识（如技术文档、项目报告），需要跨片段综合。
未来可针对企业场景进行定制化优化：
- 预处理阶段：结合企业知识的 “业务分类”（如 “人力资源”“研发”“财务”）初始化树的顶层节点，减少聚类的盲目性；
- 检索阶段：支持 “按业务层级筛选”（如 “仅检索研发部门的文档”），进一步提升检索效率；
- 更新阶段：设计 “增量树构建” 算法 —— 当知识库新增文档时，无需重建整棵树，仅需将新文档的片段聚类到现有树的对应层级，降低维护成本。
例如，在 “员工培训” 场景中，RAPTOR 可生成 “培训手册的全局摘要（顶层）→各章节核心要点（中层）→具体操作步骤（底层）” 的树结构，员工查询时：
- 想了解整体框架，直接获取顶层摘要；
- 想学习具体步骤，获取底层片段；
- 想理解 “步骤背后的原理”，获取中层摘要与关联片段 —— 这种灵活的检索体验，远优于传统知识库的 “关键词搜索 + 全文定位”。
RAPTOR 并非 “替代传统检索的万能方案”，而是 “针对复杂长文本任务的专项优化”—— 它的核心价值在于证明了 “结构感知” 对检索增强的重要性：未来的检索技术，不应再局限于 “如何优化片段匹配精度”，而应更关注 “如何用更合理的结构组织长文本，让检索更贴合人类理解逻辑”。
无论是后续的 “简单任务对比”“树 - 图融合”，还是 “企业场景落地”，本质都是在回答一个核心问题：如何让检索系统不仅能 “找到信息”，还能 “理解信息的结构与关联”？ 而 RAPTOR 的层次树结构，为这个问题提供了一个极具启发性的答案。
如果你对 RAPTOR 的技术细节感兴趣，可直接查看论文和开源项目：
- 论文地址：arXiv:2401.18059
- 项目地址：github.com/parthsarthi03/raptor
