When Structure Beats Similarity

RAGFlow’s ordinary chunk index is a strong starting point, but some questions ask for relationships that no single passage contains. This chapter examines when RAGFlow’s knowledge compilation and GraphRAG-style features add a useful second representation: trees for hierarchy, page indexes for navigation, and graphs for entities and relations. The goal is to recognize when structure is necessary, choose an artifact family for the question, and keep every generated structure subordinate to the source evidence that produced it.

When chunks are not enough

Local retrieval works best when the answer is close to a passage that can stand on its own. “What is the recommended inspection interval?” may be answered by one well-formed fragment. Even then, the fragment needs the right model, condition, and unit. But some questions are difficult for a different reason. The answer may require navigating a long document, combining several sections, following an entity through multiple relationships, or summarizing a broad body of material. Asking a single chunk to carry all those relationships forces the retrieval layer to solve a structural problem with a similarity score.

Consider a technical standard with a table of contents, definitions, requirements, exceptions, and appendices. A question about one requirement may need the section that defines the term, the section that states the rule, and an exception later in the document. A vector search can retrieve passages that sound related, but it has no inherent notion of “this section is under that chapter” or “this exception qualifies the rule.” The more the question depends on organization rather than wording, the more valuable an explicit representation of that organization becomes.

RAGFlow calls this process knowledge compilation: converting unstructured documents into structured knowledge content with a selected template. A knowledge tree organizes material by topic and hierarchy. A page index preserves original chapter and page structure so a system can locate a relevant part before expanding it. A mind map exposes a central topic and its branches. A timeline organizes events chronologically. Linked knowledge pages connect related topics into a navigable body. These artifacts do not replace chunks; they give retrieval additional routes through the same corpus.

The difference between those routes matters. A tree or page index answers a navigation problem. It can first identify the relevant branch or section, then direct retrieval toward the underlying passages. This is a locate-then-expand pattern: use the document’s organization to narrow the search, then use source text to supply the detail. A mind map is useful for orientation and topic coverage, but a branch in a mind map is not automatically proof of a fact. A timeline can make event order visible, but it depends on the compiler extracting dates and event relationships correctly. A linked page can improve exploration, but its links are derived connections that still need source support.

flowchart LR A["Parsed source chunks"] --> B["Local chunk retrieval"] A --> C["Knowledge tree and page index"] A --> D["Knowledge graph and relation paths"] A --> E["Mind map, timeline, or linked pages"] C --> F["Locate and expand"] D --> G["Multi-hop retrieval"] E --> H["Topic synthesis"] B --> I["Evidence selection"] F --> I G --> I H --> I A -. "source IDs and evidence links" .-> C A -. "source IDs and evidence links" .-> D A -. "source IDs and evidence links" .-> E

Graph representations address a more relational failure mode. GraphRAG-style processing extracts entities, such as people, organizations, products, or concepts, and relations between them.