GaussMaster: An LLM-based Database Copilot System

Guoliang Li; Hao Wu; Ji Sun; Luyang Liu; Tianyuan Wang; Wei Zhou; Xuanhe Zhou

REVIEW 4 major objections 5 minor 1 cited by

GaussMaster: An LLM-based Database Copilot System

T0 review · 4 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read GaussMaster is an LLM-based copilot for the GaussDB database that claims to handle Q&A and anomaly diagnosis end-to-end, with over 80% fully correct and safe answers on bank questions, above 95% tool selection accuracy, and zero human…

desk verdict Solid engineering story, but the evaluation is a page of assertions and the headline numbers are unsubstantiated. read the letter →

arxiv 2506.23322 v1 pith:XFO7KP3Y submitted 2025-06-29 cs.DB cs.AIcs.CLcs.IR

Wei Zhou , Ji Sun , Xuanhe Zhou , Guoliang Li , Luyang Liu , Hao Wu , Tianyuan Wang This is my paper

classification cs.DBcs.AIcs.CLcs.IR

keywords LLM-basedcopilotdatabasemaintenanceretrieval-augmentedgenerationanomalydiagnosistreemulti-agentLLMtoolorchestrationGaussDB

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper presents GaussMaster, a system that pairs a large language model with a domain knowledge base and a set of diagnostic tools to act as a database technician for GaussDB. It claims the system can answer technical questions and run anomaly diagnosis and repair end-to-end, with fully correct and safe answers on over 80% of 400+ real-world bank questions, tool selection accuracy above 95%, tool parameter filling accuracy above 99%, and zero human intervention across 34 real banking maintenance scenarios. A sympathetic reading takes the claim to be that an LLM-based copilot, guided by expert-written diagnosis trees and multi-agent orchestration, is strong enough for high-stakes commercial database maintenance.

What carries the argument

The load-bearing mechanism is the diagnosis tree: an expert-defined tree whose nodes are specific diagnostic tools (e.g., slow-query root-cause analysis) and whose paths are deterministic troubleshooting sequences for known anomaly types. The system also uses a multi-agent structure in which a chief DBA agent assigns specialized expert agents, decomposes tasks, and runs self-reflection and cross-review before invoking tools, and a RAG pipeline with fine-tuned embedding and reranking models over a 106,810-sample GaussDB corpus, plus a DFA-based word detector and semantic classifier for risky content. The diagnosis tree carries the argument because it is what makes tool orchestration reliable enough to report 95%+ accuracy.

What would settle it

Re-test GaussMaster on a fresh question set written by DBAs who did not contribute to its knowledge base, with answers scored blindly by independent DBAs, and audit the logs of the 34 maintenance scenarios for any human confirmation, override, or parameter correction; a drop below 80% correct-and-safe answers or any logged human action in the zero-intervention scenarios would disprove the central claim.

Watch

Extended reading notes

Core claim

The central discovery is that the combination of (i) a curated GaussDB knowledge base with hybrid literal-and-semantic retrieval and reranking, (ii) risk-checking on both questions and answers, and (iii) diagnosis-tree-guided, multi-agent tool orchestration lets an LLM handle database maintenance tasks that previously required human DBAs. The paper reports 85.23% high-quality answers on 400+ questions from a banking context, 95%+ tool selection accuracy and 99%+ parameter filling accuracy in anomaly diagnosis, and zero human intervention maintained over 34 real-world database maintenance scenarios. The diagnosis tree is what converts open-ended LLM exploration into a deterministic, targeted tool-invocation pipeline.

Load-bearing premise

The results depend on the evaluation being independent of the system's own construction: the 400+ test questions, standard answers, tool labels, and the 34 zero-human-intervention scenarios must not have been drawn from the same GaussDB documents and diagnosis trees used to build GaussMaster, or the reported accuracies could reflect memorized ground truth rather than real capability.

Editorial extensions

If this is right

