Evaluación de los LLM para generación de código

Después de varios días, ya se ha conseguido tener un prototipo funcional que permite generar código usando la API de OpenAI aplicando distintas metodologías. Concretamente, como el primer prototipo tiene como objetivo evaluar la calidad y precisión del código generado, este se ha automatizado para que sea capaz de leer la documentación javadoc de un proyecto ya existente e intente generar el código a partir de la firma de la clase, los constructores y los métodos junto a su descripción. Toda esta información es tratada y se envía a la API de OpenAI como si de texto natural se tratara, intentando simular la interacción que podría tener un usuario cualquiera con el LLM.

Antes, pero, como se comentó en la actualización anterior, es muy importante especificar el rol que tiene que adoptar el LLM. Además, especificando que es un generador de código y que siempre debe devolver el código generado dentro de etiquetas XML, se puede controlar la respuesta de una manera mucho más sencilla. Asimismo, también es posible especificar si debe seguir ciertos patrones antes de devolver la respuesta. Ahí justamente es donde entra en juego la posibilidad de aplicar diferentes metodologías y ver la calidad del código con cada una.

• La primera generación de código que se evaluará es a partir de lenguaje natural obtenido de la documentación javadoc sin aplicar ningún comportamiento específico más allá del rol que debe asumir el LLM.
• La segunda, será a partir del mismo texto, pero especificando que debe validar el código generado a partir de una colección de tests que se proporcionarán. Como el proyecto utilizado ya tiene esa colección de tests, se proporcionará el documento Java que los contiene.
• La tercera generación de código también tendrá que validar el código que haya generado, pero se especificará que los tests los debe crear por sí mismo en función de la entrada que haya recibido. Es decir, si en la entrada se pide que debe crear una clase que represente una lista enlazada, deberá crear los tests necesarios para validar el código generado.

Una vez generado el código, será importante evaluarlos uno a uno para poder comparar el código generado con el original. No obstante, durante la realización de las pruebas ya se han encontrado algunos problemas que se citarán a continuación.

• Algunas clases implementan ciertas interficies o heredan otras clases. Como el LLM no dispone de esta información, el código que genera incluye partes de las clases padre y dista considerablemente del código original. Por lo tanto, el primer problema que parece evidente es la falta de contexto a la hora de generar código. Como solución a ello, se modificará el prototipo para que se proporcione dicho contexto de forma recursiva hasta llegar a la clase Object. Asimismo, con el objetivo de acortar la cantidad de tokens a enviar, solo se pasará el contenido completo de la clase padre directa. Para las demás clases que no sean padre directo de la clase que se quiere generar, solo se proporcionarán sus atributos y sus métodos. No obstante, habrá que ver si esto es posible a corto plazo, ya que existe una limitación de tokens a la hora enviar texto a la API.
• Algunas veces el código generado no contiene algunas partes importantes. En ciertas ocasiones, la respuesta que proporciona no contiene la declaración de los atributos. Para dar solución a este problema se ha modificado el texto que recibe inicialmente y se le ha especificado que debe generar los atributos necesarios para que el código funcione correctamente. Además, ha habido algunas situaciones en las que el código generado solo contenía la firma de los métodos con un comentario dentro, sin proporcionar el cuerpo. Este problema no es muy habitual y, por ahora, no se ha dado solución a ello. Se está a la espera de que vuelva a pasar con el contexto modificado.
• La disponibilidad de la API de OpenAI, a pesar de tener una cuenta plus no siempre es la deseada. Por ello, muchas veces el prototipo no es capaz de generar el código, ya que la API no es capaz de proporcionar esta respuesta. Dicho problema está fuera del alcance de esta investigación porque se está trabajando con la API de un tercero, así que por ahora no se puede dar solución a ello.
• Los recientes anuncios del Parlamento Europeo y el Gobierno Español ponen en riesgo la investigación y, en general, el uso de la API de GPT. De hecho, el Gobierno Italiano ya adoptó medidas y ha bloqueado en su totalidad el uso de ChatGPT y, en consecuencia, la API de GPT que usa el prototipo utilizado. A pesar de que el Parlamento Europeo ha dado un plazo de dos meses para resolver la disputa, en caso de que decidan cerrar el servicio en la Unión Europea, la investigación seguirá utilizando servidores de Estados Unidos o de otro país donde no esté bloqueado el servicio.

Con todo el código generado, es momento de analizar si con las metodologías aplicadas el código generado es lo suficientemente correcto, si el tiempo de espera es aceptable o si es necesario cambiar de estrategia y aplicar otras técnicas. En cualquier caso, una vez analizado, ya se tiene previsto hacer ciertas modificaciones y aplicar técnicas como las que se describirán a continuación.

• Generar el código creando una cadena conversacional con el LLM.
• Proporcionar ejemplos de código como el que debe generar.
• Modificar la temperature para evaluar su comportamiento.
• Validación del código compilándolo con un compilador real y que no sea el mismo LLM que deba validarlo.

Se ha finalizado la primera versión del prototipo que permite generar código a partir de lenguaje natural con ChatGPT utilizando la biblioteca langchain. Después del desarrollo de este, se han observado ciertos aspectos muy interesantes a destacar.

• Es posible especificar cómo debe devolver el texto generado y, en consecuencia, el código. Gracias a esto, se ha creado el prototipo orientado al lenguaje XML, donde exista una etiqueta code con el código generado y, después, varias etiquetas con los tests que se hayan generado con su resultado. De esta manera, es mucho más simple tratar los datos por el prototipo.
• Es muy importante indicarle qué tipo de rol debe asumir el LLM. Es decir, para nuestro caso, el LLM debe comportarse como un generador de código y validador de este mediante los tests. Si se le especifica claramente, la respuesta que da se acerca mucho más a la esperada y se evita texto innecesario que suele crear ChatGPT (innecesario para este caso, no que no sirva para ninguna situación).
• Hay que tener mucho cuidado con la limitación de caracteres en la respuesta de ChatGPT, ya que corta el código cuando llega al límite y no lo completa debidamente. Se debe dar solución a este problema para poder generar varias funciones a la vez o clases completas.

Hasta ahora se ha creado para ChatGPT debido a que se quieren iniciar las pruebas cuando antes mejor por el riesgo de un posible cierre temporal. Ya existe un precedente, en Italia, y puede poner en riesgo toda la investigación.

Después de hacer un estudio del estado del arte de los LLM y, concretamente, de los que se pretende estudiar, se ha concluido que el prototipo se va a desarrollar con Python debido a su velocidad, porqué tiene una comunidad muy amplia enfocada a usar el lenguaje con este tipo de modelos y por el tener compatibilidad con la biblioteca langchain, que permite enviar peticiones a las API de estos LLM de una manera muy simple.

Si finalmente el estudio lo permite, se va a crear una extensión para Visual Studio Code, pero como esta tiene que estar hecha en JavaScript y el prototipo estará creado en Python, se creará una API del prototipo para poder mandar y recibir mensajes actuando como si de una caja negra se tratara.

Finalmente, debido al abrupto cierre de la API de Codex, se utilizará la API de davinci.