0:00This video is about deciding whether to build a knowledge graph at all. We'll look at what the heaviest form of the structure costs to keep current. Then four questions settle the choice between a graph and a vector database.
0:13Let's start with the most elaborate thing people build on top of a pile of documents, because it's worth knowing what it costs.
0:19Start with a corpus. Not one document, a whole pile of them, of which this is one.
0:25First, extract a knowledge graph from all of it. Entities and relationships, at corpus scale rather than from a single passage.
0:33Then group that graph into communities, which are clusters of things densely connected to each other.
0:38Then have a model write a summary of each community.
0:41And that is what you query. Summaries like this one answer global questions about themes across a corpus, which a handful of similar chunks covers badly.
0:52There is one caution worth attaching to that summary. It keeps the source keys of the passages behind it, but no document in the pile actually says it.
1:02Now suppose one document in that corpus changes.
1:05One passage, revised. A supplier report that says something different this month from what it said last month.
1:12The extraction that read it has to run again, at least over the part that changed.
1:17Which can move a community boundary, so the grouping has to be reconsidered too.
1:22And if a community changed, the summary describing it is now describing something that no longer exists.
1:29None of that is free. Each stage costs money to run, adds another place where things can go wrong, and adds latency if any of it runs at query time.
1:38Which is why plain vector retrieval over the documents is very often enough. It is worth being honest with yourself about when it is.
1:48So how do you actually choose between a vector database and a knowledge graph?
1:53Four questions, and here is the first.
1:55What must retrieval produce?
1:57If the answer is a set of entities connected to each other, follow explicit relationships. A path is the thing you want, and only a graph gives you one.
2:06If the answer is a passage of relevant prose, use vectors. This is especially helpful when the document words it differently than the way you asked.
2:16Second question. Do you need every match, or is a relevant few enough?
2:20An exact query supports a completeness claim, inside the data you queried and the conditions you stated.
2:27Every match is there, and you can say precisely what "every" means. A similarity search cannot promise that at all.
2:34Top k makes a different promise. A ranked subset, and no statement at all about what sits below the cut.
2:40This is completely fine, when a relevant subset is just what you need.
2:44Third question, and this is the one people answer too quickly.
2:48Is the structure stable and valuable enough to maintain?
2:51Here is the ingestion pipeline again, because that is what maintaining the structure actually means. Extraction, community detection, generated summaries, all of it kept current.
3:02For a pile of documents that changes constantly, and questions that are fuzzy, this is the honest starting point. One stage, and nothing to keep in step.
3:12Add a graph when the relationship questions keep coming back. A resolved supplier, its country, the document it came from: that is what the extra machinery buys you.
3:23The test is whether those questions recur often enough to pay for the maintenance. If you ask once, query the documents. If you ask every week, and the answer is a path, build the structure.
3:37Fourth question.
3:38What must you be able to audit? This one applies to both sides equally.
3:42Here is a single fact from the graph, with the identifiers on it rather than the display names.
3:47And here is the record it came from, still linked to it. Preserve the path and its supporting records, not just the answer somebody read off the end of them.
3:58Notice there is no tick anywhere here. The link says where the fact came from. It does not say anybody read the record and agreed.
4:09And this applies to both sides. Knowledge graphs and vector databases both need provenance, and both need checks appropriate to whatever is being claimed.
4:19So where does all of that leave you.
4:21You have four questions for choosing between the two systems, and the first one is what the answer has to be.
4:27A vector database finds what reads like your query.
4:30A knowledge graph finds what is connected to an entity you have already identified. Neither one is a general upgrade on the other, and both of them earn their place.
4:40You also know what the structure costs. Extraction, resolution and summaries all have to be kept current, so you build it when the relationship questions keep coming back.
4:50And whichever side answers, you keep the path and the records behind it, so a fact can be traced and checked.
4:57That is where this whole series has been heading. An ontology for what a domain allows, a knowledge graph for what it actually holds, and resolved identities underneath both. None of this makes a system right.
5:11It keeps every decision in the open, so the wrong ones can be found and changed.

Four Questions Before You Build a Knowledge Graph

Created by Abhyuday DesaiPublished 3 Oct, v1Runs 5 min 23 sec

1 view

About this video

Before building a knowledge graph at all, know what it costs. This video walks the most elaborate thing people build on a corpus, a graph extracted at scale, grouped into communities and summarized, and shows what one changed document does to every stage. Then four questions settle the choice: what retrieval must produce, whether you need every match or a useful few, whether the structure is stable enough to maintain, and what you must be able to audit on either side.

You'll learn how to:

Price the ingestion pipeline a corpus-scale graph needs, and notice when plain vector retrieval is enough
Choose a graph when the answer is a path and vectors when it is a passage
Decide when a completeness claim matters and when a ranked few will do
Keep provenance on both sides, because a link to a record is not a tick

For developers making the build-or-not decision. Closes the series.

What changed

v103 Oct 2026abhydesai5 min 23 sec21ba95b

First published version.

1 view0 likes on this version