Entity Resolution: The Matcher Was Never the Bottleneck

A benchmark published in March 2026 took 755,540 labelled record pairs from 293 sanctions lists, corporate registries and leak datasets across 31 countries, with multilingual names, set-valued fields and the kind of attribute noise that real registries produce, and ran both a production rule-based matcher and a set of language models over all of them. The rule engine, OpenSanctions' own nomenklatura regression model, scored 91.33 F1. GPT-4o scored 98.95. A 14-billion-parameter distilled model that runs on one machine scored 98.23 (Smith et al., 2026, OpenSanctions Pairs: Large-Scale Entity Matching with LLMs, arXiv:2603.11051).

The interesting part is what the authors did with that result. They did not conclude that entity resolution is solved by a better classifier. They concluded that pairwise matching is approaching a practical ceiling, and that effort should move to blocking, clustering and uncertainty-aware review. That is an unusual thing for a paper reporting a 7.6-point F1 win to say, and it is correct.

Why this matters: Every customer data platform, every sanctions screening system, every knowledge graph assembled from more than one source, and every "golden record" project runs an entity resolution pipeline. Twenty years of research measured one stage of that pipeline, the stage that decides whether two records match. That stage is now very good. The stages on either side of it, which decide which pairs get compared at all and how pairwise verdicts become entities, are where production systems actually lose accuracy, and they have almost no benchmark culture at all.

TL;DR

• Entity resolution is quadratic by nature: deduplicating 10 million records means \(\binom{10^7}{2} \approx 5.0 \times 10^{13}\) candidate pairs, so no pipeline ever evaluates them all and every pipeline throws most of them away before the matcher runs.
• Recall discarded during candidate generation is unrecoverable. A matcher with perfect accuracy cannot find a duplicate pair it never sees, so blocking sets a hard ceiling on end-to-end recall that no model improvement can lift.
• The matcher got dramatically better, fast. Ditto's fine-tuned language model beat the enhanced DeepMatcher baseline by 26.53 F1 on Abt-Buy, 89.33 against 62.8 (Li et al., 2020, arXiv:2004.00584).
• Then the benchmarks turned out to be easy. A systematic re-evaluation of 13 established matching datasets concluded that most pose rather easy classification tasks and are unsuitable for evaluating learning-based matchers (Papadakis et al., 2023, arXiv:2307.01231).
• Generalisation is the real gap: on WDC Products, built specifically to measure it, every matcher's F1 drops significantly on entities it has not seen in training (Peeters et al., 2024, arXiv:2301.09521).
• LLM matchers reach fine-tuned-PLM quality with zero or a handful of examples, and are more robust to unseen entities, but there is no single best prompt: prompt and model interact strongly with the dataset (Peeters, Steiner & Bizer, EDBT 2025, arXiv:2310.11244).
• Cost, not accuracy, is what rules LLMs out of candidate generation. Scoring 835 million candidate pairs at roughly 300 input tokens each is \(2.5 \times 10^{11}\) tokens of inference, which is why the model belongs on the uncertainty band and nowhere near the full candidate set.
• Pairwise precision does not bound cluster-level error. Entities are formed by closing the match graph, and one false edge between two correct clusters merges them permanently, with no upper bound on the damage.

At a Glance

Five stages, and only one of them has a leaderboard. The pipeline's end-to-end recall is the product of what survives each stage, and the stage with the research attention is the one in the middle.

flowchart LR
  S["Sources, n records"] --> B["Candidate generation: blocking, filtering, ANN"]
  B --> M["Pairwise matching: the stage with benchmarks"]
  M --> C["Clustering: pairwise verdicts to entities"]
  C --> R["Review and merge"]
  B -. "recall lost here is unrecoverable" .-> L["Ceiling on end-to-end recall"]
  classDef blue fill:#1e40af,stroke:#3b82f6,stroke-width:1px,color:#fff
  classDef purple fill:#6d28d9,stroke:#a78bfa,stroke-width:1px,color:#fff
  classDef teal fill:#0e7490,stroke:#22d3ee,stroke-width:1px,color:#fff
  classDef rose fill:#be123c,stroke:#fb7185,stroke-width:1px,color:#fff
  classDef slate fill:#334155,stroke:#64748b,stroke-width:1px,color:#e2e8f0
  class S blue
  class B,C purple
  class M teal
  class R slate
  class L rose

