Entity Resolution: Prevent Duplicate Nodes from Breaking Your Knowledge Graph

[Definition] Entity resolution decides whether two records refer to the same real-world entity. In a knowledge graph, it is the difference between one connected customer, contract, or product node and a cluster of near-duplicate nodes that fragment retrieval.

Why a graph can be structurally wrong while every extraction looks plausible

Consider these mentions from three documents:

Acme Corporation
ACME Corp.
Acme, Inc.
ACME-001

An extractor may correctly identify each as an organization. If the pipeline creates four nodes, relationships split across them:

Acme Corporation ── signed ── Contract A
ACME Corp.        ── owns  ── Product X
Acme, Inc.        ── cited ── Risk Memo

A Graph RAG query for “What risks affect Acme?” may traverse only one node and miss the other evidence. The model did not fail at multi-hop reasoning; the graph supplied an incomplete identity.

Define identity before matching strings

A schema should state what makes an entity unique. Use the strongest stable identifier available:

Names are useful evidence, but they are not identity. The same name can represent different people; the same organization can have many legal or historical forms.

A practical resolution pipeline

Documents
  ↓
Extract mention + type + source span
  ↓
Normalize deterministic fields
  ↓
Retrieve candidate canonical entities
  ↓
Score match evidence
  ↓
Auto-link, review, or create a new entity
  ↓
Store provenance and confidence

1. Preserve the original mention

Keep the literal source text and span. Normalization should never erase evidence:

{
  "mention": "ACME Corp.",
  "source_document": "amendment-2026-04.pdf",
  "char_start": 318,
  "entity_type": "Organization"
}

2. Normalize deterministic variation

Safe transformations depend on the entity type:

"ACME Corp." → "acme corp"
"  Acme   Corp " → "acme corp"
"+1 (415) 555-0100" → "+14155550100"

Case folding, whitespace cleanup, punctuation removal, domain extraction, and date parsing reduce obvious variation. Do not aggressively remove legal suffixes, initials, or diacritics unless your domain validates the rule.

3. Retrieve candidates before expensive reasoning

Compare a mention only to plausible candidates. Candidate retrieval can use:

• ▸exact IDs and aliases;
• ▸normalized-name lookup;
• ▸phonetic or token overlap indexes;
• ▸embedding similarity for aliases or descriptions;
• ▸graph neighbourhood overlap, such as shared address or parent company.

This keeps an LLM or cross-encoder from evaluating every entity against every mention.

4. Score multiple signals

A robust decision combines evidence instead of trusting one similarity score:

match_score =
  0.45 × identifier agreement +
  0.25 × name similarity +
  0.15 × shared attributes +
  0.15 × graph-neighbour overlap

The weights and signals are domain-specific. A name match may be strong for a rare product SKU and dangerously weak for “John Smith.”

5. Use three decisions, not two

A forced binary match creates silent corruption. A review queue is often cheaper than repairing a graph after it has powered downstream RAG answers.

Entity resolution with an LLM

LLMs help with difficult aliases, multilingual names, and contextual disambiguation, but they should return structured evidence:

{
  "decision": "same_entity",
  "canonical_id": "org_acme_001",
  "confidence": 0.87,
  "evidence": ["same registered address", "alias listed in contract appendix"],
  "needs_review": false
}

Use the LLM after deterministic lookup and candidate retrieval. Do not ask it to invent a canonical identifier from an unrestricted graph; give it candidates and require it to cite the attributes supporting its choice.

Keep provenance when merging

Do not delete the original record after a merge. Model the decision:

Mention node ── refers_to {confidence: 0.94, method: "rules+review"} ──> Canonical entity

or maintain an alias table:

Alias: "ACME Corp." → org_acme_001
Alias: "Acme, Inc." → org_acme_001

Record the source, resolver version, timestamp, reviewer, and confidence. When a later correction occurs, you need to know which graph edges were derived from the wrong match.

Evaluation for resolution

Build a labelled pair set with true matches and true non-matches. Measure both sides of the error:

Precision = correct merges / all proposed merges
Recall    = correct merges / all true merges

For high-risk domains, optimize precision first. Merging two different patients, suppliers, or legal entities can be more harmful than leaving one true duplicate for a reviewer.

Evaluate slices too:

• ▸common versus rare names;
• ▸languages and transliteration variants;
• ▸old versus recent source systems;
• ▸types with or without stable IDs;
• ▸cross-tenant or permission-boundary cases.

Graph RAG consequences

Entity resolution directly affects retrieval quality:

A useful Graph RAG answer should be able to cite both the source documents and the entity-linking evidence used to traverse between them.

Free concepts, Pro implementation

This article is public because every graph project needs an explicit identity policy. The Pro build path applies it: define canonical IDs, create candidate rules, inspect ambiguous matches, and test the effect of resolution quality on multi-hop retrieval. A Live Cohort capstone adds domain-review and governance feedback.

Next steps

1. ▸Read Ontology and Schema Design to define entity types and relationship rules.
2. ▸Read Graph RAG for graph traversal and hybrid retrieval.
3. ▸Read GraphRAG Explained for local versus global graph queries.