DAgent: LLM-Powered RDB Report Generation

• DAgent is an LLM-based system that automates analytical report generation from relational databases in response to natural language queries.
• It employs a modular architecture with planning, tools, and memory modules to decompose queries, retrieve data, rewrite SQL, and synthesize narrative reports.
• Experimental results demonstrate state-of-the-art performance in retrieval and report quality, outperforming traditional TableQA and Text-to-SQL methods.

DAgent is an LLM agent system for relational database-driven data analysis (RDB-DA) report generation, introduced to automate the production of analytical reports from relational databases in response to natural-language questions. In the formal problem setting, given a relational database $D=\{T_{1},\ldots,T_{N}\}$, where each table $T_i$ has columns $C_{i1},\ldots,C_{iM}$, and a user question $q$, the goal is to generate a textual analytical report $R$ that satisfies three criteria: completeness, correctness, and conciseness. The system is positioned as a response to the limitations of TableQA and Text-to-SQL methods, which either retrieve isolated values or produce one-off SQL queries but do not carry out multi-step reasoning, cross-table association, and synthesis into coherent analytical prose (Xu et al., 17 Mar 2025).

1. Problem formulation and task scope

RDB-DA report generation targets a class of tasks that are widely applied in fields such as finance and healthcare, but are typically completed manually by data scientists. The task is not merely database querying. It requires decomposition of a natural-language analytical question into logically independent sub-queries, retrieval of key information from relational databases, and synthesis of the results into a fluent report that meets the requirements of completeness, correctness, and conciseness (Xu et al., 17 Mar 2025).

The formal criteria are explicit. Completeness means that $R$ covers all information needed to answer $q$. Correctness means that $R$ accurately reflects the database content with no factual errors. Conciseness means that $R$ contains no redundant or irrelevant information. This definition distinguishes the task from prior settings in which the system either returns single cells or simple aggregates, or stops at SQL generation and execution without post-processing into human-readable analysis (Xu et al., 17 Mar 2025).

A common misconception is to treat DAgent as a variant of Text-to-SQL. The underlying paper rejects that equivalence. TableQA focuses on retrieving individual cells or values and cannot handle chained analytical steps or generate prose; Text-to-SQL translates natural language to SQL but stops at query execution and lacks post-processing into human-readable reports. DAgent is designed specifically for the larger end-to-end problem of database-grounded analytical report generation.

2. Modular architecture

DAgent is structured into three interacting modules—Planning, Tools, and Memory—cooperating in a multi-step reasoning loop. The design is explicitly modular: planning determines how the question should be decomposed and which retrieval strategy should be applied; tools perform decomposition, retrieval, SQL rewriting, and report generation; memory persists intermediate and final artifacts for reuse (Xu et al., 17 Mar 2025).

Module	Core functions
Planning	Decides whether to decompose $q$, selects retrieval strategies, invokes SQL rewriting, orchestrates final report generation
Tools	Problem Decomposition Tool, Data Retrieval Tools, SQL Rewriting Tool, Report Generation Tool
Memory	Stores $T_i$0 subqs, SQLs, results $T_i$1, final report $T_i$2, supports cache look-up, records planning decisions

The Planning Module decides whether to decompose $T_i$3 into sub-questions $T_i$4, selects retrieval strategies such as embedding-based retrieval versus SQL2Text, invokes SQL rewriting for optimization, and orchestrates the final call to the Report Generation Tool. The Tools Module contains four distinct capabilities. The Problem Decomposition Tool implements an LLM with LoRA adapters per domain; its input is the original question $T_i$5 and schema $T_i$6, and its output is the sub-question set $T_i$7. The Data Retrieval Tools include embedding retrieval, which encodes tables and cells into vectors $T_i$8 and finds top-$T_i$9 items via cosine similarity, and Text-to-SQL, which invokes either C3 through zero-shot ChatGPT prompting or FinSQL through LoRA-fine-tuned LLaMA2. The SQL Rewriting Tool uses a LoRA-enabled LLM to refine $C_{i1},\ldots,C_{iM}$0 so as to reduce irrelevant tuples. The Report Generation Tool prompts a large LLM such as LLaMA2 or ChatGPT with $C_{i1},\ldots,C_{iM}$1 to produce the final report $C_{i1},\ldots,C_{iM}$2 (Xu et al., 17 Mar 2025).

