AI 漏洞扫描器开发避坑：为什么初期追求高召回率反而容易走弯路

很多开发者在利用 LLM 构建安全工具时，很容易陷入一个误区：盯着 F1 分数看，试图在第一版就跑出一个漂亮的召回率（Recall）。但实际上，如果一开始就追求“全覆盖”，你大概率会掩盖掉底层引擎的逻辑缺陷，导致后期陷入无止境的调优泥潭。

最近我在实操一个 AI 漏洞扫描器时，在 OWASP Benchmark（Java 安全扫描标准测试集）上跑了一次压力测试，结果非常极端。在面对 777 个真实漏洞的测试样本时，我的扫描结果显示召回率仅为 0.07，也就是说 93% 的漏洞都被漏掉了。

如果按照常规的 KPI 考核，这个结果简直是灾难。但从工程验证的角度来看，这次实测给我的信号反而是积极的。

来看一下具体的终端输出：

$ python scripts/score_benchmark.py --findings out/java.findings.json \
 --truth benchmark-java/expectedresults-1.2.csv

OVERALL precision 0.60 recall 0.07 F1 0.13

在这个数据模型中，精准率（Precision）维持在 0.60。这意味着虽然工具捕捉到的漏洞数量极少，但只要它敢报出来，有 60% 的概率是真实的 Bug。

我的设计架构采用的是「确定性静态分析 + LLM 判定」的流水线模式：首先利用静态分析规则去搜寻潜在的漏洞路径，然后将这些可疑点交给大模型进行二次判定，剔除误报。在这次 Spike 版本测试中，我故意采取了极简策略，只定义了一个 getParameter 的 source 模式去对接几个 sink 点。

为什么在这种情况下，0.07 的召回率反而是一个“好信号”？

因为在开发 AI 工具的初期，验证链路的正确性（Correctness）远比刷高指标重要。如果这次测试结果跑出来是“精准率 0.10，召回率 0.80”，我反而会非常焦虑。因为高召回率伴随低精准率，通常意味着底层引擎在“瞎猜”或者规则写得过于宽泛，导致 LLM 被大量垃圾数据淹没，此时即便通过 Prompt 优化，也很难在短时间内提升质量。

而现在的结果清晰地告诉我：这套“静态分析 → LLM 过滤”的流水线是跑得通的。目前的低召回率并不是因为逻辑错误，而是因为我的“词汇量”太小。这就好比在守卫一座有几十扇门的房子时，我目前只在其中一扇门安装了监控，漏掉从其他门进来的贼是必然的，但这并不代表监控摄像头本身坏了。

对于想要从零构建 AI 安全工具的工程师来说，这个实操经验非常有参考价值：先确保精准率在可接受范围内，验证最小闭环。只要判定逻辑是正确的，提升召回率只需要简单地增加 source 列表或扩充规则库，这属于线性增长的体力活；而如果底层引擎逻辑混乱，那么修复它将是一个指数级难度的问题。

总结来说，不要被一个完美的 F1 分数给欺骗了。在原型阶段，一个“精准但狭窄”的工具，比一个“全面但混乱”的工具更具有迭代价值。