【心法利器】
本栏目主要和大家一起讨论近期自己学习的心得和体会，与大家一起成长。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。
往期回顾
很多原因会导致我们在思考一个问题的时候，会在考虑一个算法问题的时候第一反应就考虑这个方法用什么模型，尤其是深度学习模型，但我们在实践应用的时候，却并非如此。
这次，先给大家聊一些比较通用的问题吧。
问题的定义
明确问题，比解决问题更加重要，因为问题不明确，你努力的方向都不明确，你甚至不知道你最终有没有解决问题，因此，我们需要明确的是，问题是什么，我们需要解决的问题是什么，包括但不限于这些细节：
边界明确。例如分类的话要知道，什么query是属于什么类；相似问题要了解，什么是相似，语义还是文本，什么样的人叫做相似。
指标明确。算法问题一般要看的应该是统计指标（这点必须时刻记住），准确率、召回率等。（如果遇到要解决特定几个case的，建议黑白名单处理）。
数据和资源
数据集
深度学习类的方法通常都需要大量的、质量还挺高的数据，所以选择使用深度学习之前，我们最需要考虑的就是数据问题：
数量。
质量。
当且仅当这两个满足，深度学习才可以实施，但是另外还有一个更重要的问题——评测集。
评测集是评判一个任务是否完成，完成的如何的关键点。
因此构造一个稳定、可靠、精准的评测集是非常重要的。
评测集质量要足够高，尤其是准确率等。
数据要足够符合现实应用场景的分布，这样的评测才是有效的。
多样性足够，能覆盖更多现实应用的场景。
评测集之后，才是训练的数据集，和比赛、科研不同，我们往往很难拿到，一旦拿不到或者没拿够，各种所谓的高端模型可能就没有了，但是我们要知道的是，训练数据难寻，但是嘛，词典、规则之类的还是可以挖掘的。因此，我们，我们可以：
降级问题，先用规则和词典来顶，看看能不能满足需求上线。
不满足需求上线，那看看能不能拿来做一批训练样本，拿来直接训练，然后标注，逐步迭代然后收敛。
训练数据不行，至少可以缩小范围，再进行进一步精标，从而得到训练数据。
计算资源
算法任务除了依赖数据，还有资源，尤其现在大规模预训练语言模型当道，大部分人在不考虑现有资源的情况下就bert一把梭，最终很可能就是效果很好（好不好都不是必然的）但是就是上不了线，这里我们需要考虑几个因素：
内存够不够，加载那么大的模型，还要训练数据是否够。
cpu/gpu资源。
其实最瓶颈的是，算法服务的耗时要求，这些模型是否可达到。
这些都是我们在方案选型的时候，需要考虑的核心问题，一旦这些问题没有很好地解决，模型，尤其是大的复杂的模型，那就根本没法用。
指标
前面提到，指标直接确定了目标是否达到，因此指标的设计将直接影响目标的达成情况。来讲几个细节点吧：
算法指标，简单的准招F1，这是分类问题最直接的指标了，当然还有AUC之类的很多，这个只要数据集靠谱基本不会有什么错。
业务指标，NLP看的最多的应该是端到端的满意度，例如问答领域看回答是否满足需求，推荐系统则是看点击率、转化率等等，这些指标只有让用户适用、体验才能够得到，这些需要精心设计，否则可能会出了差错，导致产品出现一些比较尴尬的问题。
case分析
一旦效果不好，很多人会开始吼“XXX效果不好”，但是很多时候，这么直接地给出结论是很草率的，很多问题都会导致效果的不好，而不能只怪罪于模型本身：
训练数据的质量不好或者数量不够，学习不充分或者是过拟合了，也可能覆盖量不够。
评测集的质量，分布是否合理。
另外模型本身是有上线的，能解决绝大部分问题但是终究无法解决一些边缘问题，因此其实在现实应用中很难在一些比较完整可靠的方案中看到单独一个模型，一方面我们需要把模型变得更加健壮的同时也需要一些特定的手段来保证我们能解决更多高频或者是边缘案例。
回到case分析，其实通过case分析能看出大量潜藏在“效果不好”下的问题，举几个例子：
比对bad case和与训练数据中相似的case，可能是原始样本就有问题或者是太过相近模型学不出来。
边缘的特殊case，模型无法学习或者是兼顾，长短句、中英文、未登录词都有可能。
标签就是错的，导致指标看着错误。
这些都是不看case肯定不知道的问题，只有我们认真去查证分析，才能够得到更可靠的效果。
case分析还有很多技巧，详情都可以在这篇文章里面看：ML&DEV[13] | bad case分析。
小结
算法问题不等同于模型问题，我们在遇到问题的时候需要思考的事情远比模型本身要难得多，只有完整可靠的思维模型才有助于我们更好地处理各种复杂的问题。
扫一扫
381
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
