淺談 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 系統流程已結束。