SymKGQA: Few-Shot Knowledge Graph Question Answering via Symbolic Program Generation and Execution (2024)

Abstract: Semantic Parsing of natural language questions into their executable logical form (LF) has shown state-of-the-art (SOTA) performance for Knowledge Graph Question Answering (KGQA). However, these methods are not applicable for real-world applications, due to lack of KG-specific training data. Recent advances in the capabilities of Large Language Models (LLMs) has led towards generating low-level LFs such as SPARQL and S-Expression in a few-shot setting. Unfortunately, these methods: (1) are limited to the knowledge of underlying LLM about the LF, (2) performs inferior for the harder complex benchmarks such as KQA Pro, (3) suffers while grounding the generated LF to a specific Knowledge Graph. Recently, a new LF called KoPL (Cao et al., 2022a) has been introduced that explicitly models complex reasoning process step-by-step in a symbolic manner and has shown SOTA on KQA Pro in fully-supervised setting. Inspired by this, we propose SymKGQA1 framework that generates step-by-step Symbolic LF i.e., KoPL in a few-shot in-context learning setting using LLM. Our framework is not dependent on pre-trained knowledge of LLM about KoPL. We further build a Retrieval-Augmented Generation based Question-Aware Contextual KoPL (QUACK) resolver to ground the generated LF. Our experiments with different LLMs and few-shot settings demonstrate that SymKGQA outperforms all other few-shot and even many of the fully-supervised KGQA approaches.

heading: 1 Introduction
text: Knowledge Graph Question Answering (KGQA) has received a lot of research interest in recent years (Saxena et al., 2022; Zhang et al., 2022b;
*P. Agarwal is an employee at IBM Research. This work was carried out as part of PhD research at IIT Delhi. Email id: preragar@in.ibm.com
1Codebase and Data: https://github.com/data-iitd/ symKGQA
Mitra et al., 2022; Shu et al., 2022; Nie et al., 2022; Neelam et al., 2022). It aims at answering a natural language question using a structured Knowledge Graph (KG) by producing a logical form (LF) such as SPARQL, S-Expression, λ-DCS, etc. that is executed on the KG to retrieve the answer(s). When such techniques are used in applications such as intelligent assists, the annotated training data is generally not available at cold-start, thus, making it difficult to use these techniques without significant investment in building a large, generalizable (to the application) dataset to train the models on.
With recent advancements in Large Language Models (LLMs), the research is moving towards leveraging the reasoning capability of LLMs to obtain the LF for a given Natural Language Question (NLQ) in both fine-tuning (Ye et al., 2022; Shu et al., 2022; Gu et al., 2023) and few-shot settings (Gu et al., 2023; Li et al., 2023b). For few-shot setting, these works have used in-context learning (ICL) paradigm with various state-of-the-art LLMs such as GPT-3 (Brown et al., 2020) variants to generate LF. However, these methods suffer from the following limitations: (1) their LF generative capabilities are limited to the pre-trained knowledge of the underlying LLM about the grammar and semantics of the LF (SPARQL or S-expression). (2) this also results in their inferior performance for harder complex KGQA benchmarks such as KQA Pro (Cao et al., 2022a; Huang et al., 2023). These benchmarks require explicit modeling of KG complexities such as concepts, attributes, qualifiers, etc. to perform joint compositional and numerical reasoning that may not be seen by the LLM. (3) their KG grounding formulation is independent of the context of the question, which limits their performance.
Due to the recent surge in the complexity of questions that users pose to Question Answering (QA) systems, complex KGQA has particularly gained attention (Huang et al., 2023). Complex
10119
questions require joint compositional and numerical reasoning on KG to answer them. Some of the works have demonstrated that step-by-step Chainof-Thought (CoT) decomposition of the reasoning process is one of the key factors in enhancing the reasoning capability of LLMs for QA tasks (Wei et al., 2023; Zhou et al., 2023; Niu et al., 2023). However, a recent shift towards decomposing the problem with symbolic formalization i.e., Chainof-Symbol (CoS) (Hu et al., 2023) has emerged as another key factor to observe further enhancements in reasoning (Zhang et al., 2022a; Wolfson et al., 2020). Additionally, some of the works (Cao et al., 2022a; Nie et al., 2022; Liu et al., 2024) have shown that using the same underlying model with LFs having high to low formalization i.e., dissimilarity to natural language has shown an inverse trend in the performance for KGQA.
Recently, KoPL (Cao et al., 2022a), a symbolic LF has been introduced that defines various functions (operations) on KG catering to various complexities. It reflects the CoS reasoning process as compared to other LFs that have to be used as a whole query (Huang et al., 2023; Liu et al., 2024). Its modular functions and their inputs make it suitable for complex compositional and numerical reasoning while being interpretable. Figure 1 shows an example of a complex question and its corresponding LFs with high (top) to low (bottom) level of formalization. As shown, KoPL is most decomposable, interpretable LF while having symbolic formalization to solve complex questions.
Another challenge that most of the existing LLMbased techniques face while generating LF for KGQA is - that LLM picks KG items (entities, relations, etc.) based on its inherent knowledge or picks an appropriate phrase from the input question. These items have to be grounded/resolved for a KG before the generated LF can be executed. To illustrate this, consider the generated KoPL in Figure 1. The functional input of Step 3 is occupy that does not exist in the KG and the closest relations in the KG are {mass, area, etc.}. The existing methods pick the closest relation based on the similarity between occupy and the candidates {mass (0.912), area (0.84)}. Hence, they would pick mass due to its higher similarity than area. However, if we consider an additional context of the input question while choosing the closest relation, area should be chosen (desired relation). Existing methods do
2BERT similarity score
not take into consideration this context of the input question and hence, suffer in grounding the LF.
Addressing the above-discussed challenges, the contributions of our work are as follows:
1. We propose SymKGQA: a KGQA framework specifically designed to generate Symbolic KoPL program for a given complex natural language question using LLMs in a few-shot setting.
2. We further build a Retrieval-Augmented Generation (RAG) (Lewis et al., 2020) based QuestionAware Contextual KoPL (QUACK) resolver to ground the generated KoPL for a given KG.
3. We experiment with different LLMs on 3 datasets with varying complexity of questions and KG to demonstrate the flexibility and robustness of our approach. We adopt the few-shot ICL paradigm with KoPL function definitions and instructions as prompt to generate CoS KoPL programs. This prompting approach makes SymKGQA independent of the pretrained knowledge of the underlying LLM about KoPL.
Popular KGQA datasets such as MetaQA (Zhang et al., 2018), WebQSP (Yih et al., 2016), etc. has sparse coverage of complex questions. On the other hand, a recently introduced KQA Pro dataset (Cao et al., 2022a) contains much harder complex QA pairs that require compositional and numerical reasoning as compared to other datasets such as GrailQA (Gu et al., 2021; Dutt et al., 2023). Thus, this work utilizes KQA Pro as the core benchmark dataset for experiments.
Our extensive experiments demonstrate that SymKGQA outperforms all other LLM-based fewshot and even most of the SOTA fully-supervised KGQA approaches by a significant margin. To the best of our knowledge, SymKGQA is the first fewshot KGQA framework that uses a CoS approach (using KoPLs) with RAG-based QUACK resolver.

