Эксклюзивное интервью с JetBrainer | Исследователь, движимый любопытством: между промышленностью и научными кругами, часть 2

От данных к применению больших моделей: 25 ноября в Ханчжоу прошла конференция Yuanchuang, на которой были обменяны советами по разработке.

представлять

‍Это вторая часть интервью с Тимофеем Брыксиным, руководителем исследовательской лаборатории методов машинного обучения JetBrains Software Engineering , в котором он делится своими ‍мыслями о будущем IDE, инструментах LLM и меняющейся роли разработчиков. Первую часть можно найти здесь .

Тимофей Брыксин

Руководитель лаборатории исследований методов машинного обучения JetBrains в области разработки программного обеспечения

вопрос

Последняя публикация вашей лаборатории посвящена тому, чему текстовые редакторы на естественном языке могут научиться из IDE. Можете ли вы привести пример?

Эта статья – скорее призыв к промышленности, чем отчет о результатах. У нас большой опыт редактирования текста, поэтому мы знаем тонкости работы с текстом. Когнитивная нагрузка, связанная с разработкой программного обеспечения, очень высока, поскольку программирование — это не только набор текста, но и организация мыслей. IDE очень хорошо справляются с уменьшением этой когнитивной нагрузки с помощью таких функций, как подсветка синтаксиса или использование соглашений о форматировании, которые позволяют согласованно форматировать код других людей. IDE понимают основную структуру текста, предоставляя информацию о связях, которые в противном случае можно было бы упустить из виду. Идея состоит в том, что эти накопленные знания могут быть полезны вне кода, в других типах текстовых редакторов. На естественном языке вы можете мгновенно идентифицировать и выделять структуры или создавать сводки. Точный метод остается открытым вопросом, но мы считаем, что он заслуживает дальнейшего рассмотрения. Существует реальный прогресс в исследованиях когнитивной нагрузки, связанной с задачами на естественном языке, и аналогичные стратегии, которые мы видим в способах обработки кода в IDE, являются полезными, например, подсветка синтаксиса, соглашения об именах и контекстно-зависимые функции.

Мы опубликовали несколько небольших статей в этой области и считаем, что это направление заслуживает дальнейшего изучения. Очевидно, что теперь нам необходимо переосмыслить инструменты разработчика и то, как они используются, особенно в случае больших языковых моделей. Например, GitHub Copilot X демонстрирует функцию чата, с помощью которой вы можете попросить IDE найти ошибки в вашем коде. В будущем также может быть добавлен голосовой интерфейс.

вопрос

Будут ли будущие IDE поддерживать голосовое управление?

Два года назад мне сделали операцию, и на все лето я потерял возможность пользоваться рукой. Печатать одной рукой утомительно, поэтому я установил несколько инструментов преобразования речи в текст. Таким образом, я могу общаться в Slack или просто печатать голосом. Эти инструменты могут более или менее помочь в работе и достаточно удобны.

Но как только моя рука зажила, я сразу же вернулся к набору текста обеими руками и вообще перестал пользоваться голосовым помощником. Потому что ввод текста и пунктуация кажутся более быстрыми и привычными. Помните, когда впервые появились умные колонки и голосовые помощники? Говорят, что они будут общаться с людьми и станут их лучшими помощниками. Сегодня большинство этих устройств используются только для того, чтобы сообщать погоду и устанавливать будильники. Тем не менее, голосовой ввод имеет некоторый потенциал для IDE, поскольку определенные команды можно доставлять помощнику с помощью голоса. «Найди здесь ошибку», «Рефакторинг», «Извлечь это в отдельную функцию» — эти команды очень похожи на естественный язык. В настоящее время люди, как правило, привыкли отправлять голосовые сообщения, и для некоторых этот метод связи даже является предпочтительным. Возможно, у следующего поколения разработчиков появятся свои идеи, и через несколько поколений даже клавиатура может устареть.

вопрос

Что еще мы знаем об IDE будущего?

Я считаю, что с появлением этих новых помощников и языковых моделей мы полностью переоценим свою работу. Если роль разработчика начнет смещаться от простого написания кода к более сложным задачам высокого уровня, таким как проектирование, определение требований, разработка компонентов и построение системы, это заставит нас заново изобрести наши инструменты.

вопрос

Как большие языковые модели повлияют на индустрию разработки программного обеспечения?

Обобщение типичного опыта полезно для повседневных задач, но не может генерировать новые знания. Таким образом, LLM с меньшей вероятностью повлияет на задачи, которые обычно требуют интеллектуальных усилий, и с большей вероятностью будет использоваться для рутинных механических задач, которые будут (и должны) быть автоматизированы . Тем не менее, написание целевой страницы для зоомагазина определенно будет делегировано модели GPT. Однако такие задачи, как создание интеллектуальных систем и разработка новых алгоритмов, по-прежнему требуют инновационного мышления, чего модели в настоящее время не могут сделать. Еще один важный практический вопрос – как структурировать рабочие процессы разработки с использованием инструментов LLM . JetBrains активно работает над будущими инструментами разработки и созданием прототипов и скоро начнет делиться прогрессом.

