Transformers 社群回報浮水印偵測批次缺陷，輸入排序可能翻轉判定

10 月 4 日，Hugging Face Transformers 社群提出一個涉及文字浮水印評估可重現性的缺陷：同一串 token 單獨檢測與放進批次檢測，可能得到不同判定。回報者指出，在部分輸入含有 BOS（序列起始 token）、部分沒有的情況下，交換排列順序就能改變結果；案例在 Transformers 5.18.0 與 5.19.0.dev0 的 CPU 環境重現，無須下載模型權重。問題回報

這個偵測器用於辨識依指定設定生成的浮水印文字。生成端對選定的「綠色 token」增加機率偏置，偵測端再根據相同設定統計訊號，預設以 z 分數 3.0 作為判定門檻。官方文件要求生成與偵測使用一致的浮水印參數、裝置及詞彙表大小，也建議移除可能干擾偵測的提示詞。官方 API 文件

回報將問題定位到 BOS 處理：程式只檢查第一列的第一個 token，再決定是否刪除整個批次的第一欄。若第一列有 BOS，其他沒有 BOS 的列便會失去真正的內容 token。合成案例中，序列 A 的 z 分數從單獨檢測時約 3.098 降至排在含 BOS 序列後方時約 2.782，判定隨之由真變假。這組資料刻意選在門檻附近，不能據此推算實際誤判率。重現數據

同日提出的修補保留 BOS 狀態一致時的批次路徑；遇到混合輸入，則逐列移除 BOS、獨立評分後整合結果，並加入交換順序與單筆結果的回歸測試。截至查核，提案仍開放，尚無已合併或正式發版的證據。修補提案

對批次評估或內容來源驗證系統而言，這意味著資料打包方式可能成為判定變因。工程團隊可先比較單筆、混合批次及交換順序後的分數，核對 BOS 前處理是否一致。後續應觀察維護者如何處理 padding 與 BOS 相同的情況，以及真實文本測試；目前證據僅涵蓋此偵測器的混合 BOS 路徑，未測試 SynthID。