Checklist de Calidad de Fine-Tuning: 10 Pruebas Antes de Desplegar para Clientes

Entrenaste un modelo. Las métricas se ven bien. La demo para el cliente salió bien. Ahora alguien en tu equipo hace la pregunta que separa a las agencias profesionales de los aficionados: "¿Realmente estamos listos para lanzar esto?"

La mayoría de las agencias no pueden responder esa pregunta con confianza. Tienen intuición — "pareció bueno en las pruebas" — pero ningún proceso sistemático. Este checklist soluciona eso. Diez pruebas concretas, cada una con criterios claros de aprobación/rechazo, que ejecutas antes de cada despliegue para clientes.

Imprime esto. Ponlo en tu plantilla de proyecto. No te saltes pasos porque el plazo es ajustado. Las 2-3 horas que toma este checklist te ahorrarán las 20-30 horas de depuración de emergencia y control de daños con el cliente que siguen a un mal despliegue.

Prueba 1: Precisión en Conjunto de Prueba Dorado

Qué verificar: Ejecuta tu conjunto de prueba dorado (50-100 ejemplos con outputs correctos conocidos que nunca se usaron en entrenamiento) a través del modelo ajustado. Calcula la tasa de precisión.

Cómo verificarlo: Prepara un archivo JSONL con pares entrada-salida. Ejecuta cada entrada a través del modelo. Para tareas de clasificación, verifica coincidencia exacta. Para tareas de generación, haz que un experto de dominio califique cada output como Correcto, Parcialmente Correcto o Incorrecto.

Criterios de aprobación:

• Tareas de clasificación: 92%+ de precisión
• Tareas de generación: 85%+ calificadas como Correctas, menos de 5% calificadas como Incorrectas
• Ninguna categoría de error individual representa más del 3% del total de casos de prueba

Acción si falla: Si la precisión está por debajo del umbral, identifica los patrones de error. Usualmente la solución es agregar 50-100 ejemplos de entrenamiento dirigidos que cubran los casos de falla y reentrenar. No lances y esperes que funcione.

Prueba 2: Tasa de Alucinación

Qué verificar: ¿Con qué frecuencia el modelo genera información que suena plausible pero es factualmente incorrecta? Esto es especialmente crítico para casos de uso legales, de salud y financieros.

Cómo verificarlo: Selecciona 30 entradas de prueba donde la respuesta correcta involucra hechos específicos — nombres, fechas, números, citas, detalles de productos. Ejecútalas a través del modelo. Verifica cada afirmación factual en cada output contra tu material fuente.

Criterios de aprobación:

• Cero hechos alucinados en dominios de alto riesgo (legal, médico, financiero)
• Menos del 3% de tasa de alucinación para casos de uso empresariales generales
• El modelo debe expresar incertidumbre en lugar de fabricar cuando no tiene información

Acción si falla: La alucinación usualmente significa que los datos de entrenamiento son muy pequeños o el modelo está sobreajustándose a patrones en lugar de aprender hechos. Consulta nuestra guía sobre alucinación en modelos ajustados para estrategias específicas de mitigación. Considera agregar una capa RAG para fundamentación factual.

Prueba 3: Cumplimiento de Formato

Qué verificar: ¿El modelo produce consistentemente outputs en el formato exacto que la aplicación de tu cliente espera? Un modelo que genera contenido perfecto en el formato incorrecto romperá cada integración downstream.

Cómo verificarlo: Ejecuta 50 entradas de prueba y valida programáticamente cada output contra tu especificación de formato. Si el output debe ser JSON, parsea el resultado. Si debe seguir una plantilla con secciones específicas, verifica cada sección. Si debe estar bajo un límite de palabras, cuenta las palabras.

Criterios de aprobación:

• 98%+ de tasa de cumplimiento de formato
• Cero outputs que causarían un error de parsing downstream
• Manejo consistente de casos límite de formato (campos vacíos, caracteres especiales, unicode)

Acción si falla: Los problemas de formato son los más fáciles de arreglar. Agrega 20-30 ejemplos con el formato correcto y reentrena. Si el modelo es inconsistente con el output JSON, agrega instrucciones explícitas de formato en el system prompt como enfoque de cinturón y tirantes.

Prueba 4: Benchmark de Latencia

Qué verificar: ¿El modelo cumple los requisitos de tiempo de respuesta para el caso de uso del cliente? Un modelo que tarda 8 segundos por respuesta puede estar bien para procesamiento por lotes pero ser inaceptable para una interfaz de chat en tiempo real.

Cómo verificarlo: Ejecuta 100 entradas de prueba y mide el tiempo al primer token y el tiempo total de generación para cada una. Calcula la latencia p50 (mediana), p90 (percentil 90) y p99 (percentil 99).

Criterios de aprobación:

• La latencia p50 cumple el requisito del cliente (típicamente menos de 1 segundo para chat, menos de 5 segundos para procesamiento de documentos)
• La latencia p99 no es más de 3x la p50 (indica rendimiento consistente)
• Ninguna solicitud se agota o queda colgada

