Syntactic Question Abstraction and Retrieval for Data-Scarce Semantic Parsing
Year: 2020

Abstract:
Deep learning approaches to semantic parsing require a large amount of labeled data, but annotating complex logical forms is costly. Here, we propose SYNTACTIC QUESTION ABSTRACTION & RETRIEVAL (SQAR), a method to build a neural semantic parser that translates a natural language (NL) query to a SQL logical form (LF) with less than 1,000 annotated examples. SQAR first retrieves a logical pattern from the train data by computing the similarity between NL queries and then grounds a lexical information on the retrieved pattern in order to generate the final LF. We validate SQAR by training models using various small subsets of WikiSQL train data achieving up to 4.9% higher LF accuracy compared to the previous state-of-the-art models on WikiSQL test set. We also show that by using query-similarity to retrieve logical pattern, SQAR can leverage a paraphrasing dataset achieving up to 5.9% higher LF accuracy compared to the case where SQAR is trained by using only WikiSQL data. In contrast to a simple pattern classification approach, SQAR can generate unseen logical patterns upon the addition of new examples without re-training the model. We also discuss an ideal way to create cost efficient and robust train datasets when the data distribution can be approximated under a data-hungry setting.

text: tating complex logical forms is costly. Here, we propose SYNTACTIC QUESTION ABSTRACTION & RETRIEVAL (SQAR), a method to build a neural semantic parser that translates a natural language (NL) query to a SQL logical form (LF) with less than 1,000 annotated examples. SQAR first retrieves a logical pattern from the train data by computing the similarity between NL queries and then grounds a lexical information on the retrieved pattern in order to generate the final LF. We validate SQAR by training models using various small subsets of WikiSQL train data achieving up to 4.9% higher LF accuracy compared to the previous state-of-the-art models on WikiSQL test set. We also show that by using query-similarity to retrieve logical pattern, SQAR can leverage a paraphrasing dataset achieving up to 5.9% higher LF accuracy compared to the case where SQAR is trained by using only WikiSQL data. In contrast to a simple pattern classification approach, SQAR can generate unseen logical patterns upon the addition of new examples without re-training the model. We also discuss an ideal way to create cost efficient and robust train datasets when the data distribution can be approximated under a data-hungry setting.

heading: 1. Introduction
text: Semantic parsing is the task of translating natural language into machine-understandable formal logical forms. With the help of recent advance in deep learning technology, neural semantic parsers have achieved state-of-the-art results in many tasks [Dong and Lapata, 2016, Jia and Liang, 2016, Iyer et al., 2017b]. However, their training requires the preparation of a large amount of labeled data (questions and corresponding logical forms) which is often not scalable due to the requirement of expert knowledge necessary in writing logical forms.
Here, we develop a novel approach SYNTACTIC QUESTION ABSTRACTION & RETRIEVAL (SQAR) for semantic parsing task under data-hungry setting. The model constrains the logical form search space by retrieving logical patterns from the train set using natural language similarity with assistance of a pre-trained language model. The subsequent grounding module only needs to map the retrieved pattern to the final logical form.
We evaluate SQAR on various subsets of WikiSQL train data [Zhong et al., 2017] consisting of 850∼2750 samples which occupies 1.5–4.9% of the full train data. SQAR shows up to 4.9% higher logical form accuracy compared to the previous best open sourced model SQLOVA [Hwang et al., 2019]. Also, we show that natural language sentence similarity dataset can be leveraged in SQAR by pre-training the backbone of SQAR using Quora pharaphrasing data which results in up to 5.9% higher logical form accuracy.
In general, the retrieval approach causes the limitation on dealing with unseen logical patterns. In contrast, we show that SQAR can generate unseen logical patterns by collecting new examples without re-training opening an interesting possibility of generalizable retrieval-based semantic parser.
Our contributions are summarized as follows:
• Compared to the previous best open-sourced model [Hwang et al., 2019], SQAR achieves the state-of-the-art performance on the WikiSQL test data under data-scarce environment.
• We show that SQAR can leverage natural language query similarity datasets to improve logical form generation accuracy.
• We show that retrieval-based parser can handle unseen new logical patterns on the fly without re-training.
• For the maximum cost-effectiveness, we find that it is important to carefully design the train data distribution, not merely following the (approximated) data distribution.

heading: 2. Related work
text: WikiSQL [Zhong et al., 2017] is a large semantic parsing dataset consisting of 80,654 natural language utterances and corresponding SQL annotations. Its massive size has invoked the development of many neural semantic parsing models [Xu et al., 2017, Yu et al., 2018, Dong and Lapata, 2018, Wang et al., 2017, 2018, McCann et al., 2018, Shi et al., 2018, Yin and Neubig, 2018, Xiong and Sun, 2018, Hwang et al., 2019, He et al., 2019]. Berant and Liang [Berant and Liang, 2014] built the semantic parser that uses the query similarity between an input question and paraphrased canonical natural language representations generated from candidate logical forms. In our study, candidate logical forms and corresponding canonical forms do not need to be generated as input questions are directly compared to the questions in the training data, circumventing the burden of full logical form generation. Dong and Lapata [Dong and Lapata, 2018] developed the two step approach for logical form generation, similar to SQAR using sketch representation as intermediate logical forms. In SQAR, intermediate logical forms are retrieved from train set using question similarity being specialized for data-hungry setting. Finegan-Dollak et al. [Finegan-Dollak et al., 2018] developed the model that first finds corresponding logical pattern and fills the slots in the template. While their work resembles SQAR, there is a fundamental difference between two approaches. The model from [Finegan-Dollak et al., 2018] classifies input query into logical pattern whereas we use query-to-query similarity to retrieve logical pattern non-parametrically. By retrieving logical pattern using the similarity in natural language space, paraphrasing datasets can be employed during training which is relatively easy to label compared to semantic parsing datasets. Also, in contrast to classification methods, SQAR can handle unseen logical patterns by including new examples into the train set without re-training the model during inference stage (see section. 5.5). Also our focus is developing competent model with small amount of data which has not been studied in [Finegan-Dollak et al., 2018]. Hwang et al. [Hwang et al., 2019] developed SQLOVA that achieves state-of-the-arts result in the WikiSQL task. SQLOVA consits of table-aware BERT encoder and NL2SQL module that generate SQL queries via slot-filling approach.

