RetinaQA: A Robust Knowledge Base Question Answering Model for both Answerable and Unanswerable Questions (2024)

Abstract: An essential requirement for a real-world Knowledge Base Question Answering (KBQA) system is the ability to detect answerability of questions when generating logical forms. However, state-of-the-art KBQA models assume all questions to be answerable. Recent research has found that such models, when superficially adapted to detect answerability, struggle to satisfactorily identify the different categories of unanswerable questions, and simultaneously preserve good performance for answerable questions. Towards addressing this issue, we propose RetinaQA, a new KBQA model that unifies two key ideas in a single KBQA architecture: (a) discrimination over candidate logical forms, rather than generating these, for handling schema-related unanswerability, and (b) sketch-filling-based construction of candidate logical forms for handling data-related unaswerability. Our results show that RetinaQA significantly outperforms adaptations of state-of-the-art KBQA models in handling both answerable and unanswerable questions and demonstrates robustness across all categories of unanswerability. Notably, RetinaQA also sets a new state-of-the-art for answerable KBQA, surpassing existing models. We release our code-base1 for further research.

heading: 1 Introduction
text: Question answering over knowledge bases (KBQA) (Saxena et al., 2022; Zhang et al., 2022; Mitra et al., 2022; Wang et al., 2022; Das et al., 2022; Cao et al., 2022; Ye et al., 2022; Chen et al., 2021; Das et al., 2021; Shu et al., 2022; Gu et al., 2023) requires answering natural language questions over a knowledge base (KB), most commonly via generating formal queries or logical forms that are then executed over the knowledge base to retrieve the answers. When users interact with KBs in real-world settings, unanswerability of questions arises naturally.
1https://github.com/dair-iitd/RetinaQA
Users are typically unfamiliar with the schema and data of the underlying KB. Further, KBs are also often incomplete. While specialized models for handling unanswerability have been proposed for other question answering tasks (Rajpurkar et al., 2018; Choi et al., 2018; Reddy et al., 2019; Sulem et al., 2022; Raina and Gales, 2022), all existing models for KBQA assume answerability of questions over the given KB.
Recently, Patidar et al. (2023) published a benchmark dataset called GrailQAbility incorporating different categories of unanswerable questions. This work also demonstrated that state-of-the-art KBQA models perform poorly off-the-shelf for unanswerable questions. This performance improves with superficial adaptations for unaswerability, such as adding unanswerable questions during training and thresholding. However, such adaptations significantly hurt performance for answerable questions. Additionally, different state-ofthe-art models struggle with different categories of unaswerability, such as (a) questions for which schema elements (i.e. relations or entity types) are missing in the KB, and which therefore do not have valid logical forms, and (b) questions for which data elements (i.e. entities or facts) are missing in the KB, and which therefore have logical forms that are valid, but return empty answers on execution. This work demonstrated that there is no single model which performs well for all categories of unanswerable questions and answerable ones.
Our analysis of existing models reveals two key drawbacks that make KBQA models less robust – imperfect calibration and over-reliance on pathbased retrieval. To overcome these, we propose a new multi-stage Retrieve, generate, and rank architecture for KBQA named RetinaQA, which brings together several ideas from the literature.
First, a robust KBQA model has to separate questions that are answerable (having a valid logical form) from those that are unanswerable due
6643
to missing schema elements (not having a valid logical form). This requires good model calibration. Most KBQA models use generation of logical form as their final step, which has calibration challanges. Instead, since discriminative models are generally better calibrated, RetinaQA’s final stage discriminates among candidate logical forms, better separating questions without any logical form.
Secondly, existing models assume answerability, where all logical forms have accompanying paths in the KB. These models learn to rely on retrieved paths from the KB to generate logical forms. However, missing data elements may break any valid path, while the question, even though unanswerable, still has a valid logical form. Existing models falter here, and end up generating some other logical form corresponding to paths that do exist in the KB. To handle such unanswerable questions, RetinaQA additionally employs sketchfilling-based construction. It first generates schemaindependent high-level sketches, and then grounds these for the specific KB using relevant schema elements retrieved for the question.
Using experiments over GrailQAbility, we demonstrate that the performance of RetinaQA is not only stable but also significantly better than that of adaptations of multiple state-of-the-art KBQA models that assume answerability, not only across different categories of unanswerable questions, but also for answerable ones. Interestingly, we demonstrate that the RetinaQA architecture performs strongly for fully answerable KBQA benchmarks as well, and establishes a new state-of-the-art performance on the GrailQA dataset.

