Como Evaluar Tu Modelo Ajustado: Una Guia No Tecnica

Ajustaste un modelo. El entrenamiento se completo sin errores. La curva de perdida bajo. Y ahora que?

La mayoria de los equipos envian a produccion en este punto. Ejecutan algunos prompts manualmente, las salidas se ven razonables y el modelo va a produccion. Dos semanas despues, un cliente reporta que el modelo esta alucinando funcionalidades del producto que no existen, o formateando respuestas de una manera que rompe la integracion posterior.

El problema no es el modelo. El problema es que "se ve razonable" no es una estrategia de evaluacion.

La evaluacion es el paso mas omitido en el pipeline de fine-tuning. Tambien es el paso que determina si tu modelo realmente funciona en produccion o solo funciona en tu demo. Esta guia te da cinco enfoques practicos de evaluacion que requieren cero experiencia en ML — solo conocimiento del dominio y disposicion a ser sistematico al respecto.

Por Que la Evaluacion Importa Mas Que el Entrenamiento

Aqui hay un numero que sorprende a la mayoria de los equipos: un modelo puede lograr metricas de entrenamiento excelentes y aun asi fallar en el 15-30% de las consultas reales de produccion. El training loss mide que tan bien el modelo aprendio tus datos de entrenamiento. No mide que tan bien el modelo maneja entradas que nunca ha visto.

Para agencias entregando modelos a clientes, la brecha entre "entrenado exitosamente" y "funciona en produccion" es donde las reputaciones se construyen o se destruyen. Una sola falla de alto perfil — una AI legal citando un estatuto inexistente, un bot de salud dando informacion de dosificacion incorrecta — puede deshacer meses de construccion de relacion.

La evaluacion no es un paso de calidad deseable. Es la diferencia entre un modelo por el que puedes facturar con confianza y un modelo que esperas que funcione.

Enfoque 1: Muestreo con Revision Humana

El metodo de evaluacion mas simple y mas subestimado. Toma 50-100 entradas representativas de tu trafico de produccion esperado, pasalas por el modelo y haz que un experto de dominio revise cada salida.

Como hacerlo:

1. Recopila 50-100 entradas que representen tu caso de uso real. Si el modelo maneja soporte al cliente, usa tickets de soporte reales. Si genera resumenes legales, usa expedientes de casos reales.
2. Pasa cada entrada por tu modelo ajustado y captura la salida.
3. Haz que alguien con conocimiento del dominio califique cada salida en una escala simple: Correcto, Parcialmente Correcto o Incorrecto.
4. Calcula tu tasa de precision. Para la mayoria de los casos de uso en produccion, quieres 90%+ Correcto y menos de 5% Incorrecto.

Que detecta esto: Errores sistematicos que las metricas automatizadas omiten. Un modelo puede puntuar bien en perplexity pero consistentemente usar mal la terminologia especifica de la industria. Los revisores humanos detectan esto inmediatamente.

El minimo de 50 ejemplos: Por debajo de 50 ejemplos, tu estimacion de precision tiene demasiada varianza para ser util. Con 50 ejemplos, si ves 45 salidas correctas, tu precision real probablemente esta entre 82% y 97% (intervalo de confianza del 95%). Con 100 ejemplos, ese rango se estrecha a 87-96%. Mas ejemplos te dan mas confianza, pero 50 es el piso para una senal significativa.

Consejo profesional: No dejes que la persona que preparo los datos de entrenamiento haga la evaluacion. Estan demasiado cerca de las salidas esperadas y inconscientemente calificaran los casos limites como correctos. Ojos frescos detectan mas problemas.

Enfoque 2: Comparacion A/B Contra Baseline

La comparacion lado a lado es una de las tecnicas de evaluacion mas informativas, y no requiere conocimiento estadistico.

Como hacerlo:

1. Elige tu baseline. Puede ser el modelo base antes del fine-tuning, un GPT-4 con prompts, o tu version anterior del modelo.
2. Pasa las mismas 50-100 entradas de prueba por ambos modelos.
3. Presenta las salidas lado a lado a un revisor (a ciegas — no etiquetes cual es cual).
4. Para cada par, el revisor elige cual salida es mejor, o las marca como iguales.
5. Cuenta victorias, derrotas y empates.

