Migración de Bibliotecas de Componentes UI Impulsada por LLM

Hola a todos. Gracias por unirse a mi charla hoy. En la sesión de hoy, hablaré sobre cómo en Zalando utilizamos LLMs para impulsar la migración de bibliotecas de componentes en nuestra aplicación de una biblioteca de componentes a otra. Antes de comenzar, una breve introducción. Soy Nawal. Soy ingeniera principal en Zalando. Zalando, si no estás familiarizado, es una de las principales plataformas de moda en Europa, y colabora estrechamente con miles de marcas en todo el mundo.

Mi equipo es responsable de construir las plataformas, herramientas y bibliotecas de componentes que son utilizadas por otros equipos de ingeniería dentro de Zalando para construir sus propias aplicaciones B2B externas. Y estas aplicaciones externas son luego utilizadas por las marcas o nuestros socios para interactuar con Zalando y gestionar su negocio en Zalando. Como parte de la operación y mantenimiento de estas plataformas centrales, encontramos diferentes tipos de migraciones en nuestro trabajo diario.

Estas migraciones pueden variar desde simples actualizaciones de versión, por ejemplo, actualizar de React 18 a 19. Sin embargo, pueden ser migraciones más complejas como migrar de una biblioteca de componentes a otra o migrar de un marco de UI a otro o actualizar la temática de marca de nuestras aplicaciones. Una cosa fundamental sobre todas estas migraciones que llevamos a cabo es que no solo tenemos que realizar la migración para nuestras propias plataformas y herramientas centrales, sino que cuando planificamos la migración, tenemos que planificar para cada aplicación que se ejecuta en nuestra plataforma. Así que eso significa que para estas migraciones, tenemos que pensar cómo podemos automatizar a escala y llevar a cabo la migración de manera más eficiente. Ahora, hablando del problema de migración que encontramos recientemente, en Zalando para nuestras aplicaciones externas B2B, había dos bibliotecas de componentes diferentes que estaban siendo utilizadas. Estas bibliotecas de componentes tenían una estructura totalmente diferente.

Tenían diferentes interfaces, tenían diferentes componentes y tenían diferentes filosofías de diseño. Mantener dos bibliotecas de componentes diferentes era un poco costoso porque teníamos que duplicar nuestro esfuerzo, y también reducía la consistencia de las UIs para nuestros socios. Los socios verían diferentes UIs dependiendo de en qué aplicación estuvieran. Por lo tanto, queremos unificar en una sola biblioteca de componentes. Queríamos migrar todas las aplicaciones usando la biblioteca de componentes que ves en la parte superior.

Digamos que la biblioteca fuente a una biblioteca de componentes en la parte inferior, digamos biblioteca objetivo. Sin embargo, esta migración de la biblioteca de componentes fuente a la biblioteca de componentes objetivo fue un esfuerzo muy grande. Si hablamos en días de desarrollador, se esperaba que tomara más de un año completar y por lo tanto queríamos ver cómo podíamos automatizar esta migración y hacerla más rápida. Primero intentamos con code mods. Los code mods son como el enfoque tradicional para manejar este tipo de migración. Los code mods funcionan modificando directamente el árbol de sintaxis abstracta o AST por sus siglas en inglés.

Un simple AST para una declaración de importación puedes ver en el lado derecho. Como puedes ver, si quieres cambiar el nombre del paquete de old UI a digamos new UI, todo lo que tienes que hacer es encontrar dónde en el AST está el valor de old UI y luego convertirlo al nuevo valor y luego convertirlo de nuevo al código. Así que los code mods son realmente muy eficientes haciendo las transformaciones y son muy rápidos y deterministas y son una herramienta bastante buena para manejar muchas migraciones diferentes. Sin embargo, para nuestro caso de uso, lo que descubrimos fue que los code mods no eran una buena opción. Había algunas razones para esto.

La primera razón fue que había muchas variaciones en nuestra base de código y si teníamos que crear code mods para atender cada caso de uso, los code mods rápidamente se volvían muy engorrosos y desafiantes. Por ejemplo, si tomo el elemento de tipografía que es digamos el elemento más simple que tenemos e incluso en este elemento, había muchas variaciones diferentes y los equipos estaban usando diferentes prácticas. Por ejemplo, algunos equipos usaban el elemento directamente. Sin embargo, algunos equipos asignaban la tipografía a un valor más corto y luego lo usaban. Algunos equipos también usaban el objeto de encabezado y lo asignaban a una variable y luego lo usaban.

