SynthID Detector：水印检测器，检得到信号，判不出真假

2026 年 10 月 7 日，Google 把 SynthID Detector 向全球公众开放，英文界面即日可用。公众第一眼看到的是规模：SynthID 累计已给超过 1800 亿个图像与视频、24 万年时长的音频写入水印；Search、Gemini App 和 Chrome 里内置的查验功能，每天处理超过 100 万次请求。这一组数字之所以容易造成误解，正是因为它把查验做成了一个网页上登录就能用的公开入口，于是人们很自然地顺着"查得动"推成"查得准"，再把查验结果当成一句关于真假的判决。这些数字来自 Google 单方披露，没有第三方独立测量。Google SynthID

一个能一眼看穿 AI 内容的工具上线，按理说该是"AI 测谎仪"落地的时刻。但只要把 Google 对这个工具输出结果的措辞读一遍就会发现，它回答的问题比"真假"窄得多。这篇专题就沿着一条线索往下走：SynthID Detector 能给出较强的阳性归因，却无法让"未检出"成为真实性证明。理解这一点之后，再看那些规模数字、攻击论文和法务条款，才能知道它们各自在拼哪一块。

一、SynthID 检出的到底是什么：是真假判断，还是来源归因？

synthid.com 的常见问题页把两种结果写得毫不含糊。检出的时候，它说的是 "likely edited or generated by a SynthID-enabled AI model"，大意是很可能由启用了 SynthID 的 AI 模型生成或编辑过。未检出的时候，措辞换成 "No confident signal was found"，紧跟一句 "Although this does not totally rule out AI generation or manipulation"。synthid.com

关键就在这后半句。Google 自己在"未检出"旁边写明了"这并不能完全排除 AI 生成或篡改"。把"未检出"读成"内容是真人真事"，是读者加上去的解释，不是厂商的承诺。这两个结果落在同一个工具界面上，分量却完全不对等。

DeepMind 在 SynthID-Image 的技术论文里，把"建立来源"和"检测 AI"明确拆成两件事。同一个 decoder 既能回答"这张图里有没有水印"，也能在需要时恢复出承载来源信息的 payload，也就是一段能指认来源的编码。所以"能追溯这段内容经过哪个环节"和"能证明这段内容陈述为真"，是两件不同强度的事，前者是归因，后者是事实核查。SynthID-Image

之所以这两件事这么容易混，是因为检测任务本身就带一种不对称。SynthID 在检测理论所说的"开放世界"里工作：绝大多数流到检测器面前的内容从来没接入过 SynthID，里面根本没有信号。检测器要在海量没有信号的内容里，找出少数预埋了信号的样本。找到信号是一个非常强的正例，找不到信号却几乎什么都说明不了。用一句话概括，这是一场"大海捞针"的任务，捞到针能证明海里有针，捞不到不能证明海里没有针。

图注:命中是强证据,未命中几乎什么都说明不了

这张图把两类结果分开来看。未检出这一侧下面只剩两种来源，都出自官方 FAQ 自己列出的可能：内容根本没接入过 SynthID，包括它在该厂商接入之前就已生成；或者水印写过，又被重度修改弄没了。两者都指向"信号没写进去"或"写进去又没留住"，而不是"内容是真的"。至于"在无水印内容上误触发"，它不在未检出一侧，而是检出一侧的假阳性，也就是检测器报告了一个本来并不存在的信号。这是相反方向的错误，所以它解释不了未检出。

所以 SynthID Detector 交到公众手上的，是一张来源凭条：它最多能说清某段内容参与过哪个环节。理解了这一点，接下来就要问：为什么这条信号要写在生成的那一刻，而不是等生成完了再想办法认出来？

二、既然事后分类器会随模型迭代过时，把信号写进生成端为什么能撑得更久？

在 SynthID 之前，AI 内容检测的主流思路是训练一个分类器去"猜"：给它一段内容，让它判断这像不像 AI 生成的。这条路有个众所周知的软肋。SoK 综述把主动水印与被动事后检测做了二分，并直接点名 OpenAI 的 AI text classifier 在 2023 年上线，同年年底就被官方弃用，原因就是准确率不足和跨分布失败。SoK

问题出在"猜"这个动作依赖模型见过的数据。生成模型每更新一代，内容风格就变一次，分类器必须重新训练才跟得上；而一旦遇到训练分布外的内容，比如非母语者写的文字，判断就更容易失准。

