丁霄汉:学术论文写作指导–从”Hard to Follow”到高可读性

作者:丁霄汉
时间:2025年1月15日
来源:学术写作经验分享


前言

几年间我主笔或大改了20篇左右的顶会论文,一开始是在清华的实验室里苦思冥想,被拒了好几次才有点长进,基本不会因为写作被秒拒了;后来实习和工作时,在帮实习生和学弟改文章的过程中也发现了一些常见问题。我想总结一些给顶会论文写作新手的建议。如果能帮助同学们少走弯路的话,我将不胜荣幸。

这几条建议将分成上下两篇,每篇聚焦于如何避免收到一条致命的”恶评”,分别是:


目录

第一部分:宏观布局,避免”hard to follow”

第二部分:精耕细作,提高”readability”


前言

几年间我主笔或大改了20篇左右的顶会论文,一开始是在清华的实验室里苦思冥想,被拒了好几次才有点长进,基本不会因为写作被秒拒了;后来实习和工作时,在帮实习生和学弟改文章的过程中也发现了一些常见问题。我想总结一些给顶会论文写作新手的建议。如果能帮助同学们少走弯路的话,我将不胜荣幸。

这几条建议将分成上下两篇,每篇聚焦于如何避免收到一条致命的”恶评”,分别是:


第一部分:宏观布局,避免”hard to follow”

本篇先从”hard to follow”开始。缺乏经验的同学收到这样的恶评外加一个strong reject之后可能会感到迷惑和委屈,所以本文首先从审稿人的角度来分析他们为什么会对你的文章作出这样的评价,然后通过两个例子给出相应的写作建议。

审稿人视角

这个评价可能表示论文的宏观组织形式和内容分布与审稿人所期望的有较大的差距,所以他在耐心耗尽前没能搞懂你做了什么。对同一篇文章,审稿人想的跟作者想的到底差在哪呢? 一位同学可能会对自己刚完成的论文很满意,因为:

例子1:不要完整还原研究的心路历程

我为了解决一个重要的已知问题(问题甲)提出了方案A(跟其他人的方法相比变化很大),发现方案A不够好,研究一下为什么方案A不够好呢,发现这是因为方案A引入了另一个问题(问题乙);我研究了一下如何解决问题乙,最终提出了改进版方案B(在A的基础上改动很小,加一个trick),所有问题都解决了。而且这个trick用在其他方法中也有提升。我提出了两个方案,还发现了一个别人没发现的问题,我觉得这篇文章很稳。 但审稿人是以不同的视角来看这篇文章的,他并没有亲身经历我的研究过程,不可能像我一样清楚重点在哪里。他可能会问:

例子2:不要轻言”based on”和”A+B”

“提出了基于AAA和BBB的XXX”是本科毕业论文里常用的说法,适用于需要稳妥安全而不怎么需要创新性的场合。在顶会论文里这么写,可能会把本来还不错的创新性给写没了。在大多数情况下,不要轻言自己的工作“based on”,你完全可以说自己注意到了某个重要问题,琢磨明白了背后的原理,想到了一个解决方案,提出的是一种新的东西,这种东西自然地用到了AAA和BBB,而不是简单地改了改人家的成果。 设想一下,把ResNet的写作改成“based on”和“A+B”的形式,是不是就把创新性写没了? 《ResNet: Yet Another Simplified GoogLeNet》 :我们基于GoogLeNet和VGGNet设计了一种大量用3x3卷积(借鉴VGGNet)和并行shortcut(简化自GoogleNet)的模型,超越了GoogLeNet和VGGNet。为什么效果这么好呢?因为VGGNet和GoogLeNet珠玉在前,Batch Norm也很好用。反正这个工作就是这么简单,我们没有想到理论上有什么创新性,但我们给后续的工作搭建了一个好的baseline。 这样的文章能让读者学到多少东西呢? ResNet实际上是怎么写的呢?

总结和其他建议


第二部分:精耕细作,提高”readability”