heading: 3. Model
text: The model generates the logical form L (SQL query) for a given NL query Q and its corresponding table headers H (Fig. 1). First, the logical pattern l is retrieved from the train set by finding the most similar NL query with Q. For example in Fig. 1, Q is “What is the points of South Korea player?”. To generate logical form L, SQAR retrieves logical pattern l = SELECT #1 WHERE #2 = #3 by finding the most similar NL query from the train set, for instance [“Which fruit has yellow color?”, SELECT Fruit WHERE Color = Yellow]. Then #1, #2, and #3 in l are grounded to Point, Country, and South Korea respectively by the grounding module using information from Q and table headers. The process is depicted schematically in Fig. 2a. The detail of each step is explained below.

heading: 3.1 Syntactic Question Abstractor
text: The syntactic question abstractor generates two vector representation q and g of an input NL query Q (Fig. 2b). q is trained to represent syntactic information of Q and used in the retriever module (Fig. 2c). g is trained to represent lexical information of Q by being used in the grounder (Fig. 2d).
The logical patterns of the WikiSQL dataset consist of combination of six aggregation operators (none, max, min, count, sum, and avg), and three where operators (=, >, and <). The number of conditions in where clause is ranging from 0 to 4. Each condition is combined by and unit. In total, there are 210 possible SQL patterns (6 select clause patterns × 35 where clause patterns, see Fig. A1). To extract these syntactic information from NL query, both an input NL query Q and the queries in train set {Qt,i} are mapped to a vector space (represented by q and {qt,i}, respectively) via table-aware BERT encoder [Devlin et al., 2018, Hwang et al., 2019] (Fig. 2b). The input of the encoder consists of following tokens:
[CLS], E, [SEP], Q, [SEP], H , [SEP]
where E stands for SQL language element tokens such as [SELECT], [MAX], [COL], · · · ) separated by [SEP] (a special token in BERT), Q represents question tokens, and H denotes the tokens
of table headers in which each header is separated by [SEP]. E is included to contextualize and use them during grounding process (section 3.3). Segment ids are used to distinguish E (id = 0) from Q (id = 1) and H (id = 1) as in BERT [Devlin et al., 2018]. Next, two vectors q ≡ v[CLS]0:dq and g ≡ v[CLS]dq :(dq+2dh) are extracted from the (linearly projected) encoding vector of [CLS] token where i : j notation indicates the elements of vector between ith and jth indices. In this study, dq = 256 and dh = 100.

heading: 3.2 Retriever
text: To retrieve logical pattern of Q, the questions from the train set ({Qt,i}) are also mapped to the vector space ({qt,i}) using the syntactic question abstractor. Next, the logical pattern is found by measuring Euclidean L2 distance between q and {qt,i}.
qt,i∗ = argmin qt,i ||q − qt,i||L2 (1)
Since qt,i∗ has corresponding Qt,i∗ and logical form Lt,i∗ , the logical pattern l∗ can be obtained from Lt,i∗ after delexicalization. The process is depicted in Fig. 2c. In SQAR, maximum 10 closest qt,i∗ are retrieved and the most frequently appearing logical pattern is selected for the subsequent grounding process. SQAR is trained using the negative sampling method. First, one positive sample (having the same logical pattern with input query Q), and 5 negative samples (having different logical pattern) are randomly sampled from the train set. Then six L2 distances are calculated as above and interpreted as approximate probability by using softmax function after multiplied by -1. The cross entropy function is employed for the training.

heading: 3.3 Grounder
text: To ground retrieved logical pattern l∗, following LSTM-based pointer network is used [Vinyals et al., 2015].
Dt = LSTM(Pt−1, (ht−1, ct−1))
h0 = g0:dh c0 = gdh:2dh
st(i) =W(WHi +WDt) pt(i) = softmax st(i),
(2)
where Pt−1 stands for the one-hot vector (pointer to the input token) at time t−1, ht−1 and ct−1 are hidden- and cell-vectors of the LSTM decoder,W’s denote (mutually different) affine transformations, and pt(i) is the probability of observing ith input token at time t. Here dh (=100) is the hidden dimension of the LSTM. Compared to a conventional pointer network, our grounder has three custom properties: (1) as logical pattern is already found from the retriever, the grounder does not feed the output as the next input when the input token is already present in the logical pattern whereas lexical outputs like column and where values are fed into the next step as an input (Fig. 2d); (2) to generate conditional values for where clause, the grounder infers only the beginning and the end token positions from the given question to extract the condition values for where clause; (3) the multiple generation of same column on where clause is avoided by constraining the search space. The syntactic question abstractor, the retriever, and the grounder are together named as SYNTACTIC QUESTION ABSTRACTION & RETRIEVAL (SQAR).

heading: 4. Experiments
text: To train SQAR and SQLOVA, the pytorch version of pre-trained BERT model1 (BERT-Base-Uncased2) is loaded and fine-tuned using ADAM optimizer. The NL query is first tokenized by using Standford CoreNLP [Manning et al., 2014]. Each token is further tokenized (into sub-word level) by WordPiece tokenizer [Devlin et al., 2018, Wu et al., 2016]. FAISS [Johnson et al., 2017] is employed for the retrieval process. For the experiments with Train-Uniform-85P-850, Train-Rand-881, TrainHybrid-85P-897, and Train-Rand-3523, only single logical pattern is retrieved from the retriever due to the scarcity of examples per pattern. Otherwise 10 logical patterns are retrieved. All experiments
1. https://github.com/huggingface/transformers 2. https://github.com/google-research/bert
were performed with WikiSQL ver. 1.1 3. The accuracy is measured by repeating three independent experiments in each condition with different random seeds unless particularly mentioned. To further pre-train BERT-backbone of SQAR, we use Quora paraphrase detection dataset [Iyer et al., 2017a]. The further details of experiments are summarized in Appendix.

