Introducción:
Heráclito, el filósofo griego, dijo célebremente: «El cambio es la única constante en la vida». Este sentimiento es válido no solo para nuestra vida personal, sino también para el campo en rápida evolución de las aplicaciones de inteligencia artificial generativa. En particular, las aplicaciones basadas en Modelos de Lenguaje Largo (LLM) son cada vez más sofisticadas y complejas. Sin embargo, como con cualquier tecnología, el cambio es inevitable. El desafío que enfrentan los desarrolladores de estas aplicaciones es cómo prepararse y adaptarse a este cambio. Es vital que los desarrolladores de aplicaciones reconozcan la importancia del cambio y tomen medidas para garantizar que sus aplicaciones sigan siendo relevantes y valiosas frente a un cambio cada vez mayor. -Panorama tecnológico cambiante.
Crear un MVP (Producto Mínimo Viable) para una aplicación basada en LLM puede ser un desafío. Sin embargo, una vez que la aplicación está en producción, la actualización y los cambios pueden ser más desalentadores. Entregar cambios más rápido, con calidad y con gastos generales de bajo costo se vuelve esencial, pero no está bien definido.
¿Cuál es la necesidad de cambio?
También te puede interesar
- Desarrollo iterativo de software: permite a los equipos responder a los cambios y mejoras a partir del aprendizaje del desempeño del producto en el mercado. Esto da como resultado un proceso de desarrollo más eficiente y eficaz, que en última instancia conduce a un mejor producto final.
- Desarrollo de nuevas funciones: Se agregan nuevas características y capacidades a la aplicación LLM. Esto puede requerir cambios en varios componentes del producto.
- Mejoras rápidas: En un campo en rápida evolución como LLM, las mejoras rápidas a LLM son esenciales para corregir defectos y mejorar el rendimiento. Sin embargo, implementar estas mejoras puede ser un desafío debido a la naturaleza compleja de los modelos, a menudo denominados «cajas negras».
- Adopción de LLM recién introducidos: A medida que se introducen nuevos LLM, pueden ofrecer un mejor rendimiento y capacidades que los modelos existentes.
- Deriva de datos: A medida que los datos utilizados para entrenar cambian con el tiempo, los modelos pueden volverse menos precisos y requieren un nuevo entrenamiento y, finalmente, una actualización.
¿Qué podemos esperar que cambie?
¡¡Todo!! Los desarrolladores de aplicaciones LLM pueden esperar encontrar cambios en TODOS los componentes a medida que estas aplicaciones continúan evolucionando. Para seguir siendo competitivos, los desarrolladores deben estar preparados para este tipo de cambios y tener un enfoque estructurado y modular. [like Lego blocks] al desarrollo. Esto puede implicar mejorar y actualizar continuamente modelos y aplicaciones, mantenerse al día con las nuevas tecnologías y estar dispuesto a experimentar e iterar en los procesos de desarrollo para lograr mejores resultados. En última instancia, la capacidad de adaptarse y responder al cambio será fundamental para el éxito a largo plazo.
Ingrediente para el éxito:
Si bien la velocidad del cambio es esencial para mantenerse competitivo y ofrecer nuevas aplicaciones innovadoras, la entrega rápida no debe ser a expensas de la calidad. Para garantizar una alta calidad y una entrega más rápida, pruebas automatizadas juega un papel importante en la detección temprana de defectos y errores en el proceso de desarrollo.
También te puede interesar
Los patrones de prueba automatizados para los componentes existentes, como el código y los modelos, están bien definidos en forma de pruebas unitarias, pruebas de integración, pruebas de regresión, pruebas de validación cruzada y pruebas de retención. Sin embargo, actualmente no existe un proceso estandarizado para probar las indicaciones: el chico nuevo en el bloque. A medida que este campo continúe evolucionando, será importante desarrollar nuevas metodologías de prueba que puedan seguir el ritmo de estos cambios y garantizar la calidad de las aplicaciones.
Algunas de las áreas clave que se ven afectadas o que impactan las indicaciones son:
- Cambios en las indicaciones utilizadas en los LLM
- Los propios modelos LLM pueden requerir ser reemplazados
- Cambios en las aplicaciones que utilizan estos modelos
- Cambios en los datos utilizados para entrenar y probar los modelos
En este artículo, me centraré en los desafíos de probar las indicaciones y el impacto de las indicaciones en otras formas de pruebas establecidas en las aplicaciones de LLM y compartiré las soluciones que he adoptado para garantizar que estos componentes críticos se prueben y validen exhaustivamente. Al adoptar un enfoque más riguroso y estructurado para las pruebas rápidas, los desarrolladores pueden asegurarse de que sus aplicaciones sean de la más alta calidad y que estén mejor posicionadas.
Desafíos con indicaciones de prueba:
También te puede interesar
- Complejidad: Las indicaciones pueden ser complejas, con muchas entradas y salidas diferentes que deben validarse. Esta complejidad puede dificultar la creación de pruebas automatizadas que cubran con precisión todos los escenarios posibles.
- Tiempo: El tiempo de respuesta de las API utilizadas para interactuar con las indicaciones puede afectar las pruebas. Los tiempos de respuesta lentos de la API pueden generar ejecuciones de prueba más largas y mayores costos de prueba.
- Costo: El costo asociado con el alojamiento de LLM en la nube también puede ser un desafío. Las indicaciones de prueba pueden requerir la ejecución de una gran cantidad de pruebas, lo que puede ser costoso cuando se utilizan LLM basados en la nube.
- Imprevisibilidad: Los avisos que generan texto de forma libre pueden ser impredecibles, con respuestas que varían según el contexto, la entrada del usuario y el modelo con el que está operando. Esto dificulta la creación de pruebas automatizadas que puedan predecir con precisión la respuesta del aviso.
- Sensibilidad de los datos: Los avisos que interactúan con los programas de aplicación subyacentes pueden ser sensibles a los cambios en los datos o en la propia aplicación. Esto puede dificultar la prueba de solicitudes de forma aislada, ya que pueden requerir acceso a la aplicación subyacente y las fuentes de datos.
- Integración: Es posible que las solicitudes deban integrarse con otros componentes de la aplicación, como bases de datos o canalizaciones de datos. Esto puede dificultar la creación de pruebas aisladas para avisos, ya que pueden depender de otros componentes del sistema.
Tipo de cambios y metodologías de prueba:
# 1 Cambios en la aplicación:
Los cambios en la aplicación subyacente pueden requerir una nueva prueba para garantizar que funcione según lo previsto. Si bien esto no está directamente relacionado con el aviso, las metodologías existentes se ven afectadas por la introducción de LLM.
Al ejecutar las pruebas de automatización para los cambios de aplicaciones que interactúan con los LLM, es crucial tener en cuenta la velocidad y el costo de las API de LLM. Ejecutar una API LLM normal para completar con 1800 tokens puede demorar hasta 12 segundos y costar unos centavos. Teniendo esto en cuenta, ejecutar un conjunto de pruebas automatizado para aplicaciones podría convertirse en un gasto significativo y en un proceso lento. Si bien aún se pueden seguir los ciclos regulares de control de calidad, es esencial evaluar cuidadosamente el impacto de cualquier cambio en el rendimiento y el costo. Los costos aumentan a medida que aumenta la complejidad del sistema y es necesario realizar más pruebas para garantizar la calidad.
También te puede interesar
Desatando el poder de la IA en el comercio electrónico: ¡ShopSphere para brillar a la perfección! | por ShopSphere | mayo, 2023Una forma de mitigar estos desafíos es aprovechar una técnica existente que puede aislar las dependencias externas para las pruebas de automatización, burlándose de los puntos finales del servicio LLM. Esto será más fácil cuando la integración esté basada en REST, pero el uso de bibliotecas de programas de alto nivel LLM puede agregar una complejidad adicional. Hay varias herramientas por ahí. El simulacro de cable de herramienta de código abierto (https://wiremock.org/) es mi favorito, ya que viene con la capacidad de registrar la respuesta de los proveedores de servicios en la primera llamada y almacenarla en caché, que se puede usar para servir las respuestas posteriores.
#2 Cambios en las solicitudes que interactúan con la aplicación mediante datos estructurados:
Estos tipos de avisos usan datos estructurados para interactuar con las aplicaciones subyacentes, lo que permite que las aplicaciones usen las capacidades computacionales de los LLM para manipular datos y aprovecharlos en pasos posteriores. La salida normalmente estaría en formato JSON, XML, HTML, etc. Los ejemplos incluyen avisos que permiten a los usuarios procesar datos no estructurados que deben incorporarse a una base de datos, o avisos que activan acciones específicas dentro de una aplicación. El resultado de estas indicaciones es estructurado y predecible.
Si bien las salidas de datos estructurados pueden ser más fáciles de validar con métodos de prueba automatizados, aún es importante asegurarse de que las salidas sean consistentes con el contrato y cumplan con los requisitos del programa de aplicación. Este es también el comienzo de la zona gris. Los programadores de aplicaciones con gran experiencia en programación lógica que están acostumbrados a ver un comportamiento consistente con programas de alto nivel tendrán dificultades, ya que no pueden predecir el impacto de los cambios menores en el aviso en la salida generada.
Cada aviso que cambia debe validarse de forma independiente utilizando un conjunto de entradas de prueba de referencia y resultados esperados. Es muy crítico que el conjunto de prueba cubra las condiciones de contorno. El resultado de la solicitud cambiada debe afirmarse para mayor precisión. Las aserciones se pueden realizar con operadores relacionales nativos o funciones de cadena.
Se puede implementar un mecanismo de ponderación relativa para tener en cuenta la importancia relativa de las indicaciones utilizadas con frecuencia frente a las indicaciones utilizadas en condiciones límite en la puntuación final. Las indicaciones deben ser versionadas y las puntuaciones en cada cambio deben registrarse para realizar un seguimiento de las mejoras. Si bien existen herramientas como ponderaciones y sesgos (https://wandb.ai/site) que pueden realizar un seguimiento de los resultados de la experimentación de los modelos de ML, no he encontrado herramientas que brinden los mismos servicios de forma rápida.
#3 Solicitudes que generan texto de formato libre utilizado por los clientes:
Estos tipos de avisos generan respuestas de texto en lenguaje natural que están diseñadas para ser leídas e interpretadas por usuarios humanos. A menudo se utilizan en la creación de contenido y aplicaciones de IA conversacionales, donde el objetivo es crear una interacción que suene natural que imite una conversación humana. El resultado de estas indicaciones generalmente no está estructurado y puede ser difícil de validar con métodos de prueba automatizados.
Este es el elefante en la habitación. La mayoría de los pasos mencionados en la sección anterior también se aplican a esto, pero la complejidad surge con la afirmación de la salida de datos no estructurados.
Las siguientes opciones se pueden utilizar para la aserción:
Semejanza de coseno es una métrica utilizada para medir la similitud entre dos vectores de un espacio de producto interno. En otras palabras, es una forma de determinar qué tan similares son dos piezas de texto en función de su contenido. Para implementar la similitud del coseno para este caso de uso, primero debemos convertir en vectores las salidas y los resultados esperados de línea base de las indicaciones modificadas. La incrustación es útil para convertir texto en espacio vectorial. Estoy usando text-embedding-ada-002 que puede generar vectores con 1536 dimensiones y puede aceptar tokens de 8K, más de lo que generan la mayoría de los modelos actuales. Es rápido y comparativamente menos costoso. Una vez que se obtienen los vectores de salida, la similitud del coseno se puede calcular fácilmente. La puntuación de similitud del coseno es una métrica eficaz para evaluar la similitud entre los resultados de la línea de base y los resultados generados por la indicación actualizada. Una puntuación de similitud de coseno más alta indica un mayor grado de similitud entre las dos salidas.
BLEU (Suplente de evaluación bilingüe) es una métrica que se utiliza para evaluar la calidad de la traducción automática frente a una o más traducciones de referencia. Mide el grado de similitud entre una traducción generada por una máquina y una o más traducciones de referencia generadas por humanos, en función de una comparación de secuencias de n-gramas (secuencias continuas de n palabras) entre los dos textos. Es una métrica ampliamente utilizada en el campo del procesamiento del lenguaje natural para evaluar la calidad del texto generado por una máquina. Esto se puede modificar para comparar la salida de referencia con la salida generada a partir de la indicación modificada. Una puntuación BLEU más alta indica un mayor grado de similitud entre los dos resultados.
Si bien el modelo anterior (utilicé el coseno) tuvo éxito en temperaturas más bajas donde la salida era predictiva, surgen desafíos para la salida creativa de forma libre a temperaturas más altas. Es necesario establecer un enfoque alternativo.
Conclusión:
En conclusión, construir y entregar aplicaciones basadas en LLM es una tarea compleja y desafiante, y mantenerlas relevantes y útiles frente al rápido cambio tecnológico lo es aún más. Para seguir siendo competitivos, los desarrolladores deben estar preparados para enfrentar cambios en todos los componentes de la aplicación, desde las indicaciones utilizadas en los LLM hasta los propios modelos, así como cambios en las aplicaciones que utilizan estos modelos y los datos utilizados para entrenarlos y probarlos. Si bien la velocidad del cambio es esencial, la entrega rápida no debe ser a expensas de la calidad, razón por la cual las pruebas automatizadas desempeñan un papel crucial en la detección temprana de defectos y errores en el proceso de desarrollo. Si desea tener una conversación de seguimiento o necesita acceso al marco de prueba, comuníquese conmigo.
