LLMOps 的探索之路（序章）

LLMOps（Large Language Model Operations）是一個涵蓋了大型語言模型（如 OpenAI 的 GPT 系列、Google 的 PaLM 以及眾多如 Meta 的 LLaMa 這樣的開源 LLMs）開發、部署、維護和優化的一整套實作的方法論和資料管理流程。LLMOps 的存在目標是確保讓開發者甚至一般使用者能夠高效能、高擴展性且安全地使用這些強大的 AI 模型來建構和營運能夠解決使用者問題的應用程式。整個架構牽涉到 #模型訓練、#微調、#RAG、部署、監控、版本控制、更新、安全性、可協作性、可轉移性以及合規性等各個面向。

Table of Contents

MLOps vs LLMOps？

LLMOps 最常被拿來做比較的就是 MLOps，不過就實務上這兩者不是一個涇渭分明的領域，兩者間有非常多的任務、方法論以及工具使用上具有相當高的重疊度，並不是導入了 LLMOps 就不需要 MLOps，很大的程度上 LLMOps 是既有 MLOps 的延伸跟擴展，LLMOps 的出現單純是在操控新興的 LLMs 以及各種 Generative AI models 時需要應對許多在傳統 ML models 上不會遇到的問題，像是 Prompt Engineering、RAG 以及 fine-tuning 等等。

首先來聊聊 MLOps

MLOps 是將「機器學習」(ML) 與「操作」(Ops) 結合的術語，指的是將機器學習模型以一致、高效且可靠的方式投入生產的實作過程。它從 DevOps（強調在軟體開發中的協同運作與自動化）的原則中獲得靈感，並將這些原則適應於機器學習的特定需求與挑戰，主要目標是簡化並優化將機器學習模型在生產環境中部署、監控、管理和更新的過程。

MLOps 的關鍵組成

機器學習的 CI/CD（Continuous Integration & Continuous Delivery）：自動化將新的或更新的 ML model 和數據整合到現有系統中，並確保順暢部署。
資料和模型版本控制（Data and Model Versioning）：跟踪和管理數據集和模型版本的變化，以保持一致性和可重現性。
模型監控和驗證（Model Monitoring and Validation）：持續監控 production 環境中 ML 模型的效能，並確保其保持準確和高效。
協作與溝通（Collaboration and Communication）：促進資料科學家、ML 工程師和運營團隊之間的有效協作。

MLOps 解決的挑戰

模型偏移（Model Drift）：檢測和糾正由於數據模式的演變而隨時間發生的模型性能變化。
可擴展性（Scalability）：確保 ML 模型能夠有效處理不斷增長的數據量和請求。
法規遵循與倫理（Regulatory Compliance and Ethics）：特別是在像醫療保健或金融這樣的敏感領域，滿足 ML 應用的法律和道德標準。

MLOps 解決的痛點

Faster Time to Market：簡化從模型開發到部署的過程，減少提供產品與服務價值所需的時間。
可靠性和質量：定期監控和更新確保高質量、可靠的 ML 模型。
團隊協作效率：清晰的工作流程和工具增強了參與 ML 生命週期的不同團隊之間的協作。

MLOps 工具與技術

各種工具和平台支持 MLOps 實作，範圍從各大 #IaaS 如 AWS、Google Cloud、Azure 所提供的 Data pipeline 與 AI API services 到專門的軟體如 #Kubeflow、#MLflow、#TensorFlow Extended 等等。

總之在實務上 MLOps 真正去解決的問題是如何去極大化的抽象化掉需要完成一項 ML 任務中間所需的複雜資料搜集、清洗以及工具使用等等任務，不論是將多家 IaaS 所提供的既有服務串接起來還是混搭部署在本地端上的軟體形成一套解決方案，MLOps 的導入對於希望有效利用機器學習的組織來說，是一項必不可少的實作過程。它有助於橋接實驗性 ML 模型與現實應用之間的差距，確保這些模型能流暢的在實驗、測試、Staging 以及 Production 各個環境間的迭代部署過程中盡可能有效、高效且可控。

LLMOps

如同先前所提到的針對 LLMOps 的定義可以理解到，它是市場針對快速發展中的 LLMs 以及奠基在其上的各類 downstream tasks（開放式 Q&A、Chatbot、Summarization、Agents 以及多模態應用等等）的回應，儘管有許多基礎元件跟 MLOps 具有重疊性，但相對於 MLOps 也具有許多新的挑戰要去解決。

但在接續以下的討論之前，我們得先建立一個 mindset 在心中，那就是『大語言模型』究竟解決了什麼樣的一個問題？理解這件事會對之後奠基在 LLM 之上的所有討論更加容易進行。

『大語言模型』所解決最根本的問題在於：『對人類語言結構與字詞多義性的徹底理解』。

但是大語言模型是一個難以駕馭的巨獸，LLMOps（大語言模型維運）或更廣義的 GenOps（生成式 AI 維運）就是一套被發展出來嘗試去駕馭這頭巨獸的方法論，指引它去完成人類想要它完成的各項『下游任務（Downstream tasks）』，諸如客服 Q&A、情緒偵測、文本分類、實體偵測以及奠基在 LLM 上的各項 Generative AI 任務。