heading: 2 Related Work

heading: 2.1 Fully-Supervised KGQA methods
text: These KGQA techniques requires a large amount of annotated training data to learn the model. They are further divided into 2 sub-categories: (1) Semantic Parsing based techniques: This includes methods (Shu et al., 2022; Nie et al., 2022; Neelam et al., 2022) that transform the natural language question into LF, such as SPARQL, Sexpression, etc. that are directly executable on KG to retrieve the answer. KQA Pro (Cao et al., 2022a) work also provides a technique to learn questions to KoPL/SPARQL mapping using scratch training of sequence-to-sequence models such as BART. Recently, a new intermediate representation (Nie et al., 2022) i.e., GraphQ IR has been introduced that has a language-like expression to define the syntax. They demonstrate that the performance obtained with BART + GraphQ IR > BART + KoPL > BART + SPARQL. These works have shown SOTA on the KQA Pro dataset. Among these LFs, only KoPL is symbolic in nature that enables CoS. (2) Information Retrieval based techniques: This includes end-to-end learning approaches that are not tied to any specific KG (Miller et al., 2016; Saxena et al., 2020; Shi et al., 2021; Zhang et al., 2022b; Mitra et al., 2022; Saxena et al., 2022). These techniques use only QA pairs with KG triples to rank candidate entities for a given question. These techniques also require a large amount of QA pairs data for learning and can’t be used if the data is not available at cold-start.
Both categories of techniques have shown SOTA performance on specific datasets, however, highly sensitive to a large amount of manually annotated data for learning. Hence, none of these techniques can be adopted for practical applications where KG specific training data is not available.

heading: 2.2 Few-Shot KGQA methods
text: Recent advancements in the development of various pre-trained LLMs, such as T5 (Raffel et al., 2023) and Codex (Chen et al., 2021), have shown SOTA performance on various downstream tasks. Some of the LLM based frameworks have been proposed for KGQA task as well. RnGKBQA (Ye et al., 2022), TIARA (Shu et al., 2022), KB_BINDER (Li et al., 2023a) and similar works convert natural language sequences to SExpression with constrained decoding using LLMs. Pangu (Gu et al., 2023) capitalizes on the dis-
criminative ability of LLMs rather than generation. BYOKG (Bring Your Own KG) (Agarwal et al., 2023) leverages an LLM-based symbolic agent to comprehend KG information through exploration. It starts at random nodes, inspecting the labels of adjacent nodes and edges, and combining them with their prior world knowledge. FlexKBQA (Li et al., 2023b) introduces an execution-guided selftraining method and surpasses all other few-shot methods. These techniques generate low-level LFs such as SPARQL, and S-expressions but suffers from various limitations (discussed in Section 1).

heading: 3 Proposed Framework: SymKGQA
text: We first briefly define the problem statement and then introduce the details of SymKGQA framework shown in Figure 2, which consists of two stages: (1) KoPL Generation: using Few-Shot ICL; and (2) RAG based QUACK Resolver.

heading: 3.1 Problem Statement
text: The goal of the SymKGQA framework is:
1. Generate the CoS KoPL program steps (P ) for a given natural language question (Q) using a pre-trained LLM (M ) by providing a prompt (Y ).
2. Execute P , on KG K, with the help of QUACK resolver, to obtain the final answer(s). Here, K ⊂ E ×R× (E ∪L ∪C), where C is the set of concepts3, E is the set of entities, L is the set of attributes/literals and R a set of binary relations.

