SWEET：大语言模型的选择性水印

摘要

背景与问题

大语言模型出色的生成能力引发了伦理与法律层面的担忧，于是通过嵌入水印来检测机器生成文本的方法逐渐发展起来。但现有工作在代码生成任务中无法良好发挥作用，原因在于代码生成任务本身的特性（代码有其特定的语法、逻辑结构，与一般自然文本生成规律不同，现有水印方法适配性不足），具体表现为对代码质量的保留效果差。

通过扩展了 “修改对数（logit - modifying）” 的水印方法，提出了 “通过熵阈值选择的水印（Selective WatErmarking via Entropy Thresholding，SWEET）”。其核心思路是：在生成和检测水印时，移除低熵的代码片段。低熵通常意味着内容更具确定性、规律性（比如代码中重复的结构、固定的语法模板等），移除这类片段有助于让水印更贴合代码生成的特点，减少对代码正常逻辑和质量的干扰。

第一章 引言

图1

大语言模型（LLMs）在代码生成领域的表现，正以惊人速度向专家水准靠拢。从提升软件工程师的生产效率，到降低非专业人士编程的门槛，它带来的便利有目共睹。但就像一枚硬币有正反两面，大模型在代码领域的飞速发展，也带来了一系列法律、伦理和安全方面的 “暗礁”。代码许可争议、剽窃问题、漏洞隐患，还有恶意软件生成等，都让人们忧心忡忡。比如，一群个人和微软、GitHub、OpenAI 之间，就因涉嫌非法使用与复制源代码，陷入了一场版权集体诉讼。更让人警惕的是，ChatGPT 推出后不久，暗网上就有不少恶意分子分享机器生成的恶意软件和鱼叉式网络钓鱼教程。

在这样的背景下，开发能检测机器生成代码的可靠工具，就成了迫在眉睫且意义重大的事，这对公平部署具备编码能力的大语言模型来说，是关键一步。而像论文里提到的 “SWEET（通过熵阈值选择的水印）” 这类技术，就是探索解决之道的尝试。它致力于在保证代码质量的同时，有效检测出机器生成的代码，为代码生成领域的知识产权保护、安全规范等，提供更有力的技术支撑，助力大模型在代码世界里更健康地发展。

尽管机器生成代码的检测问题亟待解决，但目前针对该问题的研究成果寥寥。相反，众多研究仍将重点放在普通文本的检测问题上（引用了 Solaiman 等人 2019 年、Ippolito 等人 2020 年等诸多相关研究）。

虽然这些 “事后检测” 方法（即在文本生成过程中不进行控制）在自然语言处理的众多领域展现出了强大的性能，但它们在编程语言领域的应用仍未得到充分探索。简单来说，就是现在大家更关注普通文本的检测，而机器生成代码的检测研究很缺，而且那些适用于普通文本的事后检测方法，在代码领域还没怎么被研究过能不能用。

与 “事后检测” 方法不同，另一种用于检测机器生成文本的研究方向受到了关注：基于水印的方法。这类方法会在生成的文本中嵌入隐藏信号（引用了 Kirchenbauer 等人 2023a、b；Kuditipudi 等人 2023；Wang 等人 2023 的研究）。

以 Kirchenbauer 等人（2023a）提出的一种方法为例（我们称之为 WLLM，即大语言模型水印法）：在每一个生成步骤中，它会将整个词汇表随机分成两组（即 “绿色列表” 和 “红色列表”），并提高从绿色列表中选取标记（tokens）的概率。具体来说，通过给绿色列表标记的对数概率（logits）添加标量值，模型会更倾向于生成绿色列表中的标记，而非红色列表里的。要检测文本中的水印，我们需要统计绿色标记的数量，然后通过假设检验来判断这个数量是否具有统计显著性，从而推断出模型输出是否是在不了解 “绿 - 红规则” 的情况下生成的。

虽然基于水印的方法和事后检测方法在许多语言生成任务中都能很好地发挥作用，但我们观察到，这些性能在代码生成任务中并不能很好地迁移，比如在图 1 中就有体现。换句话说，以一种可检测的方式嵌入水印，同时又不损害代码功能，要困难得多。我们将此归因于代码生成熵极低的特性。

