Cómo Hacer QA de un Modelo Ajustado Antes de Entregarlo al Cliente

El software tradicional es determinístico. Escribes un test, pasa o falla, y lanzas con confianza. Los modelos de IA no funcionan así. La misma entrada puede producir diferentes salidas en diferentes ejecuciones. "Correcto" es un espectro, no un binario. Y el modo de falla no es un crash — es una respuesta que suena plausible pero que es sutil y peligrosamente incorrecta.

Por eso el QA para modelos ajustados es más importante y más difícil que el QA para software tradicional. Omítelo y entregarás modelos que te avergüenzan frente a clientes. Sobre-ingenierízalo y pasarás más tiempo probando que construyendo.

Esta guía es el punto medio práctico: un proceso de QA de 4 fases que toma 4-8 horas por modelo y detecta los problemas que importan.

Por Qué "Solo Corre los Tests" No Funciona

Antes de entrar al proceso, aclaremos qué hace diferente al QA de IA:

No-determinismo. Ejecuta el mismo prompt por el mismo modelo 10 veces y podrías obtener 10 salidas diferentes. Todas podrían ser aceptables. O 9 podrían ser excelentes y 1 podría ser terrible. Tu proceso de QA necesita contemplar esta varianza.

Calidad subjetiva. ¿Es "El reembolso se procesará en 3-5 días hábiles" mejor o peor que "Tu reembolso debería llegar en una semana"? Ambas son factualmente correctas. La respuesta depende de la voz de marca del cliente, las expectativas de sus usuarios y sus políticas internas.

Cambio de distribución. Tu modelo podría puntuar 96% en tu conjunto de prueba pero fallar en entradas que no se parecen a tus datos de prueba. Las entradas del mundo real son más desordenadas, más ambiguas y más adversariales que cualquier conjunto de prueba que crees.

Efectos en cascada. Un modelo que genera metadata ligeramente incorrecta en un pipeline puede causar que los sistemas posteriores fallen de maneras que parecen completamente no relacionadas con el modelo.

Necesitas un proceso de QA que maneje todo esto. Aquí está el nuestro.

Fase 1: Evaluación Automatizada (1-2 Horas)

Esta es la línea base. Si tu modelo falla la evaluación automatizada, nada más importa — vuelve y reentrena.

El Conjunto de Prueba Dorado

Cada modelo de cliente necesita un conjunto de prueba dorado: 100-500 ejemplos de entradas y salidas esperadas que representen los casos de uso principales. Estos deben ser:

• Representativos. Cubrir todas las categorías principales de entrada que el modelo verá en producción.
• Etiquetados por expertos. No generados por otro modelo de IA. Verdad de referencia etiquetada por humanos.
• Versionados. El conjunto de prueba evoluciona a medida que las necesidades del cliente cambian. Rastrea contra qué versión evaluaste.
• Estratificados. Incluir ejemplos proporcionales de casos fáciles, medianos y difíciles.

Métricas a Calcular

Ejecuta el conjunto de prueba dorado por el nuevo modelo y calcula:

Precisión o corrección específica de la tarea. Para tareas de clasificación, esto es precisión directa o F1. Para tareas de generación, usa una combinación de puntuaciones ROUGE y similitud semántica con salidas de referencia. Objetivo: mayor al 90% para la mayoría de casos de uso.

Tasa de alucinación. Cuenta salidas que contienen afirmaciones factuales no respaldadas por la entrada o la base de conocimiento del modelo. Para tareas fundamentadas (RAG, extracción), esto debería estar por debajo del 5%. Para generación abierta, por debajo del 10%.

Cumplimiento de formato. Si el modelo debería producir JSON, ¿con qué frecuencia produce JSON válido? Si debería seguir una plantilla, ¿con qué frecuencia coincide? Objetivo: mayor al 99%.

Latencia. Mide latencia P50 y P95 en el hardware objetivo. Si el P95 excede tu SLA (típicamente 2 segundos para casos de uso en tiempo real), tienes un problema.

Verificación de Regresión

Compara cada métrica contra la versión anterior. Si alguna métrica bajó más de 2 puntos porcentuales, señálala. Las regresiones son comunes — un modelo que mejora en el manejo de una categoría a menudo empeora ligeramente en otra.

Crea una tabla comparativa:

Métrica             | Anterior (v1.2) | Nuevo (v1.3) | Delta
--------------------|-----------------|------------|------
Precisión           | 93.4%           | 95.1%      | +1.7%
Tasa de alucinación | 3.2%            | 2.8%       | -0.4%
Cumplimiento formato| 99.1%           | 99.4%      | +0.3%
Latencia P95        | 1.4s            | 1.3s       | -0.1s
Prec. cat. reemb.   | 91.2%           | 88.7%      | -2.5% ⚠️

