introducir
Esta es la segunda parte de una entrevista con Timofey Bryksin, director del Laboratorio de Investigación de Métodos de Aprendizaje Automático de Ingeniería de Software de JetBrains , en la que comparte sus pensamientos sobre el futuro de los IDE, las herramientas LLM y el papel cambiante de los desarrolladores. La primera parte se puede encontrar aquí .
Timofey Bryksin
Jefe del Laboratorio de Investigación de Métodos de Aprendizaje Automático de Ingeniería de Software de JetBrains
q
La última publicación de su laboratorio se centra en lo que los editores de texto en lenguaje natural pueden aprender de los IDE. ¿Puede darnos un ejemplo?
Este artículo es más un llamado a la industria que un informe de resultados. Tenemos mucha experiencia en edición de texto, por lo que conocemos los aspectos prácticos del trabajo con texto. La carga cognitiva involucrada en el desarrollo de software es muy alta porque la programación no se trata solo de escribir sino también de organizar pensamientos. Los IDE son muy buenos para reducir esta carga cognitiva mediante funciones como el resaltado de sintaxis o el uso de convenciones de formato que permiten un formato consistente del código de otras personas. Los IDE comprenden la estructura subyacente del texto y brindan información sobre las conexiones que de otro modo podrían pasarse por alto. La idea es que este conocimiento acumulado pueda resultar útil fuera del código, en otro tipo de editores de texto. En lenguaje natural, puedes identificar y resaltar estructuras instantáneamente o generar resúmenes. El método exacto sigue siendo una cuestión abierta, pero creemos que merece una reflexión más profunda. Hay un progreso real en la investigación sobre la carga cognitiva asociada con las tareas de lenguaje natural, y estrategias similares que vemos en la forma en que los IDE manejan el código son útiles, como el resaltado de sintaxis, las convenciones de nomenclatura y las características basadas en el contexto.
Hemos publicado algunos artículos pequeños en esta área y creemos que esta dirección merece una mayor exploración. Especialmente para los modelos de lenguaje grandes, está claro que ahora necesitamos repensar las herramientas de desarrollo y cómo se utilizan. Por ejemplo, GitHub Copilot X muestra una función de chat donde puedes pedirle al IDE que encuentre errores en tu código. Es posible que en el futuro también se agregue una interfaz de voz.
q
¿Los futuros IDE admitirán el control por voz?
Hace dos años me operaron y perdí el uso de mi brazo durante todo el verano. Escribir con una sola mano es agotador, así que instalé algunas herramientas de conversión de voz a texto. De esta manera puedo chatear en Slack o simplemente escribir usando mi voz. Estas herramientas pueden ayudar más o menos en el trabajo y son bastante convenientes.
Pero tan pronto como mi brazo sanó, inmediatamente volví a escribir con ambas manos y dejé de usar el asistente de voz por completo. Porque escribir y puntuar resulta más rápido y familiar. ¿Recuerdas cuando aparecieron por primera vez los parlantes inteligentes y los asistentes de voz? Se dice que se comunicarán con los humanos y se convertirán en sus asistentes finales. Hoy en día, la mayoría de estos dispositivos sólo se utilizan para informar sobre el tiempo y configurar alarmas. Aún así, la entrada de voz tiene cierto potencial para los IDE, ya que ciertos comandos pueden entregarse al asistente mediante voz. "Encuentre el error aquí", "Refactorice", "Extraiga esto en una función separada": estos comandos son muy similares al lenguaje natural. Hoy en día, la gente está generalmente acostumbrada a enviar mensajes de voz y este método de comunicación es incluso la primera opción para algunas personas. Quizás la próxima generación de desarrolladores tenga sus propias ideas y, en unas pocas generaciones, incluso el teclado puede volverse obsoleto.
q
¿Qué más sabemos sobre el IDE del futuro?
Creo que con estos nuevos asistentes y modelos de lenguaje reevaluaremos completamente nuestra forma de trabajar. Si el rol del desarrollador comienza a pasar de simplemente codificar a tareas más complejas y de alto nivel, como diseño, descripción de requisitos, desarrollo de componentes y construcción de sistemas, esto nos obligará a reinventar nuestras herramientas.
q
¿Cómo afectarán los grandes modelos lingüísticos a la industria del desarrollo de software?
La generalización a partir de la experiencia típica es buena para las tareas cotidianas, pero no puede generar nuevos conocimientos. Por lo tanto, es menos probable que LLM afecte a tareas que normalmente requieren esfuerzo intelectual y es más probable que se utilice para tareas mecánicas rutinarias que serán (y deberían) automatizarse . Dicho esto, escribir una página de destino para una tienda de mascotas definitivamente se delegaría al modelo GPT. Sin embargo, tareas como la creación de sistemas inteligentes y el desarrollo de nuevos algoritmos todavía requieren un pensamiento innovador, algo que los modelos no pueden hacer actualmente. Otra gran cuestión práctica es cómo estructurar los flujos de trabajo de desarrollo en torno a herramientas LLM . JetBrains está trabajando activamente en futuras herramientas de desarrollo y creando prototipos, y pronto comenzará a compartir el progreso.
q
¿Qué herramientas utilizas tú mismo?
No dependemos de ninguna solución especial, ya que la mayoría de nuestros proyectos normalmente terminan en prototipos, y los sistemas de control de versiones y depuración ordinarios serán suficientes para el desarrollo.
Sin embargo, necesitamos herramientas dedicadas para procesar el código y diferentes fragmentos de texto, recopilar y analizar datos y crear conjuntos de datos. Por lo tanto, desarrollamos nuestra propia biblioteca . Por ejemplo, el problema de crear gráficos de dependencia de programas para código Python aún no se ha resuelto y aún no existe una biblioteca completamente funcional. Esto se debe principalmente a la complejidad de implementar dicha funcionalidad estática para lenguajes escritos dinámicamente. Entonces, tenemos que hacerlo nosotros mismos.
Además de la recopilación de datos, llevamos varios años desarrollando la biblioteca de código abierto KInference . Resuelve el desafío de integrar modelos neuronales típicamente entrenados usando Python con un IDE, específicamente ejecutando estos modelos en un entorno JVM (Java, Kotlin, Scala, no importa). Existen varias bibliotecas que sirven para este propósito, pero ninguna cumple con nuestros requisitos de velocidad, memoria y estabilidad en un entorno multiplataforma. Entonces, desarrollamos nuestra propia biblioteca rápida y liviana para realizar la inferencia del modelo ONNX en Kotlin puro . Su implementación es muy eficiente y nuestros desarrolladores están profundizando en la optimización del uso de la memoria caché y la CPU para garantizar cálculos rápidos. Esto nos permite incorporar modelos neuronales complejos a cualquier lenguaje basado en JVM, lo que significa que podemos crear complementos para nuestros IDE y otras ventajas. Por ejemplo, algunos modelos de la plataforma Grazie se basan en esta biblioteca. Estamos mejorando activamente esta herramienta y ampliando su soporte a otros operadores neuronales.
q
¿Cuál es el modelo más grande que jamás hayas entrenado?
Los modelos más grandes que entrenamos con fines de investigación tenían aproximadamente entre 200 y 300 millones de parámetros . Sin embargo, también nos centramos en modelos que se pueden ejecutar localmente en la computadora del usuario y utilizar datos locales. Este enfoque elimina específicamente las preocupaciones sobre la privacidad y el RGPD porque no enviamos ningún dato externamente, lo que nos da mucha libertad. Si es necesario enviar datos a otra parte, la privacidad se convierte en una cuestión importante.
q
¿Qué bibliotecas utiliza para optimizar el rendimiento de los modelos en su producto?
La cuestión no es la biblioteca, sino el enfoque . Durante la formación intentamos aplicar todas las técnicas propuestas por la comunidad: destilación, reducción de tamaño, etc. Después de eso, una gran parte del modelo se ejecuta en KInference y la eficiencia de ejecución es muy alta. Esto es útil tanto para acelerar como para comprimir el modelo.
q
¿Por qué la velocidad seguirá siendo importante en 2023? ¿Siguen teniendo sentido los problemas con una potencia informática limitada?
Mientras no estemos hablando de modelos muy grandes, en el servidor esto ya no es un gran problema. Sin embargo, esto se vuelve importante si colocas tu computadora portátil en tu regazo y el calor que emite puede calentar toda la habitación. Las herramientas de desarrollo pueden consumir muchos recursos, especialmente cuando se trabaja con bases de código grandes. Tomemos, por ejemplo, funciones IDE más avanzadas, como la refactorización, que a menudo requieren la indexación de todo el proyecto. Para un modelo integrado en un IDE, el tiempo de respuesta ideal debería estar en el rango de decenas de milisegundos y su uso de memoria debería ser lo más pequeño posible: sólo unos pocos megabytes. Por supuesto, puede introducir un modelo que consuma más recursos, pero la razón debe ser buena, por ejemplo, si el objetivo es lograr una funcionalidad que realmente "sorprenda" a los usuarios. En resumen, siempre hay que tener en cuenta el consumo de recursos.
q
¿Cómo se elige entre velocidad, precisión e integridad?
涉及 IDE 内 AI 助手（例如，在有效项目中查找 bug 并在代码编辑器中建议修正的工具）时，我们通常倾向于准确性。需要两秒才能工作的准确率达 99.9% 的模型通常比立即运行但准确率仅为 95% 的模型更受青睐。这是因为，后者有二十分之一的概率提供不正确的建议，进而造成困扰。我们希望确保的是，这种辅助不会让开发者感到烦恼以至于他们宁愿冒险不使用。避免误报至关重要，否则开发者将不得不浪费时间来解决这些问题并弄清楚它们确实是误报，而这必然会带来负面情绪。
速度和准确性之间的权衡有时可以通过辅助性工程调整或预计算来解决。此外，问题不必实时解决：分析编写的代码时，开发者稍晚一点获得建议是可以接受的。这些建议不必立即显示。
当然，在某些情况下，检出每一个潜在问题非常重要。那么，开发者是否花费额外的时间来处理误报也就不那么重要了。举例来说，搜索安全漏洞时，这种情况经常发生。不过，这样的任务在我们的项目中并不常见。
Q
开发新功能时还需要考虑什么？
务必考虑助手如何集成到开发者的工作流中。我认为社区对这些问题的关注还不够。人们经常会提出新的方式和工具，但重点是了解这些工具如何适应典型开发者的工作。你每天都会听到这样的话：“我尝试了这个功能，它显示了三次奇怪的东西，然后我就把它关掉了。”
Q
这种情况下，什么方式才是正确的？
大多数工具需要用户采取相当大的主动性。他们必须记住工具首先是可用的（许多开发者往往会忘记），有意识地努力运行，然后查看最终产生的结果。在我看来，这些工具应该更加主动。但有一个问题：如果工具不断向用户提出建议，它就会扰乱用户的工作流。那么，问题是如何确保助手能够识别干预的时机。建议应该在开发者对上下文仍然记忆犹新的特定时间提出，但也不应该干扰开发者正在进行的任务。这些是 JetBrains 正在探索的重要问题。
Q
你对你们用于数据科学的编程语言满意吗？
完美的语言没有统一的定义，这完全取决于个人喜好和当前任务。人们倾向于使用具有适当工具的语言。Python 就是这样：它因强大的工具而广受欢迎。简易性也增加了它的吸引力。你不需要像 C++ 那样花很长时间去学习，也不需要了解内存的运作方式。当然，理解这些东西很重要，但 Python 可以让你以相对简单的学习曲线开始。我们使用 Python 进行模型训练，但我们也可以选择不同的路径，使用 Kotlin。
因此，拥有一种适合每个人并被普遍采用的语言似乎不太现实 – 除非神经网络以某种方式发明了自己的语言并开始用它编写代码。但那就完全是另一回事了。
Q
你观察人们编写代码已经有一段时间了， 这些年来软件开发发生了怎样的变化？
主要趋势是任务自动化工具的发展。
在企业开发中，人们倾向于使用复杂的解决方案，其中系统基础架构处理大量复杂逻辑。这样的系统难以开发，也难以理解。大约在 2000 年代中期，随着敏捷方式的兴起，人们的心态发生了转变，开始摆脱这些试图同时完成一切的单一结构。开发者开始倾向于将逻辑嵌入编写的代码中，而不是仅仅依赖于工具和库。
同时，可以解决特定小任务而不是整个问题的工具的数量也有所增加。人们正在尝试将这些工具结合起来。有些用于开发，有些用于部署、测试、分析和版本控制等。
另一个显著的转变是认识到人类参与的重要性。好在我们已经摆脱了依赖强大工具和需要极少人际互动的庞大官僚流程。现在很明显，系统是由人类创建的，工具需要人性化，优先考虑人们的便利，即使是以牺牲可预测性为代价。
Q
你能提供一些提高数据质量的建议吗？
数据质量是人们刚刚开始认识到的一个主要问题。“垃圾进，垃圾出”的原则众所周知。不过，良好的基准和可靠的数据集相当稀缺，特别是在我们相对年轻的领域。研究论文的作者通常必须创建自己的数据集。但在某些情况下，其他研究人员在论文发表后检查这些数据集，发现它们的质量并不高。作为我们领域多个顶级会议和期刊的审稿人，我经常注意到这方面没有得到足够的重视。许多论文被拒正是因为研究人员在数据收集阶段没有抓住要点，导致无论他们后来做了什么都无关紧要。
Q
自我监控如何帮助提高数据质量？
首先，必须检查显式和隐式重复。当模型遇到大量相同代码时，它往往会认为这就是应该的样子。为此，我们经常使用克隆检测工具，而不仅仅是筛选掉 GitHub 复刻。
其次，对于许多任务来说，时间线是数据集非常重要的一部分。因为数据有时会从训练集溜进测试集，即使模型事先不应该看到它。因此，密切关注时间顺序至关重要，确保训练数据先于测试集。
第三，您需要采用更广阔的视角，仔细检查特定于任务的任何偏见，寻找可能影响模型与现实场景之间联系的任何因素。例如，在最近的一个项目中，我们为提交消息中的自动补全编译了一个数据集。有一些数据集可用于此目的，但最广泛使用的数据集之一只保留了最初的 100 个字符，并排除了不以动词开头的消息。因此，此数据集中的所有消息均以动词开头，并遵循非常典型的结构。于是，任何其他类型的消息都会让这个模型感到意外。
另一个例子：来自 GitHub 的代码。 虽然它对于研究目的来说肯定很有价值，但人们还是倾向于开源项目。谁说大公司内部的代码编写方式反映了 GitHub 上的情况？公司有其独特的方法、数据结构和库。此外，在 GitHub 目前托管的仓库中，有许多并不能很好地代表行业的普遍代码编写方式，其中包含家庭作业、教程、不维护的项目等内容。因此，通常看起来有很多代码，但仔细查看后，可能并没有看起来那么丰富。
至此，我们将结束对 Timofey Bryskin 的系列采访。请关注本系列的总结，我们将讨论学术研究与工业研究之间的差异，以及是什么造就了有趣的研究成果。我们的第一次采访中涵盖了 ML4SE 实验室所做的工作、选择和评估项目的方式以及招聘研究员时需要考虑的重要事项。Timofey，感谢分享。
本博文英文原作者：Robert Demmer
更多阅读推荐
新发布
调研报告
IDE 使用技巧
⏬ 戳「阅读原文」了解更多
本文分享自微信公众号 - JetBrains（JetBrainsChina）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。