--- layout: post.njk source: https://yage.ai/share/google-synthid-text-image-watermark-20261016.html web_feed: articleId: cmvci3lwb0003edkbg57bxz8b feedSourceId: webfeed_yage_ai guid: https://yage.ai/share/google-synthid-text-image-watermark-20261016.html sourceUrl: https://yage.ai/share/google-synthid-text-image-watermark-20261016.html speaker: yage.ai title: |- Google SynthID 详解：为什么文字边写边打，图片却要等画完再补？ date: '2026-10-16' summary: 文章详细分析了Google SynthID系统在文字和图片上的水印技术实现，强调了其背后的工程考量。文字水印采用模型生成过程中的采样循环嵌入，实现低成本和高效率；而图像水印则在生成完成后通过独立的编码器网络进行后处理嵌入。文章指出，工程上的限制（如跨团队协作、海量验证的吞吐压力、版本长期共存）是决定文字和图像水印设计差异的关键，最终导致了文字水印的嵌入位置和图像水印的后处理方式不同。此外，文章还探讨了水印检测中的工程挑战，如如何使用保形预测替代硬币假设、如何应对高并发查验压力，以及如何设计兼容多代版本的验证系统。最终结论是，水印技术需要与C2PA等工具生态结合，并从工程实践中解决实际的落地问题。 area: tech-engineering category: architecture tags: - ai-watermarking - text-watermarking - image-watermarking - system-architecture - deployment people: [] companies_orgs: - Google products_models: - SynthID-Text - SynthID-Image - Gemini - Gemini Advanced - Claude media_books: [] draft: true status: evergreen --- 为AI生成的内容添加水印看起来像是一个算法问题，但实际上它涉及到大量的工程问题。当人们讨论AI水印时，往往认为这是一个复杂的密码学或数学问题。然而在实际应用中，算法往往是最容易解决的，而决定整个系统如何构建的关键因素往往是工程方面的限制，包括服务器的承载能力和团队间的合作。目前，Google 的 SynthID 是公开资料里覆盖最全的 AI 内容标识系统，涵盖了文字、图片、音频和视频四种模态。其中，音频和视频至今没有公开第一手的资料，只有文字和图片有公开的完整论文。 这两篇公开的论文完整记录了 Google 如何在真实业务中对海量内容进行水印。文字方面的论文是发在 Nature 上的 SynthID-Text，图片方面则是去年 10 月公开的图像水印生产部署论文（arxiv:2510.09263，副标题是 Image watermarking at internet scale）。借助图像侧的系统，Google 已经在多项线上服务中给超过 100 亿张图像和视频帧打了水印。读这篇论文，正好可以看清一个超大规模的水印基础设施，是如何在现实业务中被真正落地的。 把两篇论文放在一起看，会看到一个巨大的反差：同样在 SynthID 这个体系里，文字水印是在模型一个字一个字往外写的时候顺手做进去的，而图像水印却是等到整张图画完了，再单独挂在流水线末端补上去的。为什么选两种不同的做法，主要是三件工程上的现实逼出来的，和算法谁更高明关系不大：造模型的团队和管安全的团队各干各的，改一处就得两边对齐；生成一张图只要一次，可同一张图会有成千上万人反复查看；已经发到网上的图不能当没写过，旧版本的水印得一直能验。关于文本水印的三项核心约束（能不能看出来、能不能防伪造、传到网上能不能存活）以及它们构成的不可能三角，《Claude 给 AI 内容打水印：技术上九成是旧办法换了新场景》和《Invisible Signatures》已经梳理过脉络，想深入了解可以参考阅读。这里我们只讲这套系统背后的工程底牌。 ## 文本侧：改采样与极简检测 文本水印能够近乎零成本的实现，是整个系统的起点。如果没看懂文本水印是如何把开销压缩到近乎于零的，就看不明白为什么工程师在为图像打水印时会遇到如此大的工程阻力。 文本水印的实现非常简洁，它在模型选词的过程中施加了影响。语言模型在产生文本时，是一个词一个词产生的。每产生一个词，模型都会为字典里的每一个可能出现的词计算一个概率。SynthID-Text的思路非常简单，每产生一个词，系统就会从模型提供的概率分布中采样一些候选词，然后让他们进行比赛。这个比赛会进行几轮，系统使用一个只有系统知道的密钥（私钥）来给每个词打分，分数高的进入下一轮，最终决出一个获胜者。因为候选词本来就来自模型自己的概率分布，都是它认为说得通的词，所以不论选出哪个，都不会对文本质量造成太大损害。当需要检测是否存在水印时，我们只需要根据同样的规则和密钥对生成的文本进行打分即可。最简单的检测方法是，直接把每一轮的得分相加取平均，看看倾向性如何。这个方法叫做均值打分。 文本水印的检测也非常省资源，甚至不需要动用大模型。验证方只需要拿着那把保密钥匙，把文本里的词扫一遍算个统计分数就好。论文里明确写着：“watermark detection is computationally efficient, without using the underlying LLM”。这套系统在文字里没塞额外的作者名字或版本号这类额外信息，那把钥匙本身就是身份。在大规模线上业务检验中，团队抽样分析了大约 2000 万条 Gemini 的实际用户回复，发现加了水印后点赞率的差异只有 0.01%，点踩率的差异也只有 0.02%，两者在统计学上都不显著，说明用户几乎感觉不到差别。目前这套方案已经部署在 Gemini 和 Gemini Advanced 上；虽然 Google 开源了算法的参考实现，但线上跑的钥匙和具体参数没有公开。除了直接算平均分的均值打分，系统还有一种更稳妥的办法：先让计算机学习很多带水印和不带水印的文本，算出当前这篇文本有多大可能带水印，这套方案叫作贝叶斯评分。不过这种文字水印并不是牢不可破的：论文特别指出，只要把文字换个说法重新改写一遍，水印信号就会明显变弱。 ## 转折：文字的经验为什么搬不到图片上 文字水印之所以有效，是因为文字本身就占优势。一个能在文字上成功的方案，往往带有许多隐含条件。理解为什么这些经验难以直接移植到图像上，是理解后续图像水印为何要做那么多复杂权衡的关键。 第一个坑是文字和图片的物理结构不一样。文字是一排排独立的字，AI每写一个字都可以在若干备选字中挑选。图片是几百万个相邻像素，现代AI画图用的是扩散模型，相当于墨水在水里慢慢晕开，是一个连续的演化过程，没有一个个离散的可选字符。要想在整幅图像里嵌入人眼看不见的水印，就不能边写边选，而得专门训练两个深度神经网络——一个编码器把暗号藏在像素里，一个解码器把暗号找出来——把水印信号融进几百万个像素的细微明暗关系中。 但图片水印的介质一换，计算开销的压力就完全反过来了。给文章加水印只要几行几乎不耗算力的代码，检测也只是简单的算术统计；可图片水印只要打一次，整张图片就得完完整整跑一遍庞大的神经网络。更麻烦的是，系统在接收端面临着海量请求——平时很少有人会去全网逐篇扫描一段文字有没有水印，但图片水印从上线第一天开始，就要面对全网到处流传的海量图片。论文在分析效率时也明确指出，解码器的调用频次可能比编码器高出几个数量级，因为解码器不仅要在用户上传时检查，还要应付社交媒体的日常内容审核、搜索引擎抓取网页时的自动建库，以及其他大模型在全网清洗训练语料时的海量扫描。单台机器每秒钟能检查多少张图（解码吞吐率）直接成了卡死整套系统的核心瓶颈。 真正逼着工程团队做决策的，是不同组之间的协作和冲突。如果把水印硬塞进画图模型里面（这种定制化的做法，论文称之为ad-hoc），那只要上游画图组的模型结构一改，下游水印就可能跟着失效。论文中坦言，如果真的大规模使用，这种ad-hoc的方法没法用一个水印支持现在和未来的所有模型。因此团队只能退而求其次，采用事后加工（post-hoc）的方法，先画图，再额外加一个步骤打上水印。当然，事后加工需要改动已经生成的图像像素，是一种有损的修改。但团队通过算法设计，严格保证了画质底线，让画质的变化在肉眼上不可察觉。 同一套 SynthID 在文字和图片上用了两种嵌入位置：文字水印嵌在采样循环内部、边写边打，图片水印挂在生成完成后的流水线末端、画完再补。 ## 图像侧：这套系统到底长什么样 图像水印的整个流程非常简单，就像一个两道工序的流水线。上游的AI画图模型画完一个完整的图之后，直接把图交给一个独立的编码器网络（在通信理论里面，水印是想传递的暗号，原图是运送这个暗号的通道，把这个暗号刻进图里的网络叫编码器，也叫嵌入器）。编码器对整张图快速过一遍，生成打好了水印的新图交给用户。等到需要验证的时候，直接把图交给另一个对应的解码器网络来读取暗号。整个检测过程不需要原图对照，也不需要知道生成图片当时用的提示词，拿到图就能直接验，这在技术上面叫纯盲检。 除了能分清楚图片是不是 AI 生成的之外，这个水印还可以把一些详细的身份信息放进图片里面去。最原始的版本只是负责判断图片是不是 AI 生成的，但是在 SynthID-O 面向外部客户的版本里，工程师们可以在一张图片中嵌入多达 136 bits 的额外信息。这些额外的信息可以具体到是哪家公司用哪个版本的哪个 AI 模型生成的，让溯源变得非常精细。 为了让水印能在网上活下来，打水印和读水印的两个模型都是在各种折磨里一起练出来的。在开发训练阶段，负责打水印的编码器和读水印的解码器会绑在一起互相配合训练。训练时，系统会故意给图片施加各种摧残，比如把图片使劲压缩成低清JPEG、随手裁剪掉一块、乱改颜色，或者加一层模糊滤镜。两个网络就在这种严苛对抗里不断调整，学会把暗号藏在那些即使被乱改乱涂也依然能保留下来的图像特征里。等这套系统正式上线后，真正的攻防战就转移到了安全团队与外部黑客之间。 一张图片的生成有个基本物理限制：画完了才能加水印，不能边画边打。论文里强调音频视频可以一段一段生成，一段一段加水印，但单张静态图片必须整张画完才算数——也就是论文强调必须在生成完成之后才能打水印（“watermarking has to be performed after generation”）。这个先画完再打水印的先后顺序，直接卡死了后面所有工程设计的边界。 ## 图像侧：为什么这么设计，五个部署挑战 如果这个系统要部署到互联网上、每天处理海量查验请求，那真正致命的都是实际工程难题。技术走出实验室以后，考验系统的不再是论文里的理论分数，而是反应快不快、并发量撑不撑得住、老版本兼不兼容，以及能不能扛住别人恶意破解。弄懂下面这五个工程挑战，就能明白现实里的水印系统是怎样在性能和安全之间艰难走钢丝的。 ### 挑战一：插入位置与组织解耦 把打水印放在画图之后进行，最重要的好处是大幅降低跨组对齐的成本。在大厂里，做基础大模型的团队和安全/合规团队的目标和节奏往往非常不同。做模型的团队天天在改网络结构、调算法步数、加新训练模块，如果水印代码嵌在生成模型里面，每次模型一改，安全组就要跟着重新调一遍水印，双方天天在协调，产品很难快速迭代。 只要把水印做成独立的下游服务，两边就可以各自安心干活。安全团队把水印搭成一个标准的服务接口，无论上游用的是老古董模型还是未来研发出的全新模型，反正吐出来的都是一张张普通的彩色图片。安全团队想测算响应时间、定期更换加密钥匙、升级水印模型，还是增加监控开关，自己关起门来就能搞定，做大模型的团队基本不用改代码。这种分开干的做法虽然意味着要重新修改一遍图片的像素，但通过在水印模型里严格限制修改幅度，可以把画质变化控制在肉眼发现不了的范围内。 ### 挑战二：验证端面临的吞吐压力 只看生成一张图需要多少时间，会严重低估整个系统所面临的压力。在互联网的传播过程中，一张图只生成一次，但发出去以后，会被用户、爬虫和审核系统不断查看，对水印的查验需求也就跟着被放大。 负责查水印的解码器，调用频次可能比打水印高出好几个数量级。一张图在生成的时候，只需要打一次水印；可一旦发到了公网上，成千上万的用户在浏览，搜索引擎的爬虫在抓取建库，社交媒体的安全系统要一帧一帧过筛子，做大模型的团队还在全网抓图清洗数据做训练。这些场景都可能触发一次水印查验。而且在实际生产线上，查水印往往还要和 C2PA 电子凭证核对、图片尺寸缩放等操作一起并发执行（C2PA是一种防篡改的电子元数据身份凭证，后面会单独详细讲它跟水印怎么配合）。 因此，一台服务器每秒能处理多少张图像就成了整个系统能否落地的关键因素。如果设计一个非常庞大、复杂的读水印模型，那么每天全网海量的查验操作所需的服务器电费/算力成本将难以承受。工程团队需要把解码器做得尽可能简单，确保即使使用普通的服务器，也能在极高的访问并发度下支撑全网海量的查验需求。 水印的验证端要扛住比生成端高得多的查验流量：一次生成对应无数次查验，解码吞吐因此成为整套系统的核心瓶颈。 ### 挑战三：放弃硬币假设，引入保形预测 以往学界的水印检测方法过于理想化，拿到真实场景中会很容易把正常的图也误判为有水印。早期的研究通常会做一个简化假设：从图片中提取出来的每一个 0 或 1 都是互相独立的，就像一个硬币连续被抛掷，每次得到正面和反面的几率是一半一半（在数学上叫做伯努利分布）。在这种算法下，只要从图片中提取的暗号中有超过一定数量的正确匹配，就判定这个图片带水印。 但现实中的图片五花八门，不能当抛硬币一样计算。现实网上有很多图片包含大片纯蓝的天空，或者密密麻麻全是密集的建筑物线条，这些纹理会严重干扰读水印的模型，导致一些暗号莫名其妙地扎堆出现。如果还用抛硬币那套死公式计算的话，系统很容易把一个没打过水印的普通照片误判成AI图片，造成大规模误报。因此论文的团队抛弃了这种脱离实际的数学假设，而改用了一种直接拿真实数据当参考标准的统计方法：先在真实图片里找规律看正常的分数长什么样，再用这个标准来严谨核算有多大把握没判错，这套方法叫作保形预测，算出来的指标叫作conformal p-value。 用真实数据做标尺的保形预测，给工程维护带来三个好处：系统在上线前会留一组真实图片，专门用来当对照表看正常图能拿多少分。这给工程带来三个好处：第一，数学上保证误报率不超过预设红线；第二，如果图片剪烂了、信号太弱，检测器可以选择弃权，不强行下结论；第三，即使网上图片风格变化，运维人员只需收集新图片重跑对照表，而不必重训整个模型。 ### 挑战四：单向出街下的版本长期共存 还有一个重要的问题是，普通软件的升级和更新可以随时下线旧版本，但水印系统做不到这一点。一般的软件在发布新版本之后，服务器上的旧版本的接口就可以随时关掉。但打了水印的图片一旦发到了互联网上，就脱离了系统的控制，老图片永远都在。 一旦一个老版本的水印放出来了，那相应的检测工具就要永远支持这个版本。论文里也提到了，如果某个版本的编码器对一张图片进行了打码，那么这张图片可能会在互联网上传播若干年、甚至数十年，所以它理论上需要随时都可以被查验。因此，打水印的编码器的版本直接决定了整个系统的代号。只要有某个版本的打水印模型上线过，服务器上查水印的功能就不能关，而要一直支持查验。 为了对抗新的破解，查验系统还得同时养好几个代的识别能力。虽然对老版本水印的检测不能停，但查水印的解码器却需要经常更新，以防备黑客研究出的最新破解招数。因此线上的查验服务必须维护一个能兼容所有历史版本的矩阵：一个统一的查询入口，既要认得几年前第一代老模型打的暗号，也要能查第二代和各种定制版本打上的暗号。论文也提醒到，如果第一代打水印的代码留下了安全漏洞，这个毛病就会随着长期的多代兼容一直背下去，变成甩不掉的技术历史包袱。 ### 挑战五：威胁模型划分与防御四件套 在讨论防破解之前，我们先来看看黑客可能接触到的系统的不同部分。离开使用场景来讨论防御是没有意义的，因为论文里提到了三种不同的防御场景：第一种是完全内部系统，用户完全接触不到；第二种是对外提供API的云服务系统；第三种是对模型权重直接开源的系统。 最实用的防御通常并不涉及复杂的算法，而是基于服务器端的控制规则。例如，对于对外开放的接口，最简单的措施是在网关处设置调用频率限制（比如每秒最多查询几次）。这样一来，黑客就无法通过成千上万张测试图片进行高频试探，从而无法反推暗号规律。另一种方法是为签署了信任协议的企业客户提供打水印的模块，而不直接提供核心模型，防止黑客通过获取模型代码实现白盒破解。 对于只能从外部强行破解的黑盒攻击，论文提出了四个扎实的反制措施：一是通过抗破坏训练大幅抬高擦除成本，让攻击者必须把图片画质压到惨不忍睹或者消耗昂贵算力才能勉强抹掉水印，变得得不偿失；二是在每次打水印时加入一些随机变化，防止黑客找几百张打了相同水印的图片拼在一起做抵消攻击；三是把水印暗号和这幅画的具体画面内容绑在一起，防止别人把A图片里的有效暗号抠出来贴到B图片上移花接木；四是在遇到极端图片时主动不打水印。就像文本水印遇到死记硬背的古诗词这种固定格式文本会跳过一样，如果遇见一张整张纯白、纯黑或者几乎没有任何纹理的极简图片，图像水印系统也会主动放弃打水印，防止生硬嵌入暗号反而破坏了纯净画面。 ## 水印和 C2PA 怎么合作 当把 C2PA 的电子签名和隐式水印结合使用，两者恰好可以互补，形成更可靠的防护。很多人误以为这两种方案是在相互竞争，但实际上，在工程中它们往往可以相互配合。C2PA 就像给图片贴了一张带密码学防伪签名的数字身份证，只要这张身份证还贴在图片上，认出真伪的准确率极高；但在现实中，很多社交平台在转发图片时会自动把文件附加的元数据信息顺手抹掉，身份证一丢，C2PA 就查不出来了。而隐式水印则是把暗号直接刻进了几百万个像素的明暗关系里，哪怕平台把元数据抹得干干净净，暗号依然在，但它的缺点是在图片遭到严重模糊或涂抹时，暗号可能变淡。 两者结合再加上画面指纹比对，就能形成一个多层防线：攻击者即使能伪造一份假的 C2PA 签名，也很难伪造深藏在像素里提取出的 136 bits 业务信息，更难让它和后台数据库里的图像特征指纹对上。论文在结尾也坦率承认，单靠一套 SynthID-Image 无法单独解决假消息传播、身份冒用或版权纠纷，水印本身不能提供完整不可篡改的证据链条；它必须和 C2PA 这类凭证工具一起组成工具生态，靠整个行业的平台共同协作，才能在现实中真正发挥作用。 ## 收束：同一套底牌与新战线 ### 两篇论文共同满足的工程底牌 当我们把文字和图像这两篇论文放在一起看时，可以总结出一套放之四海而皆准的系统设计标准。抛开具体的模型结构不谈，这两套看似天差地别的系统，在顶层架构上其实共享着五条必须遵守的工程底牌： 用秘密钥匙做决定：不用普通的分类器去拍脑袋猜这个东西是不是 AI 写的，唯一的依据是自己拿到的秘密钥匙参与生成的暗号。 宁可不判也不误杀：不论是贝叶斯打分对文字，还是保形预测对图片，都把不误判正常内容作为第一准则，只要证据不足，宁可主动弃权说不知道，也不下结论。 把现实的破坏因素提前学进模型：图像模型在训练时就学会压缩、裁剪、滤镜等现实中的各种破坏操作；文本水印不像图像那样有端到端的训练环节，它抗改动的短板主要靠在检测和部署环节想办法（如文本一节所述）。 验证端要廉价高并发：文字检测不用大模型，图像检测以单机每秒能查多少张图为目标，用低廉的成本来应对全网的查验请求。 不自大：清醒意识到一个水印技术并不能解决所有伪造和版权的问题，主动把自己放在包括 C2PA 在内的整个产业治理生态中。 ### 跨模态系统设计对照表 把文字和图像两种方法放到同一个表里对比，就能一眼看清为什么它们会做不同的工程取舍： 系统考量维度 文本水印 SynthID-Text 图像水印 SynthID-Image 水印在什么时候打上去 模型一边挑词输出一边顺手打上 等整张图片画完后在流水线末端单独追加 暗号藏在什么地方 藏在备选词的挑选中，稍微偏向某些词 藏在整张图几百万个像素的细微明暗关系里 对生成质量有没有损伤 理论上几乎无损（候选来自模型自身的分布） 事实上微改了像素，靠严格算法把画质损失压到肉眼看不见 拿什么东西去查验 待测的文本加上保密钥匙 待测的图片加上保密钥匙（不需要原图对照） 里面能塞进多少信息 只有一个记号（不存额外内容，钥匙本身就是证明） 能存很多业务内容（SynthID-O 能存 136 bits 的身份证信息） 靠什么标准来下结论 算平均分或贝叶斯概率评分，证据不足就弃权 用真实数据做保形预测，算准把握，证据不足就弃权 技术对外界开源了吗 算法参考代码已开源，但线上用的保密钥匙不公开 模型文件不公开，检测服务只对签约测试者开放 跟上游画图/写字模型的关系 深度绑定（代码必须直接插进模型挑词的代码里） 解耦（做成独立服务，不管上游换什么模型都能直接用） ### 隐藏在算法背后的工程妥协 这两套看起来不同的算法，其实都是工程现实逼出来的妥协。为什么同一家公司做水印，文字是边写边做，图片是画完再补？决定这个差异的是三大工程现实：跨部门合作多麻烦，全网海量验证单台机器扛不扛得住，十年后老图片要不要继续查；跟算法研发人员觉得哪种数学模型更漂亮没关系，算法本身怎么设计要给这些现实让路。 ### 战线正在向验证端转移 水印技术发展到今天，真正关键的战场已经不在怎么加水印，而在怎么查水印。对外服务上，Google 已经上线了公开的检测接口，据媒体报道每天要处理大约一百万次查验请求。但在水印技术的整个行业生态里，各大厂商的文字水印已经走向各自为政：据媒体报道，Google 的 SynthID、Claude 所用的方案、OpenAI 的 textGrain 系统，三者各用一套标准、各持一套密钥，相互间无法识别。 在检测这一端，黑客和安全专家之间的对抗也十分激烈。黑客最简单的方法就是直接改写文本，让它的句式发生变化。苏黎世联邦理工学院的 SRI Lab 在公开审计中指出，仅通过改写文本，就能让 SynthID-Text 的水印消除率超过 90%。另外一种方法是针对开源代码中的默认检测器进行攻击：有研究显示，如果检测器仅仅把每次检测得到的分数相加取平均，那么通过增加淘汰赛轮数（层膨胀攻击）就能让检测器失效。对此，学者们建议改用前面提到的贝叶斯打分会更安全。为了解决中心化问题——只有平台自己有密钥才能检测——最近的研究也开始出现新的思路，比如一种叫做 PVMark 的方法，通过密码学的零知识证明，可以让第三方在没有密钥的情况下也可以进行检测，从而摆脱对大厂的中心化检测服务的依赖。 对于想搭建内容溯源系统的团队而言，这两篇论文提供了一把真正衡量水印系统是否合格的尺子。评估一个水印方案能否落地，不能只看打一次水印花几毫秒、肉眼能不能看出来这种表面功夫，而是要严厉拷问几件更骨感的工程问题：在面对复杂多变的真实内容时有没有用真实数据做校准，老版本的水印放出去了以后能不能长期兼容维护，对外接口有没有做好防刷防撞库的频率限制，以及当全网都把图片送过来查验的时候，系统能不能用便宜的硬件成本把天量的检测并发稳稳接下来。