大語言模型在各類 NLP 下游任務上都取得了顯著進展，各種垂直領(lǐng)域大模型更是如雨后春筍般層出不窮。然而在 DevOps 領(lǐng)域，卻遲遲沒有相關(guān)大模型問世。為填補這方面的空白，螞蟻集團聯(lián)合北京大學發(fā)布了面向中文 DevOps 領(lǐng)域的首個開源大語言模型，即 DevOps-Model 。

該大模型旨在幫助開發(fā)人員在軟件開發(fā)和運維的整個生命周期中提高效率，最終目標是實現(xiàn)在 DevOps 流程中面臨任何問題時，都可以通過向 DevOps-Model 提問來獲取解決方案！

當前已經(jīng)開源了 7B 和 14B 兩種規(guī)格的 Base 和 Chat 模型，同時還開源了對應的訓練代碼。

此外，為了有效評估 DevOps 領(lǐng)域大模型的性能，我們同時發(fā)布了首個面向 DevOps 領(lǐng)域的大模型評測基準 DevOps-Eval。該評測基準根據(jù) DevOps 全流程進行劃分，包含計劃、編碼、構(gòu)建、測試、發(fā)布、部署、運維和監(jiān)控這 8 個類別，包含 4850 道選擇題。

此外，DevOps-Eval 還特別對運維 / 監(jiān)控類別做了細分，添加日志解析、時序異常檢測、時序分類和根因分析等常見的 AIOps 任務。由于 DevOps-Eval 根據(jù)場景對評測樣本做了詳盡的細分，因此除了 DevOps 領(lǐng)域大模型，也方便對特定領(lǐng)域大模型進行評測，如 AIOps 領(lǐng)域等。

目前，第一期 DevOps 領(lǐng)域模型的評測榜單已發(fā)布，除 DevOps-Model 外，還包含 Qwen、Baichuan、Internlm 等開源大語言模型；同時，DevOps-Model 和 DevOps-Eval 相關(guān)論文也在撰寫中。歡迎相關(guān)從業(yè)者一起來進行共建、優(yōu)化 DevOps 領(lǐng)域大模型和評測題目，我們也會定期更新模型、題庫和評測榜單。

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 的構(gòu)建過程

基座模型

在基礎通用模型選擇上，我們考量了模型訓練數(shù)據(jù)大小、模型能力、模型參數(shù)量級后，最終選擇的是 Qwen-7B 和 Qwen-14B 作為通用模型。因為在公開的一些評測榜單上，Qwen 系列模型基本屬于同參數(shù)量級下效果最好的模型。

同時預訓練的語料有達到 3T token 的量級，可以給基座模型帶來更為全面的知識。

訓練框架

訓練框架上，我們采用的是基于開源訓練庫 LLaMA-Factory 加以改造來進行訓練，訓練時通過 flash-attention、ZeRO、混合精度等技術(shù)來保障高效訓練。

整體的 Qwen 模型架構(gòu)是在 LLaMA 的結(jié)構(gòu)上做了一些優(yōu)化，其中包含采用了 RoPE 作為位置編碼的方式來提高模型的外推能力，采用了 RMSNorm 來提高訓練穩(wěn)定性，采用 SwiGLU 激活函數(shù)來提高模型的表現(xiàn)。

訓練流程

根據(jù)查閱文獻可知，大部分領(lǐng)域模型都是在對話模型的基礎上，通過 SFT 微調(diào)來進行知識注入。而 SFT 微調(diào)所需要 QA 語料基本都來自于 ChatGPT 生成。然而，該方案可能存在 QA 語料無法完全覆蓋領(lǐng)域知識的情況。

因此，DevOps-Model 采用的是預訓練加訓 + SFT 微調(diào)的方案，如下圖所示。我們認為針對領(lǐng)域大模型，預訓練的加訓是必要的，因為其可以將領(lǐng)域內(nèi)的一些知識在預訓練階段注入到大模型。

如果這些知識在通用大模型預訓練時沒有出現(xiàn)過，那會讓大模型學習到新的知識；如果出現(xiàn)過，就可以讓大模型進一步加深印象。第二步則是大模型對齊，目的是讓大模型可以根據(jù)問題來回答最合適的內(nèi)容。

圖1. DevOps-Model 訓練流程

訓練數(shù)據(jù)

• 數(shù)據(jù)收集

模型的定位是中文 DevOps 領(lǐng)域大模型，因此需要收集與中文 DevOps 相關(guān)的預訓練數(shù)據(jù)和 QA 數(shù)據(jù)。