以下我嘗試以實作一個 LLM-based 應用的場景來很實務性的順一遍整個 LLMOps 的流程與資料管線，當然我會盡量抽象化的來解說，盡量避開許多艱澀的技術。

Model/LLM selection

要實作一個 LLM-based application 第一件事當然就是要先決定你的應用程式要奠基在哪一個 LLMs 上作為 Foundation Model。在大多數情況下預設上就是走 OpenAI 的 GPT 系列，不過現在由於各大 IaaS 也都開始盯上這一塊市場，所以在 OpenAI 之外的選擇也愈來愈多，走 GCP 的話，你可以使用 PaLM2 以及 Vertex AI，走 AWS 的話，你可以使用 Amazon Bedrock，上面有 Claude2、Meta Llama 2 以及 Amazon Titan 等等，走 Azure 的話你可以用 Azure OpenAI Service，基本上只要 OpenAI 有的模型你在 Azure 上幾乎全部都能使用，甚至連 Meta Llama 2 以及 Falcon 你也能在 Azure 上直接取用。

另一個 Model selection 階段要做的選擇是：使用 API services 還是自己取得模型權重跟偏誤去進行地端的部署？

基本上，只要是 IaaS 提供的 LLMs，執行上都是透過 IaaS 們開設好的各種形式 APIs 去跟已經部署在它們 Infra 上的 LLMs 去進行互動，這有許多好處：

開發者不需要自行去類似 Huggingface 之類的 Model hub 或是 LLM project 的 github 自行下載模型權重、check point。
開發者不需自行撰寫 Python 程式去部署模型，也不需要傷腦筋怎樣去透過 APIs 揭露給外部進行服務。
開發者不用自行配置一台或多台需要極高算力資源的主機去進行 LLM 的部署與服務的提供。
服務計費採用 on-demand 的計費方式，沒有特例的話就是按照服務用到的輸入與輸出 token 數量來進行計費。

實務上除非有特殊的要求，例如說公司數據的資安政策或是特殊應用場景（想要去除 LLM 的 #RLHF？），直接透過 IaaS 提供的 LLM 基礎建設絕對是開發一個 LLM-based app 比較簡單的起始點，當然如果服務要支撐的使用者基數非常的龐大的話，透過自行架設算力並部署開源、可商用的語言模型如 Meta 的 Llama 2 或是 Falcon 以及 Mistral 等等，嘗試將不可預期的變動成本（很難預估的 token 成本消耗）轉換成可預期的固定成本（固定算力配置以及部署完成後不用按照 token 計費的開源 LLMs），這時候自行將解決方案架設在地端就有他的合理性，不然一般來說不會建議直接這樣搞。

資料整合

在跟多家廠商合作的實務經驗上，大多數的客戶通常是以下幾種狀況：

完全不清楚自身營運過程中擁有哪些有價值的資料。
數據零散的散落在組織內部各個部位不知如何統整起。
資料儲存的方式多且雜，結構化與非結構化都有（ex. PDF、CSV、Excel、Words、圖片、影片…）
需要即時性的資料匯總（ex. 需要整合內部 CRM 與進銷存、需要整合產品型錄即時更新庫存、需要查詢即時排班…）
族繁不及備載

因此實務上在這些數據的前處理與系統整合上是需要投入大量維運的工作，這時就需要 LLMOps 服務的介入，讓使用者可以簡易的透過易用的使用者介面上傳各種類型的檔案，串接可以自動化讀取資料的 API 接口，在這一階段，LLMOps 廠商主要提供以下幾項價值：

提供簡單易用的使用者介面讓用戶去上傳各種類型的檔案並自動的因應不同的檔案類型從中整理出文字語料。
快速無縫的整合多方數據來源並轉換成生成 AI 可以使用的資料格式。
快速且有效清洗雜亂數據的資料管線。

模型微調（Model fine-tuning）

大語言模型展現出的智能之所以驚人，主要在於它解決了一項核心問題：『對人類語言的徹底理解，而且還是跨語言』

奠基在這項能力上面，我們可以指導大語言模型去學習一系列特定的文字模式、敘事風格以及輸入與輸出格式的對應。這意味著透過額外的訓練我們可以指引大言模型在輸出生成內容的時候能夠跟隨我們想要它生成的格式或『風格』

如果應用在企業內對外的客服與 Q&A 上，我們可以讓經過 fine-tuning 後的大語言模型以品牌或是某一個特定角色的敘事風格去回答使用者所詢問的各種問題，經過微調我們可以讓大語言模型學習到某一特定敘事風格會使用的慣用語、贅詞以及抑揚頓挫的模式。

知識嵌入（Embedding）

現階段大語言模型就像是一個對『世界知識的快照』，它所表現出來的智慧全都奠基在它完成訓練的那一刻所內含的預訓練知識，以 OpenAI 的 GPT-4 為例，它目前對這個世界的了解是停留在 2023 年的 4月 30日，它對該時間點之後世界上所發生的事情一無所知，更重要的是有許多資料是這些大語言模型不該知道的，例如有著作權的書籍、企業內部的產品規格、研發數據以及各種具隱私的企業內文件等等，如果要將大語言模型應用在這些適配特定企業或組織上，就必須有方法將這些知識讓大語言模型可吸收可理解，這一段的工法，就是 LLMOPs 中名為 Embedding 的方法論。