在《顶会论文写作建议(上):宏观布局,避免“hard to follow”》中,我们讨论了如何在宏观层面设计论文的结构,以大多数人乐于接受的方式卖出自己的核心贡献。 在本篇中,我们将会聚焦于语言组织的层面,通过十几个我近几年从清华的学弟或实习生同学的论文中收集到的例子,讨论如何提高文章可读性,让读者能心平气和、行云流水地读完,让审稿人能更客观且无痛地评判文章的价值。 需要注意的是,我们讨论的前提是假设论文至少在语法层面是正确的,不再讨论那些可以用Grammarly或ChatGPT自动解决的基础问题。 正如上篇所说,大部分论文都可以写成提出问题——抽象出背后的原理——解决问题的格式(俗称讲故事)。本篇的宏观结构也将遵循这一套路,从而作为对上篇所述宏观写作原则的一次具体实践。 假设本文真的是一篇论文,那么在省略了一大堆关于写作如何重要、写作如何成为了一个重要的研究领域、引用了一大堆关于写作的重要prior work(作者自己也不一定看过,但是看到别人都在引所以就引了)的铺垫语句之后(这些气氛句子本来也没人会看,所以我就不写了),我们的故事现在开始。 本文提出用以下概念来度量文章的可读性:逻辑强度、防御弹性、迷惑时间、信息密度。在此之上,本文提出一些实用的建议和技巧来提高文章的可读性。

逻辑强度

在任何语言的学术写作中,逻辑的连贯都远比用词的华丽更重要。上篇已经介绍了一些宏观逻辑设计上的技巧。在微观层面需要注意的是,逻辑的连贯在于逻辑本身,而不在于衔接词(to this end, in contrast, specifically等等)。 换句话说,我们应该把衔接词当成使语言更加流畅的点缀,而不是通过衔接词来为本没有逻辑的句子强行构造逻辑。例如从总括到具体描述时,用“Specifically, …”;前后两句存在对比关系时,用“In contrast, …”。 而不是反过来!并不是我们写下“In contrast”,前后两句就真的因此而有了对比关系。衔接词与真实逻辑的不匹配会让人疑惑,显著降低文章的可读性。 我们的高中英语写作将衔接词的存在视作逻辑本身,甚至当成作文中的加分项。实际上,用一大堆衔接词不一定能提高文章的流畅程度,反而可能有负面作用。 我们写下每一个衔接词之后都要三省吾身:它前后两句的逻辑关系真实存在吗?它自身放在这个语境下正确吗?不用它行不行? 例1:衔接词必须自身正确,经得起推敲。 We argue that problem A is critical. To this end, we propose method B. 作者写下这句的时候想的可能只是挑个词来通过problem A引出method B,逻辑是显然的,但写出来的句子却是经不起推敲的:”this end”中的this指的是哪个end?上文说了一个“end“(要做什么/要实现什么目的)吗?上文实际上只是提出了一个观点,并没有说要做什么,所以这个衔接词自身的存在就是错误的。 例2:衔接词不能强加逻辑关系。 The system comprises three modules. First of all, Module A is …. Second, Module B is …. Last but not least, Module C is …. 作者的本意是描述三个并列的事物,这几个衔接词却给这三个本来没有次序关系的东西强加了一定的次序。这时候就不如去掉这些词,分别介绍三个事物即可,根本不用加任何衔接,语言依然流畅:The system comprises three modules. Module A… Module B… Module C.. 例3:衔接词要准确反应真实逻辑关系。 The baseline model is … On top of that, model A employs an extra attention module. In contrast, we propose a novel objective function. 这句话让人迷惑:我们的模型除了这个novel objective function以外是否也用了这个extra attention module呢?读者在寻找“In contrast”对比的对象的时候可以有两种理解。 读者可以理解成model A和我们的模型是用两种方式来解决同一问题,model A用了这一结构而没用这一目标函数,我们是用了这一目标函数而没用这一结构。读者也可以理解成我们试图拿model A和我们自己的方法对比以凸显这个目标函数的效果,所以我们的模型等于model A + 这个新提出的目标函数。 如何修改呢?如果一定要对比的话(比如你的那位不怎么懂但是confidence分数拉满的审稿人一定要让你对比),应该在结构和loss两方面分别讨论从而形成对比,消除歧义,顺便突出我们的优势: From a structural perspective, model A introduces an extra attention module while we use the same model structure as the baseline. In terms of the objective function, method A adopts the vanilla XXX loss, which suffers from …, while we … 这也就是我们所说的,先有逻辑(”我们要从两个方面进行对比!”)后有衔接词(当然不用也行),而不是用衔接词构造逻辑(简单塞进去一个In contrast并期望对比关系就因此而产生)。