預訓練數(shù)據(jù)主要來自互聯(lián)網(wǎng)技術(shù)博客、技術(shù)文檔、技術(shù)書籍等，最終收集到了 50G+ 的預訓練語料數(shù)據(jù)；

針對 QA 數(shù)據(jù)，我們的目標是想讓模型不僅能夠?qū)R到通用的問答能力，針對 DevOps 領(lǐng)域也可以學會如何更好的回答問題，因此不但收集了通用領(lǐng)域的單輪和多輪對話數(shù)據(jù)，還針對 DevOps 領(lǐng)域，通過爬取和 ChatGPT 生成的方式產(chǎn)出了屬于 DevOps 領(lǐng)域的問答數(shù)據(jù)。最終我們精心篩選了約 200K 的 QA 數(shù)據(jù)進行 SFT 微調(diào)訓練，具體數(shù)據(jù)量如下表所示。

• 數(shù)據(jù)篩選

由于預訓練數(shù)據(jù)大部分是從互聯(lián)網(wǎng)上收集的數(shù)據(jù)，質(zhì)量參差不齊，而大模型訓練中數(shù)據(jù)是最重要的一環(huán)，我們建立了如下圖所示的清洗 Pipeline，全面過濾收集到的數(shù)據(jù)。

圖2. DevOps-Model 預訓練數(shù)據(jù)清洗 Pipeline

1) 首先，由專家經(jīng)驗和人工篩選，總結(jié)出來了一批文檔級別的 Heuristic 過濾規(guī)則，這一步主要用來過濾掉那些質(zhì)量非常差的文檔；

2) 其次，即便是一篇質(zhì)量稍差的文章，也有可能含有有價值的領(lǐng)域知識，也需要盡可能的進行收集。此處，我們對文章進行段落拆分，將文章拆分成一個個段落；

3) 然后，我們將拆分后的段落會再次通過步驟 1 進行過濾，便得到了一批經(jīng)過規(guī)則過濾后的段落；

4) 再摘取其中 1000 個段落，由經(jīng)驗豐富的專業(yè)開發(fā)人員打標，獲得高質(zhì)量的打標數(shù)據(jù)；

5) 最后，根據(jù)打標后的結(jié)果來訓練了一個打分模型來針對段落進行質(zhì)量的打分，段落的向量模型選用了預訓練好的中文版本的 Sentence-Bert，打分算法選用了邏輯回歸，為了避免打分模型的誤差，會再通過帕累托分布來根據(jù)段落的質(zhì)量打分進行采樣來決定是否過濾這個段落。

經(jīng)過這個 Pipeline 后，最終沉淀下 15G 左右的數(shù)據(jù)來進行大模型的預訓練加訓。

模型使用

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，一個由螞蟻集團平臺技術(shù)事業(yè)群風險智能團隊和北京大學聯(lián)合研發(fā)的人工智能機器人，可以與用戶進行自然語言交互，并協(xié)助解答 DevOps 全生命周期中的各種問題。如果您有任何需要協(xié)助的問題或者想要進行閑聊，都可以和我交流哦。


# 第二輪對話
resp2, hist2 = model.chat(query='Java 中 HashMap 和 Hashtable 有什么區(qū)別', tokenizer=tokenizer, history=hist)
print(resp2)


# HashMap 和 Hashtable 都是 Java 中常用的哈希表實現(xiàn)，它們的主要區(qū)別在于：
# 1. Hashtable 是線程安全的，而 HashMap 不是線程安全的，因此在多線程環(huán)境下，Hashtable 的性能更穩(wěn)定。
# 2. Hashtable 中的方法都是同步的，而 HashMap 的方法不是同步的，因此在多線程環(huán)境下，Hashtable 的性能更好。
# 3. Hashtable 中的 key 和 value 都必須實現(xiàn) Serializable 接口，而 HashMap 中的 key 和 value 可以是任何對象，包括基本數(shù)據(jù)類型。
# 4. Hashtable 的初始容量是 11，而 HashMap 的初始容量是 16。
# 總之，如果需要在多線程環(huán)境下使用哈希表，并且需要保證線程安全，那么應該使用 Hashtable；如果不需要考慮線程安全，或者需要快速地進行哈希表操作，那么應該使用 HashMap。


# 第三輪對話
resp3, hist3 = model.chat(query='線程安全代表什么', tokenizer=tokenizer, history=hist2)
print(resp3)


