Comparación de Modelos Lado a Lado: Cómo Elegir el Mejor Modelo Ajustado Antes de Desplegar

Has ajustado tres variantes de modelo: una con 200 ejemplos de entrenamiento, una con 500 y una con un modelo base diferente. Las curvas de pérdida de entrenamiento se ven similares. Las puntuaciones de perplejidad están dentro del 5% entre sí. ¿Cuál envías?

Las métricas automatizadas cuentan parte de la historia. No cuentan toda la historia. Un modelo con 0.3% menos perplejidad puede alucinar más. Un modelo con mayor pérdida de entrenamiento puede producir respuestas que suenan más naturales. Un modelo que puntúa bien en tu benchmark puede fallar en los casos extremos exactos que tus usuarios encuentran con más frecuencia.

La respuesta: ejecuta los tres lado a lado con los mismos prompts y compara las salidas sistemáticamente.

Por Qué las Métricas Automatizadas No Son Suficientes

La Perplejidad Mide Sorpresa, No Calidad

La perplejidad mide qué tan "sorprendido" está el modelo por los datos de prueba. Menor perplejidad generalmente significa que el modelo predice mejor la distribución de entrenamiento. Pero un modelo que memoriza datos de entrenamiento tiene excelente perplejidad y terrible generalización.

Las Curvas de Pérdida Muestran Progreso de Entrenamiento, No Aptitud para Producción

Una curva de pérdida suave y convergente significa que el entrenamiento fue bien. No significa que el modelo maneje tus entradas del mundo real correctamente. El sobreajuste se manifiesta como excelentes métricas de entrenamiento y pobre rendimiento en producción.

BLEU/ROUGE Miden Superposición, No Corrección

Estas métricas comparan texto generado con texto de referencia. Recompensan la superposición de palabras, no la precisión factual o la finalización de tareas. Un modelo que usa frases diferentes (pero correctas) puntúa mal. Un modelo que copia datos de entrenamiento textualmente puntúa bien.

La Calidad Específica del Dominio Es Invisible para Métricas Genéricas

Si tu modelo necesita usar terminología específica, seguir formatos específicos o manejar casos extremos específicos del dominio, ninguna métrica genérica captura esto. Solo la evaluación consciente del dominio — que requiere mirar las salidas reales — te dice si el modelo cumple tus requisitos de producción.

El Método Lado a Lado

Paso 1: Construir tu Dataset de Evaluación

Si aún no tienes uno, construye un dataset de evaluación de 50-100 prompts representativos. Incluye:

• Casos comunes (60%): Las consultas de pan de cada día que tu modelo maneja diariamente
• Casos extremos (20%): Entradas inusuales, solicitudes ambiguas, condiciones límite
• Casos propensos a fallas (10%): Escenarios donde modelos anteriores han fallado
• Casos adversarios (10%): Entradas deliberadamente engañosas diseñadas para exponer debilidades

Para cada prompt, escribe la salida esperada — o como mínimo, describe cómo se ve una salida correcta. Consulta nuestra guía sobre construir datasets de evaluación desde conversaciones.

Paso 2: Ejecutar Todas las Variantes con los Mismos Prompts

Pasa cada prompt de tu dataset de evaluación por cada variante de modelo. Captura todas las salidas. Esto debe hacerse al mismo nivel de cuantización y con los mismos parámetros de inferencia (temperatura, top_p, etc.) — de lo contrario estás comparando configuraciones, no modelos.

La interfaz de canvas de Ertas soporta ejecutar múltiples modelos simultáneamente en el mismo conjunto de prompts, mostrando las salidas lado a lado para comparación directa.

Paso 3: Puntuar Cada Salida

Para cada combinación de prompt x modelo, puntúa en estas dimensiones:

Paso 4: Agregar y Decidir

Calcula puntuaciones promedio por dimensión por modelo:

En este ejemplo, el Modelo B (500 ejemplos, misma base) gana en la mayoría de las dimensiones. Pero la decisión no siempre es así de clara.

