Langfuse es una herramienta útil para realizar pruebas flexibles de agentes de IA. Recientemente, nos propusimos implementar un marco para probar agentes de IA basados ​​en chat. Lo siguiente es un relato de nuestro viaje para navegar por las herramientas disponibles.

Nos centraremos principalmente en cómo realizar esta tarea ahora, pero al final abordaremos algunas ideas sobre los desafíos que aún enfrentamos y qué pueden hacer las herramientas disponibles para respaldar mejor este tipo de casos de uso en el futuro.

Antes de revisar cómo construimos nuestro sistema, analizaremos rápidamente nuestros objetivos y criterios de éxito.

Los casos de uso de IA generativa son generalmente fáciles de implementar pero difíciles de controlar. Al implementar un agente con un modelo de contexto grande, los cambios ascendentes en las indicaciones del modelo, la configuración de temperatura, la política de moderación de contenido, etc., pueden afectar drásticamente su rendimiento.

El desafío es crear un sistema que pueda evaluar la capacidad de un agente para realizar tareas específicas sin alucinar ni romper la política de contenido. Comparamos esto con las pruebas unitarias, lo que garantiza que su agente mantenga su capacidad para realizar una amplia lista de tareas, incluso cuando el equipo detrás pueda estar centrándose en mejoras específicas. Realizar este tipo de pruebas manualmente puede resultar impreciso, llevar mucho tiempo y ser difícil de rastrear.

Entonces, nos propusimos crear un sistema que pudiera crear fácilmente estas pruebas y monitorear sus resultados. Es importante destacar que queríamos que este sistema fuera operativo con una frecuencia mínima de cambios de código requeridos para que un gerente de producto o un evaluador de control de calidad pudiera contribuir sin tener que tocar el código.

Partimos de algunos parámetros clave para nuestra búsqueda:

Cumplimiento de HIPAA, ya que tanto los productos que fabricamos como muchos de nuestros socios consultores se encuentran en el ámbito de la atención médica.

Bajo costo, tanto para mantenerse como para operar, ya que operamos de manera bastante eficiente, al igual que nuestros socios.

Impulso del desarrollo. El espacio de observabilidad del LLM está evolucionando rápidamente. Desde el principio de nuestra búsqueda, estábamos preparados para equivocarnos, pero queríamos minimizar esta posibilidad eligiendo una herramienta que probablemente evolucionara con nosotros.

Capacidad de evaluación LLM personalizada. Sorprendentemente, la capacidad de implementar y ejecutar un evaluador personalizado fue algo que no encontramos fácilmente compatible entre todas las opciones que encontramos, particularmente entre las opciones de código abierto.

Para simplificar nuestra búsqueda, identificamos a los siguientes jugadores en las categorías empresarial y de código abierto que parecían cumplir con nuestros criterios, enumerados aquí en orden aproximado.

Empresa

Fuente abierta

Elegimos Langfuse principalmente porque es fácil de implementar por sí mismo sin interactuar con un equipo de ventas empresarial y porque creemos que tiene las características críticas que necesitamos. Hasta ahora esto ha resultado ser correcto.

Despliegue

Descubrimos que el proceso de implementación, en general, es relativamente simple. Langfuse proporciona una imagen de la ventana acoplable fácil de usar y documentación sólida sobre cómo implementarla localmente. Crear un archivo YAML e implementarlo en EKS fue sencillo y tuvimos una instancia de demostración en funcionamiento en un par de horas. No configuramos SSO para nuestra POC, por lo que utilizamos la administración de usuarios básica proporcionada de fábrica (no mucha) y confiamos en datos anonimizados para cumplir con los requisitos de seguridad. Una base de datos PG de nivel gratuito en RDS podría manejar muchas consultas, evaluaciones y administración rápida para múltiples usuarios. La aplicación es muy ligera. Algunos problemas con los que nos topamos:

