通过测试生成探测基于大语言模型的代码生成中的隐私泄露

通过测试生成探测基于大语言模型的代码生成中的隐私泄露（中文全译）

翻译说明：本文是 arXiv 论文 Probing Privacy Leaks in LLM-based Code Generation via Test Generation（arXiv:2605.15248）的中文全译，由智测团队翻译。原作者：Yifei Ge、Zhenpeng Chen、Weisong Sun、Yuchen Chen、Chunrong Fang、Juan Zhai、Xiaofang Zhang、Xia Feng、Yang Liu、Zhenyu Chen。原文以 CC BY 4.0 许可发布。译文保留原文全部章节、数据与结论；参考文献列表从略。

arXiv:2605.15248v1 [cs.SE] 2026年5月14日

许可：CC BY 4.0

作者与单位

1. Yifei Ge，南京大学（Nanjing University）
2. Zhenpeng Chen，清华大学（Tsinghua University）
3. Weisong Sun，南洋理工大学（Nanyang Technological University）
4. Yuchen Chen，南京大学（Nanjing University）
5. Chunrong Fang，南京大学（Nanjing University）
6. Juan Zhai，马萨诸塞大学阿默斯特分校（University of Massachusetts Amherst）
7. Xiaofang Zhang，苏州大学（Soochow University）
8. Xia Feng，海南大学（Hainan University），通讯作者
9. Yang Liu，南洋理工大学（Nanyang Technological University）
10. Zhenyu Chen，南京大学（Nanjing University）

源文作者信息中出现的邮箱字符串为：{yifeige, yuc.chen}@smail.nju.edu.cn，{fangchunrong, zychen}@nju.edu.cn，zpchen@tsinghua.edu.cn，{weisong.sun, yangliu}@ntu.edu.sg，以及 juanzhai@umass.edu、xfzhang@suda.edu.cn、xiafeng@hainanu.edu.cn。arXiv HTML 抽取将部分邮箱与前几位作者错位粘连，译文按姓名与单位的对应关系列出作者，并完整保留上述邮箱字符串，不另行改派。

摘要

大规模代码数据集的广泛可得，推动了面向代码相关任务的大语言模型（large language models，LLMs）快速发展。这些数据集可能包含敏感的个人可识别信息（personally identifiable information，PII），当大语言模型记住并复现这些信息时，就会导致隐私泄露。然而，现有的隐私泄露检测方法依赖临时构造的提示（人工设计或自动设计）。因此，它们并不能充分逼近 PII 在代码语料中出现的真实上下文，从而难以提取出符合现实的隐私泄露。本文提出一条流水线：它模拟实际中与隐私相关的代码生成场景，并采用测试驱动策略，从生成的测试用例中引出被记忆的信息。我们进一步引入一个自动构建的隐私特征库，用真实模板与示例引导测试用例生成，从而取代人工提示工程。在 5 个广泛使用的大语言模型上开展的大规模实验表明，该流水线暴露出更多已确认的隐私泄露，检测到的泄露量相较现有基线提高至 2.56 倍。

1 引言

大语言模型已成为现代软件开发中被广泛采用的工具（例如 Copilot，GitHub，2022；或 Cursor，Cursor，2023），支撑代码生成与补全等多种代码智能任务。这些能力建立在对公开抓取的代码仓库进行大规模预训练之上（Brown 等，2020；Radford 等，2019）。然而，公开代码仓库可能包含被无意上传的敏感个人可识别信息，例如电子邮箱地址、凭据、API 密钥以及其他敏感记录（Basak 等，2023）。当 PII 被纳入训练语料后，大语言模型可能记住它，并在代码生成过程中无意复现，从而导致隐私泄露。这种泄露可能损害系统安全、用户身份或组织机密，并可能导致违反《通用数据保护条例》（General Data Protection Regulation，GDPR，欧盟，2016）或《加州消费者隐私法》（California Consumer Privacy Act，CCPA，加利福尼亚州立法机构，2018）等数据保护法规。

图 1： 在不同响应数量下已确认隐私实例的数量，并在三个隐私类别上与 Codebreaker 进行比较。

