JetBrains 软件工程机器学习方法 研究实验室负责人 Timofey Bryksin 回答了有关团队工作、团队试图解决的问题以及他领导的实验室感兴趣的其他主题的问题。

这是三部分系列采访的第一部分。

你们实验室负责哪些任务？

我们希望利用数据驱动的方式，使软件开发社区，特别是 JetBrains 受益。 我们的关注点很广泛，我们寻找可以改进现有产品和团队工作方式的想法。 开发软件时，会生成大量数据，其中有些有用，有些不太有用。基于这些数据，我们可以找出人们编写代码的模式。 这些模式帮助我们深入理解具体流程，以及最好的利用方法。

可以举几个例子吗？

去年，我们对软件开发流程的心理方面产生了兴趣。 随着 IDE 的发展，人们很少好奇功能为什么会以特定方式添加进来。 结果，IDE 的各种功能变得相当超载。 没人研究过这究竟有多方便 – 人们只是习以为常，即使它其实并不理想。

环境对代码本身有显著影响吗？

一种已知的效应是，从白板和黑色记号笔换到黑板和白色记号笔后，人们就不会再犯之前常犯的错误。 我们想看看不同的环境因素，特别是 UI 复杂性，如何影响人们编写代码的方式。

我们有两种有些相互矛盾的假设。 第一种假设是，UI 越复杂，人们感受到的压力就越大，因为他们需要集中注意力寻找正确的按钮。 而另一种假设是，UI 越复杂，完成工作的速度就越快，因为你可以使用更多工具。

注意力集中时间较短的人可能会由于缺乏元素而分心， 因为屏幕上吸引他们注意力并让他们“忙碌”的东西更少。

我们研究了两种类型的任务：一种是需要大量思考的复杂任务，另一种是不需要太多思考即可轻松执行但需要高度集中的日常任务。 我们比较了人们如何在两种 UI 中完成这些任务：一种是功能丰富的常规界面，另一种是没有按钮或面板的 Zen 模式。

这是可以衡量的吗？

可以。从我们收集的数据来看，人们往往在简洁的 UI 中效率更高。 这可能非常有益，因为人们可以更有效地使用现有工具。

JetBrains 有心理学家团队吗？

我们有一个心理学家团队参与 UI/UX 和特定的认知心理学研究（他们是更大的 市场研究团队 的子团队）。 但是，我们的方式不同。 我们更多地依赖定量研究，给人们提供一个工具，看看他们如何使用，然后计算相关性和统计显著性。 UI/UX 和认知研究团队倾向于定性研究，询问人们更喜欢什么（做更多访谈、日记和定期 UX 研究）。 研究方法之间不会相互抵消，而结合起来可以得出一些非常有趣的结果。 我们以前曾有过合作，现在看来以后还会有更多合作。

自 2016 年实验室成立以来，你们的任务发生了哪些变化？

我们明白，机器学习在软件工程任务中的新兴应用对 JetBrains 至关重要。 可以说，我们不想被困在过去，在电脑发明出来后还造打字机。 这个想法没有改变：如果有一天（或者说到了那一天），点一下按钮就可以用神经网络编写代码，不再需要开发者，那么创造软件开发产品的公司将以必要的知识和手段来利用这一技术突破。

你个人也认为软件开发将会自动化到不再需要开发者的程度吗？

网上有这样一个梗：有人发明了汇编器？ 很快就没有开发者什么事了。 有人发明了第四代编程语言？ 很快就没有开发者什么事了。 UML 都有了？ 你懂的。 毕竟，人类还能做什么呢？ 他们的主要目标不是按下按钮，而是正确设计系统，考虑所有边缘和角落情况，研究系统运作以及与用户交互的所有场景。 也就是说，就算你有一个黑箱，你可以把想法“扔”进去，让它吐出代码 – 但这仍然需要有人提出想法。

这个概念是不是很像 UML？

没错！ 这个想法的初始支持者说得很好：“我们不再编写代码 – 我们设计它，然后实现它。” UML 开发者表示他们的可视化模型可以做到第一部分。 但“不编写代码”的想法到达了那些一生都在编写代码、热爱这份工作并想如此继续下去的人那里。 当然，他们并不乐意接受。

有别的办法吗？

The Structure of Scientific Revolutions 《科学革命的结构》一书中指出，事物之间从来不是前一个结束后一个才开始，其中总有重叠。 一波上升，另一波回落。 在后一个完全形成之前，第一个仍然有意义。 如果 UML 技术在大学第一年教授，人们被教导不需要编写代码，因为工具可以为你处理一切，那么，五年内就会有一代开发者完全相信“只有老一辈才会写代码”。 行业也会发生变化，因为这一代人将习惯新的方式。 所以你不能说：“好，你不用再写代码了！” 至少，仍然会有喜欢写代码并且擅长写代码的开发者。

