Entity and schema matching benchmark: joining tables that share no keys

Matching is the problem of deciding which things in different tables are the same thing. Entity matching finds the rows that describe the same real-world entity. The model matching finds the columns that correspond across two tables. The tabular foundation model described here does both with no keys, and on schema matching it does it name-blind, while every published competitor sees column names.

This page explains both tasks, why they are hard, how I built the matcher, the mistakes that taught me the most, what made the difference, and what stayed open. Scores are left out on purpose. The model card carries them with their protocols. For all boards, see Benchmarks.

The short version

• Entity matching uses six multi-table datasets. The job is to find which rows describe the same real-world entity, with no keys and no shared identifiers.
• The model matching uses the Valentine scenarios. The job is to say which column in one table corresponds to which in another, scored as F1.
• Every published competitor sees column names. The model does not.
• For entity matching the mistake was over-training. The Music runs trained for 8,000 steps, which hurt. 1,200 steps with a two-model ensemble and a calibrated threshold fixed it.
• For schema matching the matcher combines adapter embeddings, 28 column statistics and a name channel, normalizes the scores and keeps only mutual best one-to-one matches.
• Scoring is micro-averaged, and the averaging rule must be fixed before scoring.
• The model beats the published state of the art on the entity benchmarks, and beats every name-aware matcher on all four schema scenarios.
• One published competitor was trained on the benchmark data, which is a leakage caveat for them, not for me.

Two tasks, one idea

Your customer exists in five systems under five identifiers. A hospital merges with another and now has two patient tables. A company buys a rival and inherits a second product catalogue. In every case two questions come up.

1. Which columns in these tables mean the same thing?
2. Which rows describe the same real-world thing?

Most tools want mapping workshops or match rules before they start. The model matches from the data itself, and every match carries its evidence. See Solutions, question three, "how do I unify systems that share no keys?".

Entity matching

Entity matching is also called record linkage or entity resolution. Two tables hold people, products, songs or companies. There is no shared id. The same entity may be spelled differently, described in different words, or have different fields filled in.

An everyday analogy: two address books made by two different friends. Both contain your cousin. One lists "Bob K., Brooklyn" and the other lists "Robert Kowalski, NYC". There is no common key, but a reader can tell it is the same person from the combination of details.

The model matching

The model matching works at the level of columns. Table A has a column of birth years. Table B has a column of ages at a given date. Table C has a column of dates of birth. Which ones correspond?

An everyday analogy: two forms asking the same questions in different words and a different order. Matching the forms means pairing "Surname" with "Family name" and "DOB" with "Date of birth".

Here the interesting part is that the model does not see the words at the top of the forms in the way the rivals do. It looks at what is written in the boxes.

What the benchmark measures

Keyless

Keyless means there is no shared identifier to join on. The match must come from the content of the rows.

Name-blind

Name-blind means the model does not use a column's identity. Every published competitor sees column names. That makes the schema matching comparison especially demanding for the model, because the cheapest clue is available to the others and not to it. See Column name independence and Metadata independence.

The Valentine scenarios

Valentine is a benchmark suite for schema matching. It builds scenarios by taking a table and splitting or perturbing it in controlled ways, so that the true column correspondences are known. There are four scenarios in the comparison. I report on all four.

Why matching is hard

• Different words for the same thing. "Street" and "Road", "Inc." and "Incorporated".
• Different formats. A date written three ways, a phone number with and without a country code.
• Missing fields. One side has a column the other lacks.
• Near-duplicates inside one table. Two real entities that look alike.
• Scale. Comparing every row with every row grows fast.
• Ambiguous columns. Two columns of integers that look similar but mean different things.

Text matching, which compares strings, gives out where records describe the same entity in different words. That is where the model's margin is widest.

How I built entity matching

The first mistake: over-training

The Music runs trained for 8,000 steps, and that hurt. More training did not make the matcher better. It made it fit the quirks of the training pairs and lose the general rule. This is over-fitting, in plain words.

An everyday analogy: a student who memorizes last year's exam answers and then fails a new exam on the same subject.

The fix: less training, an ensemble, a calibrated threshold

• 1,200 steps instead of 8,000. Stop early, before the matcher memorizes.
• A two-model ensemble. Two models vote. Where they disagree, a single model's quirk is outvoted.
• A calibrated threshold. The score above which a pair counts as a match is set so that the stated confidence means what it says.

Together these fixed the problem and cut the run-to-run variance. Less variance is its own result: a method that gives a different answer each time is hard to trust.

Why a calibrated threshold matters

