When is enabling RAGFlow's RAPTOR or knowledge-graph extraction worth the indexing cost?

## What these toggles actually are Both sit *after* parsing and chunking in RAGFlow's ingestion pipeline, and both are optional. They are the point where the pipeline stops being deterministic extraction and starts generating new content with an LLM. **RAPTOR** takes the chunks a document produced, groups similar ones, asks the LLM to summarize each group, and repeats over the summaries, producing a hierarchy from leaf chunks up to increasingly abstract summaries. The summaries are indexed alongside the original chunks, so retrieval can return either. Its configuration exposes the clustering and summarization knobs — things like a similarity threshold, a cluster limit, a token budget and the summarization prompt. **Knowledge-graph extraction** runs an LLM extraction pass over chunks to identify entities and the relationships between them, and stores the resulting graph for the knowledge base. You configure what entity types matter for your domain, which materially changes what gets extracted. ## The case for enabling them Standard chunk retrieval has a structural blind spot: it can only return text that exists. Two query shapes fall into that gap. - **Corpus-level and thematic questions.** "Summarize the main risks across these forty reports" cannot be answered by top-N chunks, because no chunk contains the synthesis and the top-N will be forty arbitrary fragments. A RAPTOR summary node *is* that synthesis, written once at index time rather than attempted at query time under a context limit. - **Multi-hop questions.** "Which supplier is connected to the component that failed inspection" requires joining a fact in one document to a fact in another. Vector similarity does not traverse; a graph does. If a meaningful share of real user queries has these shapes — and you can check that against actual query logs rather than imagination — the features earn their keep. ## The case against, which is usually stronger **Cost scales with the corpus, not with usage.** Every chunk is read by the LLM at least once, and RAPTOR reads them repeatedly as it builds levels. On a large corpus this exceeds the cost of parsing and embedding combined, and it is paid up front whether anyone asks a thematic question or not. **Ingestion time multiplies.** You have already accepted a heavy parse stage; these add LLM round-trips on top, subject to rate limits. An overnight ingest becomes a multi-day one. **They go stale.** Add a batch of documents and the existing clusters and summaries no longer reflect the corpus; a graph built before those documents has no edges into them. Re-running is not free, so you now own a refresh policy — which is an operational commitment, not a checkbox. **They introduce generated content into the retrieval surface.** This is the part that deserves the most scrutiny in a design review. A RAPTOR summary is the model's paraphrase; an extracted relationship is the model's inference. Both become retrievable, and when one is cited the user sees a citation that looks as authoritative as a quotation from the source PDF. In a regulated or high-stakes setting — the exact setting where layout-accurate parsing and citation grounding attracted you to RAGFlow — silently blending generated text into the evidence base is a real governance problem, and you should be able to distinguish generated nodes from source chunks when auditing an answer. **Quality is not guaranteed.** Summarization loses the specifics that make an answer verifiable; entity extraction is only as good as your entity-type configuration and the model's grasp of your domain, and it produces both spurious and missing relations. Neither is self-evaluating. ## How to decide, concretely 1. **Characterize the queries.** Sample real questions. Count how many are single-fact lookups, how many are thematic, how many are multi-hop. If lookups dominate, stop here — spend the budget on retrieval quality instead. 2. **Establish a baseline.** Measure answer quality with plain chunk retrieval first. Without it you cannot attribute any improvement to the feature. 3. **Pilot on a subset.** Enable on one knowledge base or one document set, not the whole corpus, and compare on the query types that motivated it. 4. **Price the refresh.** Estimate re-run cost at your real document churn rate. A feature you can afford once but not monthly is not deployable. 5. **Decide the audit story.** How will a reviewer tell a generated summary from a source quotation in an answer's citations? If you have no answer, that is a reason to hold off in a compliance-sensitive deployment. ## The principal's framing The honest position is that these features move work from query time to index time, and buy recall on question shapes that chunk retrieval structurally cannot serve — at the price of money, freshness and evidential purity. That trade is excellent for a small, stable, high-value corpus where users ask synthesis questions, and poor for a large, churning corpus of lookup-style documents. Naming that trade, rather than treating the toggles as free quality, is what the question is testing.