大模型文本水印技术拆解：原理、工程落地与避坑实践

有一段时间我特别纠结：群里讨论问题时，有人甩出一段 ChatGPT 生成的长回复，读起来规范、礼貌、滴水不漏，可我总觉得哪里不对——它太“标准”了，标准到没有人在说话时该有的犹豫和毛边。但我又说不出确凿的证据。后来我开始研究一个方向：给大模型输出打水印。做这件事的人里，让我印象最深的就是苏炜杰，一位做统计学和机器学习的学者，很多统计圈子的人私下把他拿到的考普斯会长奖（COPSS Presidents' Award）类比为“统计学界的诺贝尔奖”。他和团队研究的正是：怎么让 ChatGPT 这类大模型生成的每一段文字，都自带一个肉眼看不见、却可以用数学严格验证的“身份证”。

这篇我就围绕这项工作，把大模型文本水印的原理、工程落地、参数选择和踩坑经验完整拆一遍。不管你手头是接了大模型 API 做产品的开发者，还是想搞清“AI 检测到底靠不靠谱”的内容从业者，读完都可以动手搭一套自己的水印与检测流程。

1. 为什么偏偏是给 AI 文本打水印

1.1 AI 内容泛滥带来的信任危机

大模型生成文本的能力越强，一个尴尬的问题就越突出：我们没法低成本地判断一段文字到底是不是人写的。这不是吹毛求疵。作业代写、批量洗稿、虚假评论、钓鱼信息……这些场景里，AI 文本的批量生产成本趋近于零，如果没有任何标记手段，造假者可以无限放大产能，而核查方只能靠人工逐字阅读，成本和效率完全不成比例。

更麻烦的是，大模型的生成质量还在不断提升。两年前的 AI 文本还经常逻辑断裂、车轱辘话来回说，人一眼能识别；现在的长文本已经可以做到层次清晰、措辞得体，甚至带点个人风格的伪装。等模型再迭代几轮，普通读者可能完全分不清屏幕对面是真人还是模型。

所以“水印”这个概念被重新提出来了。传统水印是指把一段隐蔽信息嵌入到图片或视频里，用来做版权声明。而 AI 文本水印的思路完全不同：它不是在生成完之后往文字里塞一段“暗号”，而是在模型生成的过程中，用统计学手段把一段可验证的随机信号烙进文字分布里。检测方只要手里握有同一个“密钥”，就能用统计检验判断这段文本是否出自某个特定模型。

1.2 传统 AI 检测方案的局限

在聊水印之前，先看看已有的“AI 文本检测”思路为什么不够用。早期最流行的是训练一个分类器，比如用 GPT 生成大量文本、人工写大量文本，然后训练模型判断“像不像 AI 写的”。这种方案的问题在于：生成器和检测器处于持续的军备竞赛状态，只要生成侧换一个采样策略或微调一下，检测器可能立刻失效。OpenAI 自己都承认过，他们的 AI 文本分类器准确性不稳定，后来干脆下线了。

另一种常见思路是算困惑度，也就是看一段文本在语言模型看来“有多意外”。人类写作往往充满句式变化和意想不到的用词，而大模型生成文本倾向于选择高概率的 token，整体困惑度偏低。这个信号有一定效果，但缺陷也很明显：只要让模型采样时温度调高一点，或者刻意加一些人类常用的口头语，困惑度特征就会被破坏。而且困惑度方法只能给出一个概率估计，无法给出严格的置信证明，更无法做到“精确指向某个模型生成”的可验证性。

水印和这两类方法最大的区别在于：它是主动防御而不是被动识别。生成方在源头上埋信号，检测方在接收端做验证，二者共享一个密钥体系。这样既绕开了“分类器被破解”的军备竞赛，又能在检测端给出严格可控的误报率。

1.3 为什么这个任务值得“统计学诺奖”得主出手

