Concept Contrast Fable

Retrieval-augmented generation and knowledge graphs: one finds materials from the warehouse, the other has already drawn the relationship map in advance

Conclusion first:RAG retrieves relevant chunks from an external knowledge base and injects them into the context before generating an answer; it is a retrieval-plus-generation pipeline mechanism. A knowledge graph is a structured way of representing knowledge, organizing it in advance with entities and relationships. Both appear in knowledge-enhanced systems, but one cares about how to “look it up,” while the other cares about what knowledge itself “looks like.”

RAG retrieves relevant chunks from an external knowledge base and injects them into the context before generating an answer; it is a retrieval-plus-generation pipeline mechanism. A knowledge graph is a structured way of representing knowledge, organizing it in advance with entities and relationships. Both appear in knowledge-enhanced systems, but one cares about how to “look it up,” while the other cares about what knowledge itself “looks like.”

Fable

The county office had two treasuries: one piled with several chests and cabinets to unlock and rummage through, and one with the whole city's relationship network drawn on the wall

In Nanyang County there was an old county magistrate governing a population of three hundred thousand, hearing more than a hundred cases in court every day. He had two staffs managing records. The first staff was called the 'Case File Room'—they packed all the precedents, land deeds, and household registration records from the past thirty years into three hundred large iron cabinets, with labels on the cabinets. For every case judged, the clerk ran to the case file room to search the cabinets, find several similar precedents, and present them to the magistrate for reference in deciding the case.

The second shift was called the "Genealogy Pavilion"—only three people, and what they did was different. They drew all the relationships among families, shops, fields, and artisan households in the county into a huge relationship map, hung on all four walls of the pavilion. Who was related by marriage to whom, which shop owed money to which family, whose field was connected to whose canal—all clearly marked on the map with lines of different colors.

One year a complex case arose: three grain shops in the south of the city simultaneously accused the same rice merchant of hoarding and profiteering. The clerk ran to the case-file room to find precedents—and pulled out twelve similar 'hoarding' rulings. But the case was heard three times without resolution, because the relationships between the grain shops and the rice merchant were too complex—one grain shop was run by a distant relative of the rice merchant, and another had borrowed money from him last year. None of these relationships could be found in the twelve precedents.

The county magistrate halted retrieval in the case-file room and had the genealogy pavilion bring over their map. Three people spent half an incense stick finding the rice merchant's position on the map, and following the red, blue, and green lines extending from him, reconstructed three chains of interest within five minutes. The case was decided that same day. A court clerk later placed this map side by side with the twelve precedents and wrote a note: the case-file room lets you find similar precedents, the genealogy pavilion lets you see the relationships in the current case.

Afterward the secretary suggested to the county magistrate: could the genealogy pavilion's diagrams also be connected to the case file room? Let the cabinet search results include summaries of the three closest links to that entity in the relationship graph. The magistrate agreed. When the case file room searched 'grain merchant hoarding,' it returned twelve precedents and also attached a relationship sketch automatically exported by the genealogy pavilion—using dashed lines to mark kinship and lending connections between grain shops and grain merchants.

The key point of the new system was that the two sets of things were not merged: the case file room still retrieved text fragments by content, and the genealogy pavilion still maintained that large graph. The only addition was a "related graph summary" module at the output entrance of the case file room. If one day the genealogy pavilion updated the citywide relationship data—a shop changed hands, a new marriage alliance was formed—the case file room's related queries would automatically change with it, without the clerk needing to synchronize manually.

The county magistrate later wrote the case into the textbook for new officials, telling the next magistrate: the case-file room is responsible for finding similar precedents, and the genealogy pavilion is responsible for seeing the current relationships clearly. The two teams can cooperate but cannot replace each other. Use the cabinet-searching method to draw a chart and you can wear out the cabinet without drawing the whole city's relationships; use the genealogy pavilion to replace precedent retrieval and the basis for judgment will be incomplete.

Retrieval-Augmented Generation

Before generating an answer, retrieve relevant snippets from an external knowledge base and inject them into the context, helping the model answer based on the retrieved information. At its core, it's a retrieve-inject-generate workflow mechanism.

Knowledge graph

A data form that structurally represents knowledge using entities and relationships. Nodes, edges, and attributes are predefined, and the graph's topology expresses real-world knowledge connections. It is a way of representing knowledge.

Story Mapping

Pulling iron cabinets in the case-file room: RAG — retrieve relevant text fragments and inject them into the context
The relationship map on all four walls of the Genealogy Pavilion: knowledge graph—organizing knowledge in advance with entities and relationships
Twelve case records cannot reveal family relationships: pure retrieval cannot express structured relationships
Half a stick of incense followed the relationship lines to find three chains of interest: the knowledge graph's structural query capability
Graph access to cabinet queries: incorporating knowledge graph summaries into RAG retrieval results
The two things were not merged: retrieval mechanism and knowledge representation are two independent components
Summary of the new official school textbook: RAG and knowledge graphs work together and cannot replace each other

Applying this to RAG system architecture design

When designing a knowledge-enhanced system, first judge what form best organizes your knowledge. If the knowledge is mainly unstructured documents (manuals, policies, historical records), RAG retrieval is the main line, and a knowledge graph can serve as a supplementary layer adding related information to retrieval results. If the knowledge is inherently relational (supply chains, user profile paths, compliance dependencies), go directly to a knowledge graph for querying, with RAG as a fallback. The more common pattern is to use both together: the vector store handles broad semantic recall, the graph handles relationship queries and reasoning, and the generation layer stitches the results from both sides. The key is not to do semantic search work in the graph, nor to use a vector store to simulate the graph's multi-hop reasoning — each has its own strengths.

Retrieval-Augmented Generation Knowledge graph