評估LLMs是一個複雜的過程，因為與傳統軟體開發不同，LLMs的結果不可預測，缺陷也無法像邏輯可以歸因於特定程式碼塊那樣進行除錯。LLMs是一個黑盒，具有無限可能的輸入和輸出。
然而，這並不意味著傳統軟體測試中的概念不能應用於測試LLMs。單元測試構成了功能測試、效能測試和可靠性測試，它們共同構成了對LLM的迴歸測試。
傳統測試策略（LLM應用策略）
單元測試（每個節點）
單元測試指的是測試應用程式中最小可測試部分，對於LLMs來說，這意味著根據一些明確定義的標準來評估LLM對給定輸入的響應。
例如，對於一個單元測試，目的是評估由LLM生成的摘要的質量，評估標準可以是摘要是否包含足夠的資訊，以及是否包含來自原始文字的虛構。對評估標準的評分通常由所謂的LLM評估度量來完成。
功能測試（每個工作流）
對LLMs進行功能測試是指在特定任務上評估LLMs的表現。與傳統的軟體功能測試不同（例如，透過測試整個登入流程來驗證使用者是否能夠登入），LLMs的功能測試旨在評估模型在特定任務（例如文字摘要）範圍內的各種輸入下的表現能力。換句話說，功能測試是由特定用例的多個單元測試組成的。將單元測試組合在一起進行功能測試
迴歸測試（標準用例迴歸）
迴歸測試是指每次進行迭代時，都對LLM進行相同的測試用例評估，以確保不會引入破壞性變更。使用量化的LLM評估指標進行LLM評估的優點是，我們可以明確地設定閾值，定義什麼是“破壞性變更”，並監控LLM在多次迭代中的效能變化。
多種功能測試可以構成迴歸測試的一部分。例如，我可以評估LLM在進行摘要和程式碼生成方面的能力，對於迴歸測試，我可以衡量每次迭代時它是否仍然能夠執行這些任務。
效能測試（首token時間等）
當我們說效能測試時，我們並不是指測試LLM是否能夠執行給定的任務，而是指一些通用的效能指標，比如每秒生成的詞數（推理速度）和每詞的成本（推理成本）。效能測試的主要目的是最佳化成本和延遲。
需要注意的是，效能測試也是迴歸測試的一部分。
可靠性測試（需求功能之外的處理）
這是唯一一種與傳統軟體開發中常見的測試方法不同的測試方式。可靠性測試是一種理念，即測試LLM在負可靠性人工智慧（Responsible AI）指標如偏見、有毒性和公平性方面的表現，而不管當前的任務是什麼。例如，LLM應該在被要求總結一篇有偏見的新聞文章時不這樣做。
資料驅動測試（可自動化）
另一種思考LLM測試的方法，而不是像上面描述的那樣從傳統角度進行測試，而是基於指標標準來測試LLM系統。讓我們來看看最常見的三個指標。
準確性測試（標準用例）
其中最直接的一種方法就是準確性性測試。準確性測試就像傳統監督式機器學習中的典型測試集，即在給出整個訓練資料集的情況下，我們保留一小部分資料，看看新訓練的模型是否能夠根據目標標籤給出正確的答案。
相似度測試（相似問題相似答案）
與準確性一樣，相似度也不是傳統NLP指標能夠輕易評估
虛構性測試（反向case，LLM不虛構回答）
最後，還需要對虛構性進行測試，並且有多種方法可以實現這一點。虛構性可以作為無參考或基於參考的度量標準，其中需要一個“真相”來確定LLM輸出的實際準確性。
你可能也注意到我使用了“準確性”這個詞。然而，虛構性應該有自己的測試方法，因為虛構性的輸出並不一定就是事實錯誤的。這讓你感到困惑了嗎？想象一下，如果你的LLM輸出的資訊不在其訓練資料中。雖然在現實世界中它可能是事實正確的，但它仍然被認為是虛構性。
CI/CD中的自動化測試
你需要做的一件事是，為LLM的每次變更（無論是你或你的團隊成員所做的變更）提供自動化測試方式。在傳統的軟體開發中，尤其是在團隊環境中，自動化測試對於CI/CD流程至關重要，可以防止未被注意到的破壞性變更。
用模型來測試模型
對於這種大模型場景或者生成式場景來說， 測試人員不可能列舉出所有的問題和答案，這個太不現實了。
雖然我們可以爬取到線上使用者提的所有問題， 但是我們沒辦法把他們作為測試資料， 因為這些問題的答案需要人工來判斷。所以測試人員能列舉的情況是有限的。
用一個成熟的模型經過微調後來滿足我們的場景。
需要注意的是這種方式不能代替人工測試的，它只能是一種輔助手段，用模型來幫助我們挖掘潛在的問題（畢竟人的精力有限，不可能測試到那麼多的樣本），所以人工測試，仍然是非常重要的手段。 我們一般可能人工測試 1000~5000 個樣本， 機器測試 1W 個或者 10w 個樣本甚至更多，用這樣的策略讓人和機器一起去挖掘潛在的問題。