If correct, LLM-based copilots can take over the full database maintenance loop, not just single-point tasks like text-to-SQL or anomaly detection.
The diagnosis-tree approach suggests a general recipe: encode expert workflows explicitly so LLM tool invocation becomes deterministic enough for production.
High Q&A accuracy on domain-specific questions indicates that retrieval-augmented generation plus safety filtering can be made to work for proprietary, documentation-poor database products.
The system's orchestration of 25 diagnostic tools shows that multi-agent LLM pipelines can be reliable enough for commercial banking environments.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The same architecture could transfer to other database products or other complex systems by rebuilding the knowledge base and diagnosis trees; nothing in the design appears to be GaussDB-specific, though the paper does not test this transfer.
Zero human intervention is measured at the scenario level; a stricter audit would count every implicit human action such as alert acknowledgment, monitoring, or fallback, which the paper does not define.
A natural next evaluation would measure whether the chosen tools actually produce the correct root cause, rather than only whether the correct API and arguments were selected.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Useful paper to skim, but the evidence section is one page of assertion. GaussMaster is a real system—Huawei's LLM copilot for GaussDB, with code released—and the engineering story is coherent: hybrid retrieval, fine-tuned embedding and reranker, a safety classifier, diagnosis trees wrapping DBMind tools, and a multi-agent orchestration layer. That is genuine integration work, and the 'what we built and where we put it' part is fine.

What is new is the bundle, not the pieces. RAG, multi-agent diagnosis, and tool orchestration all appear in the cited D-Bot and LLM As DBA work. The contribution is the specific GaussDB instantiation and the reported deployment numbers. If those numbers hold, the paper matters for practitioners.

The soft spot is exactly where the stress-test says: Section 3.2 gives no protocol. The 400+ 'real-world questions' are not described—no sampling, no authorship of standard answers, no statement that they are disjoint from the 106,810 samples used to fine-tune the embedder, reranker, and risk classifier. Tool selection and parameter-filling accuracy have no test-set description, no baseline, no variance. The 'zero human intervention for 34 scenarios' has no definition of intervention, no denominator, no logs. Those are the load-bearing numbers of the paper, and as written they are unsupported. The lack of any comparison with D-Bot or LLM As DBA also makes the incremental value hard to judge.

I do not think this is fraud; it reads like a system paper rushed to an arXiv deadline. But the central claim—that an LLM can run end-to-end database maintenance with zero intervention—is not yet substantiated.

Who gets value? People building LLM copilots for operational systems will want the architecture and the safety-control details. The paper deserves peer review because the system is real and deployed, and a referee can push the authors to produce a real evaluation. I would accept it with the clear expectation of heavy revision: evaluation protocol, dataset release, baselines, error analysis. If that comes, this could be a solid systems contribution. As it stands, cite with caution.

Referee Report

4 major / 5 minor

Summary. The paper describes GaussMaster, an LLM-based copilot for GaussDB that integrates a multi-source knowledge base, a RAG-based Q&A pipeline with safety checks, and a diagnosis-and-repair module built on DBMind tools, expert-defined diagnosis trees, and multi-agent orchestration. The central claims are that in real banking deployments GaussMaster achieves 85.23% high-quality answers over 400+ real-world questions, over 95% tool selection accuracy and over 99% parameter-filling accuracy for anomaly diagnosis, and zero human intervention across 34 maintenance scenarios.

Significance. If the reported numbers are credible, GaussMaster would be a noteworthy existence proof for LLM-based end-to-end database maintenance in a high-stakes industrial setting, and several design choices (hybrid retrieval, safety filtering, diagnosis-tree-guided orchestration, cross-review among expert agents) are sensible responses to known LLM failure modes. The paper also provides a public code link, which is a positive step for reproducibility. However, the evaluation as reported in Section 3.2 is too thin to support the quantitative claims: it lacks a defined protocol, baselines, uncertainty estimates, and, most importantly, evidence that the test data and standard answers are independent of the corpus used to build and fine-tune the system. The industrial deployment claim about 'zero human intervention' is similarly underspecified. I therefore cannot yet accept the central claims at face value.

major comments (4)

