浅谈 DeepSeek 对 DBA 的影响

引言：

在人工智能技术飞速发展的背景下，DeepSeek 作为一款基于混合专家模型（MoE）和强化学习技术的大语言模型，正在重塑传统数据库管理（DBA）的工作模式。通过结合其强大的自然语言处理能力、推理优化技术及多模态交互特性，DeepSeek 为 DBA 提供了从智能诊断到自动化运维的全新解决方案。本文基于 OceanBase 社区2025.02.21 召开的obdiag SIG + AI SIG 联合周会上探讨的内容展开，将从技术特性、实践案例及未来展望等方面，探讨 DeepSeek 对 DBA 工作的革新意义。

1. DeepSeek--AI圈的魔童闹海

春节期间爆火的两个新闻：一个是国产全新开源大模型deepseek，引发全球开发者热议，甚至引发资本市场的震动，英伟达股价因其AI技术创新而暴跌 17%，单日蒸发 6000 亿美元市值；另一个是国产动画IP《哪吒》系列新作票房口碑双丰收，再次掀起国潮文化热潮。两个看似不相干的领域，却在同一时间点成为现象级话题。

我们看看DeepSeek，为何一款AI产品能掀起如此话题风暴？多数使用者或许说不清它的具体创新点，但通过自身的使用与媒介的传播，感受到其推理能力的强大。

DeepSeek模型已经对标国内Qwen、海外Llama、GPT 4o，从公布的榜单评测上看：DeepSeek-V3 在开源模型中位列榜首，与世界上最先进的闭源模型不分伯仲。

上面的图展示的是技术侧deepseek所做的创新与优化，国内外众多AI领域专家对DeepSeek的技术创新给予高度评价，认为其在某些方面做出了自主创新，为AI发展提供了新的思路。同时，当下很多国内公司与政要机构纷纷本地化部署了DeepSeek，这也从侧面印证了其技术的实用性和可靠性。总结下来DeepSeek的流行主要体现在以下几个方面：

推理能力：DeepSeek通过强化学习等技术，显著提升了模型的推理能力。例如，在数学和编程问题上，DeepSeek能够生成高质量的答案，而不仅仅是简单的重复或错误。
成本效益：与传统模型相比，DeepSeek在训练和推理成本上具有明显优势。通过优化训练方式和使用更高效的硬件，DeepSeek能够在较低的成本下达到与大型模型相当的性能。
开源和共享：DeepSeek选择完全开放代码，允许免费商用，这使得更多的开发者和研究机构能够利用其成果，加速了AI技术的发展和应用。
技术先进性：DeepSeek采用了先进的技术如DualPipe技术和FP8混合精度，这些技术不仅提高了计算效率，还降低了能耗，使得DeepSeek在性能上有了显著的提升。

在硅谷，类似DeepSeek这样的AI创新并不少有，只是这次是一家中国公司做出了这个动作，相比传统的‘美国创新、中国应用’的模式显得格外的让人兴奋。有人说这是国运来了，我理解所谓"国运来了"，实质是时代给予创新者的历史机遇。DeepSeek与哪吒的爆发，恰逢中国从"世界工厂"向"创新策源地"转型的关键节点——14亿人口大市场提供场景试验田，完整工业体系支撑技术迭代，文化复兴运动创造内容需求，这些要素共同构成了培育创新物种的独特生态。

2. AI4DBA

2.1. 如何解决数据库智能运维的“最后一公里”

本节内容大部分引用 OceanBase 社区obdiag SIG Maintainer / 南京基石数据责任有限公司CTO 徐戟(网名：白鳝)在obdiag SIG + AI SIG周上分享的观点。想观看完整会议视频的请添加微信：OBCE888，回复暗号：视频即可获得。

在DeepSeek问世之前，AI赋能数据库智能运维面临的核心挑战在于"最后一公里"的落地鸿沟。传统AI系统虽能生成诊断报告，但其输出结果往往呈现为专业术语堆砌的技术指标（如锁争用率、缓存命中率等），传统AI 产生的分析结论，就只能够给人提供参考，甚至是只能给专家提供参考，因为小白可能还没有足够的数据库的知识，对于结果可能都看不懂。但deepseek的出现，很大程度上让最后一公里的解决变得可操作起来了。

构建数据库智能运维(DBAIOPS)有三个基础，分别是“高精度的基础数据”、“高质量运维知识”以及“强大的推理模型”，三者相辅相成。最开始，我们期望不需要精确的数据，不需要专家知识，就通过模型算法去解决数据库运维这个高阶问题。这个后来被证明是不行的，高精度的基础数据肯定是必要的，这块传统方法就可以实现，比如我们采集的监控数据、告警数据等等。另一方面高质量的运维知识也是必须的，知识覆盖面很广泛，官方的文档、博客、各种书籍等，这些可以提供高质量的知识。最后强大的推理模型也是必不可少的，而 deepseek 能很好的补齐能力。

