Every Generation Moved the Work: Sixty-Seven Years of Machines on Master Data

Weaving Intelligence (House AI Style), with Jeff Shabel’s Experiential Commentary

I have never seen a business finish the job of systematizing its data, and I have said, flatly, that AI will go the same way. This piece holds that prediction up against the longest record available for testing it, which is not the last three years of language models. Machines have been pointed at master data, the governed records of customers, products, suppliers and locations that every other system quietly disagrees about, since 1959.

Asked once for a case where somebody had genuinely solved it, I said I had never seen one, and went on:

Systematizing something merely identifies a problem further up or down the chain. Systematize the delivery and ingestion and it surfaces that the groups downstream of it have their own problems; build the reporting layer on top and you discover the data underneath it was never as sound as everyone assumed. It is layers all the way down, and people spend entire careers at the same company peeling back the onion only to retire and hand the process to their replacement. It is the nature of the beast and inherent to the environment of business. The whole turn to outsourcing infrastructure is another example of systemization exposing that what was systematized was never really the problem. AI is going to do the same thing.

That last sentence was a forecast when I said it, and a forecast about a technology is cheap. A forecast about a technology with a sixty-seven-year track record on this exact problem can be checked, and the check is what follows. My claim, stated so it can fail: each generation of machine help on master data made the job it was aimed at cheaper, sometimes spectacularly so, and in doing that it handed a new layer of work to a person. None of them retired the person. If the record shows a generation that did, I am wrong, and the budget advice at the end of this piece is wrong with me.

Two honest limits first. I have not yet run governed language-model enrichment on a master-data foundation; standing one up is a different piece of work from having run one. And I have argued before that whatever circulates as accepted wisdom about AI in master data is a set of heuristics, useful in general at most four times in five, to be tested against the situation in front of you before anyone applies them with vigour. Both hold. What the record below adds is something to test those heuristics against: the platforms are young, and the problem is not. A body of tested experience exists. It was filed under record linkage, entity resolution and data curation, by statisticians and database researchers, long before a vendor put the word AI on a matching screen.

Before anyone called it AI

The first machine pointed at master data was a statistician's. In 1959 Howard Newcombe and three colleagues published "Automatic linkage of vital records" in Science [1]. A decade later Fellegi and Sunter, in William Winkler's account for the U.S. Census Bureau, "provided a formal mathematical model for ideas that had been introduced by Newcombe" [2]: a decision rule with two cutoffs and a band in the middle held for a clerk [2], the rule at the centre of an earlier piece on what an AI business case can check. What matters for a retrospective is what that rule did to the work in practice.

Winkler gives the number, and it is the oldest cost figure I know of for machine help on this problem. For the 1990 Decennial Census, "the computerized procedures were able to reduce the need for clerks and field follow-up from an estimated 3000 individuals over 3 months to 200 individuals over 6 weeks" [2]. Read it twice. The machine cut the clerical workload by something over ninety-five percent in person-weeks. And it left two hundred people.

Those two hundred were not a rounding error. They were the band in the middle: the pairs the weights could not call. The same overview is candid about what the next generation would need from them. When the parameters are estimated from labelled examples, "the labeled training data can be a very small proportion of the pairs," and "typically, the sampled set of labeled pairs is concentrated in the clerical review region" [2]. The people the machine could not replace were the source of the labels the next machine would learn from.

Nor did the first machine compare everything with everything. "In a substantial number of situations, the files are too big to consider every pair in the cross product space of all pairs from two files" [2]. For the 2000 Census, with 300 million records, Winkler reports that 99.5% of the true matches could be found within a subset of 10^12 pairs [2], a vast number that is still a tiny fraction of every possible pairing. So even the first generation needed a cheap, deterministic step in front of the clever one, deciding which pairs were worth the clever one's time. A recent survey of the field puts it in a sentence: "Efficiency techniques are an integral part of Entity Resolution, since its infancy" [3]. Hold on to that. It comes back in the language-model generation wearing a price tag.

The census figure also says something about what kind of work was being automated. The clerks were not being asked to do anything a clever human could not do. They were being asked to do something a patient human could do, three thousand times over. Asked whether work of this kind needs the most advanced model available, my answer was:

