Why an LLM benefits from a KG

Vanilla RAG retrieves chunks of text based on vector similarity and concatenates them into the prompt. While effective for many tasks, it fails when the answer requires composing information from multiple, disjoint pieces or when the correct facts are hidden behind indirect references.

A KG addresses three fundamental failure modes:

1. Multi‑hop reasoning: “Which competitor of our supplier was founded by an ex‑employee of Acme?” requires traversing a chain of relationships; no single chunk contains all the necessary facts. A graph query like (supplier)-[:supplies]->(company)-[:competitor]->(c) <-[:foundedBy]-(person)-[:exEmployeeOf]->(Acme) returns the answer directly.

2. Entity disambiguation: “Java” might refer to an island, a programming language, or a coffee brand. Vector search may mix them; a KG can distinguish them via explicit types and properties, enabling precise retrieval.

3. Authoritative and temporal facts: “What is our current return policy?” — you need the latest official statement, not a summary of drafts. KGs can attach provenance (who said it, when) and versioning as first‑class properties, allowing queries to filter by asOf or source.

GraphRAG (covered in Level 2) combines vector retrieval with graph traversal: it uses embeddings to locate starting nodes, then follows edges to gather the required context. This hybrid approach retains the flexibility of semantic search while gaining the precision of structured paths.