给正在写Paper的你:如何在成千上万的arXiv论文中脱颖而出?

本文为雷锋字幕组编译的技术博客,原标题 Heuristics for Scientific Writing (a Machine Learning Perspective),作者 Zachary C. Lipton。

翻译 | 生菜 刘宁 整理 | 凡江

今天是 1 月 28 号,我现在应该正在完成我的论文,你应该也是!但是当我们可以不写的时候为什么要写呢?ICML 的截止日期距今只有仅仅 12 天,KDD 紧随其后。ACL, COLT, ECML, UAI 和 NIPS 所有的都在放暑假之前截止,时间安排很紧几乎没有放松的时候。每一个期刊都会有成千上万的论文投递。

因为开源软件而民主化的机器学习使得大众对机器学习的兴趣激增,油管上的课程和可用的预印本文章都是令人兴奋的事情。但凡事皆有它的两面性。在接下来一个月投递给 arXiv 的成千上万的文章中,很多都会不值一读。 差劲的写作水平会注定一些文章被拒,另外一些会达不到该有的影响。即使在被接受的和有影响力的论文中,漫不经心的写作会造成混乱,并且会使一些文章之后被批评违背学术责任(你最好期待 Ali Rahimi 和 Ben Recht 不会赢得其他的经得起时间考验的奖项)。

但是等等,还是希望的!你的论文水平有救。从我的学术职业经历中,我对于如何写论文建立了强有力的观点(你可能不会同意所有这些观点)。 我最早跟 Charles Elkan 读 PHD 时了解到很多重要的科学论文写作的启法,把它们总结为精辟的格言,虽然这些格言可能有点过时。这段时间,我和更年轻的学生们一起工作,教他们如何写清晰的科学散文,我发现自己在重复这些格言,偶尔还会发现新的。

以下列举了一些很好记的规定,每一个都有简短的解释。有一些解释了语言,另一些交代了定位,还有一些处理了美学。大部分都只是启发所以有保留地接受它们,特别是当它们有争议的时候。当时如果你想要反对他们,请给出有力的理由。这是一篇很灵活的文章,如果你有很棒的点子,评论区欢迎来踩。

引言

摘要要简短

你不可能在摘要中把什么都写了,也别这么做。把摘要当做2分钟的聚光灯下的宣讲。要点要条理清晰,这有一个经过考验的准则:

1.用一句话或一个短语介绍问题;

2.解释现有方法的不足之处;

3.重点写出 : 清楚地描述你的主要贡献 (也可以用这个开头);

4.两三句说明细节,主要的定量结果等等。

这是我阅读到的机器学习的论文中第一个比较好的摘要

「Mixtures of Gaussians are among the most fundamental and widely used statistical models. Current techniques for learning such mixtures from data are local search heuristics with weak performance guarantees. We present the first provably correct algorithm for learning a mixture of Gaussians. The algorithm is very simple and returns the true centers of the Gaussians to within the precision specified by the user, with high probability. It runs in time only linear in the dimension of the data and polynomial in the number of Gaussians.」 「混合高斯模型是最基本的广泛使用的统计模型。目前的技术对于学习混合数据基本依赖于表现一般的局部搜索启发式算法。我们提供了第一个保证正确的用于学习混合高斯模型的算法。这个算法非常简单,而且能以很高概率返回由用户自定义精度的高斯模型真正的中心。」 – Sanjoy Dasgupta in Learning Mixtures of Gaussians(学习混合高斯模型)

注意到 Sanjoy 本可以通过合并开头的两句话来让文章更紧凑:「Current techniques for learning mixtures of Gaussians from data are local search heuristics with weak performance guarantees.」(目前的从数据中学习混合高斯模型的技术是效果一般的局部搜索启发式算法)

优点:更加精炼。

缺点:用关键词「Mixtures of Gaussians」(混合高斯模型)开头比现在的版本更夺人眼球

不要调戏读者

如果你有很棒的定量结果,一定要把数据放在摘要和引言;如果你的文章推导出一个可以操作的公式,放在引言。人们会继续阅读是因为他们感兴趣而不是因为你通过隐藏了信息来调戏他们。

删掉一般的开头

「The last 10 years have witnessed tremendous growth in data and computers.」(过去十年数据和电脑发生了巨变) 「Deep learning has had many successes at many things.」(深度学弟可以应用到很多方面)。如果你文章的第一句话可以添加到所有的机器学习/大数据的文章,删掉它。第一印象非常重要,第一句话是你的引言中最最珍贵的东西,不要浪费它。

在回答之前先问问题

如果你不相信存在问题,就很难对解决方案感到兴奋。如果你的文章非常抽象与现实世界没什么关系,那么它应该被视作纯数学的工作。那这篇文章大概不会成功。如果可以,用现实中引人注目的例子开头,提炼出抽象问题,用实验证明来解释这个激励人的实例。

