浮水印落在抽樣層，治理風險留在系統裡
最近看 Sebastian Raschka 用 52 張投影片拆 Claude 的文字浮水印，裡面有個定位很重要。浮水印落點在 next-token sampling，不在模型訓練完之後，也不在文章產生後才貼一層標籤。每次選 token 時，用秘密 key 和前 4 個詞導出隨機種子，讓一批接近等機率的候選字出現可驗證的選擇規律。
這個差異會直接改變工程驗證方式。我在做 SRE 時，最怕看到一個漂亮的 detector score，就被拿去當成發布門檻。假設詞彙表有 250,000 個 token，偵測器抓到的是統計訊號，不是文章上蓋了一個肉眼看不見、永遠存在的章。短文本本來就沒有多少樣本，改幾個詞、插入一句人工補充，訊號都可能變弱。
所以公司如果要靠 watermark 做內容治理，我會先把測試矩陣寫出來，才去討論要不要接供應商 API。至少要有 200、500、1000 token 三種短度，另外跑人工改寫、翻譯回譯、拼接一段人寫內容，以及同一篇文章經過三次編輯的情境。每個情境都記錄 false positive、false negative 和 abstain rate，不能只留一個 0 到 1 的分數。
版本管理也很容易漏掉。模型版本換了，sampling 設定可能換了，key rotation 後舊文還能不能驗證，這些都要先定義。若偵測服務只接受目前的 key，半年後稽核一篇舊公告，結果可能只是 API 回覆無法判定。那是治理流程的故障，不代表文章突然變成人寫的。
我會把 detector 當成風險訊號，和來源紀錄、模型呼叫 log、編輯者確認一起看。偵測到高分，可以進人工審查，不能直接退件。偵測不到，也不能替內容背書。尤其翻譯和混合編輯很常見，訊號被削弱後，真正需要查的來源證據反而更重要。
浮水印技術本身很有意思，因為它把介入點放得很低，靠 sampling 就能留下可驗證規律。可治理一家公司時，真正難的是把短文本、改寫、版本、key rotation 和例外處理都接起來。測試表沒有這些欄位，偵測器分數再精準，也只是在替流程增加一個看起來很科學的按鈕。
作者：承翰