heading: 2 Related Work
text: The predominant approach for supervised KBQA uses the question to construct a logical form, which is then executed to retrieve the answer (Cao et al., 2022; Ye et al., 2022; Chen et al., 2021; Das et al., 2021). State-of-the-art models use k-hop path traversal to retrieve data paths from linked entities in the question (Ye et al., 2022; Shu et al., 2022). Some models, instead (Chen et al., 2021) or additionally (Shu et al., 2022), retrieve schema elements (namely, entity types and relations) based on the question. These utilize transformer-based decoders to generate the target logical forms. We have observed that generative models are not adequately calibrated to separate answerable and unanswerable questions correctly.
In contrast, Pangu (Gu et al., 2023) uses language models to incrementally enumerate and discriminate between partial logical forms. Though this approach is better calibrated, its path-level enumeration makes it brittle for questions with missing data elements. Some retrieval-based methods (Saxena et al., 2020, 2022) also perform ranking of answer paths, but directly select answer nodes. These methods maximize the similarity score between a relation and the question. Adapting such techniques to detect unanswerable questions is difficult. In contrast, we perform contrastive-learning-based one-shot discrimination on fully-formed logical form candidates in the final stage.
In addition to supervised in-domain settings, transfer (Cao et al., 2022; Ravishankar et al., 2022) and few-shot (Li et al., 2023) settings have also been studied for KBQA. Here, test questions involve unseen KB relations and entity types. Approaches for these settings first generate high-level sketches (also called drafts or skeletons) that capture the syntax of the target language. These sketches are then filled in with KB-specific arguments to construct complete programs, which are finally scored and ranked. Notably, these transfer architectures do not involve any traversal-based component to retrieve logical forms. In contemporaneous work on few-shot transfer, Patidar et al. (2024) propose the FuSIC-KBQA framework accommodating one or more supervised retrievers coupled with an LLM for retrieval reranking and logical form generation. This demonstrates how retrievers from existing supervised models (Shu et al., 2022; Gu et al., 2023) can be adapted and augmented using LLMs for low-supervision settings. In principle, RetinaQA can also be accommodated as a retriever in this framework.
Unanswerability and specialized models for detecting unanswerable questions have been studied for many question-answering tasks (Rajpurkar et al., 2018; Choi et al., 2018; Reddy et al., 2019; Sulem et al., 2022; Raina and Gales, 2022). However, no specialized models have been proposed for detecting unanswerable questions in KBQA. All existing KBQA models assume that questions have valid logical forms with non-empty answers. Even in the transfer setting for KBQA (Cao et al., 2022; Ravishankar et al., 2022), though the target logical forms may involve schema elements unseen during training, questions are still assumed to be answerable. Recent work (Patidar et al., 2023)
has published the GrailQAbility benchmark by modifying the popular GrailQA dataset (Gu et al., 2021) to incorporate multiple categories of unanswerable questions. This work also demonstrates that answerable-only KBQA models, when superficially adapted for handling unanswerability, fall short in many ways.

heading: 3 The Problem and Our Solution
text: We first briefly define the KBQA with unanswerability task, and then describe the architecture of our proposed RetinaQA model.

heading: 3.1 KBQA with Unanswerability
text: A Knowledge Base G consists of a schema S with data D stored under it. The schema consists of entity types T and binary relations R defined over pairs of types. Together, we refer to these as schema elements. The data D consists of entities E as instances of types T , and facts F ⊆ E ×R×E. Together, we refer to these as data elements. We follow the definition of (Patidar et al., 2023) for defining the task of Knowledge Base Question Answering (KBQA) with unanswerability. A natural language question q is said to be answerable for a KB G if it has a corresponding logical form l, which, when executed over G, returns a non-empty
answer A. In contrast, a question q is unanswerable for G, if it either (a) does not have a corresponding logical form that is valid for G, or (b) it has a valid logical form l for G, but which on executing returns an empty answer. The first case indicates that G is missing some schema element necessary for capturing the semantics for q. The second case indicates that the schema S is sufficient for q, but G is missing some necessary data elements for answering it. In the KBQA with unanswerability task, given a question q, if it is answerable, the model needs to output the corresponding logical form l and the non-empty answer A entailed by it, and if it is unanswerable, the model either needs to output NK (meaning No Knowledge) for the logical form, or a valid logical form l with NA (meaning No Answer) as the answer. While different formalisms have been proposed for logical forms, we use s-expressions (Gu et al., 2021). These have set-based semantics, functions with arguments and return values as sets.