如果强力应用水印，会严重降低模型输出的质量，这在代码生成中尤为关键，因为哪怕违反一条规则，都可能使整个代码崩溃（见图 1 中的 “强水印”）。另一方面，如果水印应用得太弱，低熵会阻碍水印的恰当嵌入，导致绿色标记出现不足，进而增加检测难度（见图 1 中的 “弱水印”）。这些问题在普通文本生成中并不显著，因为相对较高的熵让水印候选选择更具灵活性。

1.1方法提出与优势

为了解决这些失效模式，我们扩展了 WLLM，并为代码大语言模型（以及通用大语言模型）提出了通过熵阈值选择的水印方法（Selective WatErmarking via Entropy Thresholding，SWEET）。不再对生成过程中的每个标记都应用 “绿 - 红” 规则，而是仅对熵足够高（基于设定的阈值）的标记应用该规则（这是与KGW方法的最大区别）。也就是说，我们不对那些对实现代码功能至关重要的标记应用 “绿 - 红” 规则，同时确保有足够多的绿色列表标记，以便为不太重要的标记生成可检测的水印，从而直接解决上述每种失效模式。在代码生成任务中，我们的方法在检测机器生成代码方面超越了所有基准方法（包括事后检测方法），同时实现的代码质量下降程度比 WLLM 更小。此外，通过各种分析，我们证明即使在没有提示词，或者使用小型替代模型的情况下，我们的方法也能很好地运行，这表明它在实际场景中具有鲁棒性。

1.2研究贡献

我们的贡献如下：

• 我们是首个通过实证探索现有水印和事后检测方法在代码领域失效情况的研究。
• 我们提出了一种简单却有效的方法，名为 SWEET，它改进了 WLLM（Kirchenbauer 等人，2023），在机器生成代码检测方面实现了显著更高的性能，同时比 WLLM 更好地保留了代码质量。
• 我们已经证明了我们的方法在现实场景中的实用性和优越性，例如：1）不使用提示词；2）使用更小的模型作为检测器；3）面对改写攻击时。

第二章 相关工作

2.1软件水印（Software Watermarking）

软件水印是一个研究领域，旨在在不影响代码性能的前提下，将秘密信号嵌入代码中，以防止软件盗版。

• 静态水印（Static watermarking）（Hamilton and Danicic, 2011；Li and Liu, 2010；Myles et al., 2005）：通常通过代码替换和重新排序的方式来嵌入水印。
• 动态水印（Dynamic watermarking）（Wang et al., 2018；Ma et al., 2019）：则是在程序的编译或执行阶段注入水印。（若需详细综述，可参考 Dey et al., 2018）。

从大语言模型（LLM）生成的代码文本中嵌入水印，与静态水印更为接近。例如，Li 等人（2023c）提出了一种使用同义代码替换的方法。不过，由于这种方法严重依赖特定语言的规则，恶意用户一旦知晓这些规则，就可能逆向破解水印。

2.2大语言模型文本水印（LLM Text Watermarking）

大多数针对大语言模型（LLM）生成文本的水印方法，都是基于通过预先定义的规则集合（Atallah et al., 2001, 2002；Kim et al., 2003；Topkara et al., 2006；Jalil and Mirza, 2009；Meral et al., 2009；He et al., 2022a,b），或者另一个语言模型（比如基于 Transformer 的网络，Abdelnabi and Fritz, 2021；Yang et al., 2022；Yoo et al., 2023）来修改原始文本。

近来，有一类研究工作聚焦于在 LLM 的采样过程中，将水印嵌入到标记（tokens）里（Liu et al., 2024）。它们通过两种方式在 LLM 生成的文本中嵌入水印：一是修改来自 LLM 的对数概率（logits）（Kirchenbauer et al., 2023a,b；Liu et al., 2023a；Takezawa et al., 2023；Hu et al., 2023）；二是操控采样过程（Christ et al., 2023；Kuditipudi et al., 2023）。此外，一些近期的研究关注水印对抗攻击的鲁棒性，即抵御移除水印的攻击（Zhao et al., 2023；Liu et al., 2023b；Ren et al., 2023）。最后，Gu 等人（2023）研究了水印在从教师模型到学生模型的蒸馏过程中的可学习性。

然而，这些水印方法在低熵场景下，水印检测性能会出现脆弱性（Kirchenbauer et al., 2023a；Kuditipudi et al., 2023），仅有少数研究（如 CTWL，Wang et al., 2023）试图解决这一问题。我们直接针对低熵情况下水印检测性能下降的问题，并在低熵任务（如代码生成）中证明了我们方法的有效性。

