Análisis: los benchmarks públicos dejaron de predecir la calidad en producción — cómo construir un conjunto de evaluación que sí lo haga
Las puntuaciones de las tablas de clasificación y la fiabilidad real en producción llevan dos años distanciándose. Un método probado para construir ese conjunto de evaluación privado, pequeño y poco vistoso, que realmente indica si conviene lanzar un modelo.
Respuesta rápida
¿Por qué los modelos con puntuaciones altas en los benchmarks siguen fallando en producción, y cómo deberían los equipos evaluar los modelos por su cuenta?
Los benchmarks públicos miden tareas estrechas, estáticas y ampliamente publicadas, y cada vez están más contaminados por los datos de entrenamiento y optimizados de forma directa para superarlos. La calidad en producción depende de los prompts propios, los documentos propios, los esquemas de herramientas propios y la tolerancia a fallos de cada equipo, nada de lo cual mide ninguna tabla de clasificación. La respuesta práctica es un conjunto de evaluación privado de entre 50 y 300 casos reales con el comportamiento esperado registrado, que se ejecuta con cada cambio de modelo o de prompt, puntuado mediante comprobaciones exactas cuando es posible y, cuando no, mediante un modelo juez guiado por una rúbrica.
Claves
- Una clasificación responde a «qué modelo es más potente en términos generales». Una decisión de despliegue exige saber «qué modelo funciona mejor para mi tarea, con mis datos y bajo mis restricciones». Son preguntas distintas, y solo una de ellas puede responderla otra persona.
- Cincuenta casos bien elegidos de tu propio tráfico superan a cualquier benchmark público a la hora de predecir si un cambio es seguro para publicarse.
- Divide la evaluación según la consecuencia del fallo, no según el tema. Los casos en los que una respuesta equivocada resulta costosa merecen su propia barrera de control.
- Primero las comprobaciones deterministas, después los jueces basados en modelos. Todo lo que se pueda verificar con código nunca debería delegarse a un juez.
- El conjunto de evaluación es un activo vivo: todo incidente en producción debería terminar con la incorporación de un nuevo caso.
Hay una decepción muy concreta que ya han vivido la mayoría de los equipos que lanzan productos con modelos de lenguaje. Llega un modelo nuevo con mejores cifras en todos los gráficos. Se sustituye el anterior. En menos de una semana, aumentan las solicitudes de soporte, un usuario interno informa de que los resúmenes han empeorado y alguien revierte discretamente el cambio.
No hubo engaño alguno. Las puntuaciones de las pruebas de referencia eran reales y es probable que el modelo sea más potente en términos generales. El error estuvo en la inferencia: una clasificación responde a una pregunta que ningún despliegue plantea jamás.
Qué mide realmente una prueba de referencia
Las pruebas de referencia públicas comparten una serie de propiedades que resultan útiles para la ciencia, pero poco útiles para tomar decisiones.
Son estáticas. Una prueba que cambia no permite hacer comparaciones a lo largo del tiempo, por lo que sus elementos permanecen fijos. Eso significa que las mismas preguntas se responden en miles de artículos académicos, entradas de blog y repositorios, lo que las lleva a la web abierta y, por tanto, a los corpus de entrenamiento. Esto es contaminación, y no supone una acusación de conducta indebida: es el resultado habitual de publicar una prueba y después entrenar con datos de internet. El efecto es que las puntuaciones suben más deprisa que las capacidades reales.
Son limitadas. Los conocimientos evaluados mediante preguntas de opción múltiple, las matemáticas de competición, los problemas de programación aislados y el razonamiento en formato breve son pruebas legítimas, pero su correlación con «gestiona los correos de soporte de nuestros clientes, mal puntuados, sin inventarse una política de reembolsos» es débil, y nadie ha afirmado nunca lo contrario.
Son objeto de optimización. En cuanto una cifra se convierte en el indicador con el que el sector resume el progreso, pasa a ser un objetivo en todos los ciclos de entrenamiento y evaluación. La ley de Goodhart hace el resto. No hace falta que nadie haga trampas; basta con que a todos les importe esa cifra.
Descartan las restricciones que determinan la calidad en producción: su presupuesto de latencia, la longitud del contexto, los esquemas de sus herramientas, la calidad de la recuperación, el prompt, el formato de salida y la gravedad que tiene para usted un tipo concreto de error.
Las clasificaciones basadas en preferencias humanas corrigen parte de este problema, pero introducen sus propias distorsiones. Agregan las preferencias de una población cuyas tareas no son las suyas y premian las cualidades que causan buena impresión en una comparación rápida: estructura fluida, planteamiento seguro y extensión generosa. Si su producto necesita un comportamiento conciso y literal que se niegue a responder cuando no haya certeza, una clasificación por preferencias puede señalar exactamente en la dirección equivocada.
La alternativa es más pequeña de lo que se cree
Los equipos no crean evaluaciones privadas porque imaginan algo enorme. No lo es. Un conjunto de evaluación útil suele contener entre 50 y 300 casos, y la primera versión puede prepararse en un día.
Primer paso: extraiga casos del tráfico real. No use ejemplos inventados. Recurra a los registros: mensajes reales de usuarios, documentos reales y secuencias reales de llamadas a herramientas. Los casos inventados comparten los puntos ciegos de quien los ideó.
Segundo paso: estratifique por consecuencias, no por temas. El impulso inicial es agrupar por materias. El eje útil es el coste de una respuesta errónea:
- Error silencioso — plausible, seguro e incorrecto. Es la categoría más costosa y la que conviene sobremuestrear.
- Debería haberse negado — el modelo respondió cuando el comportamiento correcto habría sido rechazar la solicitud o derivarla.
- Formato defectuoso — contenido válido presentado de una forma que rompe el analizador situado más adelante en el proceso.
- Cosmético — tono, longitud, orden. Es real, pero barato.
Un modelo que mejora en los casos cosméticos y retrocede en los errores silenciosos obtiene una puntuación media superior, pero da lugar a un producto peor. Solo un conjunto estratificado permite detectarlo.
Tercer paso: registre el comportamiento esperado, no una cadena de texto concreta. En la mayoría de los casos, la etiqueta correcta consiste en un conjunto de condiciones: debe citar el documento 3, no debe mencionar los precios, debe devolver un JSON válido con estos campos, debe negarse a responder. Las condiciones resisten las reformulaciones; las cadenas de referencia, no.
Cuarto paso: ejecute primero las comprobaciones deterministas. Validez del esquema, campos obligatorios, cadenas prohibidas, tolerancias numéricas, presencia de citas, latencia y coste en tokens. Esta capa es barata, exacta y detecta una proporción sorprendente de las regresiones reales. Todo lo que pueda decidir un assert nunca debería llegar a un evaluador.
Quinto paso: utilice un modelo evaluador solo para lo que quede. Fidelidad a una fuente, tono, exhaustividad y si una explicación responde realmente a lo solicitado. El evaluador necesita una rúbrica escrita con criterios concretos, una respuesta de referencia cuando exista y un orden aleatorio al comparar dos resultados. Informe del grado de coincidencia entre el evaluador y una persona sobre una muestra; si es bajo, el problema está en la rúbrica, no en el evaluador.
Cómo interpretar los resultados sin engañarse
Dos modos de fallo explican la mayoría de las malas decisiones tomadas a partir de datos de evaluación.
El primero es tratar una pequeña diferencia como si fuera significativa. Con 100 casos, pasar del 82 % al 85 % entra de lleno en el margen de ruido. Presente un intervalo de confianza, ejecute el conjunto varias veces y observe la varianza, o resista la tentación de declarar un ganador. La temperatura de muestreo, por sí sola, puede desplazar varios puntos el resultado de un conjunto pequeño.
El segundo es hacer desaparecer en el promedio aquello que importa. Una tasa de aciertos agregada oculta la naturaleza de los fallos. El resultado útil de una ejecución de evaluación no es una cifra, sino una tabla: la tasa de aciertos por estrato y el detalle de los casos concretos que cambiaron. Los casos que pasaron de aprobar a fallar constituyen toda la señal: léalos.
De dónde procede el conjunto de evaluación con el paso del tiempo
La primera versión procede de los registros. La versión duradera se nutre de los incidentes. Cada fallo en producción que llegue a una persona debería terminar con la incorporación de un caso al conjunto y con el registro del comportamiento esperado. Esto convierte la carga de soporte en cobertura frente a regresiones y es el mecanismo que hace que el conjunto de evaluación sea específico para su producto, en lugar de un indicador genérico de calidad.
La misma disciplina se aplica a los sistemas basados en recuperación, que requieren una capa adicional: evaluar la recuperación por separado de la generación. Si la respuesta es errónea porque nunca se recuperó el documento correcto, ningún cambio de modelo solucionará el problema, y una puntuación integral seguirá indicando que el culpable es el modelo.
Para qué siguen siendo útiles las pruebas de referencia
Nada de esto vuelve inútiles las evaluaciones públicas, y el reflejo de descartar por completo las clasificaciones constituye otro error.
Son un filtro razonable: si necesita escoger tres candidatos entre veinte modelos para someterlos a pruebas adecuadas, las puntuaciones publicadas, junto con la longitud del contexto y el precio, permiten seleccionar tres opciones defendibles. También ofrecen una línea de tendencia del sector útil: la evolución de los modelos con pesos abiertos frente a los modelos de vanguardia durante los dos últimos años es una señal real que resultaría difícil percibir de otro modo. Y unas pocas pruebas, en particular las de agentes y las que operan a escala de repositorio y dificultan la memorización al exigir un resultado ejecutado, aportan información verdaderamente valiosa sobre los cambios de capacidad.
La regla es concreta y conviene formularla con claridad: utilice las pruebas de referencia públicas para decidir qué probar y su propio conjunto de evaluación para decidir qué lanzar. Los equipos que invierten esos dos usos pasan mucho tiempo explicando a sus usuarios por qué la actualización empeoró las cosas.
Preguntas frecuentes
- ¿Son inútiles los benchmarks públicos?
- No. Son útiles para un cribado general —decidir qué tres modelos merece la pena probar siquiera— y para seguir la evolución del campo con el tiempo. Dejan de ser útiles en el momento en que se usan como sustituto de las pruebas sobre tu propia tarea.
- ¿Qué es la contaminación de un benchmark?
- Que los elementos de la prueba, o casi duplicados de ellos, aparezcan en los datos de entrenamiento de un modelo. Como la mayoría de los benchmarks públicos están en la web abierta, esto ocurre por defecto e infla las puntuaciones de una forma que no se traslada a trabajo nunca visto.
- ¿Cuántos casos de evaluación son suficientes?
- Cincuenta bastan para detectar regresiones grandes y se pueden reunir en una tarde. Unos cientos, estratificados por escenario, bastan para detectar las diferencias de calidad más pequeñas que importan entre modelos parecidos. Más allá de un millar aproximadamente, el coste de mantener las etiquetas suele superar la señal adicional que aportan.
- ¿Es fiable usar un modelo para calificar la respuesta de otro modelo?
- Es lo bastante fiable para comparaciones relativas cuando la rúbrica es específica, el juez dispone de una respuesta de referencia y se controlan los sesgos de posición y de extensión. No es fiable como puntuación absoluta de calidad, y nunca debería calificar algo que una prueba unitaria pudiera comprobar.
- ¿Con qué frecuencia debería ejecutarse la evaluación?
- Con cada cambio de prompt, cada cambio de versión del modelo, cada cambio en el esquema de herramientas, y de forma periódica sobre producción para detectar la deriva en los datos, no solo en el modelo.