Hay una frase en el Risk Report de agosto que debería haber sido el titular de la semana y ha pasado casi de largo: Anthropic reconoce que sus evaluaciones de referencia han saturado y ya no reflejan los incrementos reales de capacidad de sus modelos más nuevos. Dicho sin el envoltorio corporativo: la empresa que fabrica estos sistemas admite que su regla de medir se quedó corta y todavía no tiene otra.
Y mi reacción no es de alarma. Es de alivio incómodo, porque llevaba meses sospechándolo y creyendo que el problema era mío.
Un benchmark saturado no es un examen difícil, es un termómetro roto
Conviene entender qué significa «saturar», porque suena a tecnicismo inofensivo. Un benchmark satura cuando los modelos lo resuelven tan bien que las diferencias entre ellos caben dentro del margen de error. Pasar del 94,1% al 95,3% no te dice que el segundo modelo sea mejor: te dice que la prueba dejó de discriminar. Es un termómetro que marca «caliente» tanto si tienes fiebre como si te estás quemando.
Eso convierte en ruido la mayor parte de las tablas comparativas con las que se anuncian los modelos. No porque nadie mienta —los números son los que son— sino porque miden algo que dejó de ser relevante. Y aquí está lo que me interesa: durante el último año esas tablas han sido el argumento principal para que todos actualizáramos. Sale un modelo, publica sus barras, y la industria entera asume que la mejora es real y proporcional.
Si el fabricante no puede medir cuánto ha mejorado su modelo, nadie de fuera está en mejor posición para hacerlo.
Reconozco que la admisión me parece honesta y poco habitual. Una empresa a semanas de salir a bolsa podría haber seguido publicando barras que suben sin que nadie hubiera protestado. Decir «nuestras métricas ya no capturan las mejoras» es exactamente lo contrario de lo que aconsejaría cualquier departamento de comunicación. Eso vale un aplauso.
Lo que no vale un aplauso es todo lo que se construyó encima mientras tanto.
He elegido modelo para clientes con números que no significaban eso
Cada vez que un cliente me pregunta por qué uso un modelo y no otro, mi respuesta ha tenido siempre dos patas: mi experiencia trabajando con él y las cifras publicadas. La segunda pata sonaba más objetiva, así que pesaba más en la conversación. Resulta que era la más débil de las dos.
Y sin embargo, mirándolo con distancia, mi experiencia práctica llevaba tiempo desalineada de las tablas. He tenido modelos que puntuaban mejor y me daban peores resultados encadenando tareas largas sobre un WordPress con Breakdance. He tenido versiones que en el papel apenas mejoraban y que, en mis flujos de n8n, redujeron a la mitad las veces que tenía que intervenir a mano. Achacaba la discrepancia a mis prompts, a mi manera de partir las tareas, a lo específico de mi stack.
No era eso. O no era solo eso. Era que el número medía una cosa y mi trabajo era otra, y la brecha entre ambas se ha ido ensanchando justo mientras las tablas se aplanaban.
💡 La prueba que sí decide:
Guarda entre diez y quince tareas reales que hayas resuelto para clientes, con su resultado correcto ya conocido: un refactor concreto, una migración de plantilla, un flujo que falló y supiste por qué. Cuando salga un modelo nuevo, pásaselas. Esa comparación tarda una tarde y te dice más que cualquier tabla publicada.
El problema de fondo no es el marketing, es el umbral de seguridad
Si esto solo afectara a qué modelo elijo, sería una anécdota de compras. Pero el mismo informe eleva por primera vez la estimación de riesgo de desalineamiento de «muy bajo» a «bajo», y ahí las dos cosas se cruzan de una manera que no me gusta.
Todo el aparato de seguridad de estos laboratorios funciona por umbrales: si un modelo supera cierta puntuación en cierta evaluación, se activan medidas adicionales, se retrasa un lanzamiento, se restringe un acceso. Ese esquema depende por completo de que las evaluaciones discriminen. Un umbral medido con un instrumento saturado no es un umbral, es una formalidad.
Leído así, el movimiento del indicador de riesgo tiene bastante más sentido, y hasta me parece coherente: si has perdido resolución para saber dónde estás, lo prudente es asumir que estás más cerca del límite de lo que creías. Es la decisión correcta. Lo que me deja intranquilo es que la incertidumbre sea ahora una parte declarada del sistema, y que la única respuesta disponible sea el criterio de quien la declara.
Lo que cambia en mi forma de decidir
Tres cosas, y ninguna es dramática:
- Mis casos de prueba pasan a ser un activo del negocio: No una carpeta de apuntes, sino un conjunto versionado de tareas reales con resultado conocido que ejecuto cada vez que hay un modelo nuevo. Es lo único que mide lo que realmente hago.
- Dejo de citar benchmarks en propuestas: Si el fabricante dice que sus números no capturan las mejoras, usarlos para convencer a un cliente es venderle una precisión que no existe. Sustituirlos por «lo he probado con vuestro caso y esto es lo que sale» es más trabajo, pero resulta mucho más defendible.
- Actualizar deja de ser automático: Si la mejora no es medible desde fuera, cambiar de modelo en un proyecto en marcha es asumir riesgo sin evidencia. El modelo nuevo entra cuando gana en mis pruebas, no cuando se lanza al mercado.
La lectura optimista de todo esto es que la ventaja competitiva se desplaza hacia quien conoce bien su dominio. Si las métricas generales ya no distinguen, lo que distingue es tener criterio propio sobre un problema concreto: saber qué falla en un WordPress real, qué se rompe en un flujo con quince pasos, qué significa «funciona» para un cliente que no sabe leer una tabla comparativa.
Durante un par de años ha bastado con enterarse de qué modelo era el mejor y usarlo. Esa época se acaba hoy, y no porque los modelos hayan dejado de mejorar, sino porque nadie —ni siquiera quien los construye— puede ya decirte cuánto. La pregunta de esta semana no es qué modelo es el mejor. Es cuándo fue la última vez que lo comprobaste tú mismo.
