Who Wrote this Code? Watermarking for Code Generation

十二月 21, 2023 arxiv 本文总阅读量次

时间：2023.5

作者：Taehyun Lee, Seokhee Hong, Jaewoo Ahn, Ilgee Hong, Hwaran Lee, Sangdoo Yun, Jamin Shin, Gunhee Kim

会议：Arxiv

开源：https:// github.com/hongcheki/sweet-watermark

Abstract

随着大规模语言模型生成能力的显著提升,人们已经注意到使用它们会带来伦理和法律问题,比如剽窃和版权问题。为了解决这些问题,最近有人提出了几种为大语言模型生成的文本加入水印并进行检测的方法。但是,我们发现以前的方法无法很好地适用于代码生成任务,因为代码的语法和语义特征不同。基于Kirchenbauer等人(2023)的工作,我们提出一种新的水印方法 - 选择性基于熵阈值的水印(SWEET),它只在生成过程中词频分布熵值高的位置“偏爱”标记为“绿色”的词汇,从而保持生成代码的正确性。我们利用熵信息进行统计测试和Z分数来检测水印代码。我们在HumanEval和MBPP上的实验表明,相比其他方法,SWEET显著改进了代码正确性和水印检测性能的帕累托前线。我们还显示出著名的后处理检测方法(如DetectGPT)在这一任务中效果不佳。最后,我们证明设置一个合理的熵阈值并不是一个很大的挑战。

Background

最近，Kirchenbauer 等人（2023a）提出了一种水印技术–我们称之为 WLLM（大型语言模型水印技术）–在标记中嵌入一个隐藏的水印，表明文本是由语言模型生成的。与上述事后检测方法相反，WLLM 通过在生成的文本中嵌入检测信号，以牺牲文本质量为代价提高了检测能力。在每个生成步骤中，WLLM 都会随机地将整个词汇表分为两组（例如，绿表为我们想要嵌入水印的标记，红表为需要避免的标记）。绿色列表中的词组会在其对数值上加上一个标量。这样，模型就更倾向于从绿色列表而不是红色列表中生成标记。要检测文本中的水印，我们可以计算绿色标记的数量，并检查该数量是否具有统计学意义（通过假设检验），从而得出在不了解绿-红规则的情况下，得出模型输出是否生成的结论。

虽然 WLLM 和事后检测方法在许多语言生成任务中都能很好地发挥作用，但我们发现这些性能并不能很好地应用到代码生成任务中，如图 1 所示。我们将其归因于代码生成的极低熵4 特性。因此，与普通的自然语言生成相比，在不损害代码功能的前提下以可检测的方式为代码添加水印更具挑战性。如果使用强水印，就会严重降低模型输出的质量，这在代码生成中尤为关键，因为违反一条规则就可能破坏整个代码（见图 1 中的 “强水印”）。另一方面，如果水印应用得太弱，由于熵值较低，没有足够的绿色标记出现，导致检测难度增加（见图 1 中的 “弱水印”）。这些故障在纯文本生成中并不严重，因为相对较高的熵允许更灵活地选择水印候选对象5。为了解决这些故障模式，我们扩展了 WLLM，并提出了针对代码 LLM（和 LLM）的熵阈值选择性水印（SWEET）。在生成过程中，我们不会对每个标记应用绿-红规则，而是只对熵值足够高（给定阈值）的标记应用该规则。也就是说，我们不对制作功能代码的重要标记应用绿-红规则，同时确保有足够多的绿名单标记来为不太重要的标记制作可检测的水印，从而直接解决上述每一种失败模式。基于我们在代码完成基准 HumanEval和 MBPP上使用 StarCoder所做的实验。

我们的贡献总结为

我们是第一个以实证方法探索源代码领域现有水印和检测方法故障的人。
我们提出了一种名为 SWEET 的简单而有效的方法，该方法改进了 WLLM（Kirchenbauer 等人，2023a），并实现了对源代码的符号化。、
与 DetectGPT 等著名的事后检测方法相比，我们的方法显示出更高的 LLM 生成代码检测精度

Methodology

本文提出一种新的水印嵌入方法SWEET:

它的思路是:只为那些熵值高的词嵌入水印,而不是每个词都嵌入。

文章在Method部分主要描述了SWEET水印嵌入方法的详细内容:

提出了SWEET方法的动机,即WLLM方法直接应用于代码生成任务会出现功能下降和检测失败的问题。
描述了SWEET方法的生成阶段实现流程:
- 根据词汇表的熵值计算一个熵阈值H。
- 只对熵值大于H的词进行水印嵌入操作。
- 将词表随机划分为绿表和红表,给绿表词增加一个logit增益δ。
描述了SWEET方法的检测阶段实现流程:
- 将需要检测代码分为原始代码和LLM生成部分。
- 计算每个词的logit和熵值,选择熵大于H的词集S。
- 在S词集中统计绿表词数,并根据预期水印比例计算z-score。
阐述了如何设置熵阈值H,以人写代码的熵分布为参考。
总结提出SWEET方法的核心思想是选择性基于熵信息进行水印嵌入。

Sample

展示了一个具体的HumanEval[4]任务例子,这个例子会在后续讨论中反复使用。

(a) 对照组,直接使用WLLM方法,结果代码错误且水印难以检测。
(b)~(d) 用不同熵阈值运行SWEET方法:
- (b) 中位数阈值情况下,部分TOKEN未水印但代码正确。
- (c) 平均数阈值下,更多TOKEN水印且代码正确。
- (d) 第三四分位数阈值下,水印效果最好但代码仍正确。

![HumanEval/4为例](../imgs/[论文阅读]Who Wrote this Code Watermarking for Code Generation/image-20240103170836773.png)

用于比较 (a) WLLM 和 (b)-(d) 采用不同阈值的 SWEET。文本颜色标注了词块是在绿色还是红色列表中。灰色标记的熵小于阈值，不带水印。黄色背景颜色的强度可视化熵值。

为什么cd代码和ab不一样，选择的阈值不一样，因此代码结构和水印都不一样

那为什么在生成代码过程中绿词的频率会更高，红绿不是随机区分的吗

这是因为SWEET方法做了一定的“倾向调整”:

红绿词随机区分后,模型记下哪些是绿词,哪些是红词。
在真正生成代码时,模型会对绿词赋予一个更高的“logit增益”值(δ)。
概率公式中,logit越大,对应词的生成概率就越高。
所以给绿词赋予了更高的logit,就使它在生成过程中频率更高。

简单说,它是在保留随机性的基础上,增加模型“倾向”优先选择绿词的机制。

这样做的意义是:

代码质量不受影响,随机性使红绿词分布不规则。
但能明确增加绿词的频率,形成更明显的水印信号。

Abstract

Background

Methodology

Sample

Contributions