聚焦于能做的,而不是不能的

有时候你需要提出对比,但是不要陷入负面描述观点,尤其是你自己的观点。当其他条件都一样(语义上地),不要拐弯抹角,直接准确地说某个事物是什么,而不要去管它不是什么。这个对于你自己的方法来说尤其如此。

组织

词组不是句子,句子不是段落,段落不是小节。 一个章节包括至少一个(或零个)小节。 一篇论文至少有一个章节。

一个作者糟糕的信号就是,在一字未读的时候,你就知道文章不好。 章节,就像 PPT 上的重点一样应该是平衡的。如果你只是列出章节标题,他们需要与所属的范围一样有意义。同样的规则适用于所有的组织结构。有时一个段落可以只有 2 句话,但是更稳妥的做法是一个段落至少有三句话。

读者应该只看图或者不看图就能理解你的论文

读者应该能通过你的论文准确地了解你的研究,即使他们错过了一些图片里的数据。任何重要的观察或者技术细节一定要放在论文的正文里,这样就可以引用图片来印证。

类似地,图片应该与文章紧密相连。如果读者跳过了图片(审稿人会),他们应该有可以做到大致了解研究过程并且理解新发现的重要性。如果很难看出Y值越大结果越好还是Y值越小结果越好,那么应该在插图里说明它。

但也不要太过,插图说明不应该是一大段话。好的插图说明应该在一到三行。 注意:在计算机视觉圈子,图片十分难处理。有时一个图片就会占满整个页面,并且有 100 多个关于草稿中缺失的细节的单词,我不喜欢这种风格,但是你要提交的会议是这种标准,你得自己决定。

迅速切入文章价值点

作为一名年轻的博士生,一个机器学习的圈外人,我很沮丧,因为只写论文是不够的,所以我尝试让圈外人能完全理解每篇论文。这让我赢得了一些普通读者,但是也导致了一些早期的会议投稿被拒。

对于会议论文来说首页太冗长非常不利(期刊不太适用),因为以下原因:(1)审稿人在相似的领域,每个会议读5-10篇论文,每年会读50-100篇论文,太基础的东西会让他们觉得非常枯燥。(2)如果你做的工作在第5页才开始(总共8页),对于没有达到审稿人的要求你就不应该有任何借口。

有两个关成败的点:了解你的读者并且聪明地排版。成句的摘要,成段的引言,成页的论文应该能清楚地说明你的研究。

预估读者的问题并在论文中回答它

一个好的审稿人会试图提出批判性的问题来挑战提交的文章,这个方法能成功可能是因为 X 吗?如果答案是「我不知道」或者「不」会很可怕。如果您能预见到这个问题而且知道答案,直接写下来。如果你不知道,做实验去找到答案。严谨的试验和清晰的写作紧密相连,我希望这个说法一针见血。

风格

科学论文中的「我们」

科学写作中,用可数名词「我们」叙述,有说教的作用:「我们」包含了「你(读者)」和「我/我们(读者)」。在这种情况下,当需要表达你的想法时,你需要通过上下文说清楚。

不要听天由命

任何一个有资格的读者阅读完你的整篇文章,即使他们生活中不会分享你的观点,方法或者价值,也不会单独否认任何句子。「 X 方式比 Y 方式在大多数的数据集上表现更好」大部分的什么数据集?你的审稿人会不会选择一些数据集,验证发现是错的?更好的方法是说「许多」数据集。这个定义更严谨而且更难反驳。

宁可少写,不可错写

与上面相似:如果你不能 100%确定你的判断,就不要写上去。审稿人很少会因为你少写一两句话拒绝你的论文,但是很容易因为结论写错而驳回。

语言

断开长句

年轻人总是错误的以为句子写得越长越能显示出自己的水平。然而优秀的科学文献作者却更常用短句来写作。当你绞尽脑汁想用一句话来表达你的观点时,可能用多句话来表达更好一些。科技写作的特点是越清晰明了越好,所以能简洁就尽量简洁。 你的论文的价值是其中精妙的观点,而不是华丽的词藻。

去掉用来强调的空洞的副词

例如:极其、非常、难以置信、完全、几乎、本质上、相当、绝对、肯定 等词

这类词之所以不好有以下两点原因:

1.它们削弱了自己用来强调的目的,例如: 「algorithm X provides a tight approximation (算法X给出了严格的近似解)」这样的表达语气是毋庸置疑的 , 而「algorithm X provides a very tight approximation (算法 X 给出了非常严格的近似解) 」听起来就有了一种不确定的感觉。