從人類反饋中進行強化學習（RLHF）

大語言模型的訓練與將其對齊到符合組織的需求是一個不斷循環迭代的過程，實務上資料在自動化處理的過程中會有許多需要人工進行校正的地方，再來就是使用者的問題與 AI 合理的回應是處於一種動態的狀態下，更不用說 AI 在達成針對用戶提問一個合理比例的回答滿意度也絕非一觸可及。

為了應對上述問題，LLMOps 必須能夠有一套友善的機制讓開發者與維運者能夠快速的校正訓練內容與流程，便利的新增與刪除訓練用資料，可以用粗粒度非常細的程度去微調訓練用資料。

提示詞工程（Prompt engineering）

提示詞工程是一個指引大語言模型如何去完成使用者所提出問題的過程，標準的結構包含：

Instructions

這部分向模型說明手邊的總體任務以及如何著手處理，例如如何利用提供的外部資訊、處理查詢和結構化輸出。這通常是提示詞工程中比較固定的部分。一個常見的用途是告訴模型『你是一個有用的 XX 助理』，促使其更認真地扮演其角色。

Context

它為模型提供了額外的知識來源。這些資訊可以手動插入到提示中、通過向量資料庫搜尋獲得，或透過其他方法引入（如呼叫API、使用程式碼等）。一個常見的應用是將從向量資料庫搜尋獲得的知識作為上下文傳遞給模型。

Prompt Input

它通常代表了要求大型模型處理的具體問題或任務。這部分實際上可以與「指示說明」部分合併，但將其分成獨立的組件使結構更有條理，模板更容易重用。在調用模型形成具體提示之前，它通常作為變數傳遞給提示模板。

Output Indicator

它標記了要生成文本的開始。這類似於兒時在數學考試上寫「解答：」，標示你的答案開始的地方。如果生成 Python 程式碼，可能會使用『import』一詞來提示模型開始編寫 Python 程式碼（因為大多數Python腳本都是以導入開始）。在與 ChatGPT 對話時，這部分往往是多餘的，但在 LangChain 中，Agent 經常使用「思考：」作為引導，指示模型開始輸出其推理。

上下文管理（Context management）

上下文管理是在大型語言模型操作中一個關鍵的概念，LLMOps 在這上面扮演著重要的角色。上下文管理涉及到如何有效地組織、維護和利用上下文資訊用以指導語言模型更精準地回應查詢或完成任務。這包括如何將外部知識、數據集或即時資訊融入模型的工作流程中，以及如何根據特定情境調整模型的輸出。

簡單來說，上下文管理就是確保模型能夠在適當的時候引用正確的資訊，從而提供更加相關、準確和有用的回應。

對一般大眾來說，你可以想像上下文管理就像是一個聰明的圖書管理員，他不僅知道書架上每一本書的內容，還能根據你的問題，迅速找到並提供最相關的資訊給你。在 LLMOps 中，上下文管理的目的是讓語言模型像那位聰明的圖書管理員一樣，能夠靈活地應對各種查詢，並提供最合適的答案。

例如，當開發一個客服聊天機器人時，上下文管理能幫助機器人記住與客戶之前的對話內容，從而在後續的互動中提供更加個性化和連貫的回應。同樣地，在處理專業領域的查詢時，上下文管理可以確保機器人引用的是最新的研究成果或數據，提高其回答的專業性和準確性。

總的來說，LLMOps 是針對大語言模型進行上下文管理中不可或缺的一個組件，它使得大型語言模型能夠更加智能和適應性強，在各種應用場景中提供高質量的服務。

Model benchmark

Model Selection 其實是一個非常複雜的決策過程，開發者必須考量到的因素非常的多。

模型的性能（Model Performance）

這邊指的是開發者是否能夠有足夠的技能與知識去評估 ML model 或大型語言模型（LLM）在特定 downstream 任務上的表現。要詳細解釋這個部分，我們需要稍稍討論多個不同的性能評估指標、基準測試（benchmarks）和標準（standards）。

常見的模型評估指標有下面幾項

Accuracy

在定義上 Accuracy 是指模型正確預測的實例數占總預測實例數的比例。換句話說，它衡量了模型在所有預測中做出正確判斷的能力，其計算公式如下

Accuracy = TP + TN / (TP + FP + TN + FN)

真陽性 (TP)：模型正確預測為陽性類別的實例數。
假陽性 (FP)：模型錯誤預測為陽性類別的實際陰性類別實例數。
真陰性 (TN)：模型正確預測為陰性類別的實例數。
假陰性 (FN)：模型錯誤預測為陰性類別的實際陽性類別實例數。

Accuracy 在 #陽性分類與 #陰性分類不均衡的資料集的模型成效評估上不是一個可靠的性能指標，如果一個類別的實例數量遠多於另一個類別，模型可能傾向於總是預測較多實例的類別，從而產生高準確度，但這並不表示模型具有良好的分類能力。為了獲得更全面的性能評估，Accuracy 應該與其他指標如 Precision、Recall 和 F1 Score 一起使用。

