参与:李泽南、Smith 从研究思想的提出到实验的具体实现是工程中的基础环节。但是这一过程常常被一些明显的小瑕疵所影响。在学术界,研究生需要辛苦的科研——大量的编写代码,撰写说明以及论文创作。新的工程项目经常需要全新的代码库,而且通常很难把过去应用过的代码直接延伸到这些新项目当中去。 基于此种情况,哥伦比亚大学计算机科学博士生及 OpenAI 研究者 Dustin Tran 从其个人角度概述了从研究思想到实验过程的步骤。其中最关键的步骤是提出新观点,这往往需要大量时间;而且至少对作者来说,实验环节不仅是学习,更是解决无法预测的问题的关键所在。另外,作者还明确说明:这个工作流程仅适用于实验方面的研究,理论研究则需要遵循另外的流程,尽管这两者也有一些共同点。机器之心对该工作流程进行了编译介绍,你有什么想法呢?不妨在评论中与我们分享。 找对问题 在真正开始一个项目之前,如何让你的想法「落地」成为更正式的议题是非常关键的。有时它很简单——就像导师会给你分配任务;或者处理一个特定的数据集或实际问题;又或是和你的合作者进行谈话来确定工作内容。 更为常见的是,研究其实是一系列想法(idea)不断迭代所产生的结果,这些想法通常是通过日常谈话、近期工作、阅读专业内和专业外领域文献和反复研读经典论文所产生的。
我的所有尚未探索过的研究思想的主文档 我发现了一种方法非常有用——即保持一个单一的主文档(master document),这通常需要很多工作。 首先,它有一个项目列表来排列所有的研究想法、问题和题目。有时它们可以是比较高层面的问题,就像「用于强化学习的贝叶斯/生成方法」、「解决机器学习领域的公平性问题」;也可以是一些很具体的议题,比如「处理 EP 中记忆复杂度的推理网络」、「规模偏置的与对称的 Dirichlet 先验的分析」。我经常努力把项目列表写得更加简明:子内容通过一些链接进行展开。 然后,根据接下来要做的工作来对 idea 清单进行分类。这通常会给我的后续研究指明方向。我也可以根据其方向是否和我的研究观点一致、其必要性和有效性随时修改这些项目的优先级。更重要的是,这个列表清单不仅仅是关于后续观点的,更是关于接下来我更愿意研究什么内容的。从长远角度来考虑,这对于找到重要问题和提出简单新颖的解决方法是有重要贡献的。我经常访问这个清单,重新安排事务,添加新想法,删除不必要的议题。最终当我可以详细说明一个 idea 的时候,它就可以成为一篇比较正式的论文了。一般来说,我发现在同一个位置(同一个格式)迭代 idea 的过程可以使正式论文写作中的衔接和实验过程都变得更加流畅。 管理一个项目
我们为近期的 arXiv 预印本搭建的 repository 我喜欢在 GitHub 存储库中维护研究项目。不管一个「单元」的研究是多少,我都会将其定义成某种相对自我包含的东西;比如,它可能会连接到一篇特定的论文、一个已被应用的数据分析或目前一个特定主题。 GitHub 存储库不仅可用于跟踪代码,而且还可用于跟踪一般的研究进程、论文写作进度或尝试其它合作项目。但项目的组织方式一直以来都是一个痛点。我比较喜欢以下的结构,该结构来自 Dave Blei,可参阅:~blei/seminar/2016_discrete_data/notes/week_01.pdf -- doc/ -- 2017-nips/ -- preamble/ -- img/ -- main.pdf -- main.tex -- introduction.tex-- etc/ -- 2017-03-25-whiteboard.jpg -- 2017-04-03-whiteboard.jpg -- 2017-04-06-dustin-comments.md -- 2017-04-08-dave-comments.pdf-- src/ -- checkpoints/ -- codebase/ -- log/ -- out/ -- 1.py -- 2.py-- README.md README.md 为自己和合作者保持了一个需要去做的事的列表,这让面临的问题和前进的方向变得明确。 doc/包含所有的记录事项,每个子目录都包含一个会议纪要或是文献提交,main.tex 是主要文档,每一章节都是不同文件,如 introduction.tex,让每个章节分开可以让多人同时处理不同的章节,避免合并冲突。有些人喜欢在主要实验完成后一次写出完整论文,但我更喜欢把论文作为目前想法的记录,并且让它和想法本身一样,随着实验的进展不断推进。 etc/是其他与前面的目录无关的内容。我通常用它来存储项目中讨论留下的白板内容的图片。有时候,我在日常工作中获得了一些灵感,我会将它们都记录在 Markdown 文档中,它也是一个用于处置对于工作的各种评论的目录,如合作者对于论文内容的反馈。 (责任编辑:本港台直播) |