PaperlayerView exact revision on arXiv

Source-linked AI summary

PEARL: Front-Loading Relational Chains for Multi-Hop Table Retrieval

Subeen Ho, Hyeongu Kang, SeongKu Kang, Susik Yoon

arXiv:2608.30291v1cs.IR

TL;DR

Table retrieval remains difficult when queries require reasoning across fragmented, heterogeneous tables and whole-table representations overlook cross-table join semantics. PEARL precomputes join-aware, vertically partitioned corpus units offline, avoiding query-time LLM inference. Across multi-hop benchmarks, it improves retrieval while reducing online latency and token consumption, subject to a maximum join-path length and larger index footprint.

  • Problem

    Existing retrieval methods struggle to capture fine-grained relevance and latent join relationships across heterogeneous tables, especially for multi-hop queries.

  • Method

    PEARL discovers multi-hop join paths, generates schema-aware queries, and reorganizes relevant columns into vertically partitioned sub-table units during offline indexing.

  • Results

    PEARL outperforms the strongest baseline by 5.84% on average on Recall@k, reaches up to 30.05% gains for 3-hop queries, and reduces total latency by up to 79%.

  • Takeaways & Limitations

    Join-aware augmentation improves multi-hop retrieval beyond simple corpus enlargement while enabling standard dense retrieval without online LLM inference.

  • Takeaways & Limitations

    PEARL currently limits join paths to a maximum length of three, while its additional corpus units increase index size and may challenge memory-constrained deployments.

Abstract

from arXiv · show

While large language models (LLMs) have shown strong capabilities in tabular reasoning, retrieving relevant tables remains challenging due to the fragmented and relational structure of real-world data. Existing work typically relies on whole table representations that overlook cross-table semantics induced by join relationships. We propose PEARL, a training-free framework that shifts the paradigm toward vertical partitioning-based sub-table encoding. PEARL augments the retrieval corpus offline by generating multi-hop queries over pre-identified join paths and reorganizing relevant columns into vertically partitioned corpus units, enabling effective multi-table retrieval without query-time LLM inference. Experiments show that PEARL consistently outperforms existing methods, with up to +30.05% gains in R@2 on 3-hop queries. The source code is available at https://github.com/SOOB2NHO/PEARL.

1 Introduction

Real-world table retrieval is difficult because heterogeneous data requires multi-hop reasoning across tables, while whole-table indexing mixes relevant and irrelevant columns. PEARL addresses this by moving join-aware reasoning into offline, vertically partitioned indexing and reports consistent retrieval and efficiency gains.

  • Table retrieval is a critical bottleneck because real-world data is scattered across heterogeneous tables, making fine-grained query–table relevance difficult to capture.
  • Multi-hop queries expose implicit or deeply nested tables that whole-table embeddings struggle to identify because irrelevant columns obscure latent join relationships.
  • Inference-time query decomposition and iterative reasoning can alleviate retrieval difficulties but become computationally impractical as tables and query volumes scale.
  • PEARL front-loads recurring online computation into offline indexing by using LLMs to synthesize schema-aware, vertically partitioned sub-tables along multi-hop join paths.
  • 5.84% average Recall@k improvement over the strongest baseline and up to 30.05% gain for 3-hop queries were observed across three multi-hop retrieval benchmarks.

2 Preliminary

Multi-hop table retrieval targets tables connected through explicit or implicit join relationships. Explicit joins are schema-grounded, whereas implicit joins are latent relationships inferred from table values or semantics.

  • Multi-hop table retrieval identifies the tables needed to answer a query when they are connected through explicit or implicit relationships.
  • Explicit joins are structurally declared or strongly implied by schema evidence such as shared column names or high value containment.
  • Implicit joins connect columns referring to the same real-world entity without declared constraints and require value-level or semantic similarity to identify.

3 Methodology

