本次分享的主題是“打造 LLMOps 時代的 Prompt 數(shù)據(jù)驅(qū)動引擎”。其中 LLMOps 想要表達(dá)的概念是 LLM for AIOps。AIOps 概念提出至少已有四年，從去年開始，在學(xué)術(shù)界出現(xiàn)了 LLMOps 的趨勢，大家都在想把 LLM 用于 AIOps 來做運維，但中間會遇到一些挑戰(zhàn)。本文將重點探討在 Prompt 數(shù)據(jù)方面，LLMOps 可能遇到的一些挑戰(zhàn)，及其解決方案。

首先簡要介紹一下華為文本機(jī)器翻譯實驗室。我們在學(xué)術(shù)界和業(yè)界都有分享和產(chǎn)品，感興趣的朋友可以關(guān)注我們的公眾號，那里有很多我們的研究成果以及發(fā)表的論文。

一、背景：從 AIOps 到 LLMOps 面臨 prompt 挑戰(zhàn)

從 AIOps 到 LLMOps，重點在于大模型強(qiáng)大的泛化能力和語言理解能力。和自然語言任務(wù)類似，AI 運維領(lǐng)域也有很多細(xì)分任務(wù)，基于大模型的泛化能力，我們預(yù)期可以用其統(tǒng)一處理這些零散的下游任務(wù)，建立一個多任務(wù)處理場景。這就是我們研究的初衷。

我們認(rèn)為 LLMOps 有兩個關(guān)鍵要素：Prompt application 和 Prompt learning。Prompt 是大語言模型在預(yù)訓(xùn)練過程中學(xué)到的知識，需要與人類的期望對齊，它是人類認(rèn)知世界與模型數(shù)字世界的橋梁。

第一個關(guān)鍵要素是高質(zhì)量的 Prompt，即 Prompt application，它幫助模型理解人類的目標(biāo)，也就是說人類直接向模型提出命令或一條通向目標(biāo)的推理路徑。實際上，就是設(shè)計一個更有效的交互策略，使得模型生成的內(nèi)容能符合人的意圖和需求。

另外一個關(guān)鍵要素是 Prompt learning。Prompt learning 是指當(dāng)前一些大模型會自動生成 Prompt 指令數(shù)據(jù)集，如 Self-instruct 策略，生成許多預(yù)制問題和答案對，稱為 Prompt 訓(xùn)練集。這些訓(xùn)練集用人類的真實 Prompt 或合成 Prompt，讓模型模擬人類可能遇到的問題，實質(zhì)上是模型在學(xué)習(xí)人類的 Prompt，因此稱為 Prompt learning。圖中顯示了更好的 Prompt 策略確實能提升模型性能，而訓(xùn)練階段的低質(zhì)量 Prompt 會降低效果。

本文將重點探討這兩個方向的問題，并分享我們的一些探索。

這兩個方向分別有兩大痛點：

• 在 Prompt application 方面，傳統(tǒng)智能運維算法依賴于任務(wù)數(shù)據(jù)，專家標(biāo)注耗時耗力；且可解釋性差，可交互性弱。
• 在 Prompt learning 方面，Prompt 訓(xùn)練數(shù)據(jù)質(zhì)量不穩(wěn)定，導(dǎo)致模型性能下降；訓(xùn)練數(shù)據(jù)全面性不足，影響了模型能力。

接下來將分別介紹我們?yōu)榻鉀Q這些問題所做的工作。

二、LogPrompt：打造 LLMOps Prompt application 引擎

首先來介紹 Prompt application。這里以 AIOps 三大支柱之一的日志分析為例，介紹如何打造 Prompt application 引擎。

軟件系統(tǒng)產(chǎn)生的半結(jié)構(gòu)化文本，傳統(tǒng)上需要運維工程師手動分析，但隨著自動日志分析算法的出現(xiàn)，出現(xiàn)了很多細(xì)分任務(wù)，其中兩個經(jīng)典任務(wù)是日志解析和日志異常檢測。日志解析涉及從原始日志中提取模板和變量，模板是日志詞，變量是 IP 地址或序號等，傳統(tǒng)方法將其轉(zhuǎn)化為 1/0 組合。而日志異常檢測則是輸入日志，輸出 1 或 0 表示是否異常。

