好奇心驱动的研究员：产学之间，第二部分
这是对 JetBrains 软件工程机器学习方法研究实验室负责人 Timofey Bryksin 的采访的第二部分，他在这部分中分享了对 IDE 的未来、LLM 工具以及开发者角色变化的看法。 可以在此处参阅第一部分。
你们实验室的最新出版物关注的是自然语言文本编辑器可以从 IDE 学到什么， 能举一个例子吗？
这篇文章更多的是对行业的呼吁，而不是报告结果。 我们在文本编辑方面有很多经验，所以我们知道处理文本的具体细节。 软件开发中涉及的认知负荷非常大，因为编程不仅仅是打字，更是组织思想。 IDE 非常擅长通过语法高亮显示，或使用允许统一格式化其他人代码的格式约定等功能减少这种认知负荷。 IDE 理解文本的底层结构，提供对可能被忽略的联系的洞察。 我们的想法是，这种积累的知识可能会在代码之外、其他类型的文本编辑器中发挥作用。 在自然语言中，您可以即时识别和高亮显示结构或生成总结。 具体方法仍然是一个开放式问题，但我们认为这值得进一步思考。 自然语言任务相关认知负荷的研究取得了切实进展，我们在 IDE 处理代码的方式中看到的类似策略也很有用，例如语法高亮显示、命名约定和基于上下文的功能。
我们已经在这个领域发表了一些小文章，也相信这个方向值得进一步探索。 特别是对于大语言模型，很明显，我们现在需要重新考虑开发者工具及其使用方式。 例如，GitHub Copilot X 演示了一个聊天功能，在这个功能中您可以要求 IDE 查找代码中的错误。 未来还可能会添加语音界面。
未来的 IDE 会支持语音控制吗？
两年前，我做了手术，整个夏天都无法使用手臂。 只用一只手打字很累人，所以我安装了一些语音转文本工具。 这样我就可以在 Slack 中聊天，也可以只使用语音打字。 这些工具或多或少都能协助工作，而且相当方便。
但手臂痊愈后，我就立刻回归双手打字，彻底不再使用语音助手。 因为打字和敲标点感觉就是更快、更熟悉。 记得智能音箱和语音助手刚问世的时候吗？ 都说它们将与人类沟通对话，成为人类的终极助手。 现在呢，这些设备大多只是用来报告天气和设置闹钟。 不过，对于 IDE，语音输入还是具有一定潜力的，因为某些命令可以通过声音传递给助手。 “在这里查找错误”、“重构”、“把它提取到一个单独的函数中” – 这些命令与自然语言非常相似。 如今，人们普遍习惯发送语音消息， 这种通信方式甚至是部分人的首选。 也许下一代开发者会有自己的想法，几代人之后，可能连键盘都会过时。
关于未来的 IDE，我们还知道些什么？
我相信，考虑到这些新的助手和语言模型，我们将彻底重新评估我们的工作方式。 如果开发者的角色开始从单纯的编码转向更复杂的高级任务，例如设计、需求概述、组件开发和系统构建，这就会促使我们改造工具。
大语言模型将如何影响软件开发行业？
从典型经验泛化很适合日常任务，但不能产生新的知识。 因此，LLM 不太可能影响通常需要智力劳动的任务， 而更有可能用于将要（也应该）自动化的日常机械性任务。 也就是说，为宠物店编写着陆页肯定会委托给 GPT 模型。 然而，创建智能系统和开发新算法这样的任务仍然需要创新思维，这是模型目前无法做到的。 另一个重大的实际问题是如何围绕 LLM 工具构建开发工作流。 JetBrains 正在积极研讨未来的开发工具和创建原型，很快就可以开始分享进展。
你们自己都使用什么工具？
我们不依赖任何特殊解决方案，因为我们的大多数项目通常都以原型结束，普通的版本控制和调试系统也能够满足开发。
不过，我们确实需要专属工具来处理代码和不同的文本片段，收集和分析数据，以及创建数据集。 因此，我们开发了自己的库。 例如，为 Python 代码构建程序依赖关系图的问题还没有解决，也还没有功能齐全的库。 这主要是由于为动态类型语言实现此类静态功能的复杂性。 所以，我们需要自己完成。
除了数据收集，我们多年来一直在开发开源库 KInference。 它解决了将通常使用 Python 训练的神经模型与 IDE 集成的挑战，特别是在 JVM 环境（Java、Kotlin、Scala，无所谓）中执行这些模型。 有多种库可以满足这一目的，但没有一个符合我们在跨平台环境中对速度、内存和稳定性的要求。 所以，我们开发了自己的快速轻量型库，在纯 Kotlin 中执行 ONNX 模型推断。 它的实现非常高效，我们的开发者正在深入研究内存和 CPU 缓存使用优化，确保快速计算。 这使我们能够将复杂的神经模型引入任何基于 JVM 的语言，意味着我们可以为我们的 IDE 和其他好东西创建插件。 例如，Grazie 平台中的一些模型就是以这个库为基础构建的。 我们正在积极增强这个工具，也在将其支持扩展到其他神经算子。
你们训练过的最大的模型是什么？
我们为研究目的训练的最大模型大约有 2-3 亿个参数。 不过，我们也关注可以在用户计算机上本地运行和使用本地数据的模型。 这种方式特别消除了隐私和 GDPR 担忧，因为我们不向外部发送任何数据，这给了我们很大自由。 如果需要将数据发送到其他地方，隐私就会成为一个重要问题。
你们使用什么库来优化产品中模型的性能？
重点不是库，而是方式。 训练期间，我们尝试应用社区提出的所有技术：蒸馏、大小缩减等。 之后，很大一部分模型在 KInference 上运行，执行效率非常高。 这对于加速和压缩模型都很有帮助。
为什么速度在 2023 年仍然重要？ 计算能力有限的问题仍然有意义吗？
只要我们不是在谈论超大型模型，那么在服务器上，这就不再是一个大问题。 不过，如果将笔记本电脑放在腿上，它散发的热量能给整个房间供暖，这就变得很重要了。 开发者工具可能非常消耗资源，特别是在处理大型代码库时。 以重构等更高级的 IDE 功能为例，它们通常需要对整个项目编制索引。 对于集成到 IDE 中的模型，理想的响应时间应该在几十毫秒范围内，并且其内存使用量应该尽可能小 – 只有几兆字节。 当然，您可以引入更耗资源的模型，但理由必须充分，例如，如果目标是实现真正让用户“惊叹”的功能。 总之，你始终需要考虑到资源消耗。
你们如何在速度、准确性和完整性之间做出选择？
涉及 IDE 内 AI 助手（例如，在有效项目中查找 bug 并在代码编辑器中建议修正的工具）时，我们通常倾向于准确性。 需要两秒才能工作的准确率达 99.9% 的模型通常比立即运行但准确率仅为 95% 的模型更受青睐。 这是因为，后者有二十分之一的概率提供不正确的建议，进而造成困扰。 我们希望确保的是，这种辅助不会让开发者感到烦恼以至于他们宁愿冒险不使用。 避免误报至关重要，否则开发者将不得不浪费时间来解决这些问题并弄清楚它们确实是误报，而这必然会带来负面情绪。
速度和准确性之间的权衡有时可以通过辅助性工程调整或预计算来解决。 此外，问题不必实时解决：分析编写的代码时，开发者稍晚一点获得建议是可以接受的。 这些建议不必立即显示。
当然，在某些情况下，检出每一个潜在问题非常重要。 那么，开发者是否花费额外的时间来处理误报也就不那么重要了。 举例来说，搜索安全漏洞时，这种情况经常发生。 不过，这样的任务在我们的项目中并不常见。
开发新功能时还需要考虑什么？
务必考虑助手如何集成到开发者的工作流中。 我认为社区对这些问题的关注还不够。 人们经常会提出新的方式和工具，但重点是了解这些工具如何适应典型开发者的工作。 你每天都会听到这样的话：“我尝试了这个功能，它显示了三次奇怪的东西，然后我就把它关掉了。”
这种情况下，什么方式才是正确的？
大多数工具需要用户采取相当大的主动性。 他们必须记住工具首先是可用的（许多开发者往往会忘记），有意识地努力运行，然后查看最终产生的结果。 在我看来，这些工具应该更加主动。 但有一个问题：如果工具不断向用户提出建议，它就会扰乱用户的工作流。 那么，问题是如何确保助手能够识别干预的时机。 建议应该在开发者对上下文仍然记忆犹新的特定时间提出，但也不应该干扰开发者正在进行的任务。 这些是 JetBrains 正在探索的重要问题。
你对你们用于数据科学的编程语言满意吗？
完美的语言没有统一的定义，这完全取决于个人喜好和当前任务。 人们倾向于使用具有适当工具的语言。 Python 就是这样：它因强大的工具而广受欢迎。 简易性也增加了它的吸引力。 你不需要像 C++ 那样花很长时间去学习，也不需要了解内存的运作方式。 当然，理解这些东西很重要，但 Python 可以让你以相对简单的学习曲线开始。 我们使用 Python 进行模型训练，但我们也可以选择不同的路径，使用 Kotlin。
因此，拥有一种适合每个人并被普遍采用的语言似乎不太现实 – 除非神经网络以某种方式发明了自己的语言并开始用它编写代码。 但那就完全是另一回事了。
你观察人们编写代码已经有一段时间了， 这些年来软件开发发生了怎样的变化？
主要趋势是任务自动化工具的发展。
在企业开发中，人们倾向于使用复杂的解决方案，其中系统基础架构处理大量复杂逻辑。 这样的系统难以开发，也难以理解。 大约在 2000 年代中期，随着敏捷方式的兴起，人们的心态发生了转变，开始摆脱这些试图同时完成一切的单一结构。 开发者开始倾向于将逻辑嵌入编写的代码中，而不是仅仅依赖于工具和库。
同时，可以解决特定小任务而不是整个问题的工具的数量也有所增加。 人们正在尝试将这些工具结合起来。 有些用于开发，有些用于部署、测试、分析和版本控制等。
另一个显著的转变是认识到人类参与的重要性。 好在我们已经摆脱了依赖强大工具和需要极少人际互动的庞大官僚流程。 现在很明显，系统是由人类创建的，工具需要人性化，优先考虑人们的便利，即使是以牺牲可预测性为代价。
你能提供一些提高数据质量的建议吗？
数据质量是人们刚刚开始认识到的一个主要问题。 “垃圾进，垃圾出”的原则众所周知。 不过，良好的基准和可靠的数据集相当稀缺，特别是在我们相对年轻的领域。 研究论文的作者通常必须创建自己的数据集。 但在某些情况下，其他研究人员在论文发表后检查这些数据集，发现它们的质量并不高。 作为我们领域多个顶级会议和期刊的审稿人，我经常注意到这方面没有得到足够的重视。 许多论文被拒正是因为研究人员在数据收集阶段没有抓住要点，导致无论他们后来做了什么都无关紧要。
自我监控如何帮助提高数据质量？
首先，必须检查显式和隐式重复。 当模型遇到大量相同代码时，它往往会认为这就是应该的样子。 为此，我们经常使用克隆检测工具，而不仅仅是筛选掉 GitHub 复刻。
其次，对于许多任务来说，时间线是数据集非常重要的一部分。 因为数据有时会从训练集溜进测试集，即使模型事先不应该看到它。 因此，密切关注时间顺序至关重要，确保训练数据先于测试集。
第三，您需要采用更广阔的视角，仔细检查特定于任务的任何偏见，寻找可能影响模型与现实场景之间联系的任何因素。 例如，在最近的一个项目中，我们为提交消息中的自动补全编译了一个数据集。 有一些数据集可用于此目的，但最广泛使用的数据集之一只保留了最初的 100 个字符，并排除了不以动词开头的消息。 因此，此数据集中的所有消息均以动词开头，并遵循非常典型的结构。 于是，任何其他类型的消息都会让这个模型感到意外。
另一个例子：来自 GitHub 的代码。 虽然它对于研究目的来说肯定很有价值，但人们还是倾向于开源项目。 谁说大公司内部的代码编写方式反映了 GitHub 上的情况？ 公司有其独特的方法、数据结构和库。 此外，在 GitHub 目前托管的仓库中，有许多并不能很好地代表行业的普遍代码编写方式，其中包含家庭作业、教程、不维护的项目等内容。 因此，通常看起来有很多代码，但仔细查看后，可能并没有看起来那么丰富。
____
至此，我们将结束对 Timofey Bryskin 的系列采访。 请关注本系列的总结，我们将讨论学术研究与工业研究之间的差异，以及是什么造就了有趣的研究成果。 我们的第一次采访中涵盖了 ML4SE 实验室所做的工作、选择和评估项目的方式以及招聘研究员时需要考虑的重要事项。 Timofey，感谢分享。
本博文英文原作者：
