Knowledge graph projects tend to hit the same problem early. The ontology is clean, the sources are mapped, and then the graph has four nodes for one customer: "ACME Ltd", "Acme Limited", "ACME LTD." and a typo. Every query that touches that customer is now wrong, and an AI agent reading the graph will be confidently wrong.
Entity resolution is how you fix that. It is less glamorous than ontology design and just as important.
The three stages
End-to-end entity resolution is usually described as three stages: blocking, matching and clustering2.
| Stage | What it does | Why it matters |
|---|---|---|
| Blocking | Chooses which pairs of records are worth comparing | Comparing every pair is impossible at scale |
| Matching | Scores how likely each candidate pair is the same entity | Where accuracy is won or lost |
| Clustering | Groups matched pairs into entities | Turns pairwise decisions into consistent entities, and can infer indirect matches |
Blocking: don't compare everything
A million records means roughly half a trillion possible pairs. Blocking narrows that to plausible candidates, for example records sharing a postcode, the first letters of a surname, or a normalised company name. A survey of the field describes candidate selection as the main lever for making entity resolution scale1.
The trade-off is recall. Block too tightly and true matches never get compared. I use several blocking rules in combination, then measure how many known matches each rule would miss.
Matching: probabilistic and explainable
The classic approach is the Fellegi-Sunter model. Each field comparison, such as name, date of birth or address, contributes evidence for or against a match, weighted by how informative agreement on that field is. Modern record linkage is still largely built on it3.
I like it for two reasons. It works without much labelled data, because parameters can be estimated from the data itself. And it is explainable: you can show exactly which fields drove a match, which matters in healthcare, finance and anywhere an auditor might ask.
Splink, an open-source library developed at the UK Ministry of Justice, implements this approach at scale and is used to link people across courts, prisons and probation datasets45. It is usually the first tool I evaluate.
Machine-learned matchers can beat probabilistic ones on very messy data, but they need labelled pairs and are harder to explain. Start probabilistic, measure, and only add complexity where the numbers justify it.
Clustering: make decisions consistent
Pairwise matching can produce contradictions: A matches B, B matches C, but A doesn't match C. Clustering resolves these into consistent groups and can infer matches that were never directly compared2. In a graph, each cluster becomes one entity node with links back to every source record, so you never lose provenance.
How it fits the knowledge graph
- Resolve before you load. Run resolution in the pipeline and load resolved entities, keeping source records as linked nodes.
- Keep the evidence. Store match scores and contributing fields on the links, so a wrong merge can be explained and reversed.
- Use the ontology to guide matching. Entity types define which fields matter: date of birth for people, registration numbers for companies, product codes for items.
- Human review for the grey zone. Auto-accept high scores, auto-reject low ones, and route the middle band to a reviewer.
- Re-run incrementally. New records are matched against existing entities rather than reprocessing everything.
This is the step that makes the ideas in ontology vs knowledge graph vs semantic layer work on real data, and it is why GraphRAG answers can be trusted. The same discipline applies to patient matching in healthcare platforms, which I touch on in OMOP data quality.
How I can help
I design knowledge graphs and the resolution pipelines that feed them, from blocking strategy to review workflows. See ontology and knowledge graphs, or analyse your challenge and bring the result to a call.
- 1A Survey of Blocking and Filtering Techniques for Entity ResolutionPapadakis et al., arXiv · 2019
- 2An overview of end-to-end entity resolution for big dataThe Morning Paper · Dec 2020
- 3The State of Record Linkage and Current Research ProblemsWilliam Winkler, US Census Bureau · 1999
- 4Splink: free software for probabilistic record linkage at scaleLinacre et al., International Journal of Population Data Science · 2022
- 5