Mejora de las mutaciones de mejora genética mediante modelos de lenguaje grandes

Descripción general del contenido

• Abstracto
• Introducción
• Configuración experimental
• Resultados
• conclusiones y trabajo futuro
• Referencias

Abstracto

Los modelos de lenguaje grande (LLM) se han aplicado con éxito a tareas de ingeniería de software, incluida la reparación de programas. Sin embargo, su aplicación en técnicas basadas en búsquedas como la mejora genética (IG) aún está en gran medida inexplorada. En este artículo, evaluamos el uso de LLM como operadores de mutación para GI para mejorar el proceso de búsqueda. Ampliamos el kit de herramientas Gin Java GI para llamar a la API de OpenAI para generar ediciones para la herramienta JCodec. Tomamos muestras aleatoriamente del espacio de ediciones utilizando 5 tipos de edición diferentes. Descubrimos que la cantidad de parches que pasan las pruebas unitarias es hasta un 75% mayor con las ediciones basadas en LLM que con las ediciones de inserción estándar. Además, observamos que los parches que se encuentran en los LLM son generalmente menos diversos en comparación con las ediciones estándar. Ejecutamos GI con búsqueda local para encontrar mejoras en el tiempo de ejecución. Aunque GI mejorado con LLM encuentra muchos parches mejorados, el GI estándar encontró el mejor parche mejorado.

Introducción

A medida que los sistemas de software crecen y se vuelven más complejos, se requiere un esfuerzo manual significativo para mantenerlos [2]. Para reducir el esfuerzo de los desarrolladores en las tareas de optimización y mantenimiento del software, los paradigmas automatizados son esenciales. La mejora genética (GI) [15] aplica técnicas basadas en búsqueda para mejorar las propiedades no funcionales del software existente, como el tiempo de ejecución, así como propiedades funcionales como la reparación de errores. Aunque IG ha tenido éxito en la industria [12,13], sigue estando limitada por el conjunto de operadores de mutación que emplea en la búsqueda [14].

Los modelos de lenguaje grande (LLM) tienen una amplia gama de aplicaciones, ya que pueden procesar consultas textuales sin capacitación adicional para la tarea particular en cuestión. Los LLM han sido capacitados previamente en millones de repositorios de código que abarcan muchos lenguajes de programación diferentes [5]. Su uso para tareas de ingeniería de software ha tenido gran éxito [9,6], y se muestra prometedor también para la reparación de programas [17,19].

Kang y Yoo [10] han sugerido que existe un potencial sin explotar en el uso de LLM para mejorar el IG. GI utiliza los mismos operadores de mutación para diferentes tareas de optimización. Estos operadores se elaboran manualmente antes de iniciar la búsqueda y, por tanto, dan como resultado un espacio de búsqueda limitado. Nuestra hipótesis es que aumentar las sugerencias de parches LLM como un operador de mutación adicional enriquecerá el espacio de búsqueda y dará como resultado variantes más exitosas.

En este artículo, llevamos a cabo varios experimentos para explorar si el uso de LLM como operador de mutación en GI puede mejorar la eficiencia y eficacia de la búsqueda. Nuestros resultados muestran que los parches generados por LLM tienen tasas de compilación del 51,32 % y 53,54 % para búsqueda aleatoria y búsqueda local, respectivamente (con la categoría de aviso Medio). Anteriormente, se demostró que los LLM (que utilizaban un modelo LLM tal cual) producían código que se compilaba aproximadamente el 40% del tiempo [16,18]. Descubrimos que las ediciones basadas en LLM muestreadas aleatoriamente se compilaron y aprobaron pruebas unitarias con más frecuencia en comparación con las ediciones GI estándar. Observamos que la cantidad de parches que pasan las pruebas unitarias es hasta un 75% mayor para las ediciones basadas en LLM que para las ediciones de GI Insert. Sin embargo, observamos que los parches encontrados con LLM son menos diversos. Para la búsqueda local, la mejor mejora se logra utilizando ediciones estándar de la Declaración IG, seguidas de ediciones basadas en LLM. Estos hallazgos demuestran el potencial de los LLM como operadores de mutaciones y resaltan la necesidad de realizar más investigaciones en esta área.

Configuración experimental

Para analizar el uso de LLM como operador de mutación en GI, utilizamos el modelo GPT 3.5 Turbo de OpenAI y la caja de herramientas GI Gin [3]. Experimentamos con dos tipos de búsqueda implementadas dentro de Gin: búsqueda aleatoria y búsqueda local. Las solicitudes al LLM utilizando la API OpenAI se realizaron a través de la biblioteca Langchain4J, con una temperatura de 0,7. El proyecto objetivo de mejora en nuestros experimentos fue el popular proyecto JCodec [7], que está escrito en Java. Los métodos "calientes" a los que se dirigirán las ediciones se identificaron utilizando la herramienta de creación de perfiles de Gin repitiendo la creación de perfiles 20 veces y tomando la unión del conjunto resultante.

