导读 ChatDBA 是由上海爱可生开发的一款数据库运维领域的智能辅助系统，通过对话交互，提供数据库故障诊断、专业知识学习、SQL 生成和优化等功能，旨在提升 DBA 工作效率。本文将介绍 ChatDBA 是如何利用大语言模型实现其数据库故障诊断智能助手功能的。
1. 背景介绍
2. ChatDBA 架构
3. 挑战与解决思路
4. 未来展望
分享嘉宾｜李剑楠 上海爱可生信息技术股份有限公司 高级研发工程师
编辑整理｜程思琪
内容校对｜李瑶
出品社区｜DataFun
背景介绍
随着大模型的兴起，从底层硬件、基础设施，到中间件，再到上层应用，出现了很多优秀的基于大模型的产品。![]()
大模型在数据库领域的应用也逐渐受到关注，常见的应用场景包括 BI 数据分析、NL2SQL 等，大模型的代码生成能力也为 NL2SQL 任务带来了新的可能性。此外，DBA 越来越多地使用大模型进行日常工作，例如生成排查建议、检索数据库参数或名词含义等。因此，我们决定研发 ChatDBA 这样一个产品，帮助 DBA 提高其日常工作效率。![]()
早期开发的 ChatDBA 是一个基于 RAG
(Retrieval-Augmented Generation) 的项目，利用公司内部的历史工单数据进行了清洗、切片等工作，并加入了文本溯源这样的辅助功能为 DBA 提供问答服务。它可以实现基本问答，但对 DBA 的日常工作实际价值不大。总结来看，初期版本存在以下问题：- 输出内容泛泛，逻辑性不强：大模型生成的回答往往过于基础，缺乏实际指导意义。
- 故障诊断场景复杂：难以在多轮对话中保证排查逻辑的连贯性。
- 模型倾向问题：大模型倾向基于已有的全局信息进行推测，这与DBA 的排查思路存在差异，DBA 往往是基于现象多次检索，逐渐排查定位问题。
![]()
基于上述思考，所以我们重新设计了 ChatDBA 这一产品。它仍然是一个经典的 RAG 项目，我们希望它通过对话交互的方式，提供数据库故障诊断、数据库专业知识学习、SQL 生成、SQL 优化等功能。技术架构
![]()
升级后的 ChatDBA 仍然基于 RAG 架构，主要包含以下组件：- 环境输入处理：处理所有输入信息，并进行文本向量化、三元组抽取等操作，为模型提供输入。
- 模型规划：利用决策树、思维链、反思行动等结构，保证模型处理问题的逻辑性和连贯性。
- 工具使用：调用检索 API、监控工具接口等，增强生成内容的准确性和可靠性。
挑战与解决思路
1. 故障排查逻辑树
为了解决输出内容泛泛和逻辑性不强的问题，ChatDBA 引入了故障诊断树结构，保证多轮对话的排查逻辑。![]()
如上图中的样例，mysql 频繁报错，我们会将其分为四类场景，每类场景对应不同的排查方法。多轮对话中，随着更多信息的输入，一些排查节点可能会发生改变，可能会缩小排查范围，或引入新的故障原因，这些都会实时更新到排查逻辑树中，但框架主体是不变的。这种方法也可以提升问题解决的效率，一些 DBA 看到这样一个完整的故障诊断树后就可以开始着手解决问题了。![]()
这里的挑战在于如何生成准确的、高效的、覆盖可能原因全面的故障诊断树。上图是一个简单的示例，根据参考资料生成 Error2002 的故障排查树。假设刚好有一张工单总结是关于 Error2002 的处理方法，文章分为三个章节，相应地我们会将文章切成三个 chunk。其中第一和第三两个章节描述的是故障现象和故障总结，对生成故障排查树是没有帮助的，所以检索时并不希望召回这两个 chunk，这是检索需要解决的一个问题。而真实场景中，问题可能会更加复杂，文章可能并没有划分明显的章节，或者第二部分也许很长，就必须切开，这样就可能造成上下文割裂。很多工作考虑到了这些问题，针对 RAG 设计了信息检索的方法。接下来将介绍其中一些主流的方法。2. 信息检索
![]()
![]()
查询重写 查询扩充
![]()
![]()
![]()
3. 文档处理
在实践中为了提升整体效率，需同时考虑检索算法加文档处理。![]()
前文中提到按照章节对文档进行划分可能存在的问题，通常有两种方法来解决这一问题，一是以摘要的形式增强上下文文本块之间的关联，避免信息割裂。另一种方法，针对原始文档生成 QA 对，在检索时使用用户的输入结合 QA 对进行检索。在 ChatDBA 里面，我们融合了查询重写+文档格式化+多路召回的策略。![]()
格式化：将工单内容格式化为故障现象、原因、排查方法和解决方案四部分。
查询重写：结合对话历史，重写查询为梳理故障现象的表达，在故障现象库中进行向量检索，从召回的工单中提取排查方法和解决方案，输送到 LLM 中作为 prompt 的一部分。为了提升模型回答的效果，我们采用了分治的思想，让模型同步分析多个文档中，每篇工单对当前问题起到了什么帮助，如果有帮助，就形成当前树结构的一个补丁，最后通过合并补丁，实现完整的排查逻辑树的生成。
在确定上述策略之后，我们制定了一套数据预处理流程。![]()
为了拉通内部工单系统，自动化补充知识库，我们制定的流程如上图所示。- 首先是对工单内容做清洗，因为在一个工单中，有很多内容是与故障本身无关的，对于模型来说，就是噪音数据。
实践中重写后的文档对比原始数据，会丢失一些关键的信息或生成一些不合适的总结性的内容，所以这里我们利用模型来做了一个评分。我们把评分划分成多个维度，分别为是否删减了步骤、是否生成了原始文档中没有的内容、是否包含格式要求的多个部分等，如果分数低于阈值，就需要重新走这套流程去进行下一步的重写。4. 记忆问题
回到最初提出的问题，我们已经通过设计文档处理和 LLM 处理文档流程生成故障排查树，再利用故障排查树串联多轮对话来保障全局的回答逻辑性。接下来探讨多轮交互中关于记忆的问题。![]()
随着对话轮次增加，对话历史信息变长，模型难以处理过长输入，会导致重点信息偏差。目前的解决方案是对对话历史进行整理和存储，仅保留最近几轮的完整问答，并通过实时检索补充关键信息。![]()
我们也研究了其他一些已有工作，如上图左侧，提出了采用自信息压缩来量化提示词。通过尝试，仍然会出现大量关键信息的丢失，导致用户体验不佳，因此目前在 ChatDBA 中仍然是使用长期对话摘要、短期对话保留的形式来实现记忆。5. 意图识别
多轮对话中，用户意图识别至关重要，不同意图可能对应不同的处理逻辑。![]()
解决方案是增加意图判断模块，通过预设意图模板和不同意图处理流程来实现意图识别。然而在多轮对话中，意图识别仍面临挑战。比如用户提问“mysql 严格模式是什么意思”，单看这一个问题，用户意图应该是知识学习或概念解释，但如果前几轮的问题是关于 mysql 报错，而错误可能是由于严格模式而产生的，那么这时的意图就不仅仅是知识学习了，而是希望对故障诊断有所帮助。我们采取的解决方案是多意图处理，将同一问题走多个处理分支，最后合并答案。6. 可观测性和评估
![]()
我们希望模型的输出是一个长对话，且逻辑性强，能够为 DBA 提供实际帮助，这就需要一条长流程，也就不可避免的会遇到长流水线的弊端，难以保证每个节点输出的稳定性。![]()
因此，需要构建一个可观测模型，评估框架和端到端输出。![]()
目前评估方法多依赖于大模型自身，存在不稳定性，未来可探索利用知识图谱进行可解释性评估。7. 时间成本
长流水线还会导致生成答案时间较长，影响用户体验。目前采用分步展示中间结果的策略，并期待未来出现更多 RAG 加速平台或方案。![]()
8. ChatDBA 的核心特性
![]()
![]()
![]()
未来展望
![]()
ChatDBA 作为数据库故障诊断智能助手，正处于不断发展和完善的过程中。未来，我们将重点关注以下方向：多模态处理：处理工单系统中的图片、日志等非文本信息，进一步提升 ChatDBA 的信息处理能力。
实时监控组件接入：支持自动化巡检、分析报表等功能，帮助 DBA 更好地掌握数据库运行状态。
知识图谱构建：构建更全面、更精准的数据库知识图谱，为 ChatDBA 提供更强大的知识支撑。
个性化推荐：根据用户历史行为和偏好，为 DBA 推荐相关学习资料和故障排查方案。
高级研发工程师，作为核心研发参与向量数据库和 RAG 项目的开发。在向量检索、RAG 相关方向发表论文两篇、专利五篇。
什么是 ChatDBA？
![]()
