心法利器[37-40,115] | bad case治疗术：合集-CSDN博客

本文链接：https://blog.csdn.net/baidu_25854831/article/details/140784618

心法利器

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

2023年新的文章合集已经发布，获取方式看这里：又添十万字-CS的陋室2023年文章合集来袭，更有历史文章合集，欢迎下载。

往期回顾

bad case修复其实是一个非常考验内功的事情，我也在实践当中尽自己之力去理解和吸收，慢慢的形成一些自己的经验，累积5篇，给大家介绍一下如何修复bad case，具体的流程如下（这里有各自的传送门，当然也可以直接点进去）：

当然，我的视角主要从NLP、对话、搜索的角度来看的，对于信息更为复杂的推荐，希望大家在方法论上也能有些收获吧。

认知篇

前言

插一段前言，其实原计划是写3篇就够，认知篇并不在计划之内，后期增加的原因是很多人可能并不理解bad case在整个问题分析中的重要性，因此我觉得有必要在开始讲方法之前先给大家树立基本的概念和观念。

什么是bad case

所谓bad case，是算法领域的一个术语，用于表示在推理阶段产生的与预期不同的结果，例如一个文本分类任务，应该让文本A分为正类，结果算法分成了负类，这就是一条bad case，就算是人类这种高级碳基生物进行预测，也很可能因为走神、认知差异、知识受限等因素出错，而现在并不强大的模型当然也就经常会出现bad case，我们甚至可以说bad case是普遍存在的。

bad case分析的意义

通过基本的指标，分析出我们现在的算法方案的现状可能并不困难，但是怎么“提升效果”，却是很多人很迷茫的问题，这是微观角度，更宏观地讲，如何提升自己解决问题的能力，如何让自己更好更快地解决更多的问题，这个同样让人非常迷茫，我们为了提升自己不断学习各种算法，各种论文，却发现除了模型逐步内卷之外，自己解决问题的能力并没有提升，一个问题试了成千上万的模型却发现提升可谓是杯水车薪，解决问题的天花板变得很低，效果提升也变得很不可控。

私以为，要突破，必定是要做出一个超出当前维度的工作。第一轮在美团的实习，让我知道了大道至简，简单的方案并不比复杂模型的效果差多少，而第二次在OPPO的实习，让我知道了分析bad case是破解问题，探索问题的关键钥匙，关键点分别是这几个：

如果模型效果不好是病，那bad case就是症状，是问题现场留下的线索，足够了解bad case能让你对问题背后的病因有更多的了解，方便对症下药。
bad case分析是我了解业务、了解场景的重要途径，知道当前研究、实践中容易出现的问题，往通俗的说，吸收经验的重要途径。

所以，我个人是非常建议大家多看bad case，多分析bad case，在模型理解和吸收出现瓶颈的时候，多看bad case可能可以拓展你的思路，发现的问题多了自然会产生一些解决方案，创新点、解决问题的能力也会随之增强。

bad case分析的心理关

很多人之所以不去看数据，除了没有这个分析case的意识，很大部分的原因是抵触，包括之前的我在内，主要是这几个原因：

数据多，分析起来很枯燥，时间还很长。
不清楚该怎么分析。

对于问题1，要突破的话我主要说这几个点：

其实不用分析很多，50-100条其实就很能说明问题。
数量看着很多，但我自己做过实验，自己去标结果的话，文本分类500条可能就10来分钟，分析100条bad case可能也是10多分钟，时间并不长对吧，这个时间总比找不到解决方法时痛苦没方向要好吧。
其实整个过程可以不枯燥，因为分析完你就可以触摸到问题的根本了，自己本身也有问题理解的提升，收获很大好吧。

而第二点，有关不知道该怎么分析，我是总结了一套思路方案，认知篇先到着，后续我会给大家介绍我的这套方案，敬请期待~

现状篇

bad case修复其实是一个非常考验内功的事情，我也在实践当中尽自己之力去理解和吸收，慢慢的形成一些自己的经验，最近一连4篇，给大家介绍一下如何修复bad case，具体的流程如下：

认知篇：介绍bad case分析的背景，给大家树立一个看bad case的意识和尝试。
现状篇：治疗bad case，首先要明确现状，就是现在的技术方案的真实效果如何。
分析篇：我们都知道要开始看bad case了，要怎么看，怎么分析出问题，在篇告诉你。
解决篇：知道病情，知道病因，就该开始治疗了。