Algunos equipos no usaban el contenido como componente de texto, sino que lo usaban como una propiedad. Así que como puedes ver, había muchas variaciones diferentes y llegar a cada variación rápidamente se volvía muy desafiante. Otra limitación que notamos para los code mods fue que teníamos que hacer muchas migraciones complejas. Si miras la imagen en el lado derecho, puedes ver que cuando tenemos que migrar el componente select de la biblioteca fuente a la biblioteca objetivo, no solo tenemos que migrar el componente de datos sino también los datos en sí en ese componente. Por ejemplo, aquí las opciones de selección son una variable que es generada por una lógica de negocio de iterar sobre las opciones y eso significa que si tenemos que aplicar code mods, debemos tener cuidado de que la lógica de negocio permanezca intacta.

Además, hay otras variaciones que son posibles aquí. Por ejemplo, aquí es una variable pero puede ser una función nombrada, una función flecha y así sucesivamente. Así que como puedes ver, el desafío aquí era que había tantas variaciones y complejidades diferentes que los code mods eran un poco imprácticos y lo que queríamos era una herramienta que pudiera entender por sí misma la relación entre las diferentes partes del código y la lógica diferente que está sucediendo en el código y luego la combinamos con nuestras instrucciones y la herramienta puede hacer la migración. Así que un buen ajuste para eso fueron los LLMs y los LLMs o modelos de lenguaje grande era algo que ya estábamos usando para nuestros propósitos de codificación a través de la interfaz de usuario de Copilot o herramientas similares. Sin embargo, nunca habíamos usado LLMs o modelos de lenguaje grande a esta escala Teníamos muchas preguntas abiertas sobre esto, como ¿puede LLM realmente manejar esto?

Además, las bibliotecas o bibliotecas de componentes que teníamos eran bibliotecas internas y los LLMs no estaban entrenados en ellas. Así que otra pregunta era cómo podemos usarlo? Finalmente, ¿qué tipo de precisión o consistencia podemos esperar de este LLM? Así que en lugar de sumergirnos directamente en la implementación, lo que decidimos fue tener una exploración de tres días. Nos sentaremos como equipo e intentaremos responder a estas preguntas abiertas una por una y evaluar si los LLMs pueden ser utilizados para nuestro propósito o no.

Aunque llevamos a cabo muchas actividades durante nuestra fase de experimentación, me gustaría centrarme para esta presentación en una serie de experimentos iterativos que realizamos para mejorar la precisión del resultado y asegurar que los LLMs puedan transformar nuestros componentes correctamente. Para la primera iteración, lo que hicimos fue simplemente pasar los archivos fuente del componente al LLM. Luego le dimos al LLM un archivo de prueba que contenía diferentes usos de los componentes con variada complejidad y le pedimos que los migrara. Queríamos ver qué tan bien podía hacerlo. Los resultados no fueron muy buenos. LLM no pudo transformar los usos complejos. Podía transformar los usos simples, pero no podía transformar los usos complejos. El problema fue que después de investigar, le pedimos al LLM que hiciera demasiadas cosas de una sola vez o en un solo paso. Por ejemplo, leer el archivo fuente, extraer la interfaz, crear las instrucciones del transformador por sí mismo, luego hacer la migración. Encargarse de demasiados pasos redujo la precisión y causó que el LLM fallara.

Luego intentamos una segunda iteración donde intentamos simplificar la cantidad de datos y el contenido que enviamos al LLM al no dar el archivo fuente, sino dar la interfaz detallada del componente. Esta interfaz contenía toda la información que el LLM necesitaría saber sobre el componente como las propiedades, los subcomponentes, los valores predeterminados, etc., y luego le pedimos que hiciera lo mismo. Sin embargo, aquí también el LLM no hizo un buen trabajo. Podía transformar archivos simples o usos simples, pero no podía transformar usos más complejos. Una razón fue que el LLM estaba perdiendo mucho contexto aquí. Para dar un ejemplo, en la biblioteca fuente, el componente de botón tenía tres tamaños diferentes, pequeño, mediano, grande, mientras que en la biblioteca objetivo solo tenía dos tamaños, pequeño y grande. Entonces, si el LLM encuentra un botón con tamaño mediano, ¿qué debería hacer? ¿Dónde debería colocarlo, pequeño o grande?