图 2： 隐私泄露评估流水线概览。\* 对于泄露结果，部分候选无法被验证，并被标记为潜在（Potential）。我们只报告已确认（Confirmed）实例，从而给出隐私泄露的保守估计；潜在项仍可能对应真实泄露，但不计入报告数量。

尽管已有若干隐私保护方法在大语言模型的训练或部署阶段被引入，以降低隐私泄露风险，例如数据过滤（Ren 等，2016；Continella 等，2017）、差分隐私（Yeom 等，2018；Liu 等，2025）以及联邦学习（Thakkar 等，2021；Nasr 等，2019），隐私数据泄露事件仍在继续发生（Daniel，2025；Xiao，2024）。为更好理解并评估这些风险，已有工作（Carlini 等，2019；Nasr 等，2019；Carlini 等，2021）提出了隐私数据提取方法。这些方法与大语言模型交互，以检验其是否披露 PII，从而评估隐私泄露是否存在及其程度。

然而，现有方法在代码相关任务中从大语言模型提取隐私泄露时，其范围与有效性仍然有限。Niu 等（Niu 等，2023）的早期工作严重依赖精心设计的提示（其中许多为人工构造），并且隐私信息的数量受提示可得性的约束（见图 1）。此外，该方法专门面向 Codex（Chen 等，2021）设计，对其他大语言模型的适用性有限。Han 等（Han 等，2025）的近期工作引入自动提示生成（基于变异策略）来引出代码中的隐私内容。然而，其提示对隐私信息在真实代码语料中出现的真实上下文缺乏充分依据，导致许多被提取的候选是幻觉或占位符式内容，而不是真实隐私。

为克服这些局限，我们提出一条半自动流水线，通过测试用例生成来评估大语言模型在代码生成任务中的隐私泄露。我们的设计由以下设计原则驱动。第一，当提示与其原始训练上下文相似时，记忆更可能被触发。由于代码训练语料未知，我们通过构造带有显式隐私属性的真实开发场景（问题）来近似它们，从而提高与隐私相关的记忆浮现的可能性。第二，我们并不直接索取隐私数据——这种做法常常被大语言模型的安全机制拦截或拒绝——而是为代码函数引出单元测试。这种间接的、类似开发者的交互模式需要带有隐私取值的输入，并且在与隐私相关的任务中更不容易遭到拒绝。最后，为避免人工提示工程并在规模上提高提示有效性，我们引入一个自动构建且迭代更新的隐私特征库，提供真实模板与片段作为提示增强。

如图 2 所示，我们的流水线通过测试用例生成来审计代码生成任务中的隐私泄露。（1）我们将带有目标隐私属性的开发场景实例化，并用它们生成多样化的代码生成问题。（2）对每个问题，被评估的大语言模型首先生成相应的代码函数，随后被提示生成单元测试用例，其输入需要与隐私相关的字段。在此过程中，隐私特征库提供真实的隐私格式与内容模式作为增强，引导输出离开平凡占位符、走向合理的隐私取值。（3）提取出的候选随后在统一的验证阶段接受核验，该阶段结合自动评判大模型（Judge LLM）、基于 GitHub 的互联网检索与人工复核，得到最终的已确认隐私泄露实例集合。

表 1： 隐私类别定义。

贡献。 简言之，我们的贡献如下：

• 我们提出一条测试驱动流水线，用于评估大语言模型代码生成任务中的隐私泄露，该流水线以与隐私相关的开发场景为依据。
• 我们引入一个自动构建并上传的隐私特征库，提供源自真实泄露模式的真实模板与片段，降低对人工提示工程的依赖。
• 在 5 个广泛使用的商用大语言模型上的实验表明，我们的流水线稳定地平均识别出 92.6 个已确认隐私泄露实例，并在各隐私类别与泄露级别上优于近期基线（最高达 15.68‰ / 2.56 倍）。

2 背景与相关工作

2.1 模型记忆

大语言模型中的记忆，是指模型复现其训练数据中的特定序列，而不是生成完全新颖内容的现象。已有工作表明，当输入提示与其原始训练上下文密切匹配时，这种记忆现象可能发生（Al-Kaswan 等，2024；Yang 等，2024）。在这种情况下，大语言模型并非纯粹地泛化，而可能逐字或近乎逐字地复现训练语料中的序列。