heading: 3.2 Generation: Few-Shot ICL Prompting
text: As mentioned earlier, we adopt the ICL paradigm to generate the CoS KoPL steps for a given complex natural language question using a pre-trained LLM. We first create a prompt Y = (I, F,D) that consists of a set of Instructions I , KoPL Function Information F , and Few-Shot Demonstrations D (also shown in Figure 2). Instructions I: It describes the task and outlines generation policies for program steps P . Few instructions are shown below. Refer to Appendix A.1 for a full set of instructions.
Instructions
- The task is to come up with the steps of functions for the given test question using the list of functions provided. - To generate these steps you should match the output of the current step function with functional inputs of the next step function. ....
3A concept is an abstraction of a set of entities
Function Information F : We provide the information of all 27 KoPL functions for the LLM to understand and use them in the generation process (shown below). Refer to Appendix A.1 to find the details of all 27 KoPL functions. We specifically provide the function name, description, inputs (functional and textual), and outputs. The functional inputs come from the previous program steps whereas the textual inputs come from the question.
Function Information
Function Name: Relate Description - Find entities that have a specific relation with the given entity in the knowledge graph Functional Inputs - Entity Textual Inputs - (Predicate, Direction) Outputs - (Entities, Facts)
Demonstration Selection D: The demonstration selection is a crucial part of generation. The demonstration questions should be selected such that their KoPL program steps cover all functions. Here, we don’t require annotated KoPLs for the full training dataset, we just need them to create a pool of fewshots (approx. 10 − 100 questions), as described below. We experiment with the below methods to select n = 10 demonstration questions for ICL:
• Manual selection: Here, we manually select n = 10 natural language questions from the train set keeping in mind that their KoPL program steps, when annotated, would cover a maximum number of functions with minimal overlap to obtain diverse yet complete demonstration set D. For all the test questions of a particular dataset, D will remain fixed. Refer to Appendix A.1 for the n manually chosen set D.
• Dynamic selection: We perform function coverage-based pool selection of N (100) natural language questions from the train set inspired from “bottom-up matching" in (Drozdov et al., 2022). 1. Pool Creation (N): Since, Find and FindAll functions appear with almost all other remaining 25 functions, we randomly select k = N/25 questions that specifically demonstrate each of the 25 functions (except Find and FindAll). This ensures diversity and coverage of all functions. 2. Obtaining D (n): We build a retriever with the pool to retrieve top n = 10 nearest neighbor questions to the test question as D. After experimentation, we chose ChromaDB4, a vector-based retriever, due to its superior performance (5 − 7%) as compared to popular BM25 retriever (Robertson and Zaragoza, 2009). We mask the entities and concepts in the question to exclude their interference in determination of semantic similarity. Cosine similarity is used as the distance metric. The value of n is also dependent on the prompt length supported by an LLM. The demonstration set D of size n = 10 thus obtained is added to the prompt using the template shown.
The template, however, requires the set of entities and concepts (if present) to be annotated for each demonstration d ∈ D in the prompt using the KG. The same template is used to add the test question also in the prompt. Entity and Concept Identification: For a given complex natural language question Q during testing, the set of concepts C ′ ⊂ C and the set of entities E′ ⊂ E present in Q can be annotated using any off-the-shelf entity linker such as (Gu et al.,
4https://docs.trychroma.com/
2023; Mohammed et al., 2018) popularly used in KGQA, Named Entity Recognition (NER) methods, POS tags, or can be explicitly provided. We use NER as the entity linker for SymKGQA.
Training Example i
Question: Does Pierce County that is located in Washington or Grays Harbor County have less area? Entities: [’Washington’, ’Pierce County’, ’Grays Harbor County’], Concepts: None. The steps to solve this question are: Output: Step 1: Find(Washington) Step 2: Relate(located in the administrative territorial entity, backward) Step 3: Find(Pierce County) Step 4: And() Step 5: Find(Grays Harbor County) Step 6: SelectBetween(area, less)
After assembling the prompt Y using I , F and D, the LLM is now supposed to generate the correct CoS KoPL program steps for each test question conditioned on prompt Y and Q.
Adding I and F makes Y independent of the pretrained knowledge of the underlying LLM about the LF (i.e., KoPL) while handling complex questions. This prompting technique is applicable to any LF supporting CoS-based reasoning. Appendix A.1 contains the complete prompt for a sample test question. We compare prompt templates used by existing approaches and SymKGQA (Appendix A.2). Hyperparameter details for generation are provided in Section 4.4.
3.3 RAG based QUACK (Question-Aware Contextual KoPL) Resolver
The KoPL steps generated by LLM can have discrepancies in terms of: (a) entity and concept names; (b) relations and attributes; (c) numerical operators; (d) numerical quantity and their units; and (e) symbolic functions. This would hinder the direct execution of the generated steps on the KG. Hence, we resolve each program step with the help of RAG before executing it. Resolution: We resolve each of the above defined discrepancy, as described below:
1. Entity and Concept Names: The entity and concept names present in the generated program can be semantically similar but not grounded to a KG due to: (a) imperfect identification of E′ and C ′ by entity linker during the prompt creation. (b) LLM discards the identified E′ and C ′ and hallucinates based on its inherent knowledge. Hence, to resolve such cases, we use the following approach:
(a) Retrieval: Top 10 similar entities/concepts from the KG for each entity/concept name present in the generated step are retrieved. BERT based semantic similarity retriever is used to achieve this. (b) Generation: LLM is prompted with the retrieved list along with the question to select the most probable entity/concept from the given list. to prevent hallucinations. The prompt template used at this step is shown in Figure 2. More details on the RAG approach are provided in Appendix A.3.
2. Relation and Attribute Names: LLM chooses relations/attributes present in Q itself while generating program steps due to the absence of relation/attribute linkers. Hence, it needs to be grounded for the KG explicitly. We use the same RAG approach as (1). At the retrieval step, the top 10 similar relations/attributes from the KG for each generated relation/attribute name are retrieved. At the Generation step, LLM selects the most probable relation/attribute in the context of Q. A sample prompt is shown below:
Resolution Prompt
From below relation list, select only top relation that is most similar to the relation extracted from question.
Question: What is the higher education institution is headquartered in the city whose postal code is 20157?
Relation list = [’headquarters location’, ’work location’, ’located in the administrative territorial entity’, ’capital of’, ’located in time zone’, ’residence’, ’capital’, ’country’, ’filming location’, ’place of birth’] Relation extracted from the Question: [’headquartered in’] Answer:
3. Numerical Operators: Sometimes, the numerical operators such as {<, >, =}, etc. are either missing from the “textual input" of the KoPL function or represented in textual form (such as “less than", “greater than", etc). However, the KoPL executor requires the numerical operator in the form of symbol. Hence, to correctly identify the numerical operator symbol from Q, we provide the list of pre-defined numerical operators5 for the LLM to pick the right one in the context of Q using the same RAG approach as (1).
4. Numerical Quantity and Units: The numerical quantity unit present in Q and the unit present in the KG for that attribute can be different. Hence, it is important to normalize the numerical quantity
5Refer to Appendix A.4 for the list of numerical operators
present in Q into the unit present in the KG. We use sympy6 python library to achieve this.
5. Symbolic Function Names: As illustrated in Figure 1, sometimes LLM picks wrong symbolic function names but generates logically correct steps. In Figure 1, the model generated FilterStr at Step 3 but the functional input is a number with an operator. Considering the context of the question, the correct function that should be executed is FilterNum. To rectify such functional errors, we use the same RAG approach as (1). At retrieval step, the set of functions with the same functional inputs (from the previous step) and textual inputs (corrected using the above-described resolutions) that are possible at the current step are retrieved. Then, the most probable function to be used in the context of Q is selected at Generation step. Most of the existing methods such as (Li et al., 2023a) use only lexicon-based similarity to select top-k closest entities and relations (without considering Q as context) to resolve the LF. On the other hand, our approach utilize Q as the context so that the interconnected constraints among entities, concepts, relations, etc. are considered in a unified way while choosing the most relevant KG item. Execution: The resolved KoPL program steps are then executed on the KG as per the default KoPL executor provided (Cao et al., 2022a).