[IMAGE: Waterfall chart of end-to-end recall through a five-stage pipeline. Bar 1 starts at 100 percent, bar 2 drops to 96.2 percent labelled "blocking: pair completeness", bar 3 drops to 95.1 percent labelled "matcher recall", bar 4 stays flat labelled "clustering: precision loss, not recall loss". Caption: "Where the recall actually goes, and which stage the literature measures."]

Before the Matcher Got Good

Record linkage has a statistical foundation older than relational databases. Fellegi and Sunter formalised the problem as a likelihood-ratio test: for each pair, compute the ratio of the probability of the observed agreement pattern given that the pair is a match to its probability given that the pair is not, then set two thresholds, one for automatic acceptance and one for automatic rejection, leaving a middle band for clerical review (Fellegi & Sunter, 1969, A Theory for Record Linkage, Journal of the American Statistical Association 64(328), 1183–1210). The clerical review band was in the original formulation. Fifty-seven years later the OpenSanctions paper arrives at the same recommendation from the opposite direction.

What changed between then and now is who does the comparing.

The 2010s brought machine learning to the matcher, and the field organised itself around pair-classification benchmarks. Magellan argued, usefully and somewhat against the grain, that the research community should build complete systems with how-to guidance for every pipeline stage rather than publishing matchers in isolation (Konda et al., 2016, Magellan: Toward Building Entity Matching Management Systems, PVLDB 9(13), 1581–1584). Two years later DeepMatcher mapped the deep-learning design space across four model families and three problem types, and reported a result worth remembering: deep learning did not beat the existing learning-based solution on structured matching, but it did beat it substantially on textual and dirty data (Mudgal et al., 2018, Deep Learning for Entity Matching: A Design Space Exploration, SIGMOD).

Then pre-trained language models arrived and the gap closed violently. Ditto serialised each record pair into a sentence, fine-tuned a transformer on it, and added domain knowledge injection, span-level augmentation and a summarisation step for long values. On Abt-Buy, the hardest of the standard product datasets, it reached 89.33 F1 against DeepMatcher+'s 62.8, and the paper notes that even the plain fine-tuned DistilBERT baseline, with none of the extras, beat DeepMatcher+ substantially on every dirty dataset (Li et al., 2020, Deep Entity Matching with Pre-Trained Language Models, arXiv:2004.00584).

The reckoning came next. A systematic re-evaluation of the 13 datasets everyone had been using, assessed with new measures of linearity alongside existing complexity measures, found that most of the popular datasets pose rather easy classification tasks and are therefore unsuitable for properly evaluating learning-based matching algorithms; the authors built four harder tasks to replace them (Papadakis et al., 2023, arXiv:2307.01231). An IJCAI paper the year before had made a structurally similar argument, that the gap between reported and real-world matching performance comes from the benchmark construction process itself (Wang et al., 2022, Bridging the Gap between Reality and Ideality of Entity Matching, IJCAI).

timeline
  title From likelihood ratios to a practical ceiling
  1969 : Fellegi and Sunter formalise record linkage as a likelihood-ratio test
       : Two thresholds and a clerical review band in between
  2009 : Hassanzadeh et al. benchmark the clustering stage with the Stringer framework
  2016 : Magellan argues for whole systems rather than matchers in isolation
  2018 : DeepMatcher maps the deep-learning design space; wins on textual and dirty data only
  2020 : Ditto fine-tunes a PLM and beats DeepMatcher+ by 26.53 F1 on Abt-Buy
  2023 : WDC Products measures unseen-entity generalisation; a re-evaluation finds the classic datasets easy
  2025 : LLM matchers reach fine-tuned PLM quality with zero or few examples
  2026 : OpenSanctions Pairs hits 98.95 F1 and the authors redirect effort to blocking and clustering