heading: 3.2 The RetinaQA Model
text: Fig. 1 shows the architecture of RetinaQA. At a high level, RetinaQA has two stages – logical form enumeration, followed by logical form ranking. For logical form enumeration, RetinaQA follows
two complementary approaches and then takes the union. The first is path-traversal based retrieval. Starting from linked entities in the question, RetinaQA traverses data-level KB paths and transforms these to logical forms. The second is sketch-filling based construction, which is critical when the KB has missing data elements for the question. Here, RetinaQA first generates logical form sketches corresponding to the question, and then enumerates semantically valid groundings for these by retrieving relevant KB schema elements for filling in the sketch arguments. Note that this approach utilizes only the KB schema and avoids data. Once candidate logical forms are so identified, RetinaQA uses discriminative scoring to rank these logical forms with respect to the question. We next explain each of these components in more detail.
Entity Linker: The pipeline starts with linking mentioned entities in the question with KB entities E. This is required for both logical form retrieval and logical form construction. We use an off-theshelf entity linker (Ye et al., 2022) previously used in the KBQA literature (Shu et al., 2022; Gu et al., 2023). More details are in the Appendix (A.1). If the mentioned entities are missing in the KB, the entity linker returns an empty set.
Logical Form Retriever: As the first approach for enumerating logical forms, RetinaQA uses KB data path traversal (Ye et al., 2022). RetinaQA traverses 2-hop paths starting from the linked entities and transforms these to logical forms in sexpression. These logical forms are then scored according to their similarity with the question, and the top-10 logical forms are selected for the next stage, as illustrated under LF Retriever in Fig. 1. Following (Ye et al., 2022), we score a logical form l and question q as:
s(l, q) = LINEAR(BERTCLS([l; q])) (1)
and optimize a contrastive objective for ranking:
Lret = − exp(s(l∗, q))
exp(s(l∗, q)) + ∑
l∈L∧l ̸=l∗ exp(s(l, q)) (2)
where l∗ is the gold-standard logical form for q, and L is the set of logical forms similar to l∗. Note that the transformation to logical forms from KBpaths only covers certain operators (such as count), but not some others (such as argmin, argmax), so that this enumeration approach is not guaranteed to
cover all logical forms. More importantly for unanswerability, as illustrated in Fig. 1, this approach cannot retrieve the logical form in red when the relevant data path in the KB is broken, as by the absence of the data element (C. Manning, works at, Stanford) in our example.
Logical Form Constructor: The second approach used by RetinaQA for logical form enumeration is sketch-filling. Drawing inspiration from the transfer approaches for KBQA (Cao et al., 2022; Ravishankar et al., 2022; Li et al., 2023), RetinaQA uses logical form sketches. Sketches capture KBindependent syntax of s-expressions with functions, operators and literals, and replace KB-specific elements, specifically entities, entity types and relations, with arguments. RetinaQA first generates sketches using a sketch generator, and in parallel retrieves relevant schema elements as candidates for sketch arguments using a schema retriever, and finally fills in arguments for each candidate sketch using the retrieved argument candidates in all possible valid ways using a logical form integrator. By avoiding path-based retrieval, this approach can construct valid logical forms when these exist, even when some relevant data element for the question is missing in the KB, for example, when the data element (C. Manning, works at, Stanford) is missing in the KB but the relation works at is present in the KB schema.
Sketch Generator: The sketch generator takes the question q as input and outputs a sketch s, optimizing a cross-entropy-based objective:
Lsketch = − n∑
t=1
log(p(st|s<t, q))
Specifically, we fine-tune T5 (Raffel et al., 2020) as the Seq2Seq model. We also perform constrained decoding during inference to ensure syntactic correctness of the generated sketch. This step is unaffected by any KB incompleteness.
Schema Retriever: To retrieve candidate arguments for generated sketches, we follow the schema retriever of TIARA (Shu et al., 2022). It is a cross encoder and uses the form of Eqn.1 to score a schema element x and the question q, and optimizes the same form of the objective as for the sentence-pair classification task (Devlin et al., 2019). We train two retriever models, one for relations and one for types, and use the top-10 types and top-10 relations as candidate arguments for
each question. As illustrated in Fig. 1, this step breaks when relevant relations, such as works at, or entity types are missing from the KB schema.
Logical Form Integrator: This component grounds each generated candidate sketch using the retrieved candidate arguments and the linked entities to construct complete logical form candidates. Each candidate sketch is grounded using every possible combination of candidate arguments. A symbolic checker ensures type-level validity of the grounded logical forms for the KB G. This also avoids a combinatorial blow-up and restricts the space of logical form candidates. This component does not involve any trainable parameters.
Logical Form Discriminator: This component finally scores and ranks all the logical form candidates provided by the retriever and constructor components. A T5 encoder-decoder model is trained to score a logical form candidate. Following Zhuang et al. (2022), we feed a (question, logical form) pair to the encoder, and use decoding probability for a special token as the ranking score.2 This component uses a contrastive learning-based optimization objective similar to Eqn.2. We sample negative examples randomly, but this mostly covers the set of all negative candidates given its small size.
For a test question, the candidate logical forms are ranked according to the predicted discriminator scores. If the score of the top-ranked candidate is below a threshold (tuned on the validation set), it is classified as unanswerable i.e. L = NK and A = NA. This helps in identifying questions for which valid logical forms do not exist due to missing schema elements. For example, in Fig. 1, if the logical form in red is missing from the candidate list, the discriminator assigns a low score to the rank 1 logical form candidate, and NK is output after thresholding. Otherwise, the top-ranked candidate is predicted as the logical form.
The predicted logical form is then converted to SPARQL and executed over KB. If a non-empty answer is obtained, then the question is considered answerable with the output as the desired answer. On the other hand, if the answer is empty, the question is classified as unanswerable under the missing data elements category, i.e., A = NA.
2We use < extra_id_6 > token of T5 for tuning the ranking score.