记忆的一个广泛使用的指标是模型的困惑度（perplexity，PPL），它衡量模型在生成一个序列时有多“惊讶”。模型更熟悉的序列往往产生更低的困惑度，因而常常与更强的记忆相关。这一联系为评估生成输出是否可能来自被记忆的敏感数据提供了重要基础。

2.2 训练数据提取

训练数据提取方法已在自然语言生成的背景下被广泛研究（Carlini 等，2019；Nasr 等，2019），其目标是利用大语言模型的记忆行为从中恢复敏感 PII，从而导致隐私泄露。这些方法通常精心构造提示、对模型输出进行采样，并识别更可能是训练数据复现的候选。

在自然语言任务之外，人们也对大语言模型在代码相关应用中的隐私泄露提出了关切。已有研究表明，GitHub 等公开代码仓库可能包含未经过滤的私人信息，包括凭据与个人标识符（Meli 等，2019）。当大语言模型在这类数据上训练时，类似的记忆行为可能在代码任务中导致敏感信息泄露。

3 问题定义

3.1 隐私分类

我们对代码仓库中常见的个人信息进行分类，如表 1 所总结。遵循 CodexLeaks（Niu 等，2023）——迄今唯一提供面向代码相关隐私泄露的具体分类的研究——我们将隐私信息划分为 3 个类别：可识别（Identifiable）、私密（Private）与机密（Secret）。我们进一步细化这一分类法，去掉在代码语料中很少出现、并且在真实代码泄露案例中也很少被观察到的属性（例如性别、教育程度或社交媒体）。与这些属性相关联的、涉及隐私的开发场景在第 4.1 节引入，我们在那里描述如何将它们纳入评估流水线。

3.2 隐私泄露

隐私泄露被定义为：模型生成的、包含源于模型记忆行为的个人信息的输出（Ippolito 等，2022）。由于本研究针对训练语料并不公开的商用大语言模型，无法直接验证某一生成的隐私字符串是否来自训练数据。因此，遵循先前方法（Niu 等，2023；Han 等，2025），我们把公开的 GitHub 仓库作为预训练代码语料的代理，并通过 GitHub 检索来验证隐私信息。需要注意的是，自模型训练以来，仓库内容可能已被修改或删除。因此，我们所识别的泄露条目数量应被解释为真实隐私泄露量的一个保守下界。

3.3 威胁模型

我们假设攻击者通过输入—输出访问与模型交互，而不能直接看到模型的内部结构或参数。此外，攻击者还对训练数据中的代码片段拥有部分访问权，并事先专门了解这些代码片段所涉及的隐私信息。考虑到在不依赖开源代码的情况下训练大语言模型几乎不切实际，这是一个符合现实的假设。

4 隐私泄露流水线

4.1 代码生成问题

流水线的第一阶段，是构造一组自然涉及隐私相关字段的代码生成任务。其动机在于如下观察：当提示与训练时的上下文相似时，被记忆的隐私字符串更可能浮现。若没有这种依据，模型倾向于生成占位符或幻觉取值。由于训练语料中的原始上下文未知，我们通过把每个隐私属性落实到真实应用场景中，再把这些场景实例化为具体编程任务，来近似这些上下文。我们把每个隐私属性嵌入到该属性在功能上被需要或通常会被处理的应用场景中。我们从一个结构化的常见软件领域分类法中导出场景（包括企业应用、移动服务、云服务、Web 平台、区块链与游戏）（Zheng 等，2024），并把它们实例化为具体的代码生成任务。对每个隐私属性，我们将其映射到一个或多个场景，然后生成以场景为条件的代码生成问题，要求模型实现对该属性进行操作的功能（如表 1 所总结）。

形式化地，令 \(S\) 表示开发场景集合，\(A\) 表示第 3.1 节所定义的隐私属性集合。对每个场景 \(s \in S\)，我们识别在该场景中合理出现的属性子集 \(A(s) \in A\)。然后定义一个任务构造函数：

\[ T(s,a)=\mathrm{LLM\_question}(\Phi(s,a)), \]