[IMAGE: Timeline graphic pairing each year above with the artefact it produced: a hand-drawn agreement-pattern table for 1969, a Python notebook screenshot for 2016, a serialised record-pair string for 2020, a prompt template for 2025. Caption: "Each era changed the comparator, not the pipeline around it."]

How the Pipeline Actually Spends Its Accuracy

End-to-end recall is multiplicative across stages. Write \(PC\) for pair completeness, the fraction of true duplicate pairs that survive candidate generation, and \(R_m\) for the matcher's recall on the pairs it is given. Then the best recall the system can achieve is

That inequality is the whole argument. It says the two factors are symmetric in the arithmetic and asymmetric in the research literature, because one of them has twenty years of benchmarks and the other has a survey.

Candidate generation decides the ceiling

Entity resolution has quadratic time complexity because every record must in principle be compared with every other, which is why reducing the search space is a mandatory first stage rather than an optimisation (Papadakis et al., 2020, Blocking and Filtering Techniques for Entity Resolution: A Survey, ACM Computing Surveys 53(2)). Three families do the reducing, and they have genuinely different shapes.

Blocking groups records by a key derived from their attributes, then compares only within groups. The key is usually a concatenation of coarsened fields: a Soundex of the surname, the first three characters of a postcode, a year of birth. Multiple independent keys are run in parallel and their candidate sets unioned, because any single key fails on the field it depends on.

Similarity joins compute, exactly, all pairs within a string-distance threshold, using prefix and length filters to avoid materialising the full cross product. They give you a guarantee: nothing above the threshold is missed.

Nearest-neighbour search embeds every record as a vector and retrieves the \(k\) closest, which handles attribute-order variation and multilingual names in a way that character-level keys cannot. The first systematic comparison of all three families over ten real-world datasets found that the configuration parameters dominate performance to the point where cross-family comparison is non-trivial, which is a polite way of saying that published rankings of blocking methods mostly measure tuning effort (Papadakis et al., 2022, How to reduce the search space of Entity Resolution, arXiv:2202.12521).

The two metrics that matter are pair completeness, the recall of true matches retained, and reduction ratio, the fraction of the Cartesian product eliminated. They trade off directly, and the trade has a nasty property: reduction ratio is measurable exactly from the candidate set, while pair completeness requires labelled duplicate pairs you mostly do not have. Teams therefore optimise the metric they can see.

[IMAGE: Log-scale histogram of block sizes from a real blocking key, with a long thin tail and one isolated bar at 40,000 on the far right, the bar shaded red and annotated "96 percent of all candidate pairs". Caption: "The mean block size tells you nothing. The right tail is the whole cost."]

Pairwise matching, and why it ran out of room

Fellegi and Sunter's formulation is still the backbone of the probabilistic approach. For a comparison vector \(\gamma\) of per-field agreement outcomes, the score is the log likelihood ratio

where \(m_f\) is the probability that field \(f\) agrees given a true match and \(u_f\) the probability that it agrees by chance. The practical magic is that \(m_f\) and \(u_f\) can be estimated without labels by expectation maximisation over the comparison vectors themselves, treating match status as the latent variable. This is what makes probabilistic linkage deployable on data nobody has annotated, and it is exactly what Splink implements, building on FastLink's R implementation of EM for a Fellegi-Sunter model (UK Ministry of Justice, Splink).

The learned matchers replaced the hand-specified comparison vector with a representation learned from labelled pairs, which is why DeepMatcher's finding was that they win on dirty and textual data: those are precisely the cases where a fixed per-field comparison is the wrong abstraction, because the information has moved between fields. Pre-trained language models then removed the need for task-specific representation learning, and generative models removed most of the need for labels at all. On the OpenSanctions benchmark the error analysis is instructive: the rule-based system's failures are over-matching, while the LLM failures are concentrated in cross-script transliteration and small identifier or date inconsistencies. Those are not classifier problems. They are the residue.

[IMAGE: Horizontal bar chart of per-field log likelihood-ratio contributions for one record pair: surname agreement at plus 4.1, postcode agreement at plus 3.4, forename disagreement at minus 1.2, date of birth disagreement at minus 2.9, with a vertical line at the acceptance threshold and the running total annotated. Caption: "A Fellegi-Sunter score is an auditable sum. That is most of why it is still deployed."]