The Memory Module stores the question, sub-questions, SQL programs, intermediate results, and the final report. It also supports cache look-up for repeated or similar queries and records planning decisions for future reuse. The paper further identifies memory caching as a mechanism that reduces latency on repeated queries.

3. Multi-step reasoning workflow

DAgent’s execution model is described as a multi-step reasoning workflow. The system initializes memory $C_{i1},\ldots,C_{iM}$3, invokes the planner on $C_{i1},\ldots,C_{iM}$4, and then decides whether to process the task as a single query or as a set of decomposed sub-questions. If decomposition is selected, the Problem Decomposition Tool produces $C_{i1},\ldots,C_{iM}$5; otherwise the singleton set $C_{i1},\ldots,C_{iM}$6 is used (Xu et al., 17 Mar 2025).

For each sub-question, the planner selects either embedding retrieval or Text-to-SQL. In the embedding branch, the system performs semantic retrieval directly over the database content. In the Text-to-SQL branch, the system generates SQL from the sub-question and schema, rewrites the SQL through the SQL Rewriting Tool, executes the rewritten query on the database, and appends the resulting tuple $C_{i1},\ldots,C_{iM}$7 to the results list. Each intermediate result is stored in memory. After all sub-questions are processed, the Report Generation Tool produces the final report from the original question, the sub-questions, and the retrieved results, and the report is stored back in memory (Xu et al., 17 Mar 2025).

This workflow operationalizes several design commitments that recur throughout the paper: decomposition into logically independent sub-queries, hybrid retrieval, SQL optimization through rewriting, and final synthesis into narrative form. The ablation study later shows that query decomposition and hybrid retrieval are the principal contributors to retrieval quality, while SQL rewriting has a smaller but measurable effect.

4. DA-Dataset and evaluation protocol

To support this task, the paper introduces a benchmark for automatic data analysis report generation, including a new dataset called DA-Dataset and evaluation metrics. DA-Dataset is designed for automatic analytical report generation and is reported to contain 735 entries, with DA-CCKS comprising 201 entries drawn from HangSeng Financial data and DA-BIRD comprising 535 entries drawn from the BIRD Text-to-SQL dataset. The average question touches 4.5 tables and 10.8 columns, indicating that the benchmark is explicitly multi-table and multi-attribute rather than a single-relation lookup task (Xu et al., 17 Mar 2025).

The dataset construction pipeline has two stages. Query Synthesis samples 10 Q-SQL pairs, prompts an LLM, generates a multi-aspect analytical question, and then applies manual validation. Report Synthesis proceeds through semantic enhancement by LLM, schema retrieval by cross-encoder, SQL generation plus filtering by execution, and template-driven natural-language generation into the final report. This construction process is intended to align the benchmark with the target task of report generation rather than isolated query answering (Xu et al., 17 Mar 2025).

The evaluation framework separates retrieval quality from report quality. Retrieval is measured with table-level and column-level precision, recall, and $C_{i1},\ldots,C_{iM}$8, together with ContextRelevance, an LLM-scored $C_{i1},\ldots,C_{iM}$9–$q$0 measure of the relevance of retrieved cell contents. For report quality, the formal definitions are: $q$1

$q$2

$q$3

Additional optional metrics are BLEU and ROUGE-L. All report metrics are scored via DeepSeek-v2.5 on a $q$4–$q$5 scale using carefully designed prompts (Xu et al., 17 Mar 2025).

5. Experimental results

