DeepSeek 邂逅 OceanBase 数据库：大模型如何重塑 DBA 的工作模式？

原创 OceanBase数据库 2025-03-14

在人工智能技术加速迭代的浪潮下，DeepSeek 凭借其创新的混合专家模型（MoE）和强化学习技术，正在重塑 DBA 的工作模式。

本文聚焦 DeepSeek 的技术创新，结合 OceanBase 在社区智能问答小助手场景中的实践，深入剖析 DeepSeek 在数据库智能运维、RAG 技术实践等方面的应用，以及其为 DBA 职业发展带来的机遇与挑战，全方位展现 DeepSeek 如何引领数据库管理迈向智能化新纪元。

本文源自 obdiag SIG 和 AI SIG 联合投稿。

一、AI破局者：Deepseek 带来突破性创新

2025 年初，国产开源大模型 DeepSeek 横空出世，掀起一场技术与资本的双重风暴，引发全球开发者热议，一时间成为现象级话题。

为何一款 AI 产品能掀起全球范围内的话题风暴？DeepSeek 凭借 MoE 架构与强化学习的深度耦合，以 1/3 的推理成本实现 GPT-4 级别的性能表现。很多人或许不清楚其底层的技术逻辑，但也在使用中感受到其强大的推理能力。国内很多公司、高校与机构纷纷本地化部署 DeepSeek，更加印证了 DeepSeek 的技术实用性和可靠性。

国内外众多 AI 领域专家对 DeepSeek 给予了高度评价，认为其技术创新为 AI 发展提供了新的思路。DeepSeek 的技术突围主要体现在以下几个方面：

🚩 推理能力的突破：DeepSeek 通过强化学习等技术，显著提升了模型的推理能力。在数学证明和编程问题等复杂场景中，DeepSeek 能够生成高质量的答案，错误率较 Llama3 降低 62%。

🚩 成本效益的优势：与传统模型相比，DeepSeek 采用了先进的技术如 DualPipe 技术和 FP8 混合精度，不仅提高了计算效率，还降低了能耗，使得 DeepSeek 能够在较低的成本下达到与大型模型相当的性能。

🚩 开源生态的战略：DeepSeek 提供完整的工具链支持与商用授权，让更多的开发者和研究机构能够共享其技术成果，加速了 AI 技术的发展和应用。

这种"技术突破-成本优化-生态构建"的三位一体创新，标志着中国 AI 模型从跟随者向规则制定者的角色转变。

二、智能运维革命：Al 重构数据库管理

数据库运维如何突破最后一公里？

本节内容引用自 OceanBase 社区 obdiag SIG Maintainer / 南京基石数据责任有限公司 CTO 徐戟(网名：白鳝)在 obdiag SIG + AI SIG 周会上分享的观点。

在 DeepSeek 问世之前，AI 赋能数据库智能运维的核心挑战在于落地的"最后一公里"。传统 AI 系统虽能生成诊断报告，但其输出结果往往呈现为专业术语堆砌的技术指标（如锁争用率、缓存命中率等），其分析结论只能作为参考。DeepSeek 的出现，让数据库运维管理中诊断决策这一"最后一公里"问题有了解决方案。

如上图所示，构建数据库智能运维 (DBAIOPS) 需要三个关键基础，即“高精度的基础数据”、“高质量运维知识”以及“强大的推理模型”，三者相辅相成，缺一不可。

白鳝及其团队早期期望通过模型算法解决数据库运维的问题，然而实践证明这并不可行。利用传统方法采集监控数据、告警数据等可以完成高精度的基础数据，官方的文档、博客、书籍等可以提供高质量的运维知识，而强大的推理模型却成为方案瓶颈。DeepSeek 的出现弥补了“强大的推理模型”这一能力的短板。

上图是白鳝基于 DeepSeek-R1 推理能力所做的数据库诊断产品设计图。在 DBAIOPS 三大基础上，白鳝认为高质量的运维经验是提升 AIOPS 能力的关键。

白鳝认为，许多 AI 算法专家试图让大语言模型通过学习知识自己总结经验，进而做诊断分析，但这并非易事。至少要为大模型提供大量的故障案例，它才有可能从中归纳出相关经验。而标注这些案例需要运维专家和大语言模型专家共同参与，因为准确的推理依赖精准的数据和背景知识，否则只能进行通用问答，无法精准定位问题，无法依据现场实际情况作出更精确的判断。