Precision

中文的話應該是翻成 #精確度，是衡量一個模型在預測 Positive class 時是否精確的一項指標，具體來說，它表示被模型正確識別為 Positive class 的 examples 與模型預測為 Positive class 的所有examples（包括正確和錯誤的）之間的比例。在醫學診斷或詐騙檢測的場景中，減少 False Positive（即錯誤地將 Negative class 分類為 Positive class）是非常、非常、非常重要的。在這些應用場景中，精確度會是一個關鍵指標，高精確度意味著較少的 False positive error，但可能會遺漏一些真正的 Positive class samples。

不過 Precision 並不是沒有其局限性，單獨使用 Precision 作為評估指標是不足以全面反映模型性能的，尤其是在 Positive class 和 Negative class 樣本不均衡的情況下，Precision 可能會因忽略了大量實際為 Positive class 但被錯誤分類為 Negative class 的 samples（即 False Negatives）而變得不可靠。

因此在實務上在評估一個模型的成效時我們通常會將 Precision 與 Recall 或 Sensitivity 一起使用，以提供更全面的性能評估。另外 F1-score 是 Precision 和 Recall 的調和平均（Harmonic mean），常用於平衡這兩者，特別是在兩者之間存在權衡的情況下。

Recall

Recall 在統計學的定義是指在所有實際為 Positive class 的 examples 中，模型正確識別為 Positive class 的比例。它反映了模型捕捉 Positive class examples 的能力。

Recall 的計算公式為

Recall = True Positives / (True Positives + False Negatives)

True Positives：模型正確預測為 Positive class 的 examples 數。
False Negatives：模型錯誤預測為 Negative class 的實際 Positive class 的 example 數。

Recall 高低與否對醫學診斷或詐騙檢測等領域是非常重要的，因為在這些領域中若是將原本應該為 Positive class 的 examples 誤判為 Negative class 將會付出極為高昂的代價。具有高 Recall 的模型意味著具有低 False Negatives 的錯誤率，但可能伴隨著較高的 False Positive（即模型錯誤地將 Negative class 分類為 Positive class）的問題。

如同 Precision，Recall 這項指標也是具有它自身的局限性單獨使用 Recall 可能無法完全反映模型的準確性，因為它不考慮被錯誤分類為 Positive class 的 Negative class 的 examples。在某些情況下，提高 Recall 可能會導致 Precision 下降，這是因為模型為了捕捉更多 Positive class 而將更多 Negative class 錯誤地分類為 Positive class。

F1 Score

F1 Score 在統計定義上是 Precision 和 Recall 兩個指標的 #調和平均數，它在兩者之間提供了一個平衡，特別適用於那些對 Precision 和 Recall 同等重視的應用場景，其計算公式為：

F1 Score = 2 x (Precision x Recall) / (Precision + Recall)

在實務上，F1 Score 通常被當作是一個平衡用的指標，當 Precision 和 Recall 之間存在權衡時，F1 Score 提供了一個平衡這兩者的方法。同時在 Positive class 與 Negative class 不均衡的資料及訓練過程中尤其有用，因為對於這類不均衡的資料集單獨使用 Precision 或 Recall 可能不足以提供準確的模型性能評估，F1 Score 在這種情況下就顯得特別有用。

當然如同 Precision 跟 Recall，F1 Score 在某些場景下也是有它自身的局限性，例如在那些對 Precision 或 Recall 有特別偏好的應用中，就可能需要單獨的去考慮這兩個指標而不是用透過兩者經過調和平均數計算後的 F1 Score，再來就是在某些極端情況下，如某 class 的樣本非常少時，F1 分數可能會導致誤導性結論。

ROC-AUC

這項模型成效評估指標在定義上是由以下兩者組成

ROC（Receiver Operating Characteristic）曲線：ROC 曲線是一種圖形化展示分類器性能的工具，它通過將 True Positive Rate（TPR 又稱為 #敏感度 #真陽性率）與 False Positive Rate（FPR 又稱 #假陽性率）進行比較來展示。

AUC（Area Under the Curve）：AUC 指的是ROC曲線下的面積，其提供了一個量化分類器整體性能的方法，範圍從 0 ~ 1，AUC 越高表示分類器的性能越好。

如何計算 ROC-AUC？

True Positive Rate(TPR) = True Positives / (True Positives + False Negatives)

False Positive Rate(FPR)= False Positives / (False Positives + True Negatives)

ROC 曲線是以 FPR 為橫軸，TPR 為縱軸繪製的，而 AUC 是 ROC 曲線下方的面積。

ROC-AUC 的優點是評估分類器在不同 threshold 設定下整體性能的一種方法。它不依賴於特定的分類的 threshold，因此在資料集中陽性分類與陰性分類數量不均衡的狀態下，ROC-AUC是一個有用的成效評估指標，因為它將 #偽陽性和 #真陽性分類分開考慮。當然 ROC-AUC 也一定有他的局限性，在某些情況下，特別是當 #陰性分類的數量遠多於 #陽姓分類的數量時，ROC 曲線可能對模型性能的評估會趨向過於樂觀，同時 ROC 曲線也不直接反映分類器對於不同類別的權衡。

