Evaluar modelos

Entrenaste un adapterAdapter Conjunto pequeño de pesos extra que se entrenan y se agregan a un modelo que por lo demás no cambia, para modificar su comportamiento sin reentrenarlo entero., las cifras de entrenamientoEntrenamiento Ajustar los pesos de un modelo a partir de datos para que sus predicciones mejoren. mejoraron y un par de respuestas se ven bien. ¿El modelo mejoró? No lo puedes saber. Las cifras de entrenamiento solo muestran qué tan bien se ajusta a ejemplos que ya vio, y unas pocas respuestas elegidas a mano no son evidencia. A diferencia de un test de software, la salida de un modelo varía, y "correcto" suele ser cuestión de grado.

Evaluar responde tres preguntas: ¿funciona en casos que nunca vio?, ¿es mejor que lo que teníamos?, ¿es lo bastante bueno para salir a producción? Esta lección cubre qué necesita una evaluación, cómo se filtran los datos de prueba, cómo elegir un baselineBaseline Resultado de referencia que un modelo o cambio nuevo debe superar para contar como mejora. y una métrica, cómo convertir el resultado en una regla que bloquee una mala entrega y cómo evaluar un sistema RAGRAG Retrieval-augmented generation: encontrar pasajes relevantes en tus documentos y agregarlos al prompt antes de que el modelo responda..

Qué necesita una evaluación

Sin evaluación, cada cambio es una apuesta. Una evaluación útil tiene cuatro partes:

1. Datos de los que el modelo no aprendió.
2. Un punto de referencia, o baseline, contra el cual comparar.
3. Una métrica que capture lo que importa para la tarea.
4. Un umbral que convierta el número en una decisión.

Los datos de prueba y cómo se filtran

Un estudiante que vio el examen antes no demuestra nada con una nota perfecta. Con los modelos pasa lo mismo. Antes de entrenar, una parte de los datos se aparta como conjunto held-out (reservado), y el modelo nunca aprende de él; puntuar con ejemplos de entrenamiento mide memoria, no capacidad (Machine learning en una lección).

El examen también puede filtrarse de formas más sutiles, lo que se llama fuga de datos (data leakage):

• Casi duplicados: el mismo ticket, con otra fecha, tanto en los datos de entrenamiento como en los de prueba.
• Plantillas compartidas: si todas las respuestas siguen una misma frase fija, la prueba solo verifica esa frase.
• Contaminación: un benchmark público pudo estar en los datos de entrenamiento originales del modelo.
• Orden del archivo: si las filas están ordenadas por etiqueta y apartas el último 20%, la prueba puede tener una sola categoría.

Baselines y métricas

Un número solo no dice nada: 0,33 puede ser excelente o pésimo según lo que obtienes sin tu cambio. Compara siempre contra el modelo baseModelo base Modelo tras su primer entrenamiento general, que solo continúa texto y todavía no fue ajustado para seguir instrucciones., con las mismas instrucciones y el mismo conjunto de prueba, y, si existe, contra la versión en producción. Luego, la métrica depende de la tarea:

LLMLLM Large language model: red neuronal entrenada para predecir el siguiente token y ajustada para seguir instrucciones.-as-judge significa pedirle a un modelo que califique respuestas. Escala bien, pero los jueces favorecen la primera opción que ven, las respuestas más largas y el estilo de su propia familia de modelos. Para contrarrestarlo: una rúbrica concreta, alternar el orden, contrastar al juez con una muestra calificada por personas y nunca dejar que un mismo modelo responda y juzgue.

El eval gate

Un eval gateEval gate Verificación automática que impide publicar un modelo o cambio si no aprueba una evaluación. convierte la evaluación en una barrera: si un candidato no cumple la regla, no sale. No es un informe que alguien puede ignorar, sino un paso del pipeline que falla.

Evaluar un sistema RAG

Un sistema RAG busca en tus documentos y luego responde a partir de lo que encontró (Embeddings y RAG). Mide los dos pasos por separado; fallan por razones distintas.

• Búsqueda: con un conjunto de preguntas y el documento que cada una debería encontrar, verifica si el correcto aparece entre los primeros resultados (recall@k) y qué tan arriba queda (MRR).
• Respuesta: verifica la fidelidad (¿cada afirmación está respaldada por lo encontrado?) y la relevancia (¿responde la pregunta?). Ragas popularizó estas métricas, que suelen calificarse con un LLM como juez.

Todo lo anterior es evaluación offline: datos fijos antes de salir, barata y repetible, pero limitada a los casos que se te ocurrieron. La evaluación online observa el uso real: pruebas A/B, comentarios de usuarios, cuántas veces la gente reintenta o pide hablar con una persona. Las fallas encontradas en producción deberían convertirse en nuevos casos de prueba offline. Para agentesAgente Sistema en el que un modelo, dentro de un bucle, elige la siguiente acción hasta decidir que terminó o alcanzar una condición de parada., ver Testing y evals para agentes.

En la práctica

• Fija la regla antes de entrenar: qué métrica, contra qué baseline, con qué umbral. Ponla en código, no en una wiki.
• Corre un control negativo. Si un dataset sin patrón pasa tu gate, el gate no protege nada.
• Dales un responsable a los casos de prueba, cercano al negocio, o el gate terminará midiendo un problema viejo.
• Trata el umbral como una decisión de riesgo. Subirlo bloquea más candidatos buenos; bajarlo deja pasar más malos.

Para profundizar

La documentación de Adapta explica su evalEval Medición de qué tan bien se comporta el sistema completo en casos realistas, incluidos los pasos que dio en el camino, calificada con verificaciones imperfectas y leída con estadística. gate en detalle y registra resultados reales (en inglés):

• Learning the system tiene una sección sobre el eval gate: las filas apartadas, cómo se calcula el puntaje y por qué hay dos formas de aprobar.
• Fine-tuning use cases lista resultados del gate para varias tareas junto al puntaje del modelo base, incluido un control negativo que queda bloqueado, y advierte que un puntaje casi perfecto no prueba calidad.
• Fine-tuning, proven lee línea por línea un resultado real del gate, desde el puntaje hasta la comparación con el modelo base.

Para llevar

• Evalúa con datos que el modelo nunca vio, y cuida las fugas silenciosas como el orden del archivo o las plantillas compartidas.
• Compara contra un baseline en el mismo conjunto de prueba, con una métrica elegida para la tarea.
• Un eval gate es una regla en código que bloquea la salida, y un control negativo demuestra que bloquea.
• En RAG, mide por separado la calidad de la búsqueda y la de la respuesta.

Comprueba lo aprendido