heading: 4 Experiments
text: We address the following research questions: (1) How does RetinaQA compare against baselines for answerable and unanswerable questions in two different training settings: one with only answerable questions and another with both answerable and unanswerable questions? (2) How does RetinaQA perform for different categories of unanswerable questions? (3) How does RetinaQA perform in the answerable-only setting? (4) To what extent do the different components of RetinaQA contribute towards its performance in (1), (2) and (3) above?

heading: 4.1 Experimental Setup
text: Datasets: For research questions (1) and (2) above, we use the GrailQAbility dataset, which is the only KBQA dataset that contains both answerable and unanswerable questions. For research question (3), we use the two most popular KBQA datasets with only answerable questions, namely GrailQA and WebQSP.
GrailQA (Gu et al., 2021) is a popular KBQA dataset that contains only answerable questions. It contains questions at various levels of generalization: IID (seen schema elements), compositional (unseen combination of seen schema elements) and zero-shot (unseen schema elements). WebQSP (Yih et al., 2016) also has only answerable questions with Freebase as the KB, but unlike GrailQA, where the questions are synthetically constructed, it contains real user queries annotated with logical forms. It only has IID test questions. GrailQAbility (Patidar et al., 2023) is a recent dataset that adapts GrailQA to additionally incorporate unanswerable questions. The unanswerable questions are constructed by systematically dropping data and schema elements from the KB. More details are added in the Appendix (A.4). Evaluation Metrics: We primarily focus on evaluating the logical form using the Exact Match (EM) metric, which checks whether the predicted logical form is same as the gold logical form (which is NK for unanswerable questions with missing schema elements). We also evaluate the answers using the F1 score, which compares the predicted answer set with the gold answer set. For unanswerable questions, similar to prior work (Patidar et al., 2023), we report two F1 scores – the regular score F1(R) compares the list of answers based on the given incomplete KB, and the lenient score F1(L) which does not penalize a model for returning ideal
answers. Specifically, F1(L) accepts answers considering both KBs – the ideal or complete KB and new or incomplete KB. In a way, it evaluates the model’s ability to infer missing KB elements and predict the correct answer.
Baselines: We compare RetinaQA against existing state-of-the-art KBQA models, as per the GrailQA leaderboard and code availability. These are TIARA (Shu et al., 2022), RnG-KBQA (Ye et al., 2022), and Pangu (Gu et al., 2023). Of these, the first two are shown to the best performing models on GrailQAbility, and Pangu is a SoTA model for GrailQA3 and WebQSP (Gu et al., 2023). For fair comparison, we use the same entity linker (Ye et al., 2022) and T5-base as base LLM for all
3https://dki-lab.github.io/GrailQA/
models. For GrailQAbility, we adapt all models appropriately for unanswerability. Specifically, we perform thresholding (denoted as "+ T") on logical form generation to output NK. The thresholds are tuned on the dev set. Additionally, instead of training the models only on answerable questions (denoted as A training), we train the models using both answerable and unanswerable questions (denoted as A+U training). Further implementation details are in the Appendix (A.2).

