本文不介绍F1指标，只介绍recall和precision这两者，在账号安全风控领域中，如何去估算。因为在风控领域，你是很难区分出全部的坏人和全部的好人的。所以，正常情况下这两个指标并不好计算。本文通过二次加验拦截率入手，采用业务常用方法进一步拆分precision和recall的估算过程，从而最终顺利计算出这两个指标的数值，更好地衡量整个风控工作的质量与水平。

precision与recall基础公式

对于recall和precision,可以说，如果看重recall,说明比较偏重安全性，重视precision,则说明比较重视用户体验。对于银行业来说，其实是更注重安全性，也就是recall， 但是关注recall是有困难的。这得从recall的计算公式说起。

这里的recall，我们以坏人为正样本。那就是要找出所有的坏人（TP+FN），这里面包含识别出来拦截的真坏人(TP)，还有没有识别出来放过的假好人(FN)。

二次加验（MFA）

这里不纠结二次加验，两步验证与多因素认证（MFA）有什么不同了，核心就是识别出风险后，希望通过一系列手段进一步确认用户身份。这些手段，对于正常用户，基本都会通过的，而对于可疑用户，可能无法顺利操作。

关于二次加验的一些指标说明

• N_need_verify_total:所有需求加验的人数
• N_verify_failed : 验证失败或拒绝验证的人数
• N_verify_passed: 验证成功的人数

二次加验的拦截率：

这个指标，是最直观，最容易计算出来的。

这个指标的含义是：在所有被判定为高风险的用户中，最终有多少比例被加验环节拦截了？

二次加验拦截率与precision关系

precision计算，其实分母已经有了，就是N_need_verify_total，这个是所有判定为高风险的样本数。 但分子中，N_verify_failed是不一样的。通俗的做法是对所有失败的样例中，去抽样调查，看是用户放弃的，还是真的有问题的部分。得到一个大致的比例，然后用这个比例去估算TP,最终计算出precision。在得到一个相对合理的TP后，在金融行业，我们其实更关注的是recall。

如何计算recall

上面的过程，我们预估了TP，但是如何估计FN，并没有那么容易。

FN（False Negative）:真正的高风险恶意用户，但系统未能阻止这些

FN1：被标记为高风险，但加验通过的恶意样本

• 定义：被标记为高风险并触发了加验，成功地通过了所有的加验流程（骗取了验证码，使用AI换脸，或者找到加验流程漏洞）
• 如何发现并估算
  • 事后分析：对加验通过的用户进行抽样或者全量分析，特别是登录成功后有大额转账，修改密码等异常行为的样本
  • 关联下游：如果一个样本被标记成高风险并且通过了加验，后续其他团队有反馈确实有问题的，这一次登录就构成了一个FN1
  • 用户投诉：受害者投诉反馈本人账户出现盗用等行为，也需要标记为FN1

FN2：未被标记为高风险，直接登录成功

• 定义：这一部分未被标记为高风险，直接登录成功了，被称之为漏网之鱼。出现这种情况，其实挺严重的，相当于风控规则完全被绕过了。
• 如何发现并估算
  • 核心来源：需要跟下游确认欺诈或者相关的安全事件。
    • 资金损失
    • 账户盗用
    • 内容安全或者行为异常（比如盗用QQ后，大量删除好友发送垃圾信息）
  • 人工核查、案件分析：通过人工分析的方式，寻找可疑样本。
  • 黑样本回溯测试：将已往发现的黑产样本或者漏过的样本，在当前风控系统下进行回溯测试，看有多少会被漏掉，然后有针对性地修改。
  • 关联模型、无监督异常检测：通过聚类或者图算法等，通过关联的方式进行社群发现，找出关联样本，然后标记为FN2

通过上述的方法，得到FN1和FN2后，利用下述公式计算recall:

小结

总之，想顺利计算recall与precision，需要依赖多个团队合作，包括风控，运营，调查，数据分析等团队之间的协作，还要注意发现FN之后要，分析原因，优化和迭代风控策略，形成闭环。如果注重用户体验，优先关注precision。如果注重安全，那么要注重recall指标的提升。