1 Introduction↩︎

Models for question answering (QA) over tables usually assume that the relevant table is given during test time. This applies for semantic parsing (e.g., for models trained on SPIDER [2]) and for end-to-end QA [3], [4]. While this assumption simplifies the QA model, it is not realistic for many use-cases where the question is asked through some open-domain natural language interface, such as web search or a virtual assistant.

In these open-domain settings, the user has some information need, and the corresponding answer resides in some table in a large corpus of tables. The QA model then needs to utilize the corpus as an information source, efficiently search for the relevant table within, parse it, and extract the answer.

Recently, much work has explored open-domain QA over a corpus of textual passages [5]–[8]. These approaches usually follow a two-stage framework: (1) a retriever first selects a small subset of candidate passages relevant to the question, and then (2) a machine reader examines the retrieved passages and selects the correct answer. While these approaches work well on free text, it is not clear whether they can be directly applied to tables, as tables are semi-structured, and thus different than free text.

In this paper we describe the first study to tackle open-domain QA over tables, and focus on modifying the retriever. We follow the two-step approach of a retriever model that retrieves a small set of candidate tables from a corpus, followed by a QA model (Figure 1). Specifically, we utilize dense retrieval approaches targeted for retrieving passages [8]–[10], and modify the retriever to better handle tabular contexts. We present a simple and effective pre-training procedure for our retriever, and further improve its performance by mining hard negatives using the retriever model. Finally, as relevant open domain datasets are missing, we process Natural Questions [1] and extract 11K examples where the answer resides in some table. Our model and data generation code as well as the pre-trained model are publicly available at https://github.com/google-research/tapas.

2 Setup↩︎

We formally define open domain extractive QA over tables as follows. We are given a training set of \(N\) examples \(\mathcal{D}_{\text{train}}= \{(q_i,T_i,a_i)\}_{i=1}^{N}\), where \(q_i\) is a question, \(T_i\) is a table where the answer \(a_i\) resides, and a corpus of \(M\) tables \(\mathcal{C}=\{T_i\}_{i=1}^{M}\). The answer \(a_i\) is comprised of one or more spans of tokens in \(T_i\). Our goal is to learn a model that given a new question \(q\) and the corpus \(\mathcal{C}\) returns the correct answer \(a\).

Our task shares similarities with open domain QA over documents [5], [7], [8], where the corpus \(\mathcal{C}\) consists of textual passages extracted from documents instead of tables, and the answer is a span that appears in some passage in the corpus. As in these works, dealing with a large corpus (of tables in our setting), requires relevant context retrieval. Naively applying a QA model, for example TAPAS[4], over each table in the large corpus is not practical because inference is too expensive.

To this end we break our system into two independent steps. First, an efficient table retriever component selects a small set of candidate tables \(\mathcal{C}_R\) from a large corpus of tables \(\mathcal{C}\). Second, we apply a QA model to extract the answer \(a\) given the question \(q\) and the candidate tables \(\mathcal{C}_R\).

3 Dense Table Retrieval↩︎

In this section we describe our dense table retriever (DTR), which retrieves a small set of \(K\) candidate tables \(\mathcal{C}_R\) given a question \(q\) and a corpus \(\mathcal{C}\). In this work we set \(K=10\) and take \(\mathcal{C}\) to be the set of all tables in the dataset we experiment with (see §6).

As in recent work for open domain QA on passages [8]–[12], we also follow a dense retrieval architecture. As tables that contain the answer to \(q\) do not necessarily include tokens from \(q\), a dense encoding can better capture similarities between table contents and a question.

For training DTR, we leverage both in-domain training data \(\mathcal{D}_{\text{train}}\), and automatically constructed pre-training data \(\mathcal{D}_{\text{pt}}\) of text-table pairs (see below).

3.0.0.1 Retrieval Model

In this work we focus on learning a retriever that can represent tables in a meaningful way, by capturing their specific structure. Traditional information retrieval methods such as BM25 are targeted to capture token overlaps between a query and a textual document, and other dense encoders are pre-trained language models (such as BERT) targeted for text representations.

Recently, proposed TAPAS, an encoder based on BERT, designed to contextually represent text and a table jointly. TAPAS includes table specific embeddings that capture its structure, such as row and column ids. In DTR, we use TAPAS to represent both the query \(q\) and the table \(T\). For efficient retrieval during inference we use two different TAPAS instances (for \(q\) and for \(T\)), and learn a similarity metric between them as .

