我们到底是在防范后门还是未能察觉它们

后门评估通常遵循一个标准流程：在包含触发器的输入上评估模型输出。从表面看，结论似乎明确——若模型在接收到触发器后未表现出后门行为，则被认为是鲁棒的[1]。

然而，这一过程忽略了一个关键环节；AI安全研究人员和评估构建者需要仔细验证触发器是否真正抵达了模型。在模型接收用户输入之前，会经过一个上下文管道对输入进行改写。至少，原始用户文本通常会被包裹在聊天模板中，例如“<|user|> … <|assistant|>”。若输入过长，系统会采用截断或摘要策略来丢弃部分token，以适配设定的上下文窗口。长时间的对话可能触发完整的记忆策略，仅保留最近的回复，或使用摘要替换部分内容。检索增强生成（RAG）系统则会将这些信息打包进检索到的文档中。最后，所有这些内容都会被分词器token化。

上述每一个步骤都有可能删除触发器。如果触发器在模型处理之前就被移除，那么模型的输出就无法反映其真实的鲁棒性。本研究的目的是直接量化这一机制。作为第一阶段，我们构建了一个工具：在原始输入中嵌入一个无害字符串——称为“金丝雀”——然后让该输入经过真实的上下文管道，并记录该“金丝雀”是否最终出现在模型接收到的token中。在近百万次试验中，很大一部分原本被归类为“触发器检测失败”的情况，实际上都是“交付失败”。所有代码，包括可复现的模块，均可在 https://github.com/sks17/LLMBackdoorPipelineHygeine 获取。当六个阶段全部完成后，我们计划撰写一份更详细的报告。

我们在四个层级上记录触发器的存续状态，并使用了三种基础对话来源——一个由Qwen模型生成的合成对话生成器、来自LMSYS-CHAT-1M和WildChat的真实人机对话，以及来自Project Gutenberg的长文档。这三个来源被输入到一个函数中，该函数会填充或裁剪至目标token长度，并加入如{{PREFIX_SLOT}}或{{OLD_TURN_SLOT}}等占位符，用于标记稍后可以插入触发器的位置。

这种数据来源方法行之有效，因为用于生成合成对话的LLM没有先前的上下文或触发器，且合成对话会经过与定义数据集相同的测试工具。每次试验我们记录四个标志，分别称为L1、L2、L3和L4。

• L1 (原始): 触发器是否在刚插入后的原始消息中？这用于区分对照试验和真实试验。
• L2 (记忆策略后): 触发器在经历记忆策略（如保留最近、摘要等）处理后是否仍然存在？
• L3 (模板化后): 触发器在完整的模板化文本中，经过聊天格式化后是否仍然存在？
• L4 (最终token): 触发器是否保留到了最终的token ID中，经过截断后？

为确保鲁棒性和可复现性，我们执行了近百万次试验，其分布如下。该方法完全独立于模型权重，因为所有被操控的属性都属于分词器。该系列的第二部分将专注于从机制上确定后门如何影响模型。

另一个值得关注的方面是[2]中提到的机械异常检测入口。

“边界触发器”指的是那些被截断部分分割的触发器。总试验次数是多次重试的结果，详见该项目的GitHub。

我们还运行了相同数据但无金丝雀的试验，以确保触发器并非偶然出现在对话或数据集中。简而言之，在458,100次试验中，没有一次是在触发器不存在的情况下被错误检测到。

这些试验得出了以下交付数据。从表面看，该测试装置的结果确实提供了值得关注的警示。

第一行“无”是对照组。每个单元格均为1.00，意味着所有触发器都成功交付，除了最后一列。tool_output列显示了来自类似agent函数或RAG系统的上下文丢失结果。这就是truncate_tail为何会如此显著地降低其触发器交付率；工具输出往往是最先被添加的内容。对于审计agent或检索系统来说，这是一个重要的注意事项。通过工具结果到达的触发器比普通聊天文本中的更脆弱，而非更坚固，而尾部丢弃策略几乎每次都会将其吞噬。

“截断开头”策略只保留最后N个token，丢弃前面的部分。不出所料，这会以很高的概率删除前缀触发器和旧轮次触发器。系统提示的存活率也相似，因为它们通常位于提示开头。由于本次实验的触发器插入非常“干净”，相同位置的触发器被删除的概率也高度相似——在本例中，热图上的许多点在小数点后五位都保持一致。

“截断结尾”策略则从上下文末尾移除token。该方法下触发器交付率最高的，是那些位于上下文前端的系统触发器，达到0.97。这与一个更广泛的解释一致：触发器的存活率，既取决于模型本身，也同样取决于上下文管道。

这些结果的一致性表明，对于那些没有明确检查潜在触发器删除的测试工具，存在明显的改进空间。即使在不需要运行近两倍试验、不需要通过解释模型激活来检测后门的情况下，仅仅将触发器移动到更不易受模型记忆和截断策略影响的区域，也能带来鲁棒性的提升。下表描述了潜在错误归因的细分情况。

错误归因率

支持“各模型结果相似是因为它们使用了非常相似（甚至相同）的分词器”这一说法的证据是，Gemma在TOST（双单侧检验）下未能通过等价性测试。其他模型有系统角色，但Gemma没有，而是将第一条系统消息与用户轮次合并。这种角色迁移也是研究者需要考虑的一个重要变量。对于专注于系统或用户的截断策略，如果预期不明确，触发器检测器可能会产生更多误报。

真实AI对话和合成对话的触发器存活率也看起来非常相似，唯一的例外是LMSYS和WildChat在“保留最近消息”策略上与长文档数据集存在差异。由于文档没有消息，这个结果是预料之中的。

各数据集下的存活率

尚未涵盖的策略是摘要，它会把旧的轮次转换成更短的、由LLM撰写的版本，并可能产生与截断不同的问题。该系列的第二部分将从机制上解释一个模型，以确定它是否正在执行类似后门的指令，但在此范围内，我们使用了一个语义评分系统来判断模型是否包含接近自然语言触发器的信息。与随机金丝雀或Unicode不同，这种类型的触发器即使在LLM进行压缩后，也可能保留信息。由于这个评分器是概率性的、依赖于模型且具有一定的随机性，我们首先在一个包含或不包含金丝雀的试验数据集上对其进行了调优。它还通过一组人工标注的摘要/触发器对进行了验证，达到了88%的精确率和88%的召回率。下表中的阈值由无触发器的孪生试验停止触发摘要器的位置定义。

语义存活率

这些试验的信息突显了一些低成本的改进措施，如果你在构建后门或触发器评估，可以采纳。首先，也是最直接的，记录最终的token ID可能比记录原始输入重要得多。其次，确保你理解你的触发器是如何与截断策略交互的——无论是用户输入、系统输入、摘要、尾部截断、头部截断，还是这些操作的某种组合。最后，对于自然语言触发器，应当限制对原始字符串匹配的信任。

[1] https://arxiv.org/abs/2408.12798
[2] https://github.com/sks17/LLMBackdoorPipelineHygeine

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：我们到底是在防范后门还是未能察觉它们要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题