Source2Synth: Synthetic Data Generation and Curation Grounded in Real Data Sources

## Abstract

Abstract Large Language Models still struggle in challenging scenarios that leverage structured data, complex reasoning, or tool usage. In this paper, we propose Source2Synth : a new method that can be used for teaching LLMs new skills without
relying on costly human annotations. Source2Synth takes as input a custom data source and produces synthetic data points with intermediate reasoning steps grounded in real-world sources. Source2Synth improves the dataset quality by discarding low-quality generations based on their answerability.
We demonstrate the generality of this approach by applying it to two challenging domains: we test reasoning abilities in multi-hop question answering (MHQA), and tool usage in tabular question answering (TQA).
Our method improves performance by 25.51% for TQA on WikiSQL and 22.57% for MHQA on HotPotQA
compared to the fine-tuned baselines.

## 1 Introduction

Large Language Models (LLMs) (Devlin et al., ; Chowdhery et al., ; Brown et al., ; Vaswani et al., ) have risen to popularity due to their remarkable ability to digest and generate human-like text (Radford et al., ).
However, LLMs still struggle with more complex tasks such as multi-step reasoning, tool use and manipulating or processing structured data.
For many of these tasks there exists source data, such as existing structured data on the web, but little data of how to use it to solve a task.In principle, one can achieve performance improvements during fine-tuning by collecting human annotated data of such tasks.
However, this is an expensive and time-consuming process (Touvron et al., ).

In this paper, we propose Source2Synth, a general approach to generate synthetic data grounded in external real-world sources. Grounding the data generation process in real-world sources steers the examples to be more realistic, diverse, and factually correct.
We showcase our method on two challenging tasks: multi-hop questions based on sources from the web, and
tabular question answering using SQL as a tool.
In both cases it achieves improved performance without relying on human annotations, resulting in a scalable data generation method for complex tasks.

Source2Synth consists of three stages: Dataset Generation and Dataset Curation, followed by Model Finetuning, see Figure 1. At the Data Generation stage, we start by selecting a data source (such as tables on the web, or related Wikipedia articles) to ground our synthetic data generation in realistic information for a specific task. Then, to generate a given example, our method first selects a seed topic to condition the generation - for example a specific entity in a Wikipedia article or a factual statement about a table.
Given the seed topic, the method then generates the full example: the instruction (e.g., question), the reasoning chain to arrive at the answer (e.g., the steps of multi-hop question answering, or tool use) and the answer itself.

At the Data Curation stage, the constructed synthetic dataset is split into two slices: the first slice is used to fine-tune the LLM, resulting in an intermediate fine-tuned model. We use this model to curate the second slice of data via imputation and the use of a filtering step by rejection sampling. For imputation, we blank some parts of a given
example and accept the example if the model can fill in the blanks. For filtering, we reject examples that cannot produce the correct answer in $k$ trials. This provides a higher quality curated dataset for the final fine-tuning stage on the second slice, resulting in a better performing model on a given task.

To demonstrate the generality of our approach, we apply it to two different domains:

- •
answering tabular-based questions by learning how to use SQL as a tool;
- •
answering multi-hop questions by performing multi-step reasoning and information extraction.

To summarize, our key contributions are:

- •
We introduce a new method for generating synthetic examples aligned with the target task, given a real-world data source as context.
- •
We introduce a curation method based on filtering and imputation which yields higher quality data and improved task performance.

Figure: Figure 1: Overall Source2Synth Method. In the Dataset Generation step we first choose a data source to build our dataset from. For each example we select a seed topic to condition the generation on, and use the data source and seed together to construct the example. The resulting synthetic dataset is sliced in two: slice 0 is used to fine-tune an intermediate version of the LLM (LLMSynth), and we use LLMSynth to curate slice 1 through filtering and/or imputation during the Dataset Curation step. The resulting curated dataset is of higher quality and aligned with the user’s design. At the Model Finetuning stage, the final LLM (LLMCurated) is trained on the curated synthetic dataset, which can then be used to provide good performance on the task of interest.
Refer to caption: x1.png

## 2 Related Work

##### Synthetic Data Generation using LLMs

A number of works propose different strategies to generate synthetic datasets leveraging pre-trained language models. Some of these works rely on probing the knowledge contained in the LLM by first providing a prompt and letting the model either generate the continuation of a prefix or predict missing words in a close-style template (Schick and Schütze, , ; Petroni et al., ; Jiang et al., ).
Other works introduce a variety of ways to improve the quality of synthetic data by using model-based or human filtering (Schick and Schütze, ; Liu et al., ; Li et al., ; Thoppilan et al., ). Our method however does not rely on human annotations, and we improve the quality of the synthetic data by leveraging the LLM itself. Furthermore, our selection of the seed topic is automated and we use real data as a starting point. We note that some recent work also leverages real-world data for specific cases, such as a corpus from the web to construct high-quality synthetic data (Nguyen et al., ) or open-source code snippets to generate diverse instruction data for code generation (Wei et al., ; Dubey et al., ). In our case, we do not require a back-translation approach or an initial finetuning to generate the seed to digest the data. Our work proposes a general framework which can be applied across tasks.
See Liu et al. () for a thorough overview of synthetic data research and references therein.

