Tras el fine-tuning tienes un modelo nuevo. El benchmark en la tarea de entrenamiento ha subido. El equipo está contento. Pero cuando despliegas el modelo en producción, los clientes empiezan a reportar respuestas extrañas en casos que antes del entrenamiento funcionaban perfectamente. ¿Qué ha pasado? Ha pasado algo que vemos una y otra vez: el modelo se evaluó únicamente en lo que le enseñamos, no en lo que sin querer le desaprendimos.
Evaluar un modelo fine-tuneado es una disciplina distinta a evaluar un sistema LLM en producción. No comparas si tu pipeline RAG devuelve los chunks correctos — comparas qué ha hecho un cambio concreto de pesos en el modelo en su conjunto. Este artículo cubre cómo hacerlo de forma sistemática: desde el conjunto de eval específico de la tarea hasta la comparación base vs. fine-tuned, pasando por la detección de regresiones en capacidades generales.
Por qué "el loss bajó" no es suficiente
La pérdida de entrenamiento (training loss) te dice con qué precisión el modelo se adaptó a los datos de entrenamiento. No te dice nada sobre si el comportamiento del modelo en la práctica ha mejorado. Y desde luego no te dice qué le ha pasado al modelo fuera del dominio en el que entrenaste.
En la práctica vemos tres errores frecuentes:
- Evaluar solo sobre los datos de entrenamiento — el modelo ha memorizado patrones, no aprendido a generalizar
- Probar solo la tarea objetivo — ignorar las capacidades generales que el fine-tuning pudo dañar
- No comparar con el modelo base — no saber qué es beneficio del fine-tuning y qué era ya capacidad del modelo base
El olvido catastrófico (catastrophic forgetting) es un fenómeno real, documentado empíricamente en varias familias de modelos. El fine-tuning sobre datos de dominio estrecho puede degradar capacidades que el modelo adquirió durante el preentrenamiento — razonamiento lógico, formateo, seguimiento de instrucciones, conocimientos fuera del dominio. Los métodos PEFT como LoRA reducen este riesgo, pero no lo eliminan.
Las tres capas del framework de evaluación
Una evaluación sólida de un modelo fine-tuneado se asienta sobre tres capas. Cada una captura un riesgo distinto.
1. Conjunto de eval específico de la tarea
Esta es tu señal primaria. Mide si el modelo ha dominado aquello para lo que lo entrenaste.
Principio clave: held-out test set. Una parte de los datos etiquetados que el modelo nunca vio durante el entrenamiento debe reservarse exclusivamente para la evaluación final. Si usas los mismos datos para entrenamiento y evaluación, la medición no vale nada — el modelo pudo memorizar en lugar de aprender.
Procedimiento práctico: 1. Antes del entrenamiento, divide el dataset en entrenamiento / validación / test (p. ej., 80 / 10 / 10) 2. El conjunto de validación sirve para el seguimiento durante el entrenamiento (early stopping, ajuste de hiperparámetros) 3. El conjunto de test se usa una sola vez, cuando el entrenamiento ha terminado — nunca de forma iterativa para ajustar
Para la medición en sí necesitas una evaluación con respuesta correcta definida para tu tarea. Los formatos varían según el tipo de tarea:
- Clasificación / routing — accuracy, puntuación F1, confusion matrix
- Extracción de entidades / salida estructurada — F1 a nivel de token, exact match, o parser personalizado
- Tareas generativas — aquí se complica: BLEU/ROUGE tienen baja correlación con la calidad humana para LLM; son mejores el LLM-as-judge (un modelo frontier evalúa la respuesta) o rúbricas propias
Para la mayoría de los casos de uso B2B de dominio recomendamos construir 100–500 preguntas con respuestas de referencia elaboradas a mano y verificadas por un experto de dominio. Este es tu estándar de oro. La cantidad no es lo decisivo — lo decisivo es la cobertura de los tipos de casos y los edge cases más relevantes en la práctica.
2. Comparación base vs. fine-tuned
Evalúa el modelo fine-tuneado siempre en comparación con el modelo base, no solo en términos absolutos. El motivo: necesitas saber qué añadió realmente el fine-tuning respecto a lo que ya tenías de partida.
Una tabla de resultados típica debería incluir:
- Modelo base (sin fine-tuning) en tu test específico de la tarea
- Modelo fine-tuneado en el mismo test
- Delta (mejora o empeoramiento)
Si el modelo fine-tuneado supera al base en un marginal 2–3 %, valora críticamente si merece el coste de mantenimiento. Si el delta es negativo, tienes un problema — ya sea de calidad de datos o de configuración del entrenamiento.
La comparación también revela cuándo el fine-tuning no es la solución. Hemos visto casos en los que el modelo base con un prompt bien configurado (system prompt, ejemplos few-shot) alcanzó el 90 % de lo que lograba el modelo fine-tuneado — a coste cero de entrenamiento y sin riesgo de regresión. Para estos casos recomendamos a los clientes la decisión RAG vs. fine-tuning como primer paso antes del entrenamiento.
3. Regresión en capacidades generales
Esta es la capa que la mayoría de los equipos omite — y es precisamente aquí donde se esconden los problemas que no salen a la luz hasta producción.
El fine-tuning en un dominio estrecho puede dañar:
- El seguimiento de instrucciones — el modelo empieza a ignorar partes del prompt o a cambiar el formato de la respuesta
- El rechazo a responder preguntas fuera del dominio — el modelo intenta responder desde el dominio incluso ante preguntas donde lo correcto sería decir "no sé"
- El razonamiento lógico — los resultados en tareas de razonamiento pueden caer
- Las capacidades lingüísticas — si entrenaste en un idioma, otros idiomas pueden degradarse
Para detectar regresiones usamos una combinación de enfoques:
a) Benchmarks estándar como sanity check
lm-evaluation-harness de EleutherAI permite ejecutar el modelo en benchmarks estándar (MMLU y similares). No esperes que el modelo fine-tuneado supere al base en MMLU — ese no es el objetivo. Lo que vigilas es que no haya bajado significativamente (más de unos pocos puntos es motivo de investigación).
b) Conjunto de regresión de comportamiento (behavioral regression set)
Crea tu propio conjunto de ejemplos que cubra capacidades importantes para tu aplicación, pero que no esté directamente relacionado con el dominio de entrenamiento. Por ejemplo: - Formateo de salida (JSON, Markdown, tablas) - Rechazo de preguntas sin sentido - Seguimiento de instrucciones (seguir múltiples condiciones en el prompt) - Precisión factual en áreas fuera del dominio
Este conjunto puedes montarlo una vez y reutilizarlo en cada nueva ronda de fine-tuning. La inversión se amortiza en la tercera y cuarta ronda, cuando sin él pierdes la visión de conjunto.
c) Comparación de la distribución de respuestas
Enfoque pragmático: toma 200–500 entradas reales de producción (o de staging), ejecútalas en el modelo base y en el fine-tuneado, y compara la distribución de longitud de respuestas, la frecuencia de rechazos y — si tienes LLM-as-judge configurado — la distribución de puntuaciones. Las desviaciones estadísticas señalan el problema antes de que lo reporten los usuarios.
Configurar el held-out test set: dónde nos equivocamos
El held-out test set suena sencillo, pero en la práctica falla en varios puntos.
Contaminación de distribución: si generaste datos de entrenamiento de forma sintética (modelo teacher) y el test set lo generaste también con el mismo proceso, estás midiendo únicamente con qué fidelidad el modelo imita al teacher — no con qué eficacia resuelve la tarea real. El test set debe proceder de casos reales o estar verificado por un experto de dominio.
Separación temporal: en sistemas de producción con fine-tuning periódico es crítico que el test set esté separado temporalmente del conjunto de entrenamiento. Si entrenas con datos del Q1 y testeas con datos del Q1 (aunque sea un subconjunto separado), puedes no detectar el desplazamiento de distribución que se producirá en el Q2. Lo ideal es que el test set provenga de una ventana temporal distinta a la del entrenamiento.
Tamaño y representatividad: un test set de 50 ejemplos es demasiado pequeño para extraer conclusiones estadísticamente fiables en la mayoría de las tareas. Para clasificación binaria necesitas del orden de 300–500 ejemplos para que el intervalo de confianza al 95 % sea lo suficientemente estrecho como para tomar decisiones. Para tareas generativas con LLM-as-judge funcionan conjuntos más pequeños, pero interpreta los resultados con precaución.
Fuga por augmentación: si usaste paráfrasis o variaciones de ejemplos reales para augmentar los datos de entrenamiento, verifica que ninguna variante haya llegado al test set.
Pipeline de evaluación práctico paso a paso
Para equipos que hacen fine-tuning por primera vez o de forma esporádica, recomendamos este procedimiento minimalista:
- 1.Antes del entrenamiento: reserva el test set (mínimo el 10 % de los datos, nunca lo uses en el entrenamiento), registra el score baseline del modelo base en el eval específico de la tarea y en el behavioral regression set.
- 1.Durante el entrenamiento: monitoriza la pérdida de validación (val loss) — debería bajar junto con la pérdida de entrenamiento. Si el val loss se estanca o sube mientras el train loss baja, estás sobreentrenando el modelo. Detén el entrenamiento y prueba con menos epochs o un
rankmayor del adaptador.
- 1.Tras el entrenamiento: ejecuta el modelo en el test set específico de la tarea. Compara con el modelo base. Ejecuta el behavioral regression set. Compara con el modelo base.
- 1.Antes del despliegue: LLM-as-judge sobre una muestra de entradas reales (si las tienes). Revisión manual de al menos 20–30 casos concretos — los números engañan; leer las respuestas revela patrones que las métricas no ven.
Todo este pipeline puedes encuadrarlo con herramientas como lm-evaluation-harness, un script Python propio sobre vLLM u Ollama, o plataformas de eval en la nube. Para la mayoría de los proyectos B2B a medida, un script propio es suficiente — no sobrestimes la infraestructura cuando lo que necesitas es una respuesta fiable a la pregunta "¿es el modelo mejor?".
Cuándo la regresión es demasiado grande para aceptarla
No existe un umbral universal. Depende del caso de uso. Algunas reglas orientativas:
La mejora específica de la tarea debe superar la regresión en capacidades generales. Si el fine-tuning mejoró la precisión en el dominio en 15 puntos, pero el seguimiento de instrucciones cayó un 20 %, el resultado es negativo — un formato de respuesta incorrecto hace al modelo menos útil precisamente en el dominio que intentabas mejorar.
Cero mejora en el test específico de la tarea es motivo para parar. Si el modelo base con un prompt few-shot alcanza los mismos resultados que el modelo fine-tuneado, el fine-tuning no era necesario. Esto lo vemos con clientes más a menudo de lo que cabría esperar — subestiman lo que puede hacer un buen prompt.
Una regresión pronunciada en el rechazo de preguntas fuera del dominio es un problema grave. Un modelo entrenado para responder consultas técnicas sobre un producto concreto no debe empezar a alucinar respuestas también ante preguntas donde la respuesta correcta sería "esto no lo sé". Esta regresión es un riesgo de seguridad directo en sectores regulados. Está relacionada con la temática de guardrails para agentes de IA, donde el mecanismo de rechazo es la primera línea de defensa.
Evaluación continua: cuando repites el fine-tuning
Los modelos de dominio no se tunan una sola vez — si lo haces bien, cada nueva ronda de datos traerá una nueva ronda de fine-tuning. En ese caso la evaluación sistemática es aún más importante, porque necesitas seguir la tendencia a lo largo de las iteraciones, no solo los números absolutos.
Recomendamos mantener un registro sencillo de cada ronda: - Fecha del entrenamiento y versión del modelo (base + fine-tuned) - Tamaño del conjunto de entrenamiento y fuente de datos - Score específico de la tarea (base / fine-tuned / delta) - Score del behavioral regression set - Notas sobre anomalías o revisión manual
Este registro es una inversión que se recupera cuando hay que depurar una regresión en el sistema de producción. Sin él, el equipo sabe que "algo cambió tras el último entrenamiento" — pero no sabe qué, cuándo ni por qué.
Para los equipos que planean fine-tuning periódico con un ciclo inferior a un mes, merece la pena plantearse un pipeline de evaluación automatizado — cada commit de un nuevo modelo lanza automáticamente el eval específico de la tarea y el regression set, y registra los resultados. Este nivel de inversión tiene sentido en sistemas de producción donde el modelo está directamente en la cadena de interacciones con clientes.
Preguntas frecuentes
¿Cuántos ejemplos necesito en el test set?
Para la mayoría de las tareas B2B de dominio recomendamos un mínimo de 100–300 ejemplos verificados manualmente. Por debajo de 100 la fiabilidad estadística es baja — un dataset pequeño dificulta distinguir una mejora real de la varianza aleatoria. Para clasificación binaria, 300–500 es un límite inferior razonable para un intervalo de confianza al 95 %. Para tareas generativas con LLM-as-judge puedes trabajar con conjuntos más pequeños, pero interpreta con mayor precaución.
¿Qué es LLM-as-judge y cuándo usarlo?
LLM-as-judge es una técnica en la que un modelo frontier (p. ej., de la familia Claude Sonnet o GPT) evalúa las respuestas del modelo fine-tuneado según criterios definidos — precisión, relevancia, formato, tono. Es útil para tareas generativas donde no existe una "respuesta correcta" unívoca. Desventajas: añade coste (llamadas API) y el judge puede tener sus propios sesgos (prefiere respuestas más largas, estilo formal). Para aplicaciones B2B de dominio recomendamos la combinación: LLM-as-judge para la calidad global + métricas deterministas (exact match, parser) para los campos críticos.
¿Cómo detectar el olvido catastrófico sin un conjunto de benchmarks complejo?
Procedimiento pragmático: toma 50–100 prompts reales que el modelo gestionaba correctamente antes del fine-tuning y verifica que los siga gestionando después del entrenamiento. Si tienes acceso a los logs del sistema de producción, observa los ejemplos con alta valoración de los usuarios — son una buena fuente para el behavioral regression set. Combinado con una revisión manual rápida de 20–30 respuestas, se detecta la mayoría de los problemas antes de que lleguen al cliente.
¿Por qué baja el val loss pero la calidad de las respuestas no mejora?
Caso clásico de overfitting o desajuste de distribución entre el entrenamiento y el uso real. La pérdida de validación baja cuando el modelo ajusta mejor el conjunto de validación — pero si ese conjunto no refleja las entradas reales, esa pérdida es un proxy incorrecto de la calidad real. Otra causa: un learning rate o rank del adaptador demasiado bajos, de modo que el modelo solo aprende patrones superficiales. Prueba a aumentar el rank (p. ej., de 8 a 16 o 32) y verifica que el conjunto de validación sea representativo. Tema relacionado: por qué falla el fine-tuning.
¿Cuándo tiene sentido repetir el fine-tuning en lugar de usar RAG?
Repite el fine-tuning si el dominio se ha estabilizado y tienes un flujo constante de nuevos ejemplos etiquetados procedentes de producción. Si el conocimiento del dominio cambia rápido (nuevos productos, regulaciones modificadas), RAG es más flexible — el cambio se escribe en la base de conocimiento, no en los pesos del modelo. Para decidir sobre la combinación de ambos enfoques, consulta el dataset para fine-tuning — cuánto y de qué calidad.
*Si estás considerando hacer fine-tuning de tu propio modelo y no sabes cómo configurar el proceso de evaluación, estaremos encantados de revisar tu caso de uso concreto. En MP Industrial Solutions ayudamos a las empresas a diseñar todo el pipeline desde los datos y el entrenamiento hasta la evaluación — para que antes del despliegue en producción sepas exactamente qué es lo que el modelo realmente domina.*