1. Modelo mental
Un eval es una prueba repetible. Su objetivo no es producir un número bonito, sino detectar si un cambio mejora o empeora el comportamiento que importa. El eval debe parecerse al trabajo real y capturar también los fallos que más cuestan.
No existe una única métrica para todo. Exactitud puede ser binaria; calidad de redacción puede requerir rúbrica; retrieval necesita recall/precision; agentes necesitan medir también acciones, permisos y recuperación de errores.
La evaluación útil ocurre antes y después del lanzamiento. Antes decide si el sistema merece salir; después detecta regresiones cuando cambian prompts, modelos, fuentes o tráfico.
2. Conceptos que debes dominar
Entrada concreta con resultado esperado o criterios de evaluación.
Conjunto pequeño, revisado y representativo que usas como referencia estable.
Criterios y niveles que reducen la ambigüedad del juicio humano.
Condición clara para requisitos duros: JSON válido, cita presente, cálculo correcto.
Modelo que evalúa otra salida con una rúbrica; útil a escala, pero también necesita validación.
Empeoramiento que aparece después de cambiar modelo, prompt, herramienta o datos.
Subgrupo de casos: idioma, longitud, categoría, riesgo, cliente o tipo de documento.
Métrica observada con tráfico real: escalados, abandonos, correcciones o satisfacción.
3. Workflow paso a paso
Define el riesgo
Escribe qué error no puede ocurrir.
La rúbrica prioriza impacto, no estética.
Recoge casos reales
Incluye normales, difíciles y fallos históricos.
La muestra no está compuesta sólo por demos bonitas.
Anota expectativas
Para cada caso, define referencia o criterios.
Sabes por qué una salida pasa o falla.
Elige métricas
Combina métricas automáticas y juicio cuando haga falta.
Cada métrica responde a una decisión.
Construye baseline
Mide el sistema actual antes de cambiarlo.
Puedes comparar contra algo estable.
Ejecuta cambios aislados
Cambia una variable por experimento.
Sabes qué causó la mejora.
Analiza slices
No te quedes con la media.
Detectas grupos donde el sistema falla.
Fija gate
Define umbral para publicar y plan de rollback.
Un resultado insuficiente bloquea el release.
4. Ejemplo completo
Caso:asistente que responde preguntas sobre políticas internas.
| Criterio | Peso | Regla |
|---|---|---|
| Factualidad | 40% | La respuesta debe estar respaldada por fragmento recuperado. |
| Cita | 25% | Documento y sección correctos. |
| Completitud | 20% | Cubre todos los elementos de la pregunta. |
| Claridad | 15% | Acción siguiente comprensible. |
Añade casos sin respuesta en la base documental. Un sistema fiable debe saber decir “no tengo evidencia suficiente” en lugar de inventar.
5. Matriz de decisión
| Decisión | Qué mirar | Señal buena | Señal de riesgo |
|---|---|---|---|
| Métrica exacta | Hay respuesta determinista | Parser, test, igualdad | Usas un juez para algo verificable |
| Rúbrica humana | Calidad es contextual | Criterios y ejemplos | “Me gusta/no me gusta” |
| LLM judge | Necesitas escala | Correlaciona con humanos | Juez no validado |
| Online metric | Impacto real | Escalados, correcciones | Sólo optimizas offline |
| Slice analysis | Hay grupos heterogéneos | Métricas por categoría | La media oculta fallos graves |
6. Fallos y límites
Una guía útil también debe decir cuándo detenerse. Estos son los fallos que más cambian la calidad del resultado:
- Crear el eval después de elegir el ganador.
- Usar ejemplos de entrenamiento como evaluación.
- Cambiar modelo, prompt y retrieval al mismo tiempo.
- Optimizar una métrica proxy que no representa valor real.
- Dejar fuera casos sin respuesta o datos incompletos.
- Usar un juez LLM sin comprobar su acuerdo con humanos.
- No revisar resultados por slices.
- No versionar dataset, rúbrica y resultados.
7. Cómo medirlo
No midas sólo si “parece bueno”. Define una señal observable antes de escalar.
| Métrica | Qué mide | Cómo observarla | Umbral/alerta |
|---|---|---|---|
| Pass rate | Casos que pasan | Pasan/total | Bajo el gate acordado |
| Factualidad | Hechos correctos | Rúbrica/citas | Error crítico >0 |
| Retrieval recall | Evidencia recuperada | Top-k contiene respuesta | Cae por categoría |
| Coste/caso | Eficiencia | Tokens + revisión | Sube sin calidad |
| Latencia | Experiencia | p50/p95 | p95 supera SLA |
| Escalado humano | Autonomía segura | Escalados/total | Cae a costa de errores |
8. Checklist de producción
9. Ejercicios para convertir lectura en habilidad
- Crea un golden set de 20 casos de una tarea que haces.
- Escribe una rúbrica de cuatro criterios con 0/1/2 puntos.
- Compara juicio humano y juez LLM en diez ejemplos.
- Busca un caso donde la media sea buena pero un slice falle.
- Define qué métrica te haría revertir un cambio mañana.
10. Qué estudiar después
No intentes memorizar toda la IA. Encadena la siguiente pieza cuando resuelva una duda que ya has encontrado en la práctica.
Apéndice A · Preguntas que deberías poder responder
- ¿Qué parte del problema es determinista y cuál necesita juicio probabilístico?
- ¿Qué dato o ejemplo cambiaría tu decisión actual?
- ¿Cómo distinguirás una mejora real de una respuesta simplemente más convincente?
- ¿Qué ocurre cuando faltan datos, la herramienta falla o la respuesta es incierta?
- ¿Qué parte del proceso debe seguir bajo responsabilidad humana?
- ¿Qué coste operativo aparece después del primer prototipo?
- ¿Qué revisarías dentro de 30, 90 y 180 días para evitar que el sistema envejezca?
Si no puedes responder todavía a varias de estas preguntas, no significa que el proyecto esté mal: significa que has encontrado exactamente los huecos que la siguiente iteración debe cerrar. Ese es uno de los usos más valiosos de una guía técnica: convertir incertidumbre difusa en decisiones explícitas.
Apéndice B · Cuatro escenarios para practicar la decisión
Pregunta:Hay respuesta determinista.Señal favorable:Parser, test, igualdad.Alerta:Usas un juez para algo verificable.
Pregunta:Calidad es contextual.Señal favorable:Criterios y ejemplos.Alerta:“Me gusta/no me gusta”.
Pregunta:Necesitas escala.Señal favorable:Correlaciona con humanos.Alerta:Juez no validado.
Pregunta:Impacto real.Señal favorable:Escalados, correcciones.Alerta:Sólo optimizas offline.
No memorices la tabla como si fuera una regla universal. Cambia volumen, riesgo, disponibilidad, privacidad o coste y vuelve a recorrer la decisión. Un sistema robusto documenta qué variables sostienen la elección y cuáles podrían invalidarla.
Apéndice C · Cuaderno de campo para tu propio caso
Copia estas preguntas en un documento y complétalas con un caso real. El objetivo es que el conocimiento deje de estar en la página y pase a tu proceso.
- Problema¿Qué trabajo concreto intentas mejorar y para quién?
- Baseline¿Cómo se hace hoy, cuánto tarda y qué errores aparecen?
- Datos¿Qué entra, de dónde viene, quién puede verlo y qué no debería salir del entorno?
- Salida¿Qué formato y criterios convierten el resultado en usable?
- Prueba¿Qué 20–50 casos representarían el trabajo real?
- Riesgo¿Cuál es el fallo más costoso y cómo se detecta?
- Operación¿Quién observa, corrige, actualiza y puede detener el sistema?
- Revisión¿Qué evento o fecha obligará a reevaluar esta decisión?
Guarda también dos ejemplos que funcionaron y dos que fallaron. Con el tiempo, esos ejemplos se convierten en un pequeño dataset de evaluación mucho más útil que cualquier memoria informal de “esto parecía ir bien”.
Apéndice D · De prototipo a producción
Una demo responde a la pregunta “¿puede funcionar?”. Producción responde a otras: “¿funciona de forma repetible?”, “¿qué pasa cuando falla?”, “¿quién lo mantiene?”, “¿cómo sabemos que sigue siendo bueno dentro de tres meses?” y “¿podemos revertirlo?”. El salto entre ambas fases suele ser mayor que el salto entre dos modelos.
Antes de escalar, separa cuatro planos.Calidad:casos y métricas.Operación:latencia, cuotas, errores y costes.Gobernanza:permisos, datos, revisión y responsables.Cambio:versiones, fuentes y fechas de reevaluación. Si uno de estos planos no tiene dueño, el riesgo aparecerá precisamente cuando el uso crezca.
- Define un SLO de calidad y uno operativo.
- Registra versión de modelo, prompt, fuentes y configuración.
- Mantén una muestra estable para detectar regresiones.
- Añade un fallback para proveedor, herramienta o dato ausente.
- Decide qué errores se reintentan y cuáles se escalan.
- Presupuesta revisión humana, no sólo tokens.
- Evita permisos permanentes que sólo necesitabas para una prueba.
- Programa una revisión tras cambios de modelo, precio, política o dataset.
Finalmente, observa el sistema con tráfico real. Una mejora offline puede empeorar experiencia, coste o tasa de escalado. Las métricas de esta guía son el comienzo; adáptalas al impacto de tu caso y conserva siempre ejemplos concretos detrás de cada porcentaje.
Evals: convertir “me parece mejor” en una decisión reproducible
Una evaluación empieza por el workload, no por el benchmark. Construye casos que representen entradas normales, límites y fallos costosos. Si tu sistema procesa reclamaciones, incluye mensajes incompletos, contradictorios, largos, multilingües y con datos que no deben inferirse. Un conjunto pequeño pero realista suele ser más útil que cientos de ejemplos sintéticos homogéneos.
La rúbrica debe reflejar el impacto del error. Exactitud, cobertura, formato, seguridad, groundedness o utilidad no pesan igual en todos los casos. Para extracción puede existir ground truth exacto; para redacción puede ser necesaria una rúbrica humana; para respuestas con fuentes, puedes medir si cada claim está respaldado. Define antes de ejecutar para evitar adaptar el criterio al modelo que quieres que gane.
Los jueces LLM son útiles para escalar revisiones, pero también son modelos y pueden tener sesgos de estilo o preferencia. Calíbralos con ejemplos humanos y revisa desacuerdos. Para decisiones importantes, combina señales automáticas, pruebas deterministas y muestras humanas. El evaluador no debería convertirse en una segunda caja negra incuestionada.
Registra versión de modelo, prompt, parámetros, herramientas y dataset. Sin esa metadata no puedes reproducir una mejora ni explicar una regresión. Un resultado de 92% aislado carece de contexto; un 92% frente a 86% en el mismo conjunto, con coste y latencia conocidos, sí permite decidir.
Los evals deben vivir cerca del ciclo de cambio. Si cambias modelo, retrieval, instrucciones o una herramienta, vuelve a ejecutar. El objetivo no es obtener una medalla, sino detectar cuándo una modificación aparentemente pequeña rompe un comportamiento que ya funcionaba.
Una escala de madurez para evals: convertir “me parece mejor” en una decisión reproducible
Resuelve un caso real de principio a fin. Conserva entrada, salida y correcciones. Aquí buscas descubrir fallos, no automatizar.
La entrada y la salida ya tienen contrato, existen ejemplos límite y puedes medir calidad, tiempo y coste con el mismo criterio.
Hay observabilidad, permisos, fallback, responsable, revisión de cambios y un mecanismo para detectar regresiones antes de afectar al usuario.
La transición entre niveles debe estar motivada por evidencia. No pases a integración o autonomía sólo porque una demo salió bien. Pasa cuando hayas repetido la tarea con casos representativos, sepas dónde falla y el ahorro neto siga siendo positivo después de incluir revisión y operación.
Para los primeros 30 días, reúne ejemplos y construye el baseline. Entre 30 y 60 días, estabiliza el contrato de entrada/salida y convierte los fallos recurrentes en tests, checklist o reglas. Entre 60 y 90 días, si el volumen lo justifica, añade automatización, monitorización y revisión de costes. Si una etapa no supera sus propios criterios, mantén el sistema en la etapa anterior.
Documenta también las condiciones de salida: qué cambio de proveedor, política, precio, modelo, volumen o riesgo obligaría a reevaluar el diseño. Una arquitectura madura no pretende ser definitiva; hace explícito cuándo deja de ser válida.
Antes de considerar el trabajo terminado, realiza una revisión adversarial: busca deliberadamente entradas ambiguas, datos faltantes, instrucciones contradictorias, límites de cuota y resultados que parezcan correctos pero no puedan verificarse. El objetivo no es demostrar que el sistema funciona, sino descubrir bajo qué condiciones deja de funcionar y comprobar que esos fallos tienen una respuesta segura. Registra cada hallazgo y conviértelo en una prueba futura.
- Guarda al menos 20 casos reales, incluidos fallos.
- Define un criterio de aprobación que otra persona pueda aplicar.
- Separa métricas de calidad, coste y operación.
- Establece quién puede detener o revertir el sistema.
- Programa una fecha de revisión aunque nada parezca haber cambiado.
Documentación que sostiene y actualiza esta guía
Las capacidades y políticas cambian. Usa estas referencias para comprobar los puntos que dependan de un proveedor o de una versión concreta.