讓天下沒有難做的開發和運維，DevOps終于有了專屬大模型，螞蟻和北大聯合發布
大語言模型在各類 NLP 下游任務上都取得了顯著進展，各種垂直領域大模型更是如雨后春筍般層出不窮。然而在 DevOps 領域，卻遲遲沒有相關大模型問世。為填補這方面的空白，螞蟻集團聯合北京大學發布了面向中文 DevOps 領域的首個開源大語言模型，即 DevOps-Model 。
該大模型旨在幫助開發人員在軟件開發和運維的整個生命周期中提高效率，最終目標是實現在 DevOps 流程中面臨任何問題時，都可以通過向 DevOps-Model 提問來獲取解決方案！
當前已經開源了 7B 和 14B 兩種規格的 Base 和 Chat 模型，同時還開源了對應的訓練代碼。
此外，為了有效評估 DevOps 領域大模型的性能，我們同時發布了首個面向 DevOps 領域的大模型評測基準 DevOps-Eval。該評測基準根據 DevOps 全流程進行劃分，包含計劃、編碼、構建、測試、發布、部署、運維和監控這 8 個類別，包含 4850 道選擇題。
此外，DevOps-Eval 還特別對運維 / 監控類別做了細分，添加日志解析、時序異常檢測、時序分類和根因分析等常見的 AIOps 任務。由于 DevOps-Eval 根據場景對評測樣本做了詳盡的細分，因此除了 DevOps 領域大模型，也方便對特定領域大模型進行評測，如 AIOps 領域等。
目前，第一期 DevOps 領域模型的評測榜單已發布，除 DevOps-Model 外，還包含 Qwen、Baichuan、Internlm 等開源大語言模型；同時，DevOps-Model 和 DevOps-Eval 相關論文也在撰寫中。歡迎相關從業者一起來進行共建、優化 DevOps 領域大模型和評測題目，我們也會定期更新模型、題庫和評測榜單。
DevOps-Model
- Github 地址：https://github.com/codefuse-ai/CodeFuse-DevOps-Model/tree/main
- 模型地址：
- 7B 版本
https://modelscope.cn/models/codefuse-ai/CodeFuse-DevOps-Model-7B-Base/summary
https://modelscope.cn/models/codefuse-ai/CodeFuse-DevOps-Model-7B-Chat/summary - 14B 版本
- https://modelscope.cn/models/codefuse-ai/CodeFuse-DevOps-Model-14B-Base/summaryhttps://modelscope.cn/models/codefuse-ai/CodeFuse-DevOps-Model-14B-Chat/summary
DevOps-Eval
- GitHub 地址：https://github.com/codefuse-ai/codefuse-devops-eval
- HuggingFace 地址：https://huggingface.co/datasets/codefuse-admin/devopseval-exam
DevOps-Model 的構建過程
基座模型
在基礎通用模型選擇上，我們考量了模型訓練數據大小、模型能力、模型參數量級后，最終選擇的是 Qwen-7B 和 Qwen-14B 作為通用模型。因為在公開的一些評測榜單上，Qwen 系列模型基本屬于同參數量級下效果最好的模型。
同時預訓練的語料有達到 3T token 的量級，可以給基座模型帶來更為全面的知識。
訓練框架
訓練框架上，我們采用的是基于開源訓練庫 LLaMA-Factory 加以改造來進行訓練，訓練時通過 flash-attention、ZeRO、混合精度等技術來保障高效訓練。
整體的 Qwen 模型架構是在 LLaMA 的結構上做了一些優化，其中包含采用了 RoPE 作為位置編碼的方式來提高模型的外推能力，采用了 RMSNorm 來提高訓練穩定性，采用 SwiGLU 激活函數來提高模型的表現。
訓練流程
根據查閱文獻可知，大部分領域模型都是在對話模型的基礎上，通過 SFT 微調來進行知識注入。而 SFT 微調所需要 QA 語料基本都來自于 ChatGPT 生成。然而，該方案可能存在 QA 語料無法完全覆蓋領域知識的情況。
因此，DevOps-Model 采用的是預訓練加訓 + SFT 微調的方案，如下圖所示。我們認為針對領域大模型，預訓練的加訓是必要的，因為其可以將領域內的一些知識在預訓練階段注入到大模型。
如果這些知識在通用大模型預訓練時沒有出現過，那會讓大模型學習到新的知識；如果出現過，就可以讓大模型進一步加深印象。第二步則是大模型對齊，目的是讓大模型可以根據問題來回答最合適的內容。
圖1. DevOps-Model 訓練流程
訓練數據
- 數據收集
模型的定位是中文 DevOps 領域大模型，因此需要收集與中文 DevOps 相關的預訓練數據和 QA 數據。
預訓練數據主要來自互聯網技術博客、技術文檔、技術書籍等，最終收集到了 50G+ 的預訓練語料數據；
針對 QA 數據，我們的目標是想讓模型不僅能夠對齊到通用的問答能力，針對 DevOps 領域也可以學會如何更好的回答問題，因此不但收集了通用領域的單輪和多輪對話數據，還針對 DevOps 領域，通過爬取和 ChatGPT 生成的方式產出了屬于 DevOps 領域的問答數據。最終我們精心篩選了約 200K 的 QA 數據進行 SFT 微調訓練，具體數據量如下表所示。
- 數據篩選
由于預訓練數據大部分是從互聯網上收集的數據，質量參差不齊，而大模型訓練中數據是最重要的一環，我們建立了如下圖所示的清洗 Pipeline，全面過濾收集到的數據。
圖2. DevOps-Model 預訓練數據清洗 Pipeline
1) 首先，由專家經驗和人工篩選，總結出來了一批文檔級別的 Heuristic 過濾規則，這一步主要用來過濾掉那些質量非常差的文檔；
2) 其次，即便是一篇質量稍差的文章，也有可能含有有價值的領域知識，也需要盡可能的進行收集。此處，我們對文章進行段落拆分，將文章拆分成一個個段落；
3) 然后，我們將拆分后的段落會再次通過步驟 1 進行過濾，便得到了一批經過規則過濾后的段落；
4) 再摘取其中 1000 個段落，由經驗豐富的專業開發人員打標，獲得高質量的打標數據；
5) 最后，根據打標后的結果來訓練了一個打分模型來針對段落進行質量的打分，段落的向量模型選用了預訓練好的中文版本的 Sentence-Bert，打分算法選用了邏輯回歸，為了避免打分模型的誤差，會再通過帕累托分布來根據段落的質量打分進行采樣來決定是否過濾這個段落。
經過這個 Pipeline 后，最終沉淀下 15G 左右的數據來進行大模型的預訓練加訓。
模型使用
DevOps-Model 的使用可以參考如下流程使用，更詳細的信息請參考 Github。
- 模型下載：
從 https://github.com/codefuse-ai/CodeFuse-DevOps-Model/tree/main 找到自己想要下載的 Chat 模型版本，當前提供了 7B 和 14B 的模型；
- 模型交互：
from transformers import AutoModelForCausalLM, AutoTokenizer
from transformers.generation import GenerationConfig
tokenizer = AutoTokenizer.from_pretrained("path_to_DevOps-Model-Chat", trust_remote_code=True)
model = AutoModelForCausalLM.from_pretrained("path_to_DevOps-Model-Chat", device_map="auto", trust_remote_code=True, bf16=True).eval()
# 指定 generation_config
model.generation_config = GenerationConfig.from_pretrained("path_to_DevOps-Model-Chat", trust_remote_code=True)
# 第一輪對話
resp, hist = model.chat(query='你是誰', tokenizer=tokenizer, history=None)
print(resp)
# 我是 DevOps-Model，一個由螞蟻集團平臺技術事業群風險智能團隊和北京大學聯合研發的人工智能機器人，可以與用戶進行自然語言交互，并協助解答 DevOps 全生命周期中的各種問題。如果您有任何需要協助的問題或者想要進行閑聊，都可以和我交流哦。
# 第二輪對話
resp2, hist2 = model.chat(query='Java 中 HashMap 和 Hashtable 有什么區別', tokenizer=tokenizer, history=hist)
print(resp2)
# HashMap 和 Hashtable 都是 Java 中常用的哈希表實現，它們的主要區別在于：
# 1. Hashtable 是線程安全的，而 HashMap 不是線程安全的，因此在多線程環境下，Hashtable 的性能更穩定。
# 2. Hashtable 中的方法都是同步的，而 HashMap 的方法不是同步的，因此在多線程環境下，Hashtable 的性能更好。
# 3. Hashtable 中的 key 和 value 都必須實現 Serializable 接口，而 HashMap 中的 key 和 value 可以是任何對象，包括基本數據類型。
# 4. Hashtable 的初始容量是 11，而 HashMap 的初始容量是 16。
# 總之，如果需要在多線程環境下使用哈希表，并且需要保證線程安全，那么應該使用 Hashtable；如果不需要考慮線程安全，或者需要快速地進行哈希表操作，那么應該使用 HashMap。
# 第三輪對話
resp3, hist3 = model.chat(query='線程安全代表什么', tokenizer=tokenizer, history=hist2)
print(resp3)
# 線程安全是指在多線程環境下，程序能夠正確地處理并發訪問，并且不會出現數據競爭、死鎖、饑餓等異常情況。線程安全的程序可以保證在不同的線程之間共享同一個數據結構時，數據的正確性和一致性。線程安全的實現通常需要使用同步機制，如鎖、原子操作等，來保證對共享數據的訪問是線程安全的。在 Java 中，可以通過 synchronized 關鍵字、Lock 接口等機制來實現線程安全。根據以上代碼來和模型進行交互，建議在運行時可以先 pip 安裝一下 github 中的 requirements.txt；同時，Github 中的代碼也提供了微調的方式，有興趣的可以在 DevOps-Model 的基礎上來微調自己的模型。
DevOps-Eval
數據來源
DevOps-Eval 最終生成的樣本格式都為單項選擇題，采用此類格式的原因是單項選擇題客觀性高，不但能夠提高樣本收集效率，并且方便進行自動化評測。
因此，我們收集樣本的策略是盡可能獲得選擇題原題，或者通過某些手段生成或轉換為選擇題。經過統計，該項目的數據來源可以分為以下 5 大類：
1) 選擇題類試題：直接為選擇題形式的公開試題，例如計算機通識類考試試題、DevOps 專業考試試題等；
2) 問答類試題：此類試題以問答題的形式出現，且已按照 DevOps 場景進行了有效劃分，來源如超級碼客、devops-exercises 等，我們再在問答題基礎上通過 ChatGPT 生成答案并轉換為選擇題；
3) 開源數據集：基于開源數據集構造 AIOps 相關樣本，例如基于 LOGPAI 的數據構造日志解析相關的選擇題樣本，基于 TraceRCA 的數據構造根因分析相關選擇題樣本；
4) ChatGPT 生成：某些細分場景缺乏現成的試題，我們使用場景關鍵詞通過 ChatGPT 直接生成相應的選擇題；
5) 數據仿真生成：通過數據仿真的手段生成數據，例如時序異常檢測、時序分類等試題。
數據分類
DevOps-Eval 根據 DevOps 全流程進行劃分，共分為 8 個大類和 53 個子類，包含 4850 道選擇題。其中，AIOps 場景有 4 個，共計 2200 個中英文題目。每個子類分為 dev 數據集和 test 數據集。
其中，dev 數據集包含 5 個帶有標簽和解析的樣例，用于 few-shot 評測；test 數據集僅包含標簽，用于模型評測。
下圖給出了 DevOps-Eval 數據的具體細分類別。若要進一步了解各個類別包含的具體內容，可以參考 Github 中更為詳細的樣本明細腦圖。
圖3. 數據細分類別
DevOps 領域大模型評測榜單
評測方式
DevOps-Eval 包含 0-shot 和 Few-shot 兩種評測方式。其中針對 DevOps 題目，主要評測 0-shot 和 5-shot 的結果。
而針對 AIOps 題目，由于題目的 token 長度較長（如日志解析任務，題干會包含多行日志），5-shot 后的題干長度會超過 2k 個 token。而大部分模型的訓練的上下文就是 2k，所以針對 AIOps 的題目，主要評測 0-shot 和 1-shot 的結果。
Base 模型和 Chat 模型獲取預測結果的方式如下：
1) Base 模型：將問題輸入大模型后，基于模型預測下一個 Token 的得分，獲得分別對應 A，B，C，D 四個選項的得分，將得分最高的選項作為模型對于這道題預測結果；
2) Chat 模型：我們先將問題轉換為 Chat 模型對齊訓練時使用的 prompt，比如 Qwen 采用的是 chatml 的格式，Baichuan2 是一種自定義的格式，采用模型對齊訓練的格式能夠使得模型更好地發揮其能力。當轉換好后輸入大模型，然后用和 Base 模型相同的方式獲取預測結果。
評測結果
- DevOps 全流程評測榜單
（1）0-shot 評測結果
圖4. DevOps 全流程評測榜單的 0-shot 評測結果
如圖所示，0-shot 評測結果中 DevOps-Model-14B-Chat 平均分最高，達到了 80.34 分。從總體上來看，各模型的分數區分度不大。
（2）5-shot 評測結果
圖5. DevOps 全流程評測榜單的 5-shot 評測結果
如圖所示，5-shot 的結果要稍好于 0-shot，其中 DevOps-Model-14B-Chat 平均分依然最高，達到了 81.77 分。
從總體上來看，各模型的分數區分度也并不大，說明樣本集難度偏低，后期需要區分下樣本難度等級。
- AIOps 場景評測榜單
（1）0-shot 評測結果
圖6. AIOps 場景評測榜單的 0-shot 評測結果
從 0-shot 結果來看， Qwen-14B-Base 平均分最高，達到了 49.27 分。從總體上來看，各模型在 AIOps 類別的區分度明顯變大。
（2）1-shot 評測結果
圖7. AIOps 場景評測榜單的 1-shot 評測結果
1-shot 的結果要稍好于 0-shot，其中 DevOps-Model-14B—Chat 平均分最高，達到了 53.91 分。
在不同細分類別的表現，根因分析得分相對較高，可能跟根因分析題目做了簡化相對較為簡單有關，而時序異常檢測整體表現都不太好，當前大模型對時序類數據的處理依然有待提升。
從上述的評測結果可以看到，DevOps-Model-14B-Chat 在 3 項評測中獲得了最好的結果，但同時也需要看到，在多個場景中，多個模型的評測結果差異不大，后續要針對 Eval 數據集做一些難度區分。
未來展望
DevOps-Model
當前發布的是模型的 1.0 版本，后續主要優化方向包括以下兩點：
1）構造更加大、更多樣的 DevOps 數據集：當前的 DevOps Corpus 只有 15G 的數據量，未來希望能夠擴充到 50G 這個量級，進一步提升模型能力；
2）采用 DevOps 領域的專有詞匯來擴充模型的詞表。當前的模型詞表是從比較通用的語料中產出的，然后針對 DevOps 領域，有一些專有的詞匯并不在詞表中，所以下一步會產出 DevOps 領域的專有詞表加到 tokenizer 中來提升模型的效果。
DevOps-Eval
針對 DevOps-Eval 項目，主要優化方向包括以下幾點：
1）不斷豐富評測數據集：包括增加英文題目、平衡各類別的數據量，題型將不局限于選擇題，增加問答等形式，對數據集增加難度分級等；
2）重點關注 AIOps 領域：AIOps 一直是運維領域的研究熱點，大模型與 AIOps 能碰撞出什么火花也是當前行業內最關心的話題。目前 DevOps-Eval 已涵蓋 4 類常見的 AIOps 任務，后續將繼續增加，直至覆蓋運維領域的所有智能化任務；
3）持續增加評測模型：一期主要評測了一些主流的、規模不是很大的開源模型，后續將覆蓋更多的模型，并重點跟蹤評測面向 DevOps 和 AIOps 領域的大模型。
希望能有更多伙伴加入共建 DevOps-Model 和 DevOps-Eval的行列，期待在大家的共同努力下，建立更準確、更全面的 DevOps 領域大模型評測體系，推動 DevOps 領域大模型技術的不斷發展與創新。