heading: 4.2 Results for KBQA with Unanswerability
text: We first address research question (1). In Table 1, we report high-level performance of different models on GrailQAbility. With A+U training, RetinaQA+T outperforms all models overall and is about 9 pct points ahead of the closest competi-
tor (Pangu+T) in terms of EM. For unanswerable questions, RetinaQA achieves a 16 pct points improvement, while being consistently better for answerable questions. Unsurprisingly, thresholding helps all models for unanswerable questions and hurts slightly for answerable ones. This drop is relatively small for Pangu and RetinaQA, suggesting that these are better calibrated due to their discriminative training.
Next, we address research question (2). Table 2 drills down on performance for different categories of unanswerability. First, we observe that for the baselines, performance varies significantly across different categories. Pangu performs well for missing schema elements but is the worst model for missing data elements. TIARA is the best baseline for missing data elements but does not perform as well for missing schema elements. We further analyze such variability in performance for the baselines in the Appendix (Sec. A.3.1). RetinaQA performs the best by a large margin for questions with missing data elements, and compares favorably with Pangu for missing schema elements, making it the overall model of choice across different categories of unanswerability. We also note that RetinaQA+T results shows little degradation for questions with missing data (which have valid logical forms), and huge gains for questions with missing schema elements.
In the A training setting, as a testimony to its robustness, RetinaQA achieves comparable performance for answerable and unanswerable questions, with an EM gap of only 4 pct points. In contrast, this gap ranges 18 to 45 pct points for other models. Other trends are very similar to the A+U setting.
Additionally, we see that RetinaQA largely outperforms existing models across different generalization settings for answerable questions (Table 3). RetinaQA performs the best for IID and compositional generalization, but for zero-shot generaliza-
tion, RetinaQA performs slightly worse than Pangu. This is mainly because of the trade-off related to path traversal, as we explain in Section 4.4.
For unanswerable questions (Table 4), RetinaQA outperforms all existing models for both IID and zero-shot generalization. Furthermore, we observe that the difference between EM and F1(R) scores is the smallest by far for RetinaQA, indicating that it not only predicts unanswerability correctly but also does so for the right reason.
Additionally, In Table 5, we further scrutinize the performance of the models for sub-categories of zero-shot unanswerable questions. We observe that RnG-KBQA and Pangu perform better in terms of both EM and F1(R) for these categories. However, this is a natural benefit of mostly predicting L = NK for unanswerable questions, which results in extremely poor performance for the missing data element category, as we have already seen in Table 2. As seen earlier, here too all the baseline models have huge variations in performance across full z-shot and partial z-shot categories. This is in contrast to RetinaQA, which achieves comparable performance. It does so without compromising on performance for missing data elements category. This further establishes the stability of RetinaQA across various generalization categories and makes it more reliable for real-world scenarios.