¿Esa regresión en la categoría de reembolsos? Podría ser aceptable en contexto (la precisión general mejoró), o podría ser un bloqueante si el cliente pidió específicamente mejorar el manejo de reembolsos. Por eso la evaluación automatizada sola no es suficiente.

Fase 2: Batería de Casos Extremos (1-2 Horas)

La evaluación automatizada te dice cómo rinde el modelo en entradas típicas. Las pruebas de casos extremos te dicen cómo falla.

Construyendo el Conjunto de Casos Extremos

Crea 50-100 entradas adversariales e inusuales específicas del dominio del cliente. Categorías a cubrir:

Entradas ambiguas. Consultas que podrían interpretarse de múltiples maneras. ¿El modelo pide aclaración o adivina mal?

Entradas de frontera. Solicitudes que técnicamente están dentro del alcance pero apenas. Un modelo de revisión legal al que le preguntan sobre derecho fiscal cuando fue entrenado en derecho contractual.

Entradas adversariales. Intentos de inyección de prompts, solicitudes de ignorar instrucciones, intentos de extraer prompts del sistema o datos de entrenamiento.

Entradas vacías o mínimas. ¿Qué pasa con una entrada en blanco? ¿Una sola palabra? ¿Un signo de interrogación?

Entradas extremadamente largas. Entradas que se acercan o exceden la ventana de contexto. ¿El modelo trunca elegantemente o alucina?

Entradas fuera de alcance. Solicitudes claramente fuera del dominio del modelo. ¿Declina cortésmente o genera basura con confianza?

Entradas multi-idioma. Si el cliente opera en inglés pero tiene clientes que escriben en español, ¿qué pasa?

Casos extremos de formato. Entradas con formato inusual — todo en mayúsculas, sin puntuación, uso intensivo de emojis, markdown, bloques de código.

Calificando Casos Extremos

Para cada caso extremo, califica la salida en una escala de 3 puntos:

• Aprobado: El modelo lo manejó apropiadamente (respuesta correcta, rechazo elegante, solicitud de aclaración razonable)
• Falla suave: La salida del modelo fue subóptima pero no dañina (rechazo verboso, ligeramente fuera de tema pero no incorrecto)
• Falla grave: El modelo produjo salida dañina, peligrosa o completamente incorrecta

Objetivo: cero fallas graves, menos del 10% de fallas suaves. Cualquier falla grave necesita abordarse antes de la entrega — ya sea mediante datos de entrenamiento adicionales, prompt engineering o guardarraíles.

Fase 3: Revisión de Experto Humano (1-2 Horas)

Las métricas automatizadas y las baterías de casos extremos aún omiten cosas que un experto de dominio detecta en segundos. Esta fase trata sobre evaluación cualitativa.

El Protocolo de Revisión

Selecciona 20-30 entradas que representen uso realista de producción. No tu conjunto de prueba — entradas frescas que simulen lo que los usuarios del cliente realmente enviarán. Incluye una mezcla de:

• 10 solicitudes típicas, del día a día
• 10 solicitudes moderadamente complejas
• 5-10 solicitudes que requieren matiz o juicio

Haz que un experto de dominio (idealmente alguien familiarizado con el negocio del cliente) revise cada salida por:

Corrección factual. ¿La información es precisa? ¿Hay errores sutiles que las métricas automatizadas podrían omitir?

Tono y voz. ¿La salida suena como la marca del cliente? Si el cliente es un bufete de abogados, el modelo no debería sonar casual. Si es una app de consumo, no debería sonar como un escrito legal.

Completitud. ¿El modelo abordó todas las partes de la pregunta? ¿O respondió la parte fácil e ignoró la difícil?

Seguridad. ¿Hay salidas que podrían crear responsabilidad para el cliente? Consejos médicos incorrectos, interpretaciones legales erróneas, lenguaje discriminatorio.

Documentando Hallazgos

Para cada problema encontrado, documenta:

• La entrada que lo activó
• Lo que el modelo dijo
• Lo que debería haber dicho
• Severidad (crítico, mayor, menor)
• Solución recomendada (más datos de entrenamiento, ajuste de prompt, guardarraíl)

Los problemas críticos y mayores deben resolverse antes de la entrega. Los problemas menores se documentan como limitaciones conocidas.

Fase 4: Prueba de Aceptación del Cliente (1-2 Horas)