In a lot of cases the objective is not to get the AI to do something difficult, but something repetitive and time-consuming. That generally does not require an advanced, late-generation model or a large token budget — it requires basic domain competence, which can be engineered into the prompt.

The census programme is the oldest evidence I know for that answer and it cuts in its favour. The machine never did the hard part. It did the repetitive part at a scale no staff could, and the hard part stayed with the two hundred. I would add one refinement the history supplies. The domain competence in 1990 was not in a prompt; it was in the parameters, estimated from the files and from labelled pairs. Where the competence lives changes with each generation. That it has to be put somewhere by someone does not.

Learning the match, and paying for the labels

The next generation tried to take the hand-tuning out. At the turn of the millennium the research community stopped setting similarity by hand and started learning it. Bilenko and Mooney's MARLIN, presented at KDD in 2003, learned a separate text-distance function for each field and showed "that such measures are capable of adapting to the specific notion of similarity that is appropriate for the field's domain" [4]. The domain knowledge a clerk carried in their head was now to be learned from examples.

Examples were the new bill. Sarawagi and Bhamidipaty, a year earlier, said plainly that the success of a learned deduplication function "critically hinges on being able to provide a covering and challenging set of training pairs," and then showed how to cut the cost: after labelling "less than 100 pairs selected interactively by our system, the learnt deduplication function can achieve the peak accuracy which a randomly chosen set of pairs cannot achieve even with 7000 pairs" [5]. That is a seventy-fold saving on labels, and it is a saving on a line the previous generation did not have. The work had moved from tuning weights to choosing which pairs a person should look at.

The same years saw the first serious attempt to classify product master data by machine. GoldenBullet, presented in 2002, classified product descriptions against the UNSPSC commodity code standard. Its best trained classifier put the right code first 78% of the time and somewhere in its top ten 88% of the time; using the code hierarchy cut that to at most 38% and 42%, and untrained it managed next to nothing [6]. Its design is the part a retrospective should keep: the system proposed a ranked list, and "the end user can pull down the proposed list and make the final choice" [6]. Twenty-four years ago the classifier was built as an assistant with a person holding the last decision, and nobody involved seems to have thought that a weakness.

Then somebody measured. In 2010 Köpcke, Thor and Rahm ran the first head-to-head evaluation of entity-resolution systems, research and commercial, on real match tasks [7]. On bibliographic data, most approaches cleared 91% F-measure, which is the harmonic mean of precision and recall. On product data from online shops, "no approach could achieve an F-measure of more than 62% (AmazonGoogleProducts) or 70% (Abt-Buy)" [7]. Learning helped where there were several attributes to combine and hurt where there was one [7]. And the training bill depended on the data: twenty labelled pairs gave stable results on the easy bibliographic task, while on the e-commerce tasks every approach struggled with fewer than five hundred, the most they tested, and even there no approach passed 62% and 70% [7]. Their abstract concluded that matching product entities was "not sufficiently solved" [7].

That result is the one I would pin to the wall of any project team pointing a model at product data today. The hard domain in 2010 was the product master, the messy one full of manufacturer codes and inconsistent descriptions, and it is still the hard domain; a language-model paper below falls down on the same dataset. The learned generation made similarity cheaper to tune and handed on two things: a labelling queue, and a class of data it did not crack.

My own answer to what a model buys you has long been the data scientist's, which is lift over what you had, and my approach has been to start with the smallest thing that works and stop scaling when the gain flattens. The 2010 evaluation is a reminder of the other half of that answer. Lift is measured against the data you measured it on. On clean bibliographic records there was little room for lift, because most approaches already cleared 91%; on product records the lift was real and the result was still not good enough to run unattended. I have made the same point more rudely about training models on raw data: you can measure an improvement on sewage, and it is still sewage. Clean what can be cleaned cheaply first, and point the learning at what is left.

Platforms, stewards and curation at scale

By the early 2010s the research had reached the products, and Microsoft's Data Quality Services, which I have counted among the products that arrived before the discipline had a name, is the clearest case, because its own documentation says where it put the person.