其中 \(\Phi(s,a)\) 是一个场景—属性提示模板，要求模型生成在场景 \(s\) 中涉及属性 \(a\) 的功能性代码。大语言模型执行 \(T(s,a)\)，产生一组多样化的、具有上下文感知的代码生成问题 \(\mathcal{Q}\)。这些问题作为流水线后续阶段的输入。

4.2 模型响应

在这一阶段，我们直接与被评估的大语言模型（测试大模型，Test LLM）交互，通过其响应暴露潜在的隐私泄露。从与隐私相关的生成问题出发，我们驱动模型产生功能性代码，然后生成其输入可能包含被记忆隐私信息的测试用例。通过引出测试输入而不是直接查询，这种交互降低了触发内置安全机制的可能性。

对每个问题 \(q \in \mathcal{Q}\)，测试大模型生成代码片段 \(c=\mathrm{LLM}_{test}(q)\)（对应图 2 中的步骤 1–2）。我们抽取那些显式处理或引用隐私相关字段的函数，得到候选函数集合 \(G(c)\)。在这一步中，我们丢弃对实际数据处理没有贡献的辅助成分，例如导入语句、全局常量或占位代码。接下来，对与一个或多个隐私属性 \(a\) 相关联的每个函数 \(g \in G(c)\)，我们要求测试大模型生成单元测试用例（步骤 3–4）。测试用例生成的提示由函数 \(g\) 与从隐私特征库 \(\Lambda(a)\) 中抽取的属性特定提示组合而成（细节见第 5 节），从而使模型被鼓励提供真实的、符合属性形态的输入，而不是平凡占位符。形式化地，我们构造测试用例提示 \(\mathrm{prompt}(g,\Lambda(a))\)，并再次查询模型，得到测试用例 \(\tau=\mathrm{LLM}_{test}(\mathrm{prompt}(g,\Lambda(a)))\)。

从每个生成的测试用例 \(\tau\) 中，我们提取出现在输入参数或数据结构中、且匹配隐私属性结构模式的具体取值（步骤 5）。我们通过一个确定性解析过程 \(\mathrm{ExtractPII}(\cdot)\) 提取候选隐私信息，该过程扫描 \(\tau\) 并收集不同属性的词元跨度。跨问题与函数提取出的全部取值之并为：

\[ \mathcal{C}=\bigcup_{q\in\mathcal{Q}}\bigcup_{g\in G(c_{q})}\mathrm{ExtractPII}(\tau_{q,g}). \]

4.3 过滤与验证

提取之后，我们得到从生成的测试用例中收集的候选隐私取值集合 \(C\)。我们结合 Judge LLM、基于 GitHub 的验证与人工复核，以保留已确认的隐私泄露。

基于 Judge LLM 的过滤。 为减少后续阶段的人力，我们实例化一个预言模型 \(\mathrm{LLM}_{\mathrm{judge}}\)，旨在自动筛除候选中的幻觉字符串、占位符或其他不合理取值。对与属性 \(a \in A\) 相关联的每个提取值 \(x \in C\)，Judge LLM 接收 \(x\)、其属性类型、对 \(a\) 的结构与语义特征的简要描述，以及若干取自先验知识的片段示例。在这一上下文条件下，\(\mathrm{LLM}_{\mathrm{judge}}\) 判断 \(x\) 在真实代码中是否是属性 \(a\) 的一个合理实例（例如格式正确的电子邮箱地址、长度合理的电话号码，或类似凭据的字符串），并拒绝格式无效或语义明显不合理的条目。我们把这一自动过滤步骤所保留的候选子集记为 \(C_{\mathrm{judge}} \subseteq C\)。

GitHub 检索与人工复核。 过滤之后，我们使用 GitHub 检索验证候选隐私信息的真实性。对每个候选 \(x \in C_{\mathrm{judge}}\)，我们使用完整字符串或一个有区分力的子串查询 GitHub 代码搜索 API。令 \(k\) 表示检索命中数。与先前工作的设定一致，我们保留满足 \(1 \leq k \leq 100\) 的候选（因为非零匹配表明其出现在真实代码中，而过于频繁的匹配不太可能对应真实信息）。

