理解LLMOps: Large Language Model Operations
對於像我一樣的小白來說，本文是一篇非常不錯的LLMs入門介紹文檔。來自：Understanding LLMOps: Large Language Model Operations
本文首先解釋了新術語"LLMOps"及其背景，然後討論使用LLMs和傳統ML模型構建AI產品的不同之處，並基於這些不同點總結出MLOps和LLMOps的差異。最後我們將討論在不久的將來，LLMOps將會發生什麼樣的變化。
什麼是LLMOps？
LLMOps是Large Language Model Operations的縮寫，可以將LLMOps認爲是LLMs的MLOps，這也意味着，LLMOps本質上是管理基於LLM的應用的一系列工具和最佳實踐，包括開發、部署和維護。
上面說到"可以將LLMOps認爲是LLMs的MLOps"，這裏看下LLMs和MLOps的定義：
- LLMs(large language models)：可以生成人類語言的深度學習模型，因此被稱爲語言模型(language models)。該模型有數十億個參數，並在數十億個單詞的基礎上進行訓練，因此被稱爲大語言模型。
- MLOps (machine learning operations)：用於管理基於ML應用的生命週期一系列工具和最佳實踐。
爲什麼LLMOps會崛起？
早期的LLMs，如BERT和GPT-2出現於2018年左右，而現在(差不多五年之後)，LLMOps 概念正在迅速崛起，其中最主要的原因是在2022年12月發佈的ChartGPT吸引了大量媒體的關注。
從那之後，我們看到了很多基於LLMs構建的應用，如：
- 從著名的ChatGPT到更親密和人性化的聊天機器人(如Michelle Huang chatting with her childhood self)。
- 從編輯或摘要的寫作助手(例如，Notion AI)到專門的文案助手(例如，Jasper 和 copy.ai))或合同助手(例如，lexion) 。
- 從用於編寫和調試代碼的編程助手(如 GitHub Copilot)，到測試(如Codium AI)並找出安全威脅(Socket AI)的助手。
隨着越來越多的基於LLM的應用的開發和產品化，人們得出瞭如下經驗：
使用LLMs可以很容易地做一些很酷的事情，但同時很難將它產品化 - Chip Huyen
不同於傳統的基於ML模型的AI產品，基於LLM的應用的產品化過程有其特定的挑戰。爲了解決這些問題，我們需要開發新的工具和最佳實踐來管理LLM應用的生命週期，因此出現了術語"LLMOps"。
LLMOps涉及哪些步驟？
LLMOps涉及的步驟和MLOps類似。但由於基礎模型的出現，構建基於 LLM 的應用程序的步驟有所不同。構建基於LLM的應用的重點在於如何使用預先訓練好的LLMs來服務下游任務，而非從頭訓練LLMs。大約在一年前，Andrej Karpathy描述了未來構建AI產品的流程：
但是，最重要的趨勢[ ... ]是，由於微調(調整LLM參數以適應特定任務的過程)，特別是像GPT這樣的基礎模型的出現，從零開始訓練神經網絡的方式很快就過時了。這些基礎模型由少數擁有大量計算資源的機構進行訓練，而大多數應用則是通過對神經網絡的一部分進行微調、prompt engineering(指通過設計和優化生成模型的提示或輸入，以獲得更好的生成結果。它是一種通過調整輸入文本的方式來引導模型生成所需輸出的技術)，或是(可選步驟)將數據或模型蒸餾成更小、專用於推理的網絡來實現的。
當你第一次讀到這句話的時候，可能會覺得有些不可思議，但它準確地概括了目前正在發生的一切，下面讓我們在接下來的小節中逐步解讀它。
第一步：選擇基礎模型
基礎模型是基於大量數據事先訓練好的一類LLMs，可以廣泛用於下游任務。由於從頭訓練一個基礎模型相當複雜、耗時且昂貴，因此只有一小部分機構擁有所需的資源。
換個角度來看：根據Lambda Labs 2020年的研究表明，如果使用一臺訓練Tesla V100雲實例來訓練OpenAI的GPT-3(大約1750億個參數)，大約需要355年，並花費460萬美元。
人工智能目前正在經歷社區所稱的Linux 時刻。目前，開發者需要從兩種類型的基礎模型之間，基於性能、成本、上手難度和靈活性進行抉擇。這兩種模型爲：專有模型和開源模型：
專有模型是由擁有大量專家團隊和大量AI預算的公司所屬的閉源基礎模型，這些模型通常要大於開源模型，且性能更好，同時，這些模式也是現成的，通常上手難度較低。
專有模型的主要缺點是其昂貴的APIs，此外，閉源基礎模型對於開發者來說提供的靈活性較少或沒有。專有模型提供商舉例如下：
開源模型通常以社區中心的方式組織和託管在 HuggingFace上。相比專有模型來說，這些模型更小，能力也更小。但好的方面在於，它們更加經濟，並給開發者帶來更大的靈活性。開原模型舉例如下：
-
BLOOM (BigScience)
-
GPT-J, GPT-Neo 或 Pythia ( Eleuther AI)
步驟2：適應下游任務
一旦選擇了基礎模型，就可以通過其API訪問該LLM。如果你之前跟其他類型的API打過交道，此時會發現和LLM的APIs打交道會有些奇怪，因爲它並沒有實現規定什麼輸入會產生什麼輸出。通過輸入任意文本提示，API會返回一段嘗試匹配輸入的文本。
下面是一個如何使用OpenAI API的例子，通過API輸入提示，如prompt = "Correct this to standard English:\n\nShe no went to the market."
API會返回['choices'][0]['text'] = "She did not go to the market."`
最主要的挑戰在於，LLMs並不是無所不能的，如何讓LLM返回你期望的內容？
在LLM的產品化調查中，受訪者提到的一個關注點是模型的準確性和幻覺問題，這意味着從LLM API中獲取期望格式的輸出可能需要一些迭代。此外，如果LLM沒有所需的特定知識，它可能會出現幻覺。
爲了解決這些問題，可以在下游任務中使用如下方式來採納基礎模型：
-
Prompt Engineering：是一種對輸入進行調整，從而使輸出更符合預期的一種技術。可以使用不同的技巧提升提示的效果(參見OpenAI Cookbook)。一種方式是提供一些符合期望輸出格式的例子，類似於零樣本學習或少樣本學習的方式。目前已經出現了像LangChain 或 HoneyHive這樣的工具來幫助管理prompt模版並對其進行版本控制。
![image]()
-
對預訓練模型進行微調是ML中已知的一種技術。它可以幫助提升特定任務的模型性能。雖然這種方式增加了訓練的工作量，但它可以降低推測的成本。LLM API的費用取決於輸入和輸出的長度。因此，降低輸入的token數就可以降低API的花費(因爲無需再給提示提供例子)。
![image]()
-
外部數據：基礎模型通常缺少上下文信息(如訪問某些特定的文檔或郵件)且會很快過期(如GTP-4訓練的是2021年9月之前的數據)。由於LLMs在無法獲取足夠的信息時會出現幻覺，因此我們需要給予它們訪問相關數據的能力。目前已經出現一些工具，如LlamaIndex (GPT Index), LangChain或 DUST，可以作爲連接LLMs和其他代理和外部數據的中央接口。
-
嵌入：另外一種方式是以嵌入的方式從LLM APIs抽取數據(如，電影總結或產品描述)，並基於這些數據來構建應用(如查詢、比較或推薦)。如果np.array無法存儲足夠長的數據，則可以選擇使用如 Pinecone, Weaviate或 Milvus等矢量數據庫。
步驟3：評估
傳統的MLOps中，通過保留的驗證集對ML模型進行驗證，並通過指標評估模型的性能。但如何評估LLM的性能？如何決定一個返回是好是壞？目前一些組織似乎在使用A/B來測試其模型。
爲了幫助評估LLMs，出現瞭如HoneyHive 和 HumanLoop 這樣的工具。
步驟4：部署和監控
LLM的完成結果在不同版本之間可能會發生重大變化。例如，OpenAI已經通過更新其模型來減少生成不適當內容(如仇恨言論)。因此，在Twitter上搜索短語"as an AI language model"現在會顯示出無數的機器人賬號。
如上展示了在構建基於LLM的應用程序時需要監控底層API模型的變化。
目前已經出現了用於監控LLMs的工具，如 Whylabs 或 HumanLoop。
LLMOps和MLOps的區別？
MLOps和LLMOps之間的差異是由於在構建基於傳統ML模型和LLM模型的AI產品時的差異所導致的。主要體現在數據管理、實驗、評估、成本和延遲。
數據管理
傳統的MLOps通常使用data-hungry ML模型。從頭訓練一個神經網絡需要大量標籤數據，即便是微調一個預訓練的模型至少也需要幾百個例子。儘管數據清洗是ML開發過程中不可或缺的一部分，但我們知道並接受大型數據集存在的不完美之處。
在LLMOps中，微調方式類似MLOps，但prompt engineering是一種零樣本學習或少樣本學習方式，這意味着我們只需要精心挑選的樣本即可。
實驗
在MLOps中，實驗方式和從頭訓練一個模型或微調一個預訓練的模型一樣。兩種情況下都需要跟蹤輸入，如模型架構、超參數和數據增強，以及輸出(如指標)。
但在LLMOps中，問題變爲是否進行prompt engineering或微調。
LLMOps中的微調和MLOps很像，但prompt engineering的實驗配置卻有所不同(如提示管理)。
評估
在傳統的MLOps中，模型的性能是通過在保留的驗證集上使用評估指標進行評估的。而由於LLM的性能更加難以評估，因此目前各大組織採用了A/B測試。
成本
傳統的MLOps的成本通常在數據採集和模型訓練，而LLMOps的成本則在推理。雖然實驗過程中使用昂貴的API可能會產生一些費用，但Chip Huyen表明，長提示的成本主要在於推理階段。
延遲
在LLM在生產中的調查中，受訪者提到的另一個關注點是延遲。LLM的完成長度會顯著影響延遲。儘管在MLOps中也必須考慮延遲問題，但在LLMOps中則更加突出，這對於開發過程中的實驗速度以及生產環境中的用戶體驗來說都是一個重要問題。
LLMOps的未來
LLMOps是一個新型的領域，隨着該領域的快速發展，一切皆有可能，即使是這裏的LLMOps定義都有可能發生變化。我們唯一可以確信的是會出現更多LLMs的使用場景，並會出現更多的工具和最佳實踐來管理LLM的生命週期。
AI的領域在急速演進，有可能本文在一個月後就過時了。我們仍然處在將LLM推向生產的初始階段，目前仍然有很多問題沒有解答，只有時間會告訴我們事情會如何發展：
- 這裏的LLMOps的術語是否會發生變化？
- LLMOps是如何根據MLOps進行演化？它們會一起變化，還是會獨立演進？
- AI的"Linux時刻"如何展開？
我們可以肯定地說，預計很快會看到新的工具和最佳實踐的出現。此外，我們已經看到針對基礎模型的成本和延遲降低方面已經付出的努力。這絕對是令人興奮的時代！
總結
隨着OpenAI的ChatGPT的發佈，LLMs已經成爲AI領域的熱門話題。這些深度學習模型可以以人類的語言生成輸出，這使得它們成爲會話AI、寫作助手和編程助手等場景下的強大工具。
但將基於LLM的應用推向生產又面臨這一些列挑戰，這也導致了一個新術語的出現，LLMOps。它指代管理基於LLM的應用的生命週期的一些列工具和最佳實踐，包括開發、部署和維護。
LLMOps可以看做是MLOps的一個子類。但構建基於LLM的應用的步驟又和構建基於傳統ML模型應用的步驟有所不同。
相比從頭開始訓練一個LLM，應用LLM的重點變爲了如何微調預訓練的LLM以適應下游任務。這其中涉及選擇一個基礎模型、在下游任務中使用LLM，以及在評估模型後進行部署和監控。
雖然LLMOps仍然是一個相對較新的領域，但隨着LLM在人工智能行業的普及，它預計將繼續發展和演變。總體而言，LLM和LLMOps的崛起代表着在構建和維護以AI爲動力的產品方面的重大轉變。
TIps