心法利器[54] | NLP任务上线前评测

心法利器

本栏目主要和大家一起讨论近期自己学习的心得和体会，与大家一起成长。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。

近期，我再次总结了我的历史文章，累积起来有50w字，百余篇文章了，有兴趣可以拿来看看，获取方式：七夕清流，百余篇累计50w字文章合集发布。

往期回顾

• 心法利器[49] | 数据分布的含义理解
  

• 心法利器[50] | 测试集构造思考

• 心法利器[51] | 长短句语义相似问题探索

• 心法利器[52] | 口语化句子解析问题

• 心法利器[53] | 数据增强的现实应用思考

无论我们做什么模型也好策略也好，最终是需要上线的，然而，在常见的互联网场景，面对成千上万甚至千万上亿的用户，一些小的错误很容易造成重大损失，用户体验的下降非常小昂明显，因此，在上线前，一定要经过谨慎全面的评测，才能对新方案的质量有保证。今天给大家介绍一下我对NLP任务上线前的评测流程吧。

当然，NLP任务本身，我这里另外还推荐一篇有关NLP相关的评测指标任务，来自我们组的工作，这个事其实和算法息息相关：如何评价智能助手的好坏？小布助手是怎样炼成的？当然，本文覆盖的内容有限，埋个坑，这篇文章估计会出解读。

懒人目录：

• 核心思路。

• 算法质量。

• 算法服务性能。

• 我的checklist。

• 补充说明。

核心思路

首先，我们要保证上线任务的质量，那我们得知道什么是质量，从算法和工程角度，其实就是两个点：

• 算法质量，要求预测足够准，算法效果好，结果符合预期。这点的好坏最终影响的是整个AI系统的“智能”程度，出了问题就会被用户认为是“智障”。

• 算法服务的性能，单机速度、并发能力、内存等。工程的性能问题是整个系统的可用性问题，一旦性能不足，整个系统可能会崩溃。

所以，我们的评测，也应该是围绕着两个点来进行的。

算法质量

所谓一名算法，这本就应该是我们作为算法应该去保证的事，那么算法质量，这个东西本身该怎么定义，我们又应该怎么去保证，其实大家也有自己的认识，我这里聊聊我的。

首先，质量上，我们应该考虑的应该是评估方式，具体思路应该是这么几个：

• 基本的算法指标，例如分类模型那我们要考虑准确率、召回率、AUC等。一般地我们要求有baseline目标，必须比这个高，这个是绝对指标，另外如果是迭代优化的话，那肯定是要比原来好或者是不比原来差，此时考虑的是相对指标。

• 体验效果，除了基本的算法和准招，算法最终服务的使用体验，所以还需要考虑满意度、满足率等因素，根据用户所问有没有满足进行满意度评分。

• 基本功能，这个其实应该是最低的要求，就是根据产品要求的基本用户功能需要满足，一般是通过构造必过case集进行分析得到的。

基本的算法指标大家都很容易想到，但其实算起来并不简单，因为数据的分布不同，往往会影响指标计算，所谓的数据骗人，很大概率就是因为这个，所以我们应该认真设计这套数据集，我这里考虑的点主要是这几个：

• 和实际应用场景一致——在线随机。需要注意的是，这个是肯定不能简单的从训练集里面拆的。

• 口径、筛选条件，包括去重不去重、分子分母的口径、计算的漏斗和流程部分等。举个例子，有些指标里的数据如果口径不变就会产生不同了，例如同样是满意度，分母有的人可能理解为“满足query占有回复非兜底的占比”，也可能会被理解为是“满足query占所有query的占比”，可以看到这两个口径算下来的结果会有很大偏差的。

• 保证数据质量，对齐标注标准。别看这个事很简单，很多问题，尤其是语义相似度问题，很多人对“相似”的标准差异是很大的，所以一定要对齐对清楚。

另外，还要考虑的是指标的设计，在现实任务中，很多情况可能就不只是准招这么简单了，还要考虑一个角度，相对指标和绝对指标。当且仅当绝对指标和相对指标都是变好的，我们才能考虑去上线。

• 绝对指标考虑的是指标的绝对值，例如准确率90%，召回率80%之类的，在论文科研上我们更关心这种类型的指标，在实践上，我们也会挺关心这种类型指标，只不过这种只是我们初步或者说对及格线的评估，要进一步评估好不好，还需要一些相对指标的评估。

• 相对指标则更倾向于去对比，用在一些迭代任务，我们要求的是比原来好，这个好更应该是一一对比的，我们不能让总体指标比原来好的同时伤害很多原来就不错的case，所以此时我们要去做类似SBS的评测，逐一评估变好变差，最终评价胜出率。

算法服务性能

算法服务性能是一个新手很容易被忽略但是却非常重要的因素，很多新人可能一上来吭哧吭哧搞了一个bert结果上不了线，或者在为自己的bert无法上线而抱不平，其实很多时候就是因为没有把算法服务性能当做一个上线需要考虑的因素。所谓算法服务性能，是指在算法服务作为服务的承担能力，例如并发能力、处理速度等，这个东西形容起来其实就和一个服务台上的服务人员工作方案类似，平均每个业务的处理时间，能承受多少人的持续请求，尽管新的方案服务起用户来感受更好，但是因为时间太长处理不了更多用户，那肯定也是不行的。所以，我们肯定是需要把握好算法服务性能。

算法服务性能需要考虑这些因素：

• 跑必过case。保证基本功能的实现，这块是不能有问题，包括不能有bug。

• 单进程下的耗时，内存、CPU、GPU等的占用，都不能太高。

• 多进程下考虑qps、也要考虑内存、CPU、GPU等的占用，都不能太高。

这个要测试的方法也比较通用，因为很多工程大佬已经走过这些坑了，本质我们就是再走一遍这个流程，就是压测——压力测试。通过多进程地执行一些随机的query或者是一些更容易耗时高的query，能测出服务的承受能力，具体的代码网上其实都比较好找到，部分情况还有一些已有的工具。

说白了，就是不能占用太多资源，毕竟大部分情况不管是钱还是资源都应该是有限的，我们应该更加高效地应用，我们不能不关注。

checklist

首先是算法质量：

• 基本算法指标：准确率、召回率，一方面使用历史标注做总体分析，另一方面是在线随机query的自测，当然这里要算去重，也要带频次。

• 体验指标：满意度和SBS自测，考虑用户体验，看最终的效果，一方面新版本的胜出率要高一些，另一方面整体满意度也要变好。

然后是算法服务性能：

• 单进程自动化用例，也就是必过的case，放置引入问题，甚至出现bug，未知情况的报错等。

• 压测。单、2/4/8/16等多进程的压测，观测平均和50%、90%、99%分位点耗时，观测内存等占用是否符合预期，另外注意使用的query要分两种，一种是随机的，一种是复杂的（尽可能走过多一些复杂流程的，说白了就是看看极端坏的情况）。

补充说明

上面的大部分思路和方案，基本都是基于自己的场景，有一些特异性，部分指标是可以轻松获取的，并非都适用，例如推荐系统里的类似准招之类的可能并不好评估或者说并不准确，需要依赖在线AB实验，但是依旧可以参考吧。