生成端水印换了个做法：在生成或编辑的那一刻，就把一个统计信号写进内容本身。SynthID-Image 的论文说明了这套设计为什么选"post-hoc + model-independent"，也就是生成之后加标记、且不依赖具体生成模型。论文给的理由是部署考虑，而不是某次能力突破：只有不绑定模型的方案，才能用尽量少的几套实现覆盖 Google 所有的生成内容。反过来，那些把水印嵌进某个模型版本的做法，模型换代就得跟着重做。SynthID-Image

文本模态的实现更直观。SynthID-Text 发在 2024 年的 Nature 上，它不在生成完成后反向修文本，而是在采样阶段就动手脚。生成下一个 token 时，先按模型原本的概率分布撒出一批候选，再让它们两两"打锦标赛"，逐层选出得分更高的那个，直到剩下唯一的胜者作为输出。决定谁晋级的评分函数由密钥驱动，所以最终文本只靠 token 序列本身就能被检测。

图注：Tournament sampling 的结构分上下两半。上半部用多个由密钥驱动的伪随机函数给词表里的每个 token 打分；下半部把从模型分布采出的候选 token 分对，逐层按评分晋级，最后选出下一个 token。图上写的是 m=3，这只是示意，论文正文用的配置是 m=30。水印不是事后贴在成品上的标签，而是嵌在"选哪一个 token"这个动作里。SynthID-Text

这套做法有一个很实用的后果：检测不需要再调用底层模型。论文明确说，检测时只要密钥和 token 序列就能计算分数、比对阈值，不必访问那个往往闭源的生成模型本身。SynthID-Text

图像一侧的对应结构可以这样看：

这里有一个容易被忽略的细节，它决定了下游的一切。SynthID 的 encoder 一旦部署，就很难再提高水印的多样性，也很难防止被提取；而 decoder 可以随时在线更新，用来应对新出现的攻击。也就是说，水印能不能活下去，靠的是持续运维，不是一次性的技术发布。

安全一侧的代价也写在论文里。SynthID-Image 把威胁分成两类：移除水印导致漏检，伪造水印导致误报；工具则包括对抗样本、代理模型迁移和用另一个生成模型重建图像。论文自己承认，训练出一个既完全鲁棒又完全安全的方案可能做不到，于是退而求其次，把关键攻击做得尽可能难、尽可能贵。

还有一个统计学上的设计值得记住。SynthID 的判定用的是 conformal p-value，而不是简单的二分类阈值。这种做法可以保证误报率不超过设定的水平，同时明确允许"弃权"，也就是在拿不准的时候干脆不报。这解释了公开展示给用户的结果为什么天然是"检出"和"未检出"两档，而"未检出"背后其实承认了"信号不足，我不敢下结论"。

所以把信号写进生成端，换来的是可扩展和跨版本兼容，同时它也把自己变成了一条需要厂商持续维护的信号链。这也埋下了下一章的伏笔：既然单个模型再聪明也守不住所有攻击，那么真正决定 SynthID 分量的，就变成了有多少厂商愿意在生成端写这个信号。

三、让 SynthID 变成基础设施的，是模型更聪明，还是厂商愿意接入？

回到 Google 2026 年 10 月 7 日的公告。除了 1800 亿图像视频和 24 万年音频，还有一个更关键的信息藏在合作方清单里：任何人现在都能查一段内容是不是由 Google 或其合作伙伴的 AI 生成，名单包括 OpenAI、NVIDIA、Kakao，以及"即将加入"的 Apple。同一批数字里，Search、Gemini、Chrome 的查验功能每天处理超过 100 万次请求。Google SynthID

这些规模数字要放回时间线里才看得出性质。2025 年 5 月 SynthID Detector 以可信测试者形式上线时，水印规模是 100 亿量级；2026 年 5 月的 Google I/O 上是 1000 亿量级；到 2026 年 10 月变成 1800 亿量级。这是一条逐年累计的曲线，没有一个突然跳变的日子。所以把这些数字当成"某天技术飞跃"的证据，会读错方向。

这里的变量不在检测模型有多聪明，而在两件常被混在一起的事：覆盖面和抗攻击能力。WAVES 这份基准评测的是后者。它把 26 种攻击统一到同一套协议下，同时评测 Tree-Ring、Stable Signature、StegaStamp 三种代表性水印，结论是没有任何一种水印能在所有攻击类面前守住。WAVES

图注：三个 panel 分别是 Tree-Ring、Stable Signature、StegaStamp 三种学术水印。每个点代表某一种攻击在某个强度下的表现，横轴是归一化之后的质量退化，纵轴是低误报率下的检出率，理想位置在右上角。图中没有任何一种水印的点群稳定守在右上角，也就是说它们各自只守得住一部分攻击类。图里是三种学术方案，不是 SynthID 产品的对比，数值也不要从图上目测。WAVES