Interpretando resultados: Tu modelo ajustado deberia ganar al menos el 60% de las comparaciones directas contra el modelo base para justificar el despliegue. Si gana menos del 50%, algo salio mal en el entrenamiento. Si gana 50-60%, el fine-tuning produjo una mejora marginal — considera si el costo operacional de mantener un modelo personalizado vale la pena.

Que detecta esto: Regresion. El fine-tuning puede mejorar el rendimiento en tu tarea objetivo mientras degrada las capacidades generales. La comparacion A/B revela si el modelo mejoro en tu tarea especifica pero empeoro en razonamiento basico, gramatica o seguimiento de instrucciones.

Un modo de fallo comun: el modelo ajustado clava el formato de salida perfectamente pero la calidad del contenido cae. Sin comparacion lado a lado, podrias no notarlo porque las salidas se ven bien a primera vista.

Enfoque 3: Conjunto de Prueba Dorado

Un conjunto de prueba dorado es una coleccion curada de entradas con salidas conocidas como correctas. Es lo mas cercano a una suite de tests unitarios para tu modelo.

Como construir uno:

1. Comienza con 30-50 ejemplos que cubran tus casos de uso principales.
2. Para cada ejemplo, escribe la salida ideal — la respuesta exacta que quieres que el modelo produzca.
3. Incluye niveles de dificultad: 60% casos directos, 25% complejidad moderada, 15% casos limite dificiles.
4. Almacena esto como un archivo versionado (JSONL funciona bien) que nunca uses para entrenamiento.

Como puntuarlo:

Para tareas de clasificacion, la precision es directa — el modelo elige la categoria correcta o no. Para tareas de generacion, la puntuacion requiere mas matiz:

• Tasa de coincidencia exacta: Que porcentaje de salidas coinciden exactamente con la respuesta dorada? Util para salidas estructuradas como JSON o etiquetas de categoria.
• Tasa de coincidencia semantica: Que porcentaje son funcionalmente equivalentes aunque esten redactados diferente? Requiere juicio humano.
• Inclusion de hechos clave: Para tareas factuales, lista los 3-5 hechos que cada respuesta debe incluir. Puntua el porcentaje de hechos requeridos presentes.

La regla critica: Nunca entrenes con tu conjunto de prueba dorado. En el momento en que los ejemplos de prueba se filtran en los datos de entrenamiento, tu evaluacion se vuelve sin sentido. Mantiene estos archivos separados y audita regularmente para asegurar que no haya contaminacion.

Mantenimiento en el tiempo: Agrega 5-10 nuevos ejemplos mensuales de fallos reales de produccion. Los casos donde el modelo se equivoco en produccion son los casos de prueba mas valiosos porque representan brechas reales.

Enfoque 4: Bateria de Casos Limite

Los casos limite son donde los modelos ajustados fallan mas dramaticamente. Un modelo puede manejar el 95% de consultas estandar perfectamente y desmoronarse completamente en el 5% restante — y ese 5% son frecuentemente los casos que los clientes recuerdan.

Construye tu bateria de casos limite alrededor de estas categorias:

Entradas ambiguas. Consultas que podrian interpretarse de multiples maneras. Un modelo bien comportado deberia pedir aclaracion o manejar la interpretacion mas probable mientras reconoce alternativas.

Entradas fuera de alcance. Consultas que el modelo no deberia responder. Si ajustaste un resumidor de documentos legales, que sucede cuando alguien le pide que escriba copy de marketing? El modelo deberia declinar gracilmente, no alucinar una respuesta.

Entradas adversariales. Entradas disenadas para romper el modelo — intentos de inyeccion de prompt, entradas extremadamente largas, entradas en idiomas inesperados, entradas con informacion contradictoria. Necesitas 10-20 de estas.

Condiciones limite. Entradas en los extremos de tu rango esperado. La entrada valida mas corta posible. La mas larga. Entradas con formato inusual. Entradas que combinan multiples sub-tareas.

Como ejecutarlo:

Crea una hoja de calculo con 30-50 casos limite a traves de estas categorias. Para cada uno, define el comportamiento esperado (no necesariamente una salida especifica, sino que categoria de respuesta es aceptable). Pasalos por el modelo y marca cualquier caso donde el comportamiento sea inesperado.

Criterios de aprobacion: Cero fallos catastroficos (sin salidas ofensivas, sin consejos peligrosos, sin filtracion de datos). Manejo gracil de al menos el 80% de los casos limite. Modos de fallo identificados documentados para comunicacion con el cliente.

Enfoque 5: Monitoreo en Produccion