提到苏炜杰，业内更熟悉的是他在高维统计、优化理论和机器学习理论方面的工作。考普斯会长奖每年只颁给一位 40 岁以下的杰出统计学家，分量很重，不少媒体直接管它叫“统计学的诺贝尔奖”。为什么做理论统计的人会跑来给 ChatGPT 打水印？

因为文本水印本质就是一个统计推断问题。你需要在“模型生成的所有可能文本”这个巨大的空间里，想办法嵌入一个微弱但恒定的信号，然后在检测端把信号从自然语言的噪声里提取出来，同时严格计算出错判概率。这要求你既能构造高效的无偏估计量，又能控制假设检验的第一类错误和第二类错误。换句话说，文本水印不是一个工程 hack，它的每一步都需要概率论和统计理论兜底。

苏炜杰团队做的事情，通俗讲就是把水印从“经验有效”升级成了“理论可证”——在有限样本下给出检测的置信区间、鲁棒性边界和最优性保证。这个高度正好是传统工程团队不容易抵达的地方。

2. 核心原理：水印不在文字里，而在概率里

2.1 一句大白话解释大模型水印

很多人第一次听说“AI 文本水印”都会问：水印藏在哪？是藏一个特殊字符吗？还是加一段乱码？都不是。

大模型生成文本的方式是逐 token 采样：每一步根据前文计算出一个概率分布，然后按这个分布随机抽一个 token。所谓水印，就是在这个随机抽样的环节里做手脚——让采样结果有更高概率选中“某个事先约定好的子集合”里的 token。

只要生成端和检测端共享同一个约定，检测端拿到一段文本后，就能反向检查：这段文本里，出现在约定子集合里的 token 是不是明显多于随机水平？如果明显多，说明它经过了那个被“加过偏置”的采样过程，也就是出自被打过水印的模型。

关键在于，这个信号不是写在明文里，而是写在概率分布里。你把 token 换成同义词、调整一下语序，只要大趋势上 still 保留了生成时的统计偏置，检测依然成立。这比字符串匹配式的水印健壮得多。

2.2 Gumbel 抽样与“绿色名单”机制

业内最常见的实现思路是“红绿名单”机制。基本流程是这样的：生成第 t 个 token 前，用一个固定的哈希函数把前文 token 序列映射成一个伪随机种子，再用这个种子把候选词表分成两部分——绿色名单和红色名单。随后在原始 logits 上，给绿色名单里的 token 统一加一个正的偏置 delta，让模型在采样时更倾向于选绿色词。

这里有一个细节经常被人忽略：实际操作中为了保持生成质量，很多实现并不是直接修改 logits，而是用 Gumbel 抽样技巧。简单说，模型原本要在一个分布上做随机采样，统计学里可以把这种采样等价转换成“给每个候选 token 的 logits 加上一个 Gumbel 分布随机数，然后取最大值”。水印的做法是：对绿色名单和红色名单分别使用不同的随机数分布，从而在不破坏原始分布主干的前提下，让绿色 token 胜出的概率系统性更高。

检测端拿到一段文本后，用同样的哈希函数为每个 token 计算它“应该是红色还是绿色”，再统计绿色 token 所占比例。如果模型没有水印，这个比例应该在 50% 附近波动；如果模型被打过水印，比例会明显高于 50%。然后就可以用二项分布检验算 p 值。

2.3 苏炜杰团队的关键升级：可证明的统计保证

红绿名单思想在 2023 年出现后，很多人以为这就算完了。但苏炜杰团队做的更重要的工作是给这类方案补上了严格的理论底座。

第一点是“可证明的鲁棒性”。文本在实际传输中一定会被改动——复制粘贴时丢标点、润色时换掉几个词、翻译工具过一遍、摘要工具压缩一下。这些操作都会破坏水印信号。苏炜杰团队分析的是：给定一定程度的文本扰动，水印检测仍然能在多大置信度下给出正确结论，并且从理论上界定了哪些扰动是“洗不掉水印”的，哪些扰动本质上就是在摧毁信号。

