MDM #5. Knowledge Graph-Based Entity Resolution: The Pursuit of Zero Duplicate Data
"International Business Machines Corporation" and "IBM" are the same company. "350 Fifth Avenue, New York, NY" and "350 5th Ave, NYC" are the same address. A human recognizes both instantly. A traditional MDM system, left to its own devices, registers them as two separate entities. That's where duplication begins — and where data quality problems start compounding.
Knowledge graph-based entity resolution is currently the strongest answer to this problem. It moves past simple string comparison and instead understands the context and relationships between data points to accurately identify when two records describe the same real-world entity. This article — the fifth in our global MDM series, and the closing piece of Part 1 — covers what entity resolution actually is, where traditional matching methods fall short, how knowledge graphs change the equation, and what a real implementation architecture and rollout plan look like.
- What Entity Resolution Actually Is
- The Real Business Cost of Duplicate Data
- Where Traditional Deduplication Methods Fall Short
- What a Knowledge Graph Is — An MDM Perspective
- How Knowledge Graph-Based Entity Resolution Actually Works
- Core Technical Components
- Applying This by Domain
- A Rollout Roadmap and Key Considerations
- Where This Leaves Us
1. What Entity Resolution Actually Is
Entity resolution is the process of determining whether records sitting in different source systems refer to the same real-world entity, and consolidating them into a single, unified representation. You'll also see it called record linkage, entity matching, or deduplication, depending on the context.
MDM's central goal is establishing a single source of truth. If the same customer, product, or supplier sits in multiple systems under different names and codes, even the best-designed MDM platform can't produce a unified view. Entity resolution is the work that lays the foundation for that consolidation to actually be possible.
| Type | Description |
|---|---|
| Deduplication | Finds duplicate records referring to the same entity within a single system and merges them into one |
| Record linkage | Connects records across different systems that refer to the same entity, without merging them |
| Canonicalization | Selects one representation among several variants and designates it as the master version |
| Entity fusion | Combines attribute data from multiple sources into the most complete possible master record |
2. The Real Business Cost of Duplicate Data
Duplicate data isn't just an untidy database problem. It generates direct cost and lost opportunity across the entire business.
| Impact Area | What Actually Happens |
|---|---|
| Wasted marketing spend | The same customer receives duplicate mailers, emails, and coupons — wasted spend, customer annoyance, and rising spam complaints that hurt email deliverability over time |
| Contaminated AI models | Recommendation and churn-prediction models that learn the same customer as two different people see their accuracy degrade — cutting AI ROI roughly in half |
| Inventory and procurement errors | The same material registered under different codes appears to be in shorter supply than it actually is, triggering unnecessary reorders and excess carrying cost |
| Regulatory compliance exposure | Duplicate contracts with the same counterparty, duplicate invoicing, and errors in supply chain transparency reporting all create regulatory risk |
| Degraded customer experience | A customer recognized differently across channels gets inconsistent service — fragmented loyalty points, missed discounts |
| Unreliable analytics | Executive reports built on data containing duplicates are distorted, overstating customer counts and supplier counts |
Industry surveys put average duplicate rates in enterprise master data somewhere in the 5–30% range, with annual losses for large enterprises estimated anywhere from several million to tens of millions of dollars. Duplication isn't a data hygiene issue — it's a business problem.
3. Where Traditional Deduplication Methods Fall Short
Conventional MDM systems rely on two broad approaches to detect duplicates. Both have clear limits.
Two records are flagged as duplicates only when specific fields — name, tax ID, email — match exactly.
The limitation: A single typo, an extra space, or a different formatting convention breaks detection entirely. "Procter & Gamble" and "P&G Co." get processed as completely unrelated records.
Candidate duplicates are surfaced based on string similarity measures such as edit distance (Levenshtein) or phonetic similarity (Soundex).
The limitation: This approach mishandles both directions of the problem — entities with similar-looking strings that are actually completely different companies (think "SK Hynix" and "SK Siltron," two distinct affiliates within the same Korean industrial group), and entities with dissimilar strings that are, in fact, the same company. It has no understanding of linguistic context or business relationships.
The fundamental limitation shared by both approaches is the same: neither understands the semantics or relationships behind the data. That's precisely the gap knowledge graphs close.
4. What a Knowledge Graph Is — An MDM Perspective
A knowledge graph is a database that stores entities (nodes) and the relationships between them (edges) in graph form. Rather than simply storing data, it preserves the context and meaning connecting that data together.
[Hyundai Motor Company] ──(parent of)──→ [Hyundai Motor Group]
[Hyundai Motor Company] ──(headquartered in)──→ [Seoul, South Korea]
[Hyundai Motor Company] ──(produces)──→ [Passenger Vehicles], [Commercial Vehicles]
[Hyundai Motor Company] ──(registration no.)──→ [201-81-XXXXX]
[HMC] ──(sameAs)──→ [Hyundai Motor Company]
In this graph, "HMC" and "Hyundai Motor Company" are linked through a sameAs relationship, so a query using either form resolves to the identical entity.
| Dimension | Relational DB (Traditional MDM) | Knowledge Graph-Based MDM |
|---|---|---|
| How data is stored | Tables, rows, and columns | Nodes (entities) and edges (relationships) |
| Expressing relationships | Limited to foreign-key constraints | Freely expresses many different relationship types |
| Contextual understanding | None — structural data only | Context can be inferred by traversing relationship paths |
| Duplicate detection | Centered on direct field comparison | Semantic comparison that also accounts for relationship patterns |
| Scalability | Schema changes require significant rework | New entity and relationship types can be added flexibly |
5. How Knowledge Graph-Based Entity Resolution Actually Works
Entity resolution built on a knowledge graph determines whether two records describe the same entity by combining four distinct signals.
| Signal | What It Measures | Example |
|---|---|---|
| ① Attribute similarity | Similarity of direct attributes — name, address, phone number — based on fuzzy matching | "HMC" and "Hyundai Motor Company" show low string similarity on their own, but other signals compensate |
| ② Relationship overlap | Whether both records connect to the same related entities | If both records link to the same tax ID and the same legal representative, the likelihood of a match rises sharply |
| ③ Graph neighborhood pattern | Whether the pattern of connected entities is similar | Two supplier records with a history of transacting with the same materials and the same buyers are more likely to be the same entity |
| ④ External knowledge cross-reference | Cross-checking against external business data and public registries | Confirming identity against Dun & Bradstreet records or a national business registry such as the IRS EIN database or Korea's National Tax Service |
These four signals are combined with weighted scoring to calculate a final similarity probability. Even when one signal is weak on its own, the others compensate, producing far higher overall accuracy. This is the fundamental difference between knowledge graph-based resolution and simple fuzzy matching.
6. Core Technical Components
| Component | Function | Representative Technologies |
|---|---|---|
| Graph database | Stores and queries entities and relationships in graph form; optimized for relationship-path traversal | Neo4j, Amazon Neptune, TigerGraph |
| Embedding models | Converts text attributes into vectors; the foundation for semantic similarity computation | BERT, Sentence-BERT, OpenAI Embeddings |
| Vector database | Stores embedding vectors and performs approximate nearest-neighbor search; enables similarity calculations across millions of records | Pinecone, Weaviate, pgvector |
| Graph neural networks (GNNs) | Learns patterns from graph structure to improve entity-match prediction accuracy | PyTorch Geometric, DGL |
| External data connectors | Real-time cross-referencing against business information databases and public registries | D&B API, OpenCorporates, national tax/business registry APIs |
| Decision engine | Combines all signals into a final match determination; routes by confidence level | Custom ML models combined with a rules engine |
Major MDM platforms — Informatica IDMC, Reltio, Stibo Systems among them — already offer knowledge graph-based entity resolution built in, or provide integration paths into existing graph infrastructure. For most organizations, adopting a proven platform is a far more realistic path than building this stack in-house.
7. Applying This by Domain
The problem: The same customer signs up separately through email and through two different social login providers. Name typos and inconsistent address formatting cause standard deduplication to miss the match entirely.
The knowledge graph approach: Combine name, email, and phone attribute similarity with purchase-pattern graph-neighborhood similarity and cross-reference against linked-identity verification data → records above 95% match probability merge automatically.
Impact: Customer duplicate rate drops from 15% to 2%; personalized marketing efficiency improves by roughly 40%
The problem: The same global supplier is registered under different names and codes across each subsidiary's local ERP system. The group-wide supplier count comes out to roughly three times the actual number.
The knowledge graph approach: Multilingual embeddings of legal entity names, a corporate group relationship graph, and integration with D&B global business data → automatic hierarchical grouping under the correct parent entity.
Impact: Supplier record count consolidated by 62%; stronger procurement negotiating leverage; improved accuracy in ESG supply chain reporting
The problem: The same component is registered under different names and codes across procurement, production, and maintenance teams. Inaccurate inventory visibility leads to repeated unnecessary reorders.
The knowledge graph approach: Product specification similarity, supplier relationship patterns, and embedding similarity across technical documentation → automatic identification of identical components and mapping to a standard code.
Impact: 45% reduction in duplicate material codes; 10–15% annual reduction in inventory and procurement costs
8. A Rollout Roadmap and Key Considerations
| Phase | Duration | Key Activities |
|---|---|---|
| Phase 1 Assess |
1–2 months | Measure current duplicate rates. Identify the source systems and domains where duplication originates. Prioritize by business impact. |
| Phase 2 Pilot |
2–4 months | Run a pilot on a single domain — customer or supplier. Stand up the graph database and apply embedding models. Measure accuracy and tune thresholds. |
| Phase 3 Automate |
4–8 months | Activate confidence-based auto-processing. Integrate the steward review workflow. Build out an audit log for all processing history. |
| Phase 4 Scale |
8 months+ | Extend across all master domains. Move to real-time streaming-based detection. Sharpen accuracy further through external data integration. |
- Golden record policy comes first: Decide which source system's values take precedence as the golden record before you write a line of implementation code. Governance policy has to precede technical build, not follow it.
- Design a rollback path for bad merges: You need a mechanism to reverse a merge when the AI gets it wrong. An incorrect merge can be more damaging than the original duplicate ever was.
- Build trust incrementally: Start with detection-only, human-approved processing. Expand the automated scope only once the AI's judgment has been thoroughly validated — that's the safer path.
9. Where This Leaves Us
Knowledge graph-based entity resolution is currently the strongest available answer to MDM's hardest problem — accurately recognizing the many different representations of the same real-world entity. By combining relationships, context, and external knowledge with attribute comparison, it automates a level of judgment that, until recently, only a human could reliably make.
Knowledge graphs are what let you close in on it
at a pace nothing before them could match."
That closes out Part 1 — "AI & Agentic MDM: The Age of Intelligent Data Management." Part 2 moves from global trends into real-world implementation challenges that enterprises actually run into on the ground, starting with why so many digital transformation initiatives still fail — and the master data problem hiding behind that failure rate.
Part 1. AI & Agentic MDM — The Age of Intelligent Data Management ✅ Complete
- The 2026 MDM Inflection Point: How AI Agents Are Redefining Master Data Management
- AI-Ready Data: Why Modern AI Is Starving for High-Quality Master Data
- The Core of Agentic Data Management: The Role and Future of the Data Steward Agent
- Self-Healing Master Data: How AI Detects and Repairs Errors on Its Own
- Knowledge Graph-Based Entity Resolution: The Pursuit of Zero Duplicate Data (this article)
Part 2. MDM on the Ground — Failure Patterns and How to Overcome Them
- Why 70% of Digital Transformation Initiatives Fail: The Master Data Culprit
- Why MDM Projects Struggle to Win Executive Buy-In: A Business Case Playbook
- Seven Failure Patterns in Enterprise MDM Adoption
- The Reality of Enterprise MDM Governance
- Why MDM Fails During ERP Modernization: Lessons from SAP S/4HANA
※ This blog analyzes MDM, CIAM, digital transformation, and enterprise AI strategy from a practitioner's perspective, drawing on hands-on experience leading master data transformation at a global technology manufacturer.
댓글
댓글 쓰기