[§3.2, Answer Quality] The 85.23% figure is presented with no evaluation protocol. The reader is not told how the 400+ questions were sampled, who wrote the standard answers, how the human/LLM judges were calibrated or how disagreements were resolved, or what 'high-quality' means beyond the three aspects listed. Without a baseline or a difficulty distribution, this single aggregate number cannot be interpreted; Figure 4(a) shows a category distribution but no per-category accuracy or error bars.
[§3.2, Tool Invocation Accuracy] The claims of '95%+ tool selection accuracy and 99%+ parameter filling accuracy' lack a denominator, a test anomaly set, and a definition of correct parameter filling. It is also unclear whether the reported numbers include only tools that were actually invoked or all possible tools, and no comparison is made to D-Bot, Panda, or a naive LLM agent baseline, so the improvement claim is not supported.
[§2.2 and §2.3] The evaluation is exposed to training/test contamination. The embedding model, reranker, and risk classifier are fine-tuned on a GaussDB corpus of 106,810 samples, and the knowledge base is built from the same GaussDB documents and DBMind tools used to construct the diagnosis trees. If the 400+ test questions and their standard answers were derived from the same documents or written by authors familiar with the diagnosis trees, the reported accuracies partly measure retrieval of seen content. The paper must either release the test set and standard answers, or describe a temporal/editorial split that guarantees independence (e.g., questions collected after the knowledge base was frozen, authored by a separate team).
[Abstract and §3.2] The 'zero human intervention for over 34 database maintenance scenarios' claim is not operationalized. There is no definition of 'intervention', no statement of how many scenarios were attempted in total, no time window, no operation logs, and no independent audit. As written this claim is unfalsifiable; it should either be replaced by a precise metric (e.g., median number of human actions per incident) with supporting logs, or removed.

minor comments (5)

[Figure 4] Both subfigures lack axis labels and legends; 'Question Distribution' and 'Answer Quality Distribution' are not defined in the caption, making it impossible to know what the x and y axes measure.
[Abstract] The phrase 'Tree-of-thought approach' is not reflected in Section 2.4, which describes diagnosis-tree-guided orchestration and self-reflection rather than the Tree-of-Thought prompting method; please clarify whether ToT is actually used.
[§2.3] The same count '106,810 samples' appears for both the retrieval fine-tuning corpus and the risk-classifier training set; clarify whether these are the same data or two different collections.
[§3.1] The demonstration is described as 'real-world banking', but Figure 3 is a schematic diagram; providing actual screenshots with anonymized data would strengthen the presentation.
[Abstract and §1] The code link is mentioned but the repository content is not described; please state which components are released and under what license.

Circularity Check

0 steps flagged · score 0.0 of 10

No demonstrated circular derivation; reported accuracies are empirical claims whose independence from the training corpus is not documented, which is an evidentiary concern rather than a circular step.

full rationale

GaussMaster is a systems/empirical paper, not a derivation. The closest candidate for circularity is the possibility that the 400+ test questions and standard answers overlap the 106,810-sample GaussDB corpus used to fine-tune the embedding, reranker, and risk classifier, and that the diagnosis-tree/tool labels used in evaluation come from the same DBMind components cited in the system. However, the paper never states such overlap, and no equation or construction in the text forces the reported accuracies to equal a fitted quantity. The Q&A evaluation uses human and LLM judges with standard answers, but without quote-level evidence that those standard answers were generated from the same documents used to build the knowledge base, this remains a missing-protocol/contamination concern, not a demonstrated circular reduction. Tool-selection accuracy is measured against DBMind's own tool set, but that is an internal system metric, not a derived prediction that reduces to its input by construction. Self-citations to DBMind [10] and D-Bot [11,12] support components or related work, but they are not invoked as load-bearing uniqueness theorems or as the sole justification for the headline numbers. The 'zero human intervention over 34 scenarios' claim is an anecdotal field claim with no protocol, but absence of supporting detail is a correctness/evidence risk, not circularity. Under the hard rule requiring a quotable construction or fitted-parameter rename, no circular step can be established, so the appropriate finding is no significant circularity.