Para los experimentos de muestreo aleatorio, configuramos las ejecuciones con ediciones a nivel de declaración (copiar/eliminar/reemplazar/intercambiar desde [14] e insertar pausa/continuar/regresar desde [4]) y ediciones LLM, generando 1000 de cada tipo al azar. . Se utilizó un tiempo de espera de 10000 milisegundos para cada prueba unitaria para detectar bucles infinitos introducidos por las ediciones; exceder el tiempo de espera cuenta como una falla de la prueba. Para la búsqueda local, los experimentos se realizaron de manera similar. Hubo 10 ejecuciones repetidas (una para cada uno de los 10 métodos más populares), pero las ejecuciones se limitaron a 100 evaluaciones, lo que dio como resultado 1000 evaluaciones en total, coincidiendo con la búsqueda aleatoria. En la práctica, esto fue 99 ediciones por ejecución, ya que la primera se usó para cronometrar el código original sin parches.

Experimentamos con tres mensajes diferentes para enviar solicitudes al LLM para ambos tipos de búsqueda: un mensaje simple, un mensaje medio y un mensaje detallado. Con las tres indicaciones, nuestra implementación solicita cinco variaciones diferentes del código en cuestión. El mensaje simple solo solicita el código sin ninguna información adicional. El mensaje medio proporciona más información sobre el código proporcionado y los requisitos, como se muestra en la Figura 1. Específicamente, proporcionamos al LLM el lenguaje de programación utilizado, el proyecto al que pertenece el código, así como instrucciones de formato. El mensaje detallado amplía el mensaje medio con un ejemplo de un cambio útil. Este ejemplo fue tomado de los resultados obtenidos por Brownlee et al. [4]. El parche es una instancia exitosa de la edición de inserción aplicada al proyecto jCodec (es decir, una edición que compiló, pasó las pruebas unitarias y ofreció una aceleración sobre el código original). Usamos el mismo ejemplo para todas las solicitudes detalladas utilizadas en nuestros experimentos; Esto se debe a que los LLM son capaces de realizar un razonamiento inductivo en el que el usuario presenta información específica, y el LLM puede usar esa entrada para generar declaraciones más generales, mejoradas aún más en GPT-4 [8].