Loss Function

中文翻譯應該是稱為 #損失函數，它是一個用於衡量模型的預測結果與真實數據之間的不一致程度的數學函數，在 LM model 的訓練過程中，損失函數用來指導模型的學習，目的是最小化這個函數所計算出的損失值並通過最小化這個損失值讓模型能夠學習去從訓練數據中捕捉到重要的 pattern 和趨勢。

Loss function 的類型有非常多種，常見的有 #平方誤差損失 MSE（Mean Squared Error）、交叉熵損失（Cross-Entropy Loss）、絕對誤差損失 MAE（Mean Absolute Error）以及 Huber損失等等，我們這邊先不展開，這是很大的一個坑。

接下來我們談談模型的 #基準測試與相關標準

GLUE（General Language Understanding Evaluation）

這是一組用於評估和比較 NLP 與 LLM 在多個不同 downstream tasks 執行成效上的基準測試。它包括了一系列的自然語言處理（NLP）任務，目標是要去綜合評估語言模型在理解自然語言上的能力。

一般來說GLUE包括以下幾種不同類型的NLP任務

情感分析（Sentiment Analysis）：判斷文本的情感傾向。
Textual Entailment：中文應該是翻成 #文本蘊涵，用來判斷一段文本是否邏輯上能推導出另一段文本。
語義相似性（Semantic Similarity）：評估兩段文本在語義上的相似度。
文本相關性（Textual Coherence and Cohesion）：評估文本的一致性和連貫性。

透過 GLUE，在實作 LLMOps 的過程中就能夠透過他進行

Model 性能評估：GLUE提供了一種全面性的方法來評估語言模型在多個不同 NLP 任務上所呈現出的性能，這有助於揭示模型的優勢和劣勢。
作為 Benchmark 的標準：它是一個產學界作公認的基準測試，GLUE允許研究者和開發者在一個共同的框架下比較不同模型的性能，奠基在具有一至性的認知上，透過 GLUE 去挑戰 LLMs 在各種複雜語境下的理解能力，大大降低了溝通上的成本。
模型優化方向：GLUE 的結果可以作為 LLMOps 優化整個流程的指引，幫助研究者和工程師識別模型優化的重點區域。

因此簡單的小結一下 GLUE 可以協助 LLMOps 進行

模型選擇：決定哪個 LLMs 更適合特定的應用或服務。
持續優化：根據 GLUE 的反饋進行模型的持續改進和調整。
效能基準：設定語言模型效能的期望標準。

SuperGLUE

SuperGLUE 是奠基在 GLUE 基準測試之上的一個進階版本，它包含了更具挑戰性的任務集，目的是在評估和比較 LLMs 在更高難度的NLP 任務上的表現，相對於 GLUE，SuperGLUE 還包含了以下這些跟語言相關的複雜任務

BoolQ（Boolean Questions）：判斷問句的答案是否為真或假。
CB（CommitmentBank）：文本蘊涵任務，判斷文本之間的推理關係。
COPA（Choice of Plausible Alternatives）：因果推理任務，選擇最合理的因果關係。
WiC（Words in Context）：詞義消歧任務，判斷在不同語境中單詞是否具有相同含義。
WSC（Winograd Schema Challenge）：共指解析任務，測試模型對語言中的隱性知識的理解。
其他諸多任務。

透過導入 SuperGLUE 評估基準引入更加複雜和多樣的任務，可以有效提升對 LLMs 評估的挑戰難度，進而確認 LLMs 是否能夠在更加複雜的語言任務中順利完成任務。

SQuAD（Stanford Question Answering Dataset）

SQuAD 是由 Stanford University 開發的一個問答資料集，它包含了一系列的問題和對應的答案，這些問題和答案都是基於 #維基百科的文章，SQuAD 的目標是評估和比較不同 LLMs 在理解和回答問題方面的能力。

SQuAD 相對於其他用於 #基準測試的資料集來說有以下特點

問與答的 pair 資料：SQuAD 包含成千上萬的問答對，這些問題涵蓋廣泛的主題和類型，包括 #事實性問題、#解釋性問題和 #推理性問題。
上下文相依性：每個問題都伴隨著一段文本（上下文），模型需要從中找到答案。
準確性評估：SQuAD 允許對模型在找到精確答案方面的能力進行評估。
提供了一個標準化的方式來評估 LLMs 在處理實際問答任務時的性能，特別是在理解自然語言的上下文和提取信息方面。

目前 SQuAD 有兩個主要的版本，分別是

SQuAD 1.1：這是最初的版本，包含超過 10 萬個問答對，這些問答對都是基於超過 500 篇維基百科文章。
SQuAD 2.0：這個版本在 SQuAD 1.1 的基礎上增加了可以沒有答案的問題，使得整個資料集更具挑戰性，而數量上 SQuAD 2.0 包含超過 15 萬個問答對。

簡言之，SQuAD 被廣泛用於評估包括 #問答系統、#閱讀理解模型和其他類型的 #NLP 模型。相較於 GLUE 以及 SuperGLUE， SQuAD 是一個規模更大也更多樣化、更具有挑戰性的基準測試，在 LLMs 的發展過程中起到了重要的作用。