PEARL builds join-aware retrieval units offline by discovering multi-hop paths, generating schema-aware queries, and vertically partitioning relevant columns. Online retrieval then matches queries against precomputed embeddings without additional LLM inference.

  • Pipeline: PEARL uses a two-stage pipeline: Offline Indexing constructs join-aware representations, while Online Retrieval matches queries against them.The framework is designed for standard dense retrieval without additional training or online LLM inference.
  • Join Path Discovery: Join Path Discovery constructs column and value indexes, discovers candidate edges, builds explicit or implicit paths, and selects diverse paths using Lazy Greedy.Candidate edges use structural patterns, column similarity, and cell-value overlap; path scores combine structural, semantic, and overlap signals according to edge type.
  • Instructional Query Generation: For each selected path, an LLM generates a query requiring every table and identifies the minimal columns needed to answer it.The generation process uses the full path structure and sampled rows from its tables, with removing any path table making the query unanswerable.
  • Vertical Partitioning and Indexing: Vertical partitioning projects each path table onto its query-relevant columns, producing query-conditioned sub-tables that reduce dilution from irrelevant wide-table columns.Implicit paths create independently indexed projected entries, whereas explicit paths combine projected tables into one multi-table representation.
  • Online Retrieval: At query time, PEARL max-pools similarity over implicit, explicit, and original-table embeddings, then returns the top-k tables.All embeddings are stored offline, enabling efficient approximate-nearest-neighbor retrieval without schema annotations or online reasoning.

4 Experiments

Experiments show that PEARL improves multi-hop table retrieval, especially for deeper join chains, while reducing online latency and token consumption through offline augmentation. Ablations indicate that join-aware vertical partitioning—not corpus expansion alone—drives the gains.

  • Overall Performance Results: PEARL outperforms the strongest baseline by 3.46% on SPIDER and 9.37% on MMQA under the unified setting, with minor BIRD fluctuations.
  • Ablation Study: PEARL improves over Stella-v5 by 6.77% on SPIDER, 10.81% on MMQA, and 10.39% on BIRD in R@2, isolating the effect of vertical partitioning.
  • Overall Performance Results: 30.05%, 22.81%, and 8.97% R@2 gains over the strongest baseline occur on SPIDER, MMQA, and BIRD, respectively, for 3-hop queries.
  • Efficiency: PEARL reduces online latency by over 99% across all datasets and achieves 62–79% total latency reduction at full query volume.Break-even occurs after processing 22–35% of the incoming query workload.
  • Efficiency: PEARL reduces total LLM token consumption by 4.1× relative to Greedy-JAR while maintaining higher retrieval performance.
  • Ablation Study: Comparable-size Random-view and more aggressively expanded Random-query underperform PEARL, showing that join-aware organization matters more than corpus expansion or semantic diversity alone.PEARL exceeds Random-query by 6.12%, 7.04%, and 7.14% on SPIDER, MMQA, and BIRD R@2, respectively.
  • Ablation Study: Explicit and implicit join representations provide complementary signals: removing either component degrades performance, while explicit-only variants outperform implicit-only variants.The explicit-only advantage is 4.65% on SPIDER, 6.29% on MMQA, and 6.37% on BIRD.
  • Sensitivity Analysis: The first half of sampled join paths provides the largest marginal R@2 gains, after which benefits decline toward saturation; λdiv effects vary by benchmark.MMQA benefits from higher diversity, BIRD declines at higher values, and SPIDER remains relatively insensitive.

5 Related Work

Related work on multi-hop table retrieval divides into explicit join modeling and implicit semantic alignment. Explicit methods exploit schemas but often encode whole tables, while implicit methods address incomplete structure through semantic matching or query-time reasoning.

  • Multi-hop table retrieval requires jointly retrieving multiple related tables, with explicit and implicit join relationships forming the main distinction among methods.
  • Explicit Join Modeling: Explicit join methods use metadata, foreign keys, and schema consistency to identify related tables or candidate joins before downstream reasoning.
  • Explicit Join Modeling: Whole-table encoding in explicit approaches can exceed LLM context limits in large, heterogeneous data lakes.
  • Implicit Join Alignment: Implicit join alignment uses semantic similarities or LLM reasoning when structural information is incomplete or unavailable, including dynamically explored retrieval paths.

6 Conclusion

PEARL bridges tables and multi-hop queries with a join-aware corpus, enabling standard embedding models to retrieve multi-hop evidence without online LLM reasoning. Across SPIDER, BIRD, and MMQA, it improves retrieval while substantially reducing latency and token use.

  • PEARL constructs a join-aware corpus using implicit sub-table views and explicit joined entries for related table pairs.
  • PEARL enables standard embedding models to retrieve multi-hop evidence without online LLM involvement or iterative query decomposition.
  • PEARL consistently improves retrieval performance on SPIDER, BIRD, and MMQA beyond simple corpus augmentation.
  • PEARL reduces online latency by over 99% and total latency by up to 79%.
  • PEARL cuts token consumption by up to 4.1× on average compared to Greedy-JAR, with efficiency advantages growing as query volume scales.