Las ediciones de LLM se aplican seleccionando una declaración de bloque al azar en un método de destino "caliente". El contenido de este bloque está in the prompt. The first code block in the LLM response is identified. Gin uses JavaParser (https://javaparser.org) internally to represent target source files, so we attempt to parse the LLM suggestion with JavaParser, and replace the original block with the LLM suggestion.

Resultados

El primer experimento compara mutaciones GI estándar, es decir, ediciones de inserción y declaración, con ediciones de LLM que utilizan indicaciones detalladas de manera diferente (simple, media y detallada) mediante muestreo aleatorio. La Tabla 1 muestra los resultados de todos los parches y solo de los parches únicos. Informamos cuántos parches fueron analizados exitosamente por JavaParser (denominados Válido), cuántos compilados y cuántos pasaron todas las pruebas unitarias (denominados Aprobado). Excluimos parches sintácticamente equivalentes al software original. Los mejores resultados están en negrita .

Vemos que aunque se encontraron sustancialmente más parches válidos con las ediciones estándar Insertar y Declaración, se pudieron encontrar más parches aprobados utilizando las ediciones generadas por LLM. En particular, para los mensajes Medio y Detallado, 292 y 230 parches pasaron las pruebas unitarias, respectivamente. Para las ediciones Insert y Statement, solo 166 y 91 pasaron las pruebas unitarias, respectivamente. Como anécdota, los métodos calientes con tasas de aprobación de parches más bajas y más altas diferían para cada operador: comprender esta variación será interesante para investigaciones futuras.

También es notable que los parches LLM son menos diversos: los operadores de mutación estándar encontraron más de un 50% más de parches únicos que el LLM que usa Medium.

y Avisos detallados. Sin embargo, con el mensaje Simple, ni un solo parche pasó las pruebas unitarias, ya que las ediciones sugeridas a menudo no se podían analizar. Por lo tanto, se necesitan indicaciones detalladas para obligar a LLM a generar resultados utilizables.

Investigamos más a fondo las diferencias entre los mensajes Medio y Detallado para comprender la reducción en el rendimiento con Detallado (en los conjuntos de parches únicos), ya que Medio tenía una mayor cantidad de parches compilados y aprobados. En ambos niveles de solicitud, la respuesta generada fue la misma en 42 casos (del total de casos válidos únicos). Sin embargo, Detallado tendía a generar respuestas más largas con un promedio de 363 caracteres, mientras que Medio tenía un promedio de 304 caracteres. Examinamos manualmente varias respuestas rápidas detalladas, en las que identificamos algunas variables incluidas de otros archivos, lo que potencialmente ofrece una expansión significativa del conjunto de variantes de código que GI puede explorar.

El segundo experimento amplía nuestro análisis, comparando el rendimiento de las ediciones estándar y LLM con la búsqueda local. La Tabla 2 muestra los resultados del experimento de búsqueda local. Informamos la cantidad de parches compilados y pasados, así como la cantidad de parches en los que se encontraron mejoras en el tiempo de ejecución. Además, informamos la mediana y la mejor mejora en milisegundos (ms). En la tabla, excluimos todos los parches vacíos. Como antes, los mejores resultados están en negrita .

Nuevamente, vemos que se pueden encontrar más parches que pasen las pruebas unitarias con el LLM usando las indicaciones Medio y Detallado. Además, se podrían encontrar más mejoras utilizando el LLM con estas indicaciones. En concreto, con Medio y Detallado encontramos 164 y 196 mejoras respectivamente, mientras que solo encontramos 136 con Insertar y 71 con Declaración. La mejor mejora se pudo encontrar con 508 ms con la edición de Declaración. La mejor mejora encontrada al usar LLM (usando el mensaje Medio) solo fue capaz de mejorar el tiempo de ejecución en 395 ms. También examinamos una serie de ediciones en los resultados de la búsqueda local para obtener información sobre las distinciones entre mensajes medianos y detallados debido a la baja tasa de compilación de las respuestas de mensajes detallados. En el ejemplo, una secuencia de ediciones tenía como objetivo insertar una llamada a un clip de función. El mensaje detallado intentó incorporar la llamada casi de inmediato después de algunas ediciones, lo que probablemente generó un código no válido. Por otro lado, el mensaje de Medium realizó cambios menos radicales y perfeccionó gradualmente el código. Comenzó reemplazando la expresión del operador ternario con una declaración if-then-else y llamadas a funciones del sistema antes de intentar finalmente alinear la llamada a la función clip.

conclusiones y trabajo futuro

La mejora genética del software depende en gran medida de los operadores de mutación que utiliza en el proceso de búsqueda. Para diversificar los operadores y enriquecer aún más el espacio de búsqueda, incorporamos un modelo de lenguaje grande (LLM) como operador.

Limitaciones . En general, el trabajo futuro debería considerar proyectos además de nuestro objetivo, jCodec. Nuestros experimentos utilizaron una API que no nos da control sobre las respuestas generadas por el LLM ni sobre ninguna forma de modificarlas u optimizarlas. Aunque no observamos cambios en el comportamiento durante nuestros experimentos, OpenAI puede cambiar el modelo en cualquier momento, por lo que el trabajo futuro debería considerar modelos locales. Experimentamos con solo tres tipos de mensajes para solicitudes de LLM y dentro de este número limitado de mensajes encontramos una variación en los resultados. Finalmente, nuestra implementación para analizar las respuestas de los LLM fue relativamente simplista. Sin embargo, esto sólo significaría que nuestros resultados reportados son pesimistas y que el operador con sede en LLM podría lograr una mejora aún mayor.

Resumen . Descubrimos que, aunque se encontraron parches más válidos y diversos con ediciones estándar utilizando muestreo aleatorio, se encontraron más parches que pasaron las pruebas unitarias con ediciones basadas en LLM. Por ejemplo, con la edición LLM usando el mensaje Medio, encontramos más de un 75% más de parches que pasaron las pruebas unitarias que con la edición Insertar clásica. En nuestro experimento de búsqueda local, encontramos la mejor mejora con la edición de declaración (508 ms). La mejor mejora basada en LLM se encontró con el mensaje Medio (395 ms). Por lo tanto, existe potencial para explorar enfoques que combinen ediciones LLM y IG "clásicas".

Nuestros experimentos revelaron que las indicaciones utilizadas para las solicitudes de LLM afectan en gran medida los resultados. Por lo tanto, en trabajos futuros, esperamos experimentar más con ingeniería rápida. También podría resultar útil mezclar indicaciones: por ejemplo, comenzar con medio y luego cambiar a detallado para realizar ediciones más grandes que salgan de los mínimos locales. Además, la posibilidad de combinar ediciones LLM con otras como copiar/eliminar/reemplazar/intercambiar o plantillas PAR [11] estándar podría ser interesante. Finalmente, esperamos realizar una experimentación más extensa con programas de prueba adicionales.

Disponibilidad de datos. El código, la infraestructura experimental y de solicitud de LLM, los datos de la evaluación y los resultados están disponibles como código abierto en [1]. El código también se encuentra en la rama 'llm' de github.com/gintool/gin (confirmación 9fe9bdf; ramificada desde la confirmación maestra 2359f57 pendiente de integración completa con Gin).

Agradecimientos UKRI EPSRC EP/P023991/1 y ERC 741278.

Referencias

1. Artefacto para mejorar mutaciones de mejora genética utilizando modelos de lenguaje grandes. Zenodo (septiembre de 2023). https://doi.org/10.5281/zenodo.8304433

   
   

2. B¨hme, M., Soremekun, EO, Chattopadhyay, S., Ugherughe, E., Zeller, A.: ¿Dónde está el error y cómo se soluciona? Un experimento con practicantes. En: Proc. Simposio ACM sobre los fundamentos de la ingeniería de software. págs. 117-128 (2017)

   
   

3. Brownlee, AE, Petke, J., Alexander, B., Barr, ET, Wagner, M., White, DR: Ginebra: la investigación sobre mejora genética es fácil. En: GECCO. págs. 985–993 (2019)

   
   

4. Brownlee, AE, Petke, J., Rasburn, AF: Inyectar atajos para ejecutar código Java más rápido. En: IEEE CEC 2020. p. 1–8

   
   

5. Chen, M., Tworek, J., Jun, H., Yuan, Q., Pinto, HPdO, Kaplan, J., Edwards, H., Burda, Y., Joseph, N., Brockman, G., et al. al.: Evaluación de grandes modelos de lenguaje entrenados en código. Preimpresión de arXiv arXiv:2107.03374 (2021)

   
   

6. Fan, A., Gokkaya, B., Harman, M., Lyubarskiy, M., Sengupta, S., Yoo, S., Zhang, JM: Grandes modelos de lenguaje para ingeniería de software: encuesta y problemas abiertos (2023)

7. Github - jcodec/jcodec: repositorio principal de Jcodec, https://github.com/jcodec/jcodec

   
   

8. Han, SJ, Ransom, KJ, Perfors, A., Kemp, C.: Razonamiento inductivo en humanos y grandes modelos de lenguaje. Investigación de sistemas cognitivos p. 101155 (2023)

   
   

9. Hou, X., Liu, Y., Yang, Z., Grundy, J., Zhao, Y., Li, L., Wang, K., Luo, X., Lo, D., Wang, H.: Grandes modelos de lenguaje para la ingeniería de software: una revisión sistemática de la literatura. arXiv:2308.10620 (2023)

   
   

10. Kang, S., Yoo, S.: Hacia una mejora genética adaptada a objetivos a través de grandes modelos de lenguaje. arXiv:2304.09386 (2023)

    
    

11. Kim, D., Nam, J., Song, J., Kim, S.: Generación automática de parches aprendida de parches escritos por humanos (2013), http://logging.apache.org/log4j/

    
    

12. Kirbas, S., Windels, E., Mcbello, O., Kells, K., Pagano, M., Szalanski, R., Nowack, V., Winter, E., Counsell, S., Bowes, D., Hall, T., Haraldsson, S., Woodward, J.: Sobre la introducción de la reparación automática de programas en Bloomberg. Software IEEE 38(4), 43–51 (2021)

    
    

13. Marginean, A., Bader, J., Chandra, S., Harman, M., Jia, Y., Mao, K., Mols, A., Scott, A.: Sapfix: reparación automatizada de extremo a extremo en escala. En: CISE-SEIP. págs. 269-278 (2019)

    
    

14. Petke, J., Alexander, B., Barr, ET, Brownlee, AE, Wagner, M., White, DR: Paisajes de transformación de programas para la modificación automatizada de programas utilizando Gin. Ingeniería de software empírica 28 (4), 1–41 (2023)

    
    

15. Petke, J., Haraldsson, SO, Harman, M., Langdon, WB, White, DR, Woodward, JR: Mejora genética del software: un estudio exhaustivo. Transacciones IEEE sobre computación evolutiva 22, 415–432 (2018)

    
    

16. Siddiq, ML, Santos, J., Tanvir, RH, Ulfat, N., Rifat, FA, Lopes, VC: Exploración de la eficacia de modelos de lenguaje grandes en la generación de pruebas unitarias. Preimpresión de arXiv arXiv:2305.00418 (2023)

    
    

17. Sobania, D., Briesch, M., Hanna, C., Petke, J.: Un análisis del rendimiento de corrección automática de errores de chatgpt. En: Taller internacional IEEE/ACM de 2023 sobre reparación automatizada de programas (APR). págs. 23–30. Sociedad de Computación IEEE (2023)

    
    

18. Xia, CS, Paltenghi, M., Tian, JL, Pradel, M., Zhang, L.: Fuzzing universal mediante modelos de lenguaje grandes. Preimpresión de arXiv arXiv:2308.04748 (2023)

    
    

19. Xia, CS, Zhang, L.: Continúe la conversación: solucionando 162 de 337 errores por $0,42 cada uno usando chatgpt. Preimpresión de arXiv arXiv:2304.00385 (2023)