一、結(jié)論寫在前面

論文標題：A Software Engineering Perspective on Testing Large Language Models: Research, Practice, Tools and Benchmarks

論文鏈接：??https://arxiv.org/pdf/2406.08216??

LLMs正迅速成為無處不在的工具，既是獨立工具，也是當前和未來軟件系統(tǒng)的組件。為了在2030年的高風險或安全關(guān)鍵系統(tǒng)中使用LLMs，它們需要經(jīng)過嚴格的測試。軟件工程（SE）對機器學(xué)習（ML）組件和基于ML的系統(tǒng)測試的研究已經(jīng)系統(tǒng)地探討了許多主題，如測試輸入生成和魯棒性。

論文認為，關(guān)于LLM測試相關(guān)的工具、基準、研究和實踐者的觀點也需要進行類似的組織。    

為此，本文提出了一種愿景，通過軟件工程中的機器學(xué)習測試分類法，組織和統(tǒng)一研究與工業(yè)實踐中對LLM測試的努力。論文進行了初步研究，探討了當前的研究方法、開源基準、測試工具以及實踐者的在線討論。

論文的研究結(jié)果回答了RQ1：大部分LLM測試研究尚未融入公開可用的工具中以及基準測試，引領(lǐng)未來的工程和研究方向。關(guān)于對RQ2的回答，論文注意到在線開發(fā)者并未明確提及軟件工程（SE）或機器學(xué)習（ML）測試主題，但正在將SE測試技術(shù)融入其實踐中。盡管初步，這些結(jié)果顯示出利用如圖1所示的分類法組織現(xiàn)有方法、識別差距和未來方向、促進研究者和行業(yè)實踐者之間溝通與合作的良好前景。

論文的研究存在許多局限性：論文不僅只分析了部分基準、工具和在線討論論壇，而且軟件工程的快速變化將很快使得論文基于2024年3月的快照及其結(jié)論過時。

二、論文的簡答介紹

2.1 論文的背景

鑒于LMs作為軟件系統(tǒng)組件的使用日益增加，如何指定這些系統(tǒng)的預(yù)期屬性（例如，正確性或公平性）并有效地測試它們變得非常重要。鑒于LMs迅速成為關(guān)注焦點，LLM測試方法和實踐中的成功和缺口尚未以清晰、原則性和全面的方式進行系統(tǒng)化，導(dǎo)致在實踐中應(yīng)用它們的困難。

論文的愿景。當前關(guān)于LLM測試的研究和工業(yè)實踐應(yīng)通過軟件工程（SE）的視角進行組織，即圍繞SE中機器學(xué)習測試的主題組織現(xiàn)有方法。這種組織應(yīng)有助于識別差距并促進利益相關(guān)者之間的溝通，包括LLM測試研究人員、工具開發(fā)者及用戶。最終，這應(yīng)有助于到2030年，在高度風險領(lǐng)域中更安全地使用LLMs。

為了驗證論文的愿景，論文進行了一項初步研究，探討了當前的LLM測試研究方法、基準、測試工具及工業(yè)實踐，旨在回答兩個研究問題：(RQ1) 當前開源基準、工具及在線討論涉及的LLM測試研究主題在機器學(xué)習測試分類法中的覆蓋程度如何？(RQ2) 哪些剩余的差距阻礙了實踐者有效地應(yīng)用LLM測試研究？    

圖1: SE中的ML測試分類[51]，增加了LLM特定主題

2.2 LLM測試研究

這里論文通過圖1中的LLM測試研究擴展了論文的分類法。由于基于LLM的研究最近急劇增加，論文選擇了兩篇最新的關(guān)于LLM評估的綜合文獻綜述。    

由LLM研究涵蓋的ML測試主題。LLM研究已經(jīng)探討了幾個ML測試主題，如圖1中藍色輪廓所示。對于測試工作流程，基于LLM的應(yīng)用程序通常通過基準、合成數(shù)據(jù)和人工注釋進行評估，這些對應(yīng)于測試輸入和oracle生成。與ML測試不同，現(xiàn)有的LLM評估工作主要集中在學(xué)習程序測試上，即測試訓(xùn)練過的LLMs，并且主要針對其特定應(yīng)用進行測試，例如自然語言處理、推理、醫(yī)療用途等。

