Entrenaste un , la pérdida bajó y un par de respuestas se ven bien. ¿Mejoró el modelo? Con eso no lo sabes. La pérdida de mide cuánto se ajustó a los ejemplos que ya vio, y tres respuestas elegidas a mano no son evidencia. En software tradicional un test pasa o falla; con modelos, la salida es probabilística y "correcta" suele ser una cuestión de grado.
Evaluar es construir la evidencia que responde tres preguntas: ¿funciona en casos que no vio?, ¿es mejor que lo que ya teníamos?, ¿es suficientemente bueno para salir? Veamos las herramientas para responderlas y cómo convertirlas en una regla que bloquee un despliegue.
Por qué evaluar
Sin evaluación, cada cambio (otro , otro , más datos, otro ) es una apuesta. Una evaluación útil tiene cuatro partes:
- Datos que el modelo no usó para aprender.
- Una referencia contra la que comparar ().
- Una métrica que capture lo que importa para la tarea.
- Un umbral que convierta el número en una decisión.
Held-out y fugas
El conjunto held-out (o de validación/test) se separa antes de entrenar y el modelo nunca aprende de él. Si evalúas con los mismos ejemplos del entrenamiento, mides memoria, no (ver Machine learning en una lección).
La fuga de datos (leakage) es más sutil que reutilizar filas:
- Casi duplicados: el mismo ticket con otra fecha en train y en test.
- Plantillas compartidas: si todas las respuestas siguen una frase fija, el test mide si aprendió la frase.
- Contaminación del base: un benchmark público pudo estar en el preentrenamiento del modelo.
- Orden del archivo: si el dataset está ordenado por etiqueta y separas "el último 20 %", el test puede tener una sola clase.
Baselines y métricas
Un número aislado no dice nada. 0,33 puede ser excelente o pésimo según lo que obtenga el modelo sin tu cambio. Compara siempre contra el modelo base con el mismo prompt, sobre el mismo held-out, y cuando exista, contra la versión actual en producción.
| Métrica | Sirve para | Cuidado con |
|---|---|---|
| Exact match / accuracy | Clasificación, etiquetas | Normalizar mayúsculas y espacios |
| Validez + campos exactos | Extracción a JSON | Distinguir JSON inválido de campo erróneo |
| F1 de tokens, ROUGE | Respuestas cortas, resúmenes | Premia coincidencia léxica, no verdad |
| Similitud por embeddings | Paráfrasis aceptables | Textos que dicen lo contrario pueden parecerse |
| Pérdida / perplejidad | Señal intrínseca sin etiquetas de tarea | No dice si la respuesta es útil |
| LLM-as-judge | Criterios abiertos (tono, fidelidad) | Sesgos del juez |
LLM-as-judge
Usar un modelo para calificar respuestas escala bien, pero el juez tiene sesgos conocidos: prefiere la primera opción en comparaciones (sesgo de posición), las respuestas más largas (verbosidad) y el estilo de su propia familia de modelos (autopreferencia). Mitigaciones: rúbricas concretas, alternar el orden, calibrar el juez contra una muestra etiquetada por personas y no usar el mismo modelo como generador y juez.
El eval gate
Un convierte la evaluación en un bloqueo de despliegue: si el candidato no supera la regla, no se publica. No es un reporte que alguien puede ignorar, es un paso del pipeline que falla.
La regla está en passes_eval_gate (adapta/training/models.py); este es su final, textual:
if score >= threshold:
return True
if base_score is not None and score_delta is not None:
return score >= min_floor and score_delta >= min_improvement
return False
Es decir: pasa si score ≥ 0.6, o si score ≥ 0.05 y supera al base por al menos 0,05 puntos absolutos. La segunda vía existe porque un modelo pequeño difícilmente llega a 0,6 de exp(−pérdida) aunque haya aprendido la tarea. Si la comparación con el base falla, solo queda la vía absoluta.
Para CTOs
- Define la regla antes de entrenar. Qué métrica, contra qué baseline y con qué umbral. Escríbela en código, no en una wiki.
- Exige un control negativo. Si datos basura pasan tu gate, el gate no protege nada.
- Dueño del . Alguien del negocio debe mantener los casos de evaluación; sin eso, el gate mide un problema que ya no existe.
- Umbral como decisión de riesgo. Subirlo bloquea más candidatos buenos; bajarlo deja pasar malos. Es una decisión de negocio con consecuencias técnicas.
RAG y evaluación en producción
En RAG hay dos cosas que medir por separado, porque fallan por razones distintas:
pregunta ──► recuperación ──► contexto ──► generación ──► respuesta
recall@k, MRR fidelidad, relevancia
- Recuperación: con un golden set de preguntas y el documento esperado, mide recall@k (¿está el correcto entre los k primeros?) y MRR (qué tan arriba aparece).
- Respuesta: fidelidad (¿cada afirmación está respaldada por el contexto?) y relevancia (¿responde la pregunta?). Ragas popularizó estas métricas, calculadas en general con un como juez.
Offline y online
La evaluación offline usa datasets fijos antes de desplegar: es reproducible y barata, pero solo cubre los casos que imaginaste. La evaluación online mide en producción: pruebas A/B, tráfico en sombra, feedback explícito, tasa de reintentos o de escalamiento a un humano. Ambas se complementan, y los fallos que aparecen en producción deberían volver al golden set offline. Para , que añaden herramientas y varios pasos, ver Testing y evals para agentes.
Para llevar
- Evalúa en datos que el modelo no vio y cuida las fugas, incluidas las de orden y plantillas.
- Compara siempre contra un baseline sobre el mismo conjunto.
- Elige la métrica según la tarea; la perplejidad no reemplaza una métrica de tarea.
- Un gate es una regla en código que bloquea el despliegue, con un control negativo que demuestra que bloquea.
- En RAG, mide recuperación y respuesta por separado.
Comprueba lo aprendido
En Adapta, un adapter obtiene score 0,30 y el base 0,20 sobre el mismo held-out. ¿Pasa el gate?
Sí, por la vía de mejora: 0,30 ≥ 0,05 y el delta 0,10 ≥ 0,05, aunque no alcance el 0,6 absoluto.
¿Por qué evaluar sobre las filas de entrenamiento no sirve para decidir un despliegue?
Porque mide cuánto memorizó el modelo, no cómo se comporta con entradas nuevas, que es lo que ocurrirá en producción.
Un juez LLM prefiere sistemáticamente las respuestas más largas. ¿Cómo lo mitigas?
Con una rúbrica concreta que no premie la extensión, calibrando el juez contra una muestra etiquetada por personas y revisando si el puntaje se correlaciona con la longitud.