PaperlayerView exact revision on arXiv

Source-linked AI summary

LGESQL: Line Graph Enhanced Text-to-SQL Model with Mixed Local and Non-Local Relations

Ruisheng Cao, Lu Chen, Zhi Chen, Yanbin Zhao, Su Zhu, Kai Yu

arXiv:2106.01093v3cs.CL

TL;DR

Text-to-SQL encoders struggle with heterogeneous edge topology and with distinguishing local from non-local relations. LGESQL models edge topology through a line graph, integrates both relation types, and adds graph pruning; it reaches 62.8% with GLOVE and 72.0% with ELECTRA on Spider.

  • Problem

    Heterogeneous text-to-SQL graph encoders may overlook edge-topology semantics and fail to distinguish local from non-local relations.

  • Method

    LGESQL constructs an edge-centric line graph, jointly updates original and line-graph representations, and adds graph pruning to classify schema-node relevance.

  • Results

    62.8% exact set match accuracy with GLOVE and 72.0% with ELECTRA were achieved on the Spider benchmark.

  • Takeaways & Limitations

    Line-graph edge modeling and graph pruning provide the proposed encoder with a way to learn local, non-local, and relationally relevant schema features.

  • Takeaways & Limitations

    The authors leave investigating more useful meta-paths and more effective handling of different meta-path-based neighbors for future work.

Abstract

from arXiv · show

This work aims to tackle the challenging heterogeneous graph encoding problem in the text-to-SQL task. Previous methods are typically node-centric and merely utilize different weight matrices to parameterize edge types, which 1) ignore the rich semantics embedded in the topological structure of edges, and 2) fail to distinguish local and non-local relations for each node. To this end, we propose a Line Graph Enhanced Text-to-SQL (LGESQL) model to mine the underlying relational features without constructing meta-paths. By virtue of the line graph, messages propagate more efficiently through not only connections between nodes, but also the topology of directed edges. Furthermore, both local and non-local relations are integrated distinctively during the graph iteration. We also design an auxiliary task called graph pruning to improve the discriminative capability of the encoder. Our framework achieves state-of-the-art results (62.8% with Glove, 72.0% with Electra) on the cross-domain text-to-SQL benchmark Spider at the time of writing.

1 Introduction

LGESQL addresses heterogeneous graph encoding in text-to-SQL by modeling edge topology and distinguishing local from non-local relations. It adds graph pruning and achieves state-of-the-art Spider results with and without pretrained language models.

  • Text-to-SQL converts a natural-language question and database schema into a SQL query, requiring joint encoding of heterogeneous inputs and their relations.
  • Previous methods use fixed-size edge parameters that may ignore contextualized edge topology and fail to discover useful meta-paths.
  • Treating local and multi-hop relations alike can make nodes attend equally to distant nodes, potentially causing over-smoothing.
  • LGESQL constructs a line graph to model edge topology, combining dynamically provided local edge features with parameterized non-local features during graph iteration.
  • 62.8% exact set match accuracy with GLOVE and 72.0% with a pretrained language model were achieved on Spider.
  • Graph pruning classifies schema nodes by relevance to the question, while the model targets extraction of schema items related to the target query.

2 Preliminaries

The preliminaries define the heterogeneous node-centric graph, meta-path relations, and line-graph construction used by LGESQL. Local original-graph relations become line-graph nodes, while shared endpoints define line-graph connectivity without backtracking.

  • The input graph contains QUESTION, TABLE, and COLUMN nodes, with its node count equal to the sum of their respective counts.
  • A meta-path is a composite relation formed by consecutive compatible relations; local relations have path length 1, while non-local relations are longer.
  • The line graph represents selected original-graph edges as vertices, allowing edge-topology information to be modeled explicitly.
  • Two line-graph vertices are connected when their corresponding directed original edges meet at the required shared node, capturing information flow along meta-paths.
  • Reverse-edge pairs are excluded from line-graph connectivity to prevent backtracking, and only local original-graph relations are used as line-graph vertices.
  • Figure 2 illustrates the line-graph construction by simplifying edge notation and showing how an original-graph node represents a line-graph edge.

3 Method

