导读 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 推荐相关学习资料和故障排查方案。
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
