arxiv: 2605.00043 · v1 · submitted 2026-04-29 · 💻 cs.DB · cs.AI· cs.MA

Recognition: unknown

SiriusHelper: An LLM Agent-Based Operations Assistant for Big Data Platforms

Yu Shen , Shiyang Liu , Qihang He , Yihang Cheng , Haining Xie , Zhiming He , Huahua Fan , Xianzhi Tan

show 9 more authors

Teng Ma Shaoquan Zhang Danqing Huang Fan Jiang Yang Li Chongqing Zhao Peng Chen Jie Jiang Bin Cui

Authors on Pith no claims yet

Pith reviewed 2026-05-09 21:03 UTC · model grok-4.3

classification 💻 cs.DB cs.AIcs.MA

keywords LLM agentbig data operationsknowledge base retrievalSOP distillationtroubleshooting assistantmulti-hop retrievalticket reductionintent routing

0 comments

The pith

SiriusHelper deploys an LLM agent that routes user queries, performs multi-hop retrieval via a hierarchical knowledge base, and distills SOPs from tickets to reduce big data platform support volume by 20.8 percent.

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

The paper introduces SiriusHelper as a deployed assistant that automatically detects intent and directs queries to general or specialized paths such as SQL troubleshooting. It tackles inefficient knowledge retrieval and high maintenance costs by combining DeepSearch with a priority-ordered hierarchical knowledge base for reliable multi-hop access and by automatically analyzing failed tickets to extract reusable operating procedures. A sympathetic reader would care because this setup promises to lower the workload on operations staff while keeping answers accurate and up to date without constant manual updates.

Core claim

SiriusHelper acts as a unified online assistant that identifies user intent and routes queries to appropriate handling paths, including expert workflows for domain-specific cases like SQL execution diagnosis. It combines a DeepSearch-driven mechanism with a priority-based hierarchical knowledge base to support multi-hop retrieval without context overload. The system also performs automated ticket understanding to diagnose failure reasons and extract domain-specific SOPs that continuously enrich the knowledge base, resulting in better performance than alternatives and a measured 20.8 percent drop in online ticket volume during deployment on the Tencent Big Data platform.

What carries the argument

The DeepSearch-driven mechanism paired with a priority-based hierarchical knowledge base for multi-hop retrieval, together with automated ticket understanding and SOP distillation that diagnoses failures and adds reusable procedures back into the system.

If this is right

The assistant outperforms representative alternatives in both offline experiments and live use.
Online ticket volume drops by 20.8 percent once the system is active.
Both broad consultation and specialized troubleshooting workflows receive dedicated handling paths.
Escalated tickets are converted into structured SOPs that improve the knowledge base over time.
Answer reliability rises and response latency falls for complex queries that require several retrieval steps.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

The same routing-plus-hierarchical-retrieval pattern could transfer to other enterprise platforms that face similar general-versus-specialized query mixes.
If ticket distillation works reliably, the volume of human expert involvement in support loops should continue to decline as the knowledge base matures.
Extending the priority hierarchy to include temporal or usage-based weighting might further improve retrieval precision in rapidly changing data environments.
Teams running large-scale data services could test whether replacing flat RAG indexes with this hierarchical approach yields comparable ticket reductions outside the original deployment setting.

Load-bearing premise

The DeepSearch mechanism with the hierarchical knowledge base will consistently deliver accurate multi-hop results without overwhelming context, and the automated analysis of tickets will correctly identify missing knowledge or routing errors to produce useful SOPs.

What would settle it

A controlled deployment in which multi-hop troubleshooting queries continue to produce incomplete or slow answers or in which ticket analysis yields no new reusable SOPs, so that ticket volume shows no measurable reduction after rollout.

Figures

Figures reproduced from arXiv: 2605.00043 by Bin Cui, Chongqing Zhao, Danqing Huang, Fan Jiang, Haining Xie, Huahua Fan, Jie Jiang, Peng Chen, Qihang He, Shaoquan Zhang, Shiyang Liu, Teng Ma, Xianzhi Tan, Yang Li, Yihang Cheng, Yu Shen, Zhiming He.