LGESQL encodes a heterogeneous text-to-SQL graph with both node-centric and edge-centric representations, using dual graph attention to model local and non-local relations. Its encoder feeds a grammar-based SQL decoder and an auxiliary graph-pruning task.

  • 3 Method: LGESQL uses a classic encoder-decoder backbone with graph input, line-graph-enhanced hidden, and graph output modules.The encoder maps the heterogeneous graph into node embeddings, while the output module transforms them into the target SQL query.
  • 3 Method: The graph input module initializes edge features from parameters and node representations from GloVe or pretrained language models.GloVe representations are contextualized with type-specific BiLSTMs; PLM representations use subword attentive pooling before graph encoding.
  • 3.2 Line Graph Enhanced Hidden Module: Dual RGAT layers jointly update the original graph and its line graph, using node embeddings in one graph as edge features in the other.This couples topology over nodes with topology over directed edges during iterative message passing.
  • 3.2.1 RGAT for the Original Graph: The RGAT module distinguishes local and non-local relations and manipulates local edge features more carefully.The model supports mixed static and dynamic embeddings and multi-head views with different neighborhood scopes.
  • 3.3 Graph Output Module: The graph output module combines grammar-based AST decoding for SQL generation with an auxiliary graph-pruning task.The decoder emits APPLYRULE, SELECTTABLE, or SELECTCOLUMN actions, while graph pruning classifies schema-node relevance to the question and sparse schema structure.

4 Experiments

Experiments on Spider evaluate LGESQL’s benchmark performance, component contributions, pretrained language models, and qualitative behavior. LGESQL achieves state-of-the-art results and improves handling of difficult multi-table queries.

  • 4.1 Experiment Setup: Spider is a large-scale cross-domain zero-shot benchmark with 8,659 training examples across 146 databases and 2,147 test samples from 40 unseen databases.Evaluation reports exact set match accuracy; the test set is evaluated through challenge submission because it is not public.
  • 4.2 Main Results: LGESQL achieves state-of-the-art test results across configurations, improving GLOVE accuracy from 57.2% to 62.8% and reaching 68.3% with bert-large-wwm and 72.0% with ELECTRA.The reported GLOVE gain is 5.6 percentage points.
  • 4.2 Main Results: LGESQL surpasses RATSQL across all difficulty subdivisions on both validation and test datasets, especially at the Medium and Extra Hard levels.The comparison is reported regardless of whether a pretrained language model is used.
  • 4.3.1 Different Components of LGESQL: Removing non-local relations decreases performance by roughly 2 points in LGESQL and 3 points in RGATSQL, while LGESQL with only local relations remains competitive.The ablation is interpreted as evidence that line-graph structure can capture some long-range relations.
  • 4.3.1 Different Components of LGESQL: Graph pruning contributes +1.2% in LGESQL versus +0.7% in RGATSQL, while MSDE and MMC provide gains of 2.0% and 2.1%, respectively.The results support distinguishing local from non-local relations and indicate that local relations are important for structural inference.
  • 4.3.2 Pre-trained Language Models: LGESQL outperforms RGATSQL with different pretrained language models, while larger models and task-adaptive ELECTRA generally outperform base models and vanilla BERT.The authors relate ELECTRA’s advantage to its binary word-substitution discrimination task, which resembles graph pruning.
  • 4.3.3 Case Study: In qualitative cases involving joins across multiple tables, LGESQL identifies connected schema subgraphs that RGATSQL misses, including the table flights and the template–documents link.The comparison covers generated SQL queries from LGESQL and RGATSQL.

5 Related Work

Related work addresses text-to-SQL encoding through attention, schema linking, database content, and heterogeneous graph networks. LGESQL extends these directions by modeling local and non-local edge features with a line graph.

  • Text-to-SQL Encoding: Prior text-to-SQL systems use column attention, schema-linking and type information, graph neural networks, co-attention, or database content to encode questions and schemas.These methods include Xu et al., TypeSQL, Bogin et al., Chen et al., EditSQL, and BRIDGE.
  • Text-to-SQL Encoding: RATSQL uses a complete relational graph attention network with predefined relations, whereas LGESQL additionally models local and non-local, dynamic and static edge features through a line graph.The distinction targets relational structure among heterogeneous nodes and edges.
  • Heterogeneous Graph Neural Network: Heterogeneous graph methods address multiple node and edge types through type-based encoders, type-specific transformations, and relation-parameterized graph convolutions or attention.The related methods include RGCN, RGAT, and HAN.

6 Conclusion