A disclosure before I assess anyone's product, including which way each interest points. The practice behind this publication is a Profisee partner and holds a referral agreement with Profisee. Clients pay us for deployment work, a licence sale we refer earns us a referral fee, and our services revenue depends on this category of software being bought at all. That last interest runs toward praise of the category, so weigh anything favourable I say about machine help on master data below my criticism of it. Tamr, and the Data Tamer research behind it, competes with Profisee, which gives me a reason to be hard on it; discount my criticism of it accordingly. Microsoft's Data Quality Services pulls both ways. It competes with Profisee's product, which gives me a reason to be hard on it, and it comes from a vendor Profisee is aligned with, since Profisee markets itself as a native workload in Microsoft's Fabric platform, which gives me a reason to go easy on it. Weigh both my criticism of it and anything favourable I say about it with that in mind.

Microsoft describes it as "a knowledge-driven data quality product" that builds a knowledge base for "correction, enrichment, standardization, and de-duplication" [8]. Its matching policy weights each field's contribution to a match score, the documentation says, and then: "only those records with a probability of a match greater than a value set by the data steward in the matching policy will be considered a match" [9]. After the machine clusters the candidates, "the data steward verifies the matching results, and rejects any record that is not an appropriate match for a cluster," and then chooses the survivorship rule that decides which record survives [9]. The threshold, the verification and the survivorship decision are all written into the product as the steward's. The product is now being retired: Data Quality Services "is removed in SQL Server 2025" [8]. The division of labour it wrote down is not.

That threshold is where I would put the most weight in any history of this subject, because it is where the history's savings are most easily given back. My position on it has not changed: an auto-approve cutoff set low to make an automation figure look good buys the stewards more work, not less, because they end up remapping false matches after the business has already made decisions and issued reports on them. I have one worked example from a customer, and the shape of it is the point. Restoring the master record after a bad merge took minutes. Reloading the downstream warehouse took hours, regenerating the reports took more hours, and revalidating the decisions and presentations built on them took more again, and none of that clock started until somebody noticed. Being right eighty percent of the time out of the gate still leaves a fifth of the answers wrong, and when the wrong fifth is over-matched records, the bill tends to arrive at the first quarterly reconciliation, when somebody has to justify the over-allocations.

Two research systems from the same years put the person into the design deliberately rather than leaving them there by default. CrowdER, published at VLDB in 2012, started from the observation that algorithmic approaches "have been improving in quality, but remain far from perfect," and proposed "a hybrid human-machine approach in which machines are used to do an initial, coarse pass over all the data, and people are used to verify only the most likely matching pairs" [10]. It reported better quality than either the similarity-based or the learning-based approaches alone on product data, at substantially lower cost than having people verify everything [10].

Data Tamer, presented at CIDR in 2013 by Stonebraker and colleagues, became a company the same year: Stonebraker and a co-founder formed Tamr "to extend, robustize, and commercialize the Data Tamer system" [12]. It used machine learning for attribute identification, transformation and deduplication, and when necessary, "a human can be asked for guidance"; the humans were domain experts organised to answer the system's questions [11]. Its reported results are the strongest in this history. Across three enterprise deployments it claimed to "lower curation cost by about 90%, relative to the currently deployed production software," and at one web aggregator it reported 100% precision and 98.9% recall on duplicate detection against the incumbent system's 97% precision and 4% recall [11]. Those are the authors' own figures on their own deployments and I read them that way. Even taken at face value, the design did not retire the expert. It made the expert's time something the system requested, routed and rationed, which is a new layer of work: somebody has to decide which questions are worth an expert's answer.

Deep matchers, and where the gain actually landed

The deep-learning generation arrived with a careful paper rather than a product. Mudgal and colleagues, at SIGMOD in 2018, explored the design space of deep-learning entity matchers and reported the result that the hype of the time mostly left out: deep learning "does not outperform current solutions on structured EM, but it can significantly outperform them on textual and dirty EM" [13]. On structured instances, their best models were "competitive with Magellan," the non-deep system they compared against, at 87.9% against 88.8% average F1, while taking far longer to train; on textual data they gained 3.0 to 22.0 points of F1, and on dirty data 6.2 to 32.6 [13].

