Abierto a posiciones de AI Engineer remoto o híbrido
Competencia

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.

Dónde la apliqué

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