Cuando el Modelo "Peor" Es Realmente Mejor

A veces el modelo con puntuaciones agregadas más bajas es la elección correcta para producción:

El Modelo A tiene el mejor cumplimiento de formato pero el peor tono. Si tu caso de uso es extracción de datos estructurados (salida JSON), el cumplimiento de formato importa más que el tono. Elige el Modelo A.

El Modelo C alucina más pero maneja mejor los casos extremos. Si tu caso de uso es preguntas y respuestas cara al cliente donde las respuestas incorrectas son peores que no tener respuesta, la menor tasa de alucinación del Modelo B importa más que el manejo de casos extremos del Modelo C.

El Modelo B puntúa mejor en general pero es 2x el tamaño del adaptador. Si estás desplegando en hardware edge con restricciones de memoria ajustadas, el adaptador más pequeño del Modelo A puede ser la elección práctica a pesar de puntuaciones más bajas.

El marco de puntuación evidencia las compensaciones. La decisión depende de tus prioridades específicas.

Flujo de Trabajo de Comparación para Agencias

Si estás entregando modelos ajustados a clientes (QA antes de la entrega), la comparación lado a lado sirve también como evidencia de calidad para el cliente:

1. Entrenar 2-3 variantes con diferentes configuraciones
2. Ejecutar la comparación usando las consultas de ejemplo del propio cliente
3. Presentar los resultados — muestra al cliente las salidas reales de cada variante
4. Dejar que el cliente elija qué variante se ajusta mejor a sus necesidades
5. Documentar la selección para el versionado del modelo

Esta transparencia genera confianza. Los clientes ven que probaste múltiples enfoques y seleccionaste el mejor basándote en evidencia, no en suposiciones.

Consejos para una Comparación Efectiva

Usa Consultas Reales de Producción

No uses solo tus datos de entrenamiento para evaluación (eso es probar en el conjunto de entrenamiento). Usa consultas de uso real en producción, correos de clientes o escenarios realistas que tus usuarios realmente escribirían.

Prueba en la Cuantización de Producción

Si vas a desplegar en Q4_K_M, evalúa en Q4_K_M. La cuantización puede afectar la calidad de salida de manera diferente entre modelos — un modelo que supera a otro en F16 puede perder en Q4.

Incluye Prompts "Sin Buena Respuesta"

Incluye prompts donde la respuesta correcta es "No lo sé" o "Necesito más información." Los modelos que siempre generan una respuesta (incluso cuando no deberían) son peligrosos en producción. El mejor modelo conoce sus límites.

No Te Apoyes en Una Sola Ejecución de Evaluación

Las salidas de LLM tienen varianza, especialmente a temperaturas distintas de cero. Ejecuta cada prompt 2-3 veces y puntúa el promedio. Si un modelo produce una excelente salida 2 de 3 veces y una terrible una vez, esa inconsistencia importa.

Pondera las Dimensiones por Impacto de Negocio

No todas las dimensiones importan igual. Para un chatbot de soporte, la precisión y el tono importan más. Para un pipeline de extracción de datos, el cumplimiento de formato y la tasa de alucinación importan más. Pondera tu puntuación en consecuencia.

Primeros Pasos

1. Construye un dataset de evaluación de 50-100 prompts (guía aquí)
2. Ajusta 2-3 variantes de modelo en Ertas (diferentes tamaños de datos, diferentes modelos base o diferentes hiperparámetros)
3. Ejecuta todas las variantes a través del dataset de evaluación en el canvas
4. Puntúa las salidas en precisión, completitud, formato, tono, alucinación y casos extremos
5. Agrega puntuaciones y toma una decisión basada en tus prioridades
6. Despliega el ganador y guarda el dataset de evaluación para futuras comparaciones de reentrenamiento

El dataset de evaluación y la rúbrica de puntuación que construyes ahora se convierten en activos permanentes. Cada vez que reentrenas, comparas el nuevo modelo contra el mismo benchmark. Con el tiempo, construyes una imagen clara de la mejora del modelo — y nunca envías una regresión.