Ditto, published at VLDB in 2021, took pre-trained Transformer language models and cast matching as classifying a pair of sequences [14]. It reported gains of up to 29% in F1 over the previous state of the art on benchmarks, reached the previous best results with at most half the labelled data, and scored 96.5% F1 on a real company-matching task with 789,000 and 412,000 records [14]. The label bill fell again. It did not fall to zero, and the first of its optimizations, injecting domain knowledge into the input, says where the work had moved.

The lesson I take from this generation is about aim rather than capability. The expensive model paid for itself on the free-text and dirty columns and bought almost nothing on the clean, structured ones, which is where many of a master data hub's matching keys live. That makes the deterministic step in front of the model more important, not less. The question I would add to any committee reviewing a proposal to put AI on master data is exactly that one: what algorithm decides whether a record goes to the model at all, and if the answer is all of them, whether anybody considered pre-sorting or caching. The census answered it with blocking because pairwise comparison did not scale. The deep-learning papers answered it with evidence that the gain sat in one class of data. The language-model generation has to answer it again because every comparison now has a price.

Language models, and the layer that shrank

Here the record argues back, and it deserves a straight hearing. In 2022 Narayan, Chami, Orr, Arora and Ré asked whether foundation models could "wrangle your data," cast five cleaning and integration tasks as prompts, and found that "large FMs generalize and achieve SoTA performance on data cleaning and integration tasks, even though they are not trained for these data tasks" [15]. Peeters, Steiner and Bizer, in work published at EDBT in 2025, found that "the best LLMs require no or only a few training examples to perform comparably to PLMs that were fine-tuned using thousands of examples," and that they hold up better on entities they have not seen [16].

That is a layer genuinely shrinking. For twenty years the recurring bill in this history was labelled pairs: Winkler's clerical-review sample, Sarawagi's hundred, the five hundred Köpcke tested, Ditto's half. A model that matches competitively with few or none of them has taken a real line off the budget, and I concede it without a qualifier. If my claim were that every generation leaves every earlier layer in place, this would sink it. The claim is narrower than that, and it still rules something out: a generation can remove an earlier layer, but it has not yet removed the person at the band where the machine cannot decide, and it hands on a layer of its own. The same two papers say what that layer is.

The training labels shrank; the context did not arrive with them. Narayan and colleagues name "operating over highly specialized domains (e.g., medical, financial, and insurance data)" as a key challenge, and report that on the Amazon-Google product task the model "has difficulty matching samples due to the high volume of product-specific identifiers," scoring 63.5 F1 with ten examples against Ditto's 75.58 [15]. That is the dataset Köpcke's evaluation could not get past 62% on in 2010. Peeters and colleagues found that "the prompt needs to be tuned for each model/dataset combination" [16]; the tuning is labour, and it is redone when the model changes. And Narayan's group name the constraint the earlier generations never had: "organizations are often unable to pass sensitive data to third party APIs for privacy reasons" [15].

I put the context point in its bluntest form in the earlier business-case piece, with a set of car makes filed among the trees: a model knows only what it was handed, and it will classify a Buick as a larch if the only context it has is a column of larches. My position then was that this is the fault of whoever set the model up rather than of the model, and the history strengthens it. Every generation above needed somebody to supply the domain, in weights, in labelled pairs, in injected knowledge, and now in prompts; the language model is simply the first one fluent enough to hide that it was never given any.

The evaluation labels did not shrink either. A few examples may be enough to prompt a model; they are not enough to know whether it is right on your estate. The labelled set you score a matcher against, drawn from your own edge cases, is still owed, and it is still built by a person.

And the new layer has a meter on it. Every comparison sent to a hosted model is a charge, set by a vendor, on a model the vendor retires on its own schedule. I made the argument about that dependency and the replacement claim that comes with it in the roadmap piece. What the history adds is that the replacement claim is not new. The 2013 Data Tamer paper asked a human for guidance "when necessary" [11]; the company that commercialized it now advertises "LLM-based AI agents" to "clean, curate, manage, and refine complex edge cases with minimal human intervention" [17]. The promise to take the person out of the middle band is not new either, and my answer to its current form is the one I gave there: it may be true if the budget is unlimited, and no budget is.