会上白鳝分享了他基于deepseek-r1推理能力所做的数据库诊断产品的设计图。有了上面的DBAIOPS三大基础，白鳝认为高质量的运维经验是提升AIOPS能力的关键。他指出：很多做AI算法的专家都希望能够通过让大语言模型去学习知识，从而自己总结出经验,再使用这些经验去做诊断分析。哪怕是一个人类想要简单的通过知识学习，不经过任何实践就成为一个高手都十分困难。依靠算法专家和大语言模型的底座能力，给他喂进去一大堆相关知识，就能让他自己总结出经验，想做到这一点并不容易。最起码你也得给他喂进去一大堆的故障案例，通过这些案例他才能总结出相关的经验来。而标注这些案例也需要运维专家的参与，仅仅依靠大语言模型的专家是完全不够的。如果把oracle公司的mos网站的数据喂给他,是不是就无敌了？实际上来说也不见得，因为准确的推理需要精准的数据和背景知识，其实现在mos网站也是有大模型加持的，它并没有表现出你所期望的能力。哪怕你给他足够的语料也无法解决精神定位问题所需要的精准的背景知识，更何况如果没有数据的支撑，这些东西也只能是一个通用的问答而已，无法根据每个现场环境的真实情况去做更为精准的判断。在现阶段，deepseek可以为我们的DBA提供助力。通过与他对话可以节约大量的文档搜索,案例分析的工作,但是DBA还需要有强大的判断能力,否则可能无法正确的使用DeepSeek给你的帮助。

2.2. RAG：DBA的好帮手

在DBA领域，AIGC支持下的知识库已经被证明是十分有效的辅助手段了，大模型结合RAG是目前比较流行的解决方案。RAG 是检索增强生成（Retrieval-augmented generation）的缩写，是一种利用大语言模型和检索系统来生成文本的方法。RAG 可以从大规模的文本数据库中检索相关的文档，然后将它们作为上下文信息提供给 LLM，从而提高 LLM 的生成质量和准确性。RAG 可以应用于多种任务，如问答、摘要、对话等。本节是 OceanBase 高级技术专家-蔡飞志在obdiag SIG + AI SIG周上分享的内容扩展。

2.2.1. 什么是RAG

RAG（Retrieval Augmented Generation, 检索增强生成）是一种技术框架，其核心在于当 LLM 面对解答问题或创作文本任务时，首先会在大规模文档库中搜索并筛选出与任务紧密相关的素材，继而依据这些素材精准指导后续的回答生成或文本构造过程，旨在通过此种方式提升模型输出的准确性和可靠性。RAG方法赋予了开发者无需为每个特定任务重新训练大型模型的能力，仅需连接外部知识库，即可为模型注入额外的信息资源，从而显著提升其回答的精确度。这一方法尤其适用于那些高度依赖专业知识的任务。

以下是 RAG 模型的主要优势：

可扩展性：减小模型规模及训练开销，同时简化知识库的扩容更新过程。
准确性：通过引用信息源，用户能够核查答案的可信度，进而增强对模型输出结果的信任感。
可控性：支持知识内容的灵活更新与个性化配置。
可解释性：展示模型预测所依赖的检索条目，增进理解与透明度。
多功能性：RAG 能够适应多种应用场景的微调与定制，涵盖问答、文本摘要、对话系统等领域。
时效性：运用检索技术捕捉最新信息动态，确保回答既即时又准确，相比仅依赖固有训练数据的语言模型具有明显优势。
领域定制性：通过对接特定行业或领域的文本数据集，RAG 能够提供针对性的专业知识支持。
安全性：通过在数据库层面实施角色划分与安全管控，RAG 有效强化了对数据使用的管理，相较于微调模型在数据权限管理上的潜在模糊性，展现出更高的安全性。

虽然现在大语言模型发展迅速，研发大模型的企业也快速涌现，但囿于目前语言模型的技术方案架构，训练模型、更新和发布模型参数需要耗费较长的时间，且训练数据在开启训练之后便不可再继续增补。而现实世界的信息熵增无时无刻不在持续，要让大语言模型在“昏迷”几个月之后还能自发地掌握当下最新的信息显然是不现实的。而且用于训练的数据通常是公开可访问的，一旦遇到到训练时没有输入的知识，参数再大的语言模型也只能根据学习到的知识来“推理”，这也是我们使用大语言模型产品时发现它们可能会胡说八道的原因。