Assumptions & free parameters 3 free parameters · 4 assumptions · 2 invented entities

The system's claimed performance depends on a set of hand-chosen thresholds (e.g., reranker score cutoff), the completeness of the 25 DBMind tools and expert-defined diagnosis trees, the capability of the underlying Pangu-38B LLM, and the reliability of the judges. None of these are independently established, so the reported accuracy figures rest on several unverified assumptions.

free parameters (3)

Reranker score threshold = 0.0
Documents with relevance scores below zero are discarded (Section 2.3). This threshold was chosen by hand and directly affects retrieval quality, hence answer quality.
Number of DBMind diagnostic tools = 25
The set of exposed tools determines the diagnosis coverage (Section 2.2). Its completeness is an engineering choice, not an established scientific benchmark.
Safety classifier latency budget = 500 ms
A design target for the XLNet safety classifier (Section 2.3). Not central to the accuracy claims but constrains the architecture.

assumptions (4)

domain assumption DBMind's 25 diagnostic tools produce correct and complete diagnostic information for GaussDB anomalies.
Invoked in Section 2.2 and Section 2.4 as the foundation for all tool-based diagnosis; if these tools are incomplete or erroneous, the claimed tool selection accuracy is meaningless.
domain assumption The expert-defined diagnosis trees correctly encode the troubleshooting procedures for each anomaly class.
Section 2.4 states the trees correspond to deterministic tool invocation pipelines, but no evidence is given that the trees cover the variety of real-world anomalies or that they are correct.
domain assumption The base LLM (Pangu-38B) is sufficiently capable for the generation, reflection, and tool-invocation tasks.
The entire system depends on the commercial model's reliability; no independent evaluation of this model is provided.
domain assumption The human and LLM judges in the evaluation are consistent and unbiased.
Section 3.2 describes a hybrid evaluation, but the paper does not report inter-annotator agreement or validation of the LLM-as-judge, so judge reliability is assumed.

invented entities (2)

DBA agent and specialized expert agents (Resource Expert, Component Expert, etc.)
purpose: Coordinate and execute multi-agent diagnosis by assigning tasks, invoking tools, and generating reports.
Introduced in Section 2.4 as part of the system architecture. They have no external falsifiable handle beyond the system's own evaluation; their effectiveness is not independently validated.
Anomaly diagnosis trees
purpose: Expert-defined sequences of tool invocations that guide deterministic diagnosis.
Described in Section 2.2 and 2.4. The trees are authored by the system's developers and are not verified against external standards.

how reviews work

0 comments

Cite this review

Pith. "Pith review of GaussMaster: An LLM-based Database Copilot System." pith.science (2026). https://pith.science/paper/XFO7KP3Y

@misc{pith2026250623322,
  author       = {Pith},
  title        = {Pith review of: GaussMaster: An LLM-based Database Copilot System},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XFO7KP3Y}},
  note         = {Machine review of arXiv:2506.23322}
}

read the original abstract

In the financial industry, data is the lifeblood of operations, and DBAs shoulder significant responsibilities for SQL tuning, database deployment, diagnosis, and service repair. In recent years, both database vendors and customers have increasingly turned to autonomous database platforms in an effort to alleviate the heavy workload of DBAs. However, existing autonomous database platforms are limited in their capabilities, primarily addressing single-point issues such as NL2SQL, anomaly detection, and SQL tuning. Manual intervention remains a necessity for comprehensive database maintenance. GaussMaster aims to revolutionize this landscape by introducing an LLM-based database copilot system. This innovative solution is designed not only to assist developers in writing efficient SQL queries but also to provide comprehensive care for database services. When database instances exhibit abnormal behavior, GaussMaster is capable of orchestrating the entire maintenance process automatically. It achieves this by analyzing hundreds of metrics and logs, employing a Tree-of-thought approach to identify root causes, and invoking appropriate tools to resolve issues. We have successfully implemented GaussMaster in real-world scenarios, such as the banking industry, where it has achieved zero human intervention for over 34 database maintenance scenarios. In this paper, we present significant improvements in these tasks with code at https://gitcode.com/opengauss/openGauss-GaussMaster.

