0:00This video is about two different things retrieval can return: a similarity score from a vector database, and a recorded relationship from a knowledge graph. We'll compare them, and then follow relationships through a small graph to answer a question a score can't.
0:17Let's be precise about the two systems and what each one returns, a vector database on one side and a knowledge graph on the other.
0:24A vector database holds your text as vectors. A search turns your question into a vector too, and hands you the passages whose meaning sits nearest to it. Nearest by some measure of distance, and nothing more than that.
0:39A knowledge graph starts somewhere else. It holds entities and the relationships recorded between them. You give traversal an entity you have already identified, and it walks the relationships recorded against it.
0:52So neither one is a better version of the other. A vector database and a knowledge graph take different inputs and answer different questions. Telling those apart is what this video is about.
1:04Take two supplier descriptions, Volt's and Nordparts', and ask an embedding model how close they are.
1:11Point nine one. That is high, and it means exactly what it says. The language in those two descriptions sits close together.
1:19What it does not say is that the two suppliers have anything to do with each other. No relationship, and no shared identity either.
1:27Here is a different kind of claim about Volt, recorded rather than measured.
2:14Globex buys from Volt. This one names the relationship and both of its endpoints, so a query can start at Globex and follow it.
2:22It is also an assertion somebody recorded. Recorded does not automatically mean verified, and that distinction comes back more than once.
2:31Let's put a score and an edge side by side, and name what actually separates them.
2:36An edge is in the graph because somebody or some process recorded it. It carries a type, so you know what kind of connection you are following. And between any two entities it is either there or it isn't.
2:51A score comes out of a model comparing two pieces of text. Nothing in it says what kind of connection this is. And it is a matter of degree rather than a yes or a no.
3:03So picking a cut off and calling everything above it a match still leaves you with unnamed pairs. You have decided which pairs are close. You have not said what connects them.
3:15To see what those named relationships actually buy you, we need something to follow. So here's a small dataset, starting with one record.
3:50This is what the customer database holds for Acme, and inside that system it is keyed C one. That key is local. It means something there and nothing outside it.
4:03The canonical company is a separate object with its own identifier, org acme, and that is the one the graph uses.
4:10The dashed line says this record supports that identity. It is not a fact about Acme. It is where one of the facts came from.
4:18So we carry the local key on the canonical node as an attribute. That way we can always get back to the system the evidence came from.
4:26That was one company. Here is the rest of the dataset.
4:29Three customers. Acme is the company we just mapped, and Globex and Initech we will refer to by their customer keys, C two and C three.
4:38Each one carries a revenue figure. Nine hundred, seven hundred, and two hundred. Those numbers are what top customers is going to mean in a minute.
5:14Now the supply side. Volt is a supplier, and it is based in Northland. The countries have no identifier of their own, so the name is the key.
5:30Nordparts is the other supplier, and it is based in Westia.
5:35Each country carries a flag saying whether it is sanctioned. Northland is, Westia is not. That flag is the condition we are going to search on.
5:45Start with the question, then look at how it gets written down.
5:48That is what we want to know, and the whole of it fits in one statement.
5:52This is Cypher, which is a query language for graphs. Read it like sequel for paths. We are not going to work through the syntax.
5:60What it says is three things in a row. Take the top customers, go to the suppliers they buy from, and keep the ones in a sanctioned country.
6:09One thing to notice before we follow it. The query takes the top five customers by revenue, and this dataset only has three, so all three are in.
6:19Same question as the query, but this time we follow it through the graph.
6:22That is what we are answering. Now the part of the graph it touches.
6:27Globex, one of our top customers. Volt, a supplier. Northland, a country.
6:34First hop. Globex buys from Volt, so that relationship takes us from a customer to a supplier.
6:40Second hop. Volt is based in Northland, which takes us from a supplier to a country.
6:46And Northland is sanctioned, so this path meets the condition. Globex is one answer.
6:52Initech is a top customer as well, and it also buys from Volt. Same supplier, same country, so it meets the same condition. The answer came out of joining relationships that were already recorded.
7:05And here are the rows that question returns.
7:08Two of them. Globex to Volt to Northland, and Initech to Volt to Northland. Exactly the two paths we just walked.
7:16The order they come back in is not guaranteed, which matters if you ever compare two runs by eye.
7:23What is guaranteed is that these are all of the matches. Complete, for this query and this snapshot of the data.
7:30A sequel join could express the same thing. What matters here is the capability, structured relationship querying, and not something special about one database product.
7:44So here's where that leaves you.
7:45You can tell a score from an edge. A score says two pieces of text are close, and an edge says what connects two entities and in which direction.
7:56And you can answer a question by walking the graph. Join the relationships that were recorded, and the answer is complete for that data and those conditions.
8:05One thing to carry out of this. Similarity tells you what reads alike, and only a recorded relationship tells you what is connected.

A Similarity Score Is Not a Relationship

Created by Abhyuday DesaiPublished 3 Oct, v1Runs 8 min 18 sec

0 views

About this video

A vector database returns a score from comparing text; a knowledge graph returns relationships somebody recorded. This video puts a score and an edge side by side, builds a small supplier dataset with local keys and canonical identities, and answers a question a score cannot: which top customers buy from a supplier in a sanctioned country, by joining two recorded relationships.

You'll learn how to:

Tell a similarity score from a recorded, typed, directed relationship
Separate a system's local key from the canonical identity the graph uses
Follow a two-hop question through the graph and read the rows a join returns
See what a graph answer guarantees: complete for this query and this snapshot

For developers choosing between vector search and a knowledge graph.

What changed

v103 Oct 2026abhydesai8 min 18 sec21ba95b

First published version.

0 views0 likes on this version