Este es el handoff. El cliente ve su modelo por primera vez (o ve la versión actualizada) y lo recorren juntos.

La Demo Estructurada

No le des al cliente un enlace y digas "pruébalo". Estructura la demo:

1. Ejemplos preparados (15 minutos). Recorre 5-7 ejemplos que has preseleccionado para mostrar las capacidades del modelo. Incluye al menos un ejemplo que el cliente preguntó específicamente durante el scoping.

2. Pruebas en vivo (20 minutos). Deja que el cliente escriba sus propias entradas. Aquí es donde probarán las cosas que les importan — cosas que quizás no pensaste probar.

3. Discusión de casos extremos (10 minutos). Muestra 2-3 casos extremos y explica cómo los maneja el modelo. Sé directo sobre las limitaciones: "Si alguien pregunta sobre X, el modelo declinará cortésmente porque eso está fuera de su alcance de entrenamiento."

4. Revisión de métricas (10 minutos). Recorre los resultados de evaluación. Muestra la comparación contra la línea base. Explica qué significan los números en términos prácticos.

5. Preguntas y retroalimentación (15 minutos). El cliente tendrá preguntas. Algunas serán técnicas ("¿Podemos aumentar la ventana de contexto?") y algunas serán de negocio ("¿Qué pasa cuando nuestro catálogo de productos cambia?"). Responde honestamente.

Estableciendo Criterios de Aprobación/Rechazo

Antes de la demo, acuerda criterios de aceptación explícitos:

Si el modelo cumple todos los umbrales automatizados pero el stakeholder del cliente no está satisfecho, no pasa. La evaluación subjetiva del cliente importa porque entienden su dominio mejor que tus métricas.

El Informe de QA

Después de las cuatro fases, compila los resultados en un informe de QA para el cliente:

# Informe de QA: [Cliente] [Modelo] v[X.Y.Z]
Fecha: [fecha]
Líder de QA: [nombre]

## Metodología
- Eval automatizada: [N] casos de prueba, [métricas calculadas]
- Batería de casos extremos: [N] entradas adversariales
- Revisión humana: [N] entradas tipo producción por [nombre del experto]
- Aceptación del cliente: [fecha] con [nombre del stakeholder]

## Resumen de Resultados
| Métrica             | Puntaje | Umbral    | Estado |
|---------------------|---------|-----------|--------|
| Precisión           | 95.1%   | >90%      | APROBADO |
| Tasa de alucinación | 2.8%    | <5%       | APROBADO |
| Cumplimiento formato| 99.4%   | >99%      | APROBADO |
| Latencia P95        | 1.3s    | <2s       | APROBADO |

## Limitaciones Conocidas
1. [Limitación específica con contexto y solución alternativa]
2. [Limitación específica con plan de mitigación]

## Monitoreo Recomendado
- Rastrear [métrica específica] semanalmente para detectar deriva
- Re-evaluar si [condición específica] cambia
- Reentrenamiento planificado: [fecha] o después de [condición disparadora]

Este informe se convierte en parte del historial de versiones del modelo. También es una herramienta de ventas poderosa — los clientes que ven este nivel de rigor no cuestionan tus tarifas.

Presupuesto de Tiempo

El proceso completo de QA toma 4-8 horas por modelo:

Para ciclos de reentrenamiento mensual donde los cambios son incrementales, a menudo puedes comprimir esto a 2-4 horas reutilizando la batería de casos extremos existente y haciendo una revisión humana más corta enfocada en los cambios.

¿Son 4-8 horas mucho? Compáralo con el costo de entregar un mal modelo: escalación del cliente, reentrenamiento de emergencia, posible pérdida de contrato, daño reputacional. El QA es el seguro más barato que jamás comprarás.

Integrando QA en Tu Flujo de Trabajo

No trates el QA como una compuerta única. Constrúyelo en tu procedimiento operativo estándar:

1. Después de cada reentrenamiento: QA completo de 4 fases
2. Después de cambios de configuración: Fase 1 (eval automatizada) + Fase 2 (casos extremos)
3. Semanalmente en producción: Eval automatizada contra un pequeño conjunto de prueba rotativo para detectar deriva
4. Mensualmente: Revisar el proceso de QA mismo — actualizar casos extremos, refrescar conjuntos de prueba, calibrar umbrales

Las agencias que construyen procesos de QA rigurosos son las que mantienen clientes por años. Las que lo omiten mantienen clientes por meses.

---

Para más sobre calidad de modelos, consulta nuestro fine-tuning quality checklist y la guía de evaluating fine-tuned models.