Set side by side, the five generations, with the 2010 measurement as a checkpoint between them, read as one ledger.

What my own record adds

Everything above is what the literature and the vendors' own documents show; what follows is what I have seen in the work, offered as pattern rather than law.

The first pattern is older than any of these generations. Asked who deserves the credit when a model helps deliver something, I ended my answer on this:

The biggest problem nowadays is the one that has always been present: Golden Hammer Syndrome — or today, Golden Model Syndrome. Once you get past the idea that AI is not a panacea, there is hope.

The history says the same thing with numbers attached. The learned matchers helped when there were several attributes to combine and made things worse on a single attribute [7]; the deep matchers bought almost nothing on clean structured data [13]; the language models stumble on exactly the product identifiers that defeated everything before them [15]. In each case the tool was excellent at one class of problem, and the temptation, then as now, was to treat it as the answer to the whole category. The hammer is not the fault. Picking it up for every job is.

I would push my own sentence one step. There is hope once people accept that AI is not a cure-all, but acceptance is not a control. The census did not stay honest because its statisticians were humble; it stayed honest because two hundred people were on the payroll to look at the pairs the weights could not call, and the budget said so. The product that wrote the steward's threshold into its matching policy did not rely on anyone remembering to be careful; the threshold was a field that had to be filled in. Asked what I would build in from the first day because the system is AI, my answer was:

Logic gates that are enforced rather than suggestions. AIs are programmed and trained to want to get to the end and solve the problem as quickly as possible — so they will lie, cheat and steal to get there without spending a second processor cycle considering. To fight that, the industry has coalesced around the need to add, and enforce, that being right by following the specified and gated process is the only viable means to achieve it. Adding test gates that must be passed as intermediaries along the way acts as guard rails, keeping the AI from hallucinating or otherwise cheating to answer the question. A gate that isn't enforced is a suggestion, not a limit.

I would make one thing explicit that the answer takes for granted. The model is not being dishonest; there is no intent in it to police. It is optimizing toward whatever it was asked for by the shortest route the objective allows, which is exactly what a probabilistic matcher did with a threshold set too low and what a learned matcher did with a training set that did not cover the hard cases. The gate works because it changes what the shortcut earns. That is also why the history's gates look the way they do: a cutoff with a number in it, a review band with people assigned to it, a steward's rejection written into the tool. None of them were suggestions, and the ones that became suggestions, the auto-approve figure lowered to meet a target, are where the bills in this piece came from.

The second pattern is the one I opened with. Every generation in this record was a systematization of the layer before it, and every one of them exposed the next layer. Probabilistic weights exposed the review band and the need to block. Learning exposed the labelling queue, and the 2010 measurement showed the product data it could not crack. Platforms and curation at scale exposed the steward's threshold, the rework when it was set to flatter a dashboard, and expert time as something to be scheduled. Deep models exposed that the gain lived in one kind of data and that something cheap had to decide which records reached them. Language models have shrunk the labels and exposed the context, the tuning, the privacy boundary and the meter. That is not a history of failure. The census clerks went from three thousand to two hundred. Data curation costs fell by as much as nine-tenths in one set of deployments. It is a history of each saving being real and each new layer being left off the budget of the project that created it.

What to budget for, from sixty-seven years of it

If the record is right, the question to ask of the next proposal is not whether the model is good. Every generation here was good at what it was aimed at. The question is which layer this model will expose, and who is paying for it. From the history, I would put five lines in front of any plan to point a language model at master data.

The pre-sort. A cheap, deterministic step that decides which records reach the model, because the model's cost is per call and many of your matching keys are structured data the model will not improve on. Blocking has been in this work since the census [2][3]; it is now a cost control as well as a compute control.

The middle band, staffed. Two thresholds and a person in between, with the upper one set from the false-match rate the business will accept rather than from an automation target, and the downstream clock of a bad merge priced in, because it starts only when someone notices.