这张图说清的是单点方案的天花板，也就是覆盖面再广也替代不了抗攻击能力：就算所有生成端都写了信号，任何单一水印方案在专门攻击下仍可能被抹掉。覆盖面的意义并不在这里。把它和合作方名单放在一起看，它改变的是另一件事，阳性归因能适用的内容范围。每多一家厂商在生成端写信号，SynthID Detector 能给出"这段内容参与过哪个环节"这类结论的对象就多一批；覆盖面越大，可供阳性判断的内容就越多。但这不会让"未检出"变得更可疑。内容来自没接入的模型，或者生成于某家接入之前，仍旧是查不到信号，未检出依然什么都不能证明，既不是异常迹象，也不是清白证据。跨厂商的查验流程大致是这样：

需要注意的是，这份名单里有软的部分。Apple 在公告里只是"即将加入"，Google 没有给出上线的具体日期；而 OpenAI、NVIDIA、Kakao 属于查验侧，和它们在生成侧的角色并不完全对应。所以把这份清单读成"整个行业已经统一到一套标准"，会超过公告能支撑的范围。

到这里，SynthID 的性质已经变了：它不再是一个检测模型，而是一个覆盖面。技术问题在这里转化为商务和治理问题，落点是谁愿意在生成端接进来。覆盖面越广，能给出阳性归因的内容就越多，可这并不会填补"未检出"那一侧的空缺。这正是下一章要处理的问题。

四、检出算是证据，那「未检出」到底证明了什么？

官方 FAQ 列出的"未检出"来源可以归成两类：内容来自没接入 SynthID 的模型，或者来自接入之前；以及水印确实写过，却被重度修改到信号衰减、甚至被彻底移除。两类都指向同一个方向，也就是信号没写进去，或者写进去又没留住。这两种情况下的"未检出"，都不能读成"这是真的"。

边界不只发生在负结果这一侧。官方 FAQ 同时承认，检测器可能在根本没有水印的内容上误触发，报出一个其实并不存在的信号。这是检出一侧的错误，也就是假阳性。它和"未检出"方向相反，并不会增加未检出的解释，反而提醒我们：检出结果本身也可能出错，它不是一句牢不可破的判决。

如果说 FAQ 只是承认了可能性，那么 2026 年发表在 USENIX Security 上的 MarkNull 把可能性变成了实测。这篇论文提出了一个 no-box、模型无关的移除攻击：它不接触目标水印的 encoder、decoder 或密钥，只用一个公开的代理模型。做法是在潜空间里给生成结果的表示加一点扰动，一边让它偏离水印所依赖的噪声分布，一边用感知损失把画质稳住。MarkNull

图注：这是 MarkNull 的两种攻击形态。左侧逐样本优化潜表示，一边迭代扰动、一边用感知损失控制画质；右侧是摊销版本，先训练一个移除网络，之后单次前向就能把水印去掉，速度约 0.5 秒一张。图中那个锁形标志只是通用代理模型的占位符，不代表被攻击的就是 SynthID。它说明移除攻击既能做精细，也能做到规模化。MarkNull

论文报告的结果相当直接：对 Google 商用的 SynthID-Image，攻击成功率达到 100%；在九个多位水印方案上，平均位准确率被压到 53.14%，已经接近 50% 的随机猜测水平。它的摊销版本把攻击压缩到单次前向，使这条路从研究演示变成可批量执行的操作。需要保留限定语的是，论文自称是首篇针对商用水印的移除攻击研究，而且 SynthID-Image 的评测样本只有 20 张 Imagen-3 生成的图像，不适合外推到整个产品。

单一攻击之外，2026 年 9 月的一份攻击综述把这些散落的观察归纳成了几条论点。这份综述把 60 多个目标水印和七类攻击家族重新整理，得出三个公开结论：常规的鲁棒性评测不等于安全性，因为它只测良性扰动；看起来更强的扩散潜空间水印反而暴露了新的攻击面；在某些场景下，伪造水印比移除水印更实用。Attacks Survey

后面这条尤其值得警惕。移除是让检测器"看不到信号"，伪造则是往内容里塞进一个本不属于它的信号，制造虚假的来源归属。前者骗的是"这是不是 AI 生成的"，后者骗的是"这是谁生成的"。水印检测器一旦被当成定罪的依据，伪造就成了比移除更危险的武器。