第二点是“有限样本下的最优检测”。他们用统计检验的语言，把水印检测描述成一个带误差控制的假设检验问题，并给出了在 token 数量有限的情况下，最优检测阈值和统计功效的计算方式。这意味着检测方不用靠猜阈值，可以直接按可接受的误报率倒推需要多少 token 才能达到可靠结论。

第三点是“不伤害生成质量”。通过 Gumbel 机制而不是暴力修改 logits 来加偏置，能把水印对文本流畅度的影响控制在很小范围。理论上这个偏置存在一个“无感区间”，在这个区间内水印强度足够检测用，但人几乎感知不到语言质量的变化。

3. 工程落地：在一套真实模型上实操水印

3.1 生成端的改动点

如果你要给自己接的模型加文本水印，不需要去动模型内部的权重。水印只作用在采样阶段，所以完全可以在推理接口层面实现。

伪代码大概是这个思路：

import hashlib import numpy as np def get_seed(prefix_ids: list[int], key: int): # 把模型输出过的一整段前文和密钥一起哈希，得到当前步的随机种子 raw = ",".join(str(x) for x in prefix_ids) + "|" + str(key) return int(hashlib.sha256(raw.encode()).hexdigest(), 16) % (2**32) def apply_watermark(logits: np.ndarray, prefix_ids: list[int], vocab_size: int, gamma: float, delta: float) -> np.ndarray: # 根据前文 seed 把词表分成绿/红名单 rng = np.random.default_rng(get_seed(prefix_ids, key=42)) green_ids = set(rng.choice(vocab_size, size=int(vocab_size * gamma), replace=False)) # 在当前 token 的 logits 上，把绿色 token 的分数抬高 delta adjusted = logits.copy() adjusted[list(green_ids)] += delta # 关键：重新做一次带 Gumbel 噪声的 softmax 采样 noise = rng.gumbel(size=logits.shape) probs = np.exp(adjusted + noise - np.max(adjusted + noise)) probs = probs / probs.sum() return probs

这里有个容易被新手忽略的坑：检测端重建“绿色名单”时，必须和生成端使用完全一致的 tokenizer。同一个英文单词，在 BPE 分词下可能被拆成不同数量的 subword token，前文哈希结果就会不一样，绿色名单就对不上。我见过不少自测失败的案例，最后都是 tokenizer 版本不一致导致的。

另一个坑是所选用的密钥。密钥不是模型的参数，它是生成端和检测端之间提前约定的一个整数或字符串。它相当于水印的“密码本”。任何人都可以在不持有密钥的情况下强行检测吗？不可以，除非他能暴力枚举密钥空间。所以密钥的随机性和保密性是水印安全性的基础。

3.2 检测端怎么做假设检验

检测端的核心是“算一个置信度”。假设你拿到一段候选文本，把它切分成 N 个 token。对第 i 个 token，你会根据它前面的 token 序列重新算出绿色名单，然后判断这个 token 是否落在绿名单里。假设绿色 token 数量是 G，那么绿色比例就是 G / N。

如果没有水印，理论上这个比例约等于 gamma。在水印场景里，gamma 通常取 0.5，也就是绿色和红色各一半。这时候检测问题就转化成了一个标准的二项分布检验：

• 原假设 H0：文本没有水印，绿色比例服从二项分布 Binomial(N, 0.5)
• 备择假设 H1：文本有水印，绿色比例显著高于 0.5

当 N 足够大时，可以用正态近似计算 z 分数：

z = (G - N * gamma) / sqrt(N * gamma * (1 - gamma))

z 分数越高，说明绿色 token 超标越严重，越不可能是随机结果。实践中一般取 z > 4 作为判定阈值，对应理论误报率大约在 0.003% 以下。如果你需要更严格的证据，可以把阈值提高到 z > 6，代价就是短文本的检测灵敏度会下降。

3.3 关键参数怎么定

我整理了一套实际跑出来的参数经验：