当然，我的视角主要从NLP、对话、搜索的角度来看的，对于信息更为复杂的推荐，希望大家在方法论上也能有些收获吧。

本期第二篇，开始分析bad case之前要做的事情，概括的，我认为就是对宏观的现状有一个基本的了解，简单地说就是看指标，但是这点在我看来很多人其实做的并不好，我在这里给大家详细展开说一下吧，有则改之，无则加勉。

什么叫做现状

现在有一个基本baseline，baseline自然就有对应的评测集基线方案的效果，这个所谓的效果，就是现状，好or不好，是否需要持续优化，哪个方面需要持续优化，这就是所谓的现状，只有明确了宏观的现状，才能知道我们下一步的动作。

现状定位第一步——评测集

评测集可以理解为一份试卷，用来测试一个算法方案的效果，流程是这么个流程，但是这个流程的说法还是非常多的。

首先，要确认是一个完整意义的评测集，而不是一两条样本。这里背后有一个很关键点，就是不能用一两条case来断定一个方法的好或者坏，例如遇到了一个bad case，那就说明这个方法不好，这是草率的，要综合评定一个东西的好坏，不应该只看一次，而是应该看多次，所以需要的是一个具有一定数量的数据集。

第二，是一个具有一定统计意义的数据集。统计意义不仅仅是指的数量，简单地为了数量我们直接把同一条数据复制几十万次就完事了，我们都知道不应该这么做，那所谓的具有统计意义是什么意思，我的理解是这几个：

数量上能支撑特定指标的计算足够稳定。1条数据，误差就是100%，2条数据误差就是0.5了，到了100条，误差就只有1%，所以一般地数量足够多，抽样所带来的指标波动就会越小，结合数据集的实际使用需求，我们可以确定一个可靠数据集的数量。
抽样情况和实际使用的场景尽可能一致。最理想的情况，我们能用尽可能少的样本体现未来我们使用的时候可能出现的问题，这样能让我们在正式上线之前就把问题给暴露出来，其严重程度也可以从频次等方式快速得到观测，因此这个数据集我们希望的是能尽可能和正式的使用场景一致，最常用的方式就是用在线随机query来构造我们需要的评测集。

第三，质量可靠，足够支撑当前方案的数据集。但凡自己有看过些数据，其实都会发现哪怕是一些开源的数据集，也会出现标注错误的情况，更何况我们实际使用的更为复杂困难的数据集，因此我们需要尽可能保证的是，数据集质量足够高，出错的概率尽可能低，这样才能更好地用来测试我们的算法方案。最简单的检测方式就是自己拿100条出来自己标，看是否和预期相同，一般准确率在95%以上的数据集就可以说是非常靠谱了，90%只能说勉强可用，一般90%准确的数据顶多能支撑准确率在85%的方案的评测，再高你就会发现很多模型认为正确但是标注错误的case出现。

在科研的时候，我们可能会对着sota拼分数做实验，但是到了真正落地的场景，就会发现有一个可靠的评测集是多么困难，或者说我们可能很少会去找评测集中可能出现的问题，强如LCQMC的数据集依旧有大量错误，只是看我们当前的方案时候会因为这些错误而影响我们的评估和判断而已，有的时候LCQMC的准确率到了90%就上不去，很可能就是因为评测集中有些问题，所以不一定要为自己提了几个点而高兴，不妨先去看看数据。

但我们可以确定的是，评测集，这份试卷，必须得准备好，才能够用来评估算法效果，这步绝对不能轻易简化。

现状定位第二步——指标

算法最喜欢的就是结合指标评估效果，也就是我们所谓的现状，指标这个东西我们其实在初学算法的时候就已经了解很多了，这里为什么还要单独讲呢，原因其实和上面类似，表面上看着简单，其实里面的学问其实非常多。

首先，指标的设计必须要考虑观测的目标。指标是用来体现现状的，那要体现什么现状，这就是指标存在的根本。准确率是用来评估预测的正确性的，这个大家都知道，但是我们需要评估的是哪种方面的准确？这个就很关键了，例如我们在线的关键目标是为了避免误召回，要看误召回的情况，则准确率很自然地就会想到用“实际是该意图/算法预测该意图正类”来作为准确率指标，对于负类的预测情况，我们