heading: 4 Experiments
text: Our experiments are outlined to answer the following research questions: (1) How does SymKGQA compare against existing KGQA frameworks in few-shot setting? (2) How does the performance of SymKGQA vary with different pre-trained LLMs and demonstration selection methods? (3) What are the contributions of each stage of SymKGQA?

heading: 4.1 Datasets
text: We experiment with 3 datasets with different: (a) question complexities; (b) KG domain; and (c) number of inference hops required. The statistics of these datasets are shown in Table 1.
1. KQA Pro (Cao et al., 2022a): This is a very recent dataset based on Wikidata KG and contains complex QA pairs with numerical quantities, concepts and entities for multi-hop compositional and numerical reasoning. It contains questions that require up to 10 hops to obtain the answer(s). The
6https://pypi.org/project/sympy/
test set is closed, hence, we use the validation set as the test set for our experiments.
2. MetaQA (Zhang et al., 2018): It is a largescale multi-hop dataset widely used for domainspecific KGQA (movie domain). It provides 1-hop, 2-hop, and 3-hop QA pairs.
3. WebQSP (Yih et al., 2016): This dataset contains natural language questions up to 2 hops from Google query logs answerable through Freebase KG. We sample N = 100 questions (explained in Section 3.2) to create the pool for dynamic demonstration selection and annotate their KoPLs.

heading: 4.2 Models
text: We experiment with below SOTA LLMs with varying number of parameters:
1. CodeLlama Instruct (34B) (Rozière et al., 2023): A code-focused LLM, built upon Llama 2. It can follow programming instructions without prior training for various programming tasks. The prompt/context limit of this model is 4K tokens.
2. Llama-2 (70B) (Touvron et al., 2023): It is an auto-regressive model that uses an optimized transformer architecture. The prompt/context limit of this model is 4K tokens.
3. PaLM 2 (540B) (Chowdhery et al., 2022): One of the SOTA LLM with improved multilingual, reasoning, and coding capabilities. We use text-bison-001 version of this model. The prompt/context limit of this model is 8K tokens.
4. GPT3.5-turbo: Due to the costs associated with the API, we randomly sample 100 questions from the test set of each of the three datasets and compare the performance with other models.

heading: 4.3 Baselines
text: We select the following 3 categories of baselines:
• Fully Supervised: We compare with SOTA fully supervised techniques for each dataset. It includes KVMemNet (Miller et al., 2016), EmbedKGQA (Saxena et al., 2020) for all datasets and:
1. MetaQA: SRN (Qiu et al., 2020), PullNet (Sun et al., 2019), NSM (He et al., 2021) and TransferNet (Shi et al., 2021).
2. KQA Pro: SRN, RGCN (Schlichtkrull et al., 2018), Subgraph Retrieval (Zhang et al., 2022b), BART + KoPL (Cao et al., 2022a), GraphQ IR (Nie et al., 2022).
3. WebQSP: DecAF (Yu et al., 2023), Subgraph Retrieval (Zhang et al., 2022b) and Program Transfer (Cao et al., 2022b).
• Few-Shot: We compare with few-shot techniques that have shown SOTA for each dataset:
1. KQA Pro: FlexKBQA (Li et al., 2023b) and LLM-ICL7 both generating SPARQL.
2. WebQSP: FlexKBQA, KB_BINDER (Li et al., 2023a) and Pangu (Gu et al., 2023) all generating S-Expression. We use KB_BINDER (1) setting for fair comparison.
There are no few-shot baselines that has bench-
7Alternate to Pangu for evaluation (as used in FlexKBQA)
marked MetaQA8. • Direct QA: LLMs are pre-trained on a large body of knowledge. Hence, we ask the question directly to the LLM to obtain the answer(s). Refer to Appendix A.6 for more details on the techniques adopted by each of the baseline.

