TRL 文件

訓練常見問題解答

Hugging Face's logo
加入 Hugging Face 社群

並獲得增強的文件體驗

開始使用

訓練常見問題解答

我應該關注哪些指標?

在對語言模型進行傳統的有監督微調時,損失(尤其是驗證損失)是衡量訓練進度的良好指標。然而,在強化學習(RL)中,損失對於模型效能的指示作用減弱,其值可能會波動,而實際效能卻在提高。

為解決此問題,我們建議首先關注兩個關鍵指標:

平均獎勵(Mean Reward):主要目標是在強化學習訓練期間最大化模型獲得的獎勵。目標 KL 散度(Objective KL Divergence):KL 散度(Kullback-Leibler 散度)用於衡量兩個機率分佈之間的差異性。在強化學習訓練的背景下,我們用它來量化當前模型與參考模型之間的差異。理想情況下,我們希望將 KL 散度保持在 0 到 10 之間,以確保模型生成的文字與參考模型生成的文字保持相近。

不過,還有更多對除錯有用的指標,請檢視日誌部分

為什麼使用參考模型,KL 散度的作用是什麼?

在訓練強化學習模型時,僅為獎勵進行最佳化可能會導致意想不到的行為,模型可能會以不符合良好語言生成的方式利用環境。在 RLHF(基於人類反饋的強化學習)中,我們使用一個獎勵模型,該模型經訓練用於預測生成的文字是否會獲得人類的高排名。

然而,針對獎勵模型進行最佳化的強化學習模型可能會學到一些能產生高獎勵但並不代表良好語言的模式。這可能導致極端情況,例如模型為了最大化獎勵而生成帶有過多感嘆號或表情符號的文字。在一些最壞的情況下,模型可能會生成與自然語言完全無關但卻能獲得高獎勵的模式,類似於對抗性攻擊。

圖:沒有 KL 懲罰的樣本,來自 https://huggingface.co/papers/1909.08593

為了解決這個問題,我們根據當前模型和參考模型之間的 KL 散度,在獎勵函式中增加了一個懲罰項。透過這樣做,我們鼓勵模型保持與參考模型生成的內容相近。

負 KL 散度有什麼問題?

如果你單純從模型分佈中取樣生成文字,通常不會有問題。但當你使用 generate 方法時,會有一些需要注意的地方,因為它並不總是純粹取樣,這取決於設定,並可能導致 KL 散度變為負值。基本上,當活動模型達到 log_p_token_active < log_p_token_ref 時,我們就會得到負的 KL 散度。這可能在以下幾種情況下發生:

  • top-k 取樣:模型可以平滑機率分佈,導致 top-k 的詞元機率小於參考模型的機率,但它們仍然被選中。
  • min_length:這會忽略 EOS 詞元,直到達到 min_length。因此,模型可以為 EOS 詞元分配一個非常低的對數機率,而為其他所有詞元分配非常高的機率,直到達到 min_length。

這些只是一些例子。為什麼負 KL 散度是個問題?總獎勵 R 的計算公式為 R = r - beta * KL,所以如果模型能學會如何使 KL 散度變為負值,它實際上會獲得一個正獎勵。在許多情況下,利用生成過程中的這樣一個漏洞可能比真正學習獎勵函式要容易得多。此外,KL 散度可以變得任意小,因此實際獎勵與其相比可能非常小。

那麼,你應該如何為 PPO 訓練生成文字呢?讓我們來看看吧!

如何為訓練生成文字?

為了避免上述 KL 散度問題,我們建議使用以下設定:

generation_kwargs = {
    "min_length": -1, # don't ignore the EOS token (see above)
    "top_k": 0.0, # no top-k sampling
    "top_p": 1.0, # no nucleus sampling
    "do_sample": True, # yes, we want to sample
    "pad_token_id": tokenizer.eos_token_id, # most decoder models don't have a padding token - use EOS token instead
    "max_new_tokens": 32, # specify how many tokens you want to generate at most
}

使用這些設定,我們通常不會遇到任何問題。你也可以嘗試其他設定,但如果遇到負 KL 散度的問題,請嘗試恢復這些設定,看看問題是否仍然存在。

如何除錯你自己的用例?

除錯強化學習流程可能因其複雜性而具有挑戰性。以下是一些使過程更輕鬆的技巧和建議:

  • 從一個可行的示例開始:從 trl 倉庫中一個可行的示例開始,並逐漸修改它以適應你的特定用例。一次性更改所有內容會使識別潛在問題的來源變得困難。例如,你可以先替換示例中的模型,一旦你找到了最佳的超引數,再嘗試切換到你的資料集和獎勵模型。如果你一次性更改所有內容,你將不知道潛在問題來自何處。
  • 從小處著手,後續擴充套件:訓練大型模型可能非常緩慢,需要數小時或數天才能看到任何改進。對於除錯來說,這不是一個方便的時間尺度,所以嘗試在開發階段使用小型模型變體,一旦可行再進行擴充套件。話雖如此,有時你也必須小心,因為小型模型可能沒有能力解決複雜的任務。
  • 從簡單開始:嘗試從一個最簡單的示例開始,並在此基礎上增加複雜性。你的用例可能需要一個由許多不同獎勵組成的複雜獎勵函式——嘗試先使用一個訊號,看看你是否可以最佳化它,然後再增加更多的複雜性。
  • 檢查生成內容:檢查模型生成的內容總是一個好主意。也許你的後處理或提示中有錯誤。由於設定不當,你可能會過早地截斷生成內容。這些問題在指標上很難發現,但如果你檢視生成內容,就會非常明顯。
  • 檢查獎勵模型:如果你的獎勵沒有隨時間改善,可能是獎勵模型有問題。你可以檢視極端情況,看它是否按預期工作:例如,在情感分析的案例中,你可以檢查簡單的正面和負面示例是否真的得到不同的獎勵。你還可以檢視資料集的分佈。最後,獎勵可能被查詢(query)主導,而模型無法影響查詢,所以你可能需要對此進行歸一化(例如,查詢+響應的獎勵減去查詢的獎勵)。

這些只是我們發現有幫助的一些技巧——如果你有更多有用的技巧,歡迎隨時提交 PR 將它們也新增進來!

< > 在 GitHub 上更新

© . This site is unofficial and not affiliated with Hugging Face, Inc.