我构建了一个 AI 安全扫描器 —— 结果却在自己的检测器中发现了一个 Bug

提示词注入（Prompt injection）是 LLM 应用面临的首要安全风险之一。你向模型输入一段文本，要求它忽略原始指令。有时，模型真的会照做。

我构建了 AgentProbe 来测试这一点。它会针对越狱（jailbreaks）和数据提取（data extraction）等 8 个类别，发送 49 个攻击提示词。它会报告模型失败的频率。

真正的教训不在于扫描器本身，而在于我检测代码中的一个 Bug。

难点不在于攻击，而在于检测。

你如何知道模型是否真的服从了攻击？关键词匹配是最简单的方法。你可以寻找诸如“我无法提供帮助”之类的拒绝短语，或者诸如“开发者模式”之类的服从短语。

但模型会使用一种“先推诿后服从”（hedge-then-comply）的模式。它们会说“我无法提供帮助”，但随后还是会提供受限信息。在这种情况下，关键词匹配会失效，因为其中包含了拒绝短语。

为了解决这个问题，我使用了一个“LLM 作为裁判”（LLM-as-judge）的系统。我将对话内容发送给一个更强大的模型，让它判断目标模型是否真的服从了指令。我的计划是先使用廉价的关键词检查，只有在关键词检查结果不确定时，才调用昂贵的裁判模型。

然后，我发现了我的 Bug。

当我的关键词检测器发现“先推诿后服从”模式时，它会返回一个置信度为 1 的评分。然而，我的代码只有在置信度达到 2 或更高时，才会信任关键词阶段的结果。

这意味着我的“廉价”检测器实际上从未做出过决定。每一个案例都被升级到了昂贵的裁判模型。即使我的免费工具本可以处理，我却在为每一个案例支付裁判模型的费用。

这个错误教会了我关于使用 LLM 来评估其他 LLM 的三个教训：

• 裁判必须比目标模型更聪明。 如果裁判和目标模型规模相当，它也会存在同样的盲点。
• 准确率可能会骗人。 如果大多数模型都拒绝了，那么一个总是说“拒绝”的裁判看起来很准确，但其实并没有学到任何东西。应使用 Cohen's kappa 等指标来排除偶然因素的影响。
• 裁判必须是稳定的。 将同一个测试运行五次。如果裁判改变了主意，说明结果具有模糊性，需要人工介入。

如果你正在使用 LLM 进行开发，请记住以下几点：

• 检测服从比诱导服从更难。
• 留意那些在第一句话拒绝、但在第二句话却服从的模型。
• 不要盲目信任 LLM 裁判。要衡量其可靠性。
• 分享你的 Bug。发现自己的缺陷比一次完美的发布能让我学到更多。

Source: https://dev.to/nar1frames/i-built-an-ai-security-scanner-then-found-a-bug-in-my-own-detector-140a

Optional learning community: https://t.me/GyaanSetuAi