BLEU（Bilingual Evaluation Understudy）

BLEU 是一種自動評估機器翻譯品質的方法，它通過比較機器翻譯的輸出和一個或多個參考翻譯之間的相似度來給出評分，BLEU 評分範圍通常在 0~1 之間，分數越高表示翻譯質量越接近人類翻譯的水平。

BLEU 的評分主要基於 n-gram 精確度的計算，包括以下幾個步驟

n-gram 的匹配：計算機器翻譯輸出中的 n-gram 與參考翻譯中的 n-gram 匹配的頻率。
截斷（Clipping）：限制機器翻譯輸出中的 n-gram 數量，以防止重複計算。
加權平均：對不同長度的 n-gram 匹配給予不同的權重。
長度懲罰：對於過短的翻譯輸出進行懲罰，以避免偏好簡短的輸出。

BLEU 的主要貢獻在於為機器翻譯的品質提供了一個標準化和客觀的評估方法，BLEU 允許快速比較不同機器翻譯模型的性能，並透過 BLEU 評分作為指導 LLMs 在進行翻譯任務時的優化和調整基準。

同樣的，BLEU 也有他的局限性，雖然它是一個有用的指標，但它在實務上無法完全捕捉翻譯品質的所有方面，如語義的準確性和流暢性，BLEU 依賴字面上的匹配，無法充分評價翻譯的自然性和靈活性。

ROUGE（Recall-Oriented Understudy for Gisting Evaluation）

ROUGE 是一套用於評估自動文件摘要和機器翻譯品質的基準測試，它主要通過比較自動生成的摘要或翻譯與一組人工編寫的參考摘要之間的重疊程度來評估 LLM 推論結果的質量。

ROUGE 這項基準測試有以下幾個常見的不同變體

ROUGE-N：評估 N-gram（如單詞或雙詞連續出現的序列）在自動生成的語料與參考語料中的重疊情況。
ROUGE-L：基於 #最長共同子序列（LCS），考慮句子級結構的相似性。
ROUGE-S：考慮跳躍式的雙詞序列，允許詞序列之間有間隔。

相較於 BLEU，ROUGE 提供了一種更全面的方法來評估語言模型在生成文本摘要或翻譯時的性能，特別是在保留原文主旨和重要信息方面。另外，作為一個標準化的 LLM 評估工具，ROUGE 允許研究者和開發者在一個共同的框架下比較不同 LLM 的性能，進而用評估後的數據去指導 LLM 後續的優化。

在局限性上，跟 BLEU 很類似的，ROUGE 主要關注於詞彙層面的重疊，無法充分捕捉語義和句子結構的準確性，ROUGE 評分不一定代表文本的質量高，因為它無法完全評估文本的流暢性和可讀性。

BERTScore

BERTScore 是基於 BERT（Bidirectional Encoder Representations from Transformers）語言模型的 LLM 評估方法，它通過計算生成文本和參考文本之間的語義相似性來評估文本生成任務（如機器翻譯、文本摘要）的質量。

BERTScore 利用預訓練的 #BERT model 來獲得文本的 Embedding，然後計算生成文本和參考文本之間 embedding 向量的餘弦相似度，因此它考慮了整個句子的語義，而不僅僅是單詞層面的匹配。也就是說，相較於傳統基於 n-gram 的評估方法（如 BLEU 以及 ROUGE）不同，BERTScore 關注於整體語義的相似性，能更準確地反映語言模型的理解能力，在處理複雜語境和細微語義差異時相較於傳統的基準測試有很大的優勢。

SacreBLEU

SacreBLEU 是一個提供標準化 BLEU 評分的工具，它主要的目標在解決 BLEU 的評分在不同研究和報告中缺乏一致性和可重現性的問題，可說是強化版的 BLEU，SacreBLEU 通過提供一套固定的參考數據和計算規則，確保 BLEU 評分的 #一致性和 #可比較性。SacreBLEU 相較於 BLEU 更加容易進行整合和使用，支持多種語言和更多的資料集，並且與主流的機器學習框架具有高相容性。

如何進行模型性能評估

數據準備：選擇合適的數據集，並對其進行預處理。
交叉驗證：使用交叉驗證來減少過擬合的風險並提高模型的泛化能力。
實驗設計：設定一組標準化的實驗流程，以確保評估的一致性和可重複性。
性能評估：運行模型並使用上述指標進行評估。
結果分析：分析模型性能並識別潛在的改進領域。

資源需求（Resource Requirements）

計算資源（Computational Resources）：評估訓練和推理過程中所需的計算資源，如CPU和GPU的需求。

儲存空間（Storage Space）：考慮模型大小和所需的儲存空間。

3. 可擴展性和靈活性（Scalability and Flexibility）

模型擴展（Model Scalability）：確保模型能夠適應大量數據和請求。

適應性（Adaptability）：模型是否容易適應新的數據集和不同的應用場景。

4. 成本效益（Cost-effectiveness）

運營成本（Operational Cost）：考慮訓練和維護模型的成本。

效率（Efficiency）：評估模型運行的能效和成本效益。

5. 易用性和集成（Usability and Integration）

