RAPTOR: Hierarchical Summarisation for Retrieval
Recursive clustering and summarisation into a tree, and the question types it is built for.
RAPTOR (Recursive Abstractive Processing for Tree-Organized Retrieval; Sarthi et al., 2024) builds a tree of clustered summaries over a corpus so retrieval can return either a high-level theme or a leaf-detail by question breadth.
What is RAPTOR?
RAPTOR is a retrieval architecture that recursively embeds, clusters and summarises text chunks into a multi-layer tree, where leaves store raw chunks and internal parents store abstractive summaries of clusters (Sarthi et al., 2024; arXiv:2401.18059). The paper’s method lets a query pull context at more than one abstraction level, whereas naive top-k retrieve-then-generate usually returns a single level of contiguous chunks. Official code is published in parthsarthi03/raptor, and this profile contrasts the tree retrieval idea with the baseline at Naive RAG.
How does RAPTOR build the retrieval tree?
RAPTOR builds its tree bottom-up via a repeated loop: (1) split the corpus into short contiguous chunks (about 100 tokens in the paper; sentence-preserving), (2) embed chunks with SBERT multi-qa-mpnet-base-cos-v1, (3) soft-cluster with GMM after UMAP reduction where BIC selects cluster count and a node can join multiple clusters, (4) summarise each cluster with an LLM, and then (5) re-embed summaries and repeat until further clustering is infeasible (Sarthi et al., 2024, §3). The paper reports an average summary/children compression ratio of 0.28 (≈72% compression; Appendix C).
What is collapsed tree retrieval in RAPTOR?
RAPTOR offers two query modes: tree traversal (layer-by-layer top-k from roots toward leaves) and collapsed tree retrieval (flatten all layers; cosine-rank every node; fill until a token budget). The paper prefers collapsed tree: on a QASPER subset it beat traversal, and the default used for main results is collapsed retrieval with a 2000-token budget, which corresponds to roughly top-20 nodes (Sarthi et al., 2024, §3). The drawback is stated directly: collapsed retrieval scores similarity over EVERY node, so indexing/search acceleration such as FAISS can matter; traversal keeps a fixed themes-to-details ratio, which can be too rigid for mixed query types.
RAPTOR’s capabilities and limits, side by side
This section keeps the capability↔ceiling pattern: every RAPTOR capability below rides on an operational limit that makes the number meaningful.
| Capability | What you get | The limit that rides along |
|---|---|---|
| Hierarchical multi-granularity retrieval | Leaves + summaries are searchable so queries can pick the right abstraction | Collapsed search scores all nodes (mitigation: ANN such as FAISS) |
| Soft GMM clustering | Distant related chunks can share a parent via soft membership | Clustering complexity is tied to UMAP+GMM+BIC, and tutorial simplifications that replace it with k-means are approximations |
| Abstractive summaries | Thematic questions get compressed context | Minor summary hallucinations are reported at about 4% in the paper’s appendix annotation; summariser LLM cost shows up at index time |
| Linear build scaling | Build effort scales with doc length and the number of clusters | Even with compression, the method still pays an LLM call per cluster; corpus edits trigger rebuild or partial re-summary |
| Published QuALITY/QASPER gains | Sarthi et al. report SOTA gains with GPT-4 on those benchmark setups | Paper-setup specific gains do not automatically transfer; re-measure on your labelled set |
What question types is RAPTOR built for?
RAPTOR targets questions that need discourse-level or multi-part evidence a single short contiguous chunk cannot hold, including thematic questions over long documents (NarrativeQA-style books/scripts), synthesis inside full papers (QASPER), and medium-length passage MCQ that needs the whole document (QuALITY setups around long-context contexts; Sarthi et al., 2024, §1 and §4). The paper illustrates how different query intents pull different layers of the tree (e.g., a “central theme” query versus a more procedural question). When the needed composition is truly multi-document iteration, that symptom route belongs on multi-hop failure diagnosis and the iterative multi-hop architecture at Multi-Hop RAG.
What do the published RAPTOR benchmarks show?
In the paper’s setups, RAPTOR+GPT-4 reaches 82.6% accuracy on QuALITY test (prior best CoLISA: 62.3%) and 76.2% on QuALITY-HARD (vs 54.7%). The paper reports QASPER F1 Match at 55.7% (above CoLT5 XL: 53.9%) and NarrativeQA METEOR at 19.1 (Sarthi et al., 2024, Tables 3/5/6/7). Controlled ablations in the same paper show RAPTOR’s tree setup beats the same retriever without the tree, so the gain is tied to hierarchical retrieval—not just to a better retriever.
What does RAPTOR cost to index and keep current?
RAPTOR’s expensive step is index-time: every cluster summary is an LLM call, and Appendix A reports build-time scaling roughly linearly with document length in the paper’s experiments. When the corpus changes, the index can become stale because the summaries represent the cluster structure over the old content; operationally that means rebuild or surgically re-summary affected branches rather than assuming the prior tree still matches your new documents (Sarthi et al., 2024; also see the stale-index failure cluster at stale index). Query time collapsed retrieval scores nodes with a token budget, and the paper’s reported summary-hallucination rate is about 4% in annotated summaries, with the paper arguing that errors stay localized to minor summary issues rather than propagating through parent clusters (Appendix E).
Graph RAG vs RAPTOR — which for which job?
RAPTOR organises text into a summary tree for multi-granularity vector retrieval; GraphRAG-family systems organize entities and relations for relationship- and global-corpus questions (Edge et al., 2024 line of work). A useful way to pick is to match the failure surface: RAPTOR is about hierarchical summarisation layers inside one tree, while GraphRAG is about graph construction and traversal mechanics. Parent-document / hierarchical chunking is a cheaper “small-to-large context” pattern that does not build recursive abstractive layers, so it helps with boundary loss rather than missing themes (see hierarchical chunking). LightRAG is the cheaper graph-variant profile, and GraphRAG’s deeper mechanism is explained at GraphRAG.
What is RAPTOR?
RAPTOR is a retrieval architecture (Recursive Abstractive Processing for Tree-Organized Retrieval) that recursively clusters and summarises a corpus into a multi-layer tree, so retrieval can return either a high-level theme or a leaf detail depending on the question intent (Sarthi et al., 2024).
What does RAPTOR stand for?
RAPTOR stands for Recursive Abstractive Processing for Tree-Organized Retrieval (Sarthi et al., 2024).
How does RAPTOR work?
RAPTOR builds a tree bottom-up by chunking, embedding, soft-clustering with GMM after UMAP reduction, and summarising each cluster, then repeating until further clustering is infeasible (Sarthi et al., 2024). At query time it supports collapsed-tree retrieval (flatten all layers and cosine-rank nodes) and tree traversal (layer-by-layer top-k).
When should I use RAPTOR?
RAPTOR is most useful for questions that need multi-part or discourse-level evidence where a single short chunk cannot hold the answer, such as thematic queries over long documents and synthesis within full papers (Sarthi et al., 2024). It trades higher index-time work for improved multi-granularity retrieval at query time.
Graph RAG vs RAPTOR — which should I choose?
RAPTOR chooses a text summary tree for multi-granularity retrieval, while GraphRAG-style systems focus on building and traversing an entity/relation graph for relationship-heavy or global-corpus questions. For a cheaper graph-retrieval alternative to GraphRAG, LightRAG is the graph-variant profile; for RAPTOR’s hierarchical summarisation mechanics, this page is the match.