**Figure 1.** Figure 1: SiriusHelper system overview. (1) Multi-turn search: The agent iteratively refines queries, retrieves evidence, and summarizes intermediate findings. (2) Multi-source retrieval: The agent gathers information from different sources, such as web pages and private databases. Under this agentic setting, search is defined as an active loop: the agent repeats retrieval and synthesis until it has collected enough… view at source ↗

**Figure 2.** Figure 2: Specialized agent workflow in SiriusHelper. [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗

**Figure 3.** Figure 3: SOP extraction workflow. the core issue in the ticket is still unresolved, has only been addressed with a temporary workaround due to a known bug, or is intermittent. Invalid tickets are discarded, and only valid tickets are passed to the SOP generation stage. Stage 2: Structured SOP Generation. This stage generates structured SOPs and reduces hallucination through an iterative “generate-verify” loop with… view at source ↗

**Figure 4.** Figure 4: Product interface I: In-console diagnosis. [PITH_FULL_IMAGE:figures/full_fig_p008_4.png] view at source ↗

**Figure 5.** Figure 5: Product interface II: Chatbot. completion through disambiguation and multi-turn follow-up questions. Given the request type, this component checks whether a minimal set of required fields is present (e.g., task ID, error logs). If critical inputs are missing (e.g., diagnosing a failure without any logs), SiriusHelper asks targeted questions and guides users to paste the most relevant log snippets for diag… view at source ↗

**Figure 6.** Figure 6: Ticket volume from Mar 2024 to Jan 2026. [PITH_FULL_IMAGE:figures/full_fig_p009_6.png] view at source ↗

read the original abstract

Big data platforms are widely used in modern enterprises, and an in-production intelligent assistant is increasingly important to help users quickly find actionable guidance and reduce operational burden. While recent LLM+RAG assistants provide a natural interface, they face practical challenges in real deployments: limited scenario coverage across both general consultation and domain-specific troubleshooting workflows, inefficient knowledge access due to inadequate multi-hop retrieval and flat knowledge organization, and high maintenance cost because escalated tickets are unstructured and hard to convert into assistant improvements and reusable SOPs. In this paper, we present SiriusHelper, a deployed intelligent assistant for big data platforms. SiriusHelper serves as a unified online assistant that automatically identifies user intent and routes queries to the right handling path, including dedicated expert workflows for specialized scenarios (e.g., SQL execution diagnosis). To support complex troubleshooting, SiriusHelper combines a DeepSearch-driven mechanism with a priority-based hierarchical knowledge base to enable multi-hop retrieval without context overload, thus improving answer reliability and latency. To reduce expert overhead, SiriusHelper further introduces automated ticket understanding and SOP distillation: it diagnoses the assistant failure reason (e.g., missing knowledge or wrong routing) and extracts domain-specific SOPs to continuously enrich the knowledge base. Experiments and online deployment on Tencent Big Data platform show that SiriusHelper outperforms representative alternatives and reduces online ticket volume by 20.8\%.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

SiriusHelper describes a real deployed LLM assistant for big data ops with some domain tweaks, but the 20.8% ticket reduction rests on thin evidence.

read the letter

The paper presents SiriusHelper, a production LLM agent for Tencent's big data platform. It routes queries to general or expert paths, uses DeepSearch plus a priority-based hierarchical knowledge base for multi-hop troubleshooting retrieval, and adds automated ticket analysis to diagnose failures and distill SOPs that feed back into the knowledge base. These pieces target actual pain points like poor coverage, retrieval overload, and the cost of turning tickets into reusable knowledge. The deployment angle is the main draw here, since it shows the system running live rather than just in a lab setup. The 20.8% drop in online ticket volume is the headline number, and a working version of this could cut expert time in similar environments. What the paper does well is lay out the engineering choices for handling both broad queries and specialized diagnostics in one interface. The hierarchical KB and feedback loop from tickets are sensible additions to standard RAG patterns for this domain. The soft spots are in the evaluation. The abstract gives no baselines for the outperformance claim, no definition of the metrics, and no numbers on how accurately the ticket understanding diagnoses issues or extracts clean SOPs. Without that, or any ablation on whether the enrichment step improves retrieval rather than adding noise, the causal story for the ticket reduction stays weak. The stress-test note flags exactly this gap, and it holds up. If the diagnosis step is imprecise, the self-improvement could degrade the system over time. This is for practitioners building or running LLM assistants in enterprise big data or ops settings, and for researchers who want concrete examples of applied RAG in production. It has enough real deployment detail to be worth skimming for ideas. I would send it to peer review. The production experience adds value, but referees should require clearer experimental details and validation on the automated components before the claims can be taken at face value.

Referee Report

2 major / 1 minor

Summary. The paper presents SiriusHelper, an LLM agent-based operations assistant for big data platforms. It automatically identifies user intent and routes queries to appropriate handling paths including expert workflows, combines a DeepSearch-driven mechanism with a priority-based hierarchical knowledge base for multi-hop retrieval, and introduces automated ticket understanding to diagnose failure reasons and distill SOPs for continuous KB enrichment. Experiments and online deployment on the Tencent Big Data platform are claimed to show outperformance over representative alternatives and a 20.8% reduction in online ticket volume.

Significance. If the empirical deployment outcomes hold under scrutiny, the work could have practical significance for applied LLM systems in enterprise big data operations by addressing scenario coverage, multi-hop knowledge access, and maintenance costs through a self-improving mechanism. The real-world deployment and ticket reduction result, if substantiated with proper controls, would provide valuable evidence of impact beyond synthetic benchmarks.

major comments (2)

Abstract: The central claims of outperformance over alternatives and a 20.8% reduction in online ticket volume are presented without experimental details, baseline definitions, metric definitions, or statistical tests, preventing verification of the data-to-claim linkage for the headline result.
Abstract: The automated ticket understanding and SOP distillation mechanism is described as diagnosing failure reasons (e.g., missing knowledge or wrong routing) and enriching the KB, but no quantitative validation of diagnosis precision, error analysis on extracted SOPs, or ablation studies showing the enrichment step improves retrieval quality are supplied; this is load-bearing for the self-improvement loop and the attributed ticket reduction.

minor comments (1)

The abstract could more explicitly define key terms such as 'DeepSearch-driven mechanism' and 'priority-based hierarchical knowledge base' to improve accessibility for readers unfamiliar with the specific implementation.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive and detailed feedback. We address each major comment below and indicate where revisions to the manuscript are planned.

read point-by-point responses

Referee: Abstract: The central claims of outperformance over alternatives and a 20.8% reduction in online ticket volume are presented without experimental details, baseline definitions, metric definitions, or statistical tests, preventing verification of the data-to-claim linkage for the headline result.

Authors: We agree the abstract is concise by design. The full experimental details—including baseline definitions (vanilla LLM, standard RAG, and other agent baselines), metrics (accuracy, latency, retrieval F1, and ticket volume), and statistical tests (paired t-tests with p-values reported)—appear in Section 5 (Experiments) and the online deployment subsection. The 20.8% reduction comes from a controlled production A/B test on the Tencent platform. To improve standalone readability of the abstract, we will add one sentence summarizing the evaluation methodology and explicitly directing readers to Section 5. revision: yes
Referee: Abstract: The automated ticket understanding and SOP distillation mechanism is described as diagnosing failure reasons (e.g., missing knowledge or wrong routing) and enriching the KB, but no quantitative validation of diagnosis precision, error analysis on extracted SOPs, or ablation studies showing the enrichment step improves retrieval quality are supplied; this is load-bearing for the self-improvement loop and the attributed ticket reduction.

Authors: The primary evidence for the self-improvement loop is the measured 20.8% ticket-volume reduction in the live deployment, which occurred after the SOP-distillation component was activated and directly addressed diagnosed gaps (missing knowledge or routing errors). We acknowledge that dedicated quantitative validation—diagnosis precision on annotated tickets, error analysis of extracted SOPs, and an ablation isolating the enrichment step—would strengthen the claim. We will add these analyses (including a new ablation table) to the revised Experiments section. revision: yes

Circularity Check

0 steps flagged

No derivational circularity; purely empirical system evaluation

full rationale

The paper describes an LLM-based assistant architecture (DeepSearch + hierarchical KB + automated ticket understanding) and supports its claims exclusively via deployment metrics on Tencent's platform, including a reported 20.8% ticket reduction. No equations, first-principles derivations, fitted parameters renamed as predictions, or uniqueness theorems appear in the provided text. All load-bearing assertions reduce to observed outcomes rather than self-referential definitions or self-citation chains, rendering the evaluation self-contained against external benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 2 invented entities

The central claim depends on domain assumptions about LLM intent routing and retrieval reliability plus two newly introduced mechanisms whose effectiveness is asserted but not independently evidenced in the abstract.

axioms (2)

domain assumption LLMs can accurately identify user intent and route queries to the correct expert workflow
Required for the unified assistant to function as described.
domain assumption A priority-based hierarchical knowledge base supports reliable multi-hop retrieval without context overload
Core premise behind the DeepSearch component.

invented entities (2)

DeepSearch-driven mechanism no independent evidence
purpose: Enable multi-hop retrieval without context overload for complex troubleshooting
New retrieval component introduced to address knowledge-access inefficiency.
Automated ticket understanding and SOP distillation no independent evidence
purpose: Diagnose assistant failures and extract reusable SOPs to enrich the knowledge base
Mechanism introduced to reduce expert maintenance overhead.

pith-pipeline@v0.9.0 · 5590 in / 1496 out tokens · 34193 ms · 2026-05-09T21:03:37.958301+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

36 extracted references · 14 canonical work pages · 4 internal anchors

[1]

Sorinel Căpus,neanu, Cristian-Marian Barbu, Alina-Georgiana Solomon, and Ileana-Sorina Rakos. 2025. Reshaping the Digital Economy with Big Data: A Meta-Analysis of Trends and Technological Evolution.Electronics14, 13 (2025), 2709

2025
[2]

Qiguang Chen, Libo Qin, Jinhao Liu, Dengyun Peng, Jiannan Guan, Peng Wang, Mengkang Hu, Yuhang Zhou, Te Gao, and Wanxiang Che. 2025. Towards reason- ing era: A survey of long chain-of-thought for reasoning large language models. arXiv preprint arXiv:2503.09567(2025)

work page internal anchor Pith review arXiv 2025
[3]

Fengxiang Cheng, Haoxuan Li, Fenrong Liu, Robert Van Rooij, Kun Zhang, and Zhouchen Lin. 2025. Empowering llms with logical reasoning: A comprehensive survey.arXiv preprint arXiv:2502.15652(2025)

work page arXiv 2025
[4]

Giuseppe Crupi, Rosalia Tufano, Alejandro Velasco, Antonio Mastropaolo, Denys Poshyvanyk, and Gabriele Bavota. 2025. On the Effectiveness of LLM-as-a- judge for Code Generation and Summarization.IEEE Transactions on Software Engineering(2025)

2025
[5]

Tianyu Cui, Ruowei Fu, Changchang Liu, Yuhe Ji, Wenwei Gu, Shenglin Zhang, Yongqian Sun, and Dan Pei. 2025. AetherLog: Log-based Root Cause Analysis by Integrating Large Language Models with Knowledge Graphs. In2025 IEEE 36th International Symposium on Software Reliability Engineering (ISSRE). 49–60. https://doi.org/10.1109/ISSRE66568.2025.00019

work page doi:10.1109/issre66568.2025.00019 2025
[6]

Umit Demirbaga and Gagangeet Singh Aujla. 2023. Rootpath: Root cause and critical path analysis to ensure sustainable and resilient consumer-centric big data processing under fault scenarios.IEEE Transactions on Consumer Electronics 70, 1 (2023), 1493–1500

2023
[7]

Umit Demirbaga, Zhenyu Wen, Ayman Noor, Karan Mitra, Khaled Alwasel, Saurabh Garg, Albert Y Zomaya, and Rajiv Ranjan. 2021. Autodiagn: An auto- mated real-time diagnosis framework for big data systems.IEEE Trans. Comput. 71, 5 (2021), 1035–1048

2021
[8]

Wenqi Fan, Yujuan Ding, Liangbo Ning, Shijie Wang, Hengyun Li, Dawei Yin, Tat-Seng Chua, and Qing Li. 2024. A survey on rag meeting llms: Towards retrieval-augmented large language models. InProceedings of the 30th ACM SIGKDD conference on knowledge discovery and data mining. 6491–6501

2024
[9]

Google. 2024. Try Deep Research and our new experimental model in Gemini, your AI assistant. https://blog.google/products/gemini/google-gemini-deep- research/

2024
[10]

Daya Guo, Dejian Yang, Haowei Zhang, Junxiao Song, Peiyi Wang, Qihao Zhu, Runxin Xu, Ruoyu Zhang, Shirong Ma, Xiao Bi, et al. 2025. DeepSeek-R1 incen- tivizes reasoning in LLMs through reinforcement learning.Nature645, 8081 (2025), 633–638

2025
[11]

Nam Huynh and Beiyu Lin. 2025. Large language models for code generation: A comprehensive survey of challenges, techniques, evaluation, and applications. arXiv preprint arXiv:2503.01245(2025)

work page arXiv 2025
[12]

Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rock- täschel, et al. 2020. Retrieval-augmented generation for knowledge-intensive nlp tasks.Advances in neural information processing systems33 (2020), 9459–9474

2020
[13]

Aixin Liu, Aoxue Mei, Bangcai Lin, Bing Xue, Bingxuan Wang, Bingzheng Xu, Bochao Wu, Bowei Zhang, Chaofan Lin, Chen Dong, et al . 2025. Deepseek- v3. 2: Pushing the frontier of open large language models.arXiv preprint arXiv:2512.02556(2025)

work page internal anchor Pith review arXiv 2025
[14]

Xinyuan Liu, Devki Nandan Jha, Yinhao Li, Mutaz Barika, Umit Demirbaga, and Rajiv Ranjan. 2024. AUTOMATE: Automatic anomaly detection and root cause analysis framework for hadoop. In2024 International Conference on Meta Computing (ICMC). IEEE, 213–222

2024
[15]

Siyang Lu, Xiang Wei, Bingbing Rao, Byungchul Tak, Long Wang, and Liqiang Wang. 2019. LADRA: Log-based abnormal task detection and root-cause analysis in big data processing with Spark.Future Generation Computer Systems95 (2019), 392–403

2019
[16]

OpenAI. 2025. Introducing Deep Research. https://openai.com/zh-Hans- CN/index/introducing-deep-research/

2025
[17]

Changhua Pei, Zexin Wang, Fengrui Liu, Zeyan Li, Yang Liu, Xiao He, Rong Kang, Tieying Zhang, Jianjun Chen, Jianhui Li, et al . 2025. Flow-of-Action: SOP Enhanced LLM-Based Multi-Agent System for Root Cause Analysis. In Companion Proceedings of the ACM on Web Conference 2025. 422–431

2025
[18]

Ananya Rahaman, Anny Zheng, Mostafa Milani, Fei Chiang, and Rachel Pottinger
[19]

Evaluating SQL understanding in large language models.arXiv preprint arXiv:2410.10680(2024)

work page arXiv 2024
[20]

Rui Ren. 2025. The Multi-Agent Fault Localization System Based on Monte Carlo Tree Search Approach.arXiv preprint arXiv:2507.22800(2025)

work page arXiv 2025
[21]

Devjeet Roy, Xuchao Zhang, Rashi Bhave, Chetan Bansal, Pedro Las-Casas, Rodrigo Fonseca, and Saravan Rajmohan. 2024. Exploring llm-based agents for root cause analysis. InCompanion proceedings of the 32nd ACM international conference on the foundations of software engineering. 208–219

2024
[22]

Mohammad Shahnawaz and Manish Kumar. 2025. A comprehensive survey on big data analytics: Characteristics, tools and techniques.Comput. Surveys57, 8 (2025), 1–33

2025
[23]

Zhihong Shao, Yeyun Gong, Yelong Shen, Minlie Huang, Nan Duan, and Weizhu Chen. 2023. Enhancing retrieval-augmented large language models with iterative retrieval-generation synergy. InFindings of the Association for Computational Linguistics: EMNLP 2023. 9248–9274

2023
[24]

Aditi Singh, Abul Ehtesham, Saket Kumar, and Tala Talaei Khoei. 2025. Agen- tic retrieval-augmented generation: A survey on agentic rag.arXiv preprint arXiv:2501.09136(2025)

work page internal anchor Pith review arXiv 2025
[25]

Vikramank Singh, Kapil Eknath Vaidya, Vinayshekhar Bannihatti Kumar, Sopan Khosla, Murali Narayanaswamy, Rashmi Gangadharaiah, and Tim Kraska. 2024. Panda: Performance debugging for databases using LLM agents.(2024). (2024)

2024
[26]

Zefan Wang, Zichuan Liu, Yingying Zhang, Aoxiao Zhong, Jihong Wang, Fengbin Yin, Lunting Fan, Lingfei Wu, and Qingsong Wen. 2024. Rcagent: Cloud root cause analysis by autonomous agents with tool-augmented large language models. InProceedings of the 33rd ACM International Conference on Information and Knowledge Management. 4966–4974

2024
[27]

Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoc V Le, Denny Zhou, et al. 2022. Chain-of-thought prompting elicits reason- ing in large language models.Advances in neural information processing systems 35 (2022), 24824–24837

2022
[28]

Jialong Wu, Baixuan Li, Runnan Fang, Wenbiao Yin, Liwen Zhang, Zhengwei Tao, Dingchu Zhang, Zekun Xi, Gang Fu, Yong Jiang, et al. 2025. Webdancer: Towards autonomous information seeking agency.arXiv preprint arXiv:2505.22648(2025)

work page arXiv 2025
[29]

Yunjia Xi, Jianghao Lin, Yongzhao Xiao, Zheli Zhou, Rong Shan, Te Gao, Jiachen Zhu, Weiwen Liu, Yong Yu, and Weinan Zhang. 2025. A survey of llm-based deep search agents: Paradigm, optimization, evaluation, and challenges.arXiv preprint arXiv:2508.05668(2025)

work page arXiv 2025
[30]

An Yang, Anfeng Li, Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chang Gao, Chengen Huang, Chenxu Lv, et al. 2025. Qwen3 technical report.arXiv preprint arXiv:2505.09388(2025)

work page internal anchor Pith review Pith/arXiv arXiv 2025
[31]

Wei Zhang, Hongcheng Guo, Jian Yang, Zhoujin Tian, Yi Zhang, Yan Chaoran, Zhoujun Li, Tongliang Li, Xu Shi, Liangfan Zheng, et al. 2024. mABC: multi-Agent Blockchain-Inspired Collaboration for root cause analysis in micro-services architecture. InFindings of the Association for Computational Linguistics: EMNLP

2024
[32]

Xuchao Zhang, Supriyo Ghosh, Chetan Bansal, Rujia Wang, Minghua Ma, Yu Kang, and Saravan Rajmohan. 2024. Automated root causing of cloud incidents using in-context learning with GPT-4. InCompanion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering. 266–277

2024
[33]

Honggang Zhou, Yunchun Li, Hailong Yang, Jie Jia, and Wei Li. 2018. Bigroots: An effective approach for root-cause analysis of stragglers in big data system. IEEE Access6 (2018), 41966–41977

2018
[34]

Wei Zhou, Ji Sun, Xuanhe Zhou, Guoliang Li, Luyang Liu, Hao Wu, and Tianyuan Wang. 2025. GaussMaster: An LLM-based Database Copilot System.arXiv preprint arXiv:2506.23322(2025)

work page arXiv 2025
[35]

Xuanhe Zhou, Guoliang Li, Zhaoyan Sun, Zhiyuan Liu, Weize Chen, Jianming Wu, Jiesi Liu, Ruohang Feng, and Guoyang Zeng. 2023. D-bot: Database diagnosis system using large language models.arXiv preprint arXiv:2312.01454(2023)

work page arXiv 2023
[36]

Xuanhe Zhou, Xinyang Zhao, and Guoliang Li. 2024. Llm-enhanced data man- agement.arXiv preprint arXiv:2402.02643(2024). 13

work page arXiv 2024