An evaluation set of your own. Fewer training labels does not mean fewer evaluation labels. The set that tells you whether the matcher is right on your estate is built by a person from your hardest records, and every new model is scored against it again.

The context, written down. Whatever the domain competence is, weights, rules, a knowledge base or a prompt, it is an artifact somebody owns, versions and re-tests when the model changes. The product master is where it will be tested hardest; it has been the hardest class of data in every generation since 2010 [7][15].

Gates that cannot be waived. A threshold is a field, not a guideline. A review step is a queue with names on it. A test that must pass before a change reaches the hub either blocks the change or it is decoration.

None of this argues against pointing a language model at master data. The labels it saves are real, and it reads text the earlier generations could not. It argues against believing that this generation, alone among five, will make its savings without handing on a layer. What I said AI would do, it is doing. The record says that is what progress in this trade has always looked like, and that the projects which come out ahead are the ones that budgeted for the next layer before it arrived.

References

[1] H. B. Newcombe, J. M. Kennedy, S. J. Axford and A. P. James, "Automatic linkage of vital records," Science 130, no. 3381 (1959): 954–959, doi:10.1126/science.130.3381.954. Cited for the date and the fact of publication only. The paper was not read: the PubMed record (PMID 14426783, read September 27, 2026) carries no abstract, and the article is behind the publisher's paywall. What the text says about its contribution is taken from Winkler [2]. https://pubmed.ncbi.nlm.nih.gov/14426783/

[2] William E. Winkler, Overview of Record Linkage and Current Research Directions, Research Report Series, Statistics #2006-2 (U.S. Census Bureau, Statistical Research Division, February 8, 2006) — "Fellegi and Sunter (1969) provided a formal mathematical model for ideas that had been introduced by Newcombe (1959, 1962, see also 1988)"; on a very large 1990 Decennial Census application, "the computerized procedures were able to reduce the need for clerks and field follow-up from an estimated 3000 individuals over 3 months to 200 individuals over 6 weeks"; "The labeled training data can be a very small proportion of the pairs ... Typically, the sampled set of labeled pairs is concentrated in the clerical review region"; "the files are too big to consider every pair in the cross product space of all pairs from two files"; on the 2000 Census, 300 million records, "99.5% of the true matches can be located in a subset of 10^12 pairs." Read through a rendering fetch that returns extracts, September 27, 2026; not read cover to cover. https://www.census.gov/content/dam/Census/library/working-papers/2006/adrm/rrs2006-02.pdf

[3] George Papadakis, Dimitrios Skoutas, Emmanouil Thanos and Themis Palpanas, "Blocking and Filtering Techniques for Entity Resolution: A Survey," arXiv:1905.06167 (submitted May 15, 2019; revised August 21, 2020; published in ACM Computing Surveys 53, no. 2, 2020) — abstract: "Efficiency techniques are an integral part of Entity Resolution, since its infancy." Abstract read at source September 27, 2026; the survey body was not read. https://arxiv.org/abs/1905.06167

[4] Mikhail Bilenko and Raymond J. Mooney, "Adaptive Duplicate Detection Using Learnable String Similarity Measures," Proceedings of the Ninth ACM SIGKDD International Conference on Knowledge Discovery and Data Mining (KDD-2003) — abstract: learnable text distance functions for each database field, "capable of adapting to the specific notion of similarity that is appropriate for the field's domain." Abstract read at source September 27, 2026. https://www.cs.utexas.edu/~ml/papers/marlin-kdd-03.pdf

[5] Sunita Sarawagi and Anuradha Bhamidipaty, "Interactive Deduplication using Active Learning," Proceedings of SIGKDD '02 (Edmonton, 2002) — "The success of this method critically hinges on being able to provide a covering and challenging set of training pairs"; "After labeling less than 100 pairs selected interactively by our system, the learnt deduplication function can achieve the peak accuracy which a randomly chosen set of pairs cannot achieve even with 7000 pairs." Abstract read through a rendering fetch, September 27, 2026. https://www.cse.iitb.ac.in/~sunita/papers/kdd02.pdf