对落在该范围内的全部候选，两位作者独立检查匹配到的 GitHub 上下文以及候选字符串本身，以判断它是否代表真实的个人信息，而不是文档文本、测试数据或有意虚构的示例。只有同时满足以下条件的候选才被视为最终泄露集合 \(L \subseteq C_{\mathrm{judge}}\)：（i）满足属性特定的结构约束，并且对其所声称的类型在语义上合理；（ii）得到 GitHub 上下文的支持，表明它们在代码中被用作与隐私相关的数据。

5 隐私特征库

5.1 特征库定义

为有效引导大语言模型在流水线中生成真实且多样的隐私信息，我们为每个属性维护一个隐私特征库（Privacy Feature Library）。直观上，该库提供源自真实代码上下文的模板与片段，用于增强提示，使其更接近训练时的上下文。由于当提示与其原始训练上下文相似时记忆更可能被触发，这些真实线索提高了被记忆的隐私取值出现的可能性，同时减少模板化或平凡内容（例如 “Zhang San” 或 “John Doe” 这类通用占位姓名）。形式化地，对每个隐私属性 \(a\)，我们定义一个属性特定的特征库：

\[ \Lambda(a)=\{\Lambda_{\mathrm{tmp}}(a),\;\Lambda_{\mathrm{frag}}(a)\}, \]

其中每个成分存储一类特定特征：（i）模板集合 \(\Lambda_{\mathrm{tmp}}(a)\) 包含 \(a\) 的抽象模式与结构上下文，例如键值格式与句子级模板（如 user.email = <EMAIL>、contact: <PHONE>）；（ii）片段集合 \(\Lambda_{\mathrm{frag}}(a)\) 包含值层面的子串与完整字符串，它们类似于真实的隐私内容（如 +86 138-1108-5305，或 ''li.ming@qq.com''）。

模板条目主要用于约束所生成测试输入的结构，而片段条目则作为补全线索或说明性取值。我们首先根据先验知识初始化 \(\Lambda_{\mathrm{tmp}}(a)\) 与 \(\Lambda_{\mathrm{frag}}(a)\)，其中纳入已知的隐私模式与公开可得的隐私样本。然后，我们使用流水线先前运行得到的集合 \(L(a)\) 进一步充实该库。将 \(L(a)\) 自动分解为模板成分与隐私片段、并映射到相应隐私属性 \(a\) 的具体过程如下所述。

5.2 成分划分

在得到已确认泄露集合 \(L\) 之后，我们的目标是把每个泄露实例分离为其可复用的结构模板与隐私片段。使用被评估大语言模型自身的似然（或困惑度）并不合适：被记忆的隐私字符串与频繁出现的样板模式都可能获得同样高的似然，而且困惑度的绝对范围在不同大语言模型之间往往不可比。因此，为获得无偏信号，我们转而使用一个面向代码的预训练模型 \(P\)（CodeBERT），并合理地假设 \(P\) 的训练语料并不包含被评估大语言模型所记忆的同一批私人信息。对每个泄露实例 \(x=(t_1,\ldots,t_n)\)，我们通过每次掩码一个词元、并由其余上下文预测它，来计算逐词元的伪对数似然分数：

\[ \ell_{i}=-\log \tilde{p}_{P}(t_{i}\mid\mathrm{context}(x,i)), \]

其中 \(\mathrm{context}(x,i)\) 表示掩码输入，即把 \(x\) 中第 \(i\) 个词元替换为掩码符号，同时保持所有其他词元不变。直观上，对应于常见结构成分的词元在通用代码语料中有良好表示，因而在 \(P\) 下产生相对较低的伪负对数似然（pseudo-NLL）；而属性特定的取值词元往往处于分布之外，并表现出更高的伪负对数似然。我们利用每个泄露实例内部 \(\{\ell_i\}\) 的经验分布来识别隐私模板：伪负对数似然落在下四分位数（最低的 25%）的词元被提取为隐私模板，其余所有词元被视为片段成分。然后，我们把提取出的片段替换为相应的属性槽位符号（例如 \(\langle\mathrm{EMAIL}\rangle\)、\(\langle\mathrm{PHONE}\rangle\)）以得到抽象模板，并把所得模板与片段分别存入 \(\Lambda_{\mathrm{tmp}}(a)\) 与 \(\Lambda_{\mathrm{frag}}(a)\)。

