LLM 輸出變異:當單一目標重試奏效時
在相同輸入下,45% 的 LLM 輸出會有所不同。本文將說明如何將此差異轉化為一次性的重試,既能恢復品質,又不會耗盡重試預算。
重試一個已經返回有效答案的 LLM 呼叫聽起來很浪費。大多數時候確實如此。但我們在一個生產環境的翻譯流程中測量到了一些數據,這改變了我們的想法:當我們用相同的模型、相同的提示和相同的輸入重新生成 55 個已接受的輸出時,其中有 25 個結果變得不同。對於理應已確定的答案,這意味著 45% 的變異率。本文旨在探討一個特殊情況,即這種變異成為一種資源:一種能恢復真正品質的單次、有條件限制的重試,以及在開啟此功能前,你必須設計時加以規避的兩種失敗模式(結果覆蓋和預算耗盡)。
測量結果:在輸入相同的情況下,45% 的輸出結果發生了變化
我們討論的這個流程是用於填充一個多語言的術語詞彙庫。一個批次產生器會請求兩個大型語言模型(LLM)翻譯醫學美容術語,一個共識步驟會比較兩者的翻譯,並透過反向翻譯檢查來驗證其意義。通過所有關卡的輸出會被儲存為已確認的條目。
在一次審核中,我們刪除了 55 個已確認的中文條目,然後再次執行完全相同的生成任務。提示詞、模型、溫度(temperature)都沒有改變。第二次執行的結果只與第一次的 30 個條目相符。另外 25 個條目則回傳了不同的表面形式。
這些差異並非隨機雜訊。它們可分為三類:
- 格式漂移:
capitalization(大小寫)、空格以及同義詞層級的替換,任何正規化工具都會將其視為相同。 - 真正的改善:第二次執行產生了某個設備在當地市場的既定名稱,而第一次執行時則保留了英文品牌名稱未作翻譯。
- 真正的退步:第二次執行捨棄了正確的當地名稱,而退回使用英文品牌名稱。
第二和第三類是值得關注的。它們是同一現象,但指向相反的方向。對於長尾的品牌術語,模型無法穩定地知道其在當地市場的名稱。它有時會產生正確名稱,有時則不會,兩種情況發生的機率都相當可觀。從該分佈中抽取的單一樣本,並非模型的最佳答案。它只是一次抽樣結果。
一旦你將生成過程視為從一個機率分佈中抽樣,「重試」這個問題的樣貌就改變了。問題不再是「我應該相信模型嗎」,而是「對於哪些輸出,第二次抽樣的結果可能比第一次好,以及我該如何以低成本的方式識別出它們?」
僅在可檢查的屬性違規時重試
重試所有內容會使您的成本加倍,但收益幾乎為零:對於 30 個穩定的條目,第二次抽取會回傳相同的東西,而對於漂移的條目,您無法知道哪次抽取更好。盲目重試會將變異轉換為流失。
解決方法是找到一個具有以下特性的屬性:
- 無需另一次 LLM 呼叫即可確定性地檢查。
- 與「第二次抽取可能更好」高度相關。
- 測試成本夠低,可在每個輸出上進行。
在我們的案例中,該屬性是書寫系統不匹配。中文詞彙表條目通常應包含漢字。中國的美妝市場甚至會為進口品牌設備創造本地名稱,因此,一個中文欄位中若僅有拉丁字串,通常意味著「模型在這次抽取中未能檢索到本地名稱」,而非「不存在本地名稱」。一個純函數可以測試這一點:迭代碼點,計算漢字與拉丁字母的數量,無需網路連線。
因此,重試的觸發條件變為:在完整的驗證鏈通過後,如果一個中文欄位的已接受輸出僅包含拉丁字母,則對該欄位重新生成一次,並附加一條指令:「若存在既有的本地市場漢字名稱,請優先使用;對於沒有本地名稱的品牌,則保留原始名稱。」
這裡有兩個細節很重要。首先,重試會重複使用與原始嘗試相同的生成、共識和驗證管線。跳過驗證的重試不是重試,而是繞過。其次,附加的指令是附加到基礎提示之後,而不是取代它,因此重試與第一次抽取的差異僅有一處。您會希望這個差異是可歸因的。
在實際資料上的結果是:一個填充品牌欄位首次回傳的是原始英文品牌名稱,在重試後回傳了正確的漢字市場名稱。重試後仍為拉丁字母的欄位,絕大多數是沒有既有本地名稱的小眾品牌,這正是您希望被留下的群體。運行後,約有 11% 新填寫的中文欄位仍僅有拉丁字母,而這些欄位會帶有審核標記,而不是靜默通過。
絕不以失敗結果覆寫通過的結果
任何重試設計的第一個失敗模式是覆寫 (clobbering)。您最初的輸出通過了每個關卡,但重試的結果可能不會。如果您無條件地寫入重試結果,一個通過的項目可能會被拒絕的結果取代,且一個已填滿的欄位會變為空白。這絕對比不重試更糟。
我們最終達成的約定如下:
snapshot = copy(result) // everything the pipeline may mutate
reset(result) // back to undecided state
regenerate with reinforced prompt
run consensus + verification // same gates as the original
adopt only if:
verdict == pass
AND output now satisfies the property (contains Han)
AND output does not collide with an existing confirmed entry
otherwise:
restore(snapshot) // the passing original wins
每個條件都有其存在的價值。「通過」檢查將驗證的權力保留在它應在之處。「屬性」檢查會拒絕再次回傳拉丁字母的重試,因為採納它會耗費預算卻無法修正任何問題。「衝突」檢查很重要,因為新的漢字名稱可能會與另一個概念已確認的翻譯重複;採納它會在稍後觸發管線的重複閘門,並連帶使整個欄位失效。在採納前進行檢查,意味著發生衝突的重試會靜默地還原原始版本,而不是摧毀一個有效的條目。
快照必須涵蓋管線變動的每個欄位,而不僅僅是輸出文本。我們的快照帶有七個欄位,包括判定結果、回譯和相似度距離。缺少任何一個欄位都意味著還原後的條目是兩次執行結果的混合體。
隱藏成本:重試預算與永久耗盡
第二種失敗模式更為隱晦,且幾乎在我們的初版實作中就發布了。批次管線通常會限制每個位置的嘗試次數上限。我們的系統允許三次:在三次判斷失敗後,一個位置會被永久地從母體中移除,這樣有問題的輸入就不會每晚都耗盡 LLM 的開銷。
嘗試次數計數器是從稽核日誌的資料列中得出的。我們最初的設計將重試記錄為自己的一筆資料列,這會被解讀為每晚多一次嘗試。一個每晚都被重試的位置,會在兩晚內達到三次嘗試的上限,並從填補母體中永久移除。這個本意是為了填補更多位置的功能,反而會默默地刪除它們。
解決方法是讓重試對預算來說是不可見的。重試不會寫入獨立的稽核資料列。取而代之的是,它會在最後一筆資料列的摘要欄位中附加一個標記,並同時記錄原始的輸出。這一個標記有雙重功用:
- 預算中立性:嘗試次數計數每晚只會看到一筆資料列,與之前相同。
- 僅此一次的強制執行:在重試前,管線會讀取該位置最新的資料列。若標記存在,表示此位置在當前的判斷週期中已經重試過,因此跳過。
我們將「僅此一次」的範圍限定在判斷週期內,而非永久。如果審核人員之後拒絕了該條目,而該位置重新進入母體,它會隨著新的嘗試次數一起獲得一次新的重試機會。永久性的「僅此一次」意味著一個多年前被判斷過的位置將永遠無法再次受益,這對任何人都沒有好處。
如果你能從本節學到一件事:在為批次系統添加任何重試機制前,找出所有會取用你的嘗試次數或成本計算的消費者,並檢查你的重試在它們各自看來是什麼樣子。重試會與預算、重複資料檢查、耗盡條件判斷以及監控產生交互作用。除非你明確地標示,否則這些消費者都不會知道你額外的呼叫只是一次重試。
此模式的適用與不適用之處
此模式可推廣至任何具備低成本、決定性屬性檢查的生成任務:
- 必須能成功解析的結構化輸出(JSON 結構描述、日期格式):解析失敗即為該屬性。
- 必須使用目標語文系統的翻譯:如本文所提的書寫系統檢查。
- 必須能成功編譯的程式碼生成:編譯器即為屬性檢查。
- 受限的改寫(長度限制、禁用詞彙):掃描器即為屬性檢查。
當品質是程度問題且無確定性測試時,此模式便不適用。若無法用純函數判斷「是否違規」,那就回到了 LLM 評審 LLM 的情況,而那是個成本不同的工具。當變異性低時,此模式的價值也會降低:我們在長尾術語上觀察到 45% 的變異,但在常用術語上,同一個流程幾乎是確定性的,此時重試純屬浪費。在假設重試能找到新東西之前,請先在一個刪除並重新生成的樣本上測量您的變異性。
還有一個坦誠的限制:單次重試會對分佈進行兩次取樣。對我們的工作負載而言,這恢復了大多數可恢復的案例,因為屬性檢查明確告知我們哪些位置值得第二次抽取。如果您的可恢復集合需要五次抽取,經濟效益就會改變,您或許應該修正提示,而非更費力地取樣。
常見問答
為什麼不改為提高 temperature 或使用不同模型重試? 一次變更兩個變數會讓結果無法歸因。我們的重試只改變一件事,即附加一條針對已知失敗的指令,因此任何改進都可以被歸功並保留下來。更換模型也會破壞重試輸出與原始輸出面臨相同驗證的保證。
為什麼只重試一次,而不是直到屬性成立為止? 因為「不存在既定的當地名稱」是一個合法的終端狀態。對於小眾品牌,正確答案就是其拉丁名稱,而迴圈要嘛會永遠運轉,要嘛需要一個比「一次機會,然後標記審查」更難以理解的停止條件。
對大型語言模型 (LLM) 而言,45% 的變異是正常的嗎? 這在很大程度上取決於任務與模型知識邊界的接近程度。我們那些知名的詞彙在多次執行中都很穩定;變異集中在模型真正不確定的長尾條目上。這種集中現象正是針對性重試之所以有效的原因:屬性檢查會找出那些不確定的位置。
這能取代人工審查嗎? 不能。它能縮減審查佇列。重試後仍然違規的輸出會被標記,而該標記會附上原始輸出,以便審查人員能看到兩次的結果。這種模式將工作重心從「審查所有內容」轉移到「審查機器再試一次也無法修復的內容」。