2.这些词使句子表达成为观点(而不是事实)。「Is the algorithm better? (这一算法更优吗?)」这种表达是可以的. 「Is it much better? (这一算法好的多吗?)」这就是个人观点了, 因此会带来不必要的麻烦 (见上文 AVOID HOSTAGE FORTUNE)。

主语、谓语和修饰语应该保持一致

写作中一个常见的错误是把动词和修饰词用于错误的主语,例如,「the algorithm tries to X(算法尝试在 X 上使用)」, 或者「the data is biased(数据是有偏见的)」。算法不能用尝试做动词,因为它并不能思考。如果我们想表达想法或偏好这样的动词,应该用「we」做主语,即它们是设计模型人的想法而不是算法的想法。听起来这是个常识性的错误,但是这样不一致的错误存在于所有学科的学术写作中。在一些领域中,例如机器学习的解释性和公平性领域,因为还没有标准化的定义,写作时不注意上述问题会导致整个领域的发展受阻。

推论:每个行为都应明确其由何而来。没有主语的动词常常出现在被动语态中 (句中动词是「to be」)。例如,「LSTMs are claimed to X, Y, Z(LSTMs 被声称...)」是谁声明了这一观点? 最好能将这一信息在其他地方说明。一种方法是加括号来注解,或者更好的方法是用直接引语来清楚的说明哪位作者声明了这一观点。

参考文献

多引用文章

你应该引用的一些文章很有可能就是你的审稿人写的文章。 一个常见的很无语的审稿意见就是有匿名审稿人问你为什么没有引用 A/B/C 的工作(其实全是一个人做的)。所以不相关的工作就不要引用。但如果有相关的工作,一篇都别落下,这样做百利而无一害。

这样做潜在的两点好处是:

1.你收到审稿人生气的回复的概率降低

2.那些引文的作者可能是你以后想要合作的人,他们可能会看到你引用他们的文章从而去读你的论文。

全文都要注意引用

审稿人通常都很懒也不能过目不忘。如果你的工作是基于别人的贡献时, 注意不要只把引用写在相关工作进展 这一部分-即在文献中说明研究背景的那部分。 你文章中哪里用到了前人提出的方法,就要把引用写在哪。这点对于近几年 (5-10 年) 的文章尤为重要,因为这些文章所讲的内容还没成为常识,因此人们会局限性地把引文全写在 相关工作进展部分。

写满引用页

这是一个比较实用的技巧主要适用于限制引用页数(通常 1 到 2 页)的会议文章。 如果你忘记引用最相关的文献,审稿人无论如何都不会放过你这一错误。 但是如果你遗漏了一些不是特别相关的文章,当他们提醒你时,你就可以借口说没地方写那篇引文了。但是如果你的引文页还空着,那就别指望审稿人会理解你了。

博客原址: http://approximatelycorrect.com/2018/01/29/heuristics-technical-scientific-writing-machine-learning-perspective/

原文发布于微信公众号 - AI科技评论(aitechtalk)

原文发表时间:2018-02-17

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏跟着阿笨一起玩NET

GB2312转换成UTF-8与utf_8转换成GB2312

1881
来自专栏阿炬.NET

c# datetime 格式化

2846
来自专栏菩提树下的杨过

MSDN官方的ASP.Net异步页面的经典示例代码

示例1.演示异步获取一个网址的内容,处理后显示在OutPut这一Label上 using System; using System.Web; using S...

1995
来自专栏海说

Java应用中常见的JDBC连接字符串(SQLite、MySQL、Oracle、Sybase、SQLServer、DB2)

Java应用中常见的JDBC连接字符串 Java应用中连接数据库是不可或缺的,于是便整理一些可能用到的JDBC的jar包及其相匹配的URL,以备日后查阅。 1)...

2730
来自专栏C/C++基础

C#获取系统当前时间

ystem.DateTime currentTime=new System.DateTime(); 1.1 取当前年月日时分秒 currentTime=Sy...

1153
来自专栏Pulsar-V

C#下各种获取时间的姿势

直接贴代码吧 DateTime dt = DateTime.Now; Label1.Text = dt.ToString();//2005-11-5 13:21...

3236
来自专栏xingoo, 一个梦想做发明家的程序员

windows程序设计-第四章 system1.c

/*---------------------------------------------------- SYSMETS1.C -- System M...

23710
来自专栏我和未来有约会

silverlight向服务器post数据类

using System; using System.Net; using System.Windows; using System.Windows.Co...

1975
来自专栏积累沉淀

Hive2.0.0操作HBase 1.2.1报错解决

首先看错  org.apache.hive.service.cli.HiveSQLException: Failed to open new session: ...

2359
来自专栏吴伟祥

Java Calendar 类的时间操作 原

Calendar 的 month 从 0 开始,也就是全年 12 个月由 0 ~ 11 进行表示。

783

扫码关注云+社区