Clustering is where the pairwise guarantee dies

A matcher emits a graph: nodes are records, edges are pairwise decisions with scores. Entities are supposed to be the groups. Getting from one to the other requires an assumption the matcher never made.

Consider three records with pairwise scores \(s(A,B) = 0.95\), \(s(B,C) = 0.96\), \(s(A,C) = 0.08\). Every individual decision may be correct; A and C genuinely look nothing alike because they share no fields in common, and both happen to resemble B. Transitive closure merges all three. Rejecting the merge requires overruling two high-confidence positives. There is no answer that is locally consistent, which is why the clustering stage is a separate problem with its own algorithms, and why it was being benchmarked independently as early as 2009 with frameworks that evaluated unconstrained clustering algorithms specifically for duplicate detection (Hassanzadeh et al., 2009, Framework for Evaluating Clustering Algorithms in Duplicate Detection, PVLDB 2(1), 1282–1293).

The end-to-end surveys place clustering as its own pipeline stage after blocking, block processing and matching, and note that it can also infer indirect matches the matcher never scored (Christophides et al., 2021, An Overview of End-to-End Entity Resolution for Big Data, ACM Computing Surveys 53(6)). That inference is a feature when the transitive chain is real and a catastrophe when it is not.

The stage with no papers at all

Production entity resolution is incremental. Records arrive continuously, and the cluster assignment has to survive their arrival without renumbering every entity, because downstream systems hold the cluster identifiers as foreign keys. A new record can merge two existing clusters, which means retiring two identifiers in favour of one, and a correction can split a cluster, which means minting identifiers for records that already had one. Splink's deployment at the UK Ministry of Justice runs in both batch and real-time modes across courts, prisons and probation data, which is the part of the problem that no benchmark in this article measures.

Seeing It in Motion

The economically sensible architecture, once the matcher is this good and this expensive, is a cascade: a cheap model scores everything that survives blocking, and only the uncertain band is escalated.

sequenceDiagram
  participant Src as Source tables
  participant Blk as Blocking keys
  participant Fast as Cheap scorer, EM or PLM
  participant LLM as LLM matcher
  participant Clu as Clusterer
  Src->>Blk: 10M records
  Blk->>Fast: 835M candidate pairs
  Note over Blk,Fast: pair completeness measured on a labelled sample, not assumed
  Fast->>Clu: high-confidence matches and rejects
  Fast->>LLM: uncertain band only
  LLM->>Clu: adjudicated verdicts
  Clu->>Clu: close the match graph, cap component size
  Note over Clu: cluster-level metrics, not pairwise F1

The second diagram is the failure the cascade cannot fix, because it happens after every pairwise decision is already correct.

flowchart TB
  subgraph pairs["Pairwise verdicts, all defensible"]
    A1["Record A"] -->|"0.95 match"| B1["Record B"]
    B1 -->|"0.96 match"| C1["Record C"]
    A1 -.->|"0.08 non-match"| C1
  end
  subgraph closed["After transitive closure"]
    E["One entity: A, B, C"]
  end
  pairs --> closed
  closed --> W["Two real people merged; 0.99 pairwise precision unviolated"]
  classDef teal fill:#0e7490,stroke:#22d3ee,stroke-width:1px,color:#fff
  classDef rose fill:#be123c,stroke:#fb7185,stroke-width:1px,color:#fff
  classDef slate fill:#334155,stroke:#64748b,stroke-width:1px,color:#e2e8f0
  class A1,B1,C1 teal
  class E slate
  class W rose

[IMAGE: Two side-by-side graph drawings. Left: three nodes with two solid high-score edges and one dashed low-score edge. Right: the same three nodes inside a single shaded entity boundary. Caption: "Transitive closure converts two correct decisions into one wrong entity."]

Watch It Run

By the Numbers