移除攻击的门槛到底有多低，Scott Aaronson 在其 2026 年 8 月的博客里用非技术的语言描述过：把文本在英语和法语之间来回翻译一次，或者让它夹带 emoji 再删掉 emoji，或者换一个开放模型改写一遍，都可能把水印洗掉。Aaronson

还有一层边界需要说清。水印最多只能说明"全部或部分内容由某个参与工具生成或编辑过"，它不判断画面里的陈述是否真实，也很难区分"整张图都是生成的"和"真照片上做了一处局部编辑"。一段真实拍摄的视频配上 AI 生成的旁白，可以带水印；一张完全生成的假新闻配图，也可以因为没接入而查不出信号。

把这些点连起来，这份综述支持的判断是有边界的：检出是一条可用的来源证据，而未检出可能意味着未接入、旧内容，或者信号受损、已被攻击抹除。它不是一个清白证明。既然负结果这么不可靠，检测端为什么还愿意公开、却又必须设卡？这是下一章的问题。

五、既然要公开给所有人用，为什么检测器还必须登录、限额、藏起细节？

SynthID Detector 的公开入口没有做成一个开放 API。synthid.com 的附加条款明确禁止三类行为：利用服务运行黑盒对抗攻击，或者专门优化一些用来破坏、绕过、削弱检测逻辑的变换；绕过界面批量提交请求、抓取数据，把前端当成自动化的批量查验接口；以及通过多账号或自动化工具绕过服务的速率限制。synthid.com

这些条款不是产品团队的保守选择，背后有结构性原因。AISTATS 2025 上的一篇论文把 provenance 方案的三个性质做了形式化：不可伪造性，指没有私钥的人造不出被该密钥标记过的内容；鲁棒性，指内容经过合理变换后信号仍在；公开可验证性，指验证只需要公钥，任何第三方都能独立判断。Trilemma

论文的结论是：三者同时成立在数学上可以构造，但在当前深度学习能力下走不通。他们把 DINOv2、SSCD 这类自监督图像嵌入模型放到白盒攻击下评测鲁棒性，干净的 ROC AUC 分别是 0.990 和 0.986，看起来近乎完美；一旦在 ℓ∞ 约束下攻击，最好的 SSCD 模型 ROC AUC 直接跌到 0.057，等于完全不可用。

图注：这张图横向分三行，对应三种来源方案。基于 metadata 的方案，比如 C2PA，用一份附属的 manifest 挂上密码学签名，能做到不可伪造且公开可验证，但内容被重新编码或剥离一个字节，凭证就和内容分离了，不鲁棒。基于 watermarking 和基于 retrieval 检索的方案能扛住变换，却依赖模型或私有签名，难以做到公开可验证。所以三者无法同时占满，现实部署只能叠加不同的方案。这里要留意，retrieval 不一定涉及水印，这也不是一张性能对比图。Trilemma

这就解释了公开入口为什么必须是受控入口。要让任何人都能独立验证，就得公开检测器；可检测器一旦公开，攻击者就拿到了优化目标，可以专门针对它训练移除攻击。于是平台只能在两者之间取舍：保留登录和配额，把检测器藏在一道界面后面，同时用条款拦住批量探测。下表把三条限制和它们各自对应的性质放在一起看：

除了这三条，官方还说明会短期保存一份媒体签名用于反滥用，并在规定时间后永久删除，原始媒体在查验后立即删除。这些操作细节共同指向一个目标：让公开门户不至于变成一个可以反复试探、直到把水印规律摸出来的提取工具。需要说明的是，公开端每天允许查验几次这类具体配额，没有第一方来源，本文只按"低配额"定性描述。

受控的代价也有实感。Aaronson 在他的博文里直言，Google 把 SynthID 的检测能力 heavily restricted，只开放给可信测试者，这让他的学术同行很为难，因为他们一直想要一个办法来判断学生作业有没有用 AI 代写。他目前给同事的推荐是转向 Pangram 这类基于统计偏好的检测器，而不是靠水印。Aaronson

所以受控入口是制度设计与技术约束互相牵制的产物，不是产品做错了。理解了水印单打独斗的局限，最后一章要回答的就是：光靠一个水印，可信的来源查验还缺什么？

六、一个水印之外，可信的来源查验还缺哪几块拼图？

水印解决的是"内容里有没有信号"，它回答不了"这份内容是谁在什么时候签名确认的、之后被谁改过"。这部分由内容凭证承担。C2PA 是这一层的规范，它的核心信息单元是 manifest，一份被数字签名的容器，由 Claim Signature、Claim 和 Assertions 三部分嵌套组成。C2PA Spec