##### Teaching LLMs to Use Tools

Enabling LLMs to use different tools can augment their abilities beyond text generation and towards manipulating structured data, retrieving information from external sources, or interacting with APIs. Even though the goal of our work is not specifically to teach models to use tools, but to develop a general synthetic data generation approach, we consider this to be a by-product. For example, we demonstrate how our method can be used to make LLMs use SQL - which is an example of a tool.
Tool usage is a very active area of research.
Various works augment LLMs with general tools or API calls (Parisi et al., ; Schick et al., ; Tang et al., ), while some propose to interweave intermediate reasoning steps with API calls (Gao et al., ; Cai et al., ; Paranjape et al., ) which improves performance on more complex tasks.
Finally, handling unseen tools at test time has also been tackled (Paranjape et al., ; Mekala et al., ).
See Mialon et al. () and Qin et al. () for an in-depth literature review of augmented language models research and references therein.

##### Teaching LLMs to use SQL

The above approaches usually only enable tool usage for inputs that are strings or numbers. However, using structured data during post-training can be useful to enhance the LLM’s capabilities in complex tasks, such as tables or relational data like graphs. A particular tool of interest is SQL since it enables aggregating information from tabular data. There exist a variety of benchmarks that have been proposed to assess LLMs abilities to generate SQL as well as their performance on tabular-based question answering leveraging SQL tasks (Li et al., ; Zhong et al., ).
Alternatively, handling tabular data directly by LLMs has also been tried (Herzig et al., ; Gemmell and Dalton, ), and tabular question answering benchmarks have been proposed  (Pasupat and Liang, ).

## 3 Method

Source2Synth produces high-quality synthetic examples grounded in external real-world data sources, and this resulting synthetic data is provided as step-by-step examples to the LLM for fine-tuning.
Source2Synth is composed of three stages: Dataset Generation, Dataset Curation, and Model fine-tuning.

### 3.1 Dataset Generation

##### Data source selection

The generation process begins by selecting a data source. This can be an already existing dataset re-purposed for a given task, a collection of existing data points that we would like to leverage to construct a new dataset, or structured information (e.g. graphs, tables).
There is no need for human annotations on the entries, as Source2Synth will enrich it with extra instructions.

##### Seed

In order to create a given example of our new synthetic dataset, we first generate
a seed topic as the initial trigger for the generation process, which is chosen conditioned on a randomly selected portion of the source data. The seed inspires the creation of the entry and dictates how the source data will be used.
In addition, the randomness of the seed ensures variety in the generated data.

##### Dataset construction

In order to tackle complex tasks, LLMs can leverage a step-by-step approach (Wei et al., ) that divides reasoning into smaller sub-tasks plus instructions on how to merge back each step into the final one. In Source2Synth, we leverage the seed to build synthetic data step-by-step, decomposing into such intermediate steps in order to arrive at an answer for a given question. This reasoning chain can then be used as supervision by providing it as the target in the synthetically generated training examples.

Figure: Figure 2: Source2Synth synthetic data generation process for multi-hop question answering. The method first randomly picks one article $D_{1}$, in this case with title "The Moon". At the Seed stage, an entity E is selected from $D_{1}$’s pool of entities, “Apollo 11”. Then, documents are sampled from the related documents pool of $D_{1}$ such that $E$ is present, and $D_{2}$, “Neil Armstrong”, is selected. A question $Q_{1}$ is then generated from $D_{1}$ with the constraint that the answer $A_{1}$ is the entity itself. A second question $Q_{2}$ is then generated from $D_{2}$ with the constraint that its main topic is the entity. We then prompt an LLM to merge the two questions based on the link/entity they have in common to produce the final question, reasoning chain and answer that comprise the training example.
Refer to caption: x2.png

### 3.2 Dataset Curation

The Dataset Generation process yields an augmented dataset grounded in real data. At the Dataset Curation step, we employ a model-based approach to automatically refine the dataset to enhance its quality, while avoiding the need for human supervision. In particular, we prune the newly-built dataset of all the entries that have been incorrectly crafted or that are deemed low quality. This is achieved by slicing the dataset in two and using one slice to fine-tune the LLM (LLMSynth). During curation, LLMSynth is then used to improve the quality of the second slice of the dataset using imputation plus a filtering step. After these steps, we obtain the final curated dataset (shown in purple in Figure 1).

##### Data filtering

During filtering, LLMSynth is used to predict the output of the given synthetic example using $k$ tries.
If the output cannot be predicted at least once, it is assumed the example is low quality and is not included in the final curated dataset.

##### Data Imputation

We also consider an imputation process, which involves blanking parts of the augmented data points and using the LLM to fill in the blanks, to replace those fields. This is to provide cleaner data which is less unnatural.

### 3.3 Model fine-tuning

At this stage, we fine-tune on the curated synthetic dataset, initializing from a base version or instruction-tuned version of the LLM. We use our dataset for supervised training of both the reasoning chain and the final answer given an input.
The resulting model LLMCurated is then ready to perform the desired task.

## 4 Applying Source2Synth to Special Cases

The general pipeline described above can be used to produce examples for the task at hand and to teach LLMs new skills. To demonstrate the impact of Source2Synth, we apply it to two challenging tasks where LLMs struggle, which are both areas of great interest for the community: multi-hop question answering and tabular question answering.

