Do-good-research-write-good-paper

前言

谁都可能犯错误，无意犯错不可怕，最重要是总结教训，不再犯。我也犯过各种各样的错误。

最怕的是故意犯错、作假。一步错，步步错，很难回头。

这个网页的目的是帮助同学们少无意犯错。做扎实的、正确的研究。另外，也会总结一些写论文的东西。

一些基本概念

开发集和测试集

最理想的情况下，和参加评测的情况一致，真正的测试集一直看不到，所有的性能指标都一直基于dev数据获取，从而评价模型、方法和参数的优劣。直到最终比较所提方法（超参数确定）时，才拿测试集跑出结果。

也有人为了方便，在输出dev结果的同时，将测试集结果也做出来。但是一定要保证在dev上选择超参数和方法。但是总是有诱惑的。

dev和test有时候也会出现不一致的情况，有的时候可能差距很大，差异很明显。一个方法在dev上比另一个方法好很多，但在test上比另一个方法则差很多。

详细的结果分析（包括定性分析）应该是dev还是在test上做？好像没有规定？

错误实验方法

测试集上挑选参数和模型

汇报测试集上的最好结果和别人比较

修改评价指标，和别人论文结果在不同的评价指标上比较

有的时候修改评价指标根本不是必须的，只会增加未来其他研究者做实验的复杂性。

论文

逻辑、简洁

逻辑是最重要的。段落之间，句子之间。

词语顺序的拿捏

用词的拿捏

最高境界：用最简单的话、合适的例子和图、简洁的表达，让读者准确理解。千万不要故弄玄虚，模棱两可。

格式的统一，能够体现出作者是否用心。

中英文混合

英文符号之间的空格要注意一定要有：

B, E, M, S # 英文逗号和后面的英文字符需要有空格
Finance(Fin)，Medicine(Med)，Literature(Lit)，Computer(Com) #英文圆括号(和前面的英文字符需要有空格

Latex英文文章插入中文

• \usepackage{xeCJK}
• 有可能会改变英文字体和行间距，那么后面插入：
  • \setmainfont{Times New Roman} # 重新设置英文字体
  • \setCJKmainfont{KaiTi} # 设置中文字体

数学公式

公式里的每一个符号在第一次出现时都应该明确解释说明，以增强可读性。

正文和公式中符号统一：黑体、斜体、大小写，不要出现中文的括号等

数学符号的使用要尽量规范，易懂

对上面公式进行解释不要分段（没有缩进、indent）：

where... 
其中，...

参考文献

参考文献格式统一：英文期刊、中文期刊、会议论文集（会议名称是否简写）；信息完整；页码尽可能有

参考文献在正文中引用的几种方法：

Li et al. (2017) propose
(Li et al., 2017) 
Li and Wang (2017)
Li (2017)
例： 有学者说这个人是坏蛋(Li et al., 2015[2]; Zhang and Fu, 2016[3])。Li et al. (2015) [2]和Zhang and Fu (2016) [3]说这个人是坏蛋。 

参考文件在正文中引用格式要统一，尤其是中文论文中：

不要有的写：Li等人 (2017)
而有的地方写：Li等 (2017)
如果没有特殊格式要求，建议可以用英文写法，比较清晰。

夏庆荣

英文reference 格式的要求： 样例：Cai, J.; He, S.; Li, Z.; and Zhao, H. 2018. A full end-to-end semantic role labeler, syntax-agnostic over syntax-aware? In Proceedings of COLING, 2753–2765.

• 统一：如果引用的会议名称是简写，那么其他的所有引用就都要求简写；如果是全写，那么其他全部都要简写。
• 会议论文的年份，页码要全。
• 期刊论文，如果不是很知名的期刊，可以写全称。
• 期刊论文的卷号，页码要全。
• 个例：如果有论文实在找不到页码，那么就不写。

写给同学们的一些话（待整理）

如何用简单的方法验证程序的正确性

• 如果发现同学故意伪造、修改实验数据，立刻请出课题组，换导师！即使是无意为之，也会根据严重程度，做出最严厉的惩罚！所以请同学们严谨的做科研，如果有问题拿不准，必须和老师讨论。
• 写程序的几个步骤：写完；调试，编译运行通过；验证正确性；必要的优化
  • 其中验证正确性，最重要，需要动脑筋
  • 训练过程中输出train/dev/test loss，train/dev/test性能（准确率/PRF），是一个肉眼判断、初步验证程序正确性的好办法。一般来说，train loss应该逐渐下降；train性能应该慢慢接近100%
• mini-batch算法的推荐实现
  • 每次迭代用完所有的训练实例，迭代前随机打乱所有实例（根据自己的问题和方法不同，可以有：句子级别实例、词语级别实例、shift-reduce方法中状态级别实例等）
  • 配置文件设置隔多少个batch在dev上进行测试；如果在dev上得到了一个最新的最好结果，那么在test上也输出结果（目的：1避免实验完成还需要再做一次test；2可以尽快了解dev和test的区别。其实严格来讲不应该在test做任何测试。）
    • 假设dev数据集一共N个句子，那么考虑每用掉~10N个训练句子，就跑一次评价。根据这个来设置隔多少batch进行一次评价（测试），可以凑个整
  • 如果连续50（或100等，根据自己的数据情况设置）个测试，dev上的性能没有提高，则停止训练
  • 如果超过最大迭代次数，也停止训练
  • 实验记录中这么记录，迭代次数iter=76/88（表示一共评价了88次，目前最好的评价次数是76）；注意train上的loss/accuracy也要想办法输出出来，看一下train上的收敛情况。如果实验已结束或杀死，那么也标记一下：[结束/杀死] @17硕-章波 @17硕-江心舟
  • 迭代一次（两次评价的间隔）的时间，也要记录一下。并写清楚和速度相关的设置，如CPU线程数，batch大小，隔多少batch评价一次等

科研诚信

不抄袭
不一稿多投
实验绝不可刻意作假。我们组做的东西都要见得了光，别人把咱们的代码和数据拿过去，一定可以重现出来。
搞清楚dev/test集合的作用，坚决不可以用test挑选模型。某些特殊情况下，比如刚刚接触一个数据，可以输出test的结果，但是不能汇报test上最好的结果。而是根据dev上最好的结果选择模型，然后汇报对应的test上的结果。
充分尊重前人工作，写论文时诚实地定位自己工作的贡献。这样学术圈的工作脉络才会越来越清楚，学术氛围会越来越干净。