Limitations

PEARL’s current scope is constrained by path length, benchmark-only evaluation, index growth, and reliance on offline precomputation. The authors identify longer chains, real-world validation, storage trade-offs, evolving corpora, and hybrid indexing as open directions.

  • PEARL restricts join paths to a maximum length of three, while real-world settings may contain longer dependency chains.
  • Evaluation is limited to academic benchmarks, leaving practical applicability and robustness in domain-specific deployment settings for future study.
  • PEARL maintains a larger index than whole-table retrieval because each selected join path adds corpus units.
  • Memory-constrained deployments may require a smaller corpus budget, creating a storage-efficiency versus retrieval-effectiveness trade-off.
  • PEARL precomputes selected paths before deployment, motivating hybrid workflows that resolve lower-value paths at query time.

A.2 LLM Reasoning on Tabular Data

PEARL addresses the computational and semantic limitations of table retrieval by constructing join paths offline, generating schema-aware queries, and indexing vertically partitioned sub-tables. Its path design covers explicit, implicit, and mixed relational patterns while prioritizing join-relevant rows under input limits.

  • Motivation: Repeated online LLM inference makes fine-grained table retrieval computationally expensive for latency-sensitive applications.
  • Motivation: Offline synthetic-query methods still struggle with irrelevant-column noise and remain limited to single-table retrieval.
  • Offline pipeline: PEARL’s offline indexing pipeline discovers join paths, generates instructional queries, vertically partitions tables, and indexes the resulting units.
  • Join discovery: Candidate join edges combine value overlap, structural naming patterns, and column similarity signals.
  • Path construction: PEARL generates 2-hop and 3-hop paths, supporting explicit-only, implicit-only, and mixed explicit–implicit connectivity patterns.
  • Vertical partitioning: Rows matching join-column overlap are moved first, and the first ten reordered rows are serialized for query generation and encoding.

B.3 Implementation Details of Random-View Augmentation

The random-view baseline controls for corpus expansion by using randomly projected sub-tables, while PEARL evaluates join-aware units with metrics that account for tables recovered inside retrieved paths. Its scoring and encoding choices preserve individual table evidence rather than requiring one coherent path.

  • Random-view augmentation: The Random-view baseline replaces PEARL’s join-aware entries with randomly projected sub-tables and matches PEARL’s augmented corpus size.
  • Evaluation units: PEARL’s augmented corpus contains original entries, implicit sub-entries, and explicit joined entries.
  • Evaluation units: Joined entries can inflate standard recall because one retrieved unit may contain multiple gold tables.
  • Adjusted recall: Slot R@k re-ranks tables within the top-k retrieved units using individual sub-table similarity and tests whether all gold tables appear in the re-ranked set.
  • Max-pooling: PEARL uses max-pooling across indexed views, retaining each table’s best matching view without enforcing a single coherent join path.
  • Asymmetric encoding: Asymmetric encoding joins explicit paths but encodes implicit-path sub-tables independently, using a shared generated query as semantic context.
  • Asymmetric encoding: Encoding implicit paths as joined entries improves standard R@2 but underperforms under Slot R@2, favoring separate encoding for the retrieval objective.

C.2 Evaluation on Join Path Discovery and Query Coverage

