Knowledge graph
In one sentence
A knowledge graph stores information as connected entities and relationships rather than as passages of text, so it can answer structured questions by traversing those connections rather than by retrieving a passage.
Not to be confused with Knowledge base, or Semantic search.
Definition
A knowledge graph stores facts as connections rather than as pages of text: this product is in this category, costs this, is in stock here. It can walk those connections to answer a question.
It is good for questions that need several facts joined together. For most businesses, whose customers ask about hours and returns, ordinary document search is the right tool and a graph is expensive overkill.
Knowledge graphs and vector retrieval answer different kinds of question, and combining them is an emerging pattern. Vector retrieval finds passages semantically similar to a question. A knowledge graph answers structured questions by traversing relationships. What is your returns policy is a passage question. Which of your products under a given price are available at the Mumbai branch is a graph question, and the second cannot be answered reliably by retrieving passages, because the answer requires combining structured facts that may appear in different documents.
What a graph is good at
- Multi-hop questions requiring several linked facts.
- Aggregation and filtering across entities.
- Consistency, since a fact is stored once and referenced everywhere.
- Explainability, since the traversal path is the reasoning and can be shown.
What it costs
- Construction. Building and maintaining a graph is substantially more work than uploading documents.
- Schema design. The entity and relationship types are decided up front, and changing them later is expensive.
- Brittleness. Questions outside the schema get no answer at all, where retrieval would at least return something related.
The hybrid direction, and where it fits
- GraphRAG puts structured facts in a graph and unstructured explanation in documents, routing or combining questions across both. It is an active area rather than a settled pattern, and implementations vary widely.
- Most small and medium businesses do not need one. Their questions are passage questions and their catalogs are small.
- Businesses with large structured catalogs, complex product relationships or availability that varies by location gain more.
- The honest guidance is that document retrieval is the right default, and a graph is a considered addition rather than a starting point.
Common misconception
That a knowledge graph is a better version of a knowledge base. They answer different question types. Adding graph complexity to a deployment whose questions are all passage questions adds cost and no capability.
Why it matters commercially
A graph is the correct answer for a specific class of question that retrieval handles poorly, and the wrong answer for the majority of business voice deployments. Knowing the difference prevents an expensive detour.
In voice specifically
Graph traversal has to finish inside the same sub-second budget as every other retrieval step, so the response the caller hears cannot wait on a slow multi-hop query any more than it can wait on a slow document lookup.
Where AsqVox fits
Document retrieval is the mechanism, which suits the passage questions that dominate website voice interactions. Structured catalog queries are where the limits of pure retrieval become visible, and where a structured system behind a tool call, rather than a bigger corpus, is the right fix.
Visual
Two shapes of question
One is a passage to retrieve. The other is a set of facts to join. Only the first is what retrieval does.
Statistics
Every figure carries its source and year. Vendor numbers are labelled as vendor numbers, and where no reliable figure exists this page says so rather than borrowing one.
There is no reliable published benchmark comparing knowledge graph against vector retrieval performance for business voice applications. Performance depends entirely on the question distribution.
-no reliable figureA graph that shines on a catalog of multi-hop availability questions can be dead weight on a corpus of policy questions. No single number transfers across those two businesses.
Hybrid graph and retrieval approaches are an active area of development rather than a settled pattern, and implementations vary widely enough that general claims are not meaningful.
-no reliable figureTreat GraphRAG vendor claims as reports from one implementation, not a category benchmark. The pattern is real and narrow, and the term is fashionable ahead of the evidence.
Retrieval quality bounds answer quality in a RAG system, and chunking is the highest-leverage tunable. A graph changes the retrieval mechanism rather than removing the dependency.
retrieval bounds the answerindustry rangeRAG engineering convention, 2026 - Switching to a graph does not escape the rule that the retrieval step caps answer quality. It changes how that step works, not whether it is the ceiling.
Graph traversal sits inside the sub-second time to first audio budget, alongside every other retrieval step.
within the sub-second budgetindustry rangeVoice interaction latency convention, 2026 - A multi-hop traversal is not exempt from the latency budget. If it cannot finish in time, the caller hears silence, whatever its accuracy.
There is no published data on knowledge graph adoption in voice agent deployments, which would indicate whether the complexity is being taken on in practice.
-no reliable figureWithout adoption data, treat GraphRAG in a voice pitch as an emerging capability being trialed, not a proven standard in the field.
Examples
In practice
A retailer voice agent answers policy questions well and fails on availability questions requiring product attributes combined with location stock. Retrieval returns a passage about stock checking and the model guesses specifics. The correct fix is not better retrieval but a structured query against the inventory system, exposed as a tool call. The graph question needed a structured answer, not a better passage.
The everyday version
A knowledge graph stores facts as connections rather than as pages of text: this product is in this category, costs this, is in stock here. It is good for questions that need several facts joined together. For most businesses, whose customers ask about opening hours and returns, ordinary document search is the right tool and a graph is expensive overkill.
Usage
Who says it
- Data engineers and knowledge management specialists.
- It appears in enterprise architecture discussions, and increasingly in vendor material as GraphRAG, which is a fashionable term for a genuine but narrow pattern.
Where it turns up
- Next to knowledge sources, structured data integration, multi-hop question support and catalog integration on a spec sheet.
Common misuse
- Presenting a graph as a superior alternative to document retrieval generally.
- Adopting the complexity for question distributions that do not require it.
- Assuming graph coverage where the schema does not extend.
Questions people ask
What is the difference between a knowledge graph and a knowledge base?
A knowledge base is a corpus of documents that a voice agent retrieves passages from. A knowledge graph stores facts as connected entities and relationships and traverses them. They answer different question types: a returns policy is a passage question, and which products under a price are stocked at a branch is a graph question. A graph is not a better knowledge base, it is a different question shape.
When does a business voice agent actually need a knowledge graph?
Rarely. Most small and medium businesses ask passage questions over small catalogs, and document retrieval handles those well. Graphs earn their cost for large structured catalogs, complex product relationships, or availability that varies by location. The honest default is document retrieval, with a graph as a considered addition rather than a starting point.
What is GraphRAG?
GraphRAG is the hybrid pattern that keeps structured facts in a graph and unstructured explanation in documents, then routes or combines questions across both. It is an active area of development rather than a settled pattern, and implementations vary widely enough that general claims are not meaningful, so treat a GraphRAG pitch as one implementation rather than a category standard.
What does a knowledge graph cost to build?
More than uploading documents. It takes construction and ongoing maintenance, a schema designed up front that is expensive to change later, and it is brittle: a question outside the schema returns nothing at all, where document retrieval would at least return something related. Those costs are why it is the wrong default for most deployments.
Last reviewed 3 August 2026. Written and reviewed by Dhruv Dholakia, founder of AsqVox.