A matcher gives each pair a score. Somewhere you have to draw a line: above it, a match, below it, not. A line drawn by habit can be too eager or too shy. A calibrated line is set on held-out pairs so the confidence reflects how often a pair at that score really matches. See Evaluation for the idea of reading a score next to a baseline.

No keys, no preprocessing

The model reads the raw rows. There is no blocking key, no hand-written rule and no cleaning pass. See Cell encoding for how every cell becomes a vector no matter its type.

How I built schema matching

The matcher combines three channels.

A note on the name channel. The matcher lists a name channel among its three, while the model core itself never uses column identity. That is how I describe the model: name-blind at its core.

Scoring pairs

For every pair of columns, one from each table, the matcher produces a score from the channels.

Normalizing

The scores are normalized so that they are comparable across columns. Without this, a column with many look-alike partners would look systematically weaker than one with few.

Mutual best one-to-one matches

Then the matcher keeps only mutual best one-to-one matches. A pair survives only if each column picks the other as its best match.

An everyday analogy: a dance where a pairing counts only if both people want each other as their first choice. It stops one popular column from claiming many partners.

for each column a in table A: best_b(a) = argmax over b of score(a, b)
for each column b in table B: best_a(b) = argmax over a of score(a, b)
keep (a, b) only if best_b(a) == b and best_a(b) == a

The result is a clean one-to-one alignment, which is what a data engineer wants to review.

The output

The output is a set of column alignments, entity matches and a unified schema, each with a confidence. Each aligned pair is grounded in a verbatim example from each side, so a person can see why the pair was proposed. See Capabilities.

Matches are proposed into a review queue and never applied automatically.

Measurement lessons

Most of what I learned on this board is about the ruler. Three episodes stand out.

Micro versus macro averaging

Scoring is micro-averaged. The macro average gave a different answer. In micro averaging every correspondence counts equally. In macro averaging every scenario or class counts equally, so a small scenario weighs as much as a large one.

Neither is wrong. They answer different questions. The lesson is that the averaging rule must be fixed before scoring. If you pick it after seeing the numbers, you can choose the one that flatters you.

Rebuilding missing data from its public archive

When the Valentine data was missing, I rebuilt it from its public archive. I did not substitute something similar. Using the same data as the published results is what makes a comparison to them meaningful.

The checkpoint that was not preserved

A checkpoint that was not preserved at the time of sealing taught me to copy every sealed adapter at the moment of sealing. A result you cannot reproduce is not a result. This is one reason the final work was merged into a single checkpoint. See One checkpoint.

What made the difference

• Matching from content. No keys, no rules, no cleaning pass.
• Name-blind at the core. The model does not lean on the cheapest clue.
• Less training and an ensemble for entities. 1,200 steps, two models, a calibrated threshold.
• Three channels and mutual best matches for schemas. Embeddings, 28 statistics, and a name channel, with a one-to-one filter.
• A fixed averaging rule. Micro-averaging, chosen before scoring.

The model matches records with no keys, beats the published state of the art on the entity benchmarks, and beats every name-aware matcher on all four schema scenarios while running name-blind. The margin is widest where text matching gives out: records that describe the same entity in different words.

Why content beats spelling

Spelling comparison asks whether two strings look alike. Content comparison asks whether two records behave alike across all their fields. When the same entity is described in different words, the strings differ, but the numbers, the categories and the structure still line up. The model reads all of that together.

What stayed open

• A leakage caveat on one rival. One published competitor was trained on the benchmark data. That is a caveat for them, not for me, and I note it rather than claim a larger win.
• Name-aware advantages are real in the wild. Where names are clean and informative, a name-aware matcher has an extra clue. The benchmark shows the model does not need it, not that names never help.
• Review is still needed. Matches come with confidences and are proposed, not applied. See Limitations.
• Ambiguous columns. Two similar columns can still be confused when their values are alike.

Protocol

• Entity matching: six multi-table datasets, no keys.
• The model matching: the four Valentine scenarios, F1, micro-averaged.
• The model is name-blind at its core. Competitors see column names.
• One sealed configuration, with no per-dataset tuning.
• Competitor figures are third-party published values cited to their primary source, not re-run by me.
• Results under different datasets, metrics or masking schemes are never blended into one number.
• Each run is checked for contamination against the training corpus.
• The protocols follow arXiv:2604.21238 and arXiv:2507.10897.

How the output looks

The output has the same shape for every pair of tables.

