不该用 LLM 做安全检查的架构思考

“所以你反对用 LLM 做安全防护？”

不。我反对的是偷懒的架构设计。让我解释一下两者的区别，因为这正是我正在构建的工具背后最核心的设计决策。

默认做法：让模型判断一切

目前 AI 安全领域的常见模式是：针对每一个请求，调用一次 LLM，然后问它：“这个请求是否恶意？”这种方式感觉很合理，因为模型能够理解细微的语义差异。但让前沿模型判断每一个请求，就像让你的资深工程师手动审查每一次提交中的每一行代码一样。不仅昂贵、缓慢，而且还没到午饭时间，他们就已经筋疲力尽了。

具体来说，在关键请求链路上使用 LLM-as-judge，会带来以下问题：

• 每个请求都会增加数百毫秒的延迟
• 按 token 计费，成本会随着流量增长
• 判断结果不确定（相同的输入，可能得到不同的答案）
• 安全层本身也是一个 LLM，因此它自己同样可能被 jailbreak

替代方案：逐级升级机制

与其只使用一个昂贵的判断器，不如把检测设计成多个层级：先执行成本最低的检测，只有当某个案例确实有必要时，才继续升级：

• Tier 1 — Regex。已知的攻击模式会在不到 1 毫秒内被拦截。
• Tier 2 — 传统 ML。使用 TF-IDF 和 logistic regression，对数万种攻击模式进行检测。结果确定、耗时约 7 毫秒、每次调用成本为 0 美元。绝大多数流量都不会通过这一层。
• Tier 3 — Transformer（可选）。当你希望对部分请求进行更深入的分析时，可以使用一个更重的模型。
• Tier 4 — 你的 LLM（自带模型）。对于真正模棱两可的案例，再升级到由你选择的模型：使用你自己的密钥，在你的预算上限内运行。通过成本门控，确保只有确实需要升级时才会触发。

这样一来，整个经济账就完全反转了。你不再需要为 100% 的请求支付 LLM 的费用，而只需为真正需要模型判断的极少数请求付费；并且这些判断会由你亲自选择的模型，在你自己的环境中完成。

用便宜且确定的方式处理多数，用聪明但昂贵的方式处理少数

这就是整个思路。它并不反对 LLM。这其实正是你在现实中组建安全团队的方式：快速的自动化检查负责处理海量请求，只有遇到棘手案例时，才会请昂贵的专家介入。

还有一个额外好处：由于始终开启的检测层都是确定性的，并且在本地运行，因此整个系统可以在你自己的 VPC 中以完全隔离网络的方式运行，无须调用任何托管模型。没有任何东西需要向外部服务器发送信息，因此它也不会这样做。

我为此做了一个 Demo，你可以实时观察这些快速检测层如何拦截攻击，无须注册：

https://g8kepr.com/demo-login

需要坦诚说明的权衡是：面对新颖而隐蔽的攻击时，确定性检测层的能力会弱于大模型，而这恰恰就是升级路径存在的原因。你的技术栈会如何判断一个请求是否值得接受昂贵的检查？我对此确实很好奇。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。