0:00This video is about the questions a knowledge graph can answer and a vector database can't, and the one case where the documents win. We'll start from a question a graph has answered by following relationships: which top customers buy from a supplier in a sanctioned country.
0:17Now take that same question to a vector store instead of the graph.
0:21On the left is what traversal gave us. Two paths, each one a customer, a supplier and a country, with the identifiers still attached.
0:30On the right is what similarity returns for the same words. A supplier profile, a sanctions notice, and a revenue overview.
0:38Every one of those is about the question. None of them contains the purchase links. Ranking chunks has not performed the join, so something else still has to.
0:49There is an objection worth answering here. You could precompute those relationships into the document metadata.
0:55This is the supplier profile document, and its metadata carries the supplier I-D and a sanctioned country flag.
1:03With that stored, a vector search can filter on it. Retrieve the similar chunks, keep the ones where the flag is true, done.
1:11And that works, for attributes you have already stored. But the flag did not appear by itself. Somebody derived it from the purchase and location relationships.
1:21And somebody has to keep deriving it as those relationships change.
1:26The filter is reading an answer that a join produced earlier.
1:30Now a different kind of question.
1:32This one asks about something that is not there, rather than something that is.
1:37Same language, and this one tests for the absence of a relationship rather than the presence of one.
1:43Keep a customer only if there is no ticket hanging off it whose status is open. A closed ticket would not exclude anybody.
1:51Two customers come back, Acme and Initech. Globex is the one holding the open ticket.
1:57Ask the same question of the same snapshot and you get the same set, though the order inside it is not promised.
2:04And here is the limit on that. It says nothing about tickets nobody ever logged. An empty result is a statement about your recorded data, not about the world.
2:17The exact answer we just got was a completeness claim, and that is worth holding up against what retrieval promises.
2:24On the left, the exact answer. Every customer in this snapshot with no open ticket, and there are no others.
2:31On the right, top kay retrieval for the same question. Three documents about tickets, and the dots say there are more behind them.
2:39Both of those are useful. But summarising three retrieved documents cannot establish that no matching customer was missed, because nothing looked at the ones that were not retrieved.
2:50Structure also lets you count things.
2:53Here is a third kind of question, and this one is about quantity rather than paths.
2:59In Cypher that is a group and a count. Take the purchase relationships, group them by supplier, and count what is on the other end.
3:06That is counting relationships in a graph. It is not counting how often a supplier gets mentioned across a pile of documents, and those are different numbers.
3:17Two purchase relationships arrive at Volt, one from Globex and one from Initech.
3:22So Volt's count is two.
3:24Acme buys from Nordparts, and nobody else does.
3:27Which makes Nordparts one.
3:29Strictly, that counted matching rows. Here every customer-supplier pair has exactly one purchase relationship, so rows and customers come to the same number. With repeat purchases they would not.
3:42Vector retrieval and graph traversal both fail, and it is worth being precise about how each one fails.
3:49What payment terms does Volt offer? A perfectly reasonable thing to want to know about a supplier.
3:55Volt is in the graph. We have its identity, the country it is based in, and the customers who buy from it.
4:02But payment terms were never modeled. There is no property and no relationship carrying them, so traversal has nowhere to go.
4:10And notice what that result is not. It is not "Volt has no payment terms". It is that this representation cannot tell you, which is a completely different claim.
4:22Same question, and now through vector retrieval instead.
4:25Three chunks come back. A battery quality report, a shipping schedule, and a warranty overview.
4:31Kay was three and there was no relevance cutoff, so three is what you get. The scores rank them against each other. Nothing in them says any one is relevant enough.
4:42And none of the three answers the question. Retrieval returned something, which is not the same as retrieval finding support. Knowing when to abstain has to be designed in.
4:55That is the honest weakness. Here is the honest strength.
4:58The answer does exist. It is sitting in a supplier contract, in a sentence nobody ever modeled.
5:05One clause about invoices and thirty days, which is exactly what was asked for. No schema change, no new relationship type, no migration.
5:14And vector retrieval is good at finding that clause, including when the contract words it nothing like the way you asked. That is the job it is genuinely built for.
5:27So here's where that leaves you.
5:29You can name the questions only structure answers. A relationship that is absent, a complete set of matches, and a count of connections.
5:37And you can see where the documents win. A fact nobody modeled can still sit in a sentence, and similarity is built to find that sentence.
5:46One thing to carry out of this. Retrieval returning something is not the same as retrieval finding support, and knowing which you got has to be designed in.

What Only a Knowledge Graph Can Answer

Created by Abhyuday DesaiPublished 3 Oct, v1Runs 6 min 2 sec

0 views

About this video

The same question goes to a vector store and comes back as relevant chunks with no join. This video works through what metadata filters buy and what they cost to maintain, then the questions that need structure: asking for an absence, claiming completeness, counting relationships. It ends on both failure modes side by side, and on the strength vector retrieval genuinely has: finding a clause in a contract that nobody ever modeled.

You'll learn how to:

See why ranking chunks never performs a join, and what a precomputed filter is really reading
Ask a graph for something that is not there, and say what an empty result means
Hold an exact answer's completeness claim against what top-k retrieval promises
Recognize when retrieval returned something without finding support, and when documents win outright

For developers deciding which kind of retrieval a question needs.

What changed

v103 Oct 2026abhydesai6 min 2 sec21ba95b

First published version.

0 views0 likes on this version