文档教程【免费下载链接】machine-learning-yearning-cnMachine Learning Yearning 中文版 - 《机器学习训练秘籍》 - Andrew Ng 著项目地址https://gitcode.com/gh_mirrors/ma/machine-learning-yearning-cn点击查看免费下载导读本文围绕《机器学习训练秘籍》Machine Learning Yearning 中文版中开发集Development Set与测试集Test Set的定义展开以书中猫咪图片移动应用为贯穿案例系统梳理训练集/开发集/测试集三者定位、为什么要摒弃 70% / 30% 的传统划分、以及如何让数据划分真正服务于未来实际数据分布。读完本文你将掌握一套可落地的数据划分决策流程与单值评估指标Single-Number Metric设计方法并理解开发集、测试集与评估指标为何是机器学习团队快速迭代的加速器。一、问题起点为什么 70% / 30% 划分会让部署后的模型失灵本文对应的原始章节位于仓库 _docs/Setting up development and test sets/ch05.md它开篇即用一个经典场景点出数据划分的陷阱你负责运营一个移动端 app用户会向这个 app 上传许多不同内容的图片而你希望这个 app 能够从图片中自动找到含有猫的图片。团队的做法是从不同网站下载含猫图片正样本/正例与不含猫图片负样本/反例拼成巨型数据集按70% / 30%的比例划分为训练集与测试集并训练出一个在两者上都表现良好的猫咪检测器。然而一旦把分类器部署到移动端性能却相当之差。原因非常直观网站下载的图片与用户上传的图片存在系统性差异——手机拍摄的图片往往分辨率较低、模糊不清、采光不理想训练集与测试集都取自网站导致算法无法泛化generalize到我们所关心的手机图片的**实际分布actual distribution**上。这里揭示出全书反复强调的一个核心论断在大数据时代来临前70% / 30% 的随机划分是普遍做法但在越来越多的实际应用中训练数据分布网站图片与最终关心的分布手机图片往往不同此时执意采取这种划分是坏主意。这一观点也延续到了本节小结_docs/Setting up development and test sets/ch12.md传统的 70% / 30% 训练集/测试集划分对大规模数据并不适用开发集和测试集的比例会远低于 30%。仓库中的章节脉络本文所讨论的开发集和测试集主题并非孤立章节而是仓库 _data/docs.yml 中 Setting up development and test sets 分组的开篇ch05–ch12后续章节依次展开章节主题仓库路径ch05开发集和测试集的定义_docs/Setting up development and test sets/ch05.mdch06开发集和测试集应该服从同一分布_docs/Setting up development and test sets/ch06.mdch07开发集和测试集应该有多大_docs/Setting up development and test sets/ch07.mdch08使用单值评估指标进行优化_docs/Setting up development and test sets/ch08.mdch09优化指标和满意度指标_docs/Setting up development and test sets/ch09.mdch10通过开发集和度量指标加速迭代_docs/Setting up development and test sets/ch10.mdch11何时修改开发集、测试集和指标_docs/Setting up development and test sets/ch11.mdch12小结建立开发集和测试集_docs/Setting up development and test sets/ch12.md因此本文将以 ch05 为骨架适当引用同组后续章节形成一份定义 → 原则 → 规模 → 指标 → 迭代 → 修正的完整方法论。二、三组数据集的明确定义训练集、开发集与测试集ch05 给出了三个数据集的权威定义这是全书的公共词汇务必精确区分训练集training set用于运行学习算法的数据。算法在这里被拟合、更新参数。开发集development set用于调整参数、选择特征以及对学习算法作出其它决定。它有时也被称为留出交叉验证集hold-out cross validation set。测试集test set用于评估算法的性能但不会据此改变学习算法或参数。三者职责边界清晰开发集服务于决策测试集服务于最终无偏评估。ch05 特别强调在定义了开发集与测试集之后团队可以大胆尝试许多想法如调整参数、探索最优配置因为开发集和测试集能帮助团队快速检测算法性能。书中给出一句全章纲领性的话开发集和测试集的使命就是引导你的团队对机器学习系统做出最重要的改变。换句话说数据划分不是数据工程上的例行公事而是直接影响团队决策效率与系统最终质量的战略动作。三、核心原则让开发集与测试集代表未来实际数据基于上述使命ch05 给出的操作准则是合理地选择开发集和测试集使之能够代表将来实际数据的情况并期望算法能够运行良好。落实到猫咪 app 场景这意味着测试集不应只是简单地将可用数据划出 30%尤其是当将来获取的数据移动端图片在性质上可能与训练集网站图片不同时。如果 app 尚未上线、没有真实用户反馈数据可以主动模拟未来情况——例如邀请朋友用手机拍下照片发给你先用手工采集的数据近似未来分布。app 上线后用实际用户数据更新开发集和测试集让评估基准持续贴近真实世界。如果实在没有途径获取近似未来实际情况的数据可以退而求其次使用已有网站图片但必须意识到风险系统可能无法很好地泛化。ch05 还给出一个清醒的告诫选择一个理想的开发集和测试集需要投入投入多少由你决定但不要武断地认为测试集分布与训练集分布是一致的。应尽可能选择你最终期望算法能正确处理的那类样本作为测试集而不是随手从恰好拥有的训练集中挑一部分。一个关键推论训练集与开发集/测试集可以不同分布注意 ch05 的表述重心被选作开发集和测试集的数据应当与你未来计划获取并良好处理的数据服从同一分布而不一定与训练集分布一致详见 ch12 小结。这一点在深度学习时代尤其重要——大规模训练数据常常来自网络爬取等廉价渠道而评估基准必须锚定真实业务场景。四、为什么开发集与测试集必须服从同一分布ch05 定义了和谁同分布ch06_docs/Setting up development and test sets/ch06.md则回答两者彼此之间的关系开发集和测试集的分布应当尽可能一致。书中用一个反例说明按公司核心市场把猫咪 app 数据划分为美国、中国、印度、其它地区四个区域然后把美国、印度归入开发集、中国、其它地区归入测试集——这样做是错的。原因有二团队会专注于提升开发集性能而开发集必须体现核心任务让算法在四个地区都表现优异而不是只在其中两个。分布不同会带来第二个问题系统可能在开发集上表现良好却在测试集上表现不佳——书中明确写道我曾目睹过这样的事件这令人十分沮丧并且还会浪费大量的时间。进一步地当开发集与测试集分布不同时若出现开发集好、测试集差可能的归因会变得不唯一至少存在三种情况算法在开发集上过拟合overfit测试集比开发集更难预测算法已尽力而难以再提升测试集并非更难只是与开发集性质不同分布不同针对开发集的大量改进工作是徒劳的。这三种情况需要完全不同的对策而分布不一致使问题不可诊断。ch06 的结论是如果要在特定机器学习应用上取得进展而不是做研究应尽可能选择服从相同分布的开发集与测试集这会让团队更有效率。第三方基准测试场景除外——样本提供方可能已指定不同分布的开发/测试集此时运气成分会超过技术本身的贡献。五、规模设计开发集多大、测试集多大ch07_docs/Setting up development and test sets/ch07.md专门讨论数据集规模核心标准是足够分辨算法差异开发集规模应尽可能大至少要能区分不同算法的性能差异。例如分类器 A 准确率 90.0%、B 为 90.1%那么仅有 100 个样本的开发集无法检测出这 0.1% 的差异——书中直言一个样本容量仅为 100 的开发集规模太小了。经验区间开发集规模通常在 1,000 到 10,000 个样本之间当开发集有 10,000 个样本时就很有可能检测到 0.1% 的性能提升。成熟且关键的业务场景可以更大在广告服务、网络搜索、产品推荐等领域哪怕 0.01% 的提升都直接关联利润此时团队会积极改进算法开发集规模可能远超 10,000。测试集规模应大到能够对整体系统性能给出高度可信的评估。常见启发式是取整体 30% 数据作测试集这只适用于总体数据量一般约 10010,000 个样本的情况。在大数据时代样本量可能超过 10 亿虽然开发集/测试集的绝对数量在增长但占比不断降低——我们并不需要把开发集和测试集规模提升到远超评估所需的程度不是越大越好。书中还顺带澄清了一个统计实践问题理论上可以检验算法变化是否在开发集上存在统计学显著差异但大多数团队在实践中并不执着于此除非在发表学术论文书作者明确表示在检测过程中我并没有发现统计显著性检验能够起到多少作用。六、评估指标从多值困境到单值评估指标数据划分之后下一个问题是用什么标准比较算法。ch08_docs/Setting up development and test sets/ch08.md提出单值评估指标single-number evaluation metric分类准确率就是典型的单值指标在开发集/测试集上运行分类器后返回一个数值代表样本被正确分类的比例。若 A 准确率 97%、B 为 90%可立即判定 A 更优。反例是查准率Precision与查全率Recall的组合它给出两个值抬高算法比较的难度。假设两个分类器ClassifierPrecisionRecallA95%90%B98%85%二者都没有明显优势无法指导你立即做出选择。解决办法是把两值合并为单值书中推荐F1 分数——查准率与查全率的调和平均数公式为2 / ( (1/Precision) (1/Recall) )ClassifierPrecisionRecallF1 scoreA95%90%92.4%B98%85%91.0%于是 A 胜出团队得到清晰排名。此外多目标如美国、印度、中国、其它地区四个市场的准确率可以通过取平均值或加权平均合并为单值指标——这是最常见的合并手段之一。优化指标与满意度指标ch09_docs/Setting up development and test sets/ch09.md给出另一种多目标处理框架适用于指标难以直接合入一个公式的场景。例如同时关心准确率与运行时间ClassifierAccuracyRunning timeA90%80msB92%95msC95%1,500ms把两者放进单个公式如Accuracy - 0.5 * RunningTime不太符合常理。替代方案是先定义可接受的运行时间如低于 100ms在满足运行时间约束的前提下尽可能最大化准确率。此时运行时间是满意度指标satisficing metric——必须足够好满足阈值即可准确率是优化指标optimizing metric——在约束下尽量优化。推广到 N 项标准如二进制文件大小、运行时间、准确率通常设置N-1 个满意度指标加1 个优化指标。书中以唤醒词系统类似 Alexa / Hey Siri为例优化目标是最小化假反例率用户说出唤醒词而系统未唤醒满意度约束是每 24 小时误报不超过一次假正例率约束。ch09 的结论是一旦团队在优化评估指标上保持一致就能取得更快的进展。七、度量指标如何加速迭代闭环ch10_docs/Setting up development and test sets/ch10.md把开发集与指标的作用放到迭代流程中放大即便是经验丰富的研究员也通常需要尝试多种方法才能找到满意方案。书中给出的标准迭代循环是尝试一些关于系统构建的想法idea用**代码code**实现想法根据**实验experiment**结果判断想法是否行得通第一个想到的点子一般都行不通在此基础上产生新想法并保持循环。迭代循环越快进展越快。此时开发集、测试集与度量指标的价值就体现出来了每有新想法在开发集上评估性能即可判断方向是否正确。反之如果没有开发集和度量指标就需要把每个新分类器整合进 app、花几小时体验来感受改进与否——这会浪费大量时间。而且 95.0% → 95.1% 这类 0.1% 的改进很难靠人工体验察觉但积少成多、持续积累系统会取得巨大提升开发集与指标能让你快速检测微小或大的提升从而快速决定下一步该研究还是该放弃。八、什么时候应该修改开发集、测试集和指标ch11_docs/Setting up development and test sets/ch11.md承认数据划分方案不是一锤定音而是需要随项目认知修正的。书中建议新项目应在一周内一般不会更长给出初始开发集、测试集和指标——提出一个不太完美的方案并迅速执行比花过多时间思考更好成熟应用如垃圾邮件过滤可花数月打磨。若发现初始设置与期望目标有差距尽快改进。典型信号是开发集与指标把分类器 A 排在 B 前面但团队认为 B 在实际产品中表现更优。导致排序错误的原因有三类对策各不相同实际数据分布与开发集/测试集分布不同例如初始数据多是成年猫图片用户却上传大量小猫图片→ 更新开发集与测试集使其更具代表性。算法在开发集上过拟合开发集性能远好于测试集→ 获取新的开发集。书中提醒可每周/每月在测试集上做定期评估以跟踪进度但不要根据测试集指标做任何决策包括是否回滚系统否则测试集也会开始被过拟合其无偏估计能力将失效——这对论文发表和商业决策影响很大。指标本身不是项目应当优化的目标例如准确率指标把允许色情图片出现的 A 排在 B 前面→修改评估指标对不可接受的行为施以严重惩罚并建议直接选择新指标、制定新研究目标而不是在不可靠指标上耗费时间后回头做人工挑选。ch11 的收尾态度很务实在项目中改变开发集、测试集或者指标是很常见的……当你发现它们对团队的导向不正确时不要担心只需要修改并确保团队了解新方向。九、落地清单建立开发集和测试集的完整要点综合本节全部内容ch05–ch12可整理出可直接用于团队实践的检查清单分布锚定被选作开发集和测试集的数据应与未来计划获取并良好处理的数据同分布不一定与训练集分布一致ch05、ch12。同分布原则开发集与测试集之间分布应尽可能一致否则算法调优失去可诊断性ch06。规模适中开发集 1,00010,000 个样本足以分辨 0.1% 量级的差异测试集大到能给出可信的整体评估即可两者都不是越大越好大数据场景下占比可远低于 30%ch07、ch12。单值指标为团队选择一个单值评估指标多目标时合并进一个表达式如多误差取平均或设置满意度指标 优化指标ch08、ch09、ch12。加速迭代机器学习是高度迭代的过程开发集 测试集 单值指标可快速评估算法、加速想法 → 代码 → 实验闭环ch10、ch12。快速起步、及时修正全新应用争取一周内建立开发集、测试集与指标成熟应用可花更长时间当开发集/指标导向错误时尽快修正——过拟合则扩充开发集数据、分布偏差则换新开发集与测试集、指标失准则改评估指标ch11、ch12。结语从划分数据到设计决策引擎回到猫咪 app 的教训一个在训练集与测试集上都表现良好的模型部署后却可能一败涂地问题往往不在模型本身而在于评估基准没有对准真实世界。machine-learning-yearning-cn 的 ch05 及其所在章节给出的方法论核心是开发集与测试集不是数据的随机抽样而是团队决策的锚点——它们定义了什么算好、什么算差、朝哪个方向改进。当你把代表未来实际分布与同一分布单值指标快速迭代这几条原则落到实处数据划分就从被动的统计惯例转变为一台驱动机器学习系统持续进步的决策引擎。赞分享文档教程【免费下载链接】machine-learning-yearning-cnMachine Learning Yearning 中文版 - 《机器学习训练秘籍》 - Andrew Ng 著项目地址https://gitcode.com/gh_mirrors/ma/machine-learning-yearning-cn点击查看免费下载相关推荐机器学习训练秘籍何时修改开发集、测试集与评估指标machine-learning-yearning-cn 实战指南机器学习训练秘籍何时修改开发集、测试集与评估指标machine learning yearning cn 实战指南 本篇指南围绕《机器学习训练秘籍》Ma文档教程InternLM2-7B部署优化MindSpore框架下的推理加速与内存优化技巧InternLM2 7B部署优化MindSpore框架下的推理加速与内存优化技巧 InternLM2 7B是一款基于MindSpore框架的高效大语言模型在machine-learning-yearning-cn建立开发与测试集的关键策略machine learning yearning cn建立开发与测试集的关键策略 在机器学习项目中开发集Development Set和测试集Tes文档教程上一篇Angular Timer部署指南Bower安装与生产环境配置下一篇如何自定义CoinHive矿池支持任意Stratum协议矿池的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考