Can LLMs be used for Entity Resolution?

How can I prevent LLM agents from confusing two customers with similar names?

The short answer: resolve the identity before the LLM sees it, with deterministic matching, not the model. This table contrasts an LLM-only approach with a rules-based / probabilistic entity resolution system on each criterion below; the full reasoning is preserved in the sections that follow.

Consistency & Reliability

Ask an LLM the same question in slightly different ways and there is a good chance you get a different answer. For example, asking 'Are John Smith at 123 Main St and J. Smith at 123 Main Street the same person?' versus 'Do these customer records refer to the same individual' might yield different confidence levels or even contradictory answers from the same LLM.

Then there are the straight out hallucinations. This means you can’t really rely on LLM-based entity resolution to always give the same fuzzy matching answer based on the same data, which is especially dangerous in a regulated environment.

A rules-based entity resolution system will always give the same results when the same data is repeatedly run through the system.

Explainability

“LLM says so” is not good enough to explain why two data records have been linked. Yes, you could ask the LLM to explain every pairwise connection, but this adds overhead and still has the above consistency and reliability problem.

In a rule-based entity resolution system, the rule that was used to trigger the linking between two records can be contained in the entity graph itself. This allows a user (or regulator!) to see exactly why two records were linked, down to the level of seeing which algorithms were applied to what data attributes with what thresholds and weightings.

Precision & Fine-tuning

When matching record data in entity resolution, you need to be able to control the precision (false positive rate) and recall (false negative rate) based on your use case. In some situations - such as in a credit bureau - a false positive match can be very dangerous, leading to potential fines, so you need to have very high precision. In other cases, such as fraud detection, you are looking for potential customer account matches, so you want to have high recall and can tolerate false positives.

With LLM-based entity resolution, you can’t easily adjust matching thresholds or implement use-case-specific matching tolerance.

Rules-based entity resolution allows bespoke matching accuracy based on your use case. Any matching adjustments can immediately be seen and measured, enabling you to fine-tune your matching configuration and, ultimately, the appropriate accuracy for your use case.

Temporal and Transient linking

In a specialised entity resolution solution, data can get complex but the system will handle it in a logical way so that it is still understandable and usable. For instance, individuals may change over time - a person’s name may change, they may have multiple addresses or email addresses over time. A company might change its name, or merge with another.

Representing that data relationship might mean records A to D are only linked transiently, via records B and C in a so-called entity-graph. Such an association needs to be persisted to make sense for future updates.

This is something that a LLM would not be able to handle when looking at a large body of data since an LLM cannot really maintain a memory of the relationships between different records over thousands or millions of data records.

Performance & Scalability Issues

LLMs are just slow. Processing a single record could take a few seconds, meaning it is completely unsuitable for real-time use cases, such as fraud-detection or customer on-boarding. Try to do entity resolutions on hundreds or thousands of records simultaneously and you will face significant problems.

High-performance entity resolution systems like Tilores are able to ingest and link records in milliseconds, and also simultaneously match thousands of records per second in parallel, without any performance degradation.

Cost

Token-based pricing makes large-scale LLM-based entity resolution extremely expensive. Processing millions of entity pairs through API calls becomes prohibitively costly.

Purpose-built entity resolution solutions are built with cost-efficiency in mind, meaning lower operational costs for high-volume workloads. We are not talking about small differences here. Using a LLM for entity resolution could easily be 100x more expensive, and possible 1000s of times more expensive than a bespoke entity resolution solution.

Then there is the API-rate limiting that most LLMs apply…

Sledgehammer for a Nut

There are many other drawbacks of using LLMs for entity resolution, but I think you get the point by now. Yes, they can do entity resolution, but LLMs are not the right tool for a job which is already solved by existing bespoke entity resolution systems. They are the proverbial sledgehammer being used to open a nut, when the nutcracker already does a fine job.

So when should we use LLMs in entity resolution?

It might sound like we are just being biased and anti-LLM, but that could not be further from the truth (ok, we are biased). LLMs are one of the most amazing technical transformations of our lifetime, and they do have their place in entity resolution, if used appropriately.

LLMs in Named Entity Recognition

Named entity recognition (NER) is the term for the extraction of entity attribute data from unstructured or semi-structured data. Imagine you had a large number of free text criminal court records. An LLM would excel at extracting the name of the defendants and the lawyers involved to create structured court records.

It would be highly likely that court records belonging to the same person would be extracted by an LLM with inconsistencies, especially if they are involved in multiple cases, therefore if I then wanted to link all court records that are linked to a particular individual, entity resolution would be needed in a subsequent step.

In this respect, LLMs make a perfect pre-entity resolution pre-processing tool for named entity recognition that would otherwise be difficult to achieve with regular natural language processing (NLP) techniques.

LLMs in the Loop

An important feature of an entity resolution system, is the so-called “human in the loop” whereby an individual human (e.g. a data analyst or domain specialist) can look at proposed pairwise matches that could belong together but do not meet a definitive threshold, but do warrant manual review.

It may be feasible to replace the human in this process with an agentic LLM to make these decisions. The above LLM shortcomings would still be applicable, but on a low enough volume of matches (on the assumption that even two human agents could propose different matching results) this would be an appropriate use for LLMs in entity resolution.