Luego comenzamos la tercera iteración donde pusimos el mismo prompt que antes, pero también dimos instrucciones de migración paso a paso que le dijeron al LLM cómo manejar este caso y también aclararon cualquier ambigüedad que LLM tenía. Los resultados fueron definitivamente mejores esta vez. Sin embargo, todavía había alguna inconsistencia. Parte de la lógica de negocio más compleja no fue migrada. Algunas cosas como limpiar las importaciones antiguas o variables no utilizadas tampoco se hicieron correctamente. En esta etapa, comenzamos a investigar qué podíamos hacer para mejorar el resultado. Por ejemplo, miramos alrededor y revisamos diferentes artículos de investigación y lo que descubrimos es que si proporcionamos patrones, eso podría realmente aumentar la precisión del LLM y eso es exactamente lo que hicimos.

Junto con el contexto anterior, también pasamos un conjunto de ejemplos de transformación que eran simplemente ejemplos de antes y después y los pasamos. Y con esto la precisión de LLM fue bastante buena. Tenía un 90% de precisión y estábamos bastante satisfechos con ello y luego decidimos proceder más allá. Una pequeña nota sobre la precisión, usamos una matriz para calcular qué tan bien se comportaba LLM y esta matriz de precisión era simplemente el número de líneas que fueron migradas correctamente por LLM dividido por el total de líneas de código migradas. Por correctamente, me refiero a que si había una importación no migrada correctamente o algunas variables no utilizadas o algunos errores, esos fueron excluidos y luego calculamos esta matriz.

Ahora, una vez que la estructura del prompt fue definida, así es como se veía el prompt final. Tenía cuatro secciones. Las primeras tres secciones como mencioné antes son simplemente instrucciones de mapeo de interfaz y ejemplos que fueron generados y la sección final era el archivo que se necesitaba que fuera transformado. Una cosa a notar aquí es que mantuvimos las instrucciones de interfaz y ejemplos en la parte superior porque estos no diferían de archivo a archivo. Para un componente, siempre eran los mismos y de esta manera, podíamos de esta manera, esto podía ser almacenado en caché y podíamos ahorrar algunos costos en el lado de LLM debido al almacenamiento en caché del prompt. Una vez que el prompt estaba allí, decidimos construir una pequeña herramienta que era una herramienta CLI. Esta herramienta, lo que hacía era en el primer paso, escaneaba todo el repositorio para encontrar todos los archivos que contenían los componentes que queríamos migrar.

Luego construía el prompt con los componentes como mostré en la diapositiva anterior y el archivo y luego lo enviaba al LLM para la transformación. LLM tomará el archivo, lo transformará y lo enviará como respuesta que luego fue extraída por la herramienta y se aplicó al archivo existente y se comprometió y luego se creó una revisión para que el ingeniero la verificara, la probara y luego la fusionara y desplegara. Ahora hablando un poco sobre los detalles técnicos, usamos muchas herramientas diferentes. Estas herramientas eran de código abierto pero realmente nos ayudaron a reducir mucho esfuerzo y también mucho tiempo. Usamos una herramienta llamada continue.dev. Continue.dev hizo muy fácil crear los prompts. Todo lo que teníamos que hacer era dar los archivos fuente a la herramienta y luego pedirle que generara la interfaz de instrucciones y ejemplos y fue capaz de hacerlo fácilmente. Luego también usamos LLM SDK por Dataset. Esto tenía una API de conversación muy agradable que nos permitió interactuar con LLM y también continuar respuestas si se cortaban y así sucesivamente. Finalmente, también usamos una herramienta AIDAR que también era basada en IA. Esta herramienta nos ayudó a automatizar los commits de git y también ayudó a crear un buen mensaje de commit y descripción para que el usuario que va a revisar la solicitud de extracción, sepa lo que se ha hecho y hace que las revisiones de solicitudes sean más fáciles para ellos. Para la herramienta, también teníamos un marco de pruebas de regresión en su lugar.