# 線程安全是指在多線程環(huán)境下，程序能夠正確地處理并發(fā)訪問，并且不會出現(xiàn)數(shù)據(jù)競爭、死鎖、饑餓等異常情況。線程安全的程序可以保證在不同的線程之間共享同一個數(shù)據(jù)結(jié)構(gòu)時，數(shù)據(jù)的正確性和一致性。線程安全的實現(xiàn)通常需要使用同步機制，如鎖、原子操作等，來保證對共享數(shù)據(jù)的訪問是線程安全的。在 Java 中，可以通過 synchronized 關(guān)鍵字、Lock 接口等機制來實現(xiàn)線程安全。

根據(jù)以上代碼來和模型進行交互，建議在運行時可以先 pip 安裝一下 github 中的 requirements.txt；同時，Github 中的代碼也提供了微調(diào)的方式，有興趣的可以在 DevOps-Model 的基礎上來微調(diào)自己的模型。

DevOps-Eval 

數(shù)據(jù)來源

DevOps-Eval 最終生成的樣本格式都為單項選擇題，采用此類格式的原因是單項選擇題客觀性高，不但能夠提高樣本收集效率，并且方便進行自動化評測。

因此，我們收集樣本的策略是盡可能獲得選擇題原題，或者通過某些手段生成或轉(zhuǎn)換為選擇題。經(jīng)過統(tǒng)計，該項目的數(shù)據(jù)來源可以分為以下 5 大類：

1) 選擇題類試題：直接為選擇題形式的公開試題，例如計算機通識類考試試題、DevOps 專業(yè)考試試題等；

2) 問答類試題：此類試題以問答題的形式出現(xiàn)，且已按照 DevOps 場景進行了有效劃分，來源如超級碼客、devops-exercises 等，我們再在問答題基礎上通過 ChatGPT 生成答案并轉(zhuǎn)換為選擇題；

3) 開源數(shù)據(jù)集：基于開源數(shù)據(jù)集構(gòu)造 AIOps 相關(guān)樣本，例如基于 LOGPAI 的數(shù)據(jù)構(gòu)造日志解析相關(guān)的選擇題樣本，基于 TraceRCA 的數(shù)據(jù)構(gòu)造根因分析相關(guān)選擇題樣本；

4) ChatGPT 生成：某些細分場景缺乏現(xiàn)成的試題，我們使用場景關(guān)鍵詞通過 ChatGPT 直接生成相應的選擇題；

5) 數(shù)據(jù)仿真生成：通過數(shù)據(jù)仿真的手段生成數(shù)據(jù)，例如時序異常檢測、時序分類等試題。

數(shù)據(jù)分類

DevOps-Eval 根據(jù) DevOps 全流程進行劃分，共分為 8 個大類和 53 個子類，包含 4850 道選擇題。其中，AIOps 場景有 4 個，共計 2200 個中英文題目。每個子類分為 dev 數(shù)據(jù)集和 test 數(shù)據(jù)集。

其中，dev 數(shù)據(jù)集包含 5 個帶有標簽和解析的樣例，用于 few-shot 評測；test 數(shù)據(jù)集僅包含標簽，用于模型評測。

下圖給出了 DevOps-Eval 數(shù)據(jù)的具體細分類別。若要進一步了解各個類別包含的具體內(nèi)容，可以參考 Github 中更為詳細的樣本明細腦圖。

圖3. 數(shù)據(jù)細分類別

DevOps 領(lǐng)域大模型評測榜單

評測方式

DevOps-Eval 包含 0-shot 和 Few-shot 兩種評測方式。其中針對 DevOps 題目，主要評測 0-shot 和 5-shot 的結(jié)果。

而針對 AIOps 題目，由于題目的 token 長度較長（如日志解析任務，題干會包含多行日志），5-shot 后的題干長度會超過 2k 個 token。而大部分模型的訓練的上下文就是 2k，所以針對 AIOps 的題目，主要評測 0-shot 和 1-shot 的結(jié)果。

Base 模型和 Chat 模型獲取預測結(jié)果的方式如下：

1) Base 模型：將問題輸入大模型后，基于模型預測下一個 Token 的得分，獲得分別對應 A，B，C，D 四個選項的得分，將得分最高的選項作為模型對于這道題預測結(jié)果；

