在《異形》系列的世界觀中，有個創造「人類」和「異形」，綽號被稱為「工程師」的種族，在《異形》電影第一集的人們還叫他們為「太空騎師」，也有人稱他們為 Mala’kaks。我這裡可以直接說他就是LLM工程師。(請原諒我這麼形容工程師)
所以「工程師」可能是「異形」的創作者，但也有可能只是將「異形」弄成自己兵器的「改良者」? AI大模型時代的「工程師」是不是在打造異形呢?
評估機器生成文本的品質一直是自然語言處理(NLP)領域的長期挑戰,在大語言模型(LLM)時代更顯得至關重要。我們需要深入了解 LLM 的特性和行為,才能更好地應用和改進它們。過去,人工評估一直是主要方法,因為人類能夠可靠地評估文本中的細微差別。例如簡潔性、創造力、語氣和文化差異。相比之下,傳統的自動評估指標(如BLEU、ROUGE)無法捕捉到人工評估的深度和精細度。
最近,使用大型語言模型(如GPT-4)作為評估工具受到了廣泛關注,因為它有可能達到與人工評估相當的水準。初步研究表明,如果提示得當,LLM可以模仿人類評估的精細程度。然而,儘管使用專有LLM作為評估工具的優點是顯而易見的,但也存在一些關鍵缺點:
1. 封閉原始碼:專有LLM的內部運作沒有向更廣泛的學術界披露,缺乏透明度,阻礙了集體學術努力來改進或提升其評估能力。此外,這將學術界的核心原則──公平評估,置於營利實體的控制之下,引發了中立性和自主性的擔憂。
2. 無法控制版本:專有模型經常進行版本更新,但用戶無法掌控。這帶來了再現性挑戰。再現性是科學探究的基石,版本變化導致的任何不一致都可能破壞依賴特定模型版本的研究發現的穩健性,尤其是在評估領域。
3. 高昂成本:LLM API的財務約束並非無足輕重。例如,在1000個評估實例上使用GPT-4評估四種大小(從7B到65B)的四種LLM變體,成本可能超過2000美元。這種規模的成本對學術機構或預算有限的研究人員來說可能是難以承受的。
儘管有這些局限性,專有的LLM(如GPT-4)能夠根據定制的評分規則來評估分數。具體而言,目前的資源局限於通用的、單一維度的評估指標,要麼過於特定領域/任務(例如EM、Rouge),要麼過於粗糙(例如helpfulness/harmlessness)。
例如,AlpacaFarm的提示給出了偏好的單一定義,要求模型選擇普遍偏好的模型響應。然而,響應偏好會因具體應用和價值觀而有所不同。在現實世界中,用戶可能對定制的評分規則更感興趣,例如「哪種LLM生成的響應更有趣、幽默」或「哪種LLM在回答時特別注重文化敏感性」。然而,在我們的初步實驗中,我們發現即使是最大的開源LLM(70B)與專有LLM相比,也不足以根據定制的評分規則進行評估。
這個論點也與我們經常在AI Agent中辯論的AI應該"更有用"還是"更有趣"非常相似。坦白說電影中出現的具身智能機器人都是"有靈魂"的, 但現實中我們寧願AI是個"工具助理"。儘管他已經可以幹不少"Copilot"的事情。
為了解決這些問題,KAIST AI, NAVER AI Lab, NAVER Cloud, Washington大學, MIT共同提出了Prometheus,一個13B參數的語言模型,旨在引入GPT-4的細粒度評估能力,同時保持開源、可重現和低成本。
https://arxiv.org/pdf/2310.08491.pdf
這篇文章探討了如何在沒有昂貴GPU的情況下,利用各種開源軟體元件來進行「LLM as Judge」的評估。在當前快速發展的AI領域中,成本和評估往往不像新模型的發表那樣受到關注,但它們對開發者和企業應用AI系統至關重要。眾所周知,預訓練LLM的成本極高;而像OpenAI這樣封閉原始碼的LLM使用起來也很昂貴。
評估不僅對了解模型的效能表現至關重要,也有助於確定哪種模型最適合特定場景。當LLM被用來評估其他模型時(即所謂的LLM as Judge),評估本身的成本也可能很高。雖然推論優化技術也適用於LLM Judge,但似乎沒有多少人對此感興趣。
Justine Tunney推薦了一篇博文，我認為非常值得一看:
https://blog.mozilla.ai/local-llm-as-judge-evaluation....../
本文作者檢視了幾個軟體元件如何組合在一起,實現了無需昂貴GPU的LLM as Judge評估。這些元件在設計時就強調了使用者控制、開源特性和互通性。
其中包括了用於LLM as Judge評估的開源模型Prometheus(所以擔心LLM工程師造出了AI異形?)、作者參與的mzai團隊開發並開源lm-buddy工具(用於擴展微調和評估任務)以及Mozilla創新項目llamafile(將LLM打包成單一可攜式檔案)。作者展示了這些元件如何協同運作,在相對便宜的硬體上評估LLM,以及他們如何衡量評估模型本身的性能來做出明智的選擇。
作者特別欣賞Firefox的一個功能:在網址列輸入「moz://a」,就會自動跳轉到Mozilla的宣言。Mozilla誕生自開源理念,其宣言談到了對AI演算法的控制權和用戶體驗的原則。在目前由封閉的AI即服務平台主導的市場中,這一點格外重要。
Mozilla的宣言引起了作者的共鳴,讓他重新審視這些原則在日益被AI演算法影響的現代網路中的意義。如果將「網際網路」替換為「AI演算法/框架」,Mozilla宣言中的原則仍然非常貼切。舉例來說,可以解讀為:
- 個人應該能主導AI演算法,塑造自己的使用體驗
- AI框架的效能取決於互通性、創新力和去中心化的參與
- 自由開源軟體能推動AI成為公共資源
若專注在LLM這個AI的子領域,就能看出這些原則在目前由封閉、中心化AI即服務平台主導的市場中有多麼重要。事實上,我們已經看到更開放的替代方案如雨後春筍般湧現。
儘管業界可能還未形成對開源AI的共識,但新模型持續以開源授權的方式發布在HuggingFace上。它們附上了預訓練的權重,可以直接使用或進行微調。有時也會發表論文,詳述模型訓練和使用的資料。但考慮到研究和再現性而分享訓練代碼、檢查點和訓練資料的模型非常少。這少數的例子包括BLOOM、Pythia系列、TinyLlama和Olmo。
在企業應用方面,也出現了類似的趨勢,企業傾向選用小型、開放、專門的模型,而非大型封閉的模型。Sarah Wang和Shangda Xu的報告指出,成本只是企業做出這種選擇的原因之一,且不是最重要的。其他原因包括控制力(企業既要確保資料安全,也要能理解模型的行為)和客製化能力(針對特定用例微調模型)。
關於微調,Predibase工程師在最近的LoRA Bake Off簡報中展示,小型開源微調模型在特定任務上的表現可以超越GPT-4。雖然理論上GPT-4也能微調,但OpenPipe等新創公司能籌得資金,正是因為企業需要控制力和客製化,要「以自己的微調模型取代GPT-4」。
當然,要取代一個模型,光有互通性還不夠,我們需要評估模型,比較它們的性能,才能選出最適合的那一個。
作者在mzai從事評估任務時(包括NeurIPS LLM Efficiency Challenge和內部專案),直接體驗到離線和線上模型性能(或用Context.ai指南中的說法:模型性能和產品性能)經常有重大差異,前者常無法預測後者。
離線評估是在模型上進行,使用公認可預測模型特定任務表現的學術基準和指標。線上評估則是針對基於LLM的產品,通常以人工方式在客製化資料集上進行,目的是評估回應品質,包括幻覺程度、品牌語調契合度、面對對抗性輸入的反應等更符合產品本身的指標。
這種「離線-線上落差」在其他領域也很常見。有趣的是,它在社交網路的推薦系統中尤其嚴重。
為了縮小這個落差,「LLM as Judge」的方法應運而生。它利用另一個LLM來評估你的LLM應用的回應。假設經過適當訓練,它們比離線評估更能貼近線上性能,但成本又比人工線上評估低。
和其他基於LLM的應用一樣,這方面也有多種仰賴GPT-4的工具。比方說,Anyscale的Goku Mohandas和Philipp Moritz撰寫的這篇文章,記錄了一個作者很欣賞的GPT-4評估流程。作者之所以喜歡,是因為它有條不紊地分解每個步驟,附上了參考代碼,並有詳盡的結果分析。
值得慶幸的是,業界也陸續推出了依賴開源模型、性能媲美「GPT-4 as Judge」、但價格只是零頭的替代方案。Prometheus和Ragas就是兩個例子,可分別用於評估基於LLM和基於檢索增強生成的系統。本文將聚焦在前者。
Prometheus是個完全開源的LLM(在HuggingFace以Apache 2.0授權發布),作為長篇內容的評估者,其能力與GPT-4不相上下。它能依照使用者提供的評分規則,評估任何給定的長篇文字。實驗顯示,它與人類評估者的皮爾森相關係數高達0.897。介紹Prometheus的論文已被NeurIPS 2023的Instruction Workshop所接受,而且已有後續研究瞄準視覺-語言模型。
作者以一張圖高度概括了Prometheus評分的運作方式。實務上,餵給Prometheus的每個提示(prompt)都由四部分組成:
1. 要評估模型所接收的指示(instruction)
2. 該模型的回應
3. 一個得分最高的參考答案
4. 自訂的評分規則,描述回答指示所需的主要面向
作者以方塊展示了一個來自Prometheus專案中mt_bench資料集的例子。這個資料集利用了MT Bench Human Judgements資料,後者收集了六個模型針對一系列開放式問題所生成的回答,並由人類專家評分。
當Prometheus收到這樣的提示,它的回應會包含針對所提供回答的評估意見(以自然語言表達),以及一個符合評分規則範圍的數字分數。
Prometheus的程式碼、論文和訓練資料都可以在GitHub取得。安裝必要的相依性,在run.py中填入提示模板後,就可以從命令列執行範例評估。此外,專案也提供了完整的基準測試腳本,可透過TGI調用模型服務來執行。
值得注意的是,Prometheus是Llama-2-Chat-13B模型的微調版本,因此非常吃記憶體:它需要GPU才能運作(原版模型需要超過70GB RAM的高階GPU),這是在評估模型所需的硬體之外,還得額外考量的成本。為了克服這個限制,作者展示了如何執行此模型的量化版本,並評估它在與原版模型輸出的相關性方面的性能。
在NeurIPS LLM Efficiency Challenge期間,作者體認到擁有簡單且可擴展的LLM微調和評估系統至關重要。挑戰預設提供的工具(微調用LitGPT,評估用HELM)可滿足個別提交的需求。然而,作者同時微調和評估多個模型的經驗,凸顯了一些可以改進和通用化的機會。
具體來說,作者想要:
- 建立可在本機筆電或遠端叢集上執行的任務流程;
- 提供實驗追蹤功能,讓同個實驗中的不同任務能共享成品和設定參數,並透過記錄追溯成品的來源;
- 讓任務規格保持簡單,方便使用者建立新規格;
- 讓不同元件透過開放或事實標準互通訊息。
LM Buddy是作者在mzai內部打造,並已開源到GitHub的框架,就是為了提供以上這些功能。在為開發者提供平台,去建置專用且值得信賴的AI代理的路上,這是一個核心元件,作者決定及早分享、公開開發。它目前提供了利用抽象化任務來微調和評估LLM的能力。
雖然還在早期階段,該函式庫已具備一些有用的特色:
- 基於命令列介面和YAML設定檔,提供簡單的任務介面
- 透過Weights & Biases進行輸入/輸出成品的追蹤
- 能在本機執行任務,也能利用Ray輕鬆擴展到遠端叢集
這個套件目前提供兩種任務類型:
1. 微調任務:利用HuggingFace的模型和訓練實作,以及Ray Train來擴展運算
2. 評估任務:可用Ray來擴展,目前仰賴lm-evaluation-harness進行離線評估,以及Prometheus和Ragas進行LLM as Judge評估
當需要進行推論時,不論是要評估的模型或是作為LLM Judge,作者都使用vLLM提供模型服務,並確保他們使用和開發的函式庫都支援OpenAI API。
作為LM Buddy任務的Prometheus評估,會讀取一個包含要評估提示的輸入資料集,將那些提示傳送給透過vLLM提供服務的LLM Judge,輸出的是另一個版本的資料集,內容增加了Prometheus的意見和分數。使用原版Prometheus模型時,要為它分配一個GPU,然後從(可能很多台)只有CPU的機器執行評估任務。
有沒有辦法讓終端使用者做起來更簡單呢?
llamafile旨在「將LLM聊天機器人的所有複雜性,壓縮到單一個可在六種作業系統上執行的檔案中」。它利用了兩個開源專案:llama.cpp專注於在消費級硬體上執行LLM,Cosmopolitan則是將C語言程式編譯成可在多種作業系統上執行的通用執行檔。
llamafile讓單一檔案在筆電上執行模型:透過簡單的Flask中介層代理llama.cpp自己的伺服器,可以透過OpenAI相容的API存取。多虧了Justine Tunney最近為llamafile改進的矩陣乘法核心,提示處理速度大幅提升,表現優於單獨使用llama.cpp和ollama。
這對作者的意義是,(1)可以無縫地將vLLM提供的Prometheus服務替換為llamafile版本,(2)它可以在各式各樣的硬體設定上執行。
llamafile的GitHub專案已經提供了多種模型可供下載,而HuggingFace最近也開始正式支援llamafile格式的模型。在論文作者做實驗之前,還沒有llamafile格式的Prometheus模型,所以他必須自己建構。步驟大致分為(1)編譯llamafile、(2)下載GGUF格式的Prometheus模型、(3)把所有東西打包在一起。
一旦執行了Prometheus的llamafile,它會將模型載入記憶體並開啟一個包含聊天UI的瀏覽器分頁。可以開始聊天,測試一切運作正常(畢竟Prometheus模型就是個微調版的Llama)。
由於lm-buddy任務要求透過OpenAI相容的API提供Prometheus服務,可以執行幾個命令讓llamafile相容於API。這會啟動一個在本機監聽指定URL的伺服器。現在只需將prometheus.inference.url設定為此URL,就能使用Prometheus的llamafile版本進行評估了。
報告分享了一些實驗結果。首先是量化對品質的影響。和TheBloke在HuggingFace上發布的其他GGUF格式模型一樣,他們的Prometheus頁面有個Provided files區塊,提供了根據量化程度而有所不同的模型變體。
量化是一種透過使用更低精度的資料類型來表示模型權重和啟動值,藉此減少記憶體需求和計算成本的技術。使用的位元數越少,模型就越小,能在更便宜的硬體上執行;但同時在近似原始模型權重時的品質也會變差,影響整體表現。
TheBloke的表格在這方面很有幫助,除了顯示用於量化的位元數和整體模型大小外,還有個「use case」欄位,以高層次描述了模型的品質。為了讓結果更具解釋力,衡量了不同量化程度的模型在評分上與原版模型的一致性。
他們取了Vicuna基準,用lm-buddy執行了三次評估,分別使用vLLM提供的Prometheus服務和本機的量化版llamafile模型,然後計算它們平均分數的皮爾森相關係數(PCC)。PCC介於[-1, 1]區間,數值越高代表越相關。
結果顯示,用於量化的位元數越多,llamafile模型與原版越一致,PCC值也越高。雖然Q8模型與原版最相似,但Q5的PCC值也相當高,卻只需16GB RAM。
接著測試了Prometheus和llamafile在簡單的自訂場景中的一致性。在RAG情境中測試了不同模型,從預定義問題生成模型答案,然後用Prometheus進行人工評估和自動評估,使用自訂評分規則,分別執行原版模型和llamafile版本。
結果顯示,手動標註與原版Prometheus模型的PCC為0.73,顯示兩種評估整體上是一致的。原版Prometheus模型與llamafile版本的PCC則高達0.9。
最後是評估速度和成本的比較。作者在配備A100 GPU的機器上使用原版Prometheus模型,以及在不同架構上使用基於特定llamafile的Prometheus,執行了相同的Vicuna基準測試。該基準包含320個提示,各自評估3次,總計960個HTTP請求。
要判斷哪種模型最符合成本效益並不容易。它需要綜合考慮不同變數,包括絕對成本(不只是每小時價格,在該硬體上執行特定評估任務需要多少小時,也是相關資訊)和隨需、預留或自備硬體的價格(即需要執行多少次這樣的推論)。視需求而定,使用隨需GPU或買台新筆電可能會便宜許多。
本地LLM as Judge評估是許多開放專案共同努力的成果。時間軸上展示的專案雖然只是其中一部分,但已足以說明讓作者的工作成為可能的祕方:這些專案不僅要開源,更要在設計之初就考慮互通性。從打造可攜式執行檔到定義發布LLM的標準二進位格式,從分享預量化模型到以通用API提供模型服務,所有這些努力都是為了鼓勵軟體模組化和人與人之間的協作。
Prometheus只是眾多LLM as Judge方法之一,更重要的是,LLM as Judge本身並非萬靈丹:畢竟我們還是在跟LLM打交道!其表現取決於提供的評分規則品質,以及我們用作評估者的模型之泛化能力。還有個非常重要的問題:「誰來審核審核者?」這裡只有將不同模型的表現與一些基準做了部分比較。儘管我們最信賴的還是人類做的ML評估,展示一些我們可以試驗的開放、平價的人工評估替代品仍然重要:不論是為了在特定使用案例中做出明智的模型選擇,或是為了在模型品質和成本間取得最佳平衡。
就像...臉書上有位朋友懷疑這篇文章是不是GPT自動生成的...其實我還真的很希望是, 但願AI不但會歸納也能做複雜推理, 考慮我也是Justine的sponsor之一, 這麼做似乎對她不敬。內容已經重新校稿。
沒有留言:
發佈留言