Evaluación de LLMs: datasets propios y chequeos en CI
Un agente que funciona en una demo no está evaluado. Así evalúo los de AgendaGo, que está en producción: datasets propios, chequeos deterministas y evals con modelo contra el stack real.
Qué significa evaluar un LLM
Evaluar es medir el comportamiento del agente con casos fijos y criterios escritos de antemano, no probar a mano unas pocas frases. Sin eso, cada cambio de prompt o de modelo puede romper algo y nadie se entera hasta que lo reporta un cliente.
Cómo lo hice en AgendaGo (en producción)
- Asistente del panel: un dataset de 100 frases, con la herramienta esperada para cada una, y chequeos deterministas en CI.
- Agente de WhatsApp: un dataset de 52 escenarios y 15 conversaciones. Las categorías incluyen saludo, precio, reserva, ambigüedad, adversarial y prompt injection.
- Cada escenario declara la ruta esperada, los criterios de acierto y el comportamiento prohibido.
- Los evals con modelo corren contra el stack real, con un tope de gasto, y existe un script de juez a ciegas.
Decisiones y compromisos
Separé lo que se puede verificar sin modelo de lo que no. Los chequeos deterministas corren en CI en cada cambio; los evals con modelo corren contra el stack real y tienen un costo, por eso llevan un tope de gasto.
Que cada escenario declare lo que el agente no debe hacer importa tanto como lo que debe hacer: un caso adversarial o de prompt injection se aprueba solo si el agente no cae.
La evaluación se complementa con la telemetría por llamada de la tabla ai_usage_log, que registra modelo y versión de prompt, y con un test que exige que cada insert declare las dos cosas. Lo cuento en la página de observabilidad.
Stack relacionado
- OpenAI
- Supabase
- CI