基于上述两个因素，还有由于安全运营团队和数据科学团队之间知识构成差异所造成的沟通障碍，也是“反馈迭代”传统方法无法顺利实施的原因。在关注某一特定事件的具体描述时，安全操作团队更加重视对事件的具体描述，而由于缺少背景知识，数据科学团队很难将其从这些具体描述中分离出来，提取模型上的共性。沟通双方总是觉得鸡和鸭在一起，讨论也没有什么结果。大、小因素的叠加使得经营变得脆弱。给你一些怎样坚强的建议。在系统工程的观点下，消除脆弱性及其影响几乎需要这样做：找出错误的结果，并给出正确和错误的解释。为确保模型可用，建立现代、成熟的数据仓库及相关工程框架。

建立运行模型预测结果的相关机制，提供工具和培训。

在此，每一步都是对其它工作的补充，在实际工作中也有许多实例表明改进算法修正工程难点、重新设计安全架构以降低算法难度等。希望大家都能从系统工程这个整体了解下面的建议。

一个算法要求收集错误的结果。一个普遍的误解就是：错误结果完全依赖用户的反馈，这样做只会使用户感到厌烦，反而会造成大量的报警信息堵塞运营队列，使使用安全产品的团队或运营团队不得不按照经验放弃大部分告警，以保证带宽。在这个例子中，安全团队不仅没有时间来提供反馈，甚至使模型提供者错误地认为他们自己的模型非常完美，而且实际上是用户不愿意理睬你。适当的反馈渠道可以分为几个阶段：

在模式特征基础上的反馈：通常是基于其它特性或机器模型的规则。比如算法预测的鱼叉钓鱼页面就是google首页，它可以通过在流量排序模式中交叉确认，然后利用高流量站点与鱼叉钓鱼的相关性很低这一事实排除掉。这种反馈采用许多其它特性，有效地弥补了探测模型观察攻击模式时的视野限制，从理论上提供了反馈方式，并且可以标记出绝大多数错误。

根据相关知识的反馈：在该关联扩展几步后，预测结果仍应正确，直至该关联扩展数步后出现错误。比如，算法预测某个域名是恶意软件C&C，它可以从VirusTotal或其他检测引擎或安全小组，通过与DNS查询记录相对应的IP记录关联，扩展到沙箱中访问该IP的二进制二进制文件分析结果，直至完成整个链条延伸。这种反馈利用特征空间以外的第三方知识进行独立验证，其代价略高于模型特征的反馈，是模型特征反馈的有效补充。