DataFactory: Collaborative Multi-Agent Framework for Advanced Table Question Answering

Tong Wang; Chi Jin; Yongkang Chen; Huan Deng; Xiaohui Kuang; Gang Zhao

cs.AIMar 10, 2026

DataFactory: Collaborative Multi-Agent Framework for Advanced Table Question Answering

Authors: Tong Wang, Chi Jin, Yongkang Chen, Huan Deng, Xiaohui Kuang, Gang Zhao

Organizations: Institute of Systems Engineering, Academy of Military Sciences, Beijing, 100101, China · School of Information Resource Management, Renmin University of China, Beijing, 100872, China

Abstract

Table Question Answering (TableQA) enables natural language interaction with structured tabular data. However, existing large language model (LLM) approaches face critical limitations: context length constraints that restrict data handling capabilities, hallucination issues that compromise answer reliability, and single-agent architectures that struggle with complex reasoning scenarios involving semantic relationships and multi-hop logic. This paper introduces DataFactory, a multi-agent framework that addresses these limitations through specialized team coordination and automated knowledge transformation. The framework comprises a Data Leader employing the ReAct paradigm for reasoning orchestration, together with dedicated Database and Knowledge Graph teams, enabling the systematic decomposition of complex queries into structured and relational reasoning tasks. We formalize automated data-to-knowledge graph transformation via the mapping function T:D x S x R -> G, and implement natural language-based consultation that - unlike fixed workflow multi-agent systems - enables flexible inter-agent deliberation and adaptive planning to improve coordination robustness. We also apply context engineering strategies that integrate historical patterns and domain knowledge to reduce hallucinations and improve query accuracy. Across TabFact, WikiTableQuestions, and FeTaQA, using eight LLMs from five providers, results show consistent gains. Our approach improves accuracy by 20.2% (TabFact) and 23.9% (WikiTQ) over baselines, with significant effects (Cohen's d > 1). Team coordination also outperforms single-team variants (+5.5% TabFact, +14.4% WikiTQ, +17.1% FeTaQA ROUGE-2). The framework offers design guidelines for multi-agent collaboration and a practical platform for enterprise data analysis through integrated structured querying and graph-based knowledge representation.

Figures & tables

Figure 1: Overview of the LLM-based multi-agent DataFactory framework for TableQA. The system consists of a Database Team, a Knowledge Graph Team, and a Data Leader that orchestrates their collaboration from an initial data phase through three processing phases: information storage, knowledge extraction, and insight generation.

Figure 2: Workflow of the Database Information Processing Agent. The automated pipeline combines rule-based operations for schema construction with LLM-based analysis for semantic understanding, covering table analysis, DDL generation, data ingestion, and quality assessment.

Figure 3: Architecture of the Database Information Retrieval Agent. The agent integrates table schema and DDL information, domain knowledge, and retrieved historical question-SQL pairs to construct prompts for SQL generation and database querying.

Panel of Figure 4 — Figure 4: Database Information Analysis and Visualization Agents. (a) The Analysis Agent transforms retrieved tables into natural-language summaries with domain context. (b) The Visualization Agent generates plotting code to produce interactive charts for data exploration.

Figure 5: Workflow of the Knowledge Graph Information Processing Agent. The agent follows a three-stage process of strategy generation, configuration validation, and graph construction to transform tabular data into a knowledge graph.

Figure 6: Architecture of the Knowledge Graph Information Retrieval Agent. The agent generates Cypher queries by combining graph schema information, retrieved historical question-Cypher pairs, and external domain knowledge to support robust multi-hop graph traversal.

Figure 7: Architecture of the Knowledge Graph Information Analysis and Visualization Agents. The Analysis Agent explains retrieved subgraphs in natural language, and the Subgraph Drawing Agent renders corresponding graph visualizations for the web interface.

Figure 8: Workflow of the Data Leader. The three-stage process—data discovery, evidence-based query planning, and comprehensive analysis and synthesis—implements the ReAct paradigm to coordinate Database and Knowledge Graph teams.

Figure 9: Prompt template for the Data Leader agent. It encodes the three-stage exploration principle, coordination rules for the two teams, and the ReAct-style thought–action–observation format used during reasoning.

Dataset	Task Type	Test Size	Table Size	Key Challenges	Metric
TabFact	Fact Verification	12,779 statements	5-6 cols, 14 rows	Multi-hop reasoning,	Accuracy
( Chen et al., 2020 )	(Binary)	1,695 tables	(avg.)	logical operations
WikiTQ	Computational	4,344 questions	$\geq$ 8 rows, $\geq$ 5 cols	Aggregation, sorting,	Exact Match
( Pasupat and Liang, 2015 )	Analysis			arithmetic operations	Accuracy
FeTaQA	Multi-hop	2,003 instances	5.9 cols, 13.8 rows	Causal reasoning,	ROUGE-1/2/L
( Nan et al., 2022 )	Generation		(avg.)	free-form answers	F-score

Table 1: Benchmark datasets overview with key characteristics and metrics

Model	Provider	Type	Release	Parameters	Architecture	Deployment
Claude 4.0 Sonnet	Anthropic	Commercial	May 2025	Undisclosed	Dense	API
( Anthropic, 2024 )				(Mid-weight)
Gemini 2.5 Flash	Google	Commercial	Jan 2025	Undisclosed	Dense	API
( Google DeepMind, 2024 )	DeepMind			(Lightweight)
GPT-4o mini	OpenAI	Commercial	July 2024	Undisclosed	Dense	API
( OpenAI, 2024 )				(Compact)

Table 2: Large Language Models used in evaluation with key specifications

Method	TabFact					WikiTQ
Method	Results			Average	Cohen’s	Results			Average	Cohen’s
				( Improvement )	d				( Improvement )	d
TAPAS-large 2 2 2 https://github.com/google-research/tapas	80.1±1.2%			80.1% ( $\uparrow$ 3.9%)	3.25	50.7±2.8%			50.7% ( $\uparrow$ 22.1%)	7.89
TAPEX-large 3 3 3 https://github.com/microsoft/Table-Pretraining	82.0±1.5%			82.0% ( $\uparrow$ 2.9%)	1.33	56.2±1.7%			56.2% ( $\uparrow$ 16.6%)	9.76
	GPT-4o	Deepseek	Gemini 2.5			GPT-4o	Deepseek	Gemini 2.5
	mini	V3	Flash			mini	V3	Flash

Table 3: Performance comparison of different methods on TabFact and WikiTQ datasets

Method	TabFact	WikiTQ
	Avg Tokens	Avg Tokens
End-to-end	546	794
Few-shot	935	1,189
TableCoT	1,084	1,495
StructGPT	1,721	1,999
TabSQLify	2,194	2,317

Table 4: Average token usage comparison across different methods

Model	FeTaQA			WikiTQ	TabFact
Model	ROUGE-1 F	ROUGE-2 F	ROUGE-L F	Accuracy	Accuracy
Claude 4.0 Sonnet	0.6234	0.3885	0.5067	83.2%	90.8%
Gemini 2.5 Flash	0.6107	0.3767	0.4995	77.9%	87.9%
Qwen3-235B-A22B	0.5972	0.3607	0.4776	73.2%	91.2 %
DeepSeek-V3	0.5403	0.3075	0.4309	73.6%	84.2%
GPT-4o mini	0.5576	0.3320	0.4555	67.8%	79.3%

Table 5: Performance comparison across different model providers and sizes

Panel of Figure 10 — Figure 10: Team invocation patterns across different models and datasets. The visualization demonstrates how task complexity influences tool selection strategies: (a) TabFact shows uniform Database Team preference due to binary classification nature, (b) WikiTQ exhibits moderate diversification with increased Knowledge Graph usage for complex retrieval tasks, and (c) FeTaQA displays highest combined team usage rates reflecting multi-hop reasoning requirements. Blue represents Database Team-only usage, red indicates Knowledge Graph Team-only usage, and orange represents combined team usage.

Dataset	Metric	Model	No KG Team	Complete Framework	Avg. Improvement
TabFact	Accuracy	Claude 4.0 Sonnet	86.7%	90.8% ( $\uparrow$ 4.7%)	5.5%
		Gemini-2.5 Flash	85.1%	87.9% ( $\uparrow$ 3.3%)
		Qwen3-235B-A22B	85.6%	91.2% ( $\uparrow$ 6.5%)
		DeepSeek Chat	82.0%	84.2% ( $\uparrow$ 2.7%)
		GPT-4o mini	77.3%	79.3% ( $\uparrow$ 2.6%)
		Qwen3-32B	67.7%	79.8% ( $\uparrow$ 17.9%)

Table 6: Performance comparison between framework without KG Team and complete framework

Figure 11: Model average performance across different team call frequencies. Error bars represent standard deviation across all models. Blue line shows TabFact dataset results, orange line shows WikiTQ dataset results.

Panel of Figure 12 — Figure 12: Performance heatmaps showing model accuracy across different team collaboration call frequencies. The color intensity represents performance levels, with darker red indicating higher accuracy. Each row represents a different model, and each column represents a different call frequency range (1 call, 2–3 calls, 4–5 calls, 6–10 calls, 10+ calls).

Table QA

Table question answering studies how AI systems retrieve, interpret, and reason over structured data to answer natural-language questions.

See all 66 papers

Evolving from Lessons: Skill-Augmented Table Graph Reasoning for Operation-wise Table Question Answering
Jun 20, 2026Guixin Su, Qiankun Pi, Mayi Xu +5Table QA
School of Computer Science, Wuhan University, Wuhan, China
H2Table: Hierarchical Hypergraph-Enhanced Large Language Models for Complex Table Reasoning
Sep 1, 2026Jia Ling, Yangfan Wang, Chen Tang +4Table QA Hierarchical Representation Learning
Harbin Institute of Technology · AI Research Center, Midea Group (Shanghai) Co., Ltd. · Changchun University of Science and Technology +1
ASTRA: Adaptive Semantic Tree Reasoning Architecture for Complex Table Question Answering
Apr 10, 2026Xiaoke Guo, Songze Li, Zhiqiang Liu +4Table QA LLM Reasoning
Zhejiang University

Jun 20, 2026J/K move · Enter open · S save

Evolving from Lessons: Skill-Augmented Table Graph Reasoning for Operation-wise Table Question Answering

Guixin Su, Qiankun Pi, Mayi Xu, Wenli Li+4

School of Computer Science, Wuhan University, Wuhan, China

Table QA

Open paper AskPDF arXiv

Table Question Answering (TableQA) aims to reason over tables to answer user queries. Existing research treats all questions uniformly and evaluates solely through overall accuracy, obscuring a critical reality that LLMs excel at simple lookups yet struggle with complex operations like aggregation and arithmetic. To reveal this disparity, we introduce a novel Operation-wise TableQA task with a fine-grained question taxonomy and release two datasets named WikiTQ-ow and TabFact-ow for evaluation. As for modeling bottlenecks, existing methods flatten tables into linearized texts, disrupting inherent structures and inducing the ``lost-in-the-middle'' issue, which poses a primary barrier to complex cross-row reasoning. Moreover, they typically reason from scratch, neglecting reusable patterns shared across similar operations. To address these limitations, we propose a Skill-augmented Table Graph Reasoning (SkillTGR) framework for self-evolving structured reasoning. Specifically, SkillTGR represents tables as attributed graphs with explicit row-column-cell structures, where LLMs plan and execute dynamic chains to retrieve evidence subgraphs for graph traversal reasoning. Based on this, SkillTGR builds a hierarchical SkillBank to distill reason trajectories into abstract skills under cognitive heuristics, then hybrid retrieves both successful and failed skills for contrastive augmented table graph reasoning, thereby enabling the continual self-evolution. Extensive experiments demonstrate that SkillTGR achieves superior performance with an average of 5.91% overall and 5.06% operation-wise improvement, also reducing 19.76% token consumption and 27.64% inference latency. Our codes and data will be released upon publication.

Abstract

Table QA

Explore similar work

Evolving from Lessons: Skill-Augmented Table Graph Reasoning for Operation-wise Table Question Answering

H2Table: Hierarchical Hypergraph-Enhanced Large Language Models for Complex Table Reasoning

ASTRA: Adaptive Semantic Tree Reasoning Architecture for Complex Table Question Answering