这是唯一的问题吗？

程序员的角色不仅仅是写代码，因为编码本身是一项相对简单的任务。 他们的工作是确保代码有效、高效地工作，并整合整个项目的范围，其中可能包含数百万行代码。 具有挑战性的部分是记住整个项目的背景并理解为什么许多细节是以特定方式实现。 也许在未来，我们能提供具有上亿行代码的神经模型，并在请求添加小功能时不会破坏任何东西。 但现在，即使是人类也很难做到这一点。

你们实验室最有趣的成果是什么？

我们参与过的最有趣的项目之一是与 Kotlin 编译器团队的合作。 测试编译器时，他们使用以自己的语言编写的代码段，检查代码的效率和有效性。 在所有可用且可理解的代码选项都已经检查完毕后， 他们让我们找出真人以较为少见的方式编写的代码。

他们想把这段奇怪的代码放入编译器，看看它是否会崩溃，以及在代码以一种无法解释的方式编写的极端情况下，每个编译器阶段的工作是否正确。 虽然这个过程感觉像是白费力气，但我们确实找到了这样的代码段。 我们甚至与 Kotlin 开发团队分享了一些发现，展示了人们用自己的语言编写的创造性方式。

你们在日常任务中发现过什么有趣的事吗？

我们正在进行的一个项目涉及挖掘代码中的典型变化，从学术和实践的角度来看，我都觉得这很有趣。 我们一直在与许多 Python 项目合作，使用智能图挖掘技术来识别可以自动化的常见修正，让开发者不必手动更改。 我们有很多有趣的发现。 我们发现了提高代码效率的库版本迁移、语言版本迁移以及样式编辑相关的信息。 我们甚至在 GitHub 上与作者分享了一些修正，直接询问他们是否认为在工具中自动化这些更改是实用的。 超过一半的人表示对这个想法感兴趣。 我们已经实现了一些修正，其他修正则针对特定项目。

为什么这很酷？

我们的旗舰产品 IntelliJ IDEA 有超过 2,000 项检查。 它们会分析代码并提出改进方法。 每项检查都由开发者根据自己的经验编写而成。 我们不是从最上面，而是从最下面开始，关注真人在代码中所做的更改。 我们能够发现它们是因为人们经常进行这些更改。 我相信这种自动化很重要，因为它允许工具的开发不仅基于编程大量算法（2,000 项检查中的每一项都是由某人发明、编写和调试的），而且还可以依赖于一系列开放数据。

公司内部所有机器学习相关任务都由你们负责吗？

不，JetBrains 还有其他团队更专注于产品开发和端到端实现不同功能。 他们负责研究、实现功能、将其引入产品、监控其采用情况，以及进行 A/B 测试等。 不过，他们不太可能承担高风险和非常规项目。 我们的团队专门处理难懂和不寻常的任务。 我们负责寻找具备创新和实用潜力的想法。 虽然有些团队会向我们提出具体任务，但这些项目相对较少。

选择项目时是否有“绝对可以”的标准？

可以说，我们试图同时涉足应用和学术“阵营”，但并没有一个明确的清单。 当然，我们希望打造出可以立即使用的有用的东西。 另一方面，我们也明白，这样无法取得了不起的成就，因为你会陷入日常任务的泥潭。

涉及到应用项目时，产品的性质及其受众可以极大地影响我们的方向。 拥有既定受众的成熟产品，如 PyCharm 或 IntelliJ IDEA，可能没有太多激进创新的空间，而新兴项目往往没有时间留给我们。

另一方面，研究项目往往依赖于外部合作和积累的专业知识。 重点通常是撰写论文、在会议上发言、与他人分享经验、寻找志同道合的合作者等。 这样的项目通常涉及探索新的模型或方式，例如开发一种新方式将更改嵌入代码，然后在其他地方实现。

应用想法与学术想法的比例是多少？

考虑到我们积压工作的规模，这很难确定，但我认为我们的应用想法和学术想法之间是均等分配的。 现在我们有大约 50 个潜在项目，但并非所有项目都有直接用途或拥有合适的人员。 对我来说重要的是，团队中的每个成员都在做自己热爱的事，而不仅仅是我希望他们做的事。 所以，我有责任找到对我希望他们从事的工作抱有热情的人。 例如，在一些采访中，受访者会谈到我们以前从未探索过的某个领域。 通过让新人接手，我们得以打入这个领域。 无论积压工作有多深，我们都能收获一些价值。

