包头市做网站哪个,旅游网站作用,网络品牌营销案例,非常成功的网站这是一篇写给萌新的“科学炼丹”手册 前言
近期在订阅号后台和文章评论区review了一下大家的问题#xff0c;发现很多小伙伴现在已经把机器学习、深度学习的理论基础打好了#xff0c;但是真正要解决一个现实中的算法问题的时候经常两手抓瞎#xff0c;一顿毫无目的乱试发现很多小伙伴现在已经把机器学习、深度学习的理论基础打好了但是真正要解决一个现实中的算法问题的时候经常两手抓瞎一顿毫无目的乱试甚至认为模型表现不好一定是调参不够仔细。
新手最大的问题在于解决问题的逻辑不够清晰喜欢使用“蛮力法”因此很容易陷入一个
“找到一份开源代码“
“跑了一下调了调参“
”效果不好下一个”
“效果好拿去做集成
的死循环中。就像下图一样 倘若恰好碰到一份代码让他的精度上了两个点于是他开始吹嘘“这个模型太牛逼了吊打XXXX”。而对于跑了一下没什么提升的算法他就会说“肯定论文造假了一点用都没有”。
然后以这种暴力搜索的方式解决问题久了之后他开始对别人吹嘘
“害俺们深度学习这一行就是跑跑代码调调参没有一点竞争力”
自嘲的话语被奉为圭臬可能是深度学习领域的最大悲剧。
今天跟大家分享一下我觉得应该了解的一些的炼丹常识希望小伙伴们在看完本文后可以帮助初学者提高炼丹能力和效率走出无脑调参的怪圈。
具体来说希望帮助大家实现下面几个目标 快以最快的速度解决一个算法问题 准以最少的试错次数找出最优策略 稳以最不容易出错的方式管理实验
准
在讲“快”之前先来讲讲“准”字诀因为准是最重要的问题而且是快的前提。
调研做好找准起点
接手一个算法问题后如果时间很充裕就可以先定位一下该算法问题所对口的学术会议或期刊
比如你要解决query-doc相关性匹配的问题那么你就要优先考虑SIGIRCIKM等IR强相关的会议而不是NLP的会议
如果你要解决NLI、问答、对话这种语义匹配的问题那么你就要优先考虑ACL、EMNLP、NAACL、COLING这种NLP会议而不是IR会议了
如果你把匹配模型做好了想压缩一下变得更小更快那就要优先考虑ICLR、NIPS这种更general的深度学习、神经网络会议了。
定位不出来算法问题的对口会议最起码可以逛逛AAAI和IJCAI吧虽然鱼龙混杂问题比较严重
然后根据文章title找几篇跟你的算法问题最接近的近两年的paper慢慢调研。通过这些paper的related work章节和实验章节还很容易追溯出更早的工作类似下图这种来自小鹿鹿鹿的一篇paper所以一般没有必要去手动调研更早期的paper。 于是很顺理成章的你就能找到这个算法问题的比较前沿的解法和比较经简典单的方法啦进而就有了不错的baseline迭代几版策略后说不定就出来一篇新paper。
不过如果时间很不充裕要解决的问题又比较简单比如就是个典型的文本分类问题、序列标注问题等在知乎上搜一下也经常能发现惊喜实在不行还可以问小夕嘛(∇)当然了问题太复杂的话更建议通过知乎私信右上角进行交流(//∇//)\
总之非常不建议直接去github一个repo一个repo的蛮力调参大量的宝藏方法是很难通过通用搜索引擎来找到的虽然这种行为在比赛刷榜的时候随处可见。
构建策略迭代闭环找准努力方向
避免蛮力试错的第二步就是构建完整的策略迭代闭环。由于不同的问题有不同的限定因此不存在一个绝对的流程可以恰好适合所有算法问题一个我自己最常用的迭代闭环就是
数据集分析 - 预处理策略 - 算法策略 - 模型评价 - case study
对于小白往往是在第三步和第四步陷入死循环看不到前两个环节和最后一个环节。
对于大白往往还能额外考虑一下预处理策略。
1. 数据集分析
很多小白拿到数据集后就开始迫不及待的调参之路了其实在开始之前对数据集做个简单的分析可能有助于大大降低你之后的体力劳动提前排除不靠谱的策略和不敏感的超参数并大大降低初次接触新任务时犯致命错误的概率。
比如简单统计一下样本长度分布你就可以知道max sequence length这个参数的大体取值范围没有必要把它当成一个正儿八经的超参数从小调到大简单统计一下类别分布你就不会在正负样本比91的情况下为一个90%的准确率沾沾自喜误导决策多扫几眼数据集你就不会在初次接触文本风格相关任务时把英文单词统一小写了。
2.预处理策略与算法策略
这个环节不用太多赘述啦最直接方法就是搬运上一节的调研结果将一些paper中比较有效的策略搬过来进行验证。不过尤其是注意一个meaningful的问题即我搬运这个策略甚至设计一个新的策略目的是什么要解决什么问题毕竟很多paper中的策略的适用场景是很局限的毫无目的的搬运可能会大大增加无用功。
3.模型评价
模型评价的问题在打比赛时一般不会遭遇在比较成熟的算法任务中一般也被解决了。比如谈到文本分类就能想到acc、f1等指标谈到机器翻译就能想到bleu等。然而有很多算法问题是很难找到一个 无偏且自动 的评价指标的。
一个典型的例子就是开放域对话生成问题。
虽然与机器翻译一样这也是个生成问题但是如果你沿用BLEU作为评价指标那么BLEU对对话生成来说就是一个有偏的评价指标你刷的再高也难以真实反映对话生成模型的质量对话生成问题中不存在机器翻译中的强的对齐关系。更糟糕的是由于找不到无偏的自动指标因此每迭代一次策略就需要让一群人轰轰烈烈的标注打分还要去检验是否存在异常标注者说不定有个宝宝就耍脾气了给你乱打一通这无疑是效率非常低的纵然你代码写的再快也会被评价问题所拖累。
业务中更是可能有一些模棱两可的算法任务比如“小夕来个更好的句子表示吧”那么如何无偏的评价一个表示的好坏就需要你在大规模开搞之前仔细设计清楚了。没有一个客观、无偏且自动的评价指标策略迭代无疑会非常缓慢甚至到后期推翻重来。
4.case study
像accuracy、f1、bleu等标量型评价指标可以指导当前策略整体上好不好但是却无法帮助你发现更细粒度的问题。很多小白在入行时喜欢把各种花里胡哨的算法和各种不着边际的想法一顿乱试以为有了模型评价指标就可以很轻松的评判一个算法“是不是有用”以及可以因此纯拼体力的炼丹。
但是当你额外的做一下case study之后可能你会突然发现很多自己之前的尝试完全就是多余的
你以为数据不均衡问题很严重case study才发现模型其实很轻松 你以为推理问题离自己很遥远case study才发现一大半的错例是推理问题导致的 你以为领域问题不重要case study才发现太多模型没见过的领域术语了 你以为数据集很干净case study却发现了大量错别字导致的错误决策
总之在经验不足的情况下通过case study可以帮助你排除大量的不必要尝试并有助于发现当前策略的瓶颈针对性的寻找策略和创新。
重视bug找准翻车原因
小白经常在跑了一轮迭代闭环之后就受挫“效果好差啊”。这里经常存在一个思维误区“精度不够一定是算法/参数不好”。
比如小白的觉得自己上了BERT能达到95% accuracy结果跑了个baseline后发现acc只有70%然后就开始1个点1个点的开始迭代策略。努力错了方向自然最终结果也不会太好。
实际上在这种策略迭代过程的情况下优先考虑是存在bug。比如用了BERT-uncased预训练模型却忘了对输入文本进行lowercase处理用了个char-level的模型却给文本切了词万事俱备后bash脚本里却忘了载入预训练模型等。
有时候调参和使用一些算法策略可以缓解bug带来的影响导致小白误以为继续卖力的调参和疯狂试错就一定能把这个鸿沟填平。实际上比起算法和超参bug往往致命的多。当然了对于一些特殊的算法问题比如众所周知的RL问题超参数确实极其敏感需要具体问题具体分析。
快
摆脱“洁癖”提高写代码速度
算法探索具有极强的不确定性很可能你写了半天的代码最后由于不work而完全废弃因此从代码风格上来说一定要避免把代码写成系统各种面向对象的封装技巧一顿乱怼是非常不必要的。允许一些“垃圾代码”的存在可以大大提高实验迭代的效率。
问题来了假如你生产了一堆“垃圾代码片段”该怎么高效利用它们呢直接丢掉还是复制粘贴重构代码
最简单的方法是直接使用粘合剂“Bash Script”。即将功能零散的代码片段通过bash管道命令连接起来这样还能通过“”wait命令的组合拳实现对大规模数据集的多进程并行处理。
对shell实在不熟悉的小伙伴也可以使用jupyter notebook来进行粘合。不过强烈建议每个NLP算法工程师熟练使用bash和vim相当多的数据处理和分析是不需要使用python的习惯了之后这些bash命令和vim技巧会对炼丹效率有非常明显的提升。
而对于更加碎片化的小代码比如边分析边修改逻辑生成一个小字典则可以考虑使用ipython完成任务后一条magic命令%save就让这些碎片代码变得可复用了。
不仅在生产代码上可以大大提速在debug和调参问题上依然是有学问的。
分规模验证快速完成实验
这个问题写出来时感觉很白痴但是据我观察大部分新手都存在这个问题。如果你给他100万规模的训练集他就会拿整个训练集去调试你给他1000万规模的训练集他还是拿整个训练集去调试甚至不忘抱怨“数据载入太费时间了调试好花时间呀”。 亲debug也是分阶段的呀....
第一阶段调通代码。这时候象征性的挂几百条样本就够了修正语法错误和严重的逻辑错误。
第二阶段验证收敛性。很多bug不会报错但会导致训练完全崩溃或者压根就没在训练。可以对几百条或者几千条样本进行训练看看若干epoch之后训练loss是否能降低到接近0。
第三阶段小规模实验。在万级或十万级别的小样本集上验证模型表现分析超参数敏感性。这一阶段在数据规模不大时比如几十万或一二百万其实可有可无当训练数据极其庞大时十亿级甚至百亿级的话还是必要的。有一些很细微的bug虽然不会影响收敛却会显著影响最终模型的表现。此外也有助于发现一些离谱的超参数设置。
第四阶段大规模实验。即有多少训练数据就上多少甚至多训练几个epoch。进行到第四阶段时应当绝对保证代码是高度靠谱的基本无需调参的否则试错代价往往难以承受。
理性调参把算力和时间留给策略探索
初学者喜欢把什么都作为超参数来调。
“文本截断长度不确定设置多少挂10组实验调一调” “官方代码里有个warmup不知道有啥用挂10组实验调一调” “听说batch size对性能有影响挂10组实验调一调” 一切尽在调参中╮(╯▽╰)╭
这种做法无疑是极其浪费时间和计算资源的有的超参数完全可以算出来合理范围有的取决于其他超参数和所处环境有的与网络结构和预训练模型强耦合等等。因此调参的第一步也是最重要的一步是进行超参数敏感性分析找到对当前任务性能影响最大的几个超参数之后再进行精调。
而要确定各个超参数的敏感性一方面可以根据自身经验来定一方面可以根据各paper中的取值差异大的超参数可能是敏感超参大家都取值相同的一般不敏感实在不确定跑两三组实验就够确定敏感性了完全没有必要来个“网格搜索”。
篇幅原因本文只讲通用的方法一些细节性的魔性调参资料在网上有很多了这里就不展开了。
稳
说完了“准”和“快”的问题下面就到了最容易让初学者头疼的“稳”字问题啦。
很多初学者都出现过这种手忙脚乱的情况
“诶明明我记得这个脚本能跑出来95%的准确率再一跑怎么成92%了” “我的模型去哪了” “这个模型怎么训出来的来着。。” “这俩策略有哪些diff来着” 问题就出在了实验管理和代码版本管理上。
一个工具就稳了
顾名思义实验管理就是要记录下来每一次实验的策略名和对应的实验结果一般以表格的形式记录。这里可以用excel、markdown编辑器等记录当然更建议使用支持云端同步的工具来记录比如石墨文档、印象笔记或内网的相关工具等以防电脑被偷、文件误删等意外导致的悲剧。
但是有时候实验着急对策略的描述不够仔细怎么办比如某次实验同时改变了具体策略、还改了超参数、预训练模型等一堆东西不能用一个名字概括全部怎么办呢
最简单的做法就是与版本管理工具配合再也不用担心未来settings丢失、模型无法复现、模型无法追溯环境等问题了。
而要实现版本管理也很简单Git自然是不二之选。 萌新们注意啦是GIt不是GitHub你可以不用GitHub但是不能不用Git 怎么用Git管理版本和实验迭代呢
首先务必保证训练日志、eval日志是以文件的形式存了下来而不是打印到屏幕上变成过眼云烟了此外需要保证每一次运行时的settings比如超参数、数据集版本、ckpt存储路径等都能保存到日志文件中且尽量封装一个run.sh来维护训练任务的启动环境。
之后就是看每个人自己的习惯啦。我个人的习惯是 主线策略每成功推进一步就调用git tag打个tag。这里的tag即策略名与实验管理的表格中的策略名对齐 如果要在某个策略的基础上尝试一个很不靠谱的探索那么可以在当前策略的基础上拉一个分支出来在这个分支上完成相应事情后切回主分支。当然啦万一这个分支上的策略work了就可以考虑将其转正合入主分支并打上相关tag
更多git实现版本管理的命令见这里
这样将来你想review某个策略时只需要切换到相应的tag下面或者分支下面就可以啦完整复现整个环境并能直接追溯出跑该策略时的一切相关设置以及该策略下的各种调参结果。
最后“准”字问题上还要考虑最后一种极端情况就是整个实验环境被连根拔起╮(▽)╭比如硬盘损坏之类的严重故障。因此一定要记得做好备份工作即周期性的将环境中的关键代码push到github等远程仓库。当然了对于ckpt、数据集这种大型文件可以写入.gitignore文件中以免把仓库撑爆这些大型文件的最佳归宿当然就是hadoop集群啦。
科研任务是可以通过开源数据集进行评估的但业务算法的评估还是要以业务数据为准。