The experimental setup uses DA-CCKS and DA-BIRD as evaluation datasets and compares DAgent against LLM-Answer, Schema-Answer, RandomRowCol, Text-to-SQL baselines including LLM-SQL, C3, and FinSQL, and TableQA baselines including TableRAG and ERATTA. The implementation uses the LangChain framework, LLaMA2-13B with LoRA $q$6, an A40 GPU, text-embedding-ada-002 for embedding retrieval, and DeepSeek v2.5 for report generation (Xu et al., 17 Mar 2025).

On retrieval, DAgent is reported as superior on both DA-CCKS and DA-BIRD. On DA-CCKS, DAgent achieves table precision $q$7, recall $q$8, and $q$9 $R$0, along with column precision $R$1, recall $R$2, and $R$3 $R$4, and ContextRelevance $R$5. On DA-BIRD, it achieves table precision $R$6, recall $R$7, and $R$8 $R$9, together with column precision $R$0, recall $R$1, and $R$2 $R$3, and ContextRelevance $R$4. The paper summarizes this as state-of-the-art retrieval $R$5 with gains of $R$6–$R$7 points over the best baseline (Xu et al., 17 Mar 2025).

On report generation quality, Table 3 reports Acc., Rel., and Avg. For DA-CCKS, DAgent attains $R$8 Acc., $R$9 Rel., and $q$0 Avg., compared with TableRAG’s $q$1, $q$2, and $q$3. For DA-BIRD, DAgent attains $q$4 Acc., $q$5 Rel., and $q$6 Avg., compared with TableRAG’s $q$7, $q$8, and $q$9. The paper characterizes these as superior report accuracy and relevance, with gains of $R$0–$R$1 on a $R$2–$R$3 scale (Xu et al., 17 Mar 2025).

The ablation on planning strategies isolates the contributions of the main components. Removing query decomposition reduces retrieval $R$4 by $R$5. Removing hybrid retrieval reduces retrieval $R$6 by $R$7. Removing SQL rewriting reduces retrieval $R$8 by $R$9. These results support the claim that the combination of multi-step decomposition and hybrid retrieval is the central source of performance improvement, while SQL rewriting contributes a smaller but non-negligible gain.

6. Limitations, future work, and name disambiguation

The paper identifies several limitations. DAgent depends on LLM availability and inference cost. Its evaluation relies on LLM-based scoring and may therefore inherit hallucination risk. Its benchmark covers two domains, and further generalization needs testing. These constraints bound the current empirical claims, particularly for deployment across industries not represented in DA-CCKS and DA-BIRD (Xu et al., 17 Mar 2025).

The future-work agenda is correspondingly concrete. Proposed directions include incorporating symbolic reasoning for deeper analytical chains, extending DA-Dataset to more industries such as healthcare and e-commerce, tightening factual grounding through retrieval-augmented LLMs with provenance, and optimizing cost via smaller specialized modules or distillation. A plausible implication is that subsequent systems may shift from a predominantly prompt-and-adapter-based design toward tighter grounding and more specialized components, but this remains prospective rather than demonstrated in the reported experiments.

The label “DAgent” is also used in other contemporary systems and should not be conflated with the RDB-DA report generation agent. In MAGIC, DAgent denotes the adv-patch deployment agent that determines where an adversarial patch should be hung or painted within a driving scene, acting between GAgent and EAgent in a physical adversarial attack pipeline (Xing et al., 2024). In DatasetAgent, “DAgent” is used as a shorthand for a four-agent multimodal system for auto-constructing datasets from real-world images, comprising a Demand Analysis Agent, Image Process Agent, Data Label Agent, and Supervision Agent (Sun et al., 11 Jul 2025). DrugAgent is another coordinator-based multi-agent LLM system, but it is designed for drug-target interaction prediction rather than relational-database report generation (Inoue et al., 2024). These separate usages underscore that, in the context of database analysis, DAgent refers specifically to the system introduced for end-to-end RDB-DA report generation.