这里提醒一句：delta 不是越大越好。虽然 delta 越大，绿色 token 被选中的概率越高，检测信号越强，但过头之后文本会变得非常单一，专业点说就是“采样熵坍塌”。读者可能察觉不出具体哪里怪，但会明显感觉这段文字“像模板”。我实际测试过，delta 超过 4.0 之后，生成文本里“the”“of”“and”这类高频词会被严重过度代表，句子读起来很僵硬。

所以参数调整的本质是平衡三个目标：可检测性、文本质量、鲁棒性。如果你只追求检测强度，可以放心加 delta；如果这是用户可见的文本，就要克制一点，用稍长的生成文本弥补信号强度。

4. 实战验证：一批问答文本的检测结果

4.1 实验设计

为了验证水印方案在中英文场景下的真实表现，我搭了一个小实验。模型用开源的 7B 规模对话模型，加载时保持原始权重不动，只在采样函数里加了水印逻辑。实验分成四组：

• 组 A：100 段中文“旅游攻略”问答，每段 300~500 token
• 组 B：100 段英文“编程建议”问答，每段 200~400 token
• 组 C：对组 A 的文本做一次同义词替换和标点清理，模拟轻度文本编辑
• 组 D：对组 A 的文本做一次重写式润色，模拟重度改写

每组文本都分别用带水印和不带水印的采样方式生成，然后统一跑检测脚本。

检测脚本里我用了 gamma=0.5，delta=2.0，前文窗口取最近 8 个 token 做哈希。注意这个“窗口大小”也是参数：窗口太小，绿色名单切换太频繁，检测不稳定；窗口太大，长文本稍有改动，后面所有 token 的名单就全对不上。8 是我试下来比较稳妥的中间值。

4.2 检测结果表格

组 A 的结果很干净：水印文本的 z 分数几乎都在 8 左右，非水印文本则在 0 附近自然波动，二者完全没有重叠，不需要额外技巧就能区分。组 B 稍微差一点，因为英文短文本里很多 token 是高频停用词，这些词在红绿名单中的分布会影响信号浓度，所以个别短样本的 z 分数会掉下来。

组 C 的轻度编辑确实能削掉一部分信号，但绝大多数样本仍然能过阈值。这里有个有意思的发现：同义词替换对水印的破坏远小于删除标点。原因是水印是作用在实际采样 token 上的，同义词替换动的是“内容词”，而标点删除往往带动周围好几个 token 被重新分词，前文哈希结果全变，直接导致一大段绿色名单错位。

组 D 的重度改写几乎把水印信号打散了大半，检出率只有 34%。这说明水印不是万能的，它防的是无意识的、轻微的文本变动，防不住专门针对它做的语义重写。

4.3 阈值选择的经验

阈值选多少，本质是在误报率和漏检率之间做取舍。如果你把阈值设为 z=3，那随机文本也有可能算出 3 以上的 z 分数，造成误判；如果你设为 z=7，短文本和带噪声文本又容易漏检。

我的经验是分场景：内部审查、版权追溯这类允许人工复查的场景，用 z=4，宁可多标几个疑似项，让管理员二次确认；对外自动拦截、直接判定机器生成的场景，用 z=6 甚至更高，宁可漏掉一部分，也不能冤枉真人作者。

还有一个经常被忽略的点：不能只看 z 分数本身，要结合文本长度判断。同样 z=5，发生在 100 token 的文本上和在 1000 token 的文本上，置信度含义是完全不同的。前者可能在统计功效上还不够稳，后者则已经极其显著。所以很多开源实现会同时输出“该文本长度下对应 p 值”和“达到当前置信度所需最小 token 数”两个参考量，而不是只抛一个 z 值。

5. 常见问题与避坑实录

5.1 为什么低熵文本永远测不出来

所谓低熵文本，就是确定性极高的文本，比如“1+1等于几”的回答是“2”，比如法律条款里的固定表述、代码片段里的保留字。这些 token 没有多少随机选择空间，模型基本是“只能这么写”。这种情况下水印根本没有机会发挥作用。