Guardrails for an “LLM in the Loop” would include justifying, in natural language, why each pairwise connection was made. And such agentic record connections would be flagged in the entity resolution system for potential future human auditing.

Entity Resolution based RAG for LLMs

Where we at Tilores are bullish about the potential for LLMs in entity resolution is actually the opposite way around: using an entity resolution system as a data source for LLMs - so-called retrieval augmented generation (RAG).

At Tilores we call this “IdentityRAG” where an LLM is connected, via LangChain, to a Tilores instance containing identity (e.g. customer) data. In cases where you need the LLM to be accurately retrieving information about specific identities - such as for customer service - an entity/identity resolution system excels at 1) ensuring that the correct identity is retrieved and 2) providing all possible information about the individual from disparate data sources within an organisation.

Where LLMs still make sense in Entity Resolution

• For quick analysis of small data sets, I would probably use an LLM before an entity resolution system like Tilores
• As a pre-processing step for Named Entity Recognition
• As a replacement for humans in agentic edge care analysis.

The current view (2026): does the research agree?

This piece argues that LLMs can do entity resolution but usually shouldn't, for reasons of consistency, explainability, precision, scale and cost. As of 2026, peer-reviewed and conference research has tested exactly that and broadly agrees:

• Cost is real and structural. A 2024 study, On Leveraging Large Language Models for Enhancing Entity Resolution: A Cost-efficient Approach (arXiv 2401.03426), states that current LLMs are "costly due to per-API request billing" and that existing methods "either lack quality or become prohibitively expensive at scale" — which is why it proposes selectively querying only the most valuable matching pairs rather than every pair.
• Naive pairwise matching is the expensive part. A SIGMOD 2026 paper, In-context Clustering-based Entity Resolution with Large Language Models (arXiv 2506.02509, June 2025), notes that methods focused on pairwise matching are "costly in terms of time and monetary resources, especially with large datasets," and that clustering records instead cut API calls by up to 5× at comparable monetary cost.
• Single-LLM matching needs coordination and guardrails. A December 2025 study in MDPI Computers, Multi-Agent RAG Framework for Entity Resolution, reports 94.3% accuracy on name-variation matching and a 61% reduction in API calls versus single-LLM baselines — reinforcing that production-grade results come from structure around the model, not a single LLM call, exactly the "LLM in the Loop" pattern described above.

The practical 2026 takeaway for the question that opens this article — how to stop an LLM agent confusing two customers with similar names — is unchanged: keep the identity matching deterministic and explainable, and use the LLM the opposite way around, retrieving a single resolved identity through IdentityRAG. Tilores has written more on this for regulated settings in improving LLM accuracy with entity-resolution-based RAG.

Frequently asked questions

Can LLMs be used for entity resolution?

Jein — "hmm, kinda." Given two records, or a short list, an LLM can decide whether they belong to the same identity and will probably do a decent job. But for production entity resolution it is a sledgehammer for a nut: LLMs are weak on consistency and reliability, explainability, precision and fine-tuning, temporal and transient linking, performance and scalability, and cost. Bespoke entity resolution systems already solve that job.

How can I prevent LLM agents from confusing two customers with similar names?

Do not ask the LLM to do the matching itself. Put a deterministic entity resolution system in front of it and feed the LLM a single resolved identity. At Tilores this is IdentityRAG: the LLM is connected, via LangChain, to a Tilores instance containing identity data, so the correct identity is retrieved and all available information about that individual is assembled from disparate sources before the LLM answers. An LLM asked the same matching question two slightly different ways can give contradictory answers, so the resolution must be deterministic and explainable, not left to the model.

Where do LLMs break in entity resolution, and where do they fit?

LLMs break on six drawbacks: consistency and reliability, explainability, precision and fine-tuning, temporal and transient linking, performance and scalability, and cost. They fit in three narrower roles: quick analysis of small data sets, named entity recognition (NER) as a pre-processing step, and as a replacement for the human in agentic edge-case review. The most valuable use is the opposite way around — using a resolution system as a data source for the LLM via IdentityRAG.

Why is using an LLM for large-scale entity resolution so expensive?

Token-based, per-API-request pricing makes large-scale LLM-based entity resolution extremely expensive: processing millions of entity pairs through API calls becomes prohibitively costly. Tilores puts the figure at easily 100x and possibly 1000s of times more expensive than a bespoke entity resolution solution, before API rate-limiting is even considered. Peer-reviewed research agrees — a 2024 arXiv study notes current LLMs are costly due to per-API request billing and that methods either lack quality or become prohibitively expensive at scale.

Where do LLMs actually make sense in entity resolution?

Three places. For quick analysis of small data sets, an LLM is fine before reaching for a system like Tilores. As a pre-processing step for named entity recognition (NER), extracting structured attributes from free text. And as a replacement for the human in agentic edge-case ("human in the loop") analysis, on a low enough volume of matches and with guardrails that justify each pairwise connection in natural language and flag it for future audit.

What is IdentityRAG and how does it use LLMs the right way around?

IdentityRAG uses an entity resolution system as a data source for LLMs rather than asking the LLM to do the resolution. At Tilores an LLM is connected, via LangChain, to a Tilores instance containing identity (e.g. customer) data. When you need the LLM to retrieve information about a specific identity — such as for customer service — the entity/identity resolution system ensures the correct identity is retrieved and provides all possible information about the individual from disparate data sources within an organisation.