{
  "cross_table_map": {
    "column_alignments": [
      { "a": "c3", "b": "c11", "confidence": 0.93,
        "example_a": "(212) 555-0184", "example_b": "2125550184" }
    ],
    "entity_matches": [
      { "row_a": 41, "row_b": 207, "confidence": 0.88 }
    ],
    "unified_schema": ["phone", "name", "city"]
  }
}

The values are invented to show the shape, not results. The verbatim examples from each side are what let a reviewer say yes or no quickly.

Reading the confidences

• High confidence with matching examples: accept.
• Middling confidence: review.
• Low confidence: leave unmatched.

Where it fits in a workflow

1. Name the sector of each table. See Blind sector identification.
2. Align the columns across tables.
3. Match the rows that describe the same entity.
4. Review the proposals in a queue.
5. Merge into a golden record, keeping each source's raw value.

For the product view, see Solutions.

Use cases

Lessons from this board

• Stop training before the model memorizes.
• Ensemble to reduce run-to-run variance.
• Calibrate the threshold on held-out pairs.
• Fix the averaging rule before looking at numbers.
• Rebuild missing benchmark data from the public archive.
• Copy every sealed adapter at the moment of sealing.
• Say when a rival has a leakage caveat, and do not inflate the win.

Fact sheet

Common misreadings

"Name-blind means it ignores meaning"

It ignores the label, not the meaning. The meaning comes from the values and from how columns relate.

"Beating name-aware matchers means names are useless"

It means the model does not need them. Clean names can still help a matcher that uses them.

"Matches are applied automatically"

They are proposed into a review queue with confidences and evidence.

"Longer training is always better"

On Music, it was worse. 8,000 steps hurt, and 1,200 steps with an ensemble worked.

"Macro and micro give the same answer"

They did not here. That is why the rule is fixed before scoring.

The work in order

A walk through one pair of tables

The tables below are invented, to show the logic.

Table A (customers)                     Table B (accounts)
c1: names                               k7: free text, one per row
c2: phone numbers                       k2: digits only
c3: city names                          k9: city names
c4: signup dates                        k4: dates in another format

1. Column by column, the matcher scores every pair. The two phone columns score high because their values have the same shape, even though one has punctuation.
2. The scores are normalized, so a column with several look-alikes is not unfairly weak.
3. Mutual best matches are kept: c2 with k2, c3 with k9, c4 with k4, and c1 with k7.
4. For entities, rows are compared across all fields together. Two rows that agree on phone and city and date are proposed as one entity.
5. Each proposal carries a confidence and a verbatim example from each side.

Entity matching versus schema matching

Do and do not

Do:

• Stop training before the matcher memorizes.
• Use more than one model for entities.
• Calibrate the threshold on held-out pairs.
• Keep only mutual best matches for schemas.
• Fix the averaging rule before scoring.
• Review proposals before applying them.

Do not:

• Assume more steps always help.
• Pick micro or macro after seeing the numbers.
• Substitute similar data when a benchmark file is missing.
• Overlook a leakage caveat on a rival.
• Apply merges automatically.

Questions to ask about any matching claim

• Do the competitors see column names, and does your method?
• Is any competitor trained on the benchmark data?
• Which averaging rule was used, and was it fixed in advance?
• How was the match threshold chosen?
• Is the match one-to-one, or can one column match many?
• Is the evidence for each match shown?
• Are matches applied automatically or reviewed?

The result in six lines

• Entities: ahead of the published state of the art on the six datasets.
• Schemas: ahead of every name-aware matcher on all four scenarios.
• Names: not used by the core.
• Training: shorter is better on Music.
• Variance: cut by the ensemble.
• Caveat: one rival was trained on the benchmark data.

Why the model can do this at all

Matching is a natural use of what the model already learns. During pre-training it is asked to reconstruct hidden cells from the rest of the table. That forces it to learn which columns go together and what a column's values look like. The same knowledge answers the matching question: columns that play the same role look alike, and rows that describe the same entity agree on the many small things that surround any one field.

• Axial attention compares columns with columns and rows with rows. See Architecture.
• Zeroed column embeddings keep the model reading values. See Column name independence.
• Adapters let a small trained module specialize the shared body for matching. See Adapters.
• Pre-training supplies a very wide range of tables to learn from. See Pre-training.

Quick answers

• Do I need keys? No.
• Do I need column names? No.
• Does it give evidence? Yes, a verbatim example from each side.
• Does it give a confidence? Yes, for each match.
• Does it apply merges? No, it proposes them.
• Where are the scores? In the model card, with their protocols.

The standing rules, restated