我們重點關(guān)注的是在線場景，由于軟件更新頻繁，新版本日志往往沒有歷史數(shù)據(jù)，模型缺乏適配的訓(xùn)練數(shù)據(jù)，這就要求模型能快速泛化以處理大量未知的新日志。在訓(xùn)練數(shù)據(jù)很少的情況下實現(xiàn)高效的日志分析，這是學(xué)術(shù)界的一大難題。

傳統(tǒng)日志分析的兩大痛點是依賴大量訓(xùn)練數(shù)據(jù)和缺乏可解釋性。我們做了一些小實驗，發(fā)現(xiàn)傳統(tǒng)方法在訓(xùn)練數(shù)據(jù)占整個數(shù)據(jù)集 70-80% 時表現(xiàn)很好，但當(dāng)訓(xùn)練數(shù)據(jù)減少到 10% 時，效果顯著下降。這就是由于在線場景中大部分日志是新的，模型缺乏適配的訓(xùn)練數(shù)據(jù)，導(dǎo)致性能下滑。頻繁重新訓(xùn)練模型成本高，因此需要新的解決方案。

另一個問題是現(xiàn)有方法缺乏可解釋性。傳統(tǒng)方法將日志處理成 1/0，輸出也是 1/0，用戶只能看到一個概率值。如今用戶希望看到詳細(xì)的解釋，如為什么認(rèn)為日志異常，或者生成簡短報告來減輕運維工程師的負(fù)擔(dān)。我們希望通過大模型和 Prompt 策略來解決這兩個問題。

把大模型引入到日志分析的動力首先就是大模型具有強(qiáng)大的語言泛化能力，其指令微調(diào)過程使用少量指令訓(xùn)練數(shù)據(jù)，卻能泛化到大量未知指令數(shù)據(jù)上。因此，我們認(rèn)為 LLM 有能力處理大量未知的新日志。此外，像 ChatGPT 這樣的模型擅長復(fù)雜的語言生成任務(wù)，因此我們認(rèn)為 LLM 有潛力生成日志報告或解釋異常狀態(tài)。

然而，挑戰(zhàn)在于大模型對 Prompt 非常敏感。我們前期實驗發(fā)現(xiàn)，對于簡單的 Prompt，如“請把以下日志分為正常或異?！?，大模型的表現(xiàn)較差。用更好的 Prompt 策略后，性能提升了 70-80%。這是因為日志分析高度領(lǐng)域化，包含許多專有名詞和 IP 地址等內(nèi)容，自然語言模型可能缺乏領(lǐng)域知識輸入。因此，需要探索更好的 Prompt 策略，以充分發(fā)揮大模型的潛力。當(dāng)前 NLP 社區(qū)也提出了許多 Prompt 范式，如 CoT 和 ToT 等。我們希望將這些策略更好地應(yīng)用于 LLMOps 相關(guān)領(lǐng)域。

我們一開始引入了 CoT 策略。CoT 的核心思想是模擬人的思考過程，不是直接輸出答案，而是要求模型逐步思考（如“think step by step”），這對解決我們的兩個主要問題很有幫助。①CoT 將未知問題分解為可處理的小步驟，解決了大量未見過的新日志的處理難題。②CoT 使模型輸出更多的邏輯過程，不僅僅是一個答案，這為生成解釋性報告提供了新的思路。通過 CoT prompt，模型的輸出內(nèi)容更加豐富，報告更加完整，邏輯也更清晰，同時釋放了其預(yù)訓(xùn)練階段的潛力。

我們探索了一個叫 LogPrompt 的方案，把 CoT prompt 的思想引入日志分析任務(wù)，出發(fā)點是模擬運維工程師的思考過程。人類工程師在判斷日志異?；蛘r，會根據(jù)系統(tǒng)手冊和經(jīng)驗逐步分析，而不是直接得出結(jié)論。

基于這個原則，我們設(shè)計了兩種方法：Implicit CoT 和 Explicit CoT。Implicit CoT 讓模型解釋每條結(jié)論的理由，生成隱式的思維鏈，類似于“think step by step”。Explicit CoT 則定義了解決問題的四個步驟，判斷日志異常時，先檢查文本內(nèi)容中是否有明確的告警字樣，然后再進(jìn)行下一步；如果沒有，則排除異常。我們用領(lǐng)域知識教模型如何判定異常，并將其濃縮在一個 Prompt 中。相比標(biāo)準(zhǔn) Prompt，我們增加了一個 CoT 模塊，隱式或顯式地指導(dǎo)模型思考過程。

