On this page
Key takeaways
Ask a language model a question about your business and it will answer, whether or not the information needed to answer it was retrieved. The gap gets filled with something plausible. That is a retrieval problem rather than a reasoning one: ranking text by how closely it resembles the question turns out to be a poor proxy for finding the passage that is authoritative.
- Vector search optimises for resemblance, not correctness. On business questions the wrong passage often shares more vocabulary with the question than the right one does.
- Most Graph-RAG builds its graph out of the corpus itself, so it is inferred per project and rebuilt for the next one.
- Neither approach replaces the other. Similarity is good at finding candidate text; a governed graph is what decides which candidate is authoritative and carries the provenance.
What Graph-RAG actually means
Graph-RAG is retrieval that walks a graph. Instead of embedding text and fetching the nearest neighbours to a question, the system holds entities and the relationships between them, and answers by traversing from a starting concept to the things connected to it.
The word typed is doing the work. A generic graph records that two things are related. A typed graph records how: this rule governs that field, this term is owned by that role, this KPI is derived from those three columns. Because the edges carry meaning, traversal is deterministic and the route is inspectable. You can ask why an answer came out the way it did and get a route rather than a confidence score.
The second half is provenance. Every node and every edge keeps the document, table or column it came from, so an answer arrives with its workings rather than a claim to trust.
Vector RAG ranks by resemblance. Graph-RAG follows relationships.
Vector RAG returns passages. Graph-RAG returns a path.
Similarity has no notion of authority. A superseded definition scores as well as the current one, sometimes better.
Traversal can terminate honestly. If there is no governed route to an answer, that is a fact the system can report.
The two are not exclusive. Vector search is still good at finding candidate text; it is a poor arbiter of what is true.
Where similarity search breaks down
Take on-time delivery. Ask what the rate was last quarter, and vector search returns the passages that most resemble the question: the logistics KPI definition, the SLA appendix, a slide from last year's QBR. All on topic. None of them tells the model that on-time is measured against the confirmed date rather than the originally promised date, that customer-requested reschedules are excluded, or which of the three date fields in the ERP carries the confirmed date.
The failure is structural rather than a tuning problem. Similarity ranks text by how much it resembles the question, and a superseded definition resembles the question exactly as much as the current one. Often more, because the old wording is usually the wording that made it into the slides everyone still circulates.
Graph-RAG is the usual answer to this, and it does help. Entities and relations get extracted, and traversal follows them instead of guessing from proximity. But when the graph is built out of the documents alone, it inherits their gaps. It knows the concepts the text happened to mention, in the shape the extractor happened to infer, with no connection to the systems where the data lives. It can tell you that on-time delivery relates to confirmed dates. It cannot tell you which column holds one.
Key point
That is the gap between a graph derived from a corpus and a graph governed against the business.
Where similarity search is the right tool
None of this makes vector search obsolete, and it is worth being clear about where it wins. Open-ended questions over a document set, finding candidate passages in a corpus too large to traverse, exploratory search where you do not know the right vocabulary yet, and any case where the answer genuinely is the text rather than a value derived from it. Most production systems end up using both: similarity to find candidates, a governed graph to decide which of them is authoritative and to carry provenance. The failure mode described above appears when similarity is asked to do the second job as well as the first.
Ground. Traverse. Bound.
- 01
Ground. Questions resolve against your approved business terms, not against column names or raw text.Terms mapped to the fields that carry themOne approved definition per concept, with an owner
- 02
Traverse. Retrieval walks typed relationships and returns the route, not just the passage.Rule to field, term to system, entity to regionEvery hop keeps its source
- 03
Bound. Deterministic rules constrain the answer, so gaps get flagged instead of filled.Correct, clarified, or refusedNo invention when the context is missing
What's different here
Most Graph-RAG builds its graph out of the text corpus itself, inferred per project and redone for the next one. Metagem builds against a governed business ontology, domain by domain, with each concept linked to the fields that hold it, so what you get is a standing map of the organisation rather than a per-use-case artefact.
Where it shows up
Answers arrive with their route Each answer carries the hops that produced it, rule to field, term to system, so a reviewer checks the reasoning rather than just the number.
A refusal when context is missing Where there is no governed route to an answer, the system says so or asks a clarifying question. Silence is more useful than confident invention.
One grounding, every consumer Copilot, custom agents and BI tools traverse the same governed graph, so they stop disagreeing with each other.
Questions over your own data A generated answer that carries its route can be checked by whoever owns the number, rather than taken on trust.
Frequently asked questions
- How is Graph-RAG different from vector RAG?
- Vector RAG embeds your text and fetches the passages nearest the question, which is resemblance. Graph-RAG holds entities and typed relationships and answers by traversing them, which is structure. The practical difference shows up on questions where the right answer depends on a rule, an exception or a field mapping, because those live in relationships between things and not in any single passage.
- Do we still need a vector database?
- Usually yes, and the two do different jobs. Vector search is good at finding candidate text in a large corpus, which is useful during extraction and for open-ended document questions. It is a poor arbiter of which definition is authoritative. Metagem uses both: similarity to find candidates, the governed graph to decide what is true and to carry provenance.
- What happens when the graph has no answer?
- It says so. If there is no governed route from the question to an approved definition, the system refuses or asks a clarifying question rather than assembling something plausible. That behaviour is the point of bounding traversal with deterministic rules, and it is the property that makes the output safe to put in front of an auditor.
- Which models does this work with, and does our data leave?
- Any model that can call an endpoint, including Microsoft 365 Copilot, custom agents and agent frameworks, through MCP. The graph and the traversal run inside your own environment, read-only and on metadata. Nothing is copied into the model, and swapping the model later does not mean rebuilding the grounding.
See it on your own questions
Bring one domain and a handful of questions your team already argues about. We will show you the same questions answered with the traversal attached, including the ones where the honest answer is that the context is not there yet.
Last updated October 2026.