Entity Resolution Duplicate Names: Improving RAG Accuracy

Entity resolution for duplicate names combines blocking, fuzzy string matching, and embedding-based similarity to detect when records like 'JPMorgan' and 'Chase Bank' refer to the same entity. You then merge them into a golden record before indexing, preventing retrieval fragmentation and hallucination in RAG systems. Addressing entity resolution duplicate names early ensures your knowledge graph maintains relationship integrity.

What Entity Resolution Means for Duplicate Names

Entity resolution is the process of determining when different data records refer to the same real-world entity, turning fragmented identity data into a single accurate view for fraud detection, compliance, and AI decision-making (source). Common synonyms include record linkage, fuzzy matching, data matching, and identity resolution (source).

The terminology has evolved. Record linkage dates to 1946, while identity resolution emerged in the early 2000s, often referring specifically to people and organizations (source). Today, identity resolution is considered a subset focused specifically on unifying customer records for marketing, while entity resolution covers a wider scope including households, business accounts, product SKUs, and devices (source).

The economic stakes are high. Poor data quality costs organizations an average of $12.9 million annually according to Gartner. Additionally, 94% of businesses suspect their customer and prospect data is inaccurate. When building a RAG system, these inaccuracies propagate directly into retrieval quality.

For those building How to Build Knowledge Graph from Documents for Your Company, entity resolution is the step that determines whether your graph contains four nodes for one bank or one node with four aliases.

Why Duplicate Names Break RAG Retrieval

Duplicate names for the same entity can include variations like 'JPMorgan', 'JP Morgan Chase', 'Chase Bank', and 'JPMC' (source). Without resolution, these appear as disconnected nodes in a knowledge graph, losing relationship integrity (source).

Consider what happens during retrieval. A user asks about JPMorgan's exposure to a specific sector. The graph contains a node for 'JPMorgan' linked to three relevant documents, a node for 'Chase Bank' linked to two others, and a node for 'JPMC' linked to one more. A vector search over these disconnected nodes returns partial results. The RAG system synthesizes an answer from three documents and misses the other three entirely.

This is how duplicate names cause hallucination. The model, lacking the full context, fills gaps with plausible but incorrect information. The knowledge graph has the data, but the fragmentation prevents retrieval from finding it. When comparing GraphRAG vs. Vector RAG: When a Knowledge Graph Beats Top-k, graph-based approaches suffer specifically from this node fragmentation problem.

The fragmentation problem worsens with US corporate data. There is no federal companies register, leading to over 50 separate state and territory registries (source). A single company can have different IDs and slightly different legal names across jurisdictions (source).

Step-by-Step: Resolving Duplicate Names Before Indexing

Creating golden records involves standardizing inputs, generating candidate pairs, scoring similarity, and applying survivorship rules (source). A golden record represents the best version of critical entities created by linking or merging duplicate records (source).

Here is a numbered procedure for resolving duplicate names before indexing:

1. Schema alignment: Map and standardize data fields from different sources to a common set of attributes. For example, map 'item_name' from one dataset and 'model_name' from another to a standardized 'product_name' field (source).

2. Blocking: Reduce the search space by creating smaller sets of candidate pairs to compare. Without blocking, comparing every record to every other record creates an N-squared problem that becomes impractical at scale (source).

3. Scoring similarity: Compare candidate pairs using embedding-based similarity and fuzzy string matching. Score each pair and rank by confidence.

4. Applying survivorship rules: Determine which field values survive into the golden record when sources conflict. Rules might prioritize the most recent filing, the most authoritative source, or the most complete record.

5. Creating golden records: Merge confirmed duplicates into a single node that retains all aliases and links back to source filings for provenance.

Provenance matters for auditors and regulators. OpenCorporates, which holds data on over 220 million companies across more than 140 jurisdictions, links every field in their database back to its official filing (source). Your golden records should follow the same principle.

Matching Techniques: Embeddings vs Fuzzy String Matching

Entity resolution systems use embedding-based similarity to find semantically similar entities via vector embeddings (source). Neo4j vector indexes find nearest neighbors, with scores above a threshold triggering automatic merges and lower scores flagging for review (source).

Fuzzy string matching complements embedding similarity by handling typos and abbreviations using token-based comparison (source). Libraries like rapidfuzz calculate scores, such as 100 for 'JP Morgan Chase' vs 'Chase JP Morgan' using token_sort_ratio (source).