### 4.1 Multi-hop question answering

In multi-hop question answering (MHQA),
we generate a dataset of multi-hop question-answer pairs, in addition to the reasoning chain that is used to answer the question, consisting of question decomposition into subquestions with answers, plus the entity that links them.
See Figure 2 for an overview of the procedure and Figure 3 for an example response from the Source2Synth model.

#### 4.1.1 Dataset Generation

##### Data source selection

For multi-hop question answering, we pick English Wikipedia (Wikipedia contributors, ) as the data source, since it contains articles in natural language as well as additional meta-information like links to related articles.
The data generation process starts by randomly selecting an initial article, denoted as $D_{1}$, among all available Wikipedia articles. For each $D_{1}$ we collect $n\geq 2$ related articles.

##### Seed

An MHQA seed topic corresponds to an entity $E$ retrieved from $D_{1}$. The seed in MHQA doubles also as the “hop” in the multi-hop question $Q$ that we aim to generate, since $E$ links the $n=2$ subquestions that compose $Q$. For example, in
Figure 2, we sample "The Moon" article at random, denoted by $D_{1}$, and the corresponding entity, denoted by $E$, is "Apollo 11" (displayed in blue). Then, we pick "Neil Armstrong" as $D_{2}$ from the pool of related articles, since it contains a paragraph where the entity "Apollo 11" is included.

##### Dataset construction

We prompt an instruction-tuned language model to generate two questions: a question $Q_{1}$ based on $D_{1}$ and whose answer is the selected entity $E$, and a second question $Q_{2}$ based on $D_{2}$ such that its main topic is $E$.
See Figures  16 and  17 for the exact prompts.
For example, in Figure 2, $Q_{1}=$ "What was the spaceflight that first landed humans on the Moon?", the hop is $E=$ "Apollo" and $Q_{2}=$ "Who was the commander of Apollo 11?".
We then prompt the LLM to merge
the two questions, in order to generate the final two-hop question $Q$ by using the entity as a conceptual link (hop). The exact prompt is given in
Figure 15.

Figure: Figure 3: Example Source2Synth Response on MHQA (closed book inference). We show the model’s response (reasoning steps and answer) to a multi-hop input question (yellow). The colours highlight the generation of the corresponding augmented entries: the decomposition into sub questions $Q_{1}$ and $Q_{2}$ in green, the seed $A_{1}$ in blue, and the final answer $A_{2}$ in red.
Refer to caption: x3.png

#### 4.1.2 Dataset Curation

##### Data filtering

We check if the predicted answer matches the answer in the synthetically generated example, and if after $k$ tries the LLM has not supplied the correct answer we filter out the entry entirely.
See Figure 3 for an example of model inference.

##### Data Imputation

For MHQA, we blank $Q_{1}$ and provide the LLM with $Q$, $Q_{2}$, $E$, and the relative doc sample $D_{1}$ as context when asking it to reconstruct $Q_{1}$. The new candidate for $Q_{1}$ is then assessed: if $A^{\prime}$ (the answer to this new multi-hop question $Q^{\prime}$) matches $A$ (the original answer to $Q$) then we keep the example. We find that asking the model to reconstruct parts of the multi-hop question in-context
results in a more natural and cohesive question, thus removing some of the unnaturalness of the text that can occur from automatically generated and merged examples.

Figure: Figure 4: Source2Synth synthetic data generation process for Tabular question answering. The method first generates the seed, which is a fact based on the table (shown in blue). Given the seed and table, an SQL query is then generated (in green) as well as its translation into natural language (the question Q). Then the SQL is executed on the table to obtain the answer A.
Refer to caption: x4.png

### 4.2 Tabular question answering

In Tabular question answering (TQA) we generate a question-answer dataset where each question is based on a given (real) table from the data source. Generated training examples are hence
enriched with tables and annotations which are built from automatically-generated interesting facts retrieved the table.

##### Data source selection

In the TQA case, we use unlabeled tables in the train split of the WikiSQL dataset (Zhong et al., ).

##### Seed

We then prompt an instruction-tuned language model to generate a statement based on the table. This statement corresponds to our seed topic for the generation and is a pertinent interesting fact or set of observations in natural language that can be derived from the table. The prompt is given in Figure 13.

#### 4.2.1 Dataset Construction

We next generate an SQL-statement by zero-shot prompting the LLM: we provide the table and the seed (factual statement) as context, see Figure 13 for the exact prompt. Given the produced SQL statement, it is then executed using the Python library sqlite3(^1^11https://www.sqlite.org) to obtain an SQL answer formatted as a table. If the generated statement is invalid, we discard it and re-generate.

#### 4.2.2 Dataset Curation

##### Data filtering

We check if the predicted answer of LLMSynth fine-tuned on slice 0 matches the answer in the synthetically generated example, and if after $k$ tries the model has not supplied the correct answer we filter out the entry entirely.
See Figure 5 for an example of model inference.

Figure: Figure 5: Example Source2Synth Response on TQA. We show the model’s response (SQL call and final answer) to the tabular input question (yellow). The coloured parts highlight the generation of the corresponding augmented entries: SQL in green, and the final answer in red.
Refer to caption: x5.png

## 5 Experimental Setup

We test our method on two domains: tabular question answering and multi-hop question answering.
For each, we use Source2Synth to generate and curate a high quality dataset suitable for fine-tuning, and compare our method to a number of baselines.

### 5.1 Multi-Hop QA Setup

##### Data

To evaluate multi-hop question answering abilities, we evaluate our Source2Synth method on HotPotQA (Yang et al., ). HotPotQA is a benchmark based on Wikipedia containing 113,000 examples of multi-hop question-answer pairs and is split in train, test, and validation sets.
Each entry in HotPotQA is constructed such that:
1) each question requires finding and reasoning over multiple supporting documents in order to answer; 2) each entry provides sentence-level supporting facts for strong supervision and explainability of the prediction; 3) each question can be classified as either a comparison or bridge question.