RAG 就是为了让大语言模型能够获取时下更新的、领域更专注的知识来生成所需文本而诞生的技术方案：接收到用户输入后，RAG 系统根据用户输入到知识库中进行知识检索，将检索到的知识结合用户的输入一并提交给大语言模型进行回答的生成。它类似于人类遇到问题时在搜索引擎查询问题原因、浏览网站资料、推理归纳出解决方案的过程，让大语言模型静态的知识库得到补充，打破时空的限制，是一种训练后的“再学习”过程。开发者借助 RAG 能够为各行各业各种任务实现领域专精的“智能体” Agent 以辅助人类完成具体的工作。

2.2.2. OB 智能问答小助手来啦！

OceanBase 社区为了更好的支持用户对 OB 数据库进行诊断，做了很多的努力。比如敏捷诊断工具obdiag的推出就是为了将诊断经验代码化，让用户能够快速的进行集群的巡检、根因分析以及一键收集等。但如上面2.1章节所说的，obdiag 工具和使用者也存在诸如用户怎么知道什么场景需要什么诊断命令、诊断报告如何解读等“最后一公里”的问题未能解决。

为了解决这最后一公里，OceanBase 社区探索了一条RAG + obdiag的路子，下面详细讲讲实现细节。

大家都知道数据是 LLM 的基础，也是 RAG 系统的基础。对于 RAG 系统而言，数据指的是需要进行检索的知识的集合，是需要用来增强 LLM 文本生成效果的语料库。"Quality In, Quality Out"，知识库本身的质量决定了能够产生的答案的质量。OceanBase 有众多开源项目，其中文档开源的组件包括但不限于 OceanBase、OCP、OMS、ODC、OBD、ODP、ob-operator 等。其中大部分文档都是 markdown 格式的文本文件，对于构建 RAG 知识库而言是非常好的资料。

OceanBase 使用开源文档构建 RAG 应用的业务场景之一是负责开源社区论坛问答帖子的初次应答，能够帮助值班同学尽可能地解答用户遇到的特性问题、针对诊断问题指导用户获取系统日志并且提供到问答帖子中。

实际上，我们在接收到论坛用户的提问时会先将问题进行分类，分为闲聊、特性问题和诊断问题，其中：

闲聊是指与 OceanBase 无关的问题，例如明天天气如何？如何使用 Python 实现快速排序算法？。这类问题我们直接不予回复，直接终止流程。
特性问题是指与 OceanBase 及其周边组件的特性有关的疑问，往往是抽象、宏观、整体的描述，例如oceanbase 合并到底是集群级别还是租户级别？oceanbase分区均衡策略的优先级顺序是什么？。回答特性问题属于典型的 RAG 场景，我们会将特性问题进行书面润色和改写后提交给 RAG 流程进行文档检索、检索重排和 LLM 答复流程，最终产生具有参考文档链接的答复。
诊断问题是指与 OceanBase 及其周边组件的问题排查有关的问题，往往是具体、微观、局部的描述，例如OCP 告警推送失败【CancellationException】租户备份失败: ob 4.0 环境下，调用租户下备份恢复菜单执行租户级别备份，失败，报错代码2024-08-13 10:40:38.370 INFO 1057922 --- [p...。诊断问题的处理比特性问题复杂很多，无论对于 LLM 还是对于人类来说都是如此，诊断问题复杂在错误域极大，诊断链路极长且没有足够丰富的诊断知识库可供参考，仅凭开源文档库的文档检索是无法完全解决用户问题的。在诊断问题的处理上，我们借助 obdiag 敏捷诊断工具的部分能力，为用户提供日志采集、根因分析的指引和进一步诊断方向的建议。

对于诊断问题，我们采取至少三轮对话的策略：

第一轮对话：用户初次提问时，我们将用户问题改写后交给 OBDiag Agent，该智能体结合 obdiag 的日志采集和根因分析场景给出相应的命令建议，建议用户采集日志上传到论坛中，如果可能也使用根因分析尝试排查问题。除了提出建议的 obdiag 命令之外，还会提出 4 个左右的问题，让用户补充信息；
中间轮次对话：中间轮次对话由 Question Agent 负责答复，该智能体负责根据历史消息判断问题是否可解，如果判断为可以解决，则交给 RAG Agent 进行答复；如果判断为不可解决，则向用户追问 4-5 个问题进一步获取信息；
最终对话：最终轮次的对话由 RAG Agent 完成，与特性问题一致。先用历史消息对用户的问题进行向量检索，查询到相关的文档之后再综合历史对话让 LLM 生成回答，尝试解决用户的问题，并不再响应后续的提问。最终对话生成后会追加（小助手答复已经结束，如果未能解决您的问题，请您继续追问并等待其他同学的答复，谢谢！）告知用户 RAG 系统流程已结束。