Paper deep dive
MosaicJoin: Compact Semantic Sketches for Value-Level Join Discovery
Grace Fan, Eden Wu, Majid Daliri, Juliana Freire
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 90%
Last extracted: 7/28/2026, 4:01:08 AM
Summary
MosaicJoin is a training-free, value-level semantic join discovery method that uses compact semantic sketches constructed via k-center sampling to efficiently approximate joinability between high-cardinality columns in data lakes, outperforming existing methods in speed and accuracy.
Entities (11)
Relation Signals (8)
Grace Fan → authored → MosaicJoin
confidence 98% · Grace Fan New York University... We present MosaicJoin
Juliana Freire → authored → MosaicJoin
confidence 98% · Juliana Freire New York University... We present MosaicJoin
MosaicJoin → uses → Semantic Sketch
confidence 95% · MosaicJoin achieves scalability through a novel sketching strategy that approximates the joinability of a column pair
MosaicJoin → uses → k-center
confidence 92% · MosaicJoin constructs a fixed-size set of representative value embeddings... via k-center sampling
MosaicJoin → uses → Chamfer-style similarity
confidence 90% · MosaicJoin scores each candidate sketch using a joinability score at a cost bounded by the sketch size
MosaicJoin → outperforms → DeepJoin
confidence 85% · MosaicJoin outperforms previously published methods across all benchmarks
MosaicJoin → outperforms → Snoopy
confidence 85% · MosaicJoin outperforms previously published methods across all benchmarks
MosaicJoin → outperforms → PEXESO
confidence 85% · MosaicJoin outperforms previously published methods across all benchmarks while running up to 66 times faster than other value-level methods.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Join discovery is a core task in dataset search, enabling users to find columns that can be joined with a given query column. Early approaches focused on equi-joins, but data lakes and open-data repositories often contain columns whose values refer to the same entity but use different syntactic representations. To address this challenge, recent approaches discover semantically joinable columns but face a fundamental trade-off: methods that perform value-level comparisons accurately identify joinable columns but scale poorly to columns with high cardinality; column-level methods that encode an entire column into a single embedding are efficient but do not capture the fine-grained value alignment that determines whether a join is possible. We present MosaicJoin, a value-level semantic join discovery method that balances this trade-off. MosaicJoin achieves scalability through a novel sketching strategy that approximates the joinability of a column pair without having to compare all values. At query time, MosaicJoin scores each candidate sketch using a joinability score at a cost bounded by the sketch size, making retrieval efficient even for high-cardinality columns. A query subsampling operator further reduces online search time with provable accuracy guarantees, enabling robust retrieval for large query columns. Extensive experiments show that MosaicJoin outperforms previously published methods across all benchmarks while running up to 66 times faster than other value-level methods. MosaicJoin requires no training or fine-tuning, and it scales robustly to query columns containing up to 57K values and data lake columns containing up to 1M values.
Tags
Links
- Source: https://arxiv.org/abs/2607.21781v1
- Canonical: https://arxiv.org/abs/2607.21781v1
Trouble viewing inline? Open PDF directly →
Full Text
78,331 characters extracted from source content.
Expand or collapse full text
MosaicJoin: Compact Semantic Sketches for Value-Level Join Discovery Grace Fan New York University grace.fan@nyu.edu Eden Wu New York University eden.wu@nyu.edu Majid Daliri New York University daliri.majid@nyu.edu Juliana Freire New York University juliana.freire@nyu.edu ABSTRACT Join discovery is a core task in dataset search, enabling users to find columns that can be joined with a given query column. Early ap- proaches focused on equi-joins, but data lakes and open-data repos- itories often contain columns whose values refer to the same entity but use different syntactic representations. To address this chal- lenge, recent approaches discover semantically joinable columns but face a fundamental trade-off: methods that perform value-level comparisons accurately identify joinable columns but scale poorly to columns with high cardinality; column-level methods that en- code an entire column into a single embedding are efficient but do not capture the fine-grained value alignment that determines whether a join is possible. We presentMosaicJoin, a value-level semantic join discovery method that balances this trade-off.Mo- saicJoinachieves scalability through a novel sketching strategy that approximates the joinability of a column pair without having to compare all values. At query time,MosaicJoinscores each candi- date sketch using a joinability score at a cost bounded by the sketch size, making retrieval efficient even for high-cardinality columns. A query subsampling operator further reduces online search time with provable accuracy guarantees, enabling robust retrieval for large query columns. Extensive experiments show thatMosaicJoin outperforms previously published methods across all benchmarks while running up to 66 times faster than other value-level methods. MosaicJoinrequires no training or fine-tuning, and it scales ro- bustly to query columns containing up to 57K values and data lake columns containing up to 1M values. PVLDB Reference Format: Grace Fan, Eden Wu, Majid Daliri, and Juliana Freire. MosaicJoin: Compact Semantic Sketches for Value-Level Join Discovery. PVLDB, 19(11): X-X, 2026. doi:X.X/X.X PVLDB Artifact Availability: The source code, data, and/or other artifacts have been made available at https://github.com/VIDA-NYU/MosaicJoin. 1 INTRODUCTION The number of datasets in open and enterprise data repositories and data lakes has grown dramatically in recent years [47,53], This work is licensed under the Creative Commons BY-NC-ND 4.0 International License. Visit https://creativecommons.org/licenses/by-nc-nd/4.0/ to view a copy of this license. For any use beyond those covered by this license, obtain permission by emailing info@vldb.org. Copyright is held by the owner/author(s). Publication rights licensed to the VLDB Endowment. Proceedings of the VLDB Endowment, Vol. 19, No. 11 ISSN 2150-8097. doi:X.X/X.X creating opportunities to augment data, improve machine learn- ing models, and enrich analyses [7,52]. Yet the scale and hetero- geneity of these repositories make manual data discovery infeasi- ble, as metadata in data lakes is frequently incomplete, inconsis- tent, or ambiguous [1,25,57,72]. Automated data discovery has thus attracted significant attention [8,22,29,57], with join discov- ery [64,67,74,76] emerging as a key subtask. In particular, finding semanticallyjoinable columns [12,18,19,31,43] is essential for data enrichment [6, 9, 17, 73]. Given a query column and a large repository, join discovery aims to identify columns whose values can be joined with those in the query column. Early systems focused on equi-joins, finding columns that share exact string values with the query [27,64,74,76]. However, these approaches suffer from low recall in real data lakes, where semantically equivalent values frequently differ in surface form through abbreviations, aliases, and misspellings. Semantic Joins.To handle such variations, existing semantic join dis- covery methods determine joinability based on either column-level or value-level similarities. Value-level methods such asPEXESO[18] and Exact Semantic Join, an exhaustive value-embedding baseline we evaluate in Section 5, compare individual value embeddings across columns, directly measuring fine-grained joinability. How- ever, exhaustive value-pair comparison scales poorly: for columns with tens of thousands of values, the cost becomes prohibitive, as shown in Figure 1. Column-level methods such as DeepJoin [19] and Snoopy [31], by contrast, collapse an entire column into a single fixed-length embedding retrieved via approximate nearest neighbor search. While efficient, a single vector cannot capture the fine-grained value alignment that determines whether a join is possible, producing both false negatives — joinable columns whose values align but whose column-level embeddings do not, and false positives — columns that are topically similar but not value-level joinable. Example 1.Suppose a user has a query column about football league seasons (퐶 푄 , top left in Figure 2). Equi-join methods miss the green column퐶 퐺 because its values are syntactically different: “2003 Tippeligaen” is the Norwegian name for 2003 Norwegian Pre- mier League, “1992 Vyshcha Liha” is the predecessor name of 1992 Ukrainian Premier League, and “2006 Division 1 (Swedish football)” is a formatting variant of 2006 Swedish football Division 1. Column-level methods instead return the blue column퐶 퐵 that contains basketball team names, which is topically related to sports but whose values do not align with football league seasons. Our Approach.We proposeMosaicJoin, a value-driven semantic join discovery method that achieves high accuracy of value-level matching while approaching the efficiency of column-level retrieval, as shown in Figure 1. Compared to the exhaustive value-pair com- parison method for joinability (Exact Semantic Join),MosaicJoin Figure 1: Tradeoffbetween Accuracy of Value-level Joinabil- ity and Online Search Efficiency of Column-level joinability, for query columns with up to 57K values (Section 5). reduces online search time from 15.65 seconds to 0.32 seconds while preserving high accuracy. This sub-second response time is impor- tant both for interactive dataset search [7,32], where users explore join candidates in real time, and for automated data integration pipelines [6,9], where a large number of potential join pairs must be evaluated without the discovery process becoming a bottleneck. The key insight behindMosaicJoinis that determining the joinability of two columns does not require comparing all pairs of value embed- dings. Instead, for each data lake column,MosaicJoinconstructs a fixed-size set of representative value embeddings–a semantic sketch–that maximally covers the column’s embedding space via푘- center sampling [36]. By selecting representatives that minimize the maximum distance from any value embedding to its nearest sketch point, the k-center objective guarantees that the full embedding space of the column is covered, so that similarity computed against the sketch closely approximates similarity computed against all values. At query time,MosaicJoinscores each candidate sketch us- ing Chamfer-style similarity score [36] at a cost bounded by sketch size rather than data lake column cardinality, making retrieval ef- ficient even for columns with a very large number of values. To further reduce online query cost, rather than embedding all query values, we subsample the values and use the resulting subset to estimate the full Chamfer score with provable accuracy guarantees. Unlike deep learning-based approaches [12,19,31,34,38,43,49], MosaicJoinrequires no training or fine-tuning and can be deployed immediately on any new or evolving data lake without task-specific retraining. We make the following contributions: • We proposeMosaicJoin, a training-free semantic join discovery method that preserves value-level joinability evidence while enabling efficient online top-푘retrieval over data lakes. • We introduce compact semantic sketches for columns, constructed with a푘-center procedure that covers the column embedding space and preserves rare but join-critical values. • We define a Chamfer-style joinability score over semantic sketches, bounding candidate comparison cost by sketch size rather than column cardinality. We further reduce query-time cost using a subsampling estimator with provable accuracy guarantees. •We introduce an evaluation protocol for semantic join discovery on fuzzy-join benchmarks and WDC-augmented search spaces, using LLM-as-a-judge silver labels with human validation to assess value-level alignment at scale [70]. • We evaluateMosaicJoinon six benchmarks with up to 99K columns and 1M values and show that it outperforms previ- ously published methods by up to 17.6% in the ranking metric NDCG@20 and 135.7% in the accuracy metric Precision@10, while being up to 66×faster than value-level baselines. 2 RELATED WORK Table Discovery.Table discovery has a rich line of literature [8, 22,29,57]. Early work focused on keyword search over the meta- data of tables [4,5,32], while recent systems support interactive exploration via data profiling and relationship discovery [7,21,26, 53,55,56,61,72]. Relationships include joinability, unionability, and correlation to improve machine learning models and explain data [2,3,10,13,23,35,37,58,64,67]. We focus on join discovery. Equi-join approaches approximate Jaccard similarity and set con- tainment to find value overlap [27,74,76], with later techniques sup- porting joinable and correlated tables [64–66] and multi-attribute joins [20]. These only handle exact string overlap, missing semanti- cally equivalent joins. More recent work has incorporated semantics into join discovery [16,40].PEXESO[18] performs exact value-level semantic join discovery by embedding cells individually and retriev- ing candidates within a distance threshold. AlthoughPEXESOuti- lizes pivot-based pruning and a block-and-verify index, it remains verification-heavy with runtime scaling in both query length and the number of filtered candidates; we includePEXESOas an exact value-level baseline in our experiments. Column-level join methods such asDeepJoin[19] andWarpGate[12] encode each column into a single fixed-length embedding via a pretrained language model and retrieve candidates via approximate nearest-neighbor (ANN) search. While efficient, they must truncate high-cardinality columns, which can fail to capture value-level joinability; we use DeepJoinas the representative column-level baseline; we useDeep- Joinas the representative column-level baseline.Snoopy[31] per- forms efficient value-level joinability by projecting a column onto learned proxy columns to produce a fixed-dimensional embedding for ANN retrieval. SinceSnoopy’s objective is most closely aligned with ours, we compareMosaicJoinagainstSnoopydirectly. Several related efforts address distinct settings.SILKMOTH[15] andKOIOS[54] perform semantic overlap search via maximum bi- partite matching using filter-verification frameworks. While related to join discovery,SILKMOTHandKOIOSrequire exact maximum bipartite matching at query time, making it impractical for noisy data lakes that do not contain only one-to-one joins. Nonethe- less, we includeSILKMOTHandKOIOSin our experiments.Om- niMatch[43] andHyperJoin[49] both create similarity graphs over all columns, discovering all joins fully offline rather than per- forming online top-푘retrieval asMosaicJoindoes.Freyja[50] constructs column-level profiles that do not capture fine-grained value-level alignment, andPolyJoin[34] targets multi-key (n-ary) join search.TabSketchFM[38] uses sketch-based table representa- tions capturing only exact value overlap and numerical similarity, whereasMosaicJoincaptures the semantic alignment of values in embedding space. 1 TOPJoin[41] targets context-aware join- ability in enterprise settings where valid joins require table-level semantic relationships, not just value alignments; we include it as 1 The model is not publicly available forTabSketchFM, so we are not able to include it in our experiments. *SSXFEPP0IEKYI7IEWSR 8MTTIPMKEIR :]WLGLE0MLE (MZMWMSR 7[IHMWLJSSXFEPP Ɛ )QFIHHMRK7TEGI (EXE0EOI &EWOIXFEPP8IEQ)ZSPYXMSR ,SYWXSR6SGOIXW (IRZIV6SGOIXW 7ER(MIKS6SGOIXW Ɛ )QFIHHMRK7TEGI 7OIXGLIW *SSXFEPP0IEKYI7IEWSR 2SV[IKMER4VIQMIV0IEKYI 9OVEMRMER4VIQMIV0IEKYI 7[IHMWLJSSXFEPP(MZMWMSR )QFIHHMRK7TEGI 5YIV]'SPYQR & 4 8STN.SMREFPI 'SPYQRW 3RPMRI 3ǙMRI /'IRXIV *EVXLIWX*MVWX 7OIXGL7M^IP î )QFIHHMRK7M^IG 'LEQJIV7MQMPEVMX] ᭾ FK & 4 & * !᭾ FK & 4 & % 2YQFIVSJ'SPYQRW MR(EXE0EOI 'ERHMHEXI'SPYQR & % 'ERHMHEXI'SPYQR & * 7OIXGL7M^IP î )QFIHHMRK7M^IG Figure 2:MosaicJoinPipeline, with real columns from our experimental evaluations [48] (Section 5). During the offline phase,MosaicJoinembeds column values and creates a compact semantic sketch using the푘-center procedure. During online processing, given a query column,MosaicJoinembeds the column values and ranks candidate columns using a Chamfer-style semantic joinability score.MosaicJoincorrectly returns the green column (퐶 퐺 ) about Football league seasons, whose values match those in the red query column (퐶 푄 ) in the top left. Column-based methods return the bottom blue column (퐶 퐵 ), whose column semantics are similar to those of the query column (basketball and football), but whose values do not align. a context-aware baseline. Broadly, these approaches either require offline, pairwise-heavy modeling or compress columns into coarse heuristic profiles, whereasMosaicJoinuses bounded, deterministic value sketches to keep value-level semantic join evidence while supporting fast online top-푘retrieval, even for high-cardinality columns. Fuzzy-Joins.A complementary line of work studies approximate (fuzzy) joins between two given tables by automatically selecting similarity functions and transformation rules [59].Auto-FuzzyJoin auto-programs a fuzzy-join to meet a user-specified precision tar- get while maximizing recall, alleviating manual tuning of distance functions and thresholds [48].Auto-Join[75] learns string trans- formation programs so that transformed keys can be equi-joined. More recently,DTT[14] uses neural language modeling to map entity columns into joinable formats, avoiding exhaustive searches over hand-crafted transformation spaces. These techniques focus on pairwise join execution or key transformation between two given tables, whereasMosaicJoinsearches a large repository for columns whose values can be joined with a query column. Multivector Search.Late-interaction retrievers represent queries and documents assetsof vectors and score relevance by aggregat- ing fine-grained per-element matches, enabling token-level accu- racy while allowing document representations to be precomputed for efficiency. ColBERT [39] popularized this design, demonstrat- ing that it preserves token-level evidence and is more robust than collapsing a whole text into a single embedding. However, exact evaluation is expensive because it requires many cross-vector com- parisons and cannot be reduced to a single maximum inner product search (MIPS) query. MUVERA [36] addresses this by constructing fixed-dimensional encodings whose dot product approximates the underlying set-based similarity, enabling candidate retrieval via off- the-shelf MIPS indices with lightweight re-ranking. These results motivate our use of aggregate-of-best-matches scoring: it preserves fine-grained evidence about which query values are supported by a candidate column while admitting efficient top-k retrieval through through indexing and approximation mechanisms. 3 PRELIMINARIES In this section, we introduce our notion of semantic joinability and the compact column representation used to make retrieval efficient at data-lake scale. We first define a Chamfer-style semantic joinability score for ranking candidate columns, and then motivate semantic sketches constructed via a푘-center objective. 3.1 Semantic Joinability Traditional join discovery is often based onexact value overlap: two columns are considered joinable if many values in one col- umn appear verbatim in the other [27,64,74,76]. While effective for clean, normalized data, this criterion is brittle in data lakes, where semantically equivalent values may differ in surface through abbreviations, aliases, formatting differences, misspellings. To address this, we move fromexact matchingtosemantic match- ing. Instead of comparing raw strings directly, we compare value embeddings produced by an embedding function휙(·), so that val- ues with similar meaning are close inR 푑 even when their string forms differ. This allows us to determine whether a value in the query column has a semantically similar counterpart in a candidate column. LetΦ(퐶)denote the multiset of value embeddings for column퐶: Φ(퐶)=휙(푣)|푣∈퐶 String-Based Exact-Match Joinability.A strict exact-match score can be written as J exact (퐶 푄 ,퐶)= 1 |퐶 푄 | ! 푣∈퐶 푄 1 [ ∃푣 ′ ∈퐶such that푣=푣 ′ ] (1) This measures the fraction of query values that appear exactly in퐶. Semantic Joinability via a Directed Chamfer-Style Score.Given a similarity functionsim(e.g., cosine similarity), we define semantic joinability as J ch (퐶 푄 ,퐶)= 1 |퐶 푄 | ! 푣∈퐶 푄 max 푢∈Φ(퐶) sim(휙(푣),푢).(2) This is a directed Chamfer-style aggregation [36]: for each value in the query column퐶 푄 , we keep only the best semantic match in the candidate column – the embedding푢with the highest similarity – and then, compute the average across all values. This formulation reflects the semantics of joins in real data lakes, where value mappings are frequently non-bijective. For example, in a city-to-state join, several city names may map to the same state. A one-to-one bipartite matching objective would allow only one city to claim a state, discarding the remaining join evidence and underestimating joinability. The directed Chamfer score avoids this by letting each query value independently contribute its best- match similarity, soJ ch measures semantic coverage of the query by the candidate column. This many-to-one modeling is not an assumption unique to MosaicJoin, it is independently motivated by SEMA-JOIN [33], which studies semantic joins beyond exact equality and explicitly models optional many-to-one mappings as a core join pattern. The distinction is one of setting: SEMA-JOIN predicts an instance-level mapping between two given columns using co-occurrence statistics from a large table corpus, whereas MosaicJoin targets top-k joinable-column retrieval over a data lake, where scores must be efficiently computed across many candidates and require no corpus-level supervision. The directed Chamfer score satisfies both requirements simultaneously. Ranking candidate columns.Given a query column퐶 푄 and a set of candidate columnsC, the scoreJ ch (퐶 푄 ,퐶)provides a common scale for comparison. In particular, if J ch (퐶 푄 ,퐶 푎 )>J ch (퐶 푄 ,퐶 푏 ), then, on average, values in퐶 푄 have stronger best semantic matches in퐶 푎 than in퐶 푏 . Equivalently,퐶 푎 provides better semantic coverage of the query values than퐶 푏 . Therefore, top-푘semantic joinable column search can be imple- mented by ranking candidate columns byJ ch (퐶 푄 ,퐶)and returning the highest-scoring ones. Columns with high scores provide strong semantic coverage of the query, i.e., most query values have at least one close semantic match and are therefore strong join can- didates regardless of whether the value mapping is one-to-one or one-to-many. 3.2 Compact Semantic Sketches via푘-Center The Need for Compact Representations.AlthoughJ ch is a natural semantic analogue of exact overlap, computing it exactly is pro- hibitively expensive at data-lake scale. For a data lake with N can- didate columns, evaluatingJ ch exactly requires computing, for each query value푣∈퐶 푄 , the maximum similarity against every value embedding in every candidate column. This yields an online cost of푂(푁푛|퐶|푑), where푛=|퐶 푄 |is the query column size, |C| is the candidate column size, and d is the embedding dimension — scaling with both query and data lake column cardinalities simulta- neously. For the largest columns in our evaluation (up to 57K query values and 1M data lake values [50]), this cost is reflected in the 15.65-second per-query latency of ESJ, our exact baseline. To make retrieval efficient, we replace the full embedding multisetΦ(퐶)with a compact representative subset, which we call asemantic sketch. Semantic Sketch and Representative Embeddings.For each column퐶 and sketch size푚, we construct a sketch 푆(퐶)⊆Φ(퐶),|푆(퐶)|=푚≪|퐶|, The goal is for푆(퐶)to preserve the semantic coverage ofΦ(퐶), so that joinability computed against the sketch remains a good approximation of joinability computed against the full column. 푘-center Objective for Sketch Construction.We construct푆(퐶)using a푘-center-style objective (with budget푚). Let퐷(·,·)be a distance corresponding to the similarity function (e.g., cosine distance when simis cosine similarity). We choose푚representatives that minimize the worst-case distance from any embedding inΦ(퐶)to its nearest representative: 푆(퐶)∈arg min 푆⊆Φ(퐶) |푆|=푚 max 푥∈Φ(퐶) min 푠∈푆 퐷(푥,푠).(3) Intuitively, this objective ensures that every value embedding in the column is close to at least one selected representative. This is well aligned with the Chamfer-style joinability score, which is based on best matches: if each original embedding is well covered by a nearby representative, then nearest-match similarities against the full column can be approximated using only the sketch. Approximation.The objective above is the푘-center problem with budget푚, which is NP-hard in general and closely related to facility- location-style clustering.MosaicJointherefore uses the standard greedy farthest-first traversal, described in Section 4.2, rather than solving the objective exactly. This approximation is well suited to our setting because it greedily reduces the maximum distance from any column value to its nearest representative, preserving the semantic coverage needed by the Chamfer-style best-match score. For metric distances, farthest-first gives a constant-factor approximation to the optimal푘-center radius. This sketch is built once offline during preprocessing and reused during online scoring, so its cost does not affect query-time search efficiency. 4MOSAICJOINFRAMEWORK We now discuss theMosaicJoinframework, including its offline stage where we build compact semantic sketches (Section 4.2) and online stage where we determine semantic joinability of a query column (Section 4.3). 4.1 System Overview Figure 2 shows the overall pipeline ofMosaicJoin, which consists of an offline and online stage. Given a data lake with columnsC, in theoffline stage, we embed values in each data-lake column and compress each column into a fixed-sizesemantic sketch푆(퐶)using a k-center (farthest-first) procedure. In theonline stage, given a query column퐶 푄 , we embed its values in the same way and rank Algorithm 1:Compact Column Representationvia Farthest-First Selection Input:Value embeddingsΦ=푥 1 ,...,푥 푛 ⊂R 푑 , sketch size푚 Output:Semantic sketch푆⊆Φwith|푆|=푚 1휇← 1 푛 " 푛 푖=1 푥 푖 // centroid푠 1 ←arg min 푥 푖 ∈Φ 퐷(푥 푖 ,휇) // most central point푆←푠 1 ; 2foreach푥 푖 ∈Φdo 3훿 푖 ←퐷(푥 푖 ,푠 1 )// distance to nearest selected point 4for푡=2to푚do 5푠 푡 ←arg max 푥 푖 ∈Φ\푆 훿 푖 ; 6푆←푆∪푠 푡 ; 7foreach푥 푖 ∈Φ\푆do 8훿 푖 ←min ( 훿 푖 ,퐷(푥 푖 ,푠 푡 ) ) ; 9return푆; candidate columns by a sketch-based semantic joinability score. Throughout, we reserve푘fortop-푘retrievaland use푚for the sketch size. 4.2 Offline Stage Value Embeddings.Let퐶be a column with values푣 1 ,...,푣 푛 .To capture the semantics of each value, we form the text푡 푖 :=[푣 푖 ]and compute an embedding푥 푖 :=휙(푡 푖 )∈R 푑 where휙(·)denotes the embedding function. We denote the resulting (multi)set of value embeddings byΦ(퐶):=푥 1 ,...,푥 푛 .Unless stated otherwise, we ℓ 2 -normalize embeddings so that∥푥 푖 ∥ 2 =1and cosine similarity equals the dot product:sim(푥,푦)=푥 ⊤ 푦∈[−1,1]. k-center Semantic Sketch Construction.Storing all embeddingsΦ(퐶) for every column is too expensive at a data-lake scale. Instead, we preprocess each column to derive a compactsemantic sketch 푆(퐶)⊆Φ(퐶),|푆(퐶)|=푚≪|Φ(퐶)|. Intuitively,푆(퐶)should preserve the semanticcoverageofΦ(퐶), so that online scoring can compare a query column against sketches rather than all values. To obtain diverse representatives, we use a k-center style farthest- first procedure [36]. Let퐷(·,·)be a distance consistent with our similarity; with normalized embeddings we use cosine distance 퐷(푥,푦):=1−푥 ⊤ 푦.The k-center objective seeks a subset푆of the embeddings with size푚that minimizes the worst-case distance from any point to its nearest representative: min 푆⊆Φ(퐶),|푆|=푚 max 푥∈Φ(퐶) min 푠∈푆 퐷(푥,푠). We approximate this objective with farthest-first traversal, as de- scribed in Algorithm 1: we seed the sketch with the most central embedding (closest to the centroid), then repeatedly add the point farthest from its nearest selected representative. This encourages broad coverage of the embedding space and empirically preserves rare-but-informative values. Implementation Note.Algorithm 1 runs inO(푛푚)distance compu- tations per column using the maintained nearest-center distances 훿 푖 , and is easily parallelized across columns in the offline pipeline. Algorithm 2:Top-푘Semantic Joinable Column Re- trieval Input:Query column퐶 푄 ; candidate columnsC; embedding function휙(·); compact reps푅(퐶); return size푘; query sample size푏 Output:Top-푘columns ranked by ̃ J (푏) ch (퐶 푄 ,퐶) 1푄←휙(푣)|푣∈퐶 푄 ; 2Sample a multiset푄 푏 ⊆푄of size푏uniformly at random (with replacement); 3Initialize an empty min-heap퐻(capacity푘) storing (score,퐶); 4foreach퐶∈Cdo 5푠←0; 6foreach푞∈푄 푏 do 7푠←푠+max 푟∈푅(퐶) ⟨푞,푟⟩; 8푠←푠/푏// query-subsampled Chamfer score 9if|퐻|<푘then 10HeapPush(퐻,(푠,퐶)); 11else if푠>min(퐻)then 12HeapPopMin(퐻); 13HeapPush(퐻,(푠,퐶)); 14returnHeapItemsSortedDesc(퐻); 4.3 Online Query Processing Algorithm 2 specifies how queries are evaluated. Given a query column퐶 푄 , we embed its values using the same embedding func- tion휙(·)and form the query embedding multisetΦ(퐶 푄 ). We then compareΦ(퐶 푄 )against the semantic sketch푆(퐶)of each candi- date column퐶and rank candidates by their sketch-based semantic joinability score. We return the top-푘highest-scoring columns, optionally filtering out candidates whose score is below a fixed threshold휏(we use휏=0.1). Query Subsampling for Faster Scoring.To further reduce online cost, we estimate the directed sketch-based Chamfer score using a random subset of query values. Let퐶 푄 =푣 1 ,...,푣 푛 , where 푛=|퐶 푄 |, and푆(퐶)be a candidate sketch derived using Algorithm 1. 푎 푖 :=max 푠∈푆(퐶) ( 휙(푣 푖 )·푠 ) ,푖=1,...,푛. Then the full sketch-based directed Chamfer score is ̂ J ch (퐶 푄 ,퐶)= 1 푛 푛 ! 푖=1 푎 푖 . We sample푏indices퐼 1 ,...,퐼 푏 independently and uniformly from 퐶 푄 values1,...,푛, and define the subsampled estimator ̃ J (푏) ch (퐶 푄 ,퐶)= 1 푏 푏 ! 푡=1 푎 퐼 푡 . Theorem 2 (99.9% confidence for qery-subsampled Cham- fer).Fix a candidate sketch푆(퐶), assume embeddings are normalized so that휙(푣 푖 )·푠∈[−1,1]for all푖and푠∈푆(퐶). Then E [ ̃ J (푏) ch (퐶 푄 ,퐶) ] = ̂ J ch (퐶 푄 ,퐶), and with probability at least99.9%, ) ) ) ̃ J (푏) ch (퐶 푄 ,퐶)− ̂ J ch (퐶 푄 ,퐶) ) ) ) =푂 ( √ 1 푏 ) . Proof.Define푋 푡 :=푎 퐼 푡 for푡=1,...,푏. Then ̃ J (푏) ch (퐶 푄 ,퐶)= 1 푏 푏 ! 푡=1 푋 푡 . Since each퐼 푡 is uniform on1,...,푛, E[푋 푡 ]= 1 푛 푛 ! 푖=1 푎 푖 = ̂ J ch (퐶 푄 ,퐶). Hence, by linearity of expectation, E [ ̃ J (푏) ch (퐶 푄 ,퐶) ] = ̂ J ch (퐶 푄 ,퐶). Because embeddings are normalized, each푎 푖 ∈[−1,1], and there- fore푋 푡 ∈[−1,1]. The variables푋 1 ,...,푋 푏 are independent since the indices퐼 1 ,...,퐼 푏 are sampled independently. By Hoeffding’s inequality, for any휀>0, Pr ( ) ) ) ̃ J (푏) ch (퐶 푄 ,퐶)− ̂ J ch (퐶 푄 ,퐶) ) ) ) ≥휀 ) ≤2 exp ( − 푏휀 2 2 ) . Setting the failure probability to0.001(i.e., confidence99.9%) gives 2exp ( − 푏휀 2 2 ) ≤ 0.001,which implies휀≥ √ 2 ln(2000) 푏 . Since2ln(2000) is a constant, the error bound at confidence99.9%is푂 ( √ 1 푏 ) .! Query Search Complexity.Let푁:=|C|be the number of candidate columns,푛:=|퐶 푄 |be the number of query values, and assume each candidate sketch has size at most푚(i.e.,|푆(퐶)|≤푚). Given a subsample of size푏, scoring a single candidate column requires 푂(푏푚푑)time, since for each of the푏sampled query embeddings we compute the maximum inner product against its푚sketch vectors inR 푑 . Maintaining the top-푘heap adds푂(log푘)time per candidate. Therefore, the total online query time is 푂 ( 푁푏푚푑+푁log푘 ) . When푘≪푁, the dominant term is typically푂(푁푏푚푑), and with- out query subsampling (i.e.,푏=푛) this becomes푂(푁푛푚푑). 5 EXPERIMENTS We evaluateMosaicJoinon six benchmarks, including a semantic join benchmark [50], two benchmarks originally used for fuzzy-join evaluations [48,75], and expanded variants of these benchmarks with larger search spaces, constructed by injecting tables from the WDC corpus [70]. To our knowledge, this is the first evaluation to di- rectly assess the semantic alignment of values in columns retrieved by semantic join discovery methods. Thus, we adapt fuzzy-join benchmarks for this evaluation. First, we conduct extensive ab- lation studies to analyze different design choices ofMosaicJoin. Next, we show thatMosaicJoinachieves new state-of-the-art re- sults on value-level semantic join search among published methods –outperforming the best-performing published method by up to 17.6% in NDCG@20 on smaller benchmarks and up to 135.7% in Precision@10 on larger benchmarks. 5.1 Setup 5.1.1 Environment.We implementMosaicJoinin Python using PyTorch and Huggingface transformers library. All experiments were conducted on a server equipped with a NVIDIA L40S GPU, 128GB RAM, and 8 CPU cores. 5.1.2 Benchmarks.We perform our experiments using three bench- marks and construct expanded variants of these with WDC tables (see details in Table 1). For each benchmark, we split tables into single-column tables to evaluate joinable column search. Auto-FuzzyJoin[48] andWebtables[75] benchmarks were originally designed for evaluating joins between source and tar- get tables.Auto-FuzzyJoincontains 50 diverse fuzzy-join table pairs derived from DBPedia snapshots [46] between 2013-2021, whileWebtablesconsists of 31 table-pairs collected from Bing and Google search spanning 17 topics, where joins are transformation- based (e.g., formatting or lexical variations). Since both benchmarks evaluate value-level joins, we adapt them to our search setting. The queries are the annotated join columns from the source tables, and the search space consists of all columns across all tables. The ground truth is the corresponding annotated join column from the paired target table in the original ground truth. 2 Freyjabenchmark [50] was created for semantic and syntactic joinable column discovery. It comprises 160 datasets from Kaggle and OpenML, with manually labeled ground truth. 3 To evaluate robustness at scale, we inject into all benchmarks a sample of theWDCWeb Table Corpus [70], which has been previously used to evaluate table search [23,31], into the data lakes ofAuto-FuzzyJoin,Webtables, andFreyja. 5.1.3 Baselines.We compare our approach,MosaicJoin, with the state-of-the-art approaches for column-level join method [19], value-level method [18], proxy-based join method that bridges the two [31], semantic overlap set search methods [15,54], and context- aware join method [41]. We use off-the-shelf model weights re- leased by the authors for DeepJoin and Snoopy, and the fastText base model [45] for PEXESO. This evaluates all methods in the same setting, where they can be deployed directly on new or evolving data lakes without task-specific retraining, which is exactly the setting thatMosaicJointargets. To isolate value semantics and ensure a fair comparison across methods, we evaluate all methods using column values only, without column names. This values-only setting follows prior semantic join discovery evaluations [18,31] and reflects a realistic data lake setting where metadata is often incomplete, noisy, or ambiguous [1, 25, 57]. •DeepJoin[19] is a column-level join discovery method that encodes each column into a single fixed-length embedding using SBERT. We use the model that the authors pre-trained on WDC [63] to run model inference on our benchmarks. To compare fairly with MosaicJoin, we only embed column values. 4 •PEXESO[18], a value-level method, is the most similar baseline toMosaicJoin.PEXESOembeds all column values and retrieves candidates via pivot-based filtering and a grid index. 5 2 https://github.com/chu-data-lab/AutomaticFuzzyJoin/tree/master/src/autofj/ benchmark,https://github.com/Yeye-He/Auto-Join/tree/master/autojoin-Benchmark 3 https://freyja-data-discovery.github.io 4 https://github.com/mutong184/deepjoin 5 https://github.com/BIT-DataLab/LakeBench/tree/main/join/Pexeso Table 1: Statistics onAuto-FuzzyJoin,Webtables, andFreyjabenchmarks, and WDC tables used in the expanded benchmarks. BenchmarkSplit# Cols Total # Rows Max # Rows Avg # Rows Max Card. Avg Card. Auto-FuzzyJoin Query50164.7K6,9333,2956,9333,295 Data Lake 100182K6,9331,8266,9331,826 Webtables Query323.8K690120673113 Data Lake 24447K2,1951942,19182 Freyja Query50223K57,7934,4591,303159 Data Lake 1,31716M1,048,57512,169834,2443,342 WDCData Lake 97,70310M81010281099 •Snoopy[31] is a column-level method that captures value-level joinability using proxy columns, learned from the Scorpion model [31]. We use the original model weights trained on the WDC corpus. 6 • KOIOS[54] is a value-level semantic join discovery method that embeds values and indexes them for neural similarity search. Since the original implementation is written in C, we re-implement it in Python while preserving the method’s original maximum bipartite matching scoring logic to ensure a fair comparison. 7 •SILKMOTH[15] is a value-level join discovery method based on set containment. It retrieves joinable columns by comparing the overlap between column value sets rather than semantic simi- larity. Since the original implementation is not publicly available, we implement a Python version ofSILKMOTHaccording to the algorithms and specifications in the paper [15]. • TOPJoin[41] is a hybrid join discovery method that combines value overlap, column-level semantic similarity, and table-context signals. We use the original implementation ofTOPJoin. 8 •Exact-Semantic-Join(ESJ)is a variation ofMosaicJointhat performs exact semantic join search without constructing semantic sketches of value embeddings proposed in Section 3.2. Instead, it computes exact semantic join score defined in Eq.(2)by, for each query value embedding, finding its closest value embedding in the candidate column (i.e., exact nearest-neighbor matching) and aggregating these matches at query time. 5.1.4 Ground truth Expansion.For the base benchmarks, we use the provided ground-truth labels. For the expanded benchmarks, no ground truth exists between the original query columns and the injected WDC tables, so we augment the original labels with silver labels generated by Gemini 2.5 Pro [11]. We evaluate using the union of the original benchmark ground truth and the silver labels. We use an LLM judge because many valid joins are semantic rather than exact equi-joins, and exhaustive value-pair annotation is infeasible at scale (e.g.,Freyja+WDC would require up to 20K× 26M value-pair comparisons). For each query–candidate pair, we provide both columns’ unique values after minor string normaliza- tion and ask the judge to classify the pair asequijoin,semantic, ornot joinable, with a confidence score and brief rationale. We retain only predictions with confidence>0.7. To avoid bias toward MosaicJoin, for each query column we form the annotation pool as the union of the top-50 retrieved columns fromMosaicJoin 6 https://github.com/ZJU-DAILY/Snoopy/tree/main 7 https://github.com/DataIntelligenceCrew/koios-semantic-search 8 https://github.com/IBM/ContextAwareJoin and each baseline, excluding pairs already present in the original ground truth. Thus, silver labels can originate from any method’s retrieval list. To validate retained positive silver labels, we conduct a multi-model audit on a stratified sample of 200 joinable pairs across all expanded benchmarks, including 75 semantic joins and 125 equi-joins. Each pair is independently checked by Gemini 2.5 Pro, GPT-5.5 [60], and Gemini 3.5 Flash [30]; all 200 receive major- ity support, and 185 receive unanimous support. The remaining 15 disagreement cases are manually reviewed by three human curators and confirmed as correct joinable pairs. For context, with푛=200, a one-sided exact binomial test for detecting an improvement from 90% to 95% precision at훼=0.05has approximately 80% power, confirming the statistical significance of our verification results. 5.1.5 Metrics.Following previous work [19,31], we report Recall@푘 and NDCG@푘forAuto-FuzzyJoinand WT, since they expect a single joinable column per query column in their ground truth. For Freyja, which expects multiple columns per query, we also evaluate Precision@푘. For the expanded benchmarks, where we have LLM annotations of the top-10 retrieved columns from each method, we evaluate Precision@10 and NDCG@10. For a query column퐶 푄 , letS=퐶 1 ,...퐶 |S| be the set of ex- pected joinable columns and ˆ S= ˆ 퐶 1 ,... ˆ 퐶 푘 be the set of retrieved top-푘joinable columns by a specific method with respect to퐶 푄 . Precision@푘= |S∩ ˆ S| | ˆ S| and Recall@푘= |S∩ ˆ S| |S| . NDCG@푘measures the quality of the ranking of the top-푘retrieved columns. Since our ground-truth labels are binary, we define relevance as rel 푖 = 1 [ ˆ 퐶 푖 ∈S ] , where ˆ 퐶 푖 is the column returned at rank푖. NDCG@푘is defined as 퐷퐶퐺@푘 퐼퐷퐶퐺@푘 , where퐷퐶퐺@푘= " 푘 푖=1 푟푒푙 푖 푙표푔 2 (푖+1) and퐼퐷퐶퐺@푘= " 푚푖푛(푘,|S|) 푖=1 1 푙표푔 2 (푖+1) For efficiency, we measure the query search time of all the meth- ods. All metrics are averaged over all queries. 5.2 Ablation Study We first conduct an ablation study ofMosaicJoin’s design choices on theFreyjabenchmark to identify the best hyperparameter set- ting. For each ablation study, we keep the other hyperparameters fixed. We focus on this benchmark because it is technically our largest base benchmark and has the highest cardinality, measured by the number of rows with unique values (Table 1). Varying Size of Query Subsamples.Figure 3 shows the NDCG@10 and runtime ofMosaicJoinon theFreyjabenchmark as we vary the number푏of randomly sampled rows from each query column. Table 2: Ablation studies of Precision, Recall, and NDCG for푘=10,20ofMosaicJoinonFreyjafor different sketch construction methods, online similarity methods, sketch sizes푚, and embedding models. (*) denotes the hyperparameters we use in the rest of the experiments. MethodPrecision@10 Recall@10 NDCG@10Precision@20 Recall@20 NDCG@20 Sketchk-center*0.8760.2870.8850.8290.5430.848 Construction k-means0.4540.1430.4820.2590.1630.335 chamfer ( ̂ J ch )0.8900.2920.9070.8010.5260.838 Online inverse chamfer ( ̂ J inv )0.8200.2680.8200.7970.5210.804 Similarityaverage chamfer ( ̂ J bi )*0.8760.2870.8850.8290.5430.848 푚= 1280.8820.2890.8880.8500.5580.864 Sketch 푚= 64*0.8760.2870.8850.8290.5430.848 Sizes 푚= 320.8380.2740.8480.7920.5180.813 EmbeddingGemma [69] (푑=128)*0.8760.2870.8850.8290.5430.848 Embedding MPNet [68] (푑=768)0.4600.1450.5060.2590.1630.349 Model bge-base-en-v1.5 [71] (푑=768)0.9060.2970.9090.8920.5850.899 (a) NDCG@10(b) Search Time Figure 3: Varying푏(number of sampled values from query columns) onFreyjabenchmark We observe that NDCG@10 quickly stabilizes around푏=1024, with little improvement beyond this point, while runtime is4.5× faster than using the full query column. This indicates that random query subsampling preserves retrieval quality while improving effi- ciency. Based on this tradeoff, we use 푏=1024query samples in all experiments in Section 5.3. This empirical trend is consistent with the guarantee in Theorem 2 from Section 4.3. Comparison of Sketch Construction MethodsTable 2 shows the effect of different sampling strategies for constructing semantic sketches on the performance ofMosaicJoinonFreyja. In particu- lar, we compare our푘-center-based method (Section 3.2) against a 푘-means clustering, where we use the standard푘-means implemen- tation from [62]. We observe that푘-center sampling outperforms 푘-means by large margins for all metrics. This difference is expected for two main reasons. First,푘-means is optimized to minimize average squared distance to cluster cen- troids, which tends to bias the representation toward dense regions of the embedding space. OnFreyja, where many values are re- peated or differ only slightly, this can cause multiple centroids to concentrate around highly frequent but semantically similar values, leaving other parts of the column underrepresented. In con- trast,푘-center sampling explicitly aims to maximize coverage of the embedding space, producing a more diverse set of representative points. Second,푘-means returns synthetic centroids that generally do not coincide with actual embedded values, whereas our푘-center procedure selects representatives directly from the observed embed- ding set. As a result, the semantic sketch remains grounded in real points while still effectively covering the space via the farthest-first traversal used by푘-center. Overall, these results show that푘-center sampling yields a more faithful and diverse summary of the column embeddings, leading to better retrieval performance. Varying Online Similarity Methods.To compare query columns against candidate sketches, we study several Chamfer-style sim- ilarity functions, following the same nearest-neighbor matching principle used in prior retrieval work such as Muvera [ 36]. All variants use dot-product similarity on normalized embeddings and differ only in how they aggregate these matches. This ablation helps determine which aggregation rule is best aligned with semantic join discovery. Directed Chamfer (query→candidate sketch).Our primary score is the directed average Chamfer from the query to the candidate sketch: ̂ J ch (퐶 푄 ,퐶)= 1 |Φ(퐶 푄 )| ! 푞∈Φ(퐶 푄 ) max 푠∈푆(퐶) (푞·푠). This is the sketch-based approximation of the directed semantic joinability score from Section 3.1. It measures, for each query em- bedding, how well it is supported by the candidate sketch, and is therefore the most natural choice for our retrieval setting. Inverse Chamfer (candidate sketch→query).We also evaluate the inverse direction: ̂ J inv (퐶 푄 ,퐶)= 1 |푆(퐶)| ! 푠∈푆(퐶) max 푞∈Φ(퐶 푄 ) (푠·푞). Unlike the directed score above, this variant measures how well the candidate sketch is covered by the query. While this provides a meaningful alternative, it is less directly aligned with our objective, since in join retrieval we primarily care about whether query values can be matched by the candidate column. Bidirectional (average) Chamfer.Finally, we consider a symmetric variant obtained by averaging the two directions: ̂ J bi (퐶 푄 ,퐶)= 1 2 ( ̂ J ch (퐶 푄 ,퐶)+ ̂ J inv (퐶 푄 ,퐶) ) . This score balances both notions of coverage, rewarding pairs that match well in both directions. It can be viewed as a more symmetric measure of semantic similarity, (a) BGE(b)EmbeddingGemma(c) MPNet Figure 4: UMAP projections ofFreyjavalues embeddings from BGE,EmbeddingGemma, and MPNet Models. All em- beddings are in gray. Red and blue points represent expected column values for two distinct queries. though such symmetry is not necessarily required in our inherently directed retrieval task. In all three cases, we useaveragesto keep scores comparable across query columns with different numbers of values and can- didate sketches of different sizes. As shown in Table 2, directed Chamfer and average Chamfer perform comparably. Since the dif- ference is marginal, we adopt average Chamfer in all subsequent experiments and omit the comparison between direct Chamfer against the baselines due to space constraints. Varying Sketch Size푚:We next study the effect of the sketch size parameter푚in the푘-center sketch construction algorithm (Al- gorithm 1) on theFreyjabenchmark. Here,푚controls the number of representative embeddings retained in each semantic sketch. As shown in Table 2, increasing푚beyond 64 yields only marginal gains in retrieval performance. At the same time, smaller sketches reduce search cost (e.g.,푚=64is 1.25×faster than푚=128), lead- ing to faster query-time performance. Based on this tradeoff, we use 푚=64in our experiments. More generally, this accuracy-efficiency balance can be tuned depending on system requirements, as further illustrated in Figure 1. Varying Embedding Models:We also compare different em- bedding models for constructing value representations:Embed- dingGemma[ 69], BGE [71], and MPNet [68]. We analyze the underlying structure of the embedding space. Figure 4 shows a uniform manifold approximation and projection (UMAP) visual- ization [51] of all embeddings ofFreyjavalues (shown in gray) and highlights the distribution of the expected columns for two sample queries in red and blue. To evaluate embedding quality, we compute the average cosine distance of values in each expected column to its respective group centroid. Smaller cosine distance signals compact clusters, meaning the embedding model has suc- cessfully captured the shared semantic context of a column and differentiated it from others. BGE,EmbeddingGemma, and MPNet embeddings have average cosine distances of 0.087, 0.133, and 0.174, respectively. The relative ranking of these models by cluster com- pactness (BGE,EmbeddingGemma, MPNet, in descending order) aligns exactly with their relative ranking in join discovery perfor- mance (Table 2). Thus, the embedding quality directly impacts the downstream performance. While BGE [71] with output dimension 768 achieves slightly higher retrieval accuracy, it incurs a substantially higher query-time cost: its average search time is 0.931 seconds per query, compared to only 0.080 seconds forEmbeddingGemma[69] with output di- mension 128. MPNet [68] is also fast in search time (0.098 seconds), (a) Recall@K(b) NDCG@K Auto-FuzzyJoinBenchmark (c) Recall@K (d) NDCG@K WebtablesBenchmark (e) Precision@K (f) Recall@K (g) NDCG@K FreyjaBenchmark Figure 5: Effectiveness ofMosaicJoinand baselines for vary- ing푘’s onAuto-FuzzyJoin,Webtables, andFreyja. but has significantly lower accuracy performance. We therefore selectEmbeddingGemmaas the default embedding model because it offers a much stronger efficiency–accuracy tradeoff. A key reason this works well is thatEmbeddingGemmais trained with Matryoshka Representation Learning [ 44], which concentrates the most informative semantic signal in the leading dimensions. As a result, truncating the representation to 128 dimensions preserves similar retrieval quality as higher-dimensional embeddings while significantly reducing storage and similarity computation costs at query time. Based on this tradeoff, we useEmbeddingGemmawith 128-dimensional outputs in subsequent experiments. 5.3 Comparisons against Baselines Table 3 reports the effectiveness results on all base and expanded benchmarks.MosaicJoinoutperforms existing methodsDeepJoin, Snoopy,PEXESOon all six benchmarks. We also compare against ESJ, our own exact-search variant, in detail later in this section. Base Benchmarks.OnFreyja,MosaicJoinoutperformsDeep- Join,Snoopy,PEXESOby 9.1%, 42.8%, 72.4% in NDCG@20, re- spectively, and by 10.2%, 60%, 88.8% in Precision@20. OnAuto- FuzzyJoinandWebtables,MosaicJoinoutperforms the best- performing baseline,DeepJoin, by 3.5% and 17.6% in NDCG@20, respectively. As shown in Figure 5,MosaicJoinconsistently out- performs the baselines for all values of푘on all benchmarks. SinceDeepJoincollapses each query column into a single fixed- length embedding, it cannot capture fine-grained value alignment, Table 3: Effectiveness ofMosaicJoinand external baselinesDeepJoin,Snoopy, andPEXESO, and our exact-search variantESJ on all benchmarks.PEXESOtimed out for most, if not all, queries on the expanded benchmarks. Auto-FuzzyJoinWebtablesFreyjaAuto-FuzzyJoin+WDCWebtables+WDCFreyja+WDC Method R@20 NDCG@20R@20 NDCG@20P@20 R@20 NDCG@20P@10NDCG@10P@10 NDCG@10P@10 NDCG@10 ESJ1.0000.8790.9690.5940.845 0.5560.8340.5260.7160.0720.4620.4280.625 DeepJoin 1.0000.9130.8750.4840.752 0.4950.7770.4220.6780.0250.1410.3900.484 Snoopy 1.0000.9110.6560.3470.518 0.3360.5940.4940.7780.0280.1460.3300.506 PEXESO 0.8080.7320.4000.2840.439 0.2800.492– MosaicJoin1.0000.9451.0000.5690.829 0.5430.8480.6300.8190.0660.4230.4280.562 (a) Precision@K(b) NDCG@K Auto-FuzzyJoin+WDC Benchmark (c) Precision@K(d) NDCG@K Webtables+WDC Benchmark (e) Precision@K(f) NDCG@K Freyja+WDC Benchmark Figure 6: Effectiveness ofMosaicJoinand baselines for vary- ing푘’s on the expanded benchmarks. thus producing false positives when a candidate column has a simi- lar topic but is not value-level joinable. In contrast,Snoopyprojects columns onto learned proxy columns to determine column join- ability and to capture fine-grained value alignment. However, its proxies are trained on the WDC corpus, which may not capture the value distributions in our benchmark, including the long-tail distri- butions in high-cardinality columns such as those inFreyja. On the base benchmarks,DeepJoinactually outperformsSnoopybecause DeepJoin’s SBERT encoder generalizes better out-of-domain. How- ever, on the expanded benchmarks that include injected tables from WDC (as shown in Figure 6),Snoopy’s specialized in-domain prox- ies cover the data distributions, leading to better performance than DeepJoin’s. Finally, althoughPEXESOis value-level, its accuracy is low because its pivot-based pruning can prune many joinable columns, and by counting the number of query vectors having at least one matching vector above a fixed similarity threshold, it can return many false positives. In contrast,MosaicJoin’s sketches and Chamfer scoring preserve value-level semantic coverage without relying on similarity thresholds or training data. Expanded Benchmarks.After injecting WDC tables intoAuto- FuzzyJoin,Webtables,Freyjabenchmarks, we evaluate Preci- sion@10 and NDCG@10 on the expanded benchmarks using LLM annotations.PEXESOtimes out after 10 minutes per query, and thus, we cannot report its results for the expanded benchmarks. OnFreyja+WDC,MosaicJoinoutperformsDeepJoinandSnoopy by 9.7%, 29.7% in Precision@10, respectively. OnAuto-FuzzyJoin +WDC andWebtables+WDC,MosaicJoinoutperforms the best performing baseline,Snoopy, by 27.5% and 135.7% in Precision@10, respectively. The absolute scores are lower onWebtables+WDC for all methods because most of injected WDC columns are not joinable withWebtablesqueries (72% of columns), thus resulting in many false positives in top-푘. Figure 6 shows thatMosaicJoin outperforms existing methods throughout all values of푘. Thus, MosaicJoinis robust to larger search spaces, still outperforming existing methods on value-driven semantic join discovery. Comparison withESJ.As shown in Table 3, the exact variant of MosaicJoin,ESJ, outperformsMosaicJoinby 4.4% onWebtables, by 9.2% onWebtables+WDC in NDCG@푘, and by 11.2% onFreyja +WDC. SinceESJperforms exhaustive pairwise matching over all value embeddings, it captures every possible value alignment, in- cluding value alignments thatMosaicJoin’s sketches may miss. Meanwhile, we observe the opposite trend onAuto-FuzzyJoinand Auto-FuzzyJoin+WDC, whereMosaicJoinoutperformsESJby 7.5% and 14.4% in NDCG@푘, respectively.Auto-FuzzyJoincontains one-to-many value alignments [48], andESJ’s exhaustive matching is sensitive to redundant or noisy variations of the same entity. In contrast,MosaicJoin’s푘-center sketching selects distinct repre- sentative values, thus handling these complex alignments more robustly than the exhaustive variant. Robustness to Query Column Size.We further analyze how query column size affects Precision@10, Recall@10, and NDCG@10 of all methods on theFreyjabenchmark, which contains the largest query columns in our evaluation (up to 57K values). We evenly split the query columns into five groups of varying numbers of rows. As shown in Figure 7,MosaicJoinandESJare robust as the query size grows to 57K, while the performances ofDeepJoin, (a) Precision@10 (b) NDCG@10 Figure 7: Analysis of Precision@10 and NDCG@10 ofMo- saicJoin,ESJ,DeepJoin,Snoopy,PEXESOas we vary the number of rows in query columns in theFreyjabenchmark. Recall@10 follows a similar trend. The bottom row subsam- ples values from the largest query bucket (up to 57K rows) inMosaicJoin; dashed lines show the performance of the baselines. Snoopy, andPEXESOgradually decrease. Among the baselines, PEXESOshows the lowest overall performance. SincePEXESOem- beds all query values and relies on pivot-based filtering to prune candidates, it becomes increasingly expensive and less effective as the query column size increases.DeepJoin’s performance degrades more gradually as the query size increases.DeepJointruncates columns to fit its models’ context windows, so the performance is stable on smaller queries but declines asDeepJoinloses poten- tially joinable values as the query size increases to 57K.Snoopy’s performance is generally lower thanDeepJoin’s, since its proxies are trained on WDC. As the query column size increases,Snoopy’s performance declines since its fixed-size proxies fail to represent the long-tail of large value distributions. On the other hand,MosaicJoinandESJmaintain stable per- formance across queries of all sizes.ESJcomputes Chamfer score exhaustively over all query value embeddings, so its accuracy re- mains high. However, its runtime grows linearly with query size, taking∼16 seconds per query onFreyja. In contrast, the푘-center sketches inMosaicJoinpreserve the semantic coverage of candi- date columns, regardless of their size (detailed in Section 3.2), while the query subsampling bounds the online cost of scoring regardless of query size (Theorem 2), leading to accuracy that is similar toESJ at a faster search time of∼0.4 seconds. We see thatMosaicJoin achieves high accuracy at lower query cost, even on large query columns, where all published baselines’ performances degrade. To evaluate robustness as query columns scale, we vary the per- centage of푏sampled values on the largest query columns in the Freyjabenchmark (5K to 57K rows). By reducing푏on fixed column sizes, this experiment serves as a controlled proxy for scaling be- yondFreyjabenchmark size as it represents the same reduction in sampling ratio as increasing the column size for a fixed푏. As shown on the bottom of Figure 7, as the query sampling ratio decreases for larger columns, there is a slight decline in accuracy. However, even when sampling less than2% of query values,MosaicJoinperforms comparably toDeepJoin,Snoopy, andPEXESO. While sampling does impact accuracy, these results demonstrate thatMosaicJoin remains relatively robust as query columns grow. Efficiency.Table 4 reports the preprocessing overhead forMo- saicJoinandESJonFreyja, which is the largest benchmark. While MosaicJoingenerates both embeddings and sketches andESJonly uses embeddings, the additional time and storage overhead for sketches is minimal. Specifically, sketch creation adds only 0.08, 0.07, and 0.25 seconds per column onAuto-FuzzyJoin,Webtables, andFreyjabenchmarks, respectively. Sketch construction does not increase peak memory requirements: Peak RAM and Peak GPU Memory for bothMosaicJoinandESJare 3.69 GB and 25.71 GB, re- spectively. Importantly, this preprocessing is a one-time offline cost that scales linearly through parallelization across columns. When a new column is ingested, the update cost involves generating its embedding and sketch. For theFreyjabenchmark, this update cost is 2.48 seconds and requires∼52 MB of storage. Since columns are processed independently, ingesting new columns does not require reprocessing. Table 5 reports the search time of all methods, averaged over all queries, onAuto-FuzzyJoin,Webtables, andFreyja.MosaicJoin is 2 to 66 times faster than the existing value-level joinable column baseline,PEXESO. Compared to the exact semantic search baseline ESJ,MosaicJoinis 2 to 49 times faster while achieving comparable or higher accuracy. Compared to overlap set search methods,Mo- saicJoinis 6 to 19 times faster thanKOIOSand 120 to 224 times faster thanSILKMOTH.SILKMOTHtimes out on theFreyjabench- mark after 10 minutes per query. AlthoughKOIOSuses a FAISS embedding index and a filter-verification framework, the bipartite matching used inKOIOSscoring makes the search slower than the Chamfer-style scoring inMosaicJoin. However,KOIOSis faster thanESJon theFreyjabenchmark sinceESJmust exhaustively compare all embeddings for large queries whileKOIOSeffectively prunes the search space.MosaicJoinis also up to 1.4 times faster thanTOPJoin, which uses column metadata and aggregate statis- tics and value profiles to retrieve joinable columns. As expected, single-vector methods likeDeepJoinandSnoopyare faster than MosaicJoinat query time, since they compare one vector per can- didate column rather than푚=64sketch vectors. However, Figure 1 shows that the fast search time of these methods also results in lower accuracy. Beyond search time,DeepJoinandSnoopyrequire expensive offline training on large corpora, whereasMosaicJoin requires no training, making it easier to deploy on new data. During online search on the largest benchmarkFreyja,Mo- saicJoinandESJrequire 27% and 49% peak GPU Utilization, re- spectively, to embed query columns and compute Chamfer-style scores.MosaicJoinrequires 2.39 GB of peak RAM and 2.13 GB of peak GPU memory, whileESJrequires 9.06 GB of peak RAM and 6.09 GB of peak GPU memory. These metrics demonstrate that the compact sketches inMosaicJoinnot only save memory but also significantly reduce the computational load on the GPU compared toESJ. In contrast, the value-level baselinePEXESOrequires 3% of GPU utilization, 8.53 GB of peak RAM and 0.51 GB of peak GPU memory, since it mainly uses CPU for pruning and verification. However,MosaicJoinachieves faster search time and nearly four times lower memory usage thanESJandPEXESO. Indexing.We further evaluateMosaicJoinagainst baseline meth- ods that use indexing, specifically overlap set search methodsKOIOS Table 4: Preprocessing and update costs ofMosaicJoinand ESJon theFreyjabenchmark. Time / Col Total Time Storage / Col Total Storage MosaicJoin2.48 sec 3,259.17 sec52.17 MB68.65 GB ESJ 2.23 sec 2,935.38 sec51.96 MB68.38 GB Table 5: Average Online Search Time (in seconds) onAuto- FuzzyJoin,Webtables,Freyjabenchmarks. MethodAuto-FuzzyJoin Webtables Freyja DeepJoin0.0020.0010.001 Snoopy 0.0040.0010.001 PEXESO5.2560.0711.337 ESJ 0.5070.06015.646 KOIOS 1.5470.3831.832 SILKMOTH 17.9364.809– TOPJoin 0.1060.0400.459 MosaicJoin 0.0800.0400.322 andSILKMOTH, andTOPJoin. To allow for a fair comparison of scoring methods, we incorporate the same Faiss embedding index used inKOIOSforMosaicJoincandidate retrieval. Figure 8 shows the effectiveness results on theAuto-FuzzyJoinbenchmark, which is the largest benchmark where all methods successfully complete within a 10-minute query timeout. 9 Additionally,Auto-FuzzyJoin contains one-to-many column cardinalities, which is a realistic scenario in a data lake setting where denormalized tables often result in multiple values mapping to a single query value [48]. As shown in Figure 8,MosaicJoinoutperformsTOPJoin,KOIOS, and SILKMOTHby 8.7%, 15.1%, and 523.4% in NDCG@20, respectively. Thus, Chamfer-style joinability inMosaicJoinis better suited for the one-to-many semantic mappings prevalent in noisy data lakes compared to exact bipartite matching. We further analyze the distinction between value-level methods likeMosaicJoinand hybrid methods likeTOPJoin.MosaicJoin successfully finds semantically joinable columns that contain se- mantically aligned values. For example, in theAuto-FuzzyJoin benchmark, query values like “2004 Tiger Cup” and joinable column values like “2004 AFF Championship” share no string overlap, but both refer to the same sports tournament. In this case,MosaicJoin ranks this column first, whereasTOPJoinranks it below top 3. TOPJoinutilizes table-level context, including column headers and table metadata, which is helpful when value semantics and thus the joins are ambiguous. For example, for a query column “country” in table “USA cars datasets” with values “usa”, “canada”,TOPJoin successfully retrieves a joinable column on “sales territory” with values “Northwest”, “Northeast”. WhileMosaicJoincurrently relies on value-level information, we will explore incorporating table-level contextual signals in future work. 6 CONCLUSION We presentMosaicJoin, a value-driven semantic join discovery method that achieves the high accuracy of value-level methods at 9 Experiments onWebtablesandFreyjaare included in the technical report [24]. (a) Recall@K(b) NDCG@K Figure 8: Effectiveness ofMosaicJoinwith an index onAuto- FuzzyJoin, compared toKOIOS,SILKMOTH,TOPJoin. much faster query search time.MosaicJoinconstructs푘-center se- mantic sketches for each data lake column that maximize coverage of the column’s embedding space, producing a compact represen- tation that captures the full semantics of even high-cardinality columns and enables Chamfer joinability scoring at a cost bounded by the sketch size, rather than by the column size. A query subsam- pling estimator further reduces online query search time regardless of query column size, while preserving accuracy within provable error bounds, enabling robust retrieval even for query columns with up to 57K values. Experiments on fuzzy-join and semantic- join benchmarks, including larger variants, show thatMosaicJoin outperforms existing methods across all benchmarks, making it im- mediately deployable on new data without task-specific retraining. However, value-level join discovery methods involve an inherent trade-offbetween accuracy and efficiency, as shown in Figure 1. AlthoughMosaicJoinachieves sub-second retrieval, there is a trade-offbetween sketch size and retrieval accuracy, in which a larger sketch size may result in higher accuracy but slower runtime. If we consider all value embeddings in a column, like inESJ, the accuracy may be higher (Figures 5 and 6) but the runtime is much slower (Table 5). Our results across benchmarks and ablation stud- ies (Table 2) show that the accuracy of this sketch-based method can vary depending on the embedding quality, sketch size, and the sketch construction method. Furthermore, while query sub- sampling significantly reduces search time (Figure 3), especially for larger columns in theFreyjabenchmark, subsampling may overlook rare joinable values in extremely skewed distributions. While we focus solely on values to find semantic joins, in future work we will explore whether incorporating metadata, semantic type annotations, and column profiles [ 28,42,72] could improve precision by capturing column-level and table-level context to bet- ter disambiguate semantically similar columns [40]. Additionally, whileMosaicJoin’s query search time is already faster than other value-level methods, even for benchmarks with up to 99K columns that each contain up to 1M values, approximate nearest neighbor indexing over sketch embeddings [36] could enable faster retrieval for very large data lakes. ACKNOWLEDGMENTS This work was supported in part by DARPA ASKEM (HR0011262087), ARPA-H BDF, and NSF (OAC-2411221). The views, opinions, and findings expressed are those of the authors and should not be inter- preted as representing the views or policies of these agencies. REFERENCES [1] Marco D. Adelfio and Hanan Samet. 2013. Schema Extraction for Tabular Data on the Web.Proc. VLDB Endow.6, 6 (2013), 421–432. [2] Aline Bessa, Juliana Freire, Tamraparni Dasu, and Divesh Srivastava. 2020. Ef- fective discovery of meaningful outlier relationships.ACM Transactions on Data Science1, 2 (2020), 1–33. [3] Alex Bogatu, Alvaro A. A. Fernandes, Norman W. Paton, and Nikolaos Konstanti- nou. 2020. Dataset Discovery in Data Lakes. InICDE. 709–720. [4] Dan Brickley, Matthew Burgess, and Natasha F. Noy. 2019. Google Dataset Search: Building a search engine for datasets in an open Web ecosystem. In W. 1365–1375. [5] Michael J. Cafarella, Alon Y. Halevy, and Nodira Khoussainova. 2009. Data Integration for the Relational Web.Proc. VLDB Endow.2, 1 (2009), 1090–1101. [6] Riccardo Cappuzzo, Aimee Coelho, Félix Lefebvre, Paolo Papotti, and Gaël Varo- quaux. 2025. Retrieve, Merge, Predict: Augmenting Tables with Data Lakes. TMLR(2025). [7] Sonia Castelo, Rémi Rampin, Aécio S. R. Santos, Aline Bessa, Fernando Chirigati, and Juliana Freire. 2021. Auctus: A Dataset Search Engine for Data Discovery and Augmentation.Proc. VLDB Endow.14, 12 (2021), 2791–2794. [8] Adriane Chapman, Elena Simperl, Laura Koesten, George Konstantinidis, Luis- Daniel Ibáñez, Emilia Kacprzak, and Paul Groth. 2020. Dataset search: a survey. VLDB J.29, 1 (2020), 251–272. [9] Nadiia Chepurko, Ryan Marcus, Emanuel Zgraggen, Raul Castro Fernandez, Tim Kraska, and David R. Karger. 2020. ARDA: Automatic Relational Data Augmentation for Machine Learning.Proc. VLDB Endow.13, 9 (2020), 1373–1387. [10]Fernando Chirigati, Harish Doraiswamy, Theodoros Damoulas, and Juliana Freire. 2016. Data polygamy: the many-many relationships among urban spatio- temporal data sets. InSIGMOD. 1011–1025. [11] Gheorghe Comanici, Eric Bieber, Mike Schaekermann, Ice Pasupat, Noveen Sachdeva, Inderjit Dhillon, Marcel Blistein, Ori Ram, Dan Zhang, Evan Rosen, et al.2025. Gemini 2.5: Pushing the frontier with advanced reasoning, multi- modality, long context, and next generation agentic capabilities.arXiv preprint arXiv:2507.06261(2025). [12] Tianji Cong, James Gale, Jason Frantz, H. V. Jagadish, and Çagatay Demiralp. 2023. WarpGate: A Semantic Join Discovery System for Cloud Data Warehouses. InCIDR. 1–7. [13] Tianji Cong, Fatemeh Nargesian, and HV Jagadish. 2023. Pylon: Semantic Table Union Search in Data Lakes.arXiv preprint arXiv:2301.04901(2023). [14] Arash Dargahi Nobari and Davood Rafiei. 2024. DTT: An example-driven tabular transformer for joinability by leveraging large language models.Proc. ACM Manag. Data2, 1 (2024), 1–24. [15] Dong Deng, Albert Kim, Samuel Madden, and Michael Stonebraker. 2017. Silk- Moth: An Efficient Method for Finding Related Sets with Maximum Matching Constraints.Proc. VLDB Endow.10, 10 (2017), 1082–1093. [16] Yuhao Deng, Chengliang Chai, Lei Cao, Qin Yuan, Siyuan Chen, Yanrui Yu, Zhaoze Sun, Junyi Wang, Jiajun Li, Ziqi Cao, et al.2024. Lakebench: A benchmark for discovering joinable and unionable tables in data lakes.Proc. VLDB Endow. 17, 8 (2024), 1925–1938. [17] Yuyang Dong and Masafumi Oyamada. 2022. Table enrichment system for machine learning. InSIGIR. 3267–3271. [18] Yuyang Dong, Kunihiro Takeoka, Chuan Xiao, and Masafumi Oyamada. 2021. Efficient joinable table discovery in data lakes: A high-dimensional similarity- based approach. InICDE. IEEE, 456–467. [19] Yuyang Dong, Chuan Xiao, Takuma Nozawa, Masafumi Enomoto, and Masafumi Oyamada. 2023. DeepJoin: Joinable Table Discovery with Pre-Trained Language Models.Proc. VLDB Endow.16, 10 (2023), 2458–2470. [20] Mahdi Esmailoghli, Jorge-Arnulfo Quiané-Ruiz, and Ziawasch Abedjan. 2022. MATE: Multi-Attribute Table Extraction.Proc. VLDB Endow.15, 8 (2022), 1684– 1696. [21] Grace Fan and Juliana Freire. 2025. Hierarchical table semantics for exploratory table discovery. InProceedings of the Workshop on Human-In-the-Loop Data Analytics. 1–7. [22] Grace Fan, Jin Wang, Yuliang Li, and Renée J. Miller. 2023. Table Discovery in Data Lakes: State-of-the-art and Future Directions. InSIGMOD Conference Companion. ACM, 69–75. [23] Grace Fan, Jin Wang, Yuliang Li, Dan Zhang, and Renée J. Miller. 2023. Semantics- aware Dataset Discovery from Data Lakes with Contextualized Column-based Representation Learning.Proc. VLDB Endow.16, 7 (2023), 1726–1739. [24] Grace Fan, Eden Wu, Majid Daliri, and Juliana Freire. 2026. Technical Report on MosaicJoin: Compact Semantic Sketches for Value-Level Join Discovery. https://github.com/gracefan2020/MosaicJoin/blob/main/technical_report.pdf [25] Mina H. Farid, Alexandra Roatis, Ihab F. Ilyas, Hella-Franziska Hoffmann, and Xu Chu. 2016. CLAMS: Bringing Quality to Data Lakes. InSIGMOD. 2089–2092. [26]Raul Castro Fernandez, Ziawasch Abedjan, Famien Koko, Gina Yuan, Samuel Madden, and Michael Stonebraker. 2018. Aurum: A Data Discovery System. In ICDE. 1001–1012. [27] Raul Castro Fernandez, Jisoo Min, Demitri Nava, and Samuel Madden. 2019. Lazo: A cardinality-based method for coupled estimation of jaccard similarity and containment. InICDE. 1190–1201. [28] Benjamin Feuer, Yurong Liu, Chinmay Hegde, and Juliana Freire. 2024. ArcheType: A Novel Framework for Open-Source Column Type Annotation using Large Language Models.Proc. VLDB Endow.17, 9 (2024), 2279–2292. [29] Juliana Freire, Grace Fan, Benjamin Feuer, Christos Koutras, Yurong Liu, Eduardo Pena, Aécio Santos, Cláudio T Silva, and Eden Wu. 2025. Large language models for data discovery and integration: Challenges and opportunities.IEEE Data Engineering Bulletin(2025). [30] Google. 2026. Gemini 3.5 Flash. https://ai.google.dev/gemini-api/docs/models/ gemini-3.5-flash. [31] Yuxiang Guo, Yuren Mao, Zhonghao Hu, Lu Chen, and Yunjun Gao. 2025. Snoopy: Effective and Efficient Semantic Join Discovery via Proxy Columns.IEEE Trans. Knowl. Data Eng.37, 5 (2025), 2971–2985. [32] Alon Y. Halevy, Flip Korn, Natalya Fridman Noy, Christopher Olston, Neoklis Polyzotis, Sudip Roy, and Steven Euijong Whang. 2016. Goods: Organizing Google’s Datasets. InSIGMOD. 795–806. [33] Yeye He, Kris Ganjam, and Xu Chu. 2015. Sema-join: joining semantically-related tables using big table corpora.Proceedings of the VLDB Endowment8, 12 (2015), 1358–1369. [34] Xuming Hu, Chuan Lei, Xiao Qin, Asterios Katsifodimos, Christos Faloutsos, and Huzefa Rangwala. 2025. POLYJOIN: Semantic Multi-key Joinable Table Search in Data Lakes. InNAACL. 384–395. [35] Xuming Hu, Shen Wang, Xiao Qin, Chuan Lei, Zhengyuan Shen, Christos Falout- sos, Asterios Katsifodimos, George Karypis, Lijie Wen, and Philip S. Yu. 2023. Automatic Table Union Search with Tabular Representation Learning. InACL. 3786–3800. [36] Rajesh Jayaram, Laxman Dhulipala, Majid Hadian, Jason D Lee, and Vahab Mir- rokni. 2024. MUVERA: Multi-Vector Retrieval via Fixed Dimensional Encoding. NeurIPS37 (2024), 101042–101073. [37] Aamod Khatiwada, Grace Fan, Roee Shraga, Zixuan Chen, Wolfgang Gatter- bauer, Renée J Miller, and Mirek Riedewald. 2023. SANTOS: Relationship-based semantic table union search.SIGMOD1, 1 (2023), 1–25. [38] Aamod Khatiwada, Harsha Kokel, Ibrahim Abdelaziz, Subhajit Chaudhury, Ju- lian Dolby, Oktie Hassanzadeh, Zhenhan Huang, Tejaswini Pedapati, Horst Samulowitz, and Kavitha Srinivas. 2025. Tabsketchfm: Sketch-based tabular representation learning for data discovery over data lakes. InICDE. 1523–1536. [39]Omar Khattab and Matei Zaharia. 2020. Colbert: Efficient and effective passage search via contextualized late interaction over bert. InSIGIR. 39–48. [40] Harsha Kokel, Aamod Khatiwada, Tejaswini Pedapati, Haritha Ananthakrishnan, Oktie Hassanzadeh, Horst Samulowitz, and Kavitha Srinivas. 2025. Evaluating Joinable Column Discovery Approaches for Context-Aware Search.arXiv preprint arXiv:2510.24599(2025). [41] Harsha Kokel, Aamod Khatiwada, Tejaswini Pedapati, Haritha Ananthakr- ishnan, Oktie Hassanzadeh, Horst Samulowitz, and Kavitha Srinivas. 2025. TOPJoin: A Context-Aware Multi-Criteria Approach for Joinable Column Search. arXiv:2507.11505 [cs.DB] [42] Christos Koutras and Juliana Freire. 2026. StraTyper: Automated Semantic Type Discovery and Multi-Type Annotation for Dataset Collections.arXiv preprint arXiv:2602.04004(2026). [43] Christos Koutras, Jiani Zhang, Xiao Qin, Chuan Lei, Vassilis N Ioannidis, Christos Faloutsos, George Karypis, and Asterios Katsifodimos. 2025. OmniMatch: Join- ability discovery in data products.Proc. VLDB Endow.18, 11 (2025), 4588–4601. [44]Aditya Kusupati, Gantavya Bhatt, Aniket Rege, Matthew Wallingford, Aditya Sinha, Vivek Ramanujan, William Howard-Snyder, Kaifeng Chen, Sham Kakade, Prateek Jain, and Ali Farhadi. 2024. Matryoshka Representation Learning. arXiv:2205.13147 [cs.LG] [45] Facebook AI Research Lab. 2015. fastText: Library for fast text representation and classification. (2015). https://fasttext.c/ [46] Jens Lehmann, Robert Isele, Max Jakob, Anja Jentzsch, Dimitris Kontokostas, Pablo N Mendes, Sebastian Hellmann, Mohamed Morsey, Patrick Van Kleef, Sören Auer, et al .2015. Dbpedia–a large-scale, multilingual knowledge base extracted from wikipedia.Semantic web6, 2 (2015), 167–195. [47] Oliver Lehmberg, Dominique Ritze, Robert Meusel, and Christian Bizer. 2016. A Large Public Corpus of Web Tables containing Time and Context Metadata. In W. 75–76. [48] Peng Li, Xiang Cheng, Xu Chu, Yeye He, and Surajit Chaudhuri. 2021. Auto- fuzzyjoin: Auto-program fuzzy similarity joins without labeled examples. In SIGMOD. 1064–1076. [49] Shiyuan Liu, Jianwei Wang, Xuemin Lin, Lu Qin, Wenjie Zhang, and Ying Zhang. 2026. HyperJoin: LLM-augmented Hypergraph Link Prediction for Joinable Table Discovery.arXiv preprint arXiv:2601.01015(2026). [50] Marc Maynou, Sergi Nadal, Raquel Panadero, Javier Flores, Oscar Romero, and Anna Queralt. 2026. FREYJA: Efficient join discovery in data lakes.IEEE Trans. Knowl. Data Eng.38 (2026), 1–12. [51] Leland McInnes, John Healy, Nathaniel Saul, and Lukas Großberger. 2018. UMAP: Uniform Manifold Approximation and Projection.Journal of Open Source Software 3, 29 (2018), 861. https://doi.org/10.21105/joss.00861 [52] Renée J. Miller. 2018. Open Data Integration.Proc. VLDB Endow.11, 12 (2018), 2130–2139. [53] Renée J. Miller, Fatemeh Nargesian, Erkang Zhu, Christina Christodoulakis, Ken Q. Pu, and Periklis Andritsos. 2018. Making Open Data Transparent: Data Discovery on Open Data.IEEE Data Eng. Bull.41, 2 (2018), 59–70. [54] Pranay Mundra, Jianhao Zhang, Fatemeh Nargesian, and Nikolaus Augsten. 2023. Koios: Top-k semantic overlap set search. InICDE. 1531–1543. [55] Fatemeh Nargesian, Ken Q. Pu, Bahar Ghadiri Bashardoost, Erkang Zhu, and Renée J. Miller. 2023. Data Lake Organization.IEEE Trans. Knowl. Data Eng.35, 1 (2023), 237–250. [56] Fatemeh Nargesian, Ken Q. Pu, Erkang Zhu, Bahar Ghadiri Bashardoost, and Renée J. Miller. 2020. Organizing Data Lakes for Navigation. InSIGMOD. 1939– 1950. [57] Fatemeh Nargesian, Erkang Zhu, Renée J. Miller, Ken Q. Pu, and Patricia C. Arocena. 2019. Data Lake Management: Challenges and Opportunities.Proc. VLDB Endow.12, 12 (2019), 1986–1989. [58] Fatemeh Nargesian, Erkang Zhu, Ken Q. Pu, and Renée J. Miller. 2018. Table Union Search on Open Data.Proc. VLDB Endow.11, 7 (2018), 813–825. [59] Arash Dargahi Nobari and Davood Rafiei. 2022. Efficiently transforming tables for joinability. InICDE. 1649–1661. [60] OpenAI. 2026. GPT-5.5. https://developers.openai.com/api/docs/models/gpt-5.5. [61]Paul Ouellette, Aidan Sciortino, Fatemeh Nargesian, Bahar Ghadiri Bashardoost, Erkang Zhu, Ken Pu, and Renée J. Miller. 2021. RONIN: Data Lake Exploration. Proc. VLDB Endow.14, 12 (2021), 2863–2866. [62] Fabian Pedregosa, Gaël Varoquaux, Alexandre Gramfort, Vincent Michel, Bertrand Thirion, Olivier Grisel, Mathieu Blondel, Andreas Müller, Joel Nothman, Gilles Louppe, Peter Prettenhofer, Ron Weiss, Vincent Dubourg, Jake Vander- plas, Alexandre Passos, David Cournapeau, Matthieu Brucher, Matthieu Per- rot, and Édouard Duchesnay. 2018. Scikit-learn: Machine Learning in Python. arXiv:1201.0490 [cs.LG] [63] D. Ritze, O. Lehmberg, R. Meusel, C. Bizer, and S. Zope. 2015. WDC Web Table Cor- pus. http://webdatacommons.org/webtables/2015/downloadInstructions.html [64] Aécio Santos, Aline Bessa, Fernando Chirigati, Christopher Musco, and Juliana Freire. 2021. Correlation sketches for approximate join-correlation queries. In SIGMOD. 1531–1544. [65] Aécio S. R. Santos, Aline Bessa, Christopher Musco, and Juliana Freire. 2022. A Sketch-based Index for Correlated Dataset Search. InICDE. 2928–2941. [66] Aécio S. R. Santos, Flip Korn, and Juliana Freire. 2024. Efficiently Estimating Mutual Information Between Attributes Across Tables. InICDE. 193–206. [67] Anish Das Sarma, Lujun Fang, Nitin Gupta, Alon Y. Halevy, Hongrae Lee, Fei Wu, Reynold Xin, and Cong Yu. 2012. Finding related tables. InSIGMOD. 817–828. [68] Kaitao Song, Xu Tan, Tao Qin, Jianfeng Lu, and Tie-Yan Liu. 2020. Mpnet: Masked and permuted pre-training for language understanding.NeurIPS33 (2020), 16857–16867. [69] Henrique Schechter Vera, Sahil Dua, Biao Zhang, Daniel Salz, Ryan Mullins, Sindhu Raghuram Panyam, Sara Smoot, Iftekhar Naim, Joe Zou, Feiyang Chen, et al.2025. Embeddinggemma: Powerful and lightweight text representations. arXiv preprint arXiv:2509.20354(2025). [70] WDC. [n.d.]. http://webdatacommons.org/webtables/goldstandard.html, last accessed on Feb 15, 2026. [71] Shitao Xiao, Zheng Liu, Peitian Zhang, and Niklas Muennighoff. 2023. C-Pack: Packaged Resources To Advance General Chinese Embedding. arXiv:2309.07597 [cs.CL] [72] Haoxiang Zhang, Yurong Liu, Aécio Santos, Wei-Lun (Allen) Hung, and Juliana Freire. 2026. AutoDDG: Automated Dataset Description Generation using Large Language Models.Proc. ACM Manag. Data4, 1, Article 12 (April 2026), 27 pages. https://doi.org/10.1145/3786626 [73] Zixuan Zhao and Raul Castro Fernandez. 2022. Leva: Boosting Machine Learning Performance with Relational Embedding Data Augmentation. InSIGMOD. 1504– 1517. [74] Erkang Zhu, Dong Deng, Fatemeh Nargesian, and Renée J. Miller. 2019. JOSIE: Overlap Set Similarity Search for Finding Joinable Tables in Data Lakes. In SIGMOD. 847–864. [75] Erkang Zhu, Yeye He, and Surajit Chaudhuri. 2017. Auto-join: Joining tables by leveraging transformations.Proc. VLDB Endow.10, 10 (2017), 1034–1045. [76] Erkang Zhu, Fatemeh Nargesian, Ken Q. Pu, and Renée J. Miller. 2016. LSH Ensemble: Internet-Scale Domain Search.Proc. VLDB Endow.9, 12 (2016), 1185– 1196.