• No hay forma de obtener una lista de mensajes en el SDK mediante programación. Esto significaba que cuando estábamos reuniendo varios mensajes del sistema o chats de pruebas unitarias, teníamos que almacenar nombres de mensajes en las configuraciones de cualquier punto de entrada que usáramos para un caso de uso particular (por ejemplo, una lista de pruebas unitarias en el mensaje del sistema para un agente)
• No encontramos una manera de obtener una lista de variables en las solicitudes para usar en la compilación. Estábamos usando diferentes variables para diferentes mensajes del sistema que obtendríamos y teníamos que codificar qué bits de datos se compilarían en cada uno o hacer algo de prueba y error.
• Las observaciones no estaban bien documentadas. Al registrar puntuaciones en Langfuse, vimos que se podía agregar un ID de observación, pero los documentos generalmente buenos no proporcionaban contexto adicional. Probablemente los usemos en el futuro una vez que descubramos todas las posibilidades que ofrecen.

Un diagrama de cómo utilizamos las configuraciones de aviso del sistema para crear un sistema de prueba central sin código en Langfuse

Con un par de semanas de trabajo, hemos configurado un sistema de pruebas de un extremo a otro. Langfuse ofrece más funciones de las que hemos utilizado hasta ahora, pero nos hemos centrado en utilizar indicaciones, sesiones y seguimientos.

Un requisito clave que teníamos al realizar pruebas en un agente basado en chat era la capacidad de colocar a un agente en medio de un escenario de chat, utilizando los mensajes intercambiados previamente como contexto. Se puede crear cualquier mensaje personalizado para incluir el historial de chat, pero Langfuse lo hace particularmente fácil.

Además, creamos una interfaz de chat para el agente que permite a los usuarios probar y generar nuevos mensajes de prueba in situ para evaluaciones. Esto resuelve uno de los

Para problemas potenciales al inyectar indicaciones como contexto, los chats deben representar resultados reales que el modelo podría crear.

Esto crea una vulnerabilidad potencial: los historiales de chat que utilizamos como contexto deben actualizarse si el comportamiento subyacente del modelo cambia. Dicho esto, consideramos que este método es más controlable y consistente que alternativas potenciales, como hacer que un agente interactúe con otro, algo que vamos a explorar como otra adición a este tipo de sistema.

El otro desafío clave que abordamos fue cómo crear un conjunto de pruebas completo sin necesidad de código. Primero, para definir un conjunto de pruebas, creamos un objeto de configuración en el indicador del sistema para el agente, que definió la lista de pruebas que se ejecutarán en él.

Esto también nos permitió pasar el indicador del sistema como una variable al ejecutar un conjunto de pruebas. Uno de los principales beneficios de un sistema como Langfuse es su capacidad para permitir una gestión rápida como código en su interfaz de usuario. Con ese fin, los avisos de seguimiento del sistema que pueden inyectarse en el sistema también están vinculados al aviso del sistema en la configuración, lo que nos permite forzar el modelo subyacente a estados específicos durante las pruebas mientras protege el sistema contra cambios en el primario o en el siguiente. -en las indicaciones del sistema.

Al administrar la lista de pruebas que se ejecutarán como configuraciones en el indicador del sistema, requerimos un cambio de código solo una vez por agente. La lista de pruebas que se ejecutarán se puede cambiar y ampliar dentro de la interfaz de usuario de Langfuse.

Cada mensaje de prueba está vinculado a su evaluador como parte de su configuración. Cada mensaje de prueba tiene al menos una evaluación personalizada ejecutándose, con mensajes que siguen aproximadamente esta plantilla: un útil evaluador de IA que proporcionará comentarios y puntuación en la tarea siguiente.