La evaluacion no termina en el despliegue. La evaluacion mas importante sucede en produccion, donde los usuarios reales generan entradas que nunca anticipaste.

Que monitorear:

• Distribucion de longitud de salida. Un cambio repentino en la longitud promedio de salida frecuentemente senala un problema. Si tu modelo tipicamente genera respuestas de 200 palabras y comienza a producir respuestas de 50 palabras, algo cambio.
• Tasa de rechazo. Rastrea con que frecuencia el modelo declina responder. Un pico en rechazos podria indicar que el modelo esta siendo demasiado conservador, o que esta recibiendo entradas fuera de distribucion.
• Latencia por solicitud. Los modelos ajustados deberian tener un tiempo de inferencia consistente. Los picos de latencia pueden indicar problemas de manejo de entradas.
• Senales de retroalimentacion del usuario. Si tu aplicacion incluye like/dislike o comportamiento de reintento, rastrealo. Una tasa de reintento superior al 15% sugiere que los usuarios no estan satisfechos con las salidas del primer intento.
• Tasa de error por categoria de entrada. Desglosa el rendimiento por tipo de consulta. Podrias encontrar que el modelo maneja la categoria A perfectamente pero tiene dificultades con la categoria B — informacion que impulsa tu proxima recoleccion de datos de entrenamiento.

Muestreo para revision continua: Incluso despues del despliegue, extrae 20-30 salidas de produccion aleatorias semanalmente para revision humana. Esto detecta degradacion lenta que las metricas automatizadas omiten. Si tu precision semanal cae por debajo de tu baseline, investiga inmediatamente.

Errores Comunes de Evaluacion

Error 1: Evaluar con datos de entrenamiento. Si tus ejemplos de prueba se superponen con los ejemplos de entrenamiento, tus numeros de precision no tienen sentido. El modelo no esta demostrando generalizacion — esta demostrando memorizacion.

Error 2: Evaluar solo entradas de camino feliz. Ejecutar 50 consultas estandar y ver 50 salidas correctas no significa que el modelo funciona. Significa que el modelo funciona con consultas estandar. Los casos limite son donde viven los fallos de produccion.

Error 3: Usar una sola metrica. La precision sola no te dice suficiente. Un modelo con 90% de precision que falla catastroficamente en el 2% de las entradas (produciendo contenido ofensivo o peligroso) es peor que un modelo con 85% de precision que falla gracilmente.

Error 4: Evaluar una vez y enviar. Los modelos no se degradan solos, pero el trafico de produccion si cambia con el tiempo. La re-evaluacion mensual detecta la desviacion de distribucion antes de que los clientes la noten.

Error 5: Omitir la evaluacion porque confias en los datos de entrenamiento. Buenos datos de entrenamiento son necesarios pero no suficientes. El modelo podria aprender patrones incorrectos de datos correctos — sobreajustandose a caracteristicas superficiales en lugar de la tarea subyacente.

Como Ertas Studio Ayuda con Flujos de Trabajo de Evaluacion

Ertas Studio incluye herramientas de evaluacion integradas disenadas para equipos sin experiencia en ML:

Interfaz de comparacion lado a lado. Pasa entradas de prueba por multiples versiones del modelo y compara las salidas en un formato limpio y revisable. Sin scripts necesarios.

Gestion de conjunto de prueba dorado. Sube tu conjunto de prueba una vez y re-ejecutalo contra cada nueva version del modelo con un solo clic. Rastrea tendencias de precision a traves de versiones automaticamente.

Exportacion de reportes de evaluacion. Genera reportes compartibles mostrando el rendimiento del modelo a traves de tu suite de pruebas — util para presentaciones a clientes y aprobacion interna.

El objetivo es hacer la evaluacion tan facil como el entrenamiento. Si la evaluacion requiere un script de Python y un Jupyter notebook, la mayoria de los equipos la omitiran. Si la evaluacion requiere hacer clic en un boton y revisar una tabla, la mayoria de los equipos realmente la haran.

---

Lectura Adicional

• Fine-Tuning vs. RAG: Cual Enfoque Es el Correcto? — Entendiendo cuando el fine-tuning es la eleccion correcta en primer lugar
• Como Ajustar un LLM — Recorrido completo del proceso de fine-tuning
• Checklist de Calidad de Fine-Tuning: 10 Pruebas Antes de Desplegar a Clientes — El checklist pre-despliegue que acompana esta guia de evaluacion