新闻类的网站如何做优化,广告标识标牌制作公司,辽宁省建设厅网站,云南建设厅网站备案厂家引言#xff1a;
在人工智能技术飞速发展的背景下#xff0c;DeepSeek 作为一款基于混合专家模型#xff08;MoE#xff09;和强化学习技术的大语言模型#xff0c;正在重塑传统数据库管理#xff08;DBA#xff09;的工作模式。通过结合其强大的自然语言处理能力、推理…引言
在人工智能技术飞速发展的背景下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. RAGDBA的好帮手
在DBA领域AIGC支持下的知识库已经被证明是十分有效的辅助手段了大模型结合RAG是目前比较流行的解决方案。RAG 是检索增强生成Retrieval-augmented generation的缩写是一种利用大语言模型和检索系统来生成文本的方法。RAG 可以从大规模的文本数据库中检索相关的文档然后将它们作为上下文信息提供给 LLM从而提高 LLM 的生成质量和准确性。RAG 可以应用于多种任务如问答、摘要、对话等。本节是 OceanBase 高级技术专家-蔡飞志在obdiag SIG AI SIG周上分享的内容扩展。
2.2.1. 什么是RAG
RAGRetrieval 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 系统流程已结束。 下面是OB 智能问答小助手实际使用的图左侧是钉钉群里的效果右侧是OceanBase 社区论坛的使用效果。 3. DBA敢问路在何方
当下AI技术已逐步渗透数据库领域从自动化运维到智能诊断调优DBA的职能边界正经历前所未有的重构。面对AI的冲击DBA群体既感受到效率提升的机遇也面临职业价值被弱化的隐忧。 咱们开篇从deepseek来结束也从deepseek走以下是deepseek的回答我觉得写的比我全面大家可以看一看。 4. 写在最后
AI时代DBA不会消失但固守传统技能者必将被淘汰。未来的DBA将是“六边形战士”既懂数据库内核原理又能驾驭AI工具既能设计高可用架构又深谙业务需求。唯有以技术为舟、以业务为舵方能在数据洪流中开辟新航路。