A comparison question entails comparing the same concept between $n$ objects (e.g. "Who is the tallest student in class?"), while a bridge question builds on a logical and/or causal link and requires deriving one statement to get to the answer (e.g. "What is the height of the student that topped the entry exam?" - this requires first identifying the student that topped the exam. The hop length is the number of comparison objects for comparison questions or the number of links for bridge questions. In our case, we chose $n=2$ to be consistent with HotPotQA. The test set consists of 7,405 entries, split evenly between bridge and comparison questions. We only generate synthetic data for bridge questions, since they pose a bigger challenge to current LLMs. In order to counterbalance this disparity, we include 500 comparison questions from HotPotQA’s training dataset in our fine-tuning dataset.

##### Metrics

We measure the performance using soft exact match (soft-EM) as the metric. Soft-EM is 1 if the generated output contains the golden answer and 0 otherwise.

##### Model

The base model used in the experiments in MHQA is Llama-2 70B-Chat. We hence fine-tune Source2Synth and various other baseline methods initializing from this model.
Source2Synth is trained with 1250 synthetic examples, unless noted otherwise, in addition to the 500 HotPotQA examples described above.

##### Baselines

We compare Source2Synth to the following baselines:

- •
Instruction-tuned LLM: using LLama 2 70B-Chat for the task in a zero-shot manner.
- •
Fine-tuned LLM (HotPotQA only): fine-tuning from the base model on 500 HPQA examples from the training split.
- •
LLMSynth (Synthetic dataset only): training our model with 1250 synthetic examples from Slice 1 (see Figure 1), without the data curation step.
- •
LLMSynth (Synthetic and HotPotQA): training with the uncurated synthetic data in addition to the 500 HPQA examples.

For all the models listed, we tested them using two prompting methods: a zero-shot and a three-shot CoT prompt, see the Appendix C for details.

### 5.2 Tabular QA Setup

##### Data

We conduct evaluations with the WikiSQL (Zhong et al., ) dataset validation split. The WikiSQL dataset consists of a corpus of 80,654 hand-annotated examples of natural language questions, SQL queries, and SQL tables created from 24,241 tables extracted from Wikipedia. The validation split contains 7,857 examples after removing non-executable SQL tables, see Appendix B for more details.

##### Metrics

We measure performance using the exact match (EM) and the soft-EM metrics. The EM metric equals 1 if the golden answer is equal to the generated answer and 0 otherwise.

##### Model

For TQA, we use the Starchat-beta language model Li et al. () from Huggingface as the initial language model (batch size 32, 100 steps, lr 0.0001, linear warm-up). The Starchat model is an instruction-tuned LLM with 16 billion parameters trained to act as a helpful coding assistant. This model is a fine-tuned version of StarCoder Li et al. (), a LLM which was pre-trained and then fine-tuned on a large code corpus, which contains SQL statements, and successively fine-tuned on 35B Python tokens.
For our Source2Synth generated data, the initial number of synthetic examples per slice is 8k (so 16k in total). After curation, we keep 2160 of the examples in slice 2 (27%).

##### Baselines

We compare the performance of our Source2Synth method against a variety of baselines. The baselines consist of prompting the Starchat-beta instruction-tuned language model as follows:

- •
Zero-shot Table QA: prompt with the task instruction, the table and the question in a zero-shot fashion. See Figure 7 for the prompt.
- •
One-Shot No Context QA: prompt with the task instruction and a one-shot example containing a question and answer, together with the actual question for the model to answer. See Figure 8 for the prompt.
- •
One-Shot Table QA: prompt that includes the table for both the one-shot example and the question to be answered. We use one-shot due to LLM context length and the typically large size of the tables.
See Figure 9 for the prompt.
- •
One-shot Table+SQL QA: the prompt includes an example containing the table and question, and an instruction suggesting that the model can leverage an SQL tool. We then execute the predicted SQL to obtain the answer.
See Figure 10 for the prompt.
- •
LLMSynth: Finetune the model with synthetic data but without applying the data curation step.

## 6 Results

### 6.1 Multi-Hop question answering

**Table 1: Evaluation of Source2Synth on Multi-hop question answering. The models shown are fine-tuned with 500 entries from HotPotQA (‘HotPotQA”) and/or 1250 entries from the Source2Synth Synthetic Dataset (“Synthetic Dataset”). Using Source2Synth curated synthetic data in combination with HotPotQA (last row) works best.**
| Method | 0-shot | 3-shot CoT prompt |
| --- | --- | --- |
| Instruction-tuned LLM (LLama 2 70B-Chat) | 40.45% | 44.13% |
| fine-tuned LLM (HotPotQA only) | 53.22% | 58.40% |
| LLMSynth (Synthetic dataset only) | 52.31% | 56.70% |
| LLMSynth (Synthetic and HotPotQA) | 57.46% | 62.73% |
| LLMCurated (Synthetic and HotPotQA) | 65.23% | 66.05% |

**Table 2: Analysis of MHQA bridge and comparison questions with respect to level of difficulty. We evaluate models on 1k entries for each question type. Source2Synth was used to generated bridge question type data, hence LLM-Curated-1250 outperforms other models particularly for bridge questions.**
|  | Bridge | Comparison |  |  |  |  |
| --- | --- | --- | --- | --- | --- | --- |
| Model | Hard | Medium | Easy | Hard | Medium | Easy |
| Llama2-70B-Chat | 5.3% | 11.3% | 27.1% | 13.4% | 17.7% | 26.4% |
| fine-tuned LLM (HotPotQA only) | 14.6% | 16.9% | 39.0% | 23.5% | 31.4% | 35.6% |
| LLMCurated-1250 | 25.3% | 30.7% | 41.8% | 23.3% | 32.3% | 36.9% |

Figure: Figure 6: Synthetic Data scaling performance. We show how the performance of Source2Synth changes with respect to MHQA data mix size, both before and after curation. During the curation step, the following percentages of samples were removed: 7% for 500, 8% for 750, 11% for 1250. LLMSynth (before curation) performs worse than LLMCurated (after curation) despite having more samples – but both approaches improve with more data.
Refer to caption: x6.png

##### Overall performance of Source2Synth on MHQA

We report the experimental results in Table 1. We include the baselines
of the vanilla instruction-tuned LLM, a
fine-tuned LLM using only the HPQA 500 examples from the train split (second row), and  LLMSynth which only uses the uncurated synthetic data for fine-tuning (third row).
All fine-tuned methods outperform the instruction-tuned model (first row).
Using only synthetic data or only HotPotQA data for fine-tuning demonstrates worse performance than when combined, whether the synthetic data is curated (fifth row) or not as in  LLMSynth (fourth row). Once we use the full Source2Synth pipeline to obtain the curated synthetic dataset for fine-tuning we see further performance improvements LLMCurated (fifth row) over not curating the data (fourth row).

Analysis of performance on different question types and levels of difficulty
We study the capabilities of our model by analysing the performance of LLM-Curated-1250 with particular focus on the type and difficulty of the questions – namely hard/medium/easy bridge and comparison questions.
We compare the performance of the base model, the model fine-tuned on HotPotQA, and  Source2Synth according to the difficulty level, as provided by the HotPotQA dataset. We also subdivide the results according to the type of question (bridge vs. comparison).
Results are given in Table 2.

In almost all cases, we observe that Source2Synth performs better, particularly on bridge questions, with an overall gain of 17.44% compared to the base model and a 14.56% gain compared to the LLM fine-tuned on HotPotQA. For the comparison questions, we see modest gains because our synthetic dataset only includes the harder task type (bridge). However, it is interesting to see some (small) improvement despite not explicitly targeting comparison-type questions in our dataset. Hence, Source2Synth tackled a more demanding task (bridge vs. comparison), and achieves 25.3% on hard-bridge questions compared to 14.6% of the Instruction-tuned LLM fine-tuned on HotPotQA.

**Table 3: Tabular question answering. Performance comparison on the WikiSQL evaluation dataset.**
| Method | Exact Match | Soft-EM |
| --- | --- | --- |
| One-Shot No Context QA (Starchat-beta LLM) | 0.25% | 16.22% |
| Zero-shot Table QA (Starchat-beta LLM) | 1.83% | 20.07% |
| One-Shot Table QA (Starchat-beta LLM) | 2.03% | 31.06% |
| One-shot Table+SQL QA (Starchat-beta LLM) | 12.30% | 34.13% |
| LLMSynth (Synthetic dataset only) | 23.86% | 34.21% |
| LLMCurated (Synthetic dataset only) | 34.50% | 42.80% |

##### Scaling performance

We also report scaling performance
in Figure 6. We study how performance evolves when adding more synthetic data in the fine-tuning data mix - that already includes 500 samples from the HPQA train split. We perform the analysis on LLMSynth and LLMCurated to show the impact of the curation technique.
In both cases and in all data mixes, we see that applying the Source2Synth pipeline results in a stronger model on the task.
For the LLMSynth model fine-tuned on uncurated samples we see that providing more synthetic examples leads to a steady improvement in performance across all data sizes, for both zero-shot and three-shot prompting variants.
LLMCurated follows a similar trend, but consistently outperforms the uncurated version of the model, for all training set sizes.
Overall, we observe that using our synthetic data generation pipeline to construct more data brings further performance gains in the task.

### 6.2 Tabular question answering

We report the experimental results for Tabular question answering in Table 3.
Firstly, they indicate that providing no context about the table when prompting the instruction-tuned StarChat language model has very poor performance (first row), with an EM metric of 0.25%. This is expected since the WikiSQL benchmark questions require information contained in the table, and the model does not have any other information to answer the question except for the general knowledge stored in its parameters. However, even if we pass the table as part of the prompt, the performance does not improve much. For example, passing in a zero-shot fashion (second row) only has an EM metric of 1.83%. This may be challenging for the model as the information in the table is presented in a form that is not easy for the LLM to naturally handle (i.e. a table rather than natural language). While passing an example of table usage in a one-shot fashion (third row) improves the soft-EM metric, the EM metric is still very low (2.03%). Hence, this is still very challenging for the model.
Thirdly, the performance increases once we provide a one-shot example containing the relevant table and SQL query (fourth row), with an EM of 12.3%. The ability to use the SQL tool improves the performance markedly.

We obtain a significant increase in performance when we fine-tune the StarChat model using the Source2Synth curated data (last row), with an EM of 34.5%. Our full method performs significantly better than fine-tuning the StarChat language model using synthetic data without curation, LLMSynth (second to last row) which has an EM of 23.86%, although that still outperforms the other baselines by a large margin as well, indicating the utility of our Source2Synth synthetic data generation scheme.

## 7 Conclusion

In this paper, we introduce Source2Synth, a new method for generating and curating high-quality synthetic data grounded in real data sources. We demonstrate its utility on two tasks that pose significant challenges for LLMs: multi-hop reasoning and tabular question answering with SQL. We believe our work could also be beneficial in other low-data regimes, and future work could explore our approach on other tasks and in diverse fields, for example, in to biology, chemistry and medicine.

## 8 Limitations

In this paper, our applications use a single seed to derive two-hop questions in the case of MHQA or SQL on a single table in TQA.
However, Source2Synth can be extended to more complex questions e.g. with more hops,
and even more complex tool-use, e.g. the use of multiple tables. This could be done
by looping the dataset generation steps and feeding the result of the previous step as input to the next one.
Our approach provides a way to sample the related articles graph and corresponding entities within the articles based on simple rejection sampling but we believe that our method could be improved with more clever sampling techniques. We consider this to be an interesting avenue of future research.

## Appendix A More Results on Prompt Engineering

**Table 4: MHQA prompts sweep. Overview of the model’s accuracy across different prompt strategies. Role "You are a QA-robot. Answer the following question:". Model used: Llama-2-70B-Chat, Dataset: HotPotQA test.**
| Prompt Type | Model Accuracy (soft-EM) |
| --- | --- |
| 0-shot | 40.45% |
| Role | 22.34% |
| 1-shot | 26.65% |
| Few-shots (5-shots) | 21.83% |
| Role (1-shot) | 28.29% |

## Appendix B SQL non-executable code filtering

We discard incorrect SQL statements - i.e. whose execution with sqlite3(^2^22https://www.sqlite.org) leads to an error. Discarded proportion: out of 50 tables, we generate 800 seed statements and the number of valid (executable) SQL statements was 658.

## Appendix C Prompts used in our experiments

Figure: Figure 7: Zero-shot Table QA prompt for the TQA task.

Figure: Figure 8: One-Shot No context QA prompt for the TQA task.

Figure: Figure 9: One-shot Table QA prompt for the TQA task.

Figure: Figure 10: One-shot Table+SQL QA prompt for the TQA task.

Figure: Figure 11: Prompt used to induce a pertinent and interesting seed topic in TQA. This is done zero-shot.

Figure: Figure 14: Three-shot CoT prompt used at evaluation time in MHQA.

Figure: Figure 15: Prompt used to merge Q1 and Q2 in MHQA.

Figure: Figure 16: Prompt used to generate $Q_{1}$. $Q_{1}$ is generated such that its answer $A1=E$ where $E$ is the entity retrieved.

Figure: Figure 17: Prompt used to generate $Q_{2}$. $Q_{2}$ is generated such that its main topicis $E$ where $E$ is the entity retrieved.

## Peer Reviews

confidence: 4
contribution: 4
initial_rating: 6
presentation: 1
questions: Suggestions:

• 249-250: "... (see C for more details)." Consider writing "Appendix C".

• If I understand correctly, during data curation one slice is used to train an intermediate model, and this model is used to filter examples from the other slice. What I don't understand is: why not do the reverse after that? Training on slice 2, filter examples from slice 1. As a result more generated examples will be kept -- analogous to cross-validation.

• HotPotQA --> HotpotQA
soundness: 3
strengths: • It is novel and interesting to use model train on part of the data to filter generated data in the other half

• The proposed pipeline brings significant improvement in performance, even competitive with finetuned baselines.
summary: This works presents an end-to-end pipeline to generate synthetic training data based on some data source. The pipeline consists of three steps, namely data generation, curation, and finetuning. The data generation step selects the topic of the example based on a random crop of the data source, and then goes on to generate an example with instruction, query, reasoning chain, and the final answer. The curation step filters and modifies the generate examples by dividing the synthetic data into two portions, one used to train an intermediate model to judge and filter data from the other half. The model is then finetuned with the curated data.

Evaluation on HotpotQA, WikiSQL, and Tabular QA show that the pipeline can significantly improve model performance in the target tasks, even competitive with finetuned baselines with supervised data.
weaknesses: • The paper could use much clearer presentation (grammar, wording, formatting, etc...)

• Consider discussing how the proposed pipeline avoids data leak (does it?) during the data generation step, esp. given that HotpotQA is also constructed from Wikipedia articles.

• For Tables 1 and 2, there is no comparison between LLMSynth (Synthetic dataset only) and LLMCurated (Synthetic dataset only). Adding such comparisons can further consolidate the importance of the curation step.

• The scope of this method is limited because it requires knowing the target task itself before data generation. I.e., at its current form it cannot be generalized to produce, say, instruction-tuning data to train LLMs.

---

confidence: 4
contribution: 3
initial_rating: 3
presentation: 2
questions: Q1. How do you measure the quality of the LLMSynth model that does the filtering? Does the filtering step that uses k samples from the model output make the final dataset too easy e.g. by dropping valid but hard questions?

Q2. How many questions did you construct using the Source2Synth pipeline for MHQA? How many wikipedia articles were used in the input? How many questions were generated in each stage? Articles to initial set then portion that went to tuning LLMSynth for filtering, and then how many questions remained after filtering? How much is this relative to the HotPotQA dataset? (which already has 113k questions).

Q3. Similarly for TQA, did you use only the tables in the WikiSQL dataset? What is the number of tables? How many examples were generated at each stage?
In lines 385-386 what do you mean by slice? Why generate more questions on 2 slices (16k questions) but use only (8k) questions generated on 1 slice? Also if only 27% questions are retained after curation, it goes back to question-1, is it possible that your filtering is dropping some good harder questions that would have been able to improve the model further?

Q4. Do you ensure that the synthesized questions do not overlap with existing validation and test questions in MHQA and TQA? If so, how do you do it? If not, is there a possibility of leakage?

Q5. In Table 1.Evaluation of Source2Synth on MHQA, is there a comparison with a LLaMA-70B model finetuned on the entire train split of HotPotQA as opposed to just the 500 questions? Do I understand your setup correctly that all rows in the table (except for base LLaMA) are tuned with just 500 questions from HotPotQA and/or 1250 Questions generated from the Source2Synth pipeline?

Q6. LLMCurated is not described in Sec 5.1 and Sec 6.1 clearly. Is LLMCurated tuned on uncurated synthetic examples + curated synthetic examples + 500 HotPotQA examples?
From subsequent sections it appears like the 1250 is the number of uncurated synthetic examples, what is the number of curated synthetic examples then? What if you tuned only the curated examples and not the uncurated set.

Q7. Similar questions with TQA, Is LLMSynth trained on 8k (or 16k) uncurated examples for TQA? Is LLMCurated trained only on the 2160 examples after curation?

Q8. Clarification: I assume the imputation step is only applied in the case of HotPotQA and TQA.
soundness: 2
strengths: * The paper proposes a nice idea to automatically generate compositional queries. They also propose techniques to automatically filter them using an LLM tuned on the synthesized data.

* The idea is described neatly and baseline performances are evaluated.
summary: The paper introduces an idea for generating synthetic datasets similar to the target task given a raw unstructured source as context. The generation consists of using a seed and data source to generate questions in multiple stages and combine the initial and final questions, to generate a more complex compositional query e.g. a multi-hop question or SQL query. They also propose a method for curating the synthesized data by filtering and imputation to identify higher quality examples. Prior to filtering they tune a model on the uncurated dataset (LLMSynth) to help with filtering. Their filtering involves taking k samples from the model, and if the model is unable to predict the answer in the k-samples then it’s discarded. With imputation they blank out parts of the intermediate questions and regenerate them with the other queries (this is only applied in the context of multi-hop questions, and not SQL).

They apply their approach on HotPotQA and Tabular question answering via SQL, and evaluate settings that tune a base LLM on target data specific to the dataset as well as their curated dataset and compare improvements in the performance.
weaknesses: 1. The experimental evaluation steps are lacking clarity. A lot of important details are missing which significantly affects the quality of the work. Please see questions Q1-Q6.
2. The method is applied somewhat in a limited context on two problems, but it’s not clear how many source examples they generated the synthetic examples on. It sort of seems much more limited than the size of the original dataset e.g. HotPotQA already has 113k questions, but does not seem like the synthesized dataset matches a similar number of wikipedia articles, similarly with the tabular QA dataset,
3. The experiments and the datasets do not quite necessitate the methods at least in terms of the size of the existing training set. And the experiment setup doesn’t seem to include a comparison to how the models perform with the full original training set available with the datasets, especially since they do fine tuning.
4. It is also unclear if the

I really do like the ideas but there’s some considerable mismatch in the application for these datasets. Maybe it is worth going after more challenging datasets which are smaller in size in terms of available data for training.

---

confidence: 4
contribution: 2
initial_rating: 3
presentation: 1
questions: How is the slice 0 and 1 determined? What are their respective sizes?
Which setting is used for HotpotQA, distractor or full wiki?
Is finetuning full finetuning or parameter efficient tuning like LORA?
What k is used in the experiments for data filtering?
soundness: 2
strengths: The idea of using part of synthesized dataset to finetune LLM for filtering is interesting
summary: This paper propose a way to generate synthetic data on custom data sources with large language models. First the synthetic data is generated through LLM. Then a portion of the generated data is used to finetune an LLM, which in turn will be used to curate the other portion of the generated dataset. The curated portion would be the final curated dataset that will be used for training the final LLM for the targeted domain/skill.
weaknesses: The paper is not well written, hard to follow, and some important details are missing. For example, it is not clear how the two slices of data is selected, where one is used to train an LLM to do curation for the other slice.

The generation relies on existence of data source and ability to get seed data, which limits its applicability, in particular in situation where the domain and tasks are new.

The method uses LLM to do data curation, which implicitly assumes the LLM already have reasonable capability at the target task. For example for the text to SQL task, the LLM will be used to generate SQL statement, which would not be possible is the LLM does not already have that capability. Therefore, I am not sure if this method can actually be used to enable new skills for LLMs.

---

confidence: 3
contribution: 2
initial_rating: 5
presentation: 3
questions: 1. Why is there no baseline for TQA using a fine-tuned LLM on real data? Including this would offer a more direct comparison of the synthetic data’s impact against real data performance.
2. why does the 3-shot bring more significant improvements to LLMSynth than LLMCurated in Figure-5? Are these two methods with the same training parameters and Is there a possible explanation for that?
3. Why was the base model for TQA switched from LLaMA 2-70B to Starchat-beta LM? Clarifying this would help us understand the model choice for each task.


Suggestion
1. It seems like a newline is missing for "data filtering" in Line 326 
2. Adding a pointer in the main paper to Figure 14, which displays the COT prompt used for MHQA, would improve accessibility for readers.
soundness: 2
strengths: 1. This paper addresses two critical challenges in the community—data synthesis and LLM reasoning. It presents an innovative approach that leverages the model’s generation capabilities to create synthetic data designed to enhance reasoning abilities. By grounding intermediate reasoning steps in real-world sources, this method reduces hallucination, which is a frequent issue in LLMs, making it a valuable contribution toward more reliable model behavior.
2. The paper is well-written, with a clear structure that facilitates understanding. The methodology is presented in a step-by-step manner, making the approach accessible. Additionally, the results are organized effectively, and the figures are both informative and visually accessible, enhancing the reader’s comprehension of the findings.
3. The demonstrated improvement is substantial, showing that this method offers a promising direction for bolstering model reasoning abilities in specific tasks without extensive data annotation or heavy computational requirements.
summary: This paper presents source2synth, a novel approach for generating synthetic data that incorporates intermediate reasoning steps grounded in real-world sources. The method follows a three-stage pipeline: (1) dataset generation utilizing realistic external sources to ensure relevance and factuality, (2) data curation to eliminate noise and maintain data quality, and (3) model fine-tuning for better alignment with the target task. The experimental results demonstrate significant improvements in Multi-hop QA and Tabular QA tasks, highlighting the effectiveness of the approach in enhancing model performance on complex reasoning tasks
weaknesses: 1. **Limited Generalizability:** Although the method is positioned as general, its evaluation is restricted to two tasks within a single domain and model, raising questions about broader applicability:
- Across Task Types: Both tasks involve custom adaptations. It’s unclear if the method could extend to other reasoning tasks like code generation. If it’s adaptable, specifying which tasks and what adaptations are needed would be useful; otherwise, the paper may need to scale back general claims.
- Across Domains: The method’s transferability across domains (e.g., general QA to medical QA) is not tested. Exploring cross-domain flexibility would strengthen the paper.
- Across Models: It’s unclear if the method generalizes to models with different reasoning abilities, or how model capabilities affect gains. Addressing this would enhance understanding of the method’s adaptability.

2. **Lack of Deep Analysis on Method Mechanics:** The paper lacks in-depth analysis regarding how and why the method functions effectively.
- Data Imputation Motivation: The motivation behind the selective data imputation approach is unclear. For example, it’s not explained why some tasks are chosen for imputation over others, what specific elements within a task should be imputed, or how these choices are determined.
- Primary Factors Influencing Effectiveness: It’s uncertain if gains stem from source data quality, the LLM’s generation ability, or both. For instance, does the synthesis from a weaker model impact performance differently than synthesis from a stronger model? Additionally, since the current synthesized data is based on the model’s existing knowledge (the instances model can't do correctly are filtered), understanding how data that falls outside the model’s known domain affects performance would provide valuable insights into the approach’s mechanism.

3. **Missing Baselines:** The paper claims that grounding synthetic data in external sources produces more factually accurate examples; however, the experiments do not fully substantiate this. Including a baseline where real sources are replaced with the model’s synthetic sources would help validate this claim. Furthermore, the paper does not justify the exclusion of previous data synthesis methods. Adding these baselines or justifying their absence would bolster the paper’s argument for its approach’s advantages over existing methods.

Meta-review: This paper presents Source2Synth, a data augmentation method for improving LLM performance in low-data regimes without human annotations. The key strengths are the novel self-augmentation approach and strong empirical results showing 20-25% improvements on WikiSQL and HotpotQA benchmarks. However, major weaknesses include limited analysis across model sizes/capabilities, lack of comprehensive ablation studies, and unclear explanation of data curation choices. While the method shows promise for tasks involving documents and tables, questions remain about broader applicability. Given the incomplete experimental validation and analysis, I recommend rejection despite the interesting core idea.

Decision: Reject