我們還探索了一些其他 Prompt application 策略，比如 Self-prompt，讓大模型自己生成 Prompt。首先給它一個原始的 meta-prompt，完整描述任務(wù)，例如日志解析。任務(wù)是從日志中提取公共部分作為模板，其余部分作為變量。我們告訴大模型它現(xiàn)在是一個 Prompt 工程師，請它想出五個用于執(zhí)行任務(wù)的 Prompt。然后，篩選出這五個 Prompt 中表現(xiàn)最好的一個，使用 100 條測試集進(jìn)行測試，并分析其表現(xiàn)。

另一個策略是 In-context Prompt，這涉及在描述任務(wù)后，給出一些例子，例如十個例子，五個正例，五個負(fù)例，全都拼接在后面，希望模型根據(jù)這些例子構(gòu)建任務(wù)的上下文。

還有一個策略是 Format Control，用于控制日志的輸入和輸出格式。格式控制可以減少隨機(jī)性，避免解析失敗。

我們進(jìn)行了一系列實驗，實驗設(shè)置來自于 LogHub 數(shù)據(jù)集，其中包含了各種真實收集的日志數(shù)據(jù)，包括來自 HDFS、Hadoop、Zookeeper 的，軟件、操作系統(tǒng)以及手機(jī)的日志。其中，BGL 和 Spirit 數(shù)據(jù)集都有專家標(biāo)注的異常標(biāo)簽，其余數(shù)據(jù)集則有人工打的模板。在我們的主實驗中，使用了 ChatGPT 的 API，這個實驗是去年進(jìn)行的，包括 temperature 等各項參數(shù)都進(jìn)行了設(shè)置。對于訓(xùn)練集和測試集的劃分，選擇按照時間順序進(jìn)行劃分，即選取時間上出現(xiàn)的前 10% 的數(shù)據(jù)作為訓(xùn)練集。

第一個實驗顯示，LogPrompt 在零樣本日志分析場景中表現(xiàn)良好，減少了對訓(xùn)練數(shù)據(jù)的依賴。我們首先看左邊，日志解析中的零樣本場景是指算法沒有任何訓(xùn)練輸入，每個日志都是新的，沒有歷史日志。相比之下，傳統(tǒng)算法需要訓(xùn)練數(shù)據(jù)。我們使用10% 的數(shù)據(jù)進(jìn)行訓(xùn)練，模擬在線場景，因為以前的研究也有類似的做法。實驗表明，在八個領(lǐng)域中，LogPrompt 在六個領(lǐng)域取得了最佳效果，平均來看也是最佳。

再看日志異常檢測，與之前類似，baseline 算法使用前 4000 條日志進(jìn)行訓(xùn)練，后續(xù)進(jìn)行測試，而 LogPrompt 沒有進(jìn)行訓(xùn)練。結(jié)果顯示 LogPrompt 再次取得了最佳結(jié)果。因此，LogPrompt 是在線日志分析的良好選擇。這主要歸功于 ChatGPT 的強(qiáng)大泛化能力和我們注入的領(lǐng)域知識。

接下來關(guān)注 LogPrompt 的可解釋性。我們提出了一個新任務(wù)，稱為 Log Interpretation。從之前提到的八個領(lǐng)域中隨機(jī)篩選了 200 條日志，并請六位業(yè)界 AIOps 專家進(jìn)行人工評測。輸入為原始日志，輸出要求 LogPrompt 進(jìn)行解釋，例如異常檢測需說明原因，日志解析需解釋日志內(nèi)容。

我們制定了評分標(biāo)準(zhǔn)，分為兩個維度：有用性（Usefulness）和可讀性（Readability），評分從 1 到 5。有用性（Usefulness）指生成的解釋是否詳盡、具體、相關(guān)且邏輯正確，對實際運維是否有幫助?？勺x性（Readability）則關(guān)注生成內(nèi)容是否易于理解。左下角展示了評分結(jié)果，包括平均分和高分率（評分 4 分及以上）。從平均分來看，六位專家的評分基本都在四分以上，高分率也很高，雖然個別評分有波動。

我們還收集了一些評分專家的反饋，他們普遍認(rèn)為 LogPrompt 對 AIOps 有幫助。例如，有專家提到，當(dāng)新設(shè)備插入網(wǎng)絡(luò)時，日志可能不熟悉，通常需要查找說明書，但 LogPrompt 可以快速提供解釋，比查官方定義快很多。還有專家表示，該工具能幫助快速生成異常報告，在需要召開會議時很有用。