Sources: OpenSanctions Pairs figures from Smith et al., 2026, arXiv:2603.11051. Abt-Buy figures from the arXiv v3 results table of Li et al., 2020; the headline "maximum F1 improvement" differs between versions of that paper (19, 29 and 31 percent appear in different versions), which is why the per-dataset row is quoted instead. WDC Products range from Peeters et al., 2024, arXiv:2301.09521; the seen-to-unseen drops are as restated in a follow-up benchmark paper rather than read from the original tables, so treat the magnitudes as indicative and the direction as solid. Splink figures are from the Ministry of Justice's own publications and an ADR UK blog post, which means they are developer-reported rather than independently benchmarked. The \(5.0 \times 10^{13}\) figure is arithmetic, not a measurement.

[IMAGE: Grouped bar chart of F1 on the OpenSanctions Pairs benchmark: rule-based regression model at 91.33, DeepSeek-R1-Distill-Qwen-14B at 98.23, GPT-4o at 98.95, with a dashed line at 100 and the gap between the two model bars annotated "0.72 points, at roughly 100x the cost per pair". Caption: "The accuracy argument is over. The cost argument is not."]

A Concrete Example

Deduplicate a 10-million-row customer table. Walk the arithmetic end to end.

Step 1: the pair count nobody evaluates. \(\binom{10^7}{2} = \frac{10^7 \times (10^7 - 1)}{2} = 4.99999950 \times 10^{13}\) pairs. At 100,000 pair evaluations per second, which is optimistic for a fine-tuned transformer on one GPU, that is \(5.0 \times 10^8\) seconds, or 15.8 years. This stage is not negotiable.

Step 2: block, and look at the block-size distribution rather than the mean. Key: first initial of the forename, Soundex of the surname, first three characters of the postcode. Suppose it produces 1,250,000 non-empty blocks averaging 8 records each. If blocks were uniform, pairs would be \(1{,}250{,}000 \times \binom{8}{2} = 3.5 \times 10^7\), a comfortable 35 million.

They are not uniform. Forty thousand rows have a missing postcode, so the key truncates and they all land in one block. That block alone contributes \(\binom{40{,}000}{2} = 799{,}980{,}000\) pairs, roughly \(8.0 \times 10^8\). The total is \(8.35 \times 10^8\) candidate pairs, of which 96 percent come from one degenerate block that is 23 times larger than the entire rest of the candidate graph combined. Every blocking implementation has a block-size cap for this reason, and the cap is a recall decision disguised as a performance setting.

Step 3: measure pair completeness instead of assuming it. Label 2,000 pairs by hand, stratified so that some are known duplicates found by other means. Suppose 96.2 percent of the true duplicate pairs appear somewhere in the candidate set. Reduction ratio is \(1 - \frac{8.35 \times 10^8}{5.0 \times 10^{13}} = 0.9999833\), a number that will look superb in any report. Pair completeness is 0.962, meaning 3.8 percent of the duplicates in this table are now unreachable by any downstream component.

Step 4: price the matcher against the blocker. Take the OpenSanctions numbers as a proxy: the rule engine at 91.3 and the LLM at 98.9. End-to-end recall is the product.

The matcher upgrade is worth 7.3 points, which is the larger single win, and it is available exactly once. After taking it, 4.9 points of recall are still missing, and 3.8 of those 4.9 are blocking. No further model improvement reaches them: a matcher with 100 percent recall on the pairs it sees would still land at 0.962.

Step 5: price the inference you just signed up for. Scoring all \(8.35 \times 10^8\) candidate pairs with a generative matcher, at roughly 300 input tokens per serialised pair, is \(2.5 \times 10^{11}\) input tokens. Multiply by whatever a million tokens costs on the day you read this and the answer is not a budget line, it is a reason the architecture has to be a cascade. A cheap scorer handles everything and forwards the uncertain band; if that band is 0.2 percent of candidates, the LLM sees 1.7 million pairs and \(5 \times 10^8\) tokens, roughly 500 times less.