heading: 4.4 Implementation and Hyper-parameters
text: PyTorch9 Python framework is used to implement SymKGQA. Greedy decoding is used to obtain the KoPL program steps from the LLMs (for reproducibility). Additionally, the program steps are obtained using 2 iterations of sampling decoding (for exploration) with temperature=0.3 and top_k=30 to handle the cases where the program steps generated from greedy decoding (after applying QUACK resolution) results in error. We use n = 10 and N = 100 shots for manual and dynamic demonstration selection. all-distilroberta-v110 BERT model is used at the retrieval step in QUACK. Hits@1 for KQA Pro and MetaQA, F1 score for WebQSP are the evaluation metrics used to evaluate and compare the performance of SymKGQA with baselines.

heading: 5 Results and Analysis
text: We discuss the results of SymKGQA on each dataset in detail. Qualitative analysis examples are provided in Appendix A.5.
8Benchmarking FlexKBQA, KB_BINDER and Pangu was not feasible due to closed access of GPT3.5 models.
9https://pypi.org/project/torch/ 10https://huggingface.co/sentence-transformers/
all-distilroberta-v1

heading: 5.1 Results on KQA Pro
text: The results of SymKGQA compared with different baselines are shown in Table 3. The detailed category-wise performance is provided in Table 4. As shown, SymKGQA with CodeLlama Instruct model outperforms all few-shot baselines and achieves a new SOTA in the few-shot setting for KQA Pro. Specifically, SymKGQA beats FlexKBQA by 8% and LLM-ICL by 24% (both generates SPARQL using GPT-3 variants).
The performance with PaLM 2 and Llama-2 LLMs are comparable but inferior to what we observe with CodeLlama Instruct. The performance with dynamic demonstration selection is higher than the manual selection method. SymKGQA even outperforms all fully-supervised baselines except BART + KoPL and GraphQ IR. For the sampled test set with 100 questions (shown in Table 6), the performance of SymKGQA with GPT3.5-turbo beats all other LLMs by a huge margin. Hence, this encourages us to believe that SymKGQA when used with GPT3.5-turbo has the potential to surpass BART + KoPL and GraphQ IR baselines when evaluated on a full test set.

heading: 5.2 Results on WebQSP
text: The results of SymKGQA for the WebQSP dataset are shown in Table 2a. As shown, SymKGQA achieves a new SOTA in the few-shot setting for WebQSP outperforming all few-shot baselines. All few-shot baselines generates S-Expression. SymKGQA even beats all fully supervised baselines except DecAF where the performance of SymKGQA is slightly less. The performance with dynamic demonstration selection is higher than the manual selection method. For the sampled test set with 100 questions (see Table 6), the performance of SymKGQA with GPT3.5-turbo is a bit lower than other LLMs except for CodeLlama Instruct.

heading: 5.3 Results on MetaQA
text: The results of SymKGQA for the MetaQA dataset are shown in Table 2b. As shown, SymKGQA achieves a new SOTA for 1-hop with all 3 LLMs. For 2-hop and 3-hop, SymKGQA even beats
all fully supervised baselines except TransferNet where the performance is nearly the same. The performance with dynamic demonstration selection is slightly higher than the manual selection method. For the sampled test set (shown in Table 6), the performance of SymKGQA with GPT3.5-turbo is nearly the same as all other LLMs.

heading: 5.4 Observations
text: Overall, we observed the following: 1. The low performance of the Direct QA base-
lines for all datasets indicates that LLMs inherently don’t have sufficient knowledge to answer the questions and hence, are not biased by their inherent knowledge during KoPL generation. 2. The difference in the performance with fullysupervised baselines is attributed to the use of a large amount of annotated LF data as strong supervision signals during learning, whereas, our framework addresses a more challenging few-shot setting, assuming only few-shot availability. 3. The performance of SymKGQA with dynamic selection is expected to increase further as N increases. 4. GPT3.5-turbo has the better ability to provide reasoning over complex questions (KQA Pro) as compared to other models, whereas, all the models possess similar ability to handle simpler questions (MetaQA and WebSQP). Note: Few-shot and fully supervised approaches can not be compared directly. However, we make this comparison only to show that SymKGQA is able to perform better than fully supervised methods in many scenarios. There is still some performance gap with fully supervised approaches that suggests potential avenues for future research.

heading: 5.5 Ablation Study
text: Table 5 shows the SymKGQA performance when: 1. Programs generated using sampling decoding (for exploration) are eliminated while obtaining the answers. On this elimination, the performance dropped by 6-14% for KQA Pro dataset. This high-
lights the importance of the sampling decoding in the framework. However, not much variation is observed in the generation and hence, in performance for MetaQA and WebQSP due to the simplicity of the programs for this dataset.
2. QUACK resolver is eliminated while obtaining the answers. For MetaQA 2 and 3-hop, none of the generated KoPLs were directly executable and required one or more resolutions. Hence, removal of the QUACK resolver shows a huge drop in the performance of the model. However, the proposed QUACK resolver is able to resolve most of the generated KoPL program steps and interpret them semantically and not just syntactically. The quantification of decrease in the performance demonstrates the importance and contribution of each stage.