heading: 4.3 Results for Answerable-only KBQA
text: We designed RetinaQA for stability across answerable and unanswerable questions, and this naturally trades off performance across the two categories. However, we observed that RetinaQA performed the best for answerable questions as well in GrailQAbility. Motivated by this, we next address research question (3), by evaluating it for traditional KBQA benchmarks with only answerable questions. Since all questions are answerable in this setting, we (re-)introduce Execution Guided Check (EGC) as the final step for all models including RetinaQA. With EGC, models output the highest-ranked logical form which when executed over the KB returns a non-empty answer.
In Table 6, we report results on GrailQA. We find that overall RetinaQA beats previous the stateof-the art by around 1.2 pct points in terms of F1 and 1.8 pct points in terms of EM, establishing a new state-of-the-art for this dataset. We also see that, as for answerable questions in GrailQAbility, here too RetinaQA performs the best for IID and compositional generalization, and performs almost at par with Pangu for zero-shot generalization.
Further analysis shows that RetinaQA performs well across questions of various complexities. It is the best model for 1, 2, and 4-hop questions, while it is outperformed by TIARA for 3-hop questions. More details are in the Appendix ( A.3.2).
In Table 7, we record results for WebQSP. Here, RetinaQA outperforms Pangu by 0.6 pct points but ranks below TIARA by 0.2 pct points. These numbers further establish the usefulness of its architecture for answerable-only KBQA as well.

heading: 4.4 Ablation Study
text: Finally, we address the research question (4). Here, we assess the individual contributions of the different components in RetinaQA. First, we remove (one at a time) the three key components: the logical form integrator (LFI), the logical form retriever
(LFR), and the coupled sketch generator (SG) and schema retriever (SR).
Our ablation study focuses on specific question categories. First, we study the recall of the correct logical form within the candidate set for unanswerable questions for missing data elements (see Table 12 in Appendix). We see that if we remove SR and SG, there is a significant 65 pct point decrease in recall. In contrast, removing LFR has little impact. This is because LFR relies on path traversal to retrieve candidate logical forms This fails when paths are incomplete, preventing RetinaQA from effectively enumerating logical forms. This agrees with our intuition that when essential data elements are missing, we need retrieval techniques that are independent of path traversal.
Next, we do a similar study of recall for answerable questions (Table 11 in Appendix). We observe that eliminating LFR leads to a significant reduction in recall for zero-shot questions. This is unlike removing SG and SR, which only affects i.i.d. questions. This is because retrieval techniques that do not rely on path traversal have a larger search space, resulting in more errors when encountering unseen schema elements. In contrast, path traversal-based methods are grounded at the fact level. This results in a smaller search space and therefore fewer errors for zero-shot questions. Thus, path-traversaldependent logical form retrieval is important for zero-shot generalization of answerable questions.
Finally, we evaluate the impact of LFI and EGC. Both reduce the space of logical form candidates for the discriminator, by pruning out invalid logical forms. Table 10 in the Appendix records performance of ablations of RetinaQA in the answerable setting on GrailQA. By switching off LFI and EGC separately, we see drops in performance by about 4 pct points and 2 pct points respectively. However, on switching off both together, we observe a 17 pct point drop. This shows that these components can compensate for each other, but RetinaQA needs at least one of them for good performance.
Additional ablations show that SG and SR are more helpful for complex (3-hop and 4-hop) questions. See Sec. A.3.2 for more details.

heading: 4.5 Error Analysis
text: We have done detailed error analysis for RetinaQA on GrailQAbility. Here, we present a brief summary of it. For this, we used the the best version RetinaQA, which is RetinaQA+T with A+U
training. We found three main error categories: (1) thresholding error, where, due to thresholding, RetinaQA incorrectly predicts NK for a question with a valid logical form; (2) reranking error, where the discriminator makes a mistake in scoring, though the candidates contain the correct logical form, and (3) recall error, where the correct logical form is not in the set of discriminator candidates. This may be due to errors in entity linking, logical form retrieval or logical form construction.
On the subset of answerable questions, thresholding and reranking errors occur for around 38%, and 30% of the total errors respectively. Improving discriminator calibration can potentially reduce these errors. The most frequent error is recall error (70%). Among these, entity linking errors occur 80% of the time. This clearly suggests that improving entity linkers can significantly improve the overall performance of KBQA models. Unsurprisingly, the majority of the errors across categories occur for the zero-shot generalization questions. Detailed statistics are in Table 8 in the Appendix.
For unanswerable questions, we first look at those with missing data elements (Table 9). We find that the vast majority of errors (around 90%) are recall errors, out of which about 72% are attributed to the entity linker. Next, thresholding error accounts for 45% of the total errors. Reranking errors only occur in 5% of total error. This suggests that while the ranking of the logical forms according to discriminator assigned scores is correct, the absolute scores have errors.
Finally, we look at the subset of unanswerable
questions with missing schema elements. Since for these the gold logical form is NK, thresholding error is the only source of error. This occurs for only 14% of the questions (under the same category), out of which 90% of errors occur for zero-shot generalization. This suggests that RetinaQA broadly performs well in this setting but the scores assigned to logical forms with unseen schema elements have occasional errors.

