GitHub Repo
Transformersコミュニティ、入力順で判定が変わる透かし検出のバッチ処理不具合を報告
BOS tokenを含む入力と含まない入力を混在させると、Transformersの透かし検出器のスコアがバッチ内の順序によって変わるとの報告がありました。行ごとに処理する修正案が提出されていますが、まだマージされておらず、実際のテキストでの発生頻度は未検証です。

10月4日、Hugging Face Transformersコミュニティで、テキストの透かし評価の再現性に関わる不具合が報告されました。同じtoken列を単独で検出した場合とバッチに含めて検出した場合で、判定が異なることがあります。報告者によると、一部の入力にはBOS(sequence start token)があり、ほかの入力にはない場合、並び順を入れ替えると結果が変わります。このケースはTransformers 5.18.0および5.19.0.dev0のCPU環境で再現され、モデルの重みをダウンロードする必要はありませんでした。不具合報告
この検出器は、指定された設定に基づいて生成された透かし入りテキストを識別するためのものです。生成側では、選択された「green token」の確率にバイアスを加え、検出側では同じ設定を使って信号を統計的に評価します。デフォルトの判定しきい値はzスコア3.0です。公式ドキュメントでは、生成と検出で透かしのパラメーター、デバイス、語彙サイズを一致させるよう求めており、検出を妨げる可能性のあるプロンプトを取り除くことも推奨しています。公式APIドキュメント
報告では、原因をBOSの処理に特定しています。コードはバッチの先頭行にある最初のtokenだけを確認し、その結果に応じてバッチ全体の先頭列を削除します。先頭行にBOSがあると、BOSのないほかの行では実際の内容tokenが失われます。合成ケースでは、系列Aのzスコアは単独検出時の約3.098から、BOSを含む系列の後ろに配置されたときには約2.782に低下し、判定が「真」から「偽」に変わりました。このデータはしきい値付近になるよう意図的に選ばれており、実際の誤判定率を推定する根拠にはなりません。再現データ
同日提出された修正案は、BOSの状態が一致する場合には従来のバッチ処理経路を維持します。入力が混在する場合はBOSを行ごとに削除し、個別にスコアを計算してから結果を統合します。また、順序を入れ替えた場合と単独入力時の結果を確認する回帰テストも追加しています。確認時点では提案は未解決のままで、マージまたは正式リリースされたことを示す情報はありません。修正案
バッチ評価やコンテンツの出所を検証するシステムでは、データのまとめ方が判定結果に影響する可能性があります。エンジニアリングチームはまず、単独入力、BOSが混在するバッチ、順序を入れ替えたバッチのスコアを比較し、BOSの前処理が一貫しているか確認できます。今後は、メンテナーがpaddingとBOSの状態が一致するケースをどう扱うか、また実際のテキストでテストするかが注目されます。現時点の証拠が対象としているのは、この検出器のBOS混在経路のみで、SynthIDはテストされていません。