heading: 5.6 Error Analysis
text: We analyze the following sources of errors in SymKGQA (on an average across different LLMs):
• Entity Linking: Incorrect entity and concept linking after the QUACK resolver is observed only in KQA Pro, for 1.5% of questions. No such issues are observed in MetaQA and WebQSP.
• Mismatch in Input-Output types of the generated steps: Errors in program execution due to mismatch in input-output types of the steps generated are seen only for KQA Pro, for 29% of questions. No such errors are seen for MetaQA and WebQSP.
• Incorrect KG Grounding by QUACK Resolution: The wrong answers obtained due to incorrect grounding of KG components (other than entity
and concepts) by the QUACK resolver is observed in KQA Pro, for 14% and WebQSP, for 20% of questions. No such issue is observed for MetaQA. A detailed analysis is provided in Appendix A.3.

heading: 5.7 Inference Latency
text: We make API calls LLMs for the generation of KoPL programs with average latency of 5s/call that runs on CPU. We use NVIDIA V100 GPU with 32 GB RAM for QUACK resolution and execution. On an average it consumes following GPU hours:
• 3 Hrs: Execution and Resolution for 11,797 test questions of KQA Pro
• 2 Hrs: Execution and Resolution for 1,639 test questions of WebQSP
• 3 Hrs: Execution and Resolution for 13,031 test questions of MetaQA (average of all hops).

heading: 6 Conclusion
text: We propose SymKGQA, that generates and executes symbolic programs (KoPL) in a few-shot setting. To the best of our knowledge, it is the first one to generate KoPL LF using LLMs for complex KGQA. We provide a method for LLM prompt generation with manual and dynamic demonstration selection for few-shot ICL. We further propose a RAG based Question-Aware Contextual KoPL (QUACK) Resolver that grounds the generated KoPL for a KG. Our extensive experiments shows that SymKGQA surpass all few-shot and most of the fully supervised SOTA baselines, setting a new benchmark for various complex KGQA datasets. Our approach being independent of underlying LLM knowledge, makes it applicable for any other symbolic LF while being interpretable.

heading: 7 Acknowledgements
text: This work was supported by an IBM AI Horizons Network (AIHN) grant. Srikanta Bedathur was partially supported by a DS Chair of AI fellowship.

heading: 8 Limitations
text: Despite the strong reasoning capabilities of SOTA LLMs, obtaining step-by-step CoS program may be prone to errors, which can impact the performance of SymKGQA, as discussed in Section 5.6. Most of the errors stem from a mismatch between the input-output type of the subsequent generated steps. Fortunately, these errors are generally interpretable and can be rectified with human intervention.

heading: 9 Risks
text: Our work does not have any obvious risks that we are aware of.