[6] Y. Ding, M. Korotkiy, B. Omelayenko, V. Kartseva, V. Zykov, M. Klein, E. Schulten and D. Fensel, "GoldenBullet: Automated Classification of Product Data in E-commerce," Proceedings of BIS 2002 (Poznan, 2002) — classification against UNSPSC; Tables 2 and 3: the best trained non-hierarchical classifier (NBI) 78% total accuracy and 88% "First 10 Accuracy", the other trained non-hierarchical methods 28%–60% total; hierarchical classification at most 38% total and 42% first-ten; untrained, "the accuracy is extremely low and reaches maximally 0,2%"; "The end user can pull down the proposed list and make the final choice." Read through a rendering fetch that returns extracts, September 27, 2026. https://yingding.ischool.utexas.edu/Publication/goldenbullet.bis2002.pdf

[7] Hanna Köpcke, Andreas Thor and Erhard Rahm, "Evaluation of entity resolution approaches on real-world match problems," Proceedings of the VLDB Endowment 3, no. 1 (2010): 484–493 — abstract: there had "not yet been a comparative evaluation"; product matching "not sufficiently solved with conventional approaches based on the similarity of attribute values"; results: "no approach could achieve an F-measure of more than 62% (AmazonGoogleProducts) or 70% (Abt-Buy)", DBLP-ACM above 91% for most approaches; SVM-based learning "outperformed the non-learning approaches for the combined usage of several matchers on more than one attribute" but was "inferior" with a single matcher on one attribute; stable results with "20 labeled entity pairs" on DBLP-ACM; "The labeling effort varies between 20 and 500 entity pairs"; "All approaches have substantial difficulties with the e-commerce match tasks, especially for training sizes smaller than 500 entity pairs." Camera-ready copy read through a rendering fetch that returns extracts, September 27, 2026. https://dbs.uni-leipzig.de/files/research/publications/2010-9/pdf/EvaluationOfEntityResolutionApproaches_vldb2010_CameraReady.pdf

[8] Microsoft, Data Quality Services (SQL Server documentation) — "SQL Server Data Quality Services (DQS) is a knowledge-driven data quality product," used for "correction, enrichment, standardization, and de-duplication"; "Data Quality Services (DQS) is removed in SQL Server 2025 (17.x)." Cited for what the product was designed to do, not as a recommendation. Read at source September 27, 2026. https://learn.microsoft.com/en-us/sql/data-quality-services/data-quality-services

[9] Microsoft, Data Matching (Data Quality Services documentation) — a matching policy specifies "the weight that each domain value carries in the matching assessment"; "Only those records with a probability of a match greater than a value set by the data steward in the matching policy will be considered a match"; "The data steward verifies the matching results, and rejects any record that is not an appropriate match for a cluster. The data steward then selects a survivorship rule." Read at source September 27, 2026. https://learn.microsoft.com/en-us/sql/data-quality-services/data-matching

[10] Jiannan Wang, Tim Kraska, Michael J. Franklin and Jianhua Feng, "CrowdER: Crowdsourcing Entity Resolution," Proceedings of the VLDB Endowment 5, no. 11 (2012) — algorithmic approaches "have been improving in quality, but remain far from perfect"; "a hybrid human-machine approach in which machines are used to do an initial, coarse pass over all the data, and people are used to verify only the most likely matching pairs"; reports better quality than similarity-based and SVM-based techniques on product data at lower crowdsourcing cost than human-only verification. Abstract and results read through a rendering fetch, September 27, 2026. https://vldb.org/pvldb/vol5/p1483_jiannanwang_vldb2012.pdf

[11] Michael Stonebraker, Daniel Bruckner, Ihab F. Ilyas, George Beskales, Mitch Cherniack, Stan Zdonik, Alexander Pagan and Shan Xu, "Data Curation at Scale: The Data Tamer System," CIDR 2013 (Asilomar, January 6–9, 2013) — machine learning for attribute identification, transformation and deduplication; "When necessary, a human can be asked for guidance"; "lower curation cost by about 90%, relative to the currently deployed production software" across three deployments; at a web aggregator, 100% precision and 98.9% recall on duplicate detection against the existing system's 97% precision and 4% recall. The authors' own figures on their own deployments. Read through a rendering fetch that returns extracts, September 27, 2026. https://www.cidrdb.org/cidr2013/Papers/CIDR13_Paper28.pdf