2) Chat 模型：我們先將問題轉(zhuǎn)換為 Chat 模型對齊訓練時使用的 prompt，比如 Qwen 采用的是 chatml 的格式，Baichuan2 是一種自定義的格式，采用模型對齊訓練的格式能夠使得模型更好地發(fā)揮其能力。當轉(zhuǎn)換好后輸入大模型，然后用和 Base 模型相同的方式獲取預測結(jié)果。

評測結(jié)果

• DevOps 全流程評測榜單

（1）0-shot 評測結(jié)果

圖4. DevOps 全流程評測榜單的 0-shot 評測結(jié)果

如圖所示，0-shot 評測結(jié)果中 DevOps-Model-14B-Chat 平均分最高，達到了 80.34 分。從總體上來看，各模型的分數(shù)區(qū)分度不大。

（2）5-shot 評測結(jié)果

圖5. DevOps 全流程評測榜單的 5-shot 評測結(jié)果

如圖所示，5-shot 的結(jié)果要稍好于 0-shot，其中 DevOps-Model-14B-Chat 平均分依然最高，達到了 81.77 分。

從總體上來看，各模型的分數(shù)區(qū)分度也并不大，說明樣本集難度偏低，后期需要區(qū)分下樣本難度等級。

• AIOps 場景評測榜單

（1）0-shot 評測結(jié)果

圖6. AIOps 場景評測榜單的 0-shot 評測結(jié)果

從 0-shot 結(jié)果來看， Qwen-14B-Base 平均分最高，達到了 49.27 分。從總體上來看，各模型在 AIOps 類別的區(qū)分度明顯變大。

（2）1-shot 評測結(jié)果

圖7. AIOps 場景評測榜單的 1-shot 評測結(jié)果

1-shot 的結(jié)果要稍好于 0-shot，其中 DevOps-Model-14B—Chat 平均分最高，達到了 53.91 分。

在不同細分類別的表現(xiàn)，根因分析得分相對較高，可能跟根因分析題目做了簡化相對較為簡單有關(guān)，而時序異常檢測整體表現(xiàn)都不太好，當前大模型對時序類數(shù)據(jù)的處理依然有待提升。

從上述的評測結(jié)果可以看到，DevOps-Model-14B-Chat 在 3 項評測中獲得了最好的結(jié)果，但同時也需要看到，在多個場景中，多個模型的評測結(jié)果差異不大，后續(xù)要針對 Eval 數(shù)據(jù)集做一些難度區(qū)分。

未來展望

DevOps-Model

當前發(fā)布的是模型的 1.0 版本，后續(xù)主要優(yōu)化方向包括以下兩點：

1）構(gòu)造更加大、更多樣的 DevOps 數(shù)據(jù)集：當前的 DevOps Corpus 只有 15G 的數(shù)據(jù)量，未來希望能夠擴充到 50G 這個量級，進一步提升模型能力；

2）采用 DevOps 領(lǐng)域的專有詞匯來擴充模型的詞表。當前的模型詞表是從比較通用的語料中產(chǎn)出的，然后針對 DevOps 領(lǐng)域，有一些專有的詞匯并不在詞表中，所以下一步會產(chǎn)出 DevOps 領(lǐng)域的專有詞表加到 tokenizer 中來提升模型的效果。

DevOps-Eval

針對 DevOps-Eval 項目，主要優(yōu)化方向包括以下幾點：

1）不斷豐富評測數(shù)據(jù)集：包括增加英文題目、平衡各類別的數(shù)據(jù)量，題型將不局限于選擇題，增加問答等形式，對數(shù)據(jù)集增加難度分級等；

2）重點關(guān)注 AIOps 領(lǐng)域：AIOps 一直是運維領(lǐng)域的研究熱點，大模型與 AIOps 能碰撞出什么火花也是當前行業(yè)內(nèi)最關(guān)心的話題。目前 DevOps-Eval 已涵蓋 4 類常見的 AIOps 任務，后續(xù)將繼續(xù)增加，直至覆蓋運維領(lǐng)域的所有智能化任務；

3）持續(xù)增加評測模型：一期主要評測了一些主流的、規(guī)模不是很大的開源模型，后續(xù)將覆蓋更多的模型，并重點跟蹤評測面向 DevOps 和 AIOps 領(lǐng)域的大模型。

希望能有更多伙伴加入共建 DevOps-Model 和 DevOps-Eval的行列，期待在大家的共同努力下，建立更準確、更全面的 DevOps 領(lǐng)域大模型評測體系，推動 DevOps 領(lǐng)域大模型技術(shù)的不斷發(fā)展與創(chuàng)新。