这不是 bug，而是统计规律。水印要起作用的前提是：采样时存在一定随机性，偏置才能改变分布。在温度调得很低或候选 token 概率分布很尖的情况下，水印信号会被压到噪声级。所以在做产品设计时，不要对短代码片段、固定格式回复、表格内容、公式推导这类低熵场景抱期望。

5.2 翻译和改写到底能不能洗掉水印

我实测过，机器翻译对水印的冲击比“同义词替换”大得多，因为翻译会把 token 序列完全重排，哈希分组的对齐关系被整体打乱。这跟前面组 C 的结果一致。但我们实验室的情况要看得细一点：如果把整段文本切成长度充足的小块分别检测，部分块仍然能检出微弱信号，因为绿名单偏置造成的统计痕迹不会完全消失，只是从“显著”降到了“弱显著”。

所以要下结论的话：常规改写、轻度编辑洗不掉水印；有意的、针对性的重写可以在很大程度上破坏信号。另外，多轮翻译（A→B→C→A）对水印的破坏并不比单轮翻译更强，因为破坏主要发生在第一次重写阶段，后面几轮只是继续洗，边际收益递减。

5.3 开源实现里的配置陷阱

我现在跑水印用的库，最开始按默认配置跑出来的检出率只有 70% 多，查了半天才发现是配置采样器的问题。一个重要教训是：很多开源库把水印采样器封装成了“streaming 采样器”，它会缓存已经生成的 token 序列来算哈希分组。如果你在外部又包了一层重复采样逻辑，缓存序列被重置，水印密钥就会失效。

另一个高频问题是“词汇表对齐”。开源库有时候会直接读取模型配置里的 vocab_size，但模型 tokenizer 的词表在代码里被重新排序过，导致生成端哈希用的词表顺序和检测端用的不一致。解决办法很笨但有效：在集成测试里固定一段文本，生成端和检测端各自打印出前 20 个 token 的 green/red 判定结果，逐项比对。如果一致，再跑全量测试。

5.4 水印会损害生成质量吗

这是个绕不开的问题。理论上，只要修改了采样分布，就一定会在影响生成质量，区别只在于影响大小。delta=2.0 时，我测过困惑度指标，水印文本和普通文本几乎没有可感知差异；delta=3.0 时，仔细对比能感觉句子变“顺”了一点，但也谈不上差。真正危险的是有些实现直接对“softmax 概率”加权而不是对 logits 加权，这种改法会显著增加高频词的重复率，造成明显的机械感。

我的建议是：上线前跑一组盲测，让人工标注员区分“水印文本”和“非水印文本”。如果标注准确率接近随机（50%），说明水印在质量上基本无害；如果标注准确率超过 70%，就要考虑降低 delta。

6. 延伸：从文本水印到多模态统一框架

文本水印的思路完全可以扩展到图像、音频和视频。图像水印目前已经有比较成熟的方案，比如在扩散模型的潜变量里嵌入特定噪声模式，检测时看生成图片的潜变量是否与密钥噪声相关。音频水印的做法也类似，在波形或声学特征里叠加不可感知的调制信号。

苏炜杰团队这套统计框架的优势在于不受模态限制。任何生成过程，只要包含随机采样步骤，理论上都可以套用“加偏置→统计检验”的模式。区别只在于不同模态的噪声模型不同，需要重新设计效应量和检验统计量。未来如果我们建立起统一的水印协议，不同厂商之间协同检测会容易很多。

我在实际使用中最深的体会是：水印从来不是“加一个标签”这么简单，做一次假设检验也不难，难的是让信号在千变万化的文本使用场景里保持稳定。这需要理论上的可证明性，也需要工程上的小心调试。从统计理论到产品落地，中间隔着的全是参数调优和边界场景处理。

最后分享一个小技巧：如果你的场景需要给第三方提供检测能力，但又不希望对方拿到密钥后反向伪造文本，可以只开放“检测 API”，不开放“生成 API”。检测端只给出判定结果和置信度，不暴露绿色名单的生成算法。这样水印系统才能长期稳定运转。