heading: 5 Conclusions
text: We have presented RetinaQA, the first specialized KBQA model that shows robust performance for both answerable and unanswerable questions. To address this challenging task, RetinaQA identifies candidate logical forms using data-traversal-based retrieval, as well as schema-based generation via sketch-filling that bridges over data gaps that break traversal. RetinaQA also discriminate between fully formed candidate logical forms at the final stage instead of generating these. This enables it to better differentiate between valid and invalid logical forms. In doing so, RetinaQA unifies key aspects of different existing KBQA models that assume answerability in IID and transfer settings.
Unlike superficial adaptations of existing SoTA models for unanswerability, we show that RetinaQA demonstrates stable performance across adaptation strategies, question categories (answerable and different categories of unanswerable questions) and different generalization settings. We also show that RetinaQA performs significantly better for unanswerable questions and almost at par for answerable ones. RetinaQA also performs well with only answerable training, which is a likely real-world scenario. RetinaQA also retains this stability and performance for answerable-only KBQA benchmarks, achieving a new state-of-the-art performance on the answerable-only GrailQA dataset. We release our code-base 4 for further research.
4https://github.com/dair-iitd/RetinaQA
Limitations
A sketch, while free of references to the KB, still specifies the length of the path to be traversed in the KB. The subsequent grounding step is limited by this and cannot adapt the path length after retrieving schema elements from the KB. RetinaQA inherits this limitation from existing sketch generation approaches (Cao et al., 2022; Ravishankar et al., 2022). We hope to improve this in future work.
For unanswerable questions without valid logical forms for the given KB, RetinaQA only outputs l =NK. However, this does not explain the gap in the schema, which, if bridged, would have make this question answerable. The situation is similar for unanswerable questions with valid logical forms but missing data elements. This is also an important area of future work.
Risks
Our work does not have any obvious risks.

heading: Acknowledgements
text: Prayushi is supported by a grant from Reliance Foundation. Mausam is supported by a contract with TCS, grants from IBM, Wipro, Verisk, and the Jai Gupta chair fellowship by IIT Delhi. We thank the IIT Delhi HPC facility for its computational resources.