另一個關(guān)鍵點是誤報處理。系統(tǒng)報告異常時，不知道是否需要處理，如果 LogPrompt 能提供簡短解釋，可能有助于處理誤報。我們也做了一些壞案例（Bad Case）分析，發(fā)現(xiàn) ChatGPT 在特定領(lǐng)域的知識不足，例如對某些日志的特定術(shù)語和無語義信息的日志解釋不夠，這是后期需要優(yōu)化的方向。

我們對三種 Prompt 策略進(jìn)行了消融分析。第一個是 Self-prompt 和生成的五個 Prompt，測試結(jié)果顯示 Prompt2 表現(xiàn)最好。我們發(fā)現(xiàn)，如果 Prompt 中包含更多的正式、精確的詞，如"standards"和"convert"，LLM 的表現(xiàn)可能會變好。另一方面，對中間過程的描述更清晰也能幫助 LLM，例如 Prompt2 中的"identify the replace"。

第二個消融研究是關(guān)于 CoT prompt，包括簡單 Prompt、implicit CoT（要求 LLM 解釋理由）和按照我們規(guī)定的步驟解析。有趣的是，僅僅讓 LLM 在給出答案時解釋理由就能大幅提升表現(xiàn)。我們認(rèn)為這是因為預(yù)訓(xùn)練階段訓(xùn)練了大量邏輯豐富的語料，當(dāng)要求 LLM 給出理由時，邏輯鏈會變得更清晰，這更符合預(yù)訓(xùn)練的范式。

第三個消融研究是關(guān)于 In-context Prompt，我們改變了輸入上下文樣本的數(shù)量。結(jié)果顯示，過少或過多的上下文樣本都會影響 LLM 的表現(xiàn)。過少的樣本無法建立足夠的上下文，而過多的樣本可能會產(chǎn)生注意力噪聲，導(dǎo)致 LLM 過度關(guān)注樣本而忽略任務(wù)本身。

在探索 LogPrompt 之后的應(yīng)用方向時，發(fā)現(xiàn)將這套方法應(yīng)用到工業(yè)界仍存在挑戰(zhàn)。當(dāng)前的模型如 ChatGPT、Gemini 和 Cloud 等，都是基于 API 的，具有脆弱性，可能隨時無法使用。因此，我們考慮開發(fā)可以部署的小型 LLM 用于 LLMOps。

我們進(jìn)行了初步實驗，使用了 Vicuna 13B 小模型，它可以直接部署。我們使用 Simple Prompt 和 LogPrompt 對日志異常和日常日志解析任務(wù)進(jìn)行測試。盡管 Vicuna 只有 13B 的參數(shù)，但在 HDFS、Linux 和 ProxFire 等領(lǐng)域的表現(xiàn)已接近于 ChatGPT。我們認(rèn)為，小模型有潛力完成這些任務(wù)，并且高級 LogPrompt 策略在小模型上也有效。然而，在許多領(lǐng)域的表現(xiàn)仍不理想，提升有限，離實際應(yīng)用還有距離。Vicuna 等小模型缺乏日志或運維相關(guān)語料的訓(xùn)練，知識容量也較小，因此我們可能會對其進(jìn)行知識注入和領(lǐng)域適應(yīng)，來提升其性能。

三、LLMOps 持續(xù)成長源動力：CoachLM 打造 Prompt learning 數(shù)據(jù)飛輪

在討論如何編寫 Prompt 以便大模型更好地理解人類時，另一個關(guān)鍵點是數(shù)據(jù)飛輪。為了進(jìn)行知識注入，我們需要大量訓(xùn)練數(shù)據(jù)，這就需要我們構(gòu)建一個 Prompt Learning 的數(shù)據(jù)飛輪。

以下是我們部署的 Prompt Learning 數(shù)據(jù)飛輪的過程：①使用開源數(shù)據(jù)集如 Alpaca，并對其進(jìn)行泛化，生成合成數(shù)據(jù)，然后優(yōu)化質(zhì)量（機(jī)器生成的數(shù)據(jù)質(zhì)量可能不高）；②進(jìn)行質(zhì)量評測，包括人工編輯，得到高質(zhì)量的子集；③對這些數(shù)據(jù)進(jìn)行模型評價，再讓模型生產(chǎn)新數(shù)據(jù)。