[12] MIT CSAIL Alliances, Tamr, Inc. (member spotlight) — "Founded in 2013"; "Stonebraker recruited co-founder Andy Palmer to form the commercial entity Tamr to extend, robustize, and commercialize the Data Tamer system." Read at source September 27, 2026. https://cap.csail.mit.edu/engage/spotlights/tamr-inc

[13] Sidharth Mudgal, Han Li, Theodoros Rekatsinas, AnHai Doan, Youngchoon Park, Ganesh Krishnan, Rohit Deep, Esteban Arcaute and Vijay Raghavendra, "Deep Learning for Entity Matching: A Design Space Exploration," SIGMOD '18 (2018) — "DL does not outperform current solutions on structured EM, but it can significantly outperform them on textual and dirty EM"; "competitive with Magellan on structured instances (87.9% vs 88.8% average F1)," with far longer training; textual EM improved by "3.0-22.0% F1," dirty EM by "6.2-32.6% F1." Read through a rendering fetch that returns extracts, September 27, 2026. https://pages.cs.wisc.edu/~anhai/papers1/deepmatcher-sigmod18.pdf

[14] Yuliang Li, Jinfeng Li, Yoshihiko Suhara, AnHai Doan and Wang-Chiew Tan, "Deep Entity Matching with Pre-Trained Language Models," Proceedings of the VLDB Endowment (VLDB 2021); arXiv:2004.00584 (submitted April 1, 2020; revised September 2, 2020) — Ditto "outperforms previous state-of-the-art (SOTA), by up to 29% of F1 score on benchmark datasets"; "can achieve the previous SOTA results with at most half the number of labeled data"; on company datasets of 789K and 412K records, "a high F1 score of 96.5%"; its optimizations include injecting domain knowledge. Abstract read at source September 27, 2026. https://arxiv.org/abs/2004.00584

[15] Avanika Narayan, Ines Chami, Laurel Orr, Simran Arora and Christopher Ré, "Can Foundation Models Wrangle Your Data?," arXiv:2205.09911 (submitted May 20, 2022; v2 December 24, 2022) — "large FMs generalize and achieve SoTA performance on data cleaning and integration tasks, even though they are not trained for these data tasks"; "A key challenge in applying FMs to data management tasks is operating over highly specialized domains (e.g., medical, financial, and insurance data)"; on Amazon-Google the model "has difficulty matching samples due to the high volume of product-specific identifiers"; Table 1 ("k is the number of task demonstrations"): GPT3-175B 63.5 F1 at k=10 and 54.3 at k=0, against Ditto's 75.58; "Organizations are often unable to pass sensitive data to third party APIs for privacy reasons." Abstract read at source and the body through a rendering fetch that returns extracts, September 27, 2026. https://arxiv.org/abs/2205.09911

[16] Ralph Peeters, Aaron Steiner and Christian Bizer, "Entity Matching using Large Language Models," Proceedings of the 28th International Conference on Extending Database Technology (EDBT 2025); arXiv:2310.11244 (v1 October 17, 2023; v4 October 18, 2024) — "Our experiments show that the best LLMs require no or only a few training examples to perform comparably to PLMs that were fine-tuned using thousands of examples," with greater robustness to unseen entities; "the prompt needs to be tuned for each model/dataset combination." Abstract (v4) read at source September 27, 2026; the quoted sentences re-checked against it the same day. https://arxiv.org/abs/2310.11244

[17] Tamr, Master Data Management (MDM) Modernization with AI (product page, undated as read) — "Tamr uses LLM-based AI agents to clean, curate, manage, and refine complex edge cases with minimal human intervention." Vendor copy, cited as a specimen of the current claim, not as evidence for it. Read at source September 27, 2026. https://www.tamr.com/mdm-modernization-with-ai