LLM研究探討的測試屬性包括魯棒性、公平性和可信度。已經(jīng)表明，LLMs可以制造聽起來合理的虛假信息，即“幻覺”。因此，正確性測試還檢查模型輸出是否嚴格遵循事實信息。為此開發(fā)了幾種技術(shù)，包括事實一致性測試、基于不確定性的測試和黑盒測試。在機器翻譯中，幻覺也是一種研究過的故障模式，“其中翻譯在語法上是正確的，但與源句無關(guān)”。這個定義與LLMs上下文中的幻覺略有不同，其中沒有源句，生成文本的真實性是主要關(guān)注點。

新增條目：LLM特定主題。除了“通用”ML測試主題研究外，在LM測試中還探索了LLM特定的主題，如圖1中藍色文本所示。首先，由于LLMs的能力適合于大量任務(wù)，LLMs已被測試其正確性、魯棒性、公平性、可信度。此外，LLMs已被部署在包括醫(yī)學(xué)和社會科學(xué)在內(nèi)的各種其他領(lǐng)域，或其他特定應(yīng)用，如個性測試[4]。

結(jié)論。針對RQ1，論文的初步審查表明，多個軟件工程（SE）測試主題與大型語言模型（LLM）測試研究相關(guān)，但尚未得到充分關(guān)注。

效度威脅。論文僅查看了兩篇文獻綜述，盡管它們在撰寫時是全面且近期的。

2.3 LLM評估基準

在LLM研究中，評估主要依賴于基準。流行的LLM如GPT-4和Gemini使用多個基準來傳達和比較它們在廣泛任務(wù)和領(lǐng)域中的性能。這里論文分析了OpenCompass GitHub倉庫，這是一個包含76個公開可用基準的流行集合，旨在識別未充分探索的LLM測試主題。OpenCompass被選為GitHub上搜索“l(fā)lm evaluation”時星標最高的LLM基準倉庫。

基準覆蓋。研究的基準包括通用基準，例如為通用語言理解開發(fā)的SQuAD2.0 ，特定任務(wù)的基準，例如為醫(yī)療應(yīng)用開發(fā)的CMB ，以及涉及圖像和文本的多模態(tài)基準，例如用于視覺語言模型的MMBench 。    

在76個基準中，有74個用于測試模型在不同能力上的正確性，包括數(shù)學(xué)推理、內(nèi)容摘要和代碼生成 。剩余的兩個基準，CrowS-Pairs 和 AdvGLUE ，分別測試模型的公平性和魯棒性。某些基準，如SciBench 、HumanEval 和 CMB ，可用于評估模型與特定應(yīng)用場景的相關(guān)性。集合中沒有專門針對隱私、安全性、效率或可解釋性的基準。某些應(yīng)用，例如開放式聊天機器人，要求LLM在廣泛的任務(wù)上進行測試，以查看其響應(yīng)情況。OpenCompass中的復(fù)合基準，如MMBench 和 SummEdits ，是不同任務(wù)特定基準的集合，旨在解決這一挑戰(zhàn)。通過提供一致的測試框架 ，復(fù)合基準允許實踐者和研究人員理解LLM模型與開放式應(yīng)用的相關(guān)性。

結(jié)論。論文對OpenCompass的分析確定，幾乎所有基準都致力于測試模型的正確性和與特定應(yīng)用領(lǐng)域的相關(guān)性。盡管需要更多工作來增加其采用和覆蓋范圍，但OpenCompass之外確實存在用于隱私、安全性、魯棒性、效率、可解釋性和公平性的基準。為了回答RQ1，基準本身充分覆蓋了ML測試分類法中的少數(shù)主題。

有效性威脅。論文僅考慮了一個基準集合。它是GitHub上迄今為止最受歡迎的，因此代表了當前針對LLM測試的基準實踐狀態(tài)。OpenCompass專注于通用LLM能力，因此未考慮專注于特定用例的基準，如CodeXGLUE [24]。

2.4 開源測試工具

開源工具為實踐者提供了接觸研究中確立的測試技術(shù)的機會。這里論文將開源工具的功能與論文的分類法（圖1）中概述的主題相對應(yīng)，以確定在實踐中應(yīng)用LLM測試研究的差距。

工具選擇。為了識別實踐者常用的開源測試工具，論文在Github上搜索了“l(fā)lm evaluation”，并根據(jù)GitHub星數(shù)對結(jié)果進行排名，這表明了實踐者的興趣和使用情況。論文僅考慮專注于測試和評估的倉庫，排除了模型庫、運行基準測試的工具以及其他沒有突出測試包的LLM倉庫。論文還限制了分析范圍，僅限于適用于各種LLM部署（如總結(jié)、問答和文本生成）的文本輸入、文本輸出應(yīng)用程序的通用工具。搜索結(jié)果顯示有八個LLM測試倉庫擁有超過1000顆星和適當?shù)奈臋n，其中三個僅包含其他倉庫實現(xiàn)的功能，因此被排除。表1列出了選定的五個工具及其所涉及的分類法主題（見圖1）。