Acción si falla: La latencia es principalmente una función del tamaño del modelo y el hardware. Si el modelo es muy lento, considera un modelo base más pequeño, mayor cuantización o mejorar el hardware de despliegue. Cambiar de cuantización Q8 a Q4 típicamente reduce la latencia en 30-40% con pérdida mínima de calidad.

Prueba 5: Manejo de Casos Límite

Qué verificar: ¿Cómo se comporta el modelo cuando recibe entradas fuera de su rango esperado? Entradas vacías, entradas extremadamente largas, entradas en el idioma incorrecto, instrucciones contradictorias, intentos de inyección de prompts.

Cómo verificarlo: Prepara 20-30 entradas de casos límite en estas categorías:

• 5 entradas vacías o casi vacías
• 5 entradas que son 5-10x más largas de lo típico
• 5 solicitudes fuera de alcance (pidiendo al modelo hacer algo para lo que no fue entrenado)
• 5 entradas adversariales (inyección de prompts, intentos de jailbreak)
• 5 casos límite específicos del dominio del cliente

Criterios de aprobación:

• Cero fallas catastróficas (contenido ofensivo, filtración de datos, exposición del system prompt)
• Degradación elegante en al menos 80% de los casos límite (rechazo cortés o respuesta razonable de mejor esfuerzo)
• Sin bucles infinitos, outputs vacíos o texto distorsionado

Acción si falla: Agrega los casos límite fallidos (con ejemplos de manejo correcto) a tus datos de entrenamiento y reentrena. Para robustez adversarial, agrega 10-20 ejemplos del modelo rechazando correctamente intentos de inyección de prompts.

Prueba 6: Verificación de Sesgo y Equidad

Qué verificar: ¿El modelo trata a diferentes grupos demográficos, regiones o segmentos de casos de uso de manera equitativa? El sesgo en modelos ajustados frecuentemente proviene de datos de entrenamiento desbalanceados.

Cómo verificarlo: Crea 20 pares de entradas de prueba donde la única diferencia es una variable demográfica (nombre, ubicación, género, edad). Ejecuta ambas versiones a través del modelo. Compara los outputs para diferencias significativas en tono, calidad o recomendaciones.

Criterios de aprobación:

• Sin diferencia estadísticamente significativa en la calidad del output entre grupos demográficos
• Sin estereotipos o suposiciones basadas en información demográfica
• Tono y utilidad consistentes independientemente de la demografía implícita de la entrada

Acción si falla: Audita tus datos de entrenamiento para desbalance demográfico. Si el 90% de tus ejemplos de entrenamiento involucran un grupo demográfico, el modelo tendrá bajo rendimiento para otros. Balancea el dataset y reentrena.

Prueba 7: Guardarraíles de Seguridad

Qué verificar: ¿El modelo rechaza generar contenido dañino, ilegal o inapropiado? El fine-tuning puede debilitar el entrenamiento de seguridad del modelo base, especialmente si tus datos de entrenamiento incluyen ejemplos que empujan los límites.

Cómo verificarlo: Ejecuta 15-20 entradas de prueba que soliciten:

• Instrucciones dañinas (violencia, autolesión, actividades ilegales)
• Generación de información privada (SSNs falsos, números de tarjetas de crédito)
• Contenido que viola las directrices de marca del cliente
• Asesoramiento médico o legal que debería incluir disclaimers

Criterios de aprobación:

• 100% de tasa de rechazo para solicitudes genuinamente dañinas
• Disclaimers apropiados en asesoramiento profesional (legal, médico, financiero)
• Sin generación de patrones de datos privados incluso cuando se solicita creativamente
• Los outputs se alinean con la voz de marca y políticas de contenido del cliente

Acción si falla: Si los guardarraíles de seguridad están debilitados, probablemente necesitas agregar ejemplos de rechazo explícitos a tus datos de entrenamiento. Incluye 20-30 ejemplos del modelo rechazando correctamente solicitudes dañinas. Para alineación de marca, agrega ejemplos que demuestren el tono correcto y manejo de límites.

Prueba 8: Comparación A/B vs. Línea Base

Qué verificar: ¿El modelo ajustado es realmente mejor que la alternativa? La línea base puede ser el modelo base con un buen system prompt, un GPT-4 con prompts, o la solución actual del cliente.

Cómo verificarlo: Ejecuta 50 entradas de prueba a través del modelo ajustado y la línea base. Presenta pares de outputs a un revisor ciego (no saben qué output provino de qué modelo). El revisor elige el mejor output para cada par o los marca como iguales.

Criterios de aprobación:

• El modelo ajustado gana al menos 60% de las comparaciones directas
• El modelo ajustado no tiene categorías donde pierde consistentemente contra la línea base
• La mejora de calidad es notable en la tarea específica que le importa al cliente