现阶段，DeepSeek 能够为 DBA 提供有力支持，通过与它对话，可大幅节省文档搜索和案例分析的时间。但 DBA 仍需具备强大的判断能力，否则可能无法充分利用 DeepSeek 为运维工作提供帮助。

RAG 技术实践：构建专属数据库知识引擎

本节内容引用自 OceanBase 高级技术专家蔡飞志在 obdiag SIG + AI SIG 周会上分享的观点。

1、基于 RAG 的数据库运维知识库

在数字化转型浪潮中，数据库运维场景正面临着海量日志解析、故障快速定位和知识动态更新的三重挑战。基于 RAG 的智能运维知识库通过"检索增强生成"技术，有效融合了大语言模型的推理能力与专业数据库的精准知识，为 DBA 构建了"智能驾驶"式的决策支持系统。

RAG 即检索增强生成（Retrieval-augmented generation），是一种利用大语言模型和检索系统生成文本的方法。它可以从大规模的文本数据库中检索相关文档，并将其作为上下文信息提供给 LLM，从而提高 LLM 生成内容的质量和准确性。RAG 可以应用于问答、摘要、对话等多种任务。

RAG 的核心在于当 LLM 面对解答问题或创作文本任务时，首先在大规模文档库中搜索并筛选出与任务紧密相关的素材，然后依据这些素材精准指导后续的回答生成或文本构建过程，提升模型输出的准确性和可靠性。

RAG 赋予了开发者无需为每个特定任务重新训练大型模型的能力，只需连接外部知识库，就能为模型注入额外信息资源，提升其回答的精确度。该方法尤其适用于高度依赖专业知识的任务。

RAG 模型具有以下优势：

👍 可扩展性强：可减少模型规模及训练开销，简化知识库的扩容与更新流程。

👍 准确性高：通过引用信息源，用户可核查答案的可信度，增强对模型输出结果的信任。

👍 可控性好：支持知识内容的灵活更新与个性化配置。

👍 可解释性高：展示模型预测所依赖的检索条目，提高理解与透明度。

👍 多功能应用：RAG 可适应问答、文本摘要、对话系统等多种应用场景的微调与定制。

👍 时效性突出：运用检索技术捕捉最新信息，确保回答既即时又准确，相比仅依赖固有训练数据的语言模型优势明显。

👍 领域定制灵活：通过对接特定行业或领域的文本数据集，RAG 能够提供针对性的专业知识支持。

👍 安全性高：通过在数据库层面实施角色划分与安全管控，RAG 有效强化了对数据使用的管理，与微调模型在数据权限管理上的潜在模糊性相比，安全性更高。

囿于目前语言模型的技术方案架构，模型训练、更新和发布参数耗时较长，且训练数据一旦确定，开启训练便难以继续增补。而现实世界的信息熵增时刻继续，期望大语言模型在长时间“昏迷”后仍能自动掌握最新信息显然不切实际。

此外，用于训练的数据通常是公开获取的，一旦遇到训练时没有输入的知识，即使参数再大的语言模型，也只能凭借已学知识进行“推理”，这也正是大语言模型产品有时会“胡言乱语”的原因。

RAG 正是为解决大语言模型获取最新、更专业领域的知识以生成所需文本而诞生的技术方案。接收到用户输入后，RAG 系统根据用户的输入，在知识库中进行检索，并将检索到的知识结合用户的输入一并提交给大语言模型用于生成回答。这类似于我们在遇到问题时，在搜索引擎上查找资料、分析归纳解决方案的过程。

RAG 为大语言模型静态的知识库注入新内容，打破时间和空间限制，实现训练后的 “再学习”。开发者借助 RAG 能够为各行各业的不同任务打造领域专精的 “智能体” Agent，辅助人类完成具体工作。

2、RAG 技术实践：帮助 DBA 解决客户问题

OceanBase 社区为了更好的支持用户对 OceanBase 数据库进行诊断，推出敏捷诊断工具 obdiag ，将诊断经验代码化，让用户能够快速进行集群巡检、根因分析以及一键数据收集等工作。然而，如前文 2.1 章节所述，obdiag 工具和使用者之间存在诸如用户如何知晓在何种场景下使用何种诊断命令、如何解读诊断报告等“最后一公里”的问题。

为了攻克这一难题，OceanBase 社区探索出一条 RAG + obdiag 的创新路径。

数据是 LLM 的基础，也是 RAG 系统的基石。对 RAG 系统而言，数据指的是需要用于检索的知识的集合，是用于增强 LLM 文本生成效果的语料库。正所谓 “输入决定输出”，知识库本身的质量直接决定了生成答案的质量。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 系统流程结束。