Qué son los evals; los unit test de los LLMs
Tiempo estimado de lectura: 4 min
- Los evals son unit tests para sistemas basados en LLMs: pipelines reproducibles que miden si un modelo/prompt/pipeline sigue entregando lo que el negocio necesita.
- Tipos de evaluadores: determinista (regex/JSON Schema), semántico (embeddings + similitud) y LLM-as-a-Judge.
- Práctica: crea un dataset representativo, define la métrica principal, implementa runner y scorer, e integra en CI/CD.
Introducción
Que son los evals; los unit test de los llms. Lo repito porque es la pregunta que nadie hace en serio hasta que algo falla en producción y empiezan a llover tickets.
Resumen rápido (lectores con prisa)
Eval: pipeline reproducible con dataset (golden set), runner, scorer y reporte que actúa como CI para la parte probabilística del sistema. Busca señales (factualidad, coherencia, formato), no igualdad exacta. Usa validación determinista, similitud de embeddings o un LLM-judge según el caso.
¿Qué son los evals; los unit test de los llms?
Un eval es un pipeline reproducible: un dataset de entradas y salidas (golden set), un runner que envia prompts al modelo, un scorer que compara la respuesta con criterios, y un reporte que te dice si rompiste algo. Piénsalo como CI para la parte probabilística del sistema.
A diferencia de un test unitario clásico, aquí no buscas igualdad exacta: buscas señales. Precisión factual, coherencia, formato JSON válido, ausencia de alucinaciones, y que el tono encaje con la interfaz. Todo eso se mide con métricas y reglas. Y sí: algunas veces el “juez” también es otro LLM.
Tipos prácticos de evaluadores (y cuándo usarlos)
Descripción breve de los enfoques más prácticos para evaluar salidas de LLMs y cuándo aplicarlos.
Determinista
Regex, validación de esquema (JSON Schema), comprobaciones de campo. Útil cuando la salida debe ser parseable. Ejemplo: validar que el LLM devuelva {"name": "...", "email": "..."}.
Semántico
Embeddings + similitud coseno. Ideal para summarization y Q&A donde importa el sentido, no la palabra exacta.
LLM-as-a-Judge
Un LLM potente evalúa las respuestas según una rúbrica. Sirve para tono, coherencia o seguridad, pero introduce sesgo y coste.
No mezcles métricas porque sí. Prioriza la que más impacta tu negocio: si tu app depende de JSON bien formado, la métrica principal es “JSON parseable + campos obligatorios”.
Herramientas y referencias prácticas
Empieza con herramientas que ya existen:
Estos proyectos te dan fixtures, runners y ejemplos para arrancar. No reinventes la rueda: adapta un benchmark a tu caso de uso.
Cómo montar tu primer eval (en 5 pasos reales)
Pasos concretos para crear un eval operativo.
1. Crea un dataset de 50–100 ejemplos representativos
Incluye casos comunes y edge cases que te aterran.
2. Define la métrica principal
Ej.: exact match para IDs, coseno>0.85 para respuestas semánticas, 0-1 score para seguridad.
3. Implementa el runner
Script que llama al LLM con el prompt actual y guarda outputs.
4. Añade el scorer
Validación JSON + embeddings o LLM-judge según necesites.
5. Integra en CI/CD
Si la puntuación baja del umbral, el pipeline falla y se bloquea el despliegue.
Resultado: antes de tocar el botón de deploy sabes si rompiste la experiencia.
Ejemplo corto: validar extracción de entidades en n8n
Tienes un workflow que extrae nombre, email y producto de emails entrantes. Tu eval debería:
- Enviar 200 emails sintéticos + reales.
- Comprobar que el JSON sea válido.
- Verificar que el campo email pase regex.
- Comparar entidades con embeddings para detectar ocasionalmente false negatives.
Si el score cae de 0.92 a 0.82 tras un cambio de prompt, no lo llames “variación normal”. Llama a la rollback.
Peligros reales (y cómo evitarlos)
- Data contamination: cuidado con ejemplos de test que el modelo ya vio en entrenamiento. Usa datos frescos.
- Varianza: ejecuta cada caso varias veces (n=3–5) y usa la media o el percentil.
- Métricas irrelevantes: BLEU o ROUGE por costumbre no te salvan; usa métricas alineadas con el objetivo del negocio.
- Juez sesgado: si usas un LLM como juez, documenta la rúbrica y haz validaciones humanas periódicas.
Punto para líderes técnicos
Los evals transforman subjetividad en trazabilidad. Permiten comparar coste vs. calidad (GPT-4o-mini vs. otro) con cifras, no con intuiciones. Integrar evals es un paso pequeño en esfuerzo y gigante en reducción de riesgos.
Haz esto ahora: crea un mini-eval con 50 ejemplos, añade una job en tu CI que ejecute el runner y falle si el score < 0.8. Si en 2 semanas no tienes alertas útiles, sube el umbral.
No es sexy. Es necesario. Y cuando el sistema falle a las 3 a.m., agradecerás haberlos hecho.
Dominicode Labs
Si trabajas con automatización, IA aplicada, n8n o workflows, puede interesarte explorar recursos adicionales en Dominicode Labs. Es una continuación lógica para prototipar mini-evals y automatizar runners en pipelines existentes.
FAQ
Preguntas frecuentes — haz clic en una pregunta para ir a la respuesta.
¿Qué es un eval?
Un eval es un pipeline reproducible que incluye un dataset (golden set), un runner que llama al modelo, un scorer que compara salidas según reglas o métricas y un reporte que indica si el rendimiento cumple el umbral esperado.
¿Cuándo usar evaluadores deterministas?
Usa evaluadores deterministas cuando la salida debe ser parseable y exacta (por ejemplo JSON con campos obligatorios). Validaciones por regex y JSON Schema son adecuadas en esos casos.
¿Por qué usar embeddings en evaluaciones semánticas?
Porque las tareas como summarization y Q&A requieren comparar significado, no coincidencia literal. Embeddings + similitud coseno capturan la proximidad semántica entre la salida y la referencia.
¿Cómo integrar evals en CI/CD sin frenar despliegues válidos?
Define umbrales claros y ejecuta las evaluaciones en una job separada. Si el score baja del umbral, falla la job y bloquea el despliegue. Ajusta el umbral basado en datos y monitoriza alertas para evitar falsos positivos.
¿Qué precauciones tomar si uso un LLM como juez?
Documenta la rúbrica, valida el juez con comparaciones humanas periódicas y considera el sesgo y coste. Guarda ejemplos y decisiones para auditoría.