The two techniques catch different problems. Embeddings recognize that 'JPMorgan Chase' and 'Chase Bank' are semantically related even though they share no common tokens. Fuzzy matching catches that 'JPMC' is an abbreviation of 'JPMorgan Chase' with a partial_ratio score of 80.

Using both in combination gives you coverage for both semantic drift and lexical variation. A pair that scores low on fuzzy matching might score high on embedding similarity, and vice versa.

Preventing False Positives with Type Constraints and Human Review

Type-constrained matching prevents false positives by only matching entities of the same type, such as ORGANIZATION (source). This ensures 'Apple' the company matches 'Apple Inc' but not 'Apple' the fruit product (source).

Without type constraints, your matching pipeline creates invisible false positives. A merge between 'Apple' the company and 'Apple' the fruit corrupts the golden record. Downstream retrieval returns agricultural documents when the user asked about stock prices. These errors are hard to detect because the names match perfectly.

The SAME_AS pattern creates relationships for human review when automatic merging confidence is insufficient (source). These relationships store metadata including confidence scores, status (pending, confirmed, rejected), and creation timestamps (source).

This human-in-the-loop approach is essential for edge cases. When embedding and fuzzy scores disagree, or when both fall in a middle range, automatic merging is risky. The SAME_AS relationship preserves the candidate match without committing to a merge, letting a reviewer make the final call.

For systems aligned with the EU AI Act for RAG Deployments: What Actually Applies Since August 2026, this audit trail of confidence scores and review status provides the documentation regulators expect.

Practical Takeaway: Build a Pipeline That Survives Ambiguity

A robust pre-indexing pipeline for entity resolution combines four mechanisms. Blocking reduces the search space in entity resolution by creating smaller sets of candidate pairs to compare (source). Type-constrained matching prevents false positives by only matching entities of the same type, such as ORGANIZATION (source).

Dual scoring with both embeddings and fuzzy string matching catches semantic and lexical variations. Neo4j vector indexes find nearest neighbors, with scores above a threshold triggering automatic merges and lower scores flagging for review (source). The SAME_AS pattern creates relationships for human review when automatic merging confidence is insufficient (source).

External identifiers can further boost accuracy. Legal Entity Identifiers (LEIs) cover almost 2.9 million entities globally. Having an LEI can jump matching accuracy to near-perfect, though they represent a tiny fraction of the full business universe (source). In 2023, GLEIF linked over half of all LEIs directly to OpenCorporates IDs, creating an open bridge between registry truth and global financial reporting systems (source).

The pipeline that survives ambiguity is one that never forces a binary merge decision when confidence is low. Block aggressively, match within types, score with two complementary techniques, and route uncertain matches to human review. Your RAG system will return coherent answers because your graph contains coherent entities.

FAQ

What is the difference between entity resolution and identity resolution?

Identity resolution is a subset focused specifically on unifying customer records for marketing. Entity resolution covers a wider scope including households, business accounts, product SKUs, and devices (source).

How do blocking strategies reduce the computational cost of comparing millions of records?

Blocking creates smaller sets of candidate pairs to compare. Without blocking, comparing every record to every other record creates an N-squared problem that becomes impractical at scale (source).

What are the risks of false positives when matching entities with similar names?

False positives merge unrelated records. Type-constrained matching prevents this by only matching entities of the same type, ensuring 'Apple' the company matches 'Apple Inc' but not 'Apple' the fruit (source).

How do Legal Entity Identifiers (LEIs) improve matching accuracy for business data?

LEIs cover almost 2.9 million entities globally. Having an LEI can jump matching accuracy to near-perfect, though they represent a tiny fraction of the full business universe (source).

What role does human review play in the entity resolution workflow?

The SAME_AS pattern creates relationships for human review when automatic merging confidence is insufficient. These store metadata including confidence scores, status (pending, confirmed, rejected), and timestamps (source).

How do embedding-based similarity and fuzzy string matching work together?

Embeddings find semantically similar entities via vector indexes. Fuzzy string matching complements this by handling typos and abbreviations using token-based comparison, such as rapidfuzz scoring 'JP Morgan Chase' vs 'Chase JP Morgan' at 100 (source).