Transformers 社群提出重複懲罰修補，避免左側填補誤傷結束符號

Transformers 社群於 11 月 1 日提交 PR #50215，針對文字生成中的重複懲罰提出修補。作者指出，RepetitionPenaltyLogitsProcessor 可能把已被注意力遮罩排除的填補 token 也算進歷史紀錄；當左側填補使用的 pad_token_id 與結束符號 eos_token_id 相同，EOS 的生成分數便可能受到不必要的懲罰。截至查核時，提案仍為開啟狀態。修補提案

這個使用情境並不罕見。官方教學建議，長度不同的提示批次送入生成模型時，應使用左側填補，範例也直接將填補符號設為 EOS。文件另說明，repetition_penalty 大於 1 可抑制重複，而 EOS 用來觸發生成停止。因此，若填補位置影響了 EOS 分數，工程上值得檢查的便包括停止時機與輸出長度；這是依機制推導的風險，尚非已公布的大規模品質量測。官方生成教學

提案的做法，是讓懲罰處理器接收可選的 attention_mask，排除遮蔽位置，並從抽樣與束搜尋流程傳入遮罩。測試設計同時涵蓋真正出現在輸入中的 EOS、不同填補長度，以及多組回傳序列，避免修補只解決填補問題，卻連有效的歷史 token 也一併忽略。作者回報，相關處理器測試有 53 項通過，生成整合測試另有 3 項通過。變更與測試說明

對維護批次推論服務的團隊，這份提案提供了一個可操作的驗證方向：固定模型、提示與解碼參數，比較同一提示單獨執行，以及搭配較長提示形成批次時的 EOS 分數與停止步數，並對照是否啟用重複懲罰。接下來應觀察維護者是否接受遮罩傳遞方式，以及正式 CI 結果；目前公開頁面仍顯示 CI 等待維護者批准，作者列出的測試不能視為專案已完成驗證或正式版已修復。提案狀態