近日，微软研究院自适应系统和交互组研究人员、华盛顿大学 Affiliate 助理教授、ACL 最佳论文奖得主 Marco Tulio Ribeiro 撰写了两篇博客，分享作为研究人员应该怎么做项目的建议。本文将对两篇篇博客的中心思想进行了编译整理。 >>加入极市CV技术交流群，走在计算机视觉的最前沿
三思后行，搞学术也是一样的道理。但如何思考才是正确的呢？
接下来我应该做什么项目呢？对于从本科生到博士生及从事更深研究的任何人来说，这是一个反复出现的问题。其实，这个问题可以分解成以下几步走：第一步提出想法，第二步组织和充实想法，第三步决定哪些想法值得作为研究项目。
近日，微软研究院自适应系统和交互组研究人员、华盛顿大学 Affiliate 助理教授、ACL 最佳论文奖得主 Marco Tulio Ribeiro 撰写了两篇博客，分别展示了第一步过程中的启发式方法以及在第二、三步中如何做。
Marco Tulio Ribeiro。图源：microsoft
在博客中，Ribeiro 使用了自己工作中的很多轶事，不过也表示这并不是让每个人都应该做他做的事，只是为了展示他在做这些事的过程中产生了最深刻的洞察力。此外，他的建议和启发式方法偏向于自己喜欢做的研究，其他人都应该保持自己的风格和偏好。
卡内基梅隆大学助理教授陈天奇、UC Santa Barbara 计算机科学系助理教授王威廉也在推特上推荐了这两篇博客：「这对新人研究员来说是非常好的建议。」
本文将对两篇篇博客的中心思想进行了编译整理（以第一人称转述），内容如下：
想法往往出现在你当前知识的相邻可能（adjacent possible）中。你知道的越多，就越容易提出新的想法。我认为一个好的经验是努力对自己的很多相邻领域进行广泛的概述，然后在自己的领域真正地深入研究，或者根据需要解决项目中的一个子问题。更具体地，课程和调研论文非常适合获得广泛的概述，这是因为其他人已经以连贯的思路编译、组织和呈现重要信息，省去了你的诸多麻烦。
对于课程来说，很快就会过时或者没有涵盖你想要获得详细概述的子领域，比如你很容易找到一门 NLP 课程，但很难找到 NLP 中关于可解释性的课程。最近的论文或演讲可能更新，但也可能很快就会过时。关键在于了解整体研究趋势，而不陷入细枝末节中，除非你想深耕某一领域。我就会特别关注人们正在解决哪些问题、哪些技术最先进以及如何完成评估。
与此同时，我还有意识地在日程安排上留出一些学习的时间，但在弄清楚读什么或者学习什么方面并不是非常系统，有时随机性可能也挺好的。
比如，如果我在不同的论文中看到了自己不熟悉的问题或技术，通常会下功夫学习它们。我还请求合作者给我发一些他们最近非常喜欢的论文。我喜欢使用的另一种启发式方法是阅读在 ML 和 NLP 顶会中获奖的论文，即使与我的研究无关。最后，我强烈建议在 poster 环节四处走动并与作者多多交流，以便为未来的学习努力积累素材。
除了努力扩展相邻可能之外，我还喜欢如下几条启发式方法。需要注意，这些方法是相互重叠的，虽然不甚详尽，但我认为它们非常有用。
美国数学家 Richard Hamming 曾提出过一条著名的建议：你应该了解自己所在领域的最重要问题是什么，并努力解决它们。这条建议还有一个鲜为人知的附录，对伟大的科学家进行了描述：
他们通常有 10 到 20 个想要解决的重要问题。当他们看到一个新想法出现时，人们会听到他们说「这个想法与这些问题中的某一个相关。」
我认为这里发挥作用的原则是，当我们有意识地优先考虑某件事时，往往注意到其他事情与它的关联，却看轻任何其他的一切。列出重要问题的清单是一种有目的地设置过滤器的方法，能够帮你在阅读论文、观看演讲或处理其他事情时注意到关联。换言之，这是一种确保你始终检查自己获得的新知识是否可以在某些问题上展开相邻可能的方法。
我认为，设置过滤器通常是一种极好的做法，而做到这点的一种方式就是一一列出你想要提出想法的事情。我的问题清单当然由自己的兴趣和偏好决定，但也发现向自己尊重的研究者询问他们最重要问题的清单并咨询自己清单中应该推迟的项目很有用。
在进行研究（或课程项目）的过程中，大多数人常常会遭遇失败，也就是尝试了一些没有效果的事情。当你觉得一些技术应该可以解决自己的问题但未能如愿时，尤其令人恼火。
不过，这样的失败和烦恼是培养新想法的沃土，但前提是你需要花时间弄明白问题在哪里以及什么导致了问题的发生。由于这些失败往往与你当时实际做的任何事情关系不大，因此当你找到应对方法或放弃时，很容易会忽略到它们。相反，我建议记下并做出一个我搞不懂的失败清单，以便之后继续调研。
我非常喜欢这种方法，因为在无意中搞定了自己的博士论文题目。我曾经在谷歌实习，训练的一个模型在现实世界中表现糟糕，尽管它具有很好的交叉验证准确率。我花了很多时间获得新数据、进行输入扰动和观察预测结果。这真的让我很烦，毕竟花了这么长的时间才搞清楚自己的模型实际表现怎么样。我的导师让我就这个实习项目做一个展示，而我最终只谈了自己的烦恼，而不是在实习期间具体做了什么。
之后，导师问我是否想要解决这个问题。当时我正在进行一个不相关的课题（分布式系统和机器学习），但还是转向了该问题并写出了下面的论文，并为我余下的博士研究定下了基调。我的很多其他论文也都以类似的方式写出来，这都与我倾向于研究让自己烦恼的事情相关。
论文地址：
https://arxiv.org/pdf/1602.04938.pdf
制造失败：如果你没有失败清单又该怎么办呢？不用担心，我这里有一种非常可靠的方法来创建这种清单。如果你读到了一篇喜欢的论文或者发现一些高大上的新技术或模型（如 BERT、GPT-3、CLIP、Dall-E 等），花时间思考这些技术或模型如何用来做一些论文中没有做过的有用或很酷的事情，然后努力去做。虽然往往会以失败告终，你就可以开始对失败进行调研。
尝试在现有工作和未解决的问题之间找到类比。这感觉像是对上述 von Neumann / Hamming 示例的重复，但我认为值得指出的是，这种启发超越了「将技术 X 应用于问题 Y」。
早在 2017 年，就有很多关于视觉模型对抗样本的论文，但对于文本模型来说，没有什么真正令人满意的成果。造成这种情况的部分原因是图像处于连续空间中，因此很容易定义与人类感知大致对应的距离度量（例如，具有较小 L2 范数的像素扰动对人眼来说几乎是不可察觉的）。
那时我正在做另一个项目，在那里我试图找到「足够」的输入子集，将预测用作解释。让我感到困扰的是，文本模型的子集通常比我预期的要大得多，因为模型对微小的变化非常敏感。在某个时候，我突然意识到，令我困扰的是预测随着语义的微小变化而改变，而不是字符或单词的数量。例如，如果情感分析模型对「这是一部好电影」和「这不是一部好电影」有不同的预测（即使只改变了一个词），那很好；但如果它对「这部电影」有不同的预测，那就不行了。我意识到文本中「小的 L2 范数」的正确类比是「小的语义距离」，而不是「小的编辑距离」，于是我写了一篇论文。
这个项目反过来又导致了另一个类比。除了个别对抗样本之外，我们最终提出了对抗性规则——类似于正则表达式的规则（例如，将 What is 替换为 What's）导致模型改变了很多预测。
当我把这个 demo 给一个朋友时，他告诉我「这些规则就像 ML 的单元测试」。我喜欢这个类比，并开始思考「我还想写什么其他类型的单元测试？」。
我认为这清楚地表明，使用类比不仅仅是将技术应用于新问题，而是可以探索相似之处和不同之处。类比既是一种约束（可以在类比不成立的部分被丢弃），也是来自原始领域的现成想法的来源，你可以尝试将其应用于新领域。
这种启发的一个好处是，即使它失败了，它也会导致对某些现状的更好理解，从而扩大你的相邻可能性，并在未来产生更好的想法。
这很重要，因为这种启发经常会面临失败，通常有一个原因使某事只能维持现状（当它很容易时，其他人往往会在你之前完成）。然而，当它成功时，它会是非常酷的工作。我想到的一个例子是 HOGWILD! 论文（NeurIPS 2020 时间检验奖），它挑战了尝试并行化 SGD 时需要一些同步的（非常合理的）假设。这篇论文很酷的原因之一是因为当时的现状是如此合理——每个人都知道在并行化任何算法时需要处理竞争条件，但你使用了 lock 来做到这一点。
「idea 很廉价，执行才意味着一切。」这句话或许适用于其他领域（比如初创公司），但这两个条款都不太适用于研究。虽然产生「OK」的 idea 很容易，但好的 idea 并不会是廉价的，而且产生更多的 idea 是获得优秀 idea 的最佳方法之一。此外，虽然执行很重要，但一些伟大论文的贡献就在于 idea，即使当时它在执行上并不出色。
在上文提到的谷歌实习经历中，我为一个项目工作了大概 6 周，然后我与一位高级研究员进行了对话，希望获得技术上的帮助，让我的解决方案发挥作用。
但我带着崩溃的心态离开了会议室，因为他们让我相信自己正在处理的是一个糟糕的问题，因此即使解决方案确实有效，也无关紧要。这是一堂特别有价值的课程，这次之后，我决心好好考量我所想要解决的每一个问题。
不过时间久了，我也淡忘了这一课的教训。在我完成关于可解释性的第二篇论文后不久，我浪费了很多时间（大概几个月）在一个现在看来甚至难以描述的项目上徘徊。如果我没记错的话，它是「统一可解释性」、「一堆很酷的可解释性实验」和「新的可解释性技术」的混合体——这些都不够清晰，也无法评估，没有利于任何有意义的进展。
从那时起，我一直在使用并不断改进结构化流程，以确保我不会忘记提出过去发现有用的某些问题。我将这些流程编入模板或清单。
以下是我目前将想法组织成潜在项目的模板。在我的 CheckList 论文开发过程中，我使用模板的快照作为执行示例。
CheckList ：我们想知道我们的模型是否符合业务规则、先验知识和常识。现在，即使是专家也很难写出这些是什么。大多数人甚至没有想过他们为什么需要这样做。
为什么困扰：总结一下为什么这个问题很重要，或者我们为什么关心它的解决。
CheckList ：训练 / 评估数据是静态的，通常导致模型的偏差。
准确性通常不是我们关心的全部，而且测试集几乎从来没有足够大或变化到足以测试某些行为（例如，模型在存在拼写错误时的行为方式，模型对于某些异常值的行为方式等）。
当前的解决方案及其失败的原因：一个可能适用于「问题」的方法列表，即使它们不是专门为它设计的。请注意，「它们失败了」并不是说这些方法不好，只是它们不能解决我们的问题，即使它们在其他方面非常出色。
CheckList 示例：我列出了一堆方法（与这篇博文无关），并说「这些方法并不能真正测试人类期望的模型行为，只有少数例外。此外，有些需要访问模型内部。」
如果我有一个解决方案，它会是什么样子？这样做的重点不是实际提出解决方案，而是「映射」我们期望什么样的解决方案，如下面的示例所示。如果你能想出多种可能的解决方案，那就更好了。
CheckList 示例：一个测试框架，包括不同测试类型的分类
我怎么知道我是否解决了它？同样，这主要是评估的草图（不需要详细信息）
- 许多令人信服的 SOTA 模型未能通过测试的示例，并收集到见解
- 与微软工程师进行的「用户研究」，我们（希望）表明他们在编写测试后在自己的模型中发现了一堆（可修复的）问题.
什么是不确定性？这必须是真的吗？这个解决方案不能正常工作是什么？这是关于绘制出高度不确定性的区域，并确保我们尽可能快地排除会使项目或解决方案草图无效的事情。
- 如果我是唯一能够进行测试的用户，那么这将是失败的。
- 如果 SOTA 模型仅在特殊测试中失败，则可能准确性已经足够好，我们不需要这个项目了
计划草图是这里的关键词。我们只需要前几个步骤的合理细节，而第一步通常是某种形式的初步文献综述。
- 为 SOTA 情绪分析模型写测试 - 为其他几个模型（释义，SQuAD）编写测试
前五点（直到「我怎么知道我解决了它」）是让我们了解项目是什么，如果成功，世界会发生什么变化，我们为什么关心这种变化，以及我们如何展示确实发生了一些变化。
最后两点主要是为了评估项目（下一节），并有一个关于如何取得进展的试探性「草图」。
除了组织新想法之外，这个模板是我使用的一个更大模板的一个子集，并且在我处理我的项目时会不断修改（我计划在未来写一篇关于这个的帖子）。模板的第一个版本几乎总是以某种方式出错，例如问题定义在中途发生变化，我们提出的解决方案与我们最初的猜测完全不同，评估完全不同等等。但是，我们发现在这个阶段有一个暂定版本比根本没有模板要好得多，即使以后一切都变了。
需要注意的是，这个模板非常面向「问题」，而不是面向「解决方案」。这恰好是我喜欢做的那种研究，因此我自然有更多的经验。话虽如此，我认为这里的一些想法可以（通过一些调整）应用于更具探索性的想法，其中问题定义可能有点模糊。
上面的模板有助于使想法更具体，并避免定义不明确的项目。但是，我们仍然需要决定是否要在一个特定的项目上工作，或者在众多项目中选择哪个。
我看到许多研究生开始从事第一个向他们展示的「足够好」的项目。我认为这是一种糟糕的方法，因为大多数人发现很难放弃项目，而且提出替代想法的时间比结束项目的时间要短得多（几周 vs 几个月）。
当然，这里的目标函数取决于你的总体目标。对于试图美化简历的本科生来说，最好的项目通常与试图建立论文方向的研究生或希望他们的研究为现有产品增加价值的行业研究人员不同。
其次，时间限制也很重要——例如，实习项目通常限制在 12-16 周。
最后，必须考虑可用的资源，无论是个人资源（例如，与新手相比，有经验的研究人员通常能够更好地解决一个非常开放的问题）或机构资源（例如，计算的可用性、资金用于众包、工程帮助等）。
基于这些警告，我认为一些不算全面的启发式方法有助于避免陷入常见陷阱。
写下项目工作的可能结果，以及你对可能性的估计（尽量具体）。有些项目在极端情况下（成功或失败）更加极端，而其他项目则更有可能部分成功。即使是粗略的估计也会迫使你考虑当前的资源和限制如何影响成功的可能性，以及可以预期的成功或失败，例如「如果我成功，这个项目会产生什么样的影响？」，以及「我能确定几周后肯定失败，还是几个月后才能知道？」。
反过来，这可以帮助你考虑风险 / 回报组合以及该项目的概况是否符合目标，例如，如果你是一名希望很快毕业的研究生，就不应该接受一个风险很大且很少有人参与的项目。
一个警告是，你应该对这些估计判断出非常高的不确定性，并且要非常小心过早的优化。我认为在当前的最佳估计中添加一些随机性（例如，根据当前的信念和目标做一些没有真正「意义」的项目）是一个很好的策略，可以避免因为你无法预料到它们而错失良机。鉴于我们大多数人都不擅长估计结果及其概率，我仍然认为在评估项目时做出粗略的估计是有用的，即使人们不会太认真地对待这些估计。
这可以算是启发 1 的一个应用，但我认为它的重要性足以独立存在。请注意，我并不是说「上限高」是一个好的项目的充分条件，但无论你如何定义「成功」或「奖励」，「下限」通常足以拒绝一个项目。你可能不同意（这很好），但我只是认为，如果最好的情况是一篇「好的」论文（即使风险接近于零），那么在几乎任何项目上花费大量时间都是不值得的。我的导师曾经说过，一篇伟大论文比三篇好论文更有价值，我认为这种心态真的很有帮助。当然，你不能保证伟大，但如果你追求「足够好」，通常是能做到的。
这里的一个例外是申请博士课程的学生，其中顶级论文的数量似乎很重要。在这种情况下，将发表所需的风险和努力最小化似乎是一个不错的策略，即使你最终得到了一连串好论文（我建议在你开始攻读博士学位后改变策略）。
与其做出接受或拒绝项目的不可逆决定，不如收集更多信息以完善提案并减少不确定性。
一个警告：对项目的投资越多，沉没成本就越多。因此，这可能看起来很愚蠢，但我认为在此期间将项目视为一种可能性（而不是确定性）来思考和讨论是很重要的阶段，例如避免说「这是我现在正在做的项目」。
几个人推销项目，看看他们是否「购买」你的故事，你对其重要性的估计，当前解决方案的缺点等。我认为在这一点上持怀疑态度和消极的人很好，反而是「That's cool」这种回应并没有给我们太多信息。
可能有点矛盾的是，我认为你不应该太听从他们的看法。大多数原创想法一开始听起来都不太好。如果你不气馁，负面反馈正好是模板中「不确定性」部分的绝佳素材。此外，或许这是进行文献综述的好方法，因为人们会问你「这不是 X 在 1984 年完成的吗？」
作为个人轶事，我将一篇获得了最佳论文奖的论文投给了一些比我更资深、更有经验的 NLP 人员，他们给了我非常负面的反馈，而且非常肯定。这样的反应真的出乎我的意料（我认为这个项目很酷），但也确实有助于让我在模板的「我怎么知道我解决了它」部分更加谨慎。向专家询问不确定的具体问题，也是一种降低失败风险不确定性的方法。
回顾模板的「不确定性」部分，并尝试减少不确定性，尤其是在可能导致项目失败的事情上。这里经常有可能出现作弊，例如，如果建议的解决方案是 A → B → C → D 并且你对 D 有不确定性，那不如先伪造一个 C 而不是从 A → B → C。
黑客攻击非常适合确保你很好地解决了问题。即使你手动完成所有步骤，也必须检查自己提出的任何步骤和「输出」是否现实。
参与黑客会议的结果可能是与一群新人交谈的好素材，因为你通常会得到具体的例子，让人们很容易想象一个项目的「最终结果」。
John Tukey 说过：「对正确问题的近似答案比对近似问题的精确答案更有价值。」
无论好坏，选择一个研究项目都会在很长一段时间内（对大多数人来说是 3 到 12 个月）决定你的工作轨迹。此外，正如上面的引述所指出的，即使是在一个好问题上取得平庸的进展，也可能比在一个不那么重要的问题上取得优异的进展更有价值。
第一篇：https://medium.com/@marcotcr/coming-up-with-research-ideas-3032682e5852
第二篇：https://medium.com/@marcotcr/organizing-and-evaluating-research-ideas-e137637b599e
公众号后台回复“ECCV2022”获取论文分类资源下载～
![]()
微信扫码咨询专知VIP会员