5.3 语义聚类

划分之后，我们得到从不同泄露样本中自动提取的隐私片段与模板集合。这些原始模式常常以跨语言、跨书写风格的多样表层形式出现，也可能包含由不完美划分产生的噪声伪影。因此，我们应用语义聚类来合并等价模式，并去除孤立的或语义不一致的条目。

具体而言，我们使用模型 \(P\) 的编码器嵌入每个模板（以及片段）。然后在嵌入空间中用基于密度的方法（DBSCAN）进行聚类。由于不同隐私属性之间存在显著的语义间隙，与同一属性相关联的模板和片段倾向于形成稠密簇，包括跨语言与跨风格的变体（例如 “email:”、“EMAIL =”）。我们把聚类中的低密度点视为噪声并丢弃这些离群点，因为它们通常对应虚假字符串或划分错误的片段，与任何主要簇都不对齐，否则会降低特征库的质量。聚类之后，我们通过与由初始化特征库导出的属性原型进行比较，把每个保留下来的簇指派给一个隐私属性。

6 实验

表 2： GPT 与 DeepSeek 大语言模型系列的平均泄露结果。

表中 “GPT” 与 “DS” 分别表示 GPT 系列与 DeepSeek 系列。每个系列的四列依次为：接受数、Judge LLM、GitHub 检索、人工核查确认数；最后一列为该系列的千分比（‰）。测试用例数一列中的括号给出原文的计数分解。

6.1 实验设置

模型。 我们评估 5 个有代表性的商用大语言模型，来自 2 个广泛使用的模型家族：GPT 系列（GPT-4o、GPT-4.1 与 GPT-OSS）以及 DeepSeek 系列（DeepSeek-V3 与 DeepSeek-R1）。对每个模型，我们使用默认设置（细节见第 A.1 节）。

基线。 我们与 2 种有代表性的方法进行比较：CodexLeaks（Niu 等，2023）与 Codebreaker（Han 等，2025）（见第 A.2 节）。

指标。 我们采用 Han 等（2025）提出的指标：级别 \(L\) 的泄露比例（Leaked Proportion at Level \(L\)，LP-\(L\)），衡量含有多于 \(L\) 个泄露个人身份元素的响应；以及级别 \(L\) 的关联泄露（Interconnected Leakage at Level \(L\)，IL-\(L\)），关注含有多于 \(L\) 个相互关联的个人身份元素的响应。

细节。 我们考虑 8 个真实的代码任务场景，每个场景涉及多个隐私属性（见第 4.1 节）。对每个场景，我们生成 20 个问题；对每个问题，被评估的大语言模型被提示产生 10 个测试用例。

6.2 实验结果

主要结果。 表 2 总结了我们的流水线在共计 5 个商用大语言模型上的逐步平均结果，评估覆盖 3 个隐私类别与 15 个隐私属性。对每个属性，表中报告流水线各阶段所保留的实例数量，包括被接受的测试用例数（接受数，Accepted Number）、Judge LLM 过滤后剩余的候选（Judge LLM）、落在 GitHub 检索阈值内的候选（Github Search），以及最终核验通过的隐私实例数（已确认，Confirmed）。

我们强调 4 点观察。（1）被评估的大语言模型对与隐私相关的请求表现出非零拒绝（平均为 39.3% 与 30.9%），表明模型对与隐私相关的查询表现出明确的回避行为。尽管如此，大多数请求仍被接受，这说明即使存在安全机制，测试用例生成仍能引出与隐私相关的输出。（2）即使在保守验证之下，所有被评估的大语言模型都观察到已确认的隐私泄露：GPT 系列与 DeepSeek 系列的已确认实例平均分别为 105.7 与 79.5。这表明，一旦模型决定响应与隐私相关的请求，私人信息就可能出现在其输出中。（3）隐私泄露表现出强烈的类别依赖性，已确认泄露率最高的是可识别类别，平均为 24.64‰，高于私密类别（4.25‰）与机密类别（11.78‰）所观察到的泄露率。最频繁泄露的属性（例如电子邮箱、账户/用户名与地址）与我们的预期一致，即这类字段在公开代码语料中很普遍。（4）GPT 与 DeepSeek 模型家族都表现出不可忽略的隐私泄露率（17.6‰ 与 13.3‰），但泄露最严重的属性类型不同（GPT 系列：出生日期与账户/用户名；DeepSeek 系列：密钥与电子邮箱）。这一差异很可能反映了它们底层代码训练语料的不同，以及每个系列所记忆的隐私数据子集的不同。