More concretely, the TAPAS encoder \(\texttt{TAPAS}(x_1, [x_2])\) takes one or two inputs as arguments, where \(x_1\) is a string and \(x_2\) is a flattened table. We then define the retrieval score as the inner product of dense vector representations of the question \(q\) and the table \(T\): \[\begin{align} &h_q = \mathbf{W_q}\texttt{TAPAS}_{\text{q}}(q)\texttt{[CLS]} \\ &h_T = \mathbf{W_T}\texttt{TAPAS}_{\text{T}}(\texttt{title}(T), T)\texttt{[CLS]} \\ &\texttt{S}_\text{ret}(q, T) = h^T_q h_T, \end{align}\] where \(\texttt{TAPAS}(\cdot)\texttt{[CLS]}\) returns the hidden state for the CLS token, \(\mathbf{W_q}\) and \(\mathbf{W_T}\) are matrices that project the TAPAS output into \(d=256\) dimensional vectors, and \(\texttt{title}(T)\) is the page title for table \(T\). We found the table’s page title to assist in retrieving relevant tables, which is also useful for Wikipedia passage retrieval [8].

3.0.0.2 Training

The goal of the retriever is to create a vector space such that relevant pairs of questions and tables will have smaller distance (which results in a large dot product) than the irrelevant pairs, by learning an embedding. To increase the likelihood of gold \((q, T)\) pairs, we train the retriever with in-batch negatives [10], [13], [14]. Let \(\{(q_i,T_i)\}_{i=1}^{B}\) be a batch of \(B\) examples from \(\mathcal{D}_{\text{train}}\), where for each \(q_i\), \(T_i\) is the gold table to retrieve, and for each \(j\neq i\) we treat \(T_j\) as a negative. We now define the likelihood of the gold table \(T_i\) as: \[\begin{align} p(T_i | q_i)=\frac{\exp[\texttt{S}_\text{ret}(q_i,T_i)]}{\sum_{j=1}^B \exp[\texttt{S}_\text{ret}(q_i,T_j)]}. \end{align}\]

To train the model efficiently, we define \(\mathbf{Q}\) and \(\mathbf{T}\) to be a \(B\times d\) matrix that hold the representations for questions and tables respectively. Then, \(\mathbf{S}=\mathbf{Q}\mathbf{T}^T\) gives an \(B\times B\) matrix where the logits from the gold table are on the diagonal. We then train using a row-wise cross entropy loss where the labels are a \(B\times B\) identity matrix.

3.0.0.3 Pre-training

One could train our retriever from scratch, solely relying on a sufficiently large in-domain training dataset \(\mathcal{D}_{\text{train}}\). However, we find performance to improve after using a simple pre-training method for our retriever. suggest to pre-train a textual dense retriever using an Inverse Cloze Task (ICT). In ICT, the goal is to predict a context given a sentence \(s\). The context is a passage that originally contains \(s\), but with \(s\) masked. The motivation is that the relevant context should be semantically similar to \(s\), and should contain information missing from \(s\).

Similarly, we posit that a table \(T\) that appears in close proximity to some text span \(s\) is more relevant to \(s\) than a random table. To construct a set \(\mathcal{D}_{\text{pt}}= \{(s_i,T_i)\}_{i=1}^{M}\) that consists of \(M\) pre-training pairs \((s,T)\), we use the pre-training data from . They extracted text-table pairs from 6.2M Wikipedia tables, where text spans were sampled from the table caption, page title, page description, segment title and text of the segment the table occurs in. This resulted in a total of 21.3M text-table \((s,T)\) pairs. While uses extracted \((s,T)\) pairs for pre-training TAPAS with a masked language modeling objective, we pre-train DTR from these pairs, with the same objective used for in-domain data.

3.0.0.4 Hard Negatives

Following similar work [10], [13], [15], we use an initial retrieval model to extract the most similar tables from \(\mathcal{C}\) for each question in the training set. From this list we discard each table that does contain the reference answer to remove false negatives. We use the highest scoring remaining table as a particular hard negative.

