在网络安全领域，我们已有段时间没有更新相关话题了。近期我专注于AI应用落地的实践操作，积累了不少实战经验，今天想与大家分享关于AI安全审计的一些心得。

我们采用的是本地部署的GPU模式，虽然算力有限，但足以运行小规模Demo进行可行性验证。许多企业为了省事倾向使用付费或免费的云端模型，然而当涉及内部敏感日志数据时，这种做法并不可持续——数据一旦离开本地，安全风险便难以掌控。

因此，AI时代的安全工作面临着两难困境：一方面要推动员工使用AI提升效率，另一方面又必须严守AI数据安全的合规底线。本文旨在帮助安全团队在提效方面找到突破口——利用AI进行审计，从而减轻安全人员的工作负担。

需要说明的是，本文暂不讨论大流量生产环境，因为那种场景下本地推理算力的门槛过高，更适合金融行业来分享。我们聚焦于相对可控的场景，例如后台人员的操作日志、下载日志、访问日志等。只要数据来源于内部人员行为审计，且规模不是特别庞大，本地部署的方案完全可行。

本次测试的目标模型包括四个：Qwen2.5的32B和72B版本、DeepSeek R1，以及Qwen3的32B版本。AI前端平台采用本地搭建的Dify平台1.4.0版本，用于构建后台日志审计的工作流程。

具体流程如下：首先，使用自动化采集工具抓取后台日志——所有数据均经过脱敏处理后再传输，每次抓取一页，大约十条记录，超过此数量本地算力便无法支撑。数据传入Dify平台后，审计策略沿用传统规则，例如非工作时间的下载、大文件下载等。关键区别在于：整个流程无需安全开发人员编写任何代码，审计人员可以零代码完成操作，从而大幅释放人力资源。

接下来是核心环节——模型能力的对比测试。在提示词设计上，统一从角色设定、任务目标、输出格式、注意事项四个维度进行构建。

• 首先测试Qwen2.5。结果不尽如人意，几乎是在“答非所问”。当后台日志信息量稍大时，它根本处理不过来。
• 接着测试DeepSeek R1。其表现如同一个不太听话的孩子，需要花费大量精力调整提示词，时而正常，时而异常，难以放心使用。此外，它的推理过程无法关闭，每次输出后还需要额外接一个LLM模型来提炼结果，这引入了额外的复杂性和成本。
• 最后测试Qwen3。在相同的提示词下，输出结果最为理想，基本无需额外调教。这一点，确实值得称赞。

如果您也有类似的日志审计需求，那么Qwen3是一个值得尝试的选择。