有一段时间我特别纠结群里讨论问题时有人甩出一段 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, key42)) green_ids set(rng.choice(vocab_size, sizeint(vocab_size * gamma), replaceFalse)) # 在当前 token 的 logits 上把绿色 token 的分数抬高 delta adjusted logits.copy() adjusted[list(green_ids)] delta # 关键重新做一次带 Gumbel 噪声的 softmax 采样 noise rng.gumbel(sizelogits.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 关键参数怎么定我整理了一套实际跑出来的参数经验参数含义推荐范围实际经验gamma绿色名单比例0.3 ~ 0.5别低于 0.3太低的话绿色信号太稀疏delta绿色 token logits 偏置1.0 ~ 3.0从 2.0 起步调到 3.0 就基本无感知上限N_min最短检测文本长度200 token 以上低于 100 token 基本测不出可靠水印z_threshold判定阈值4.0 ~ 6.0生产环境用 5.0 比较平衡这里提醒一句delta 不是越大越好。虽然 delta 越大绿色 token 被选中的概率越高检测信号越强但过头之后文本会变得非常单一专业点说就是“采样熵坍塌”。读者可能察觉不出具体哪里怪但会明显感觉这段文字“像模板”。我实际测试过delta 超过 4.0 之后生成文本里“the”“of”“and”这类高频词会被严重过度代表句子读起来很僵硬。所以参数调整的本质是平衡三个目标可检测性、文本质量、鲁棒性。如果你只追求检测强度可以放心加 delta如果这是用户可见的文本就要克制一点用稍长的生成文本弥补信号强度。4. 实战验证一批问答文本的检测结果4.1 实验设计为了验证水印方案在中英文场景下的真实表现我搭了一个小实验。模型用开源的 7B 规模对话模型加载时保持原始权重不动只在采样函数里加了水印逻辑。实验分成四组组 A100 段中文“旅游攻略”问答每段 300~500 token组 B100 段英文“编程建议”问答每段 200~400 token组 C对组 A 的文本做一次同义词替换和标点清理模拟轻度文本编辑组 D对组 A 的文本做一次重写式润色模拟重度改写每组文本都分别用带水印和不带水印的采样方式生成然后统一跑检测脚本。检测脚本里我用了 gamma0.5delta2.0前文窗口取最近 8 个 token 做哈希。注意这个“窗口大小”也是参数窗口太小绿色名单切换太频繁检测不稳定窗口太大长文本稍有改动后面所有 token 的名单就全对不上。8 是我试下来比较稳妥的中间值。4.2 检测结果表格实验组平均文本 token 数水印文本平均 z 分数非水印文本平均 z 分数阈值 z5 下的检出率A中文4028.51-0.12100%B英文3126.870.0396%C轻度编辑3885.620.1189%D重度改写3612.18-0.0534%组 A 的结果很干净水印文本的 z 分数几乎都在 8 左右非水印文本则在 0 附近自然波动二者完全没有重叠不需要额外技巧就能区分。组 B 稍微差一点因为英文短文本里很多 token 是高频停用词这些词在红绿名单中的分布会影响信号浓度所以个别短样本的 z 分数会掉下来。组 C 的轻度编辑确实能削掉一部分信号但绝大多数样本仍然能过阈值。这里有个有意思的发现同义词替换对水印的破坏远小于删除标点。原因是水印是作用在实际采样 token 上的同义词替换动的是“内容词”而标点删除往往带动周围好几个 token 被重新分词前文哈希结果全变直接导致一大段绿色名单错位。组 D 的重度改写几乎把水印信号打散了大半检出率只有 34%。这说明水印不是万能的它防的是无意识的、轻微的文本变动防不住专门针对它做的语义重写。4.3 阈值选择的经验阈值选多少本质是在误报率和漏检率之间做取舍。如果你把阈值设为 z3那随机文本也有可能算出 3 以上的 z 分数造成误判如果你设为 z7短文本和带噪声文本又容易漏检。我的经验是分场景内部审查、版权追溯这类允许人工复查的场景用 z4宁可多标几个疑似项让管理员二次确认对外自动拦截、直接判定机器生成的场景用 z6 甚至更高宁可漏掉一部分也不能冤枉真人作者。还有一个经常被忽略的点不能只看 z 分数本身要结合文本长度判断。同样 z5发生在 100 token 的文本上和在 1000 token 的文本上置信度含义是完全不同的。前者可能在统计功效上还不够稳后者则已经极其显著。所以很多开源实现会同时输出“该文本长度下对应 p 值”和“达到当前置信度所需最小 token 数”两个参考量而不是只抛一个 z 值。5. 常见问题与避坑实录5.1 为什么低熵文本永远测不出来所谓低熵文本就是确定性极高的文本比如“11等于几”的回答是“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 水印会损害生成质量吗这是个绕不开的问题。理论上只要修改了采样分布就一定会在影响生成质量区别只在于影响大小。delta2.0 时我测过困惑度指标水印文本和普通文本几乎没有可感知差异delta3.0 时仔细对比能感觉句子变“顺”了一点但也谈不上差。真正危险的是有些实现直接对“softmax 概率”加权而不是对 logits 加权这种改法会显著增加高频词的重复率造成明显的机械感。我的建议是上线前跑一组盲测让人工标注员区分“水印文本”和“非水印文本”。如果标注准确率接近随机50%说明水印在质量上基本无害如果标注准确率超过 70%就要考虑降低 delta。6. 延伸从文本水印到多模态统一框架文本水印的思路完全可以扩展到图像、音频和视频。图像水印目前已经有比较成熟的方案比如在扩散模型的潜变量里嵌入特定噪声模式检测时看生成图片的潜变量是否与密钥噪声相关。音频水印的做法也类似在波形或声学特征里叠加不可感知的调制信号。苏炜杰团队这套统计框架的优势在于不受模态限制。任何生成过程只要包含随机采样步骤理论上都可以套用“加偏置→统计检验”的模式。区别只在于不同模态的噪声模型不同需要重新设计效应量和检验统计量。未来如果我们建立起统一的水印协议不同厂商之间协同检测会容易很多。我在实际使用中最深的体会是水印从来不是“加一个标签”这么简单做一次假设检验也不难难的是让信号在千变万化的文本使用场景里保持稳定。这需要理论上的可证明性也需要工程上的小心调试。从统计理论到产品落地中间隔着的全是参数调优和边界场景处理。最后分享一个小技巧如果你的场景需要给第三方提供检测能力但又不希望对方拿到密钥后反向伪造文本可以只开放“检测 API”不开放“生成 API”。检测端只给出判定结果和置信度不暴露绿色名单的生成算法。这样水印系统才能长期稳定运转。