2.3事后检测（Post - hoc Detection）

事后检测方法的目标是在生成过程中不嵌入任何信号的情况下，区分出人类创作的文本和机器生成的文本。

其中一条研究路线是利用基于困惑度的特征，像 GPTZero（Tian 和 Cui，2023）、Sniffer（Li 等人，2023a）以及 LLMDet（Wu 等人，2023）都属于这类。另一条研究路线则是使用预训练的语言模型，例如 RoBERTa（Liu 等人，2019），并对其进行微调，将其作为分类器来识别文本来源（Solaiman 等人，2019；Ippolito 等人，2020；OpenAI，2023b；Guo 等人，2023；Yu 等人，2023；Mitrović等人，2023）。

与此同时，一些近期的研究在没有额外训练流程的情况下解决检测问题，比如 GLTR（Gehrmann 等人，2019）、DetectGPT（Mitchell 等人，2023）以及 DNA - GPT（Yang 等人，2023）。不过，事后检测方法仍然面临挑战。例如，虽然 GPTZero（Tian 和 Cui，2023）仍在使用，但 OpenAI 的 AI 文本分类器（OpenAI，2023b）在推出仅六个月后就因准确率问题停止使用了。此外，我们已经证明，事后检测方法在检测低熵的机器生成代码时是失败的。

第三章 方法（Method）

我们提出了一种新的水印方法 ——SWEET，它仅对熵足够高的标记（tokens）进行选择性水印嵌入。

3.1 动机（Motivation）

尽管之前的水印方法 WLLM（Kirchenbauer 等人，2023a）可以应用于大语言模型（LLM）生成文本的任何领域，但在代码生成中进行水印嵌入和检测时，会引发两个关键问题，这归因于水印强度方面的困境。

水印会导致性能下降。在编程语言中，表达相同含义的方式仅有少数几种，而且一个错误的标记就可能导致不理想的输出。如果像 WLLM 那样强力嵌入水印（WLLM 会在不利用任何上下文信息的情况下，随机将词汇表分为绿色和红色列表，只提升绿色列表标记的对数概率），必然会增加生成错误标记的可能性。例如，在图 2（a）中，第二行的 “return” 标记之后，对数概率最高的下一个标记是 “sum”，这也是标准解决方案的一部分。但 WLLM 把 “sum” 放到了红色列表，而把 “mean” 放到了绿色列表。因此，采样到的标记是 “mean”，从而导致了语法错误。

图2

3.2图2解析：

• 问题与标准解法：左侧呈现了 HumanEval/4 的问题（要求实现计算平均绝对偏差的函数）以及标准的正确解法。
• 不同方法的代码生成与指标：
  • （a）WLLM：生成的代码存在错误（Correctness 为 ×），水印可检测性低（z - score 仅 2.45，水印嵌入比例 1.0）。代码里错误地使用了mean相关操作，偏离了标准解法中基于sum计算均值的逻辑。
  • （b）SWEET - 低熵阈值：生成的代码仍错误（Correctness 为 ×），虽 z - score 提升到 3.39，但水印嵌入比例降至 0.44，代码质量未得到有效改善。
  • （c）SWEET - 中等熵阈值：生成的代码正确（Correctness 为√），z - score 达到峰值 4.96，水印嵌入比例 0.20。代码逻辑贴合标准解法，通过合理的变量定义（如distances列表）和计算步骤，实现了平均绝对偏差的正确计算。
  • （d）SWEET - 高熵阈值：代码正确（Correctness 为√），z - score 为 4.67，水印嵌入比例 0.19。代码逻辑同样正确，但相比中等熵阈值，z - score 有所下降。

3.3低熵序列会避免被加水印。

另一个关键问题是，当水印强度过弱，无法在低熵文本中嵌入水印时，若红色列表的标记具有极高的对数概率（logit）值，以至于必然会被生成，就会阻碍水印检测。例如，在图 2（a）中，带有白色背景的标记代表低熵且几乎没有候选标记。这在代码生成任务中会变得更为致命，因为代码生成的结果相对普通文本更短，比如只要求生成一个函数的代码块⁶。WLLM 的检测方法基于统计检验，涉及统计整个长度内绿色列表标记的数量。然而，如果文本长度较短，基于统计检验的水印检测效果就会下降⁷。