開源工具的優(yōu)勢。所有研究的工具都解決了測試預(yù)言的識別和正確性測試問題，如圖1中綠色部分所示。測試預(yù)言一直是許多開源工具的共同關(guān)注點，包括正則表達式或其他簡單的字符串匹配函數(shù)[7, 34]。    

此外，大型語言模型（LLMs）或檢索增強生成（RAG）系統(tǒng)已被用作測試預(yù)言來測試LLMs，例如“LLM作為評判者”或“GEval”。對測試預(yù)言的關(guān)注源于LLMs的輸入和輸出由不受限制的自然語言文本組成。這使得識別正確輸出的任務(wù)轉(zhuǎn)變?yōu)樽匀徽Z言理解挑戰(zhàn)，涉及解釋輸出是否傳達了預(yù)期的意義。在正確性方面，根據(jù)系統(tǒng)要求，LLM的輸出可能因多種微妙的原因而被視為不正確。例如，由于禮貌和事實準確性對客戶服務(wù)LLM的正確性都很重要，因此既有效又粗魯?shù)捻憫?yīng)，或禮貌但錯誤的響應(yīng)都被視為不正確。已經(jīng)實施了測試來檢查響應(yīng)是否包含特定的、事實性的信息且沒有幻覺。此外，還有專門用于檢查抽象寫作屬性的測試，如“簡潔”、“無爭議”或“敏感”。最后，有測試檢查輸出是否符合指定的結(jié)構(gòu)和格式，例如JSON。

開源工具的差距。幾個研究主題未被任何研究過的工具解決。論文在表1中用空圈表示它們。其中，模型相關(guān)性已通過基準測試解決。盡管具有數(shù)百萬參數(shù)的LLMs的推理非常昂貴，但沒有任何調(diào)查的工具實現(xiàn)了優(yōu)先處理測試或跳過冗余測試的基礎(chǔ)設(shè)施。

因此，對于LLMs的測試簡化和優(yōu)先級排序仍然是未來研究和發(fā)展的一個有前景的領(lǐng)域。此外，LLMs的原始訓(xùn)練語料庫通常對LLM實踐者來說是未知的，并且據(jù)推測規(guī)模巨大，這為數(shù)據(jù)、學(xué)習程序和框架測試帶來了挑戰(zhàn)。盡管如此，LLM實踐者和研究人員仍然可以通過測試調(diào)試LLMs并通過微調(diào)修復(fù)錯誤，無論是通過API還是本地使用定制的語料庫和學(xué)習程序。然而，這些工作流程并未被論文研究的任何工具實現(xiàn)，因此是未來工作的重要方向。

結(jié)論。通過將開源工具映射到分類法中的主題，論文發(fā)現(xiàn)測試預(yù)言的識別和正確性得到了開源工具的良好解決，盡管對于不同任務(wù)的不同測試預(yù)言之間的比較尚未進行。此外，大多數(shù)其他ML測試主題仍未得到解決，即調(diào)試和修復(fù)、測試優(yōu)先級和簡化、測試充分性生成、框架測試、學(xué)習程序測試、數(shù)據(jù)測試以及模型相關(guān)性。為了回答RQ1和RQ2，開源工具僅覆蓋了ML測試分類法中主題的一小部分，這種工具的缺乏直接阻礙了從業(yè)者有效應(yīng)用LM測試研究。

效度威脅。論文的工具調(diào)查僅包括了當今最流行的五種工具，這些工具是通過在GitHub上的一次搜索查詢選出的，因此顯然是不完整的。此外，工具的功能完全基于文檔確定，這可能與徹底的實驗和代碼審查相比提供有限的見解。  

2.5 LLM測試的實踐

這里論文通過分析在線論壇上與測試相關(guān)的討論，來考察LLM測試在實踐中的應(yīng)用。通過比較討論內(nèi)容與論文的分類法和測試工具的主題，論文識別出當前測試實踐中的潛在差距。

數(shù)據(jù)。論文專注于Reddit，這是最受歡迎的在線論壇之一，因為其子論壇是廣泛使用且面向廣泛受眾的問題導(dǎo)向型論壇。