API和工具支持（API and Tool Support）：檢查模型是否提供易用的API和與現有工具的集成能力。

文檔和社群支持（Documentation and Community Support）：良好的文檔和活躍的開發者社群可以幫助解決實施過程中的問題。

6. 安全性和隱私（Security and Privacy）

數據安全（Data Security）：確保模型的使用符合數據隱私和安全標準。

模型安全（Model Security）：考慮模型是否容易受到攻擊，如對抗性攻擊等。

7. 法規遵從性（Regulatory Compliance）

符合標準（Standards Compliance）：確保模型遵守相關行業和地區的法規要求。

8. 維護和支持（Maintenance and Support）

更新頻率（Update Frequency）：考慮模型提供者更新模型的頻率。

技術支持（Technical Support）：評估模型提供者是否提供可靠的技術支持。

總結選擇合適的大型語言模型需要綜合考量性能、資源需求、可擴展性、成本效益和易用性等多個因素。此外，安全性、隱私、法規遵從性以及維護和支持也是重要的考慮因素。通過仔細評估這些標準，您可以做出符合您特定需求和目標的合理決策。

Data integration

上述的 Model Selecting 的程序其實是一個非常複雜的任務，

Privacy measurement

In-context learning

Embedding

Fine-tuning

RLHF

Prompt engineering

Context management

Model deployment

Model performance

Model montioring

Model governance

Model security

TBD

項目	MLOps	LLMOps
算力需求

更龐大算力的需求

LLMs 的預訓練和微調需要對極為龐大的資料集進行處理，這些任務通常遠比訓練一個傳統的機器學習（ML）模型所要啃食的算力來的多得太多。為了加速 LLM 的訓練過程，需要使用專門的硬體如 GPU 叢集對數據進行更快的平行運算。總之相對於 MLOps，LLMOps 除了傳統 MLOps 要做的事情可能一件也少不了，但在新技術、流程設計、算力與硬體資源的 deploy 上卻可能複雜上 n 倍。另外，為了能夠有效的降低 model 進行推論所需的算力，模型壓縮和蒸餾技術在整個 LLMOps 的迭代過程中也是個重要的環節之一。

既然談到了 LLM 的壓縮和蒸餾技術，我們就來多說一些。

LLM 的壓縮（Compress）通常包含以下幾個階段

評估模型需求：首先要評估完成預訓練與 fine-tuning 後的原始 LLM 的規模和性能，確定壓縮後需要達到的性能指標和大小。
選擇壓縮策略：根據模型的特點和應用上的需求去選擇合適的壓縮方法。常見方法包括
- 權重剪枝（Pruning）透過去除不重要的模型權重，例如只保留權重最大的參數去降低模型大小。
- 量子化（Quantization）：減少表示權重的浮點數，例如從 32 bit 降低到 8 bit。
- 知識蒸餾（Knowledge Distillation）：用較小的模型去 Mimic 大模型的輸出進而取得相近的效果。
- 編碼（Coding）：例如透過 Huffman Coding 編碼將 weights 編碼為可變長度去壓縮模型。
性能評估：壓縮後需要評估模型的性能，以確保其仍滿足既定的應用標準。

接下來我們談談 #知識蒸餾（Knowledge Distillation），這是一種在機器學習和深度學習中常見的技術，尤其用於較大型模型的壓縮和優化。它的基本概念是將一個大型、複雜的模型（稱為 #教師模型）的知識轉移到一個更小、更高效的模型（稱為 #學生模型）中。整個迭代過程中最重要的任務當然是要先訓練出教師模型，而且要確保它能夠達到足夠高水準的性能。接著會使用教師模型對訓練數據進行預測，生成輸出。這些輸出不僅包括最終預測結果，也可能包括中間層的反應和其他形式的 Soft Labels。在這之後就是學生模型的訓練，使用由教師模型生成的輸出來訓練學生模型。這個過程的目標是使學生模型能夠學習到教師模型的行為和決策方式。然後我們要對學生模型展開 eval，學生模型基本上一定會比教師模型在參數量與複雜度小非常多，但目標是要讓其保持接近教師模型的性能。知識蒸餾在許多領域都會應用到，特別是在需要部署到算力資源有限的環境（如移動設備、嵌入式系統）的情況下。一但能夠有效的完成 Knowledge Distillation 將能夠大規模的減少模型的大小和算力需求，進而加快模型的推理速度並保持相對高性能的同時降低能耗。知識蒸餾是一種高效的模型優化技術，通過從大型模型到小型模型的知識轉移，達到在有限的算力下保持良好性能的目的。

不論是壓縮還是蒸餾，目的都在生成一個更小、更高效，但仍保有相對於大模型相似功能的新模型。這對於在計算資源有限的環境中部署模型尤其重要，能夠在保持較高性能的同時減少對計算資源的需求。透過這些技術，LLM 能夠在更節能且成本效益更高的方式下運行。

轉移學習：與從頭開始創建或訓練的許多傳統ML模型不同，許多大型語言模型是從一個基礎模型開始的，並通過新數據進行微調以提高在更具體領域的性能。這種微調方法允許使用更少的數據和計算資源來達到特定應用的最先進性能。