Lo que teníamos era un conjunto dorado de ejemplos de migración antes y después y cada vez que hacíamos cambios en los prompts, intentábamos ejecutar la herramienta nuevamente en los ejemplos anteriores y luego compararlo con los ejemplos posteriores. Lo comparábamos manualmente o a través de LLM y decíamos cuándo se usaba esto para ver si había alguna regresión o disminución en la precisión de la herramienta. También fue muy útil si queríamos probar un nuevo modelo y ver cómo se comportaba ese modelo. Así que esta configuración de regresión fue muy útil para nosotros.

Otra cosa que tuvimos que hacer para mantener la precisión del resultado de LLM fue gestionar el tamaño del contexto de los prompts que enviábamos a la herramienta. Primero, queríamos intentar ejecutar la herramienta con tantos componentes como fuera posible. Sin embargo, lo que notamos es que si el tamaño del contexto se vuelve muy grande, la precisión del resultado comenzaba a degradarse bastante. Así que lo que, después de un poco de prueba y error, descubrimos es que alrededor de 40,000 tokens era un buen tamaño para el prompt y eso es lo que usamos para nuestra herramienta. Así que migramos un pequeño conjunto de componentes, asegurándonos de que el tamaño del token estuviera por debajo de 40,000 tokens.

Ahora, hablemos un poco sobre cuál fue el resultado. Pudimos migrar más de 11 aplicaciones B2B complejas. Estas aplicaciones eran aplicaciones bastante complejas. Se esperaba que la migración de cada una de estas aplicaciones tomara entre uno a cuatro meses y LLM asistió en esta migración realizando las tareas de transformación o migración más repetitivas y comunes, liberando a nuestro equipo de diseño, producto e ingeniería para centrarse en tareas más desafiantes, puliendo la UI, refinando errores, probando, y luego desplegando y fusionando. LLM también llevó a cabo las transformaciones o migraciones con una alta precisión del 90 por ciento o más. Y muchos de estos, y no hubo problemas específicos aquí, fueron pocos errores aquí y allá, pero la mayoría de las cosas eran solo entradas no utilizadas. Así que esto aseguró que nuestros ingenieros no necesitaran pasar mucho tiempo corrigiendo problemas causados por LLMs. El costo por repositorio para nosotros fue de 40 USD. Si miras cuánto esfuerzo nos ahorró LLM durante esta migración, fue un muy buen retorno de inversión.

Por otro lado, también enfrentamos un incidente aquí. Este incidente se debió al hecho de que cuando el LLM migró los datos esperados por un componente, el LLM cometió un error en esa migración. Sin embargo, este problema fue muy difícil de detectar y también se pasó por alto durante la revisión, lo que resultó en que el código se desplegara en producción y los usuarios vieran una página rota. Dos aprendizajes de este incidente para nosotros fueron, primero, los LLMs pueden generar un código que parece plausible, pero puede ser incorrecto. Y por eso es muy importante que siempre que tengas algo así, algún código generado por LLMs, lo revises muy cuidadosamente.

Otro problema fue que cuando los LLMs migran el código, pueden crear una brecha de conocimiento porque los usuarios no lo han migrado ellos mismos, por lo que pueden carecer un poco de familiaridad con la biblioteca. Y esto realmente puede causar un incidente o puede causar dificultad en la depuración, y así sucesivamente. Y lo que recomendamos aquí es que un equipo debería estar básicamente lo más cerca posible del código, intentar integrarse y tratar de entender lo que está sucediendo, para que este tipo de problemas no ocurran.

Dando un ejemplo de cómo se vería la migración, como puedes ver, este es un ejemplo de un PR, que fue básicamente hecho por el LLM. Puedes ver que es un PR muy grande, por lo que puedes imaginar la cantidad de esfuerzo que nos ahorró la migración automatizada realizada por el LLM. También hizo un muy buen trabajo al migrar los diferentes componentes. Algo interesante es que si miras el componente select, el componente select tenía un poco de lógica dentro de él. Por ejemplo, tenía un map que realmente iteraba sobre las opciones de selección, y también había un componente de texto dentro de la opción de selección. El LLM pudo migrar todo esto con éxito. Extrajo la lista de opciones y la convirtió en un objeto. También extrajo la función y la puso en el campo de etiqueta. Así que, como puedes ver, el LLM pudo realizar con mucho éxito transformaciones complejas de varios pasos sin ninguna información extra o adicional. Luego, hay algunos ejemplos más que me gustaría compartir, donde los LLMs hicieron un trabajo bastante bueno.