heading: A Appendix
text: A.1 Entity Linker We use an off-the-shelf entity linker (Ye et al., 2022) previously used in the KBQA literature (Shu et al., 2022; Gu et al., 2023), which uses a standard 3-staged pipeline - Mention Detection, Candidate Generation, and Entity Disambiguation. Mention Detector first identifies span of text from question which corresponds to name of an entity. For each mention a set of candidates entities are generated using alias mapping of FACC1 (Gabrilovich et al., 2013). Final stage is a neural disambiguator which rank candidates given the question and context of entities.
A.2 Implementation Details
To perform experiments for GrailQAbility, we first update the original Freebase KG using codebase5. To test baselines for GrailQAbility, we use the existing codebases6 7 8 and make changes in code to adapt for answer-ability detection. All of the baselines assumes answerability and employs Execution Guide Check i.e. if a logical form returns an empty answer upon execution then they select next best logical form. We have removed this constraint while performing experiments for GrailQAbility. Also for A+U training we have made code changes so that models can be trained to predict logical form as NK unanswerable questions. We implement our model using Pytorch (Paszke et al., 2019) and Hugging Face9. All the experiments of RetinaQA are performed using an NVIDIA A100 GPU with 80 GB RAM. Above mentioned configurations are the maximum ones, since we have different components and all do not require same compute configurations. For Sketch Generation we fine tune
5https://github.com/dair-iitd/GrailQAbility 6https://github.com/dki-lab/Pangu 7https://github.com/microsoft/KC/tree/main/
papers/TIARA 8https://github.com/salesforce/rng-kbqa 9https://huggingface.co/
Seq2Seq t5-base model for 10 epochs (fixed). We use learning rate of 3e-5 and batch size of 8. We use beam search during decoding with beamsize = 10. We also check syntactic correctness while selecting top ranked sketch. For WebQSP sketch generator is trained for 15 epochs with batch size of 2 Training time for sketch parser is around 3 hours. LF Integrator is a parameter free module and does not require any training. Since, LF Integrator converts logical forms into query-graphs and validates type-level constraints, it is a costly operation. So we employ parallel processing(with cache) for this stage i.e. we use 4-6 CPUs (each with 2 cores) to create pool of valid logical forms. It takes around 5 hours to generate candidates for all train, dev and test data. Finally we train Discriminator which fine-tune t5-base Seq2Seq model. We train Discriminator with learning rate 1e-4 and batch size 4 for 10 epochs. For discriminator training we use AdmaW (Loshchilov and Hutter, 2019) optimizer and linear scheduler with warm up ratio of 0.01. We use 64 negative samples per question for contrastive training. Generally discriminator model converges in 2 epochs of training so we use patience of 2 i.e. if best model does not change for consequent 2 epochs then we assume model has converged and will stop training. It takes around 7- 8 hours to train a discriminator. We train WebQSP for 15 epochs with patience equal to 10 and 32 negative samples. Inference time for discriminator is few minutes.
For A+U training components like Entity Linker, Schema Retriever, LF Retriever are trained only on question where logical form is known. While training for questions with l ="NK" is performed only at last step.
All the results presented for single run (however the reproducibility of results is already verified).
We release our code-base10 for the community.
A.3 In Depth Analysis
A.3.1 Trade-off Analysis Sec 4.4 describes how individual components strengthens performance for different types of answerabilties and unanswerabilties. This section discusses an important trade-off i.e. Traversal dependent Retrieval Vs Traversal independent Retrieval : Traversal based Retrieval methods perform step by step enumeration over KB to retrieve next possible set of candidates(which is retrieval at data level). While Traversal independent Retrieval
10https://anonymous.4open.science/r/ RETINAQA-122B
based method generate candidates based on semantic similarity with the question(which is at schema level). So for Data Element Missing unanswerability where data paths are missing, Traversal based methods will never find correct path during enumeration and hence will not be able to reach to a correct logical form. While Traversal independent method can generate correct logical form. Hence Traversal independent methods performs well for data element missing. At the same time the search space for Traversal independent methods is much larger as it lacks KB grounding information. So for zero-shot generalisation where schema elements are unseen Traversal dependent tends to get confused between similar schema elements.
A.3.2 Complexity Analysis Tab. 13 records the performance of RetinaQA for queries of different complexities represented by number of relations in s-expression (or number of hops in answer path). We can see that for 1-hop and 2-hop questions RetinaQA is better than both baselines, while for 3-hop questions RetinaQA is not the best but is better than Pangu. Further by comparing ablations i.e. without Logical Form Retriever and without (Sketch Generation and Schema Retriever) we can see that Sketch Generation and Schema Retriever contribute more to the performance of 3-hop and 4-hop questions.
A.4 GrailQAbility - Dataset Creation
We summarise the dataset creation algorithm of GrailQAbility (Patidar et al., 2023) here. In a nutshell, the authors start with a standard KBQA
dataset containing only answerable questions for a given KB. Then they introduce unanswerability in steps, by deleting schema elements (entity types and relations) and data elements (entities and facts) from the given KB. They mark questions that become unanswerable as a result of each deletion with appropriate unanswerability labels. So starting from a larger set of all answerable questions, the authors create two subsets of data - one set of answerable questions and another set of unanswerable questions (which are unanswerable due to missing structures in graph/KB).

heading: Future Work
text: We hope to improve this in future work. For unanswerable questions without valid logical forms for the given KB, RetinaQA only outputs l =NK. However, this does not explain the gap in the schema, which, if bridged, would have make this question answerable. The situation is similar for unanswerable questions with valid logical forms but missing data elements. This is also an important area of future work. Risks
Our work does not have any obvious risks