图注：manifest 是一个被签名包裹起来的三层结构。外层是 C2PA Manifest，往里依次是 Claim Signature、Claim 和 Assertions。Claim 把为这份内容背书的是哪些 assertion 打包起来，Claim Signature 用签名者的私钥对 Claim 签名，Assertions 里则是关于内容的具体声明。图中浅紫色的几个方块只是占位符，不代表某个具体的标准断言。C2PA Spec

规范把"绑定到内容"的方式分成两类，这段是理解互补关系的关键。硬绑定是一串密码学哈希，唯一标识整份内容或其中一部分，它能证明"这份 manifest 属于这个文件，而且文件自签后没被改过"，代价是一旦内容被重新编码或改动一字节，凭证就失效。软绑定则不同，它是从内容的数字表示里算出来的标识，可以是内容指纹，也可以是嵌进去的不可见水印，因此换了编码、改了分辨率仍可能匹配上。规范规定一份 manifest 最多含一条硬绑定，却可以含零条或多条软绑定。

这两类绑定的分工，正好是水印与凭证互补的物理基础。当一份内容的 manifest 被人为剥离之后，如果来源仓库里还存着这份 manifest 的副本，就可以用软绑定把它重新匹配回来。C2PA 甚至把这套恢复流程做成了标准接口：

图注：这是 C2PA 的通用 manifest 恢复流程，四条生命线分别是客户端、manifest、软绑定算法清单和 manifest 仓库。客户端先取得水印算法清单，逐个尝试检测内容里的水印，命中后经软绑定接口按内容或按绑定反查，取回原来的 manifest。要注意这不是 SynthID Detector 的流程，而是 C2PA 标准里通用的恢复路径。C2PA SBR

水印和凭证的并用，不是本文的推导，SynthID 论文的部署章节就写明了这一点。单靠检索指纹相对更易误报，单靠水印相对更易漏检，两者失效模式互补；为了防住伪造攻击，一张图不仅要带正确的水印 payload，还要能匹配上仓库里存的嵌入之一。SynthID-Image

现实中的推进也在按这个方向走。Google 在 2026 年 5 月的公告里提到，Pixel 10 是第一台内置 C2PA 内容凭证的手机，内容凭证的查验正在往 Gemini App、Search 和 Chrome 铺开。Google SynthID

而水印制度本身，也不只是厂商自愿的事。Aaronson 把水印部署放进一个集体行动框架里：加州 SB-942 只覆盖视听内容、把文本排除在外；Anthropic 在 2026 年 8 月部署 Claude 文本水印，据称是受欧盟法规推动，并承诺"任何人都能做检测"，但检测 API 当时还在开发中；OpenAI 早期曾因担心客户流失而拒绝部署水印，后来据 Aaronson 转述才可能跟进。Aaronson

把这一层放进来之后，整幅图就清楚了。SynthID Detector 是这条来源查验链上的一个节点，而不是终点。可信的体系需要几块拼在一起：鲁棒的生成端水印负责"内容里写过什么"，C2PA 凭证负责"谁签名确认过、编辑链是什么"，原始采集凭证负责"内容从哪来"，事实核查负责"内容陈述是否为真"。任何单独一块都会留一个洞，水印的洞是脆弱和未覆盖，凭证的洞是易被剥离。SynthID Detector 真正的贡献，是把这个"拼接证据"的过程往前推了一步，它给出的是一条来源线索，而不是一个真假按钮。

参考文献

本专题引用的核心资料如下，建议深入学习时阅读原文：

1. Google expands SynthID Detector for AI content — https://blog.google/innovation-and-ai/models-and-research/google-deepmind/synth-id-ai-content/
2. SynthID-Image: Image watermarking at internet scale — arXiv:2510.09263
3. Scalable watermarking for identifying large language model outputs (SynthID-Text) — https://www.nature.com/articles/s41586-024-08025-4
4. C2PA Content Credentials Technical Specification 2.4 — https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html
5. SoK: Watermarking for AI-Generated Content — arXiv:2411.18479
6. On the Difficulty of Constructing a Robust and Publicly-Detectable Watermark — https://proceedings.mlr.press/v258/fairoze25a.html
7. MarkNull: Model-Agnostic Watermark Removal in AI-Generated Images via On-Manifold Latent Manipulation — arXiv:2608.10166
8. Invisible Image Watermark Attacks: A Survey — https://www.preprints.org/manuscript/202609.1697/v1
9. WAVES: Benchmarking the Robustness of Image Watermarks — https://proceedings.mlr.press/v235/an24a.html
10. Anthropic's LLM watermarking (Scott Aaronson, Shtetl-Optimized) — https://scottaaronson.blog/?p=10032