Given the new triplets of question, reference table and mined negative table, we train a new model using a modified version of the in-batch negative training discussed above. Given \(\mathbf{Q}\) and \(\mathbf{S}\) as defined above and a new matrix \(\mathbf{N}\) (\(B\times d\)) that holds the representations of the negative tables, \(\mathbf{S'}=\mathbf{Q}\mathbf{N}^T\) gives another \(B\times B\) matrix that we want to be small in value (possibly negative). If we concatenate \(\mathbf{S}\) and \(\mathbf{S'}\) row-wise we get a new matrix for which we can perform the same cross entropy training as before. The label matrix is now obtained by concatenating an identity matrix row-wise with a zero matrix.

3.0.0.5 Inference

During inference time, we apply the table encoder \(\texttt{TAPAS}_{\text{T}}\) to all the tables \(T \in \mathcal{C}\) offline. Given a test question \(q\), we derive its representation \(h_q\) and retrieve the top \(K\) tables with representations closest to \(h_q\).

In our experiments, we use exhaustive search to find the top \(K\) tables, but to scale to large corpora, fast maximum inner product search using existing tools such as FAISS [16] and ScaNN [17] could be used, instead.

4 Question Answering over Tables↩︎

A reader model is used to extract the answer \(a\) given the question \(q\) and \(K\) candidate tables. The model scores each candidate and at the same time extracts a suitable answer span from the table. Each table and question are jointly encoded using a TAPAS model. The score is a simple logistic loss based on the CLS token, as in  [18].

The answer span extraction is modeled as a soft-max over all possible spans up to a certain length. Spans that are located outside of a table cell or that cross a cell are masked. Following , the span representation is the concatenation of the contextual representation of the first and last token in the span \(s\): \[\begin{align} &h_{start} = \texttt{TAPAS}_r(q, \texttt{title}(T), T)[\texttt{START}(s)] \\ &h_{end} = \texttt{TAPAS}_r(q, \texttt{title}(T), T)[\texttt{END}(s)] \\ &\texttt{S}_\text{read}(q, T) = \texttt{MLP}([h_{start}, h_{end}]). \end{align}\] The training and test data are created by running a retrieval model. We extract the \(K=10\) highest scoring candidate tables for each question. At training time we add the reference table if it is missing from the candidates.

At inference time all table candidates are processed and the answer of the candidate with the highest score is returned as the predicted answer.

5 Dataset↩︎

We create a new English dataset called NQ-Tables from Natural Questions [1] (NQ). Concurrently with this work, [19] study a similar subset of NQ but without the retrieval aspect.

NQ was designed for question answering over Wikipedia articles. The \(320K\) questions are mined from real Google search queries and the answers are spans in Wikipedia articles identified by annotators. Although the answers for most questions appear in textual passages, we identified 12K examples where the answer resides in a table, and can be used as a QA over tables example. To this end, we form NQ-Tables that consists of \((q,T,a)\) triplets from these examples. Tables are extracted from the article’s HTML, and are normalized by transposing infobox tables.

We randomly split the original NQ train set into train and dev (based on a hash of the page title) and use all questions from the original NQ dev set as our test set. To construct the corpus \(\mathcal{C}\), we extract all tables that appear in articles in all NQ sets.

NQ can contain the same Wikipedia page in different versions which leads to many almost identical tables. We merge close duplicates using the following procedure. For all tables that occur on the same Wikipedia page we flatten the entire table content, tokenize it and compute \(l_2\) normalized uni-gram vectors of the token counts of each table. We then compute the pair-wise cosine similarity of all tables. We iterate over the table pairs in decreasing order of similarity and attempt to merge them into clusters. This is essentially a version of single link clustering. In particular, we will merge two tables if the similarity is \(> 0.91\), they do not occur on the same version of the page, their difference is rows is at most 2 and they have the same number of columns.

Dataset sizes are given in the following table:

6 Experiments↩︎

Details about the experimental setup are given Appendix 8.

6.0.0.1 Retrieval Baselines

We consider the following baselines as alternatives to DTR. We use the BM25 [20] implementation of Gensim [21]². To measure if a table-specific encoder is necessary, we implement DTR-text, where the retriever is initialized from BERT[22] instead of TAPAS. To test whether the content of the table is relevant, we experiment with DTR-schema, where only the headers and title are used to represent tables.

6.0.0.2 Retrieval Results

