Por qué es tan difícil probar agentes
Que el agente de IA funcione como se esperaba no es fácil. Incluso pequeños ajustes en componentes como las versiones de solicitudes, la orquestación de agentes y los modelos pueden tener impactos grandes e inesperados.
Algunos de los principales desafíos incluyen:
Resultados no deterministas
La cuestión subyacente que nos ocupa es que los agentes no son deterministas. Entra la misma entrada, pueden salir dos salidas diferentes.
¿Cómo se prueba un resultado esperado cuando no se sabe cuál será? En pocas palabras, probar resultados estrictamente definidos no funciona.
Salidas no estructuradas
El segundo desafío, y menos discutido, de probar sistemas agentes es que los resultados a menudo no están estructurados. Después de todo, la base de los sistemas agentes son los grandes modelos de lenguaje.
Es mucho más fácil definir una prueba para datos estructurados. Por ejemplo, el campo id nunca debe ser NULL o ser siempre un número entero. ¿Cómo se define la calidad de un gran campo de texto?
Costo y escala
LLM-as-juez es la metodología más común para evaluar la calidad o confiabilidad de los agentes de IA. Sin embargo, es una carga de trabajo costosa y cada interacción del usuario (rastreo) puede constar de cientos de interacciones (intervalos).
Entonces repensamos nuestra estrategia de prueba de agentes. En esta publicación compartiremos nuestros aprendizajes, incluido un nuevo concepto clave que ha demostrado ser fundamental para garantizar la confiabilidad a escala.
Probando a nuestro agente
Contamos con dos agentes en producción que son aprovechados por más de 30.000 usuarios. El Agente de resolución de problemas analiza cientos de señales para determinar la causa raíz de un incidente de confiabilidad de los datos, mientras que el Agente de monitoreo hace recomendaciones inteligentes para el monitoreo de la calidad de los datos.
Para el agente de resolución de problemas probamos tres dimensiones principales: distancia semántica, conexión a tierra y uso de herramientas. Así es como probamos cada uno.
Distancia semántica
Aprovechamos las pruebas deterministas cuando corresponde, ya que son claras, explicables y rentables. Por ejemplo, es relativamente fácil implementar una prueba para garantizar que una de las salidas del subagente esté en formato JSON, que no exceda una longitud determinada o para asegurarse de que las barreras de seguridad se llamen según lo previsto.
Sin embargo, hay ocasiones en las que las pruebas deterministas no funcionan. Por ejemplo, exploramos la incorporación de resultados nuevos y esperados como vectores y el uso de pruebas de similitud de cosenos. Pensamos que esta sería una forma más barata y rápida de evaluar la distancia semántica (el significado es similar) entre los resultados observados y esperados.
Sin embargo, descubrimos que había demasiados casos en los que la redacción era similar, pero el significado era diferente.
En su lugar, ahora le proporcionamos a nuestro juez LLM el resultado esperado de la configuración actual y le pedimos que califique en una escala de 0 a 1 la similitud del nuevo resultado.
Conexión a tierra
Para garantizar la solidez, verificamos que el contexto clave esté presente cuando debería estarlo, pero también que el agente se niegue a responder cuando falte el contexto clave o la pregunta esté fuera de alcance.
Esto es importante ya que los LLM están ansiosos por complacer y alucinarán cuando no estén fundamentados en un buen contexto.
Uso de herramientas
Para el uso de herramientas, contamos con un LLM como juez que evalúa si el agente se desempeñó como se esperaba para el escenario predefinido, lo que significa:
No se esperaba ninguna herramienta y no se llamó a ninguna herramienta. Se esperaba una herramienta y se utilizó una herramienta permitida. No se omitieron herramientas requeridas. No se utilizaron herramientas no permitidas.
La verdadera magia no es implementar estas pruebas, sino cómo se aplican. Aquí está nuestra configuración actual basada en dolorosas pruebas y errores.
Mejores prácticas de prueba de agentes
Es importante tener en cuenta que no solo sus agentes no son deterministas, ¡sino también sus evaluaciones de LLM! Estas mejores prácticas están diseñadas principalmente para combatir esas deficiencias inherentes.
Fallos suaves
Los umbrales estrictos pueden resultar ruidosos con pruebas no deterministas por razones obvias. Entonces inventamos el concepto de “fallo suave”.
La evaluación vuelve con una puntuación entre 0-1. Cualquier valor inferior a 0,5 es un fracaso total, mientras que cualquier valor superior a 0,8 es un aprobado. Las fallas leves ocurren con puntuaciones entre 0,5 y 0,8.
Los cambios se pueden fusionar en caso de una falla leve. Sin embargo, si se excede un cierto umbral de fallas leves, se considera una falla grave y el proceso se detiene.
Para nuestro agente, actualmente está configurado de modo que si el 33 % de las pruebas resultan en una falla leve o si hay más de 2 fallas leves en total, entonces se considera una falla grave. Esto evita que el cambio se fusione.
Reevaluar las fallas leves
Las fallas leves pueden ser un canario en una mina de carbón o, en algunos casos, pueden ser una tontería. Alrededor del 10% de los fracasos leves son el resultado de alucinaciones. En el caso de una falla leve, las evaluaciones se volverán a ejecutar automáticamente. Si las pruebas resultantes pasan, asumimos que el resultado original fue incorrecto.
Explicaciones
Cuando una prueba falla, es necesario comprender por qué falló. Ahora pedimos a todos los jueces de LLM que no solo proporcionen una puntuación, sino que la expliquen. Es imperfecto, pero ayuda a generar confianza en la evaluación y, a menudo, acelera la depuración.
Eliminar pruebas escamosas
Tienes que probar tus pruebas. Especialmente con las evaluaciones de LLM como juez, la forma en que se construye el mensaje puede tener un gran impacto en los resultados. Realizamos pruebas varias veces y si el delta entre los resultados es demasiado grande, revisaremos el mensaje o eliminaremos la prueba inestable.
Monitoreo en producción
Las pruebas de agentes son nuevas y desafiantes, pero son un paseo por el parque en comparación con monitorear el comportamiento de los agentes y los resultados en producción. Los insumos son más confusos, no se espera ningún resultado base y todo ocurre a una escala mucho mayor.
¡Sin mencionar que hay mucho más en juego! Los problemas de confiabilidad del sistema se convierten rápidamente en problemas comerciales.
Este es nuestro enfoque actual. Estamos aprovechando las herramientas de observabilidad de los agentes para abordar estos desafíos e informaremos sobre nuevos aprendizajes en una publicación futura.
El agente de resolución de problemas ha sido una de las funciones más impactantes que hemos incluido. Desarrollar agentes confiables ha sido un viaje que ha definido una carrera y estamos emocionados de compartirlo con usted.
Michael Segner es estratega de productos en Monte Carlo y autor del informe de O’Reilly, “Mejora de la confiabilidad de los datos + IA a través de la observabilidad”. Este fue escrito en coautoría con Elor Arieli y Alik Peltinovich.