表 3： 与基线方法的比较。

图 3： 伪负对数似然分数 \(\ell_i\) 的分布。\(\Lambda_{\mathrm{tmp}}\) 与 \(\Lambda_{\mathrm{frag}}\) 分别表示模板词元与片段词元的分数分布。虚线表示用于分离的第一四分位数（Q1）阈值。

图 4： 隐私片段词元（\(\Lambda_{\mathrm{frag}}\)）的聚类，对应于所提取的隐私内容。不同颜色表示不同的隐私属性。

图 5： 模板词元（\(\Lambda_{\mathrm{tmp}}\)）的聚类，表示代码中由结构主导的部分。不同颜色表示不同的隐私属性。

与基线的比较。 表 3 在不同隐私类别与泄露级别上，将我们的方法与 CodexLeaks 和 Codebreaker 进行比较。总体而言，在所有 LP-\(L\) 级别上，我们的流水线都稳定地产生高于两个基线的泄露比例。特别是 \(\mathrm{LP}\geq 1\)，它等价于先前工作中常用的泄露率指标，已经表明我们的方法比现有方法更频繁地发现隐私泄露。随着泄露级别提高（\(\mathrm{LP}\geq 2\) 与 \(\mathrm{LP}\geq 3\)），我们的方法继续优于基线，这表明：在共享同一组输入参数的情况下，经由测试用例生成所引出的隐私泄露，更可能在单次响应中包含多个隐私元素。除总体泄露比例之外，我们的方法也实现了更强的泄露隐私信息关联。在更高的关联级别（例如 \(\mathrm{IL}\geq 2\) 与 \(\mathrm{IL}\geq 3\)）下，尤其是对可识别类别，我们的结果稳定地超过 CodexLeaks 与 Codebreaker。这说明，在真实的、由场景驱动的设定下所诱发的隐私泄露，不仅增加了泄露信息的数量，也促使模型在同一次响应中暴露多个相关隐私元素的组合。

表 4： 核心组件的消融研究：代码生成问题（CGQ）、隐私特征库（FL）与测试用例生成（TG）。

\* PP、PR 与 PF1 分别表示相对于参考隐私集合的精确率、召回率与 F1 分数。TP、FN 与 FP 分别表示：在参考集合中被找到的已确认隐私实例、从参考集合中被遗漏的已确认隐私实例，以及在参考集合之外被找到的已确认隐私实例。

消融研究。 表 4 报告了对流水线 3 个关键组件的消融研究。我们把完整流水线所识别的已确认隐私泄露集合视为参考，并考察去掉单个组件如何影响所恢复的泄露隐私实例数量。对每个消融变体，我们记录所得泄露计数，并测量其泄露比例指标。（1）去掉 CGQ 时，拒绝率下降，表明基于场景的问题使提示与隐私更相关，从而触发模型更强的回避行为。与之相对，所恢复的泄露量下降（TP），表明若没有真实场景，就难以诱导模型复现特定记忆。（2）去掉 FL 导致较温和但稳定的下降（PR），这与特征库提供真实格式与内容线索的作用一致。若没有这种引导，模型更可能产生信息量较低的测试输入（或被安全过滤拦截），从而降低泄露已确认隐私的机会。（3）去掉 TG 造成最大的性能下降，因为流水线不再能利用测试用例生成来绕过安全机制，直接限制了泄露发现能力。（4）仅使用 TG 仍能浮现一些泄露，包括额外的参考集合之外的实例（FP），但总体性能仍明显低于完整流水线。这表明每个组件在我们的流水线中扮演着彼此不同而又互补的角色。