Este era un pop-up de notificación, y en la biblioteca de origen el pop-up de notificación tenía un tiempo de espera de 4.5 segundos, pero en la biblioteca de destino, no había tiempo de espera para el pop-up de notificación. Tenía que ser especificado explícitamente. Aunque no instruimos al LLM para hacerlo, automáticamente tomó el valor por defecto de la fuente y lo añadió aquí. Así que, se puede ver lo inteligentes que son los LLMs en algunos casos. Además, corrigió un problema en uno de los nombres de funciones. Este problema fue, no sé por cuánto tiempo, pero aún así fue capaz de corregir este tipo de problemas.

Hablando de los desafíos, la alucinación e ignorar instrucciones son algunas de las preocupaciones más comunes cuando usamos LLM, y también vimos el mismo problema. Un ejemplo es este campo exclusivo que no estaba en nuestras instrucciones, por ejemplo, pero el LLM aún así lo añadió. Otro problema es que la salida no siempre es determinista. Algo que estaba funcionando hoy puede empezar o dejar de funcionar mañana. Por ejemplo, si miras la imagen en la parte inferior, puedes ver que cambió el nombre de la función de uno correcto a uno incorrecto. Algo así no sucede cada vez, pero puede suceder, digamos, una cada 10-15 ejecuciones.

Teníamos la temperatura configurada en cero, pero aún así sucedió, y estas son las cosas que pedimos a nuestros ingenieros que vigilen durante las revisiones. Otro problema fue que tuvimos que gestionar los prompts muy cuidadosamente. Si la entrada era muy grande, entonces la precisión de los prompts comenzaba a disminuir y los LLMs no podían transformarlo muy correctamente, y por lo tanto, tuvimos que tener cuidado con eso. Otro problema fue que las respuestas eran bastante lentas, especialmente en comparación con los codemods. Cada respuesta de LLM tomó alrededor de 30 a 200 segundos por archivo, y aunque esto no fue un problema durante la migración ya que la herramienta de migración podía ejecutarse en segundo plano, sin embargo, ralentizó nuestras fases iterativas y experimentales debido a este tiempo que tomaba.

También hubo algunas limitaciones relacionadas con el proyecto debido a las cuales no pudimos usar la herramienta a su máxima capacidad. Por ejemplo, había limitaciones de tiempo debido a las cuales no pudimos migrar los casos de prueba. Hubo algunas diferencias en los componentes donde cada uno de ellos necesitaba ser manejado de manera individual, y había muchas variaciones en la base de código lo que hacía que el uso de la herramienta fuera más desafiante.

Ahora, hablando de las lecciones aprendidas, los LLMs son bastante efectivos. A través de este proyecto, pudimos ver que los LLMs fueron bastante efectivos para nuestra migración, y ahora, hemos estado usando LLM en todas nuestras migraciones futuras también. El enfoque iterativo y experimental que aplicamos durante este proyecto resultó ser muy útil, y este es el modelo que usamos siempre que tenemos algunas preguntas abiertas sobre claridad acerca del uso de LLMs en nuestro proyecto. Los LLMs pueden migrar, pero no transfieren el conocimiento, y esto puede, como mostré antes, causar problemas en la depuración o incluso causar incidentes en el peor de los casos.

Por lo tanto, nuestra recomendación para los equipos es que se mantengan al tanto del código, sepan lo que está sucediendo, y si hay algo nuevo, intenten familiarizarse con esa base de código. Como se mostró en la diapositiva anterior, hubo muchos problemas inesperados causados por los LLMs, y los equipos deben asegurarse de que haya algún ingeniero que esté revisando cada cambio y revisándolo cuidadosamente, porque los LLMs aún pueden cometer muchos errores. Usamos muchas herramientas, y estas herramientas fueron muy útiles para reducir nuestro tiempo y también reducir nuestro esfuerzo. Estas herramientas también son como un paisaje que avanza muy rápido.