En la tercera semana de septiembre de 2026 llegaron tres grandes lanzamientos de modelos seguidos y los tres dijeron lo mismo: más barato, al menos tan bueno como antes. Cada anuncio traía una tabla, y cada tabla estaba construida con las pruebas que eligió la empresa que anunciaba.
Esas tablas no son inútiles, pero no responden a tu pregunta. Tu pregunta es: ¿cuál es mejor en mi trabajo y cuánto me cuesta? Solo tus propios datos pueden responderla. La buena noticia es que no hace falta mucha infraestructura.
Qué es un conjunto de evaluación
Un conjunto de evaluación (eval) es una colección pequeña de entradas que das al modelo junto con las respuestas que deberían producir. La documentación de OpenAI resume el proceso en tres pasos: describir la tarea como una configuración de evaluación, ejecutarla y analizar los resultados para iterar.
El objetivo no es juzgar al modelo en general, sino ver si un cambio que hiciste (cambiar de modelo, editar la instrucción, bajar el nivel de esfuerzo) ha roto tu trabajo.
Paso 1: convierte tu criterio de éxito en un número
La documentación de Anthropic contrasta criterios buenos y malos con ejemplos. "Salidas seguras" es un mal criterio; "menos del 0,1 % de las salidas en 10.000 pruebas marcadas como tóxicas" es bueno. Igualmente, en lugar de "que clasifique bien el sentimiento", conviene decir "una puntuación F1 de al menos 0,85".
Escribir esto suele ser el paso más difícil, y saltárselo deja sin sentido todo lo demás. Convierte "que la respuesta al cliente sea buena" en algo verificable: "la respuesta nombra el producto por el que preguntó el cliente e indica correctamente el plazo de devolución".
Paso 2: saca los ejemplos del trabajo real
Aquí se aplican dos de los tres principios de diseño de Anthropic:
- Sé específico de la tarea: los casos de prueba deben reflejar tu distribución real de trabajo. Incluye los extremos: entradas irrelevantes, entradas larguísimas, entradas malintencionadas, casos ambiguos.
- Prioriza el volumen sobre la calidad: en palabras de la documentación, más preguntas con puntuación automática de señal algo menor es mejor que pocas preguntas corregidas a mano.
En la práctica, empezar con 30 a 50 ejemplos basta. No los inventes: sácalos de registros reales, como los tickets de soporte del mes pasado, errores de tu propio código o preguntas que alguien hizo de verdad. Recoge sobre todo los casos que el modelo falló antes; son los que más información aportan.
Paso 3: automatiza la puntuación
Una prueba que se lee a mano se abandona en la tercera ejecución. La documentación de Anthropic enumera varios métodos automáticos:
| Método | Dónde sirve |
|---|---|
| Coincidencia exacta | Clasificación: la etiqueta es correcta o no |
| Similitud del coseno | Consistencia: respuestas parecidas a preguntas reformuladas |
| ROUGE-L | Resumen: solapamiento con un resumen de referencia |
| Puntuación con modelo (1-5) | Cualidades subjetivas como tono, empatía o profesionalidad |
| Clasificación binaria con modelo | Decisiones de sí o no, como "¿se filtraron datos personales?" |
Si puntúas con un modelo, importan dos reglas: usa un modelo distinto del que produce las respuestas y ata la puntuación a una rúbrica explícita. La prueba de una buena rúbrica es si dos expertos darían la misma nota a la misma respuesta.
Paso 4: mide también el coste
Los lanzamientos de esta semana iban de coste, así que tu evaluación debería registrar tres números y no solo la precisión:
- Tasa de acierto.
- Tokens por tarea (entrada, salida y lecturas de caché por separado).
- Tiempo por tarea.
Las tablas de los fabricantes se han movido en la misma dirección: hablan de coste por tarea antes que de puntuación absoluta. Hacer esa cuenta con tu propio trabajo es la única forma de saber qué significa para ti una afirmación como "un 40 % más barato".
Un ejemplo concreto: respuestas de soporte
Supongamos que un modelo escribe las respuestas de soporte de una tienda online. El conjunto de evaluación se monta así:
- Ejemplos: 40 tickets reales del último mes. 25 de los tipos habituales (dónde está mi pedido, cómo se devuelve, cambios de talla), 10 casos difíciles (dos pedidos mezclados, devoluciones parciales) y 5 casos límite (mensaje irrelevante, cliente enfadado, datos incompletos).
- Salida esperada: no una respuesta perfecta escrita a mano, sino lo que una respuesta correcta debe contener. Por ejemplo: "indica que el plazo de devolución es de 14 días", "repite el número de pedido", "no menciona a la empresa de transporte".
- Puntuación: esos puntos se comprueban con coincidencia exacta o una verificación simple de texto. El tono se evalúa aparte, con un modelo que solo juzga el tono.
- Coste: cada ejecución registra los tokens de entrada y salida, y de ahí sale el coste por tarea.
Un conjunto así se monta en una tarde y sirve durante años. Cuando aparece un modelo nuevo, el trabajo se reduce a ejecutar dos comandos y poner dos tablas una al lado de la otra.
Tres errores frecuentes
- Incluir solo ejemplos fáciles. Todos los modelos superan los casos fáciles; un conjunto solo distingue donde cuesta. La mitad debería ser difícil.
- No auditar nunca al evaluador. Los evaluadores automáticos también se equivocan. Lee y puntúa diez ejemplos a mano de vez en cuando y compara; si no coincides, corrige la rúbrica.
- Mirar un solo número. La tasa global de acierto esconde qué tipo de caso se rompió. Desglosa los resultados por categoría: si mejoran los envíos y empeoran las devoluciones, la media no lo dirá.
Paso 5: lee bien el resultado
El error más común es tomar una diferencia pequeña entre dos modelos por una diferencia real. El artículo de Anthropic sobre el enfoque estadístico de las evaluaciones propone varias correcciones:
- Indica el margen de error. Con el error estándar de la media puedes dar un intervalo de confianza del 95 %: la media más y menos 1,96 errores estándar.
- Corrige las preguntas agrupadas. Varias preguntas sobre el mismo texto no son independientes; según el artículo, el error estándar agrupado puede ser más de tres veces mayor que el ingenuo.
- Usa comparaciones emparejadas. Como pruebas ambos modelos con las mismas preguntas, el análisis emparejado elimina el ruido que viene de la dificultad de cada pregunta.
En la práctica: en un conjunto de 40 ejemplos, la diferencia entre un 72 % y un 75 % probablemente sea ruido. O añades ejemplos o no conviertes esa diferencia en el motivo de una decisión.
Paso 6: ejecútalo con regularidad
El valor de una evaluación está en la repetición, no en una comparación única. Ejecútala en tres momentos:
- Al cambiar de modelo o de versión.
- Al cambiar la instrucción.
- Al probar un nivel de esfuerzo menor o un modelo más pequeño para reducir coste.
Guarda los resultados con la fecha y el nombre del modelo. Tres meses después, cuando alguien diga "antes esto lo hacía mejor", tendrás un registro y no una impresión.
Dónde guardar el conjunto
Un conjunto de evaluación no es un documento: es parte del código. Tres reglas prácticas ayudan:
- Guárdalo en el repositorio, junto al código de la aplicación, para que al cambiar una instrucción el conjunto se actualice en el mismo commit.
- Limpia los datos de clientes. Al tomar ejemplos reales, sustituye nombres, direcciones, números de pedido y teléfonos: los datos deben ser realistas, no reales.
- Que ejecutarlo sea un solo comando. Un conjunto que necesita más de dos líneas para arrancar no se ejecuta.
Por dónde empezar
Lo más pequeño y útil que puedes hacer hoy: reúne 20 casos del último mes en los que el modelo se equivocó, escribe la respuesta correcta de cada uno, ejecútalos en dos modelos y anota la tasa de acierto y los tokens por tarea. Con eso basta para saber qué hacer la próxima vez que un anuncio diga "un 50 % más barato".