LGESQL uses a line graph to enrich edge features and capture relational structure for text-to-SQL. The paper identifies future work on more useful meta-paths and better handling of meta-path-based neighbors.

  • Conclusion: Line-graph iteration lets local edges incorporate multi-hop relational features and capture significant meta-paths without relying only on the original graph structure.The model also integrates non-local relations so the encoder can attend to remote nodes through shortcuts.
  • Conclusion: Future work will investigate more useful meta-paths and more effective methods for handling different meta-path-based neighbors.This is stated as an open direction rather than a completed contribution.

A Local and Non-Local Relations

The paper defines local relations as one-hop paths and non-local relations as longer meta-paths. The relation inventory includes both categories, with remaining RATSQL relations treated as non-local for comparison.

  • Relation Definitions: The relational adjacency matrix contains both local and non-local relations, while relations outside the listed local checklist are treated as non-local for fair comparison with RATSQL.The local-relation checklist is only a subset of RATSQL’s complete relation set.

B.1 ASDL Grammar

The ASDL grammar converts SQL into short action sequences while reusing types hierarchically and enumerating list sizes. It covers 98.7% of training cases and 98.2% of validation cases.

  • ASDL Grammar: The grammar translates each target SQL query into a sequence of actions that constructs its abstract syntax tree.The complete grammar is provided in Figure 8.
  • ASDL Grammar: Shorter action sequences are designed to reduce long-term forgetting in the autoregressive decoder by removing optional operators and enumerating constructors.SQL-unit solutions are expanded according to the existence of different clauses.
  • ASDL Grammar: Hierarchical type reuse supports parameter sharing across clauses, including shared column and value types.The same col unit type is used for columns in different clauses, while val unit serves SELECT and CONDITION clauses.
  • ASDL Grammar: For same-type item lists, the grammar enumerates possible occurrence counts instead of using a termination action.Each item is then generated under this quantitative limitation.
  • ASDL Grammar: 98.7% of training cases and 98.2% of validation cases are covered by the grammar.

B.2 Decoder Architecture

The decoder autoregressively constructs SQL abstract syntax trees from encoded question, table, and column memory. It uses a structured ON-LSTM, attention over memory, and action-specific prediction or copying mechanisms.

  • Decoder Architecture: The decoder produces actions that construct the target SQL abstract syntax tree from encoded question, table, and column memory.The memory is X = [Xq; Xt; Xc], and a single-layer ON-LSTM is used as the autoregressive decoder.
  • Decoder Architecture: The initial decoder state is obtained by attentive pooling over the encoded memory.The initialization uses trainable parameters v0, W0, and W1.
  • Decoder Architecture: At each timestep, the structured ON-LSTM updates its hidden state using previous-action, parent-action, parent-state, and frontier-node-type information.The frontier node is the current non-terminal AST node being expanded.
  • Decoder Architecture: Eight-head attention computes a context vector over memory, which is combined with the decoder state and passed through a two-layer tanh MLP.The resulting attention vector has dimension 512.
  • Decoder Architecture: APPLYRULE actions use a softmax classification layer, while SELECTTABLE and SELECTCOLUMN actions retrieve schema items through attention-based mechanisms.SELECTTABLE directly copies a table from encoded table memory; SELECTCOLUMN uses analogous parameters.

C Graph Pruning

Graph pruning is trained as an auxiliary binary discrimination task, rather than as a cascaded prerequisite for decoding. Preliminary comparisons report that multitasking avoids the training-inference inconsistency observed in cascaded pruning.

  • Graph Pruning: The graph-pruning task predicts binary labels for schema items, leaving the encoder responsible for discrimination and the decoder responsible for organizing the semantic frame.This simplifies the target compared with multi-class syntactic-role classification.
  • Graph Pruning: Unlike cascaded approaches that feed pruning relevance scores or pruned graphs into encoding, graph pruning is used in a multitasking manner.The comparison includes a separate encoder for pruning and a refined encoder for the pruned graph and question.
  • Graph Pruning: Cascading pruning into decoder attention creates training-inference inconsistency because training uses gold schema items while evaluation uses predicted pruning options.Sampling-based noise injection produced performance merely competitive with multitasking in pilot experiments.
  • Graph Pruning: The authors therefore treat graph pruning as an auxiliary output module rather than constraining the text-to-SQL decoder to use pruned memory.
Loading 2106.01093v3…