PEARL’s join-path analysis finds that retrieval value does not require agreement with query-specific gold paths, but does depend on meaningful relational structure. Generated queries also cover real query intents substantially better than random matching while rarely duplicating test queries.

  • Join Path Quality: Join Path Discovery achieves F1 scores of 0.61 on SPIDER, 0.38 on MMQA, and 0.39 on BIRD against gold paths.Gold paths represent paths required by observed queries, whereas discovery identifies a broader path set without future-query access.
  • Join Path Quality: On SPIDER, PEARL outperforms an oracle indexing only gold paths, while the oracle performs better on MMQA and BIRD.This shows gold-path agreement is not equivalent to retrieval optimality and leaves room for improved path discovery.
  • Join Path Quality: PEARL performance decreases monotonically as discovered paths are corrupted and falls below the base encoder at 100% corruption.At 50% corruption, PEARL still outperforms the base encoder on all three benchmarks.
  • Join Path Quality: Implicit paths receive a higher share of nearest generated queries than their prevalence in the generated query pool, particularly on BIRD.The result suggests discovered joins align with real query intents rather than benefiting merely from corpus volume.
  • Query Coverage: Generated-query coverage exceeds random matching by 0.173–0.216 in median cosine similarity across all benchmarks.Nearest-neighbor similarity is higher for 3-hop than 2-hop queries, while fewer than 0.4% of nearest generated queries reach cosine similarity of at least 0.9.
  • Backbone Robustness: Using GPT-4o mini as a common backbone, PEARL achieves gains up to +17.6% on 3-hop SPIDER and +20.63% on 3-hop MMQA.PEARL attains the best BIRD R@5, indicating that gains primarily arise from retrieval architecture rather than backbone strength.

D.2 Analysis of BIRD dataset

BIRD’s small development set gives Jaccard-based methods unusually strong statistical priors, narrowing PEARL’s apparent advantage on 2-hop retrieval. Nevertheless, PEARL remains effective under these priors, while its storage and latency overhead remain predictable.

  • BIRD Dataset Characteristics: PEARL trails GJAR and JAR on BIRD 2-hop R@2 but outperforms both on SPIDER and MMQA.The analysis attributes the BIRD gap to dataset characteristics rather than a general failure of PEARL’s retrieval design.
  • BIRD Dataset Characteristics: 55% of BIRD gold join pairs rank first by Jaccard similarity among intra-database table pairs.BIRD’s development set contains only 75 tables, making exhaustive offline Jaccard computation practical and highly reliable.
  • BIRD Dataset Characteristics: PEARL improves over the Stella-v5 baseline in slot-level recall on BIRD despite strong statistical priors favoring Jaccard-based methods.This indicates join-aware offline indexing remains effective in the BIRD setting.
  • Scope Boundary: The authors state that BIRD may underestimate PEARL’s benefit relative to realistic large-scale settings and leave detailed large-scale investigation for future work.MMQA shows stronger performance and better reflects complex multi-hop retrieval scenarios than BIRD and SPIDER.
  • Efficiency: Corpus expansion remains approximately 2.4× across benchmarks, while MMQA requires only a 5.44 MB index and ANN search stays below 32 ms.The expanded MMQA index is roughly 3 MB larger than whole-table indexing.
  • Efficiency: Increasing K from 0.25|C| to 1.00|C| raises online latency by less than twofold across all three benchmarks.The overhead is incurred primarily in storage, which scales predictably with |C|, rather than online latency.

E.3 Experimental Results

In single-hop retrieval, PEARL combines vertically partitioned sub-tables with instructional-query augmentation to improve representation quality. Its gains are strongest on wide tables, persist across ablations, and increase with query diversity.

  • Retrieval Results: PEARL consistently outperforms all baselines in R@1 and R@5 on FeTaQA.On FeTaQA tables with at least 11 columns, it achieves a 20.9% or 8.1 percentage-point R@5 gain over the strongest baseline.
  • Retrieval Results: Vertical partitioning improves retrieval on wide tables by pruning irrelevant columns and reducing information dilution.PEARL constructs semantically salient sub-table fragments aligned with downstream queries.
  • Ablation Analysis: PEARL outperforms variants using only sub-tables, augmented queries, or query-header combinations.The combined representation performs better across wide-table and multi-hop scenarios, indicating synergy between partitioning and query-conditioned encoding.
  • Sensitivity Analysis: With N = 1, PEARL already outperforms the baseline in R@5, and performance improves consistently as N increases.The analysis associates more diverse instructional queries with broader coverage of potential user intents.
  • Prompt Design: Implicit 2-hop prompts enforce value-based entity alignment and require a complex question to characterize a two-table semantic connection.Implicit 3-hop prompts treat the intermediate table as a value-based bridge in a semantic chain.
  • Prompt Design: Explicit multi-hop prompts align semantic transitions with foreign-key relationships and require every table in the chain to answer the query.Single-hop prompts instead generate diverse instructional queries over individual tables to enrich their representations.
Loading 2608.30291v1…