具體而言，論文選擇了子論壇r/LocalLlama，因為它專注于LLMs且在該網(wǎng)站上頗受歡迎——自2023年3月創(chuàng)建以來，它已成為論壇上最受歡迎的子論壇之一，排名位于前五百分位。從Academic Torrents[39, 48]收集了自2023年3月至2024年1月的子論壇提交內(nèi)容及其相應(yīng)評論。為了描述平臺上的對話，論文將提交內(nèi)容和評論結(jié)合起來，使得分析單元如表1所示：涵蓋ML測試不同主題的開源工具。2024年3月分析的工具，覆蓋范圍基于工具的官方文檔。這是一個子論壇帖子。最終數(shù)據(jù)集包含15,209個提交和11,377條評論，涵蓋了該子論壇的11,344個帖子（提交及其對應(yīng)的評論）。

表1：涵蓋ML測試不同主題的開源工具

測試相關(guān)關(guān)鍵詞。為了探究來自不同背景的子論壇用戶如何討論大型語言模型（LLM）的測試，論文首先在數(shù)據(jù)中搜索與軟件系統(tǒng)測試、機器學(xué)習、LLMs以及表1中列出的測試工具名稱相關(guān)聯(lián)的關(guān)鍵詞。這些關(guān)鍵詞來源于相應(yīng)的文獻，因此與圖1中提出的分類法有所不同。表3報告了在數(shù)據(jù)中發(fā)現(xiàn)的測試特定關(guān)鍵詞的頻率和百分比。與測試相關(guān)的關(guān)鍵詞大約出現(xiàn)在總帖子的0.8%中。

接下來，“單元測試”（N=38）和“毒性”（N=29）是最常被討論的測試關(guān)鍵詞，而其他傳統(tǒng)軟件（例如，“測試預(yù)言”（N=0），“功能測試”（N=0））和機器學(xué)習（例如，“對抗性攻擊”（N=5），“對抗性示例”（N=0））測試關(guān)鍵詞在數(shù)據(jù)中出現(xiàn)的頻率不到0.05%，如果存在的話。表1中的測試工具同樣在子論壇用戶中不受歡迎，總共出現(xiàn)在不到0.02%的數(shù)據(jù)中。    

討論分析。為了更好地刻畫與測試相關(guān)的對話，論文進行了語義主題分析，以識別和分析包含測試相關(guān)關(guān)鍵詞的數(shù)據(jù)中的模式、主題和見解。這些對話的質(zhì)量在帖子之間有所不同，范圍從對測試的一般討論到實際操作中的特定方法。論文注意到，前者在“毒性”方面尤為明顯，這在討論有毒或偏見的模型輸出和新發(fā)布模型的性能報告中經(jīng)常被提及。

相比之下，關(guān)于單元測試的討論顯得更具操作性，許多用戶報告了他們個人開發(fā)的測試，用以評估模型或文獻中報告的測試。盡管單元測試在子論壇上相對流行，但似乎缺乏關(guān)于如何實際測試大型語言模型（LLMs）的一致指導(dǎo)或步驟。例如，在回應(yīng)一個帖子“提示工程似乎像猜測工作 - 如何正確評估LLM應(yīng)用？”時，一些用戶指出使用單元測試等方法，而其他用戶則報告了他們獨立開發(fā)的流程。例如，表2的A面板中引述了一種結(jié)合用戶評估的組合測試方法。相反，B面板突出了一種由另一用戶開發(fā)的層次化方法，該方法似乎借鑒了軟件工程。

表2：來自r/LocalLama的示例引述

結(jié)論 在r/LocalLlama上觀察到的許多方法的新穎性表明，軟件工程（SE）和機器學(xué)習（ML）方法在測試大型語言模型（LLMs）方面具有實用性，同時也揭示了理論與實踐之間可能存在的差異。

除了明確借鑒單元測試和集成測試等方法來測試LLMs外，用戶提出的方法具有即興和實驗性質(zhì)。有趣的是，論文注意到討論中并未明確引用SE或ML術(shù)語。因此，所述的測試方法與學(xué)術(shù)文獻及表1中的測試工具存在差異。論文的研究結(jié)果顯示，研究與實踐之間存在較大鴻溝，這強調(diào)了研究者與實踐者之間加強溝通的必要性。    

效度威脅。對r/LocalLama子論壇的分析是對LLM測試用戶討論的初步考察。具體而言，分析中使用的搜索詞有限，可能導(dǎo)致遺漏與測試討論相關(guān)的關(guān)鍵字。此外，子論壇上的用戶群體多樣，可能不完全代表活躍在測試領(lǐng)域的專業(yè)人士，從而影響研究結(jié)果的普遍性。

表3：數(shù)據(jù)中關(guān)鍵詞的頻率與比例

本文轉(zhuǎn)載自 ??AI帝國??，作者： 無影寺