Acción si falla: Si el modelo ajustado no supera claramente a la línea base, el fine-tuning no funcionó lo suficientemente bien para justificar el despliegue. Revisa la calidad y cantidad de tus datos de entrenamiento. A veces la respuesta honesta es que la ingeniería de prompts con un modelo de frontera es suficiente para este caso de uso.

Prueba 9: Costo Por Inferencia

Qué verificar: ¿El costo operativo de ejecutar este modelo se ajusta al presupuesto del cliente y tus requisitos de margen? Un modelo que cuesta $0.50 por solicitud es una propuesta de negocio muy diferente a uno que cuesta $0.005.

Cómo verificarlo: Calcula el costo por inferencia basado en tu configuración de despliegue:

• Para auto-hospedado: (costo de GPU por hora) / (solicitudes por hora a la latencia objetivo)
• Para despliegue en la nube: (costo de instancia por hora) / (throughput medido)
• Incluye todos los costos: cómputo, almacenamiento, transferencia de red, monitoreo

Criterios de aprobación:

• El costo por inferencia está bajo el presupuesto declarado del cliente
• El margen de la agencia es al menos 40% (si estás cobrando al cliente por inferencia)
• El costo a escala proyectada (3x, 10x el volumen actual) sigue siendo viable

Acción si falla: Optimiza el despliegue. Cambia a un nivel de cuantización más pequeño, agrupa solicitudes, usa una variante de modelo más pequeña o ajusta el hardware de despliegue. Si los costos son fundamentalmente muy altos para el caso de uso, ten la conversación honesta con el cliente antes del despliegue en lugar de después de la primera factura.

Prueba 10: Criterios de Aceptación del Cliente

Qué verificar: ¿El modelo cumple los criterios específicos que el cliente definió al inicio del proyecto? Esta es la prueba más importante porque mide lo que al cliente realmente le importa.

Cómo verificarlo: Revisa los criterios de aceptación de tu declaración de trabajo o kickoff del proyecto. Para cada criterio, prepara 10-20 casos de prueba que lo validen directamente. Ejecuta las pruebas y documenta los resultados.

Criterios de aceptación comunes del cliente:

• "Debe categorizar correctamente el 95% de nuestros tickets de soporte"
• "Debe generar respuestas que coincidan con nuestra voz de marca"
• "Debe procesar un documento en menos de 3 segundos"
• "Debe manejar entradas en español"
• "No debe divulgar información de un departamento a otro"

Criterios de aprobación: Todos los criterios de aceptación definidos por el cliente se cumplen. Si un criterio es ambiguo, documenta tu interpretación y obtén aprobación del cliente antes del despliegue.

Acción si falla: Si criterios de aceptación específicos fallan, prioriza arreglar esos sobre todos los demás problemas. Un modelo que pasa 9 de tus 10 pruebas internas pero falla el criterio principal del cliente no está listo para lanzar.

Ejecutando el Checklist en la Práctica

Estimación de tiempo: 2-4 horas para una ejecución exhaustiva de las 10 pruebas. La primera vez toma más tiempo (construir conjuntos de prueba, configurar scripts de evaluación). Las ejecuciones subsiguientes son más rápidas porque reutilizas y extiendes tus activos de prueba.

Quién lo hace: Idealmente, la persona que ejecuta el checklist no es la persona que entrenó el modelo. Ojos frescos detectan más problemas. Si tu equipo es pequeño, como mínimo haz que alguien más revise las pruebas de casos límite y seguridad.

Cuándo ejecutarlo:

• Antes de cada despliegue para clientes (no negociable)
• Después de cada ciclo de reentrenamiento
• Mensualmente para modelos en producción, incluso sin cambios (detectar drift)
• Inmediatamente después de cualquier problema reportado por el cliente

Documentación: Registra los resultados de cada ejecución del checklist. Fecha, versión del modelo, versión del conjunto de prueba, aprobado/rechazado para cada prueba y notas sobre cualquier elemento borderline. Esto crea una pista de auditoría que es valiosa para la confianza del cliente y para tu propio seguimiento de calidad.

La Única Regla Que Más Importa

Si una prueba falla, no lances. No existe "lo arreglaremos en la próxima versión" para modelos en producción que manejan datos reales de clientes. El costo de un despliegue fallido — confianza del cliente, depuración de emergencia, potencial responsabilidad legal — siempre excede el costo de retrasar el lanzamiento unos días para arreglar el problema.

Las agencias que construyen una reputación de confiabilidad cobran más, retienen clientes más tiempo y obtienen referidos. Este checklist es cómo construyes esa reputación sistemáticamente.

---

Lectura Adicional

• Cómo Evaluar Tu Modelo Ajustado — Guía detallada sobre cada enfoque de evaluación referenciado en este checklist
• Ertas Studio vs. Fine-Tuning DIY para Agencias — Eligiendo las herramientas correctas para tu flujo de trabajo de agencia