這個數(shù)據(jù)飛輪的核心是 Prompt 優(yōu)化，通過自動優(yōu)化模型 CoachLM 對訓(xùn)練數(shù)據(jù)進(jìn)行優(yōu)化。

我們目前在做的是通用的模型，可以應(yīng)用于 AIOps 領(lǐng)域，但不僅限于 AIOps，目的是解決機(jī)生 Prompt 訓(xùn)練數(shù)據(jù)質(zhì)量不穩(wěn)定和模型性能下降的問題。以 Alpaca 開源數(shù)據(jù)集為例，它是通過 GPT 合成的，這樣的數(shù)據(jù)可以用于 AIOps。但數(shù)據(jù)質(zhì)量需要人工評估和優(yōu)化，這非常耗時耗力。實驗表明，人工優(yōu)化確實有效，但效率極低。

為了解決這個問題，我們提出了一個自動優(yōu)化數(shù)據(jù)的模型。這個模型不僅解決表面問題（如缺少輸入），還處理深層次問題（如事實錯誤）。關(guān)鍵是避免低質(zhì)量 Prompt 數(shù)據(jù)堆積，防止訓(xùn)練效果下降和 AI 能力受損。

業(yè)界的解決辦法是對大模型生成的數(shù)據(jù)集進(jìn)行小批量過濾，只有 10% 的數(shù)據(jù)用于訓(xùn)練。這導(dǎo)致大量數(shù)據(jù)被過濾，損害了全面性。例如，Alpagasus 模型的代碼邏輯被過濾掉，缺失了數(shù)學(xué)推算能力。

本質(zhì)上我們使用的是一種稱為 Coach Instruction Tuning 的方法。目前，我們讓語言專家標(biāo)注了大約 2000 條數(shù)據(jù)，并經(jīng)過了專家的人工優(yōu)化。然后，我們使用大模型的指令微調(diào)技術(shù)，構(gòu)造了這些修改范例，讓模型學(xué)習(xí)專家的優(yōu)化思路。最終，在真正訓(xùn)練之前，我們使用 CoachLM 模仿專家的修改思路對生成的合成數(shù)據(jù)進(jìn)行優(yōu)化。

上圖中給出了一些例子，可以看到，原始數(shù)據(jù)較為簡潔甚至是簡陋的，經(jīng)過 CoachLM 優(yōu)化后，其邏輯鏈和思維鏈變得更為完整豐富，給出了許多思辨過程。

我們進(jìn)行了一些實驗，看到了數(shù)據(jù)質(zhì)量的全面提升。左側(cè)是原始的 Alpaca 數(shù)據(jù)集，右側(cè)是我們優(yōu)化過的 5 萬條數(shù)據(jù)，使用 ChatGPT 對這些數(shù)據(jù)進(jìn)行評分，結(jié)果顯示優(yōu)化后的數(shù)據(jù)質(zhì)量普遍較高，得分 4.5 以上的數(shù)據(jù)占比從 17% 增長到了 78%。此外，我們還從六個維度對數(shù)據(jù)進(jìn)行了人工評分，對其進(jìn)行了全面的評估。

我們用這批數(shù)據(jù)訓(xùn)練了一個模型，并在開源的 benchmark 上進(jìn)行了測試。結(jié)果顯示，我們的 7B 模型取得了最佳成績，超越了所有開源模型。我們還與更強(qiáng)的模型進(jìn)行了對比，結(jié)果發(fā)現(xiàn)我們?nèi)娉^了 Vicuna-13B 模型，并在五項測試中取得了最佳成績。

接下來，我們計劃將工作擴(kuò)展到多語言方向。目前大量開源模型主要用英語訓(xùn)練，對多語言支持不佳。我們的實驗表明，Coach 的優(yōu)化效果與基座關(guān)系密切，如果基座效果不好，Coach 的效果也會不好。因此，我們未來的方向是通過增量預(yù)訓(xùn)練或多語言指令微調(diào)，增強(qiáng)模型的多語言能力。

四、未來暢想

結(jié)尾部分是對未來的暢想?，F(xiàn)在已經(jīng)進(jìn)入全模態(tài)時代，到 2026 年可能會由兩大引擎推動全模態(tài) LLMOps 的發(fā)展，即 Prompt application 對齊引擎和 Prompt learning 學(xué)習(xí)引擎。文本和圖片模態(tài)將得到進(jìn)一步支持，語音助手可以一鍵解決問題，甚至視頻平臺也可能納入其中，為 LLMOps 提供全模態(tài)支撐。