人類反饋：在訓練大型語言模型中，通過人類反饋的強化學習（RLHF）是一項主要的改進。由於LLM任務通常非常開放式，因此來自應用程序最終用戶的人類反饋對評估LLM的性能至關重要。在LLMOps管道中整合這個反饋循環，既簡化了評估，又為LLM的未來微調提供了數據。

超參數（Hyperparameter）調整：在傳統ML中，超參數調整通常集中於提高準確度或其他指標。對於LLM來說，調整也變得重要，以減少訓練和推理的成本和計算功率要求。例如，調整批次大小和學習率可以顯著改變訓練的速度和成本。因此，傳統ML模型和LLM都受益於跟踪和優化調整過程，但重點不同。

性能指標：傳統ML模型有非常清晰定義的性能指標，如準確度、AUC、F1分數等。但評估LLM時，則適用一整套不同的標準指標和評分，如雙語評估替代者（BLEU）和針對摘要評估的回憶導向替代者（ROUGE），在實施時需要額外考慮。

提示工程：指令跟隨模型可以處理複雜的提示或指令集。設計這些提示模板對於從LLM獲得準確、可靠的回應至關重要。提示工程可以減少模型幻覺和提示黑客攻擊的風險，包括提示注入、泄露敏感數據和越獄。

建立LLM鏈或管道：通過使用如 LangChain 或 LlamaIndex 等工具建立的LLM管道，將多個LLM呼叫和/或對外部系統（如向量數據庫或網絡搜索）的呼叫串聯在一起。這些管道允許LLM用於複雜任務，如知識庫問答，或基於一組文件回答用戶問題。LLM應用開發經常集中於構建這些管道，而不是構建新的LLM。

在使用 LLMOps 系統如 Deus 之前，基於 LLM 開發應用的過程是個非常繁瑣與耗時的工程，開發者需要自行處理每一個迭代階段的任務，這可能導致效率低下、難以擴展和安全性問題，以下是有無導入 LLMOps 在效率上的一份比較圖。

任務	不使用 LLMOPs	導入 LLMOPs
資料的準備與搜集階段	必須手動收集和預處理許多不同資料源的數據，涉及到複雜的資料清洗和標籤工作，需要編寫許多程式碼來進行處理。	系統預設會提供許多自動化數據源串接、收集和預處理的工具，並大量了簡化資料清洗和對數據下標籤的工作，最小化甚至消除需要撰寫編碼工作。
Prompt Engineering	開發者只能通過呼叫 API 或 Playground 進行 Prompt 編寫和調試，非常難快速的進行不同方法論（ex. CoT、ToT、GoT、Cot-SC 等等）的測試跟迭代，缺罰即時的模型推論回饋和視覺化的控制。	可以在同一個管理介面下調用出多個不同的 LLMs 進行 1:n 的提示詞測試，同時可以在快速的從預先建立好的 Prompt Templates（ex. 超參數與提示詞方法論）快速的對同一個問題進行大規模的測試與優化。
Embedding	開發者必須自行串接各家的 Vector Stores，並自行管理本地端數據與 Vector Store 中數據的關聯，本地端資料有編輯或修改的發生都得要自己撰寫程式去跟 Vector Store 進行同步。	LLMOPs 系統預設上會串接好市場上主流的 Vector Store，像是 Pinecone、Chroma、Weaviate、Qdrant 以及 Faiss 等等，用戶只需要透過介面進行簡易的設定就能開箱即用。
Context Management	開發者必須自行管理呼叫各家 LLM API 或是 LLM model 時的 context	系統會自動處理長上下文的 Embedding、存儲和管理，提高效率和擴展性，無需編寫大量程式碼。
應用監控與維護	手動收集和分析性能數據，通常無法及時的發現和處理問題，開發完善的系統日誌記錄功能也會是一件非常繁瑣的任務。	系統能自動化且即時的監控各項效能數據，快速發現和處理問題，確保 LLM-based apps 的穩定運行，並會提供完整的日誌記錄系統輔助後續的各項調校任務。
模型 fine-tuning	需要自行處理微調數據的搜集和訓練過程，需要自行做版本控制，同時需要應對各個不同語言模型所需要的語料格式、參數設置以及微調後模型的 eval。	系統預設上會提供一鍵 fine-tuning 功能，基於過去已標注的真實使用數據進行訓練，提高模型性能，減少需要大量撰寫程式的工作。
Model routing	必須有開發者配合自行串接各個不同 LLMs 的 fine-tuning API 或是更低階的函式庫去將訓練資料部署在多個 model 上。不同模型間的路由也需要開發者自行撰寫程式進行。	系統化的將訓練數據同時部署在多個不同的 LLMs 上做相互的備援並根據問題的複雜程度或是領域去自動切換使用的模型。
系統管理與維運	需要技術人員參與或花費成本開發管理後台，增加開發和維護成本，缺乏多人協同和對非技術人員的友好支持。	易用的界面，非技術人員也可參與，支持多人協同，降低開發和維護成本。與傳統開發方式相比，Dify 提供了更加透明和易於監控的應用管理，讓團隊成員更好地了解應用的運行情況。

TBD

Reference

LLM benchmarks