вопрос

Какие инструменты вы используете сами?

Мы не полагаемся на какие-то специальные решения, так как большинство наших проектов обычно заканчиваются прототипами, а для разработки достаточно обычных систем контроля версий и отладки.

Однако нам нужны специальные инструменты для обработки кода и различных фрагментов текста, сбора и анализа данных, а также создания наборов данных. Поэтому мы разработали собственную библиотеку . Например, до сих пор не решена проблема построения графов зависимостей программ для кода Python, а полнофункциональной библиотеки пока нет. В основном это связано со сложностью реализации такой статической функциональности для динамически типизированных языков. Итак, нам нужно сделать это самим.

Помимо сбора данных, мы уже несколько лет занимаемся разработкой открытой библиотеки KInference . Он решает задачу интеграции нейронных моделей, обычно обучаемых с использованием Python, с IDE, в частности, выполнения этих моделей в среде JVM (Java, Kotlin, Scala, это не имеет значения). Существует множество библиотек, которые служат этой цели, но ни одна из них не отвечает нашим требованиям к скорости, памяти и стабильности в кроссплатформенной среде. Итак, мы разработали собственную быструю и легкую библиотеку для выполнения вывода модели ONNX на чистом Kotlin . Его реализация очень эффективна, и наши разработчики работают над оптимизацией использования памяти и кэша ЦП, чтобы обеспечить быстрые вычисления. Это позволяет нам переносить сложные нейронные модели на любой язык, основанный на JVM, а это означает, что мы можем создавать плагины для наших IDE и другие вкусности. Например, некоторые модели платформы Grazie построены на этой библиотеке. Мы активно совершенствуем этот инструмент и расширяем его поддержку на другие нейронные операторы.

вопрос

Какую самую большую модель вы когда-либо обучали?

Самые крупные модели, которые мы обучали для исследовательских целей, имели примерно 200–300 миллионов параметров . Однако мы также фокусируемся на моделях, которые можно запускать локально на компьютере пользователя и использовать локальные данные. Этот подход конкретно устраняет проблемы конфиденциальности и GDPR, поскольку мы не отправляем никакие данные наружу, что дает нам большую свободу. Если данные необходимо отправить куда-то еще, конфиденциальность становится важной проблемой.

вопрос

Какие библиотеки вы используете для оптимизации производительности моделей в вашем продукте?

Дело не в библиотеке, а в подходе . Во время обучения мы стараемся применять все методы, предложенные сообществом: дистилляцию, уменьшение размера и т.д. После этого большая часть модели прогоняется на KInference, и эффективность выполнения очень высока. Это полезно как для ускорения, так и для сжатия модели.

вопрос

Почему скорость все еще имеет значение в 2023 году? Имеют ли еще смысл проблемы с ограниченной вычислительной мощностью?

Поскольку мы не говорим об очень больших моделях, то на сервере это уже не является большой проблемой. Однако это становится важным, если вы кладете ноутбук на колени и излучаемое им тепло может нагреть всю комнату. Инструменты разработчика могут быть очень ресурсоемкими, особенно при работе с большими базами кода. Возьмем, к примеру, более продвинутые функции IDE, такие как рефакторинг, которые часто требуют индексации всего проекта. Для модели, интегрированной в IDE, идеальное время отклика должно находиться в диапазоне десятков миллисекунд, а использование памяти должно быть как можно меньшим — всего несколько мегабайт. Конечно, можно внедрить и более ресурсоемкую модель, но причина должна быть веская, например, если цель — добиться функциональности, которая действительно «удивит» пользователей. Короче говоря, всегда нужно учитывать потребление ресурсов.

вопрос

Как вы выбираете между скоростью, точностью и полнотой?

涉及 IDE 内 AI 助手（例如，在有效项目中查找 bug 并在代码编辑器中建议修正的工具）时，我们通常倾向于准确性。需要两秒才能工作的准确率达 99.9% 的模型通常比立即运行但准确率仅为 95% 的模型更受青睐。这是因为，后者有二十分之一的概率提供不正确的建议，进而造成困扰。我们希望确保的是，这种辅助不会让开发者感到烦恼以至于他们宁愿冒险不使用。避免误报至关重要，否则开发者将不得不浪费时间来解决这些问题并弄清楚它们确实是误报，而这必然会带来负面情绪。

速度和准确性之间的权衡有时可以通过辅助性工程调整或预计算来解决。此外，问题不必实时解决：分析编写的代码时，开发者稍晚一点获得建议是可以接受的。这些建议不必立即显示。

当然，在某些情况下，检出每一个潜在问题非常重要。那么，开发者是否花费额外的时间来处理误报也就不那么重要了。举例来说，搜索安全漏洞时，这种情况经常发生。不过，这样的任务在我们的项目中并不常见。