Step 6: watch pairwise precision stop protecting you. Say the table holds roughly 650,000 true duplicate pairs and the cascade runs at 0.99 pairwise precision. That is about 6,600 false positive edges in the match graph. Each one, under transitive closure, merges two clusters that were individually correct. Most merges are small because most clusters are small, but the consequence of any single merge is unbounded: a false edge joining two 400-record corporate groups yields one 800-record entity, and no pairwise metric computed on the 835 million candidate pairs will register it. This is why cluster-level evaluation exists, and why a pipeline that reports only pairwise F1 is reporting on a stage rather than on a system.

Where It Breaks

Recall lost in blocking is invisible by construction

To know your pair completeness you need labelled duplicate pairs, and to find labelled duplicate pairs at scale you need a working entity resolution system. The circularity is real, and the usual escape is a stratified hand-labelled sample seeded from other evidence: shared account numbers, customer complaints about duplicate mailings, manual merges that support staff already performed. Teams that skip this step do not get a wrong pair completeness number; they get no number, and then they tune the matcher.

The benchmarks that built the field were too easy

This is worth sitting with, because almost every matcher comparison in circulation rests on the affected datasets. The re-evaluation that assessed 13 established datasets with four approaches, including new measures of linearity, concluded that most pose rather easy classification tasks (Papadakis et al., 2023). When a benchmark is close to linearly separable, the headline consequence is not that the reported scores are wrong; it is that the ranking between methods becomes noise, because everything above a certain capacity saturates.

Generalisation to unseen entities is the gap that remains

WDC Products exists because the standard benchmarks test a matcher on the same products it trained on. Measured properly, performance of all matchers drops significantly for unseen entities, and the authors report Top-F1 between 0.64 and 0.89 depending on the benchmark variant, which is a wide enough band that quoting a single number for a matcher is meaningless without naming the variant (Peeters et al., 2024). The LLM result that matters most here is not the headline F1 but the robustness claim: generative matchers degrade less on entities they have not seen, which is a different and more useful property than scoring higher on entities they have (Peeters, Steiner & Bizer, EDBT 2025).