• Competitor figures are never re-run by me.
• They are cited to their primary source.
• My figures come from one sealed configuration.
• There is no per-dataset tuning.
• Different datasets, metrics or masking schemes are never blended.
• Each run is checked for contamination.
• Caveats on rivals are recorded, not exploited.

What each channel adds

Adapter embeddings

• They describe a column and its cells as vectors.
• They come from adapters on the shared body.
• They carry the learned sense of what a column's values look like.

Column statistics

• There are 28 of them.
• They summarize the shape of a column's values.
• They give a cheap, stable view that does not depend on text.

Name channel

• It scores pairs on names.
• It is one of the three channels.
• The core of the model never uses a column's identity.

Reading the output as a reviewer

1. Start with the highest-confidence alignments and confirm them quickly.
2. Read the verbatim examples on the doubtful ones.
3. Leave low-confidence pairs unmatched.
4. Apply the accepted matches to build the unified schema.
5. Keep each source's raw value next to the merged one.

What a reader can take away

• Tables with no shared keys can still be joined.
• Training longer can make a matcher worse.
• A one-to-one filter gives clean alignments.
• The averaging rule is part of the claim.
• Caveats belong next to results.

Where to read next

• Blind sector identification for naming what a table is before matching it.
• Missing-value imputation for another use of column relations.
• One checkpoint for why every sealed adapter lives in one object.
• Solutions for the questions this model answers.

Terms used on this page

• Entity matching. Finding rows in different tables that describe the same real-world thing.
• the model matching. Finding columns in different tables that correspond.
• Valentine. A benchmark suite of schema matching scenarios with known correspondences.
• Micro-average. An average where every correspondence counts equally.
• Macro-average. An average where every scenario or class counts equally.
• Ensemble. Several models combined, usually by voting or averaging.
• Calibrated threshold. A cut-off set so that confidences mean what they say.
• Mutual best match. A pair in which each side picks the other as its first choice.
• Adapter. A small trained module added to a shared body. See Adapters.

Frequently asked questions

What is entity matching?

It is the task of finding rows in different tables that describe the same real-world entity, with no shared key. The benchmark uses six multi-table datasets, and the model reads the raw rows to decide which records belong together.

What is schema matching?

It is the task of deciding which column in one table corresponds to which column in another. The benchmark uses the four Valentine scenarios and scores the result as F1, micro-averaged.

How can the model match without column names?

Its core never uses a column's identity. It reads the values and how columns relate to each other, so two columns that behave alike can be paired even when their labels differ. Every published competitor in the comparison sees column names, and the model still beats them on all four scenarios.

What went wrong with the Music runs?

I over-trained them. Training for 8,000 steps hurt. I cut training to 1,200 steps, used a two-model ensemble and a calibrated threshold, and that fixed the problem and reduced run-to-run variance.

What is a mutual best one-to-one match?

It is a pair of columns in which each column picks the other as its best match. Keeping only those pairs gives a clean one-to-one alignment and stops one column from claiming several partners.

Why does micro versus macro averaging matter?

The two rules gave different answers, so the choice can change the story. I fixed micro-averaging before scoring, so the rule could not be picked to flatter the result.

Does the model apply matches automatically?

No. Matches, alignments and the merged-schema proposal come with a confidence and evidence, and they are proposed into a review queue. A person decides what to apply.

Is the comparison fair to the rivals?

Competitor figures are third-party published values and are not re-run. One rival was trained on the benchmark data, and I record that as a leakage caveat for them. Where I had to rebuild the Valentine data, I did it from its public archive.

Where is the margin widest?

Where text matching gives out, on records that describe the same entity in different words. When strings agree, any matcher does well. When they do not, reading the whole record pays off.

What if two columns look alike?

They can still be confused. The mutual best rule and the confidence score help, and the review queue is there for the doubtful cases. See Limitations.

Summary

Matching joins tables that share no keys. The model matches rows to rows and columns to columns from content alone, with a name-blind core. On entity matching it beats the published state of the art on the six datasets, and on the four Valentine schema scenarios it beats every name-aware matcher, with the widest margin where records use different words for the same entity.

The path there was full of lessons about the ruler: over-training on Music fixed by 1,200 steps, a two-model ensemble and a calibrated threshold; micro-averaging fixed before scoring; missing data rebuilt from its public archive; every sealed adapter copied at the moment of sealing. What stayed open is a leakage caveat on one rival, the continuing value of review, and confusion between look-alike columns. Read next: Metadata independence, Architecture, Capabilities and Limitations.