heading: A Appendix
text: A.1 Few-Shot ICL Prompt
Full prompt for a sample test question of KQA Pro is shown in Figure 3.
A.2 Few-Shot ICL Prompt Templates of Existing Methods
Full prompt for a sample test question of KQA Pro is shown in Table 10.
A.3 RAG based QUACK Resolver
Retriever: The full set of each KG item i.e., entities, concepts, relations, attributes, qualifiers, etc. are indexed separately in ChromaDB. The KG item generated at each step is used as the input query to retrieve the top-10 closest corresponding KG item. The retrieved list is then passed to the LLM using the prompt shown in Figure 2 (Generation). This approach of encoding each KG item set separately provides the following advantages over indexing triples for retrieval:
For the grounding task, the grounding of each generated KG item has to be done w.r.t that item only. For example: if we consider the grounding of the generated relations, it has to be picked from the set of relations in the KG only. It will never be picked up from the set of other KG items i.e., entities, concepts, etc. Hence, indexing each KG item set separately provides constraint retrieval.
Given that the input query will be the generated relation, on the other hand, if the triples of the KG are indexed, then the retrieved triples will not be constrained to the relations. It will contain the corresponding entities as well that could be irrelevant for a given question and hence introduce some noise in the retriever output.
We experiment with both these approaches and found out that indexing KG items separately provides provides superior performance (8 − 10%) than indexing KG triples. Generation: Here, we adapt the generation step in RAG by using the discriminative ability of the LLM instead of generation to select the most probable entity/concept from the given list to prevent hallucinations.
We further perform in-depth analysis of effectiveness of our proposed QUACK resolver on KQA Pro dataset. Table 7 shows the QUACK performance (Accuracy) mainly for entities/concepts and relations/attributes.
A.4 List of Numerical Operators The list of the numerical operators supported are as follows: [<,≤, >,≥,=, ̸=, argmin, argmax]
A.5 Qualitative Analysis of the Generated KoPLs
The examples of the generated KoPL steps that are not directly executable before QUACK resolver and executes correctly after QUACK resolution for each dataset are shown in Table 8. The examples of the generated KoPL steps that resulted in error (failure cases) during execution even after QUACK resolver are shown in Table 9.
A.6 Baselines • Pangu (Gu et al., 2023) is a recent SOTA
KGQA model. It uses LLMs for discrimination rather than generation for grounding the generated draft. It incrementally constructs plans in a step-wise fashion to handle large search spaces.
• KB_BINDER (Li et al., 2023a) enables fewshot learning for KBQA using LLMs through two key stages: Draft Generation, where given a question, an LLM generates a preliminary “draft” logical form using few-shot examples; and Knowledge Base Binding, where entities and relations in the draft are grounded to the target KG using string matching and similarity search.
• LLM-ICL is an in-context learning-based baseline we implement for KQA Pro. As there are no experimental results of Pangu and KB_BINDER on KQA Pro, we use LLM-ICL as an alternative. Since KQA Pro models do not include an entity linking stage, LLM-ICL directly generates SPARQL queries without further grounding stage, ensuring a fair comparison.
• KVMemNet (Miller et al., 2016) performs QA by first storing facts in a key-value structured memory before reasoning on them in order to predict an answer. At each reasoning step, the collected information from the
memory is cumulatively added to the original query to build context for the next reasoning iteration.
• SRN (Qiu et al., 2020) model starts from the question entity and uses a path search technique to predict the relation path sequence to reach the target entity.
• RGCN (Schlichtkrull et al., 2018) uses a graph convolution network-based technique to encode the KG into graph form and perform QA.
• EmbedKGQA (Saxena et al., 2020) uses KG embeddings to perform multi-hop reasoning using a RoBERTa-based question encoder.
• Subgraph Retrieval (Zhang et al., 2022b) use a dual-encoder that provides better retrieval as compared to the existing retrieval methods.
• PullNet (Sun et al., 2019) extracts a question specific subgraph from the entire relation graph using a graph CNN instead of heuristics and then retrieves the answer.
• NSM (He et al., 2021) propose a teacherstudent approach. The student network aims to find the correct answer to the query, while the teacher network tries to learn intermediate supervision signals for improving the reasoning capacity of the student network. They utilize both forward and backward reasoning to enhance the learning of intermediate entity distributions.
• BART + KoPL (Cao et al., 2022a) is an end-to-end generation model that directly produces the corresponding KoPL program steps given a question. It is worth noting that the pre-trained BART model is forced to have the capability to memorize the relations and entities present in the KG.
• GraphQ IR (Nie et al., 2022) proposes a unified intermediate representation for graph query languages, named GraphQ IR. It has a natural-language-like expression that bridges the semantic gap and formally defined syntax that maintains the graph structure. A neural semantic parser is used to convert user queries into GraphQ IR, which can be later losslessly compiled into various downstream
graph query languages such as SPARQL, Lambda DCS, etc.
• TransferNet (Shi et al., 2021) answers multihop questions by attending to different parts of the question at each step. It then computes activated scores for relations, and then transfers the previous entity scores along activated relations in a differentiable way.
• FlexKBQA (Li et al., 2023b) utilizing Large Language Models (LLMs) as program translators. It leverages automated algorithms to sample diverse programs, such as SPARQL queries, from the knowledge base, which are subsequently converted into natural language questions via LLMs. They use this synthetic dataset to facilitate training of a specialized lightweight model for a KG.
• DecAF (Yu et al., 2023) jointly generates both logical forms and direct answers and then combines the merits of them to get the final answers. They treat logical forms as regular text strings just like answers during generation, reducing efforts of hand-crafted engineering. DecAF linearizes KG into text documents and leverages free-text retrieval methods to locate relevant sub-graphs.
- FilterDate Description - Similar to FilterStr, except that the attribute type is date in the knowledge graph Functional Inputs - Entities Textual Inputs - (Key, Value, Operation) Outputs - (Entities, Facts)
- QFilterStr Description - Filter entities and corresponding facts with a qualifier condition of string type in the knowledge graph Functional Inputs - Entities Textual Inputs - (Qualifier Key, Qualifier Value) Outputs - (Entities, Facts)
- QFilterNum Description - Similar to QFilterStr, except that the qualifier type is number in the knowledge graph Functional Inputs - Entities Textual Inputs - (Qualifier Key, Qualifier Value, Operation) Outputs - (Entities, Facts)
- QFilterYear Description - Similar to QFilterStr, except that the qualifier type is year in the knowledge graph Functional Inputs - Entities Textual Inputs - (Qualifier Key, Qualifier Value, Operation) Outputs - (Entities, Facts)
- QFilterDate Description - Similar to QFilterStr, except that the qualifier type is date in the knowledge graph Functional Inputs - Entities Textual Inputs - (Qualifier Key, Qualifier Value, Operation) Outputs - (Entities, Facts)
- Relate Description - Find entities that have a specific relation with the given entity in the knowledge graph Functional Inputs - Entity Textual Inputs - (Predicate, Direction) Outputs - (Entities, Facts)
- And Description - Return the intersection of two entity sets in the knowledge graph Functional Inputs - (Entities, Entities) Textual Inputs - None Outputs - Entities
- Or Description - Return the union of two entity sets in the knowledge graph Functional Inputs - (Entities, Entities) Textual Inputs - None Outputs - Entities
- QueryName Description - Return the entity name in the knowledge graph Functional Inputs - Entity Textual Inputs - None Outputs - string
- Count Description - Return the number of entities in the knowledge graph Functional Inputs - Entity Textual Inputs - None Outputs - number
- QueryAttr Description - Return the attribute value of the entity in the knowledge graph Functional Inputs - Entity Textual Inputs - Key Outputs - Value
- QueryAttrUnderCondition Description - Return the attribute value whose corresponding fact should satisfy the qualifier condition in the knowledge graph Functional Inputs - Entity Textual Inputs - (Key, Qualifier Key, Qualifier Value) Outputs - Value
- QueryRelation Description - Return the relation between two entities in the knowledge graph Functional Inputs - (Entity, Entity) Textual Inputs - None Outputs - Predicate
- SelectBetween Description - From the two entities, find the one whose attribute value is greater or less and return its name in the knowledge graph Functional Inputs - (Entity, Entity) Textual Inputs - (Key, Operation) Outputs - string
- SelectAmong Description - From the entity set, find the one whose attribute value is the largest or smallest in the knowledge graph Functional Inputs - Entities Textual Inputs - (Key, Operation) Outputs - string
- VerifyStr Description - Return whether the output of QueryAttr or QueryAttrUnderCondition and the given value are equal as string in the knowledge graph Functional Inputs - Value Textual Inputs - Value Outputs - boolean
- VerifyNum Description - Return whether the two numbers satisfy the condition in the knowledge graph Functional Inputs - Value Textual Inputs - (Value, Operation) Outputs - boolean
- VerifyYear Description - Return whether the two years satisfy the condition in the knowledge graph Functional Inputs - Value Textual Inputs - (Value, Operation) Outputs - boolean
- VerifyDate Description - Return whether the two dates satisfy the condition in the knowledge graph Functional Inputs - Value Textual Inputs - (Value, Operation) Outputs - boolean
- QueryAttrQualifier Description - Return the qualifier value of the fact (Entity, Key, Value) in the knowledge graph Functional Inputs - Entity Textual Inputs - (Key, Value, Qualifier Key) Outputs - Qualifier Value
- QueryRelationQualifier Description - Return the qualifier value of the fact (Entity, Pred, Entity) in the knowledge graph Functional Inputs - (Entity, Entity) Textual Inputs - (Predicate, Qualifier Key) Outputs - Qualifier Value
Training Examples:
Training Example 1: Question: What is the connection between A Serious Man to Ireland (the one whose nominal GDP is 239389340720.488 United States dollar)? Entities: [’A Serious Man’, ’Ireland’], Concepts: None. The steps to solve this question are: Output: Step 1: Find(A Serious Man) Step 2: Find(Ireland) Step 3: FilterNum(nominal GDP, 239389340720.488 United States dollar, =) Step 4: QueryRelation() Done
Training Example 2: Question: Which first-level administrative country subdivision established post-1829 covers the biggest area? Entities: None, Concepts: [’first-level administrative country subdivision’]. The steps to solve this question are: Output: Step 1: FindAll() Step 2: FilterYear(inception, 1829, >) Step 3: FilterConcept(first-level administrative country subdivision) Step 4: SelectAmong(area, largest) Done
Training Example 3: Question: What is the ISNI of John Broome (the one born in 1738-01-01)? Entities: [’John Broome’], Concepts: None. The steps to solve this question are: Output: Step 1: Find(John Broome) Step 2: FilterDate(date of birth, 1738-01-01, =) Step 3: QueryAttr(ISNI) Done
Training Example 4: Question: Does the sovereign state that has a diplomatic relation with Malaysia (the subject of this statement is East Timor–Malaysia relations), have the CIVICUS Monitor country entry of saint-lucia? Entities: [’Malaysia’], Concepts: [’sovereign state’]. The steps to solve this question are: Output: Step 1: Find(Malaysia) Step 2: Relate(diplomatic relation, forward) Step 3: QFilterStr(statement is subject of, East Timor–Malaysia relations) Step 4: FilterConcept(sovereign state) Step 5: QueryAttr(CIVICUS Monitor country entry) Step 6: VerifyStr(saint-lucia) Done
Training Example 5: Question: What is the umber of episodes in TV series with Twitter username ThomasFriends (the subscription number of this statement is 15947)? Entities: None, Concepts: [’television series’]. The steps to solve this question are: Output: Step 1: FindAll() Step 2: FilterStr(Twitter username, ThomasFriends) Step 3: QFilterNum(number of subscribers, 15947, =) Step 4: FilterConcept(television series) Step 5: QueryAttr(number of episodes) Done
Training Example 6: Question: When was born the person that was nominated for Tony Award for Best Actor in a Musical in 1967? Entities: [’Tony Award for Best Actor in a Musical’], Concepts: [’human’]. The steps to solve this question are: Output: Step 1: Find(Tony Award for Best Actor in a Musical) Step 2: Relate(nominated for, backward) Step 3: QFilterYear(point in time, 1967, =) Step 4: FilterConcept(human) Step 5: QueryAttr(date of birth) Done
Training Example 7: Question: Does Pierce County that is located in Washington or Grays Harbor County have less area? Entities: [’Washington’, ’Pierce County’, ’Grays Harbor County’], Concepts: None. The steps to solve this question are: Output: Step 1: Find(Washington) Step 2: Relate(located in the administrative territorial entity, backward) Step 3: Find(Pierce County) Step 4: And() Step 5: Find(Grays Harbor County) Step 6: SelectBetween(area, less) Done
Training Example 8: Question: How many researchers are the occupation of Aristotle or practice motivational speaking? Entities: [’Aristotle’, ’motivational speaking’], Concepts: [’researcher’]. The steps to solve this question are: Output: Step 1: Find(Aristotle) Step 2: Relate(occupation, forward) Step 3: FilterConcept(researcher) Step 4: Find(motivational speaking) Step 5: Relate(practiced by, forward) Step 6: FilterConcept(researcher) Step 7: Or() Step 8: Count() Done
Training Example 9: Question: Is the nominal GDP of Guinea-Bissau over 69000000 United States dollars on the date 1996-01-01? Entities: [’Guinea-Bissau’], Concepts: None. The steps to solve this question are: Output: Step 1: Find(Guinea-Bissau) Step 2: QueryAttrUnderCondition(nominal GDP, point in time, 1996-01-01) Step 3: VerifyNum(69000000 United States dollar, >) Done
Training Example 10: Question: Which university has fewer students, George Washington University or University of Hamburg? Entities: [’George Washington University’, ’University of Hamburg’], Concepts: None. The steps to solve this question are: Output: Step 1: Find(George Washington University) Step 2: Find(University of Hamburg) Step 3: SelectBetween(students count, less) Done
Test Question: Question: Who was the prize winner when Mrs. Miniver got the Academy Award for Best Writing, Adapted Screenplay? Entities: [’Mrs. Miniver’, ’Academy Award for Best Writing, Adapted Screenplay’], Concepts: None. The steps to solve this question are: Output:

heading: Future Work
text: There is still some performance gap with fully supervised approaches that suggests potential avenues for future research