开发新功能时还需要考虑什么？

务必考虑助手如何集成到开发者的工作流中。我认为社区对这些问题的关注还不够。人们经常会提出新的方式和工具，但重点是了解这些工具如何适应典型开发者的工作。你每天都会听到这样的话：“我尝试了这个功能，它显示了三次奇怪的东西，然后我就把它关掉了。”

这种情况下，什么方式才是正确的？

大多数工具需要用户采取相当大的主动性。他们必须记住工具首先是可用的（许多开发者往往会忘记），有意识地努力运行，然后查看最终产生的结果。在我看来，这些工具应该更加主动。但有一个问题：如果工具不断向用户提出建议，它就会扰乱用户的工作流。那么，问题是如何确保助手能够识别干预的时机。建议应该在开发者对上下文仍然记忆犹新的特定时间提出，但也不应该干扰开发者正在进行的任务。这些是 JetBrains 正在探索的重要问题。

你对你们用于数据科学的编程语言满意吗？

完美的语言没有统一的定义，这完全取决于个人喜好和当前任务。人们倾向于使用具有适当工具的语言。Python 就是这样：它因强大的工具而广受欢迎。简易性也增加了它的吸引力。你不需要像 C++ 那样花很长时间去学习，也不需要了解内存的运作方式。当然，理解这些东西很重要，但 Python 可以让你以相对简单的学习曲线开始。我们使用 Python 进行模型训练，但我们也可以选择不同的路径，使用 Kotlin。

因此，拥有一种适合每个人并被普遍采用的语言似乎不太现实 – 除非神经网络以某种方式发明了自己的语言并开始用它编写代码。但那就完全是另一回事了。

你观察人们编写代码已经有一段时间了，这些年来软件开发发生了怎样的变化？

主要趋势是任务自动化工具的发展。

在企业开发中，人们倾向于使用复杂的解决方案，其中系统基础架构处理大量复杂逻辑。这样的系统难以开发，也难以理解。大约在 2000 年代中期，随着敏捷方式的兴起，人们的心态发生了转变，开始摆脱这些试图同时完成一切的单一结构。开发者开始倾向于将逻辑嵌入编写的代码中，而不是仅仅依赖于工具和库。

同时，可以解决特定小任务而不是整个问题的工具的数量也有所增加。人们正在尝试将这些工具结合起来。有些用于开发，有些用于部署、测试、分析和版本控制等。

另一个显著的转变是认识到人类参与的重要性。好在我们已经摆脱了依赖强大工具和需要极少人际互动的庞大官僚流程。现在很明显，系统是由人类创建的，工具需要人性化，优先考虑人们的便利，即使是以牺牲可预测性为代价。

你能提供一些提高数据质量的建议吗？

数据质量是人们刚刚开始认识到的一个主要问题。“垃圾进，垃圾出”的原则众所周知。不过，良好的基准和可靠的数据集相当稀缺，特别是在我们相对年轻的领域。研究论文的作者通常必须创建自己的数据集。但在某些情况下，其他研究人员在论文发表后检查这些数据集，发现它们的质量并不高。作为我们领域多个顶级会议和期刊的审稿人，我经常注意到这方面没有得到足够的重视。许多论文被拒正是因为研究人员在数据收集阶段没有抓住要点，导致无论他们后来做了什么都无关紧要。

自我监控如何帮助提高数据质量？

首先，必须检查显式和隐式重复。当模型遇到大量相同代码时，它往往会认为这就是应该的样子。为此，我们经常使用克隆检测工具，而不仅仅是筛选掉 GitHub 复刻。

其次，对于许多任务来说，时间线是数据集非常重要的一部分。因为数据有时会从训练集溜进测试集，即使模型事先不应该看到它。因此，密切关注时间顺序至关重要，确保训练数据先于测试集。

第三，您需要采用更广阔的视角，仔细检查特定于任务的任何偏见，寻找可能影响模型与现实场景之间联系的任何因素。例如，在最近的一个项目中，我们为提交消息中的自动补全编译了一个数据集。有一些数据集可用于此目的，但最广泛使用的数据集之一只保留了最初的 100 个字符，并排除了不以动词开头的消息。因此，此数据集中的所有消息均以动词开头，并遵循非常典型的结构。于是，任何其他类型的消息都会让这个模型感到意外。

另一个例子：来自 GitHub 的代码。虽然它对于研究目的来说肯定很有价值，但人们还是倾向于开源项目。谁说大公司内部的代码编写方式反映了 GitHub 上的情况？公司有其独特的方法、数据结构和库。此外，在 GitHub 目前托管的仓库中，有许多并不能很好地代表行业的普遍代码编写方式，其中包含家庭作业、教程、不维护的项目等内容。因此，通常看起来有很多代码，但仔细查看后，可能并没有看起来那么丰富。