heading: 5. Result and Analysis

heading: 5.1 Preparation of data scarce environment
text: The WikiSQL dataset consists of 80,654 examples (56,355 in train set, 8,421 in dev set, and 15,878 in test set). The examples are not uniformly distributed over 210 possible SQL logical patterns in train, dev, and test sets while they have similar logical pattern distributions (see Fig. A1, Table 6). To mimic original pattern distribution while preparing data scarce environemnts, we prepare TrainRand-881 by randomly sampling 881 examples from the original WikiSQL train set (1.6%). The validation set Dev-Rand-132 is prepared by the same way from the WikiSQL dev set.

heading: 5.2 Accuracy Measurement
text: SQAR retrieves SQL logical pattern for a given question Q by finding most syntactically similar question from the train set and ground the retrieved logical pattern using LSTM-based grounder (Fig. 2a). The model performance is tested over the full WikiSQL test set by using two metrics: (1) logical pattern accuracy (P) and (2) logical form accuracy (LF). P is computed by ignoring difference in lexical information such as predicted columns and conditional values whereas LF is calculated by comparing full logical forms. The execution accuracy of SQL query is not compared as different logical forms can generate identical answer hindering fair comparison. Table 1 shows P and LF of several models over the WikiSQL original test set conveying following important messages: (1) SQAR outperforms SQLOVA by +4.0% in LF (3rd and 4th rows); (2) Quora pre-training improves the performance of SQAR further by 0.9% (4th and 5th rows); (3) Under data-scarce condition, the use of pre-trained language model (BERT) is critical (1st and 2nd rows vs 3–5th rows);
It is of note that COARSE2FINE [Dong and Lapata, 2018] shows much lower accuracy compared to SQLOVA-GLOVE although both models use GLoVe [Pennington et al., 2014]. One possible
3. https://github.com/salesforce/WikiSQL
explanation will be that COARSE2FINE first classify SQL patterns of where clause (sketch generation) while SQLOVA generate SQL query via slot-filling approach. The classification involves abstraction of whole sentence and this process can be a data-hungry step.

heading: 5.3 Generalization test I: dependency on logical pattern distribution
text: When the size of train set is fixed, assigning more examples to frequently appearing logical patterns (in test environment) to the train set will increase the chance for correct SQL query generation as trained model would have a higher performance for frequent patterns (Train-Rand-881 is constructed in this regard). On the other hand, including diverse patterns in train set will help the model to distinguish similar patterns. Considering these two aspects, we prepare additional two subsets Train-Uniform-85P-850, and Train-Hybrid-85P-897. Train-Uniform-85P-850 consists of 850 uniformly distributed examples over 85 patterns whereas Dev-Uniform-80P-320 consists of 320 uniformly distributed examples over 80 patterns. Train-Hybrid-85P-897 is prepared by randomly sampling examples from top most frequent 85 logical patterns. Each pattern has approximately 128 times smaller number of examples compared to the full WikiSQL train set as in Train-Rand-881. In addition, all patterns are forced to have at least 7 examples for the diversity (Fig. A1, and Table 6) resulting in total 897 examples. Only 85 patterns out of 210 patterns are considered because (1) 85 patterns occupy 98.6% of full train set, and (2) only these patterns have at least 30 corresponding examples (Fig. A1, Table 6). A dev set Dev-Hybrid-223 is constructed similarly by extracting 223 examples from the WikiSQL dev set (Fig. A1, Table 6). The difference between three types of train sets are shown schematically in Fig. 3 (orange: Train-Uniform-85P-850, purple: Train-Rand-881, black: Train-Hybrid-85P-897).
Table 2 shows following important information: (1) SQAR outperforms SQLOVA again by +4.1% LF in Train-Uniform-85P-850 (3rd and 5th rows of upper panel) and +4.0% LF in TrainHybrid-85P-897 (3rd and 5th rows of bottom panel); (2) the Quora pre-training improves model performance +5.9% LF in Train-Uniform-85P-850 and by +0.5% LF in Train-Hybrid-85P-897(4th and 5th rows of each panel).
Both SQAR and SQLOVA show good performance when they are trained using either TrainRand-881 or Train-Hybrid-85P-897(3rd and 5th columns of Table 1, 2). In real service delivering scenario, the data distribution in test environment could vary with time. In regard of this, we prepare
an additional test set Test-Uniform-81P-648 by extracting 8 examples from top most frequent 81 logical patterns from the WikiSQL test. The resulting test set has completely different logical pattern distribution with the WikiSQL test set. The table 3 shows that both models show best overall performance when they are trained with Train-Hybrid-85P-897 being remained robust to the change of test environment (4th columns). The result highlights the two important properties for train set to have: reflecting test environment (more examples for frequent logical patterns), and including diverse patterns.

heading: 5.4 Generalization test II: dependency on dataset size
text: To further test generality of our findings under change of train set size, we prepare three additional train sets: Train-Uniform-85P-2550, Train-Rand-2677, and Train-Hybrid-96P-2750 (Table 6). Train-Uniform-85P-2550 consists of 2550 uniformly distributed examples over 85 patterns, Train-Rand-2677 consists of 2667 examples randomly sampled from the WikiSQL train data, and Train-Hybrid-96P-2750 is larger version of Train-Hybrid-85P-897 in which each logical pattern includes at least 15 examples for 96 logical patterns (Table. 6). Table 4 shows following information: (1) SQAR shows marginally better performance than SQLOVA showing +1.9%, +0.5%, and -0.7% in LF when Train-Rand-2677, Train-Uniform-85P-2550, and Train-Hybrid-96P-2750 are used as the train sets (1st and 3rd rows of each panel); (2) Again, the pre-training using Quora paraphrasing datset increases LF by +0.5%, +3.3%, and +2.7% in Train-Rand-2677, Train-Uniform-85P-2550, and Train-Hybrid-96P-2750 respectively (2nd and 3th rows of each panel); (3) Both SQAR and SQLOVA show best performance when they are trained over hybrid dataset. Observing that the performance gap between SQAR and SQLOVA becomes marginal as increasing the size of train
set, we train both models using full WikiSQL train set. The result shows that again, there is only marginal difference between two models (SQLOVA LF: 79.2± 0.1, SQAR LF = 78.4± 0.2). The overall results are summarized in Fig. 4.