[IMAGE: Slope chart with two columns, Seen and Unseen, and one line per matcher (R-SupCon, Ditto, RoBERTa), every line falling steeply to the right, with the drop in F1 points labelled at each line's end. Caption: "Every matcher falls on entities it has not met. The ranking at the left tells you little about the ranking at the right."]

Prompt sensitivity makes LLM matchers hard to operate

The EDBT study's blunt finding is that there is no single best prompt: the right one has to be tuned per model and per dataset. On the OpenSanctions benchmark, systematic prompt optimisation with DSPy gave consistent but modest gains, and in-context examples added little and sometimes hurt. A matcher whose accuracy depends on a prompt that has to be re-tuned when the model version changes is an operational liability in a way that a Fellegi-Sunter model with estimated \(m\) and \(u\) parameters is not, and that liability does not appear in any F1 table.

Transitivity is assumed by the pipeline and guaranteed by nothing

Covered in the worked example, and it deserves restating as a failure mode rather than an arithmetic curiosity: pairwise precision computed over candidate pairs places no bound on cluster-level error. Two defensible positives plus closure equals one wrong entity. Production systems manage this with component size caps, with "do not merge" rules derived from strong identifiers that must not disagree, and with human review triggered by component growth rather than by pairwise score. None of those are in the research pipeline.

Class imbalance makes the threshold the real model

In a 10-million-row table with 650,000 true duplicate pairs among 835 million candidates, the positive class is under 0.1 percent of what the matcher sees. At that ratio, a shift in threshold that moves recall by one point moves the absolute false-positive count by thousands, and F1 on a balanced benchmark set says nothing about where to put the threshold on a production distribution. The threshold has to be calibrated on the real prior, which means a labelled sample from the real candidate set rather than from a benchmark.

Measuring the stage is not measuring the system

Pairwise F1 on a curated pair set is a clean, reproducible, comparable metric, and it is the reason the field made rapid progress on the matcher. It also cannot see blocking recall, cluster-level error, incremental stability or operating cost. A system that reports 98.9 F1 and merges two real people once a week is both of those things at the same time, and only one of them is on the dashboard.

Alternative Designs

The cascade is not a compromise between the other rows; it is what the OpenSanctions authors are pointing at when they say the remaining work is uncertainty-aware review. Fellegi and Sunter's clerical review band was the same idea with a person in the escalation slot instead of a model.

How It Is Used in Practice

Splink is the clearest public example of probabilistic linkage at national scale. It was built at the UK Ministry of Justice because the existing packages did not work at the volumes government linkage requires, stated as tens to hundreds of millions of records, and it implements a Fellegi-Sunter model with EM parameter estimation over Spark, DuckDB and similar backends. It now links people across courts, prisons and probation data in both batch and real-time deployments, and has been downloaded over three million times. That deployment is interesting precisely because the matcher is the 1969 model: the engineering went into blocking, scale, and the review workflow.

OpenSanctions is the other end of the spectrum. Its production system is the rule-based nomenklatura regression model at 91.33 F1, operating over 293 heterogeneous sources with multilingual names and set-valued fields, which is the hardest realistic input shape for a rule engine. The 2026 benchmark exists because the maintainers wanted to know what a model upgrade would buy, and the honest answer they published was: a lot on the pairs, and the next bottleneck is elsewhere.

In commercial customer data platforms the pattern is almost always the cascade, for the reason the token arithmetic gives, with an added constraint the research literature rarely models: cluster identifiers are foreign keys in other systems, so the pipeline is judged on identifier stability as much as on accuracy. A rebuild that improves F1 by two points and renumbers 4 percent of entities is, for most operators, a regression.

[IMAGE: Three-panel architecture comparison. Panel 1: Splink at MoJ, labelled "1969 matcher, 2020s blocking and scale". Panel 2: OpenSanctions, labelled "rule engine in production, LLM measured". Panel 3: a commercial CDP cascade, labelled "cheap scorer plus escalation, identifier stability as a constraint". Caption: "Three deployments, three different answers to the same arithmetic."]

Insights Worth Remembering

1. End-to-end recall is a product, and only one factor has a leaderboard. \(R_{\text{system}} \le PC \cdot R_m\). Twenty years of benchmarks improved \(R_m\). Most production deficits live in \(PC\), which is measured by nobody because measuring it requires the labels the system was supposed to produce.

2. Reduction ratio is the metric you can see; pair completeness is the metric that matters. A candidate set that eliminates 99.998 percent of the Cartesian product looks like an unqualified success and is perfectly compatible with silently discarding 4 percent of the duplicates in the table.

3. Block-size distributions, not averages, determine cost. One degenerate block built from a missing field can contribute 95 percent of the candidate pairs. The block-size cap that fixes it is a recall decision wearing a performance setting's clothes.

4. The matcher upgrade is a one-time dividend. Moving from a rule engine to a near-ceiling model is worth several points of recall exactly once. After that, the remaining loss is dominated by the stage that was never upgraded.

5. Pairwise precision places no bound on cluster-level error. Transitive closure converts a handful of defensible false positives into merged entities whose size is unbounded. Any entity resolution report that quotes only pairwise F1 is describing a component, not a system.

6. LLM matchers are priced out of candidate generation, not out of matching. \(8.35 \times 10^8\) pairs at 300 tokens each is \(2.5 \times 10^{11}\) tokens. The cascade is not an optimisation; it is the only arrangement in which a generative matcher is affordable at all.

7. Robustness to unseen entities is the result worth quoting from the LLM literature, more than the F1. A matcher that holds up on products, people and companies absent from its training data removes the per-domain labelling project, and that is a larger operational change than two points of accuracy.

8. Identifier stability is a first-class requirement that no benchmark measures. Downstream systems hold cluster identifiers as foreign keys, so a rebuild that improves accuracy while renumbering entities is experienced as an outage.

Open Questions

Can pair completeness be estimated without labels? No established method does this reliably. Capture-recapture estimators over two independent blocking schemes are the promising direction in principle, since the overlap between two candidate sets carries information about what both missed, but validated estimators for entity resolution specifically are not something this article can point to. This is the highest-value open problem in the pipeline.

Where should the uncertainty band's boundaries go? The cascade's cost and its accuracy both depend on the band width, and the band is currently set by hand. The principled answer is a calibrated cheap scorer plus a decision-theoretic threshold weighing expected escalation cost against expected error cost, which is easy to write down and, as far as published work shows, standard practice nowhere.

Does the pairwise ceiling hold on harder data? The 98.95 F1 result is measured on one benchmark, one domain, one labelling process, and the authors' own error analysis says the residue is transliteration and identifier inconsistencies. Whether the ceiling is a property of matching or of that benchmark is unestablished, and the previous generation of benchmarks turning out to be easy is a reason for caution.

What is the right cluster-level metric? Pairwise F1, cluster-level F1 and the partition-comparison measures disagree about which errors are serious, and the choice determines what a pipeline optimises. Clustering has been evaluated independently since at least 2009, yet no measure became the default the way pairwise F1 did for matching.

How should incremental resolution handle a split? Merging two clusters when new evidence arrives is mechanically easy and semantically contained. Splitting one, after downstream systems have persisted the identifier, has no clean answer, and the literature treats the incremental case far more thinly than the batch case even though production systems are almost all incremental.

Sources and Further Reading

1. Fellegi, I. P., & Sunter, A. B. (1969). "A Theory for Record Linkage." Journal of the American Statistical Association, 64(328), 1183–1210. DOI: 10.2307/2286061
2. Smith, Sesodia, Lindenberg & de Witt (2026). "OpenSanctions Pairs: Large-Scale Entity Matching with LLMs." arXiv:2603.11051
3. Li, Y., Li, J., Suhara, Y., Doan, A., & Tan, W.-C. (2020). "Deep Entity Matching with Pre-Trained Language Models." PVLDB. arXiv:2004.00584
4. Mudgal, S., et al. (2018). "Deep Learning for Entity Matching: A Design Space Exploration." SIGMOD. Technical report PDF
5. Konda, P., et al. (2016). "Magellan: Toward Building Entity Matching Management Systems." PVLDB, 9(13), 1581–1584. PDF
6. Papadakis, G., Kirielle, N., Christen, P., & Palpanas, T. (2023). "A Critical Re-evaluation of Benchmark Datasets for (Deep) Learning-Based Matching Algorithms." arXiv:2307.01231
7. Peeters, R., Der, R. C., & Bizer, C. (2024). "WDC Products: A Multi-Dimensional Entity Matching Benchmark." EDBT. arXiv:2301.09521
8. Peeters, R., Steiner, A., & Bizer, C. (2025). "Entity Matching using Large Language Models." EDBT 2025, 529–541. arXiv:2310.11244
9. Steiner, A., Peeters, R., & Bizer, C. (2024). "Fine-tuning Large Language Models for Entity Matching." arXiv:2409.08185
10. Papadakis, G., Skoutas, D., Thanos, E., & Palpanas, T. (2020). "Blocking and Filtering Techniques for Entity Resolution: A Survey." ACM Computing Surveys, 53(2). DOI: 10.1145/3377455
11. Papadakis, G., et al. (2022). "How to reduce the search space of Entity Resolution: with Blocking or Nearest Neighbor search?" arXiv:2202.12521
12. Christophides, V., Efthymiou, V., Palpanas, T., Papadakis, G., & Stefanidis, K. (2021). "An Overview of End-to-End Entity Resolution for Big Data." ACM Computing Surveys, 53(6). DOI: 10.1145/3418896
13. Hassanzadeh, O., Chiang, F., Miller, R. J., & Lee, H. C. (2009). "Framework for Evaluating Clustering Algorithms in Duplicate Detection." PVLDB, 2(1), 1282–1293. DOI: 10.14778/1687627.1687771
14. Wang, T., Lin, H., et al. (2022). "Bridging the Gap between Reality and Ideality of Entity Matching: A Revisiting and Benchmark Re-Construction." IJCAI. arXiv:2205.05889
15. UK Ministry of Justice. "Splink: MoJ's open source library for probabilistic record linkage at scale." GOV.UK
16. ADR UK. "Splink: Free software for probabilistic record linkage at scale." adruk.org

Free to read, no ads, no sign-up. If it was useful you can buy me a coffee.