防御弹性

在写作的时候,我们每写完一句话都要考虑审稿人可能从哪个角度攻击这句话。“防御弹性”指的是我们的语言引起审稿人的质疑的频率和面对审稿人的挑剔时的抵抗能力。 正如写代码时要有“防御式编程”的概念,写作时也要有“防御式写作”的意识,随时考虑笔下的语句是不是无懈可击的。 例4:言出有据。 当我们说“Problem A是本领域的关键问题且尚未得到解决”,这时就要考虑到审稿人可能会问:“为什么说这是关键问题?它造成的后果有多严重?这种后果对最终性能影响大吗?”这就需要我们完善引用: It is reported that problem A results in … [1,2,3] and … [4,5], which are critical to … because … [6, 7, 8]. 丰富且适当的引用会让人觉得作者学识渊博,对本领域理解深刻(哪怕你只看过那些文章的摘要,只是在制造这样的幻象也行)。 例5:轻重适当。 在展示了实验结果之后,我们往往需要解释为什么我们的方法会work。不解释一般是不行的,解释的太绝对了又可能被审稿人challenge(“怎么证明?有什么理论?”),这时就要把握轻重。

迷惑时间

“迷惑时间”是读者在阅读过程中每一次“咦,这是啥”到“哦,原来是这样”之间的时间的总和。当代人类的耐心是有限的,一篇文章的总的迷惑时间越短,可读性就越高,审稿人就会越心平气和。 例7:提出一个概念后应就近解释。 在深度学习领域中,一个复杂的模型中的一个简单结构根据其功能(和讲故事的需要)可能被命名为XXX Perceiver, XXX Perceptron, XXX Recognizer, XXX Gating Function等等。 建议在给出其名字以后直接解释其实质(we propose XXX, which is implemented with a two-layer MLP)。不然如果在Introduction里只给出了它的名字而在Method部分再给出其实现的话,读者会在很长的一段时间里带着“这么玄乎的东西到底是个啥”的疑惑,最后发现“原来就这啊”,阅读体验很不好。 例8:指代对象应显然且毫无歧义。 We update structure A to solve the problem caused by model B, which is widely used in the literature. 这里“widely used”到底是A还是B?如果我们的写作水平有限,无法让长句完全不带歧义的话,就应该将其拆为短句。没有人会因为你缺少展示高超英语水平的长难句而拒你的文章! 例9:不要在需要读者集中注意力时多次引用数页后的内容。 我们在introduction里可以提几句我们的结果有多么多么好,带上几个对后面的图表的reference,但不要频繁这么干,尤其是不要在需要读者集中注意力(比如你正在激情四射地展开自己的核心故事,需要读者来判断这个故事是否合理的时候),不然读者翻过去再翻回来的这段时间里思维就断了。读者思维的连续性也是可读性的一部分,毕竟论文是线性叙事。这也是孙剑老师教我的最后一点。

信息密度

信息密度就不是什么新的概念了,指的是读者能从单位长度的文字中提取到的有效信息量。信息密度过低的文章会让人走神并怀疑作者的专业性。 例10:气氛组语句不应过于冗长。 我们都知道每篇论文中总有一些不会有人认真看的句子,这些句子一般位于各章开头,且其中“recent years”含量极高。这些句子一般还是要写几句的,但建议注意以下几点。

As can be observed in Table 1, A outperforms B. 改为 Table 1 shows that A outperforms B.

Table 1 shows that the accuracy of model A is 81.0% and the accuracy of model B is 80.0%, so we conclude that model A outperforms model B. 改为 Table 1 shows that model A outperforms model B by 1.0% in the accuracy (81.0% v.s. 80.0%). 用简练的语言准确表达意思是一门技术活,具有本质的困难性。建议多看英语母语者写的论文和其他文字内容,特别是那些有丰富教学经验的年轻选手,因为写教案是最锻炼语言组织能力的(对的,我说的就是当年斯坦福CS231N的主讲Andrej Karpathy)。 例12:图表附近应是全文中信息密度最高的地方,重要的解释和阐述距离图表越近越好。