概念达到原型阶段的比例是多少？原型转变为功能的频率如何？

我们的大多数概念都能进入原型阶段，因为功能不佳的原型仍然是原型。 我们只有几个项目没有取得后续进展。

但是，并非所有原型最终都会成为我们付费产品中的功能。 人们为什么使用 GitHub Copilot？ 它可能不会一直生成有意义的建议，但当它生成时，人们会很高兴。

这样你就有了“哇”的效果。 或者，就是让工具非常可靠。

从原型到功能的转化率要低得多，大约为 10%。 把工具交给团队后，我们就认为它是成功的。它将踏上自己的旅程，就像其他功能一样，可能会也可能不会进入产品。 失败的原因有很多。 举一个我们研究过的例子，我们在 EAP 程序 中向用户推出了一个功能，但随后我们遇到从 UI 角度实现的挑战。 在找到解决方案之前，它一直被搁置。

公司如何评估你们的绩效？

以指标为基础的方式违背 JetBrains Research 的文化。 我们的 KPI 很少，当然也没有全公司范围的标准。 我们没有具体的目标，像是今年计划的一定数量的专题或论文。

你认为对像你们这样的团队不设定 KPI 是正确的吗？

是的！ DARPA 就是一个很好的例子，这个组织创造了互联网。 他们的方式是聚集聪明的人才，不加限制，让他们自由创造。 互联网和许多有趣的东西都是这样被创造出来的。 JetBrains 也采用这种方式。 我们雇用富有激情的人才，给他们很大自由。 如何扩展到成千上万人就是另一回事了，但就研发而言，这是很好的做法。

采用指标会有什么问题？

有了指标，增长就成了衡量标准。 如果你的目标是发表十篇论文，你就会发表十篇论文。 问题是，如果你没有足够的成果来写十篇高质量论文怎么办？ 你可能仍然会发表十篇，只是有几篇就不会那么好。 在我们的研发团队中，我们对团队的有用性有一个共同的主观理解，可以通过多种途径得到支持。 通过逐步建立声誉，我们已经有机会自行寻找我们认为正确的事。 同时，公司偶尔会提出人们可能有兴趣探索的新领域，我们会倾听相关意见并与不同的团队展开合作。

你们的规划期限是多长？ 你知道今年你们要做什么吗？

我知道我们今年要做的事情。 我可以谈论的一个领域是图神经网络和 Transformer 的其他实用替代方案，这些被低估的方案可以在我们的任务中得到更有效地利用。 至于明年，我已经有一个粗略的想法，但我们这个行业很难计划得太远，因为一切都变化得太快了。 例如，强大的语言模型正愈发普及。 显然，我们必须对此做出回应。 主要价值不是来自工具本身，而是来自它的集成。 没人说因为有调试器就不再需要 IDE 了，对吧？ 调试器实际上已经无缝集成到开发流程中。 同样，语言模型需要集成到开发流程中，供应商必须能够处理这项复杂的任务。

大型语言模型的出现有没有迫使你们调整路线？

完全不会。 对于由人编写的代码，自动重构怎么样？ 这项任务仍然与语言模型的出现相关。

我们可以给 ChatGPT 一段代码，询问如何改进。 有趣的是，ChatGPT 确实提供了很好的推荐。 不过，如果在下一步中要求它执行相同的建议，在大多数情况下，生成的代码都将无法运行。 更新颖的任务处理方式可能是这样：我们询问语言模型，“帮我把这段代码变得更好。”

实验室的人员结构是怎样的？

在我们的团队中，研究员与工程师之间的界限非常微妙。 研究员专注于收集数据以及训练和测试模型。 他们的任务是构想出新工具。 而工程师是采用现有模型并尝试实现。 他们为 IDE 和其他产品构建插件。 研究员的任务是阅读和撰写白皮书、思考和训练模型。 工程师花费更多时间编程和研究如何将想法集成到工具中。

对他们的要求有什么差异？

对于工程师，我们期望的是高质量和可预测的编程，以及对算法和数据结构的理解。 因此，他们的面试与其他团队和项目的面试类似。

由于必要的背景和对数学的良好理解，研究员的数量远少于工程师。 我们理想的候选研究员需要拥有代码分析领域工作经验，只可惜，这样的人很少。 我们更常收到来自相关领域的申请，比如自然语言处理或计算机视觉。

