Published
A matcher is only as tested as its inputs
Record linkage — matching two records that refer to the same real-world entity despite different spellings, formats, or missing fields — is a scoring problem. A matcher assigns confidence, and somewhere a threshold decides merge or no-merge. You cannot evaluate that decision boundary with data that has no duplicates near it.
A test set built from unique, well-formed rows tells you the matcher runs. It does not tell you where it draws the line between 'Jon Smith, 14 Elm St' and 'Jonathan Smith, 14 Elm Street' — which is the actual job.
What the test set has to encode
A record-linkage test set needs a known duplicate rate, fuzzy variants at controlled edit distance, and — critically — a label for what the correct answer is. Without ground truth, you can eyeball a matcher's output but you cannot score precision or recall against it.
generate-data.com's fuzzy and exact duplicate generation ships with Master ID and Duplicate Type columns for exactly this reason: the Master ID ties every generated duplicate back to its source record, and the Duplicate Type marks whether a given row is an exact copy or a fuzzy variant. That is the ground truth a record-linkage test needs, generated alongside the data instead of hand-labeled after the fact.
Building the test set
Model your schema, set a duplicate rate per field or per table, and generate a dataset where every duplicate is traceable to its master record. Score your matcher against the Duplicate Type labels and you have a real precision/recall number, not a demo that happened to work.
Start with a schema that looks like your production entities, not a generic sample.
Related: generate-data.com and Generate-Data project overview.