heading: 5.5 Generalization test III: parsing unseen logical forms
text: In general, retrieval-based approach cannot handle new type of questions when corresponding logical patterns are not presented in the train set. However, unlike simple classification approach [Finegan-Dollak et al., 2018], SQAR has interesting generalization ability originated from the use of query-to-query similarity in natural language space. The train data in SQAR has two roles: (1) supervision examples at training stage, and (2) a database to retrieve the logical pattern (a retrieval set) from which the most similar natural language query will be found during inference stage. Once the model is trained, the second role can be improved by including more examples into the train set
later. Particularly, by adding examples with new logical patterns, the model can handle questions with unseen logical patterns without re-training.
To experimentally show this, we measured P and LF of SQAR while changing the retrieval set during an inference stage (Table. 5). The train set is fixed to Train-Rand-881 consisting of 67 logical patterns. The result shows that upon addition of Train-Hybrid-85P-897 into the template set, which includes 18 more logical patterns compared to Train-Rand-881, P and LF increases by 1.1% and 0.6% respectively (2nd row of the table). Similar results are observed with Train-Hybrid-96P-2750 (+2.0% in P and +0.7% LF, 3rd row of the table) and with Test-Full-15878 (+4.1% in P and +1.7% in LF, 4th row of the table). To further show the power of using query-to-query similarity, we replaced the entire retrieval set from Train-Rand-881 to Train-Hybrid-96P-2750 where only 43 examples are overlapped between them. Again, P and LF increase by 1.7% and 0.5% respectively (5th row of the table). To further confirm the addition of examples enables parsing of unseen logical patterns, we introduce two additional metrics: R-capacity and RG-capacity. R-capacity is defined by the number of successfully retrieved logical pattern types by SQAR in the test set whereas RG-capacity indicates the number of successfully generated (retrieved and grounded) logical pattern types. The table shows both R- and RG-capacities increases upon addition of examples into the retrieval set (5th and 6th columns). It should be emphasized that, during the training stage, SQAR observed only 67 logical patterns. Collectively, these results show that, SQAR can be easily generalized to handle new logical patterns by simply adding new examples without re-training. This also shows the possibility of transfer learning, even between semantic parsing tasks using different logical forms as intermediate logical patterns can be obtained from the natural language space.

heading: 6. Conclusion
text: We found that our retrieval-based model using query-to-query similarity can achieve high performance in WikiSQL semantic parsing task even when labeled data is scarce. We also found, pretraining using natural language paraphrasing data can help generation of logical forms in our querysimilarity-based-retrieval approach. We also show that retrieval-based semantic parser can generate unseen logical forms during training stage. Finally, we found careful design of data distribution is necessary for optimal performance of the model under data-scarce environment.

heading: Appendix A. Appendix
text: A.1 Experiments
A.1.1 MODEL TRAINING
To train SQAR, pre-trained BERT model (BERT-Base-Uncased4) is loaded and fine-tuned using ADAM optimizer with learning rate of 2×10−5 except the grounding module where the learning rate is set to 1× 10−3. The decay rates of ADAM optimizer are set to β1 = 0.9, β2 = 0.999. Batch size is set to 12 for all experiment. SQLOVA is trained similarly using pre-trained BERT model (BERT-Base-Uncased). The learning rate is set to 1 × 10−5 except NL2SQL layer which is trained with the learning rate 10−3. Batch size is set to 32 for all experiment.
Natural language utterance is first tokenized by using Standford CoreNLP [Manning et al., 2014]. Each token is further tokenized (into sub-word level) by WordPiece tokenizer [Devlin et al., 2018, Wu et al., 2016]. The headers of the tables and SQL vocabulary are tokenized by WordPiece tokenizer directly. FAISS [Johnson et al., 2017] is employed for the retrieval process. The PyTorch version of BERT code5 is used. The model performance of COARSE2FINE was calculated by using the code6 published by original authors [Dong and Lapata, 2018]. Our training of COARSE2FINE with the full WikiSQL train data results in 72± 0.3 logical form accuracy on WikiSQL test set.
All experiments were performed with WikiSQL ver. 1.1 7. The model performance of SQAR SQLOVA and COARSE2FINE was measured by repeating three independent experiments in each condition with different random seeds. The errors are estimated by calculating standard deviation. The performance of SQLOVA-GLOVE was measured from two independent experiment with different random seeds. For the experiments with Train-Uniform-85P-850, Train-Rand-881, TrainHybrid-85P-897, and Train-Rand-3523, only single logical pattern is retrieved from the retriever due to the scarcity of examples per pattern. Otherwise 10 logical patterns are retrieved. The models are trained until the logical form accuracy is saturated waiting up to maximum 1000 epochs.
A.1.2 PRE-TRAINING WITH QUORA DATASET
To further pre-trained BERT-backbone used in SQAR, we use Quora paraphrase detection dataset [Iyer et al., 2017a]. The dataset contains more than 405,000 question pairs with a corresponding binary indicator that represents whether two questions are a pair of paraphrase or not. The task setting is analogous to the retriever of SQAR which detects the similarity of two given input NL queries and can be seen as fine-tuning in perspective of paraphrase detection task. During the training, two queries are given to the BERT model along with [CLS] and [SEP] tokens as in the original BERT training setting [Devlin et al., 2018]. The output vector of [CLS] token was used for the binary classification to predict whether given two queries are a paraphrase pair or not. The model was trained until the classification accuracy converges using using ADAM optimizer.
4. https://github.com/google-research/bert 5. https://github.com/huggingface/pytorch-pre-trained-BERT 6. https://github.com/donglixp/coarse2fine 7. https://github.com/salesforce/WikiSQL
101 103 select AVG(#) (210)
select MIN(#) where # > # and # > # and # > # (209) select AVG(#) where # > # and # > # and # < # and # < # (208)
select SUM(#) (207) select MIN(#) where # > # and # > # and # > # and # > # (206)
select MAX(#) where # < # and # < # and # < # and # < # (205) select COUNT(#) where # < # and # < # and # < # and # < # (204)
select AVG(#) where # < # and # < # and # < # and # < # (203) select MAX(#) where # = # and # < # and # < # and # < # (202) select MAX(#) where # > # and # > # and # > # and # > # (201) select SUM(#) where # = # and # < # and # < # and # < # (200) select SUM(#) where # > # and # > # and # > # and # < # (199) select MAX(#) where # > # and # > # and # > # and # < # (198) select MIN(#) where # > # and # < # and # < # and # < # (197)
select MAX(#) where # = # and # = # and # > # and # > # (196) select MIN(#) where # = # and # < # and # < # and # < # (195)
select (#) where # < # and # < # and # < # and # < # (194) select AVG(#) where # = # and # < # and # < # and # < # (193) select MIN(#) where # > # and # > # and # > # and # < # (192)
select (#) where # > # and # < # and # < # and # < # (191) select MAX(#) where # = # and # = # and # = # and # < # (190) select MAX(#) where # = # and # = # and # = # and # = # (189) select AVG(#) where # > # and # > # and # > # and # > # (188)
select (#) where # > # and # > # and # > # and # > # (187) select SUM(#) where # > # and # > # and # > # and # > # (186)
select COUNT(#) where # = # and # = # and # = # and # = # (185) select SUM(#) where # = # and # = # and # = # and # > # (184) select SUM(#) where # = # and # = # and # = # and # = # (183)
select COUNT(#) where # = # and # < # and # < # and # < # (182) select SUM(#) where # < # and # < # and # < # and # < # (181)
select COUNT(#) (180) select COUNT(#) where # > # and # > # and # > # and # > # (179)
select MIN(#) where # < # and # < # and # < # and # < # (178) select SUM(#) where # = # and # > # and # > # and # > # (177) select MAX(#) where # > # and # > # and # < # and # < # (176) select MIN(#) where # = # and # = # and # = # and # > # (175)
select COUNT(#) where # > # and # > # and # > # and # < # (174) select AVG(#) where # = # and # = # and # > # and # > # (173)
select COUNT(#) where # = # and # = # and # = # and # < # (172) select COUNT(#) where # = # and # = # and # = # and # > # (171)
select AVG(#) where # = # and # = # and # = # and # > # (170) select MIN(#) where # > # and # > # and # < # and # < # (169)
select COUNT(#) where # > # and # < # and # < # and # < # (168) select AVG(#) where # = # and # = # and # = # and # < # (167) select SUM(#) where # > # and # > # and # < # and # < # (166)
select (#) where # > # and # > # and # < # and # < # (165) select AVG(#) where # > # and # < # and # < # and # < # (164) select MAX(#) where # = # and # = # and # < # and # < # (163) select MAX(#) where # = # and # = # and # = # and # > # (162) select MIN(#) where # = # and # = # and # > # and # < # (161)
select COUNT(#) where # = # and # > # and # > # and # > # (160) select AVG(#) where # = # and # = # and # < # and # < # (159) select MIN(#) where # = # and # > # and # > # and # > # (158)
select COUNT(#) where # > # and # > # and # < # and # < # (157) select (#) where # = # and # > # and # > # and # > # (156)
select MIN(#) where # = # and # = # and # = # and # < # (155) select AVG(#) where # > # and # > # and # > # and # < # (154) select AVG(#) where # = # and # > # and # > # and # > # (153) select SUM(#) where # = # and # = # and # > # and # > # (152) select MAX(#) where # > # and # < # and # < # and # < # (151)
select (#) where # = # and # < # and # < # and # < # (150) select SUM(#) where # > # and # < # and # < # and # < # (149)
select MAX(#) where # > # and # > # and # > # (148) select SUM(#) where # = # and # = # and # = # and # < # (147)
select (#) where # > # and # > # and # > # and # < # (146) select MIN(#) where # < # and # < # and # < # (145)
select COUNT(#) where # = # and # > # and # > # and # < # (144) select MIN(#) where # = # and # = # and # = # and # = # (143)
select (#) where # < # and # < # and # < # (142) select SUM(#) where # = # and # = # and # > # and # < # (141) select AVG(#) where # = # and # = # and # = # and # = # (140) select AVG(#) where # = # and # > # and # < # and # < # (139)
select AVG(#) where # < # and # < # and # < # (138) select (#) where # = # and # = # and # > # and # > # (137)
select COUNT(#) where # = # and # = # and # < # and # < # (136) select COUNT(#) where # < # and # < # and # < # (135)
select MAX(#) where # = # and # > # and # > # and # < # (134) select COUNT(#) where # = # and # = # and # > # and # > # (133)
select (#) where # > # and # > # and # > # (132) select SUM(#) where # = # and # > # and # > # and # < # (131)
select SUM(#) where # < # and # < # and # < # (130) select COUNT(#) where # > # and # > # and # > # (129)
select MAX(#) where # = # and # > # and # > # and # > # (128) select MAX(#) where # = # and # > # and # < # and # < # (127)
select AVG(#) where # > # and # > # and # > # (126) select SUM(#) where # = # and # = # and # < # and # < # (125)
select SUM(#) where # > # and # > # and # > # (124) select SUM(#) where # = # and # > # and # < # and # < # (123) select MAX(#) where # = # and # = # and # > # and # < # (122) select MIN(#) where # = # and # = # and # > # and # > # (121)
select (#) (120) select MAX(#) where # < # and # < # and # < # (119)
select MIN(#) where # = # and # = # and # < # and # < # (118) select COUNT(#) where # = # and # > # and # < # and # < # (117) select COUNT(#) where # = # and # = # and # > # and # < # (116)
select MIN(#) where # = # and # > # and # < # and # < # (115) select AVG(#) where # > # and # < # and # < # (114)
select (#) where # = # and # > # and # > # and # < # (113) select (#) where # > # and # < # and # < # (112)
select AVG(#) where # = # and # = # and # > # and # < # (111) select COUNT(#) where # > # and # < # and # < # (110)
select MIN(#) where # > # and # < # and # < # (109) select AVG(#) where # = # and # > # and # > # and # < # (108)
select (#) where # = # and # = # and # < # and # < # (107) select SUM(#) where # > # and # < # and # < # (106) select SUM(#) where # > # and # > # and # < # (105)
select MIN(#) where # = # and # > # and # > # and # < # (104) select (#) where # = # and # > # and # < # and # < # (103)
select MIN(#) where # > # and # > # and # < # (102) select MAX(#) where # > # and # > # and # < # (101)
select (#) where # > # and # > # and # < # (100) select AVG(#) where # > # and # > # and # < # (99) select MAX(#) where # > # and # < # and # < # (98) select AVG(#) where # = # and # = # and # = # (97) select MAX(#) where # = # and # = # and # = # (96) select MIN(#) where # = # and # = # and # = # (95)
select COUNT(#) where # > # and # > # and # < # (94) select MIN(#) where # < # and # < # (93)
select COUNT(#) where # = # and # = # and # = # (92) select SUM(#) where # = # and # = # and # = # (91)
select SUM(#) where # > # and # > # (90) select (#) where # = # and # = # and # > # and # < # (89)
select AVG(#) where # < # and # < # (88) select MAX(#) where # > # and # > # (87)
select MIN(#) where # = # and # < # and # < # (86) select SUM(#) where # = # and # > # and # > # (85)
select SUM(#) where # < # and # < # (84) select MIN(#) where # > # and # > # (83)
select AVG(#) where # = # and # < # and # < # (82) select COUNT(#) where # > # and # > # (81)
select (#) where # = # and # = # and # = # and # < # (80) select (#) where # < # and # < # (79)
select COUNT(#) where # < # and # < # (78) select MAX(#) where # = # and # < # and # < # (77) select MAX(#) where # = # and # > # and # > # (76) select AVG(#) where # = # and # > # and # > # (75)
select MAX(#) where # < # and # < # (74) select MAX(#) where # = # and # = # and # > # (73)
select AVG(#) where # > # and # > # (72) select COUNT(#) where # = # and # < # and # < # (71)
select MIN(#) where # = # and # = # and # > # (70) select SUM(#) where # = # and # < # and # < # (69) select MAX(#) where # = # and # = # and # < # (68)
select COUNT(#) where # = # and # = # and # > # (67) select (#) where # = # and # = # and # = # and # > # (66)
select COUNT(#) where # = # and # > # and # > # (65) select MIN(#) where # = # and # > # and # > # (64) select AVG(#) where # = # and # = # and # > # (63) select AVG(#) where # = # and # = # and # < # (62)
select COUNT(#) where # = # and # = # and # < # (61) select SUM(#) where # = # and # = # and # > # (60) select SUM(#) where # = # and # = # and # < # (59)
select (#) where # > # and # > # (58) select MIN(#) where # = # and # = # and # < # (57)
select (#) where # = # and # > # and # > # (56) select (#) where # = # and # < # and # < # (55)
select SUM(#) where # > # (54) select AVG(#) where # > # and # < # (53)
select MAX(#) where # = # and # > # and # < # (52) select MIN(#) where # > # and # < # (51)
select MAX(#) where # > # and # < # (50) select SUM(#) where # > # and # < # (49)
select COUNT(#) where # > # and # < # (48) select COUNT(#) where # > # (47)
select (#) where # = # and # = # and # = # and # = # (46) select MAX(#) where # > # (45)
select MIN(#) where # = # and # > # and # < # (44) select SUM(#) where # = # and # > # and # < # (43)
select COUNT(#) where # < # (42) select SUM(#) where # < # (41)
select COUNT(#) where # = # and # > # and # < # (40) select (#) where # > # and # < # (39)
select AVG(#) where # > # (38) select AVG(#) where # = # and # > # and # < # (37)
select MIN(#) where # > # (36) select MIN(#) where # < # (35)
select MAX(#) where # < # (34) select AVG(#) where # < # (33)
select (#) where # = # and # > # and # < # (32) select SUM(#) where # = # and # = # (31) select AVG(#) where # = # and # = # (30)
select MAX(#) (29) select MAX(#) where # = # and # = # (28)
select (#) where # < # (27) select (#) where # = # and # = # and # < # (26)
select MIN(#) where # = # and # = # (25) select MIN(#) (24)
select (#) where # = # and # = # and # > # (23) select (#) where # > # (22)
select SUM(#) where # = # and # > # (21) select COUNT(#) where # = # and # = # (20)
select MAX(#) where # = # and # < # (19) select AVG(#) where # = # and # > # (18) select SUM(#) where # = # and # < # (17) select MIN(#) where # = # and # > # (16)
select COUNT(#) where # = # and # < # (15) select AVG(#) where # = # and # < # (14)
select COUNT(#) where # = # and # > # (13) select MAX(#) where # = # and # > # (12) select MIN(#) where # = # and # < # (11)
select SUM(#) where # = # (10) select AVG(#) where # = # (9)
select (#) where # = # and # = # and # = # (8) select (#) where # = # and # < # (7) select (#) where # = # and # > # (6)
select MIN(#) where # = # (5) select MAX(#) where # = # (4)
select COUNT(#) where # = # (3) select (#) where # = # and # = # (2)
select (#) where # = # (1)
Pa tte
rn s
101 103 Counts
101 103
(a) Train (b) Dev (c) Test
Figure A1: SQL logical patterns and their frequency in the (a) train, (b) dev, and (c) test sets of WikiSQL. The index of each pattern is represented in the parentheses on the y-axis labels.

heading: 33 116 14 28 10 1 7 30 7 25 15 4 0 2 0 4

heading: 32 123 16 33 10 1 7 30 6 25 15 4 0 2 2 4

heading: 31 165 15 34 10 0 7 30 6 25 15 4 0 2 2 4

heading: 30 179 16 61 10 2 7 30 12 25 15 4 0 2 0 4

heading: 29 180 29 55 10 2 7 30 9 25 15 4 1 2 1 4

heading: 28 188 36 59 10 3 7 30 7 25 15 4 0 2 0 4

heading: 27 197 22 58 10 2 7 30 10 25 15 4 1 2 2 4

heading: 26 222 35 59 10 2 7 30 9 25 15 4 0 2 0 4

heading: 25 225 30 59 10 3 7 30 12 25 15 4 1 2 3 4

heading: 24 234 35 76 10 3 7 30 10 25 15 4 1 2 1 4

heading: 23 247 42 69 10 4 7 30 11 25 15 4 1 2 2 4

heading: 22 309 45 83 10 2 7 30 15 25 15 4 0 2 0 4

heading: 21 312 48 93 10 5 7 30 12 25 15 4 0 2 0 4

heading: 20 319 50 97 10 2 7 30 9 25 15 4 1 2 5 4

heading: 19 324 62 120 10 7 7 30 21 25 15 4 0 2 4 4

heading: 18 329 48 89 10 3 7 30 19 25 15 4 0 2 1 4

heading: 17 330 59 109 10 3 7 30 16 25 15 4 0 2 1 4

heading: 16 334 55 92 10 5 7 30 17 25 15 4 0 2 0 4

heading: 15 341 46 75 10 7 7 30 11 25 15 4 1 2 2 4

heading: 14 357 55 88 10 9 7 30 17 25 15 4 1 2 2 4

heading: 13 360 70 103 10 7 7 30 21 25 15 4 0 2 3 4

heading: 12 369 59 107 10 5 7 30 23 25 15 4 0 2 5 4

heading: 11 374 57 91 10 8 7 30 25 25 15 4 2 2 6 4

heading: 10 619 105 173 10 11 7 30 30 25 20 4 0 2 3 4

heading: 9 653 104 178 10 9 7 30 27 25 21 4 2 2 8 4

heading: 8 794 92 229 10 13 7 30 30 25 25 4 1 2 3 4

heading: 7 858 138 240 10 14 7 30 55 25 27 4 4 2 10 4

heading: 6 1116 158 339 10 14 9 30 53 25 35 4 3 2 15 4

heading: 5 1412 202 413 10 22 12 30 65 25 45 4 3 2 7 4

heading: 4 1476 235 419 10 23 12 30 84 25 47 4 5 2 19 4

heading: 3 3430 480 972 10 61 27 30 159 54 108 4 4 4 23 8

heading: 2 6050 964 1798 10 95 48 30 263 95 190 4 10 8 52 16

heading: 1 30128 4419 8269 10 484 236 30 1425 471 942 4 84 35 305 70

heading: Appendix B. Supplementary tables
text: 69 38 4 9 10 1 7 30 3 25 15 4 0 2 0 4 70 38 9 10 10 0 7 30 4 25 15 4 0 2 1 4
71 36 11 8 10 0 7 30 1 25 15 4 0 2 3 4 72 36 7 9 10 0 7 30 0 25 15 4 0 2 0 4 73 36 6 15 10 0 7 30 1 25 15 4 2 2 2 4 74 36 7 10 10 0 7 30 0 25 15 4 0 2 1 4 75 36 10 10 10 0 7 30 2 25 15 4 0 2 2 4 76 36 5 12 10 1 7 30 2 25 15 4 0 2 0 4 77 36 4 12 10 0 7 30 1 25 15 4 0 2 0 4 78 35 8 15 10 1 7 30 2 25 15 4 0 2 0 4 79 35 8 10 10 1 7 30 2 25 15 4 0 2 0 4 80 34 3 6 10 0 7 30 2 25 15 0 0 0 0 0
81 33 2 7 10 0 7 30 2 25 15 0 0 0 0 0 82 33 4 8 10 0 7 30 2 25 15 4 0 2 0 4 83 31 3 14 10 2 7 30 1 25 15 0 0 0 0 0 84 30 4 4 10 0 7 30 2 25 15 4 0 2 0 4 85 30 6 10 10 0 7 30 2 25 15 4 0 2 0 4 86 29 11 14 0 0 0 0 2 0 15 0 0 2 2 4 87 29 5 10 0 0 0 0 0 0 15 0 0 2 0 4 88 29 2 11 0 0 0 0 0 0 15 0 0 0 0 0 89 27 5 7 0 2 0 0 1 0 15 0 0 2 0 4 90 26 3 12 0 0 0 0 0 0 15 0 0 0 0 0
91 24 1 4 0 0 0 0 0 0 15 0 0 0 0 0 92 22 5 7 0 1 0 0 1 0 15 0 0 2 0 4 93 22 5 9 0 0 0 0 2 0 15 0 0 2 0 4 94 21 4 4 0 0 0 0 1 0 15 0 0 2 0 4 95 20 3 8 0 0 0 0 1 0 15 0 0 0 0 0 96 20 2 8 0 0 0 0 0 0 15 0 0 0 1 0 97 18 5 3 0 0 0 0 0 0 0 0 0 2 0 4 98 16 4 7 0 1 0 0 1 0 0 0 0 2 0 4 99 16 1 2 0 0 0 0 0 0 0 0 0 0 0 0 100 14 3 2 0 0 0 0 1 0 0 0 0 0 0 0

heading: 101 14 2 7 0 0 0 0 0 0 0 0 0 0 0 0

heading: 102 14 2 4 0 0 0 0 0 0 0 0 0 0 0 0

heading: 103 13 4 3 0 0 0 0 1 0 0 0 0 2 0 4

heading: 104 12 1 4 0 0 0 0 1 0 0 0 0 0 0 0

heading: 105 11 2 3 0 0 0 0 1 0 0 0 0 0 0 0

heading: 106 11 2 3 0 0 0 0 0 0 0 0 0 0 0 0

heading: 107 11 3 5 0 0 0 0 1 0 0 0 0 0 1 0

heading: 108 11 0 5 0 0 0 0 0 0 0 0 0 0 0 0

heading: 109 11 2 9 0 0 0 0 1 0 0 0 0 0 0 0

heading: 110 11 2 6 0 1 0 0 0 0 0 0 0 0 0 0

heading: 111 10 0 2 0 0 0 0 1 0 0 0 0 0 0 0

heading: 112 10 5 3 0 0 0 0 1 0 0 0 0 2 0 4

heading: 113 9 2 3 0 0 0 0 0 0 0 0 0 0 0 0

heading: 114 9 5 7 0 0 0 0 0 0 0 0 0 2 1 4

heading: 115 9 0 1 0 0 0 0 0 0 0 0 0 0 0 0

heading: 116 9 3 2 0 0 0 0 0 0 0 0 0 0 0 0

heading: 117 8 1 3 0 0 0 0 0 0 0 0 0 0 0 0

heading: 118 8 0 1 0 0 0 0 0 0 0 0 0 0 0 0

heading: 119 8 0 0 0 0 0 0 1 0 0 0 0 0 0 0

heading: 120 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 121 7 1 1 0 0 0 0 1 0 0 0 0 0 0 0

heading: 122 7 1 5 0 0 0 0 0 0 0 0 0 0 0 0

heading: 123 7 1 2 0 0 0 0 2 0 0 0 0 0 0 0

heading: 124 7 1 1 0 0 0 0 1 0 0 0 0 0 0 0

heading: 125 7 0 2 0 0 0 0 1 0 0 0 0 0 0 0

heading: 126 7 1 0 0 1 0 0 1 0 0 0 0 0 0 0

heading: 127 7 0 1 0 0 0 0 2 0 0 0 0 0 0 0

heading: 128 6 0 2 0 0 0 0 1 0 0 0 0 0 0 0

heading: 129 6 1 2 0 0 0 0 1 0 0 0 0 0 0 0

heading: 130 6 0 3 0 0 0 0 0 0 0 0 0 0 0 0

heading: 131 6 1 1 0 0 0 0 1 0 0 0 0 0 0 0

heading: 132 6 1 1 0 1 0 0 0 0 0 0 0 0 0 0

heading: 133 6 1 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 134 6 1 1 0 1 0 0 0 0 0 0 0 0 1 0

heading: 135 6 1 3 0 0 0 0 0 0 0 0 0 0 0 0

heading: 136 6 0 3 0 0 0 0 1 0 0 0 0 0 0 0

heading: 137 5 1 7 0 0 0 0 0 0 0 0 0 0 0 0

heading: 138 5 0 0 0 0 0 0 1 0 0 0 0 0 0 0

heading: 139 5 0 3 0 0 0 0 0 0 0 0 0 0 0 0

heading: 140 5 0 1 0 0 0 0 0 0 0 0 0 0 0 0

heading: 141 5 0 0 0 1 0 0 0 0 0 0 0 0 0 0

heading: 142 5 0 1 0 0 0 0 0 0 0 0 0 0 0 0

heading: 143 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 144 4 3 1 0 0 0 0 1 0 0 0 0 0 1 0

heading: 145 4 1 1 0 0 0 0 0 0 0 0 0 0 0 0

heading: 146 4 1 1 0 0 0 0 0 0 0 0 0 0 0 0

heading: 147 4 0 1 0 0 0 0 0 0 0 0 0 0 0 0
text: 148 3 1 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 149 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 150 3 2 0 0 0 0 0 0 0 0 0 0 0 1 0

heading: 151 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 152 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 153 3 0 1 0 0 0 0 0 0 0 0 0 0 0 0

heading: 154 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 155 3 0 2 0 0 0 0 0 0 0 0 0 0 0 0

heading: 156 3 2 3 0 0 0 0 1 0 0 0 0 0 0 0

heading: 157 3 1 1 0 0 0 0 0 0 0 0 0 0 0 0

heading: 158 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 159 3 1 0 0 0 0 0 1 0 0 0 0 0 0 0

heading: 160 3 1 0 0 0 0 0 1 0 0 0 0 0 0 0

heading: 161 3 0 6 0 0 0 0 0 0 0 0 0 0 0 0

heading: 162 2 0 3 0 0 0 0 0 0 0 0 0 0 0 0

heading: 163 2 0 2 0 0 0 0 0 0 0 0 0 0 0 0

heading: 164 2 1 3 0 0 0 0 0 0 0 0 0 0 1 0

heading: 165 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 166 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 167 2 0 0 0 1 0 0 0 0 0 0 0 0 0 0

heading: 168 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 169 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 170 2 1 2 0 0 0 0 0 0 0 0 0 0 0 0

heading: 171 2 2 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 172 2 0 2 0 0 0 0 0 0 0 0 0 0 0 0

heading: 173 2 1 0 0 0 0 0 1 0 0 0 0 0 0 0

heading: 174 2 0 1 0 0 0 0 0 0 0 0 0 0 0 0

heading: 175 2 0 1 0 0 0 0 0 0 0 0 0 0 0 0

heading: 176 2 1 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 177 2 0 1 0 0 0 0 0 0 0 0 0 0 0 0

heading: 178 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 179 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 180 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 181 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 182 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 183 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 184 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 185 1 0 2 0 0 0 0 0 0 0 0 0 0 0 0

heading: 186 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 187 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 188 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 189 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0

heading: 190 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 191 1 0 2 0 0 0 0 0 0 0 0 0 0 0 0

heading: 192 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 193 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0

heading: 194 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 195 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0

heading: 196 1 0 2 0 0 0 0 0 0 0 0 0 0 0 0

heading: 197 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0

heading: 198 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0

heading: 199 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 200 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 201 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 202 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 203 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0

heading: 204 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 205 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 206 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 207 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

heading: 208 0 1 2 0 0 0 0 0 0 0 0 0 0 0 0

heading: 209 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0
text: 210 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Review summaries:
The paper presents a retrieval-based semantic parsing method for the data-scarce setting. The model retrieves a logical pattern from the train data by computing the similarity between NL queries. Then lexicons are added to the retrieved pattern in order to generate the final LF. The motivation and the proposed method make sense to me. The experimental results also show that the approach improves the performance over several baseline methods. The only concern is that the experiments are only conducted on wikisql, which is not very data-hungry. The paper reduces the number of training set to simulate the setup. The paper could be improved by conducting experiments on more small-scale datasets.