你们的团队只有科学家吗？还是也有来自商界和业界的专家？

机器学习的实践经验不容易转化为研究经验。 我们处于产业和学术之间的中间地带。 那些在银行之类商业活动中广泛应用机器学习的人有不同的经验和目标。 他们主要关注解决具体问题和改进特定指标，而我们的团队需要了解模型的运作方式并使其适应我们的任务。 不是每个人都有这样的经验。 我们面试了很多人，但招聘的并不多。

你们的转化率是多少？

在上一个招聘周期中，我们收到了大约 200 份申请。 最后我们面试了 40 人，只聘用了 2 人。 这是一份艰巨的工作，需要一系列特殊技能，并非每个人都具备。

软技能重要吗？

重要的是能适应我们自由、扁平的结构，但这就并不适合每个人。 我们需要有责任心和自律的人，他们不需要细微的管理，并且能主动与其他团队成员沟通。 这非常重要。 我相信软件工程是以人而不是计算机为本。 毕竟，代码是由人编写、为人编写的。 比方说，团队主管在某种意义上讲应该是心理学家和社会学家，才能建立团队，并让这个团队成为一个统一的整体。 商业软件开发是把不同领域的专家聚集在一起，发挥出更有效的协同作用。 这需要一种结构化的理解方式，而且，对于团队组织或招聘决策来说，没有什么公式是万能的。

除了硬技能之外，你在招聘时还看重什么？

我发现一个有趣的关联：只要一个人在任何领域拥有博士学位，我们就很可能有话题可聊。

博士学位可以代表很多东西。 他们很可能更独立，能够深入思考，并且就同一主题撰写过多篇论文，即使这个主题与我们的领域没有直接关系。 我们已经聘请了来自其他领域的人员，比如弦理论或激光领域。 这给我们带来了多样性和宝贵的外部想法。 这在研发中很重要，因为我们的惯性思维，有些想法是我自己或者其他团队成员可能永远也想不到的。 如果他们具备我们需要的技术技能，教学经验也是一个加分项。 博士学位不是严格要求，因为两个方向都有例外。 有些人加入的团队有着非常善于设立目标的主管。 另外，如果一个人没有博士学位，也不是说他就不能独立思考或者学习新事物。

需要什么样的培训？

在研发中，你需要扎实地掌握统计学、概率论和线性代数，这是现代神经模型的基础。 我们领域的研发细节使学习曲线更加陡峭。 你需要了解软件开发的具体流程。 但没有什么是不可能的。 实习生在我们这里可以取得进一步发展，所以我非常清楚成为一名独立研究员的道路。 这需要很长时间，需要努力和纪律，但终究可以实现。

最后，你认为好奇心是可以训练的吗？

我相信这是天生的。 一个人要么想理解事物运作的方式，要么干脆不想。 我很难想象一个研究员被迫保持好奇。 有些人可能擅长按部就班地完成任务，但只有拥有好奇心的人才能创造出新的事物。

本博文英文原作者：

好奇心驱动的研究员：产学之间，第三部分

欢迎来到我们对 JetBrains 软件工程机器学习方法研究实验室负责人 Timofey Bryksin 的采访的第三部分。 这次我们将谈论基础与应用研究前沿、行业竞争以及最新的 AI 趋势。 第二部分位于此处。 Timofey Bryksin，JetBrains 软件工程机器学习方法研究实验室负责人 像你们这样的实验室和专注于纯科学的研究小组有什么区别？ 差异相当大，主要在于我们如何看待工作成果。 我们从实际的角度出发，思考我们的工作能否应用于现实世界。 学术研究的主要目标通常是产生新知识和推动某个领域的发展。  只要有详细记录并且可以重现，现有知识的任何改进都是值得发表的好结果。 有时，虽…

好奇心驱动的研究员：产学之间，第二部分

这是对 JetBrains 软件工程机器学习方法研究实验室负责人 Timofey Bryksin 的采访的第二部分，他在这部分中分享了对 IDE 的未来、LLM 工具以及开发者角色变化的看法。 可以在此处参阅第一部分。 Timofey Bryksin，JetBrains 软件工程机器学习方法研究实验室负责人 你们实验室的最新出版物关注的是自然语言文本编辑器可以从 IDE 学到什么， 能举一个例子吗？ 这篇文章更多的是对行业的呼吁，而不是报告结果。 我们在文本编辑方面有很多经验，所以我们知道处理文本的具体细节。 软件开发中涉及的认知负荷非常大，因为编程不仅仅是打字，更是组织思想。 IDE 非…