内容简介:近日微软研究的 John Langford 讨论了顶会到底应不应该提交代码,因为不同研究主题与领域对代码的需求不同,他表明代码提交应该鼓励,但并不能强制。作为 ICML 2019 的程序主席,Russ Salakhutdinov 表示他赞成 John Langford 的观点,他们在 ICML 2019 的评审中也引入了代码提交的选项。目前 ICML 2019 的评审结果已经出来了,那么你们提交代码了吗?ICML、ICLR 和 NeurIPS 都在尝试将实验代码和数据作为评审材料的一部分提交,它们鼓励作者在
近日微软研究的 John Langford 讨论了顶会到底应不应该提交代码,因为不同研究主题与领域对代码的需求不同,他表明代码提交应该鼓励,但并不能强制。作为 ICML 2019 的程序主席,Russ Salakhutdinov 表示他赞成 John Langford 的观点,他们在 ICML 2019 的评审中也引入了代码提交的选项。目前 ICML 2019 的评审结果已经出来了,那么你们提交代码了吗?
ICML、ICLR 和 NeurIPS 都在尝试将实验代码和数据作为评审材料的一部分提交,它们鼓励作者在评审或出版过程中提交代码以帮助结果可复现。目前,研究结果的可复现性通过论文、workshop 和演讲得到了很多讨论,也受到越来越多的关注。
最基本的驱动因素当然是目前的研究结果缺少可复现性,很多优秀研究都没有提供对应的代码。对任何评审和出版来说,可复现性的缺失是一个严肃的问题。因为后来的研究者会基于先驱工作做一些新的东西,缺乏可复现性将有碍这一过程。
其实由于随机初始化等机制缺乏可复现性,早期的神经网络研究并不受欢迎。虽然,目前证明神经网络的表征能力十分强大,但可复现性问题仍然存在。此外,研究中我们总会潜在怀疑前沿工作的结果是有一些水分,而提供可复现的代码能在一定程度上排除这样的质疑。
有了上面的观点,John Langford 表明可复现性的支持者应该将其理解为一个重要的属性,但并不是唯一的属性。例如,我们相信即使研究结果很难复现,但社区也能看到 AlphaGoZero 的发布。对于研究社区而言,真正有价值的是展示什么是可能的,而不是展示将围棋代码应用到另一种游戏的可能性。真正有价值的是展示算法更多的可能性,尽管它可能连代码都没有发布。如果我们将可复现性作为绝对价值,那么我们很可能就错过了这样的研究成果。
一个重要的观念是, 机器学习 至少有三种研究:
-
算法:这种研究的目标是发现一些更好的算法以解决各种学习问题,这是顶会上最典型的类型。
-
理论:该研究的目标是一般性地理解哪些学习算法是可能的,哪些是不可能的。虽然这些论文同样可能提出算法,但它们通常并不要求一定要实现,这会浪费作者、评审者和读者的时间。
-
应用:这一些研究的目标是解决特定的任务。AlphaGoZero 就是一个合理的例子,它在围棋上用算法击败了世界冠军。对于这类研究而言,由于计算量大、数据所有权等特点,编程的可复现性可能不切实际。
如果使用一种「放之四海皆准」的策略,要求每一篇论文都是可编程复现的,这种错误会降低研究社区的活力与创新。保证这三方面的研究的基本需求,将丰富社区的各种新思想。
如果我们从更广泛的角度来考虑这个论点,你是否希望医疗健康条例以所有科学研究为基础,包括那些不公开的数据?还是希望只以公共医疗领域的数据为基础?后者等价于忽略大多数科学研究,只针对特定领域做决策会有更好的效果。
强制方法的替代是将代码作为补充资料,附加材料在变化的评审过程中也能很好地追踪、记录。
-
在以前做机器学习研究时,论文不是双盲的。社区因为评审公正性开始使用双盲机制,无论是什么资历的作者和论文都能被公平评审。同时社区并不限制论文在发布前公布到 arXiv 上或者公开讨论,因为这会降低作者的研究效率。双盲评审社区可能有不同观念,但在 ML 领域这么做并没分歧。
-
在以前做机器学习研究时,提交论文的页数也有强制限制。对理论论文而言,证明部分不包括在内。我们后来改变了评审流程,允许(不要求)提交附录,便于评审使用。这为作者/评审增加了更多选择,获得了所有人的支持。
说到复现,我们能为社区做什么?
-
如果评审能够拿到底层代码或者数据,是否能更好地做评审工作?
-
开放代码对作者有好处吗?
-
开发代码对读者有好处吗?
如果准确无误,答案无疑是「yes」。
对评审而言,不为他们添加负担非常重要。评审可能缺乏计算资源、平台或者个人时间,无法完全复现论文结果。因此,我们应该像附录那样查看代码(和数据)提交,便于评审探究和使用。
对作者而言,放出代码有两个好处:提供额外的方法,说服善于质疑的评审;促进后续的工作也这么做,很多高引用量的论文都开放了源代码。当然,许多情况下不太可能放出代码或者对作者没好处。例如一篇理论论文,很可能算法不是重点,或者因为数据所有权,代码并不能完全公开。从此来看,我们应该有选择的支持、鼓励开放代码。
对读者而言,附加代码(和数据)明显增加了一篇论文的深度价值。一些读者可能用不到,但一些会用到(代码),在许多情况下这能极大的降低使用该论文的壁垒。
鼓励研究者添加附加实现,这也是 ICML2019 程序主席 Kamalika Chaudhuri 和 Ruslan Salakhutdinov 今年的策略。
除了鼓励外,我们需要进一步强制代码提交吗?考虑到一篇论文是否应该发布,持怀疑态度的审稿人肯定可以将可重复性的价值与其他价值进行权衡。因此有需要的话可以有附加代码,但强制代替提交却会降低其它价值。
我们应该少添加一些附加材料吗?我看不到理由:附加的方法能纯粹改进作者/评审/发布流程。不是每个人都能够利用这些好处,但限制其他人利用这些好处就很不合情理了。
最后值得一提的是,今年 ICML 的代码提交流程是个尝试。我们希望所有的程序主席能够作此尝试,因为这是改进的开始。我们应该尽全力尝试这样的工作,评估得失,预期明年的调整。
原文地址:http://hunch.net/?p=11377237
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 我们究竟应不应该使用框架?
- 计算机学生应不应该考研?附上袁哥的考研经历
- golang的强制类型转换
- Lucene 段的强制合并(一)
- Lucene 段的强制合并(二)
- 什么是Python的强制()用于?
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。