Figures

Figures reproduced from arXiv: 2506.23322 by the authors.

**Figure 1.** GaussMaster offers comprehensive database maintenance ability across diverse tasks. either fail to provide conclusive answers or incorrectly infer from other database systems (e.g., PostgreSQL rather than GaussDB). Second, high-stakes enterprise environments, such as banking, demand strict correctness and safety, yet LLMs easily produce irrelevant or even hazardous responses. For instance, LLMs may hallucinate uns… view at source ↗

**Figure 2.** Overview of GaussMaster Knowledge Base Preparation. GaussMaster aggregates multisource GaussDB documents into a unified knowledge base, splitting text by semantic boundaries (e.g., the code block including GaussDB SQLs), retaining structural elements (e.g., the hierarchical titles in markdown files), and removing duplicates. Each chunk is augmented with version tags and neighboring context. Additionally, GaussMast… view at source ↗

**Figure 3.** Demonstration of LLM-based Q&A and LLM-based Diagnosis & Repair in GaussMaster. (a) Question Distribution (b) Answer Quality Distribution [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

Figures from the paper (1 more)

**Figure 4.** Figure 4: Answer Quality of Testing Questions. the tool invocation accuracy of LLM-based Diagnosis & Repair over different database anomalies. The underlying LLM is Pangu-38B (a commercial model in Huawei) by default. Answer Quality. We adopt a hybrid evaluation strategy where b…

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

DBA-Bench: A Production-Fidelity Benchmark for LLM-Based Database Operations Agents
cs.DB 2026-07 conditional novelty 6.0 of 10

A production-fidelity benchmark finds that LLM database-operation agents achieve at most 17.9% safe recovery versus 93.4% for human DBAs.

Reference graph

Works this paper leans on

14 extracted references · 9 canonical work pages · cited by 1 Pith paper

[1]

(Artificial Intelligence)

Amazon. (Artificial Intelligence). https://aws.amazon.com/ai/

work page
[2]

(Intelligent Applications)

Azure SQL. (Intelligent Applications) . https://learn.microsoft.com/en- us/azure/azure-sql/database/ai-artificial-intelligence-intelligent-applications? view=azuresql

work page
[3]

(Database 23ai)

Oracle. (Database 23ai). https://www.oracle.com/database/23ai/

work page
[4]

Sihem Amer-Yahia, Angela Bonifati, Lei Chen, Guoliang Li, Kyuseok Shim, Jian- liang Xu, and Xiaochun Yang. 2023. From Large Language Models to Databases and Back: A Discussion on Research and Education. SIGMOD Rec. 52, 3 (2023), 49–56

work page 2023
[5]

Guoliang Li, Xuanhe Zhou, and Xinyang Zhao. 2024. LLM for Data Management. Proc. VLDB Endow. 17, 12 (2024), 4213–4216

work page 2024
[6]

Singh, Kapil Vaidya, Vinayshekhar Bannihatti Kumar, Sopan Khosla, Balakrishnan Narayanaswamy, Rashmi Gangadharaiah, and Tim Kraska

Vikramank Y. Singh, Kapil Vaidya, Vinayshekhar Bannihatti Kumar, Sopan Khosla, Balakrishnan Narayanaswamy, Rashmi Gangadharaiah, and Tim Kraska

work page
[7]

Hao Sun, Zhexin Zhang, Jiawen Deng, Jiale Cheng, and Minlie Huang. 2023. Safety Assessment of Chinese Large Language Models. CoRR abs/2304.10436 (2023)

arXiv 2023
[8]

Wei Zhou, Yuyang Gao, Xuanhe Zhou, and Guoliang Li. 2025. Cracking SQL Barriers: An LLM-based Dialect Transaltion System. Proc. ACM Manag. Data 3, 3 (SIGMOD) (2025)

2025

Show all 14 references

[9]

Wei Zhou, Yuyang Gao, Xuanhe Zhou, and Guoliang Li. 2025. CrackSQL: A Hybrid SQL Dialect Translation System Powered by Large Language Models. arXiv Preprint (2025). https://arxiv.org/abs/2504.00882

2025 arXiv
[10]

Xuanhe Zhou, Lianyuan Jin, Ji Sun, Xinyang Zhao, Xiang Yu, Shifu Li, Tianqing Wang, Kun Li, and Luyang Liu. 2021. DBMind: A Self-Driving Platform in openGauss. Proc. VLDB Endow. 14, 12 (2021), 2743–2746

2021
[11]

Xuanhe Zhou, Guoliang Li, and Zhiyuan Liu. 2023. LLM As DBA. CoRR abs/2308.05481 (2023)

2023 arXiv
[12]

Xuanhe Zhou, Guoliang Li, Zhaoyan Sun, Zhiyuan Liu, Weize Chen, Jianming Wu, Jiesi Liu, Ruohang Feng, and Guoyang Zeng. 2024. D-Bot: Database Diagnosis System using Large Language Models. Proc. VLDB Endow. 17, 10 (2024), 2514– 2527

2024
[13]

Xuanhe Zhou, Luyang Liu, Wenbo Li, Lianyuan Jin, Shifu Li, Tianqing Wang, and Jianhua Feng. 2022. AutoIndex: An Incremental Index Management System for Dynamic Workloads. In ICDE. IEEE, 2196–2208. 4

2022
[2024]

In 14th Conference on Innovative Data Systems Research, CIDR 2024, Chaminade, HI, USA, January 14-17, 2024

Panda: Performance Debugging for Databases using LLM Agents. In 14th Conference on Innovative Data Systems Research, CIDR 2024, Chaminade, HI, USA, January 14-17, 2024. www.cidrdb.org. https://www.cidrdb.org/cidr2024/papers/ p6-singh.pdf

2024

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.

[1] [1]

(Artificial Intelligence)

Amazon. (Artificial Intelligence). https://aws.amazon.com/ai/

work page

[2] [2]

(Intelligent Applications)

Azure SQL. (Intelligent Applications) . https://learn.microsoft.com/en- us/azure/azure-sql/database/ai-artificial-intelligence-intelligent-applications? view=azuresql

work page

[3] [3]

(Database 23ai)

Oracle. (Database 23ai). https://www.oracle.com/database/23ai/

work page

[4] [4]

Sihem Amer-Yahia, Angela Bonifati, Lei Chen, Guoliang Li, Kyuseok Shim, Jian- liang Xu, and Xiaochun Yang. 2023. From Large Language Models to Databases and Back: A Discussion on Research and Education. SIGMOD Rec. 52, 3 (2023), 49–56

work page 2023

[5] [5]

Guoliang Li, Xuanhe Zhou, and Xinyang Zhao. 2024. LLM for Data Management. Proc. VLDB Endow. 17, 12 (2024), 4213–4216

work page 2024

[6] [6]

Singh, Kapil Vaidya, Vinayshekhar Bannihatti Kumar, Sopan Khosla, Balakrishnan Narayanaswamy, Rashmi Gangadharaiah, and Tim Kraska

Vikramank Y. Singh, Kapil Vaidya, Vinayshekhar Bannihatti Kumar, Sopan Khosla, Balakrishnan Narayanaswamy, Rashmi Gangadharaiah, and Tim Kraska

work page

[7] [7]

Hao Sun, Zhexin Zhang, Jiawen Deng, Jiale Cheng, and Minlie Huang. 2023. Safety Assessment of Chinese Large Language Models. CoRR abs/2304.10436 (2023)

arXiv 2023

[8] [8]

Wei Zhou, Yuyang Gao, Xuanhe Zhou, and Guoliang Li. 2025. Cracking SQL Barriers: An LLM-based Dialect Transaltion System. Proc. ACM Manag. Data 3, 3 (SIGMOD) (2025)

2025