You are a helpful AI evaluator who will provide feedback and scoring on the task below.[Describe the scenario and how the agent has been instructed to behave in said scenario]Based on the transcript output, you will determine whether this task was successfully completed.  You will return a JSON object in the following form:-------------Example outputs:{"score": -1, "comment": [Description of an example negative case}{“score”: 1, “comment”: [Description of an example positive case]}------------In this object, score is a number between -1 and 1, with 1 indicating complete success and a -1 indicating complete failure.  The comment is a string indicating your reasoning for the score.-------------BEGIN TRANSCRIPT:{{transcript}}END TRANSCRIPT--------------Do not return any output except the JSON object referenced above.

Usando este sistema

Consideramos este marco de pruebas y evaluación como un conjunto razonable de compromisos para crear un sistema de bajo costo y fácil de operar. Vemos sus aplicaciones principales como parte de un proceso de CI/CD, lo que garantiza eso o como fuente de un cuadro de mando rápido para alguien que busca modificar las indicaciones de un sistema y desea información más exhaustiva de la que puede obtener mediante pruebas manuales.

Según los modelos que sustentan al agente y sus evaluadores, la utilización de tokens puede significar que una ejecución completa del conjunto de pruebas, que en nuestro caso puede contener fácilmente docenas de indicaciones de prueba y evaluadores, puede costar decenas de dólares.

Una forma de controlar el costo de ejecutar un sistema como este como medio para iterar solicitudes y herramientas, particularmente cuando se realizan grandes cantidades de cambios en un intento de mejorar el rendimiento de forma iterativa, es comenzar con un modelo más pequeño, midiendo el rendimiento relativo y intensificar las pruebas a modelos más grandes solo cuando encuentre un resultado alentador.

En general, estamos contentos con nuestra decisión de utilizar Langfuse. Con una cantidad de trabajo razonablemente pequeña, podríamos implementar algo que se ajuste a nuestras necesidades. El sistema era lo suficientemente flexible como para permitirnos personalizarlo para adaptarlo a nuestro caso de uso con relativa rapidez.

Hemos notado algunas deficiencias que esperamos se solucionen con el desarrollo futuro:

Al Langfuse UX le falta algo de pulido, lo que aumentaría significativamente la calidad de vida de sus usuarios. Los ejemplos incluyen la imposibilidad de duplicar un mensaje y la imposibilidad de buscar mensajes disponibles por cualquier parámetro que no sea su nombre.

La opción autohospedada no le permite activar nuevas ejecuciones de prueba desde la interfaz de usuario, lo que significa que alguien que opere el sistema debe hacerlo a través de la línea de comandos u otra interfaz de usuario desarrollada para este propósito.

Entendemos que este entorno está evolucionando rápidamente, pero creemos que este marco aproximado es razonablemente portátil, en caso de que finalmente decidamos implementarlo en otro sistema.

Una forma de aumentar nuestra cobertura de pruebas sería crear variantes de nuestras indicaciones de prueba existentes. Herramientas como TestGen-LLM están surgiendo en el espacio, pero en general, el espacio de uso de GenAI para probar GenAI es joven. Dado que estas cargas útiles son esencialmente objetos JSON, ciertamente es posible indicarle a un LLM que cree variantes. La cuestión, entonces, es cómo controlar la calidad de esas variantes para que sigan representando pruebas válidas.

Los conjuntos de datos de Langfuse son una característica interesante de la herramienta, que permite a los usuarios vincular porciones particulares de trazas como entradas y salidas esperadas de un modelo. Si bien podríamos haber usado algo como esto en nuestras pruebas unitarias, nos resultó más sencillo crear mensajes de chat como entradas y, en general, describir lo que buscábamos en los mensajes de evaluación en lugar de crear un «resultado esperado» para usar en una evaluación de un conjunto de datos. Creemos que los conjuntos de datos son el camino claro a seguir para las pruebas que se pueden evaluar en código (por ejemplo, ¿el chatbot devolvió el año correcto cuando se le preguntó? ¿El chatbot devolvió JSON funcional?). Es posible que los usemos en el futuro para pruebas más generales, pero descubrimos que es más rápido generar nuevas pruebas creando las indicaciones por separado.