Table ¿tbl:tab:test95retrieval? shows the test results for table retrieval (dev results are in Appendix 9). We report recall at \(K\) (R@K) metrics as the fraction of questions for which the highest scoring \(K\) tables contain the reference table.

We find that all dense models that have been pre-trained out-peform the BM25 baseline by a large margin. The model that uses the TAPAS table embeddings (DTR) out-performs the dense baselines by more than 1 point in R@10. The addition of mined negatives (DTR +hn) yields an additional improvement of more than 5 points. Mining negatives from DTR works better than mining negatives from BM25 (DTR +hnbm25, +0.6 R@10).

6.0.0.3 End-to-End QA

Results for end-to-end QA experiments are shown in Table ¿tbl:tab:test95qa? (dev results are in Appendix 9). We use the exact match (EM) and token F1 metrics as implemented in SQUAD [23].³ We additionally report oracle metrics which are computed on the best answer returned for any of the candidates.

We again find that all dense models out-perform the BM25 baseline. A TAPAS-based reader out-performs a BERT reader by more than 3 points in EM. The simple DTR model out-performs the baselines by more than 1 point in EM. Hard negatives from BM25 (+hnbm25) improve DTR’s performance by 1 point, while hard negatives from DTR (+hn) improve performance by 2 points. We additionally perform a McNemar’s significance test for our proposed model, DTR+hn, and find that it performs significantly better (p<0.05) than all baselines.

6.0.0.4 Analysis

Analyzing the best model in Table ¿tbl:tab:test95qa? (DTR +hn) on the dev set, we find that 29% of the questions are answered correctly, 14% require a list answer (which is out of scope for this paper), 12% do not have any table candidate that contains the answer, for 11% the model does not select a table that contains the answer, and for 34% the reader fails to extract the correct span.

We further analyzed the last category by manually annotating 100 random examples. We find that for 23 examples the answer is partially correct (usually caused by inconsistent span annotations in NQ). For 11 examples the answer is ambiguous (e.g., the release date of a movie released in different regions). For 22 examples the table is missing context or does only contain the answer accidentally. Finally, 44 examples are wrong, usually because they require some kind of table reasoning, like computing the maximum over a column, or using common sense knowledge.

7 Conclusion↩︎

In this paper we demonstrated that a retriever designed to handle tabular context can outperform other textual retrievers for open-domain QA on tables. We additionally showed that our retriever can be effectively pre-trained and improved by hard negatives. In future work we aim to tackle multi-modal open-domain QA, combining passages and tables as context.

Acknowledgments↩︎

We would like to thank William Cohen, Sewon Min, Yasemin Altun and the anonymous reviewers for their constructive feedback, useful comments and suggestions. This work was completed in partial fulfillment for the PhD degree of the first author, which was also supported by a Google PhD fellowship.

8 Experimental Setup↩︎

The DTR model uses a batch size of 256. We pre-trained the question and table encoders for 1M steps, and fine-tuned them for a maximum of 200,000 steps, with a learning rate of 1.25e-5 using Adam and linear scheduling with warm-up and dropout rate 0.2. The hyper-parameter values were selected based on the values used by on the SQA dataset. We evaluate DTR performance using recall@k, and do early stopping according to recall@10 on the dev set. We use only the tables that appear in the dev set as the corpus for the early stopping for efficiency.

For the QA reader, we initialize the model from the public TAPAS checkpoint. We use a batch size of 512, train for 50,000 steps with a learning rate of 1e-6, and dropout rate 0.2. In this setup we do not use early stopping but always train the model for the full number of steps. We limit the maximal answer length to 10 word pieces. The hyper-parameters of the QA model were optimized using a black box Bayesian optimizer similar to Google Vizier [24]. We used the hyper-parameter bounds given in Table ¿tbl:tab:hp95bounds?.

We trained all models on 32 Cloud TPU v3. Pre-Training a retrieval model takes approx. 6 days. Training a retrieval model takes approx. 4-5h. Training a QA model takes approx. 10h.

The number of parameters is the same as for a BERT large model: 340M.

9 Results↩︎

Dev and test results for the retrieval experiments are given in Table ¿tbl:tab:dev95test95retrieval?. Dev and test results for end-to-end QA are given in the appendix in Table ¿tbl:tab:dev95test95qa?.

References↩︎