The missing fact inside a company
Avi Chawla posted an example this week while comparing three ways to fetch the right information for an AI, called RAG, Graph RAG and Agentic RAG.
His example is three facts about a company's internal services. The checkout service uses the payments API. The payments API runs on cluster-3. Cluster-3 is scheduled for maintenance on Friday.
Someone asks whether the checkout service will be affected by Friday's maintenance. A search by similarity will likely find the first and third facts, because they share words with the question. It misses the middle one, which mentions neither checkout nor maintenance. A knowledge graph links all three, so the path from checkout to Friday can be followed.
Avi Chawla@_avichawlaRAG vs. Graph RAG vs. Agentic RAG, clearly explained! Standard RAG embeds documents into vectors and retrieves the most similar chunks via similarity search. For direct factual lookups, this works well. But it breaks down when a query needs to connect facts spread across multiple documents. Similarity search retrieves individual chunks, not the relationships between them. Graph RAG adds a knowledge graph layer on top. → During indexing, an LLM extracts entities and relationships from the documents. → During retrieval, the system traverses these connections instead of relying on embedding similarity alone. This is what enables multi-hop queries. Say a vector DB stores three facts about internal services: ↳ "The checkout service uses payments API." ↳ "The payments API runs on cluster-3." ↳ "Cluster-3 is scheduled for maintenance on Friday." Someone asks: "Will the checkout service be affected by Friday's maintenance?" Vector search can likely retrieve facts 1 and 3 because the query mentions "checkout service" and "Friday maintenance." But it will miss fact 2, which connects the payments API to cluster-3. That middle fact sits too far from the query in embedding space. It mentions neither "checkout" nor "maintenance," so it never makes it into the retrieved context. A knowledge graph connects these as linked entities, and graph traversal finds the full path in one query. Agentic RAG takes a different approach entirely. Instead of a fixed retrieval pipeline, an LLM agent decides at query time which tools to invoke, which sources to query, and in what order. Check the visual below to understand the three architectures thoroughly. One thing to note here is that these three aren't levels of sophistication that you need to graduate through. Instead, they solve different query types. ↳ Single-hop factual lookups → standard RAG ↳ Multi-hop relationship queries → Graph RAG ↳ Dynamic multi-source tasks with tool use → Agentic RAG Once the right architecture is in place, the next leverage point is efficiency. Most RAG architectures rely heavily on vector search, and that layer can be made 32x more memory-efficient using binary quantization. I covered the full implementation in the article below. 👉 Over to you: Which RAG architecture are you running in production?
Christian J. Ward@wardchristianjUseful that you framed these as three tools for three kinds of question. The graph only helps if the relationship was written down somewhere first. Often the link between the service, the API and the cluster lives in one engineer's head, and no retrieval method finds a fact nobody recorded. So I'd add a step before choosing an architecture. Find out which connections exist only in people.
