少样本示例造成的租户泄露：当你的提示词库变成跨客户数据存储库

打开一个日益成熟的 AI 产品的生产环境系统提示词（system prompt），向下滑过角色描述，你几乎总能看到一个标有 # Examples 或 ## Few-shot demonstrations 的部分。这些示例非常出色——它们很具体，具有领域针对性，且精准地匹配了上季度评估集（eval set）中表现不佳的失败模式。但在仔细观察后，你发现它们其实也是真实的客户数据。来自真实账户的真实工单 ID。从支持会话中原封不动摘录的措辞模式。某个租户使用的内部产品代码，而其他客户群从未听说过。

把这些示例放进去的团队并不是粗心大意。这些示例进入提示词的方式与好示例一贯进入提示词的方式相同：有人从生产环境的追踪（traces）中挖掘出模型处理不佳的案例，挑选出最干净的现成示例，将其粘贴到系统消息中，看着评估分数上升，然后发布。这条从生产环境追踪到系统提示词的流水线，是现代 LLM 工程中最可靠的提示词改进闭环。但这也是团队在不知不觉中构建的一个结构性跨租户数据泄露渠道，而系统提示词已悄然变成了一个数据处理协议（DPA）从未涵盖的多租户数据存储库。

导致泄露的挖掘流水线

泄露并非始于粗心的工程师。它始于每个发布 LLM 功能的人最终都会采用的反馈闭环，因为除此之外的替代方案更糟。从零开始编写的合成示例往往平淡无奇；模型会模仿这些模式，产生同样平淡的输出。真实的生产环境追踪携带着用户实际措辞的质感、实际出现的边界情况以及实际需要教学的失败模式。因此，提示词改进周期固定为一种熟悉的模式：查看上周失败的评估案例，寻找三四个通过小示例就能引导模型走上正轨的案例，将它们复制到提示词中，进行 A/B 测试，然后发布。

在“复制示例”和“发布”之间发生的变化，本应是一个清洗（scrubbing）步骤。在实践中，这个步骤通常并不存在，即使存在，也只是编写提示词的工程师进行的单次审查——这位工程师通常不在安全或法律团队，他不知道 “Acme Logistics” 是一个真实客户的名字，不知道工单 ID 的格式可以还原到特定账户，也不知道示例中的措辞模式具有足够的辨识度，以至于原客户一眼就能认出来。

随后，系统提示词会发布给每个租户。无论登录的是哪个客户，每个会话都会将这些少样本（few-shot）示例作为其上下文的一部分进行读取。模型现在在租户 B、租户 C 以及其他所有租户的每个请求中都会接触到租户 A 的数据。这种暴露并非理论上的——它被编码在提示词加载的架构中。唯一的问题在于，模型是否以及何时会将其被展示的内容呈现出来。

为什么模型会复述

从机械角度看，上下文学习（In-context learning）是向模型展示一小组输入/输出对的数据集，并要求其复现该模式。这种模式不仅包括结构形状（问题跟在 User: 前缀后，答案跟在 Assistant: 后），还包括示例本身的词汇内容。当一个新的查询到来，且在结构上与某个示例相似时，模型已经在预训练、指令微调和提示词本身的条件约束中被训练过，去提取示例中的 token 作为最接近的可用参考。

其结果是，少样本示例会通过多个渠道同时泄露，且程度各异：

• 相似查询下的逐字复述。 如果新租户的问题措辞与示例的输入足够接近，模型通常会给出一个直接从示例中提取命名实体的答案。客户名称、工单编号、本不该出现在新租户会话中的产品 SKU，最终都会出现在回复中。
• 保留识别信号的“洗白式”改写。 即使模型用新的词汇重写了示例，潜在的事实——异常的行业词汇、特定的工作流形状、仅差一个同义词的命名实体——对于最初产生这些内容的任何人来说都是可识别的。改写不是匿名化；它只是为法律团队提供了合理推诿的借口，而为发现这一情况的客户提供了法证证据。
• 语气和结构的分布偏移。 租户 A 的沟通风格——正式的语调、列清单的习惯、对破折号的热衷——会渗入到交付给租户 B 的每一个回复中。跨会话泄露研究表明，这是最容易检测到的跨租户信号之一，因为风格的一致性是一个可识别的指纹。
• 通过精心设计的提示词进行提取。 一个有动机的攻击者，甚至是出于好奇的普通客户，都可以通过提问来探测提示词，旨在直接诱导模型输出少样本内容。KV 缓存共享研究已经证明，即使是侧信道攻击也可以重建提示词内容；上下文复述则是一个更容易的向量，甚至不需要缓存计时分析。

这个架构层面的现实令人不安：系统提示词在功能上是模型处理每个请求时的工作记忆（working memory）的一部分。任何粘贴进去的内容都已被添加到一个共享的底层基质中，而模型在被提示时，会被训练积极地去复现这些内容。

没人提及的法律视角

加载中…