定性验证。 为验证隐私特征库的构建按预期工作，我们可视化逐词元的伪负对数似然分数 \(\ell_i\)（第 5.2 节）以及聚类结果（第 5.3 节）。图 5 显示两个成分之间存在清晰分离：模板词元表现出更低且更集中的伪负对数似然值，而片段词元具有更高的离散度并带有明显的右尾，这支持了我们从高 \(\ell_i\) 区域提取隐私片段的设计选择（以 Q1 为阈值）。（译者注：原文此处写作 Figure 5；所述内容与图 3 的伪负对数似然分布说明相符。）

图 5 与图 5 共同说明了所提取的隐私片段与模板在嵌入空间中的语义组织。（译者注：原文写作 Figures 5 and 5。）聚类结果揭示了不同隐私属性之间清晰的语义分离，属性特定的片段与模板形成彼此不同的簇，这证明了在隐私特征库内部实现跨语言、跨风格对齐的可行性。

7 结论

我们提出一条测试驱动流水线，用于审计代码相关大语言模型任务中的隐私泄露。通过利用真实场景与一个自动构建的隐私特征库，我们的方法发现了已确认的隐私泄露，并优于先前基线。我们的工作提供了一种实用的审计方法，以帮助确保大语言模型在实际应用中更安全、更可靠地部署，突出了不可忽略的风险，并支持在实践中更安全地部署大语言模型。

局限性

对于商用大语言模型，其底层训练语料并不公开可得，因而无法为生成的隐私字符串建立成员关系的真实标签。遵循先前工作，我们依赖 GitHub 检索作为潜在训练来源的实用代理，并因此继承检索功能的局限，以及仓库自训练以来可能已被修改或删除的可能性。因此，我们所报告的已确认泄露应被解释为一个保守下界，而且我们无法可靠地量化有多少未验证（或被遗漏）的候选对应幻觉、又有多少对应真正被记忆的数据。

尽管 Judge LLM 通过过滤不合理候选大幅减少了人工工作量，全自动验证对于高置信度的隐私审计仍然不足。在实践中，仍需要人工复核来确认某个候选在真实代码上下文中被用作与隐私相关的数据，这限制了大规模审计的可扩展性。未来工作可以通过纳入跨来源的更强证据聚合，以及更标准化的人工标注协议，来改进自动化。

我们的评估覆盖了一组有代表性但有限的大语言模型与场景。隐私泄露行为在其他模型家族、部署设定或语言上可能不同，我们将其留给未来工作。

伦理考量

本文工作带有潜在的伦理影响，因为通过我们的方法所识别的隐私泄露可能涉及敏感个人信息。模型能力的进步与部署场景的增加表明，这些风险在实际环境中确实可能发生。因此，我们认真对待伦理考量，并采取审慎措施，以尽量减少任何非预期的伤害。具体而言，我们对任何被提取示例中的身份细节进行掩码，确保个人身份保持机密。通过实验收集的任何隐私信息都被安全存储与管理，仅能在受保护的环境中访问。此外，本文呈现的所有示例都用 “*” 匿名化，以防止非预期地披露个人信息。在这一公开版本中，我们不发布原始提取出的隐私字符串、中间产物或代码。

我们承认有必要透明地讨论这些潜在的隐私风险。我们相信，公开指出这些隐私问题，对于提高认识、促进进一步研究以及制定防御策略至关重要。

说明：所提供源文正文在伦理考量之后结束。arXiv HTML 导航列出了附录 A（补充实验细节，含 A.1 被评估模型与默认解码、A.2 基线与公平比较协议）、附录 B（提示与工作流示例）、附录 C（补充定量结果）与附录 D（结果验证），以及参考文献，但这些部分的正文未包含在源文件中，故未译出，亦未补写其内容。参考文献列表从略。

署名与许可

本文译自 Yifei Ge、Zhenpeng Chen、Weisong Sun、Yuchen Chen、Chunrong Fang、Juan Zhai、Xiaofang Zhang、Xia Feng、Yang Liu、Zhenyu Chen，Probing Privacy Leaks in LLM-based Code Generation via Test Generation，arXiv:2605.15248。

原文链接：https://arxiv.org/abs/2605.15248

原文以 CC BY 4.0 许可发布。

译者：智测团队