Claude Opus 5.5 salió el 22 de septiembre de 2026 y, nueve días después, ya hay un repositorio que mide en público la degradación de modelos de IA día a día, en vez de esperar a que la comunidad lo intuya por comentarios sueltos en redes.
El proyecto se llama LiveNerf y ataca un problema concreto: cuando un modelo rinde peor semanas después de salir, lo único que suele haber son capturas de pantalla y quejas, nunca una línea base con la que comparar de verdad.
TL;DR
- Detectar si un modelo empeoró exige comparar el mismo panel de preguntas contra su línea base del lanzamiento.- Bajar el esfuerzo de razonamiento recorta hasta 62% los tokens de salida antes de que caiga la nota.- Un panel calibrado descarta las preguntas que el modelo siempre acierta o siempre falla, deja solo las dudosas.- Con prompts congelados y una CLI fijada en una versión, la única variable que cambia es el modelo mismo.- El método usa errores estándar agrupados, la misma estadística que Anthropic recomienda para comparar evaluaciones.
¿Qué es la degradación de modelos de IA?
La degradación de modelos de IA es la pérdida gradual de calidad que sufre un modelo de lenguaje tras su lanzamiento, sin que el proveedor anuncie un cambio de versión. Puede deberse a cuantización, enrutamiento a una variante más barata o menos esfuerzo de razonamiento, y solo se confirma comparando contra una línea base fija.
El término se popularizó por una acusación puntual: que Anthropic 'nerfea' sus modelos días o semanas después de publicarlos. La acusación puede ser cierta, puede ser ruido estadístico, o puede ser una mezcla de las dos cosas. El problema de fondo no es si la acusación es real, sino que casi nadie mide con un método que aguante una revisión seria.
Ahí está el aporte real de LiveNerf: no defiende ni acusa a nadie, corre el mismo panel todos los días desde el lanzamiento de Opus 5.5 y deja que la estadística hable primero.
Por qué importa
Un equipo que sirve un modelo en producción no puede confiar solo en la sensación de que 'algo cambió'. Si un proveedor baja el esfuerzo de razonamiento para ahorrar cómputo, la nota final puede tardar en moverse, pero el consumo de tokens se mueve antes. LiveNerf documenta justamente ese patrón: con esfuerzo bajo, el consumo de tokens de salida cae 62% mientras la nota baja apenas 8,3 ± 4,5 puntos; con esfuerzo medio, el consumo cae 26% y la nota baja 4,2 ± 3,9 puntos, según la validación publicada por el proyecto.
Esa asimetría explica por qué el conteo de tokens funciona como alerta temprana. Antes de que la precisión se mueva lo suficiente como para ser estadísticamente significativa, el gasto de cómputo ya cambió. Para cualquiera que pague por token, ese dato solo vale si viene de un panel fijo y repetido, no de una anécdota aislada en un foro.
💭 Clave: el proyecto mide dos señales, no una: la precisión y el conteo de tokens. Cuando un modelo empieza a pensar menos, eso se nota en los tokens antes que en la nota.
El seguimiento diario arrancó el 24 de septiembre de 2026.Cómo funciona un benchmark de seguimiento
El diseño de LiveNerf resuelve un problema técnico incómodo: un modelo con razonamiento activado no se puede volver determinista. No hay parámetros de sampling que fijar ni forma de apagar el pensamiento interno. La solución no es pelear contra eso, sino congelar todo lo demás: los prompts, la versión exacta de la CLI de Claude Code (pinneada en 2.1.280) y el hash del harness que corre la evaluación (461391b6fce64167 en las seis corridas registradas al 29 de septiembre de 2026).
Con esos tres elementos fijos, cualquier diferencia en el resultado tiene una sola explicación posible: el modelo cambió. El proyecto corre sobre Inspect, el framework de evaluación abierto del AI Security Institute del Reino Unido, y sigue la metodología estadística que Anthropic describe en su trabajo sobre errores estándar en evaluaciones: comparación pareada por pregunta, con errores agrupados para que la dificultad de cada ítem se cancele en vez de mezclarse con la señal.
El panel de preguntas no se eligió al azar. LiveNerf arrancó con 2.336 preguntas de GPQA Diamond, MMLU-Pro, matemática de competencia y AIME 2025-26, las tamizó con 4 muestras por pregunta y encontró que Opus 5.5 acierta cerca del 93% al primer intento, y que el 97% de las preguntas resultan siempre correctas o siempre incorrectas. Solo 78 preguntas quedaron en la zona intermedia, las que a veces acierta y a veces falla, y esas son las que forman el panel final.
flowchart TD
A["2336 preguntas candidatas"] --> B["4 muestras por pregunta"]
B --> C{"Resultado"}
C -->|"93% acierta siempre"| D["Descartada: muy facil"]
C -->|"97% acierta o falla siempre"| E["Descartada: sin variacion"]
C -->|"a veces acierta"| F["Panel final: 78 preguntas"]
Filtrar por 'a veces acierta' introduce un sesgo conocido: esas preguntas parecen más cerca del 50/50 de lo que realmente están, porque el ruido de la muestra de calibración las empuja hacia el centro. LiveNerf lo midió: en muestras frescas, la tasa de acierto de esas 78 preguntas subió de 54,7% a 62,0%, así que el cálculo de poder estadístico usa la tasa fresca, no la de calibración. Con ese ajuste, una corrida diaria del panel completo puede detectar un cambio de precisión de unos 7,5 puntos por ventana de diez días.
Ejemplos prácticos y cómo replicar la comparación estadística
La parte que un desarrollador puede copiar sin depender de LiveNerf es la comparación pareada: guardar, por cada pregunta, el resultado de hoy contra el resultado de la línea base, y calcular la diferencia con un error estándar agrupado por pregunta en vez de tratar cada muestra como independiente. Así una pregunta difícil no distorsiona el promedio más que las demás.
import numpy as np
def diferencia_pareada(baseline, corrida_actual):
# baseline y corrida_actual: listas de 0/1 por pregunta, mismo orden
diffs = np.array(corrida_actual) - np.array(baseline)
delta = diffs.mean()
se = diffs.std(ddof=1) / np.sqrt(len(diffs))
return delta, se
baseline = [1, 1, 0, 1, 0, 1, 1, 0]
corrida_actual = [1, 0, 0, 1, 0, 1, 0, 0]
delta, se = diferencia_pareada(baseline, corrida_actual)
print(f"delta={delta:.3f} se={se:.3f}")
Con ese panel de ejemplo de 8 preguntas, la salida es delta=-0.250 se=0.164: una caída de 25 puntos porcentuales con un error estándar de 16,4 puntos, es decir, todavía dentro del ruido para una muestra tan chica. Con las 78 preguntas reales de LiveNerf y una ventana de diez corridas diarias, ese mismo cálculo tiene el poder suficiente para separar una caída real de una racha mala.
sequenceDiagram
participant Cron as Cron diario
participant CLI as CLI headless
participant Modelo as Modelo bajo prueba
participant Grader as Grader automatico
Cron->>CLI: dispara la corrida diaria
CLI->>Modelo: envia las preguntas del panel
Modelo-->>CLI: devuelve respuestas y tokens usados
CLI->>Grader: pasa respuestas a evaluar
Grader-->>Cron: log append-only con el resultado
Note over Cron,Grader: mismo prompt, misma CLI, todos los dias
Cómo empezar a correr tu propio benchmark de seguimiento
LiveNerf corre sobre claude -p, la variante headless de Claude Code, y necesita una suscripción a Claude Max en vez de una API key. El repositorio usa uv como gestor de dependencias, con pyproject.toml y uv.lock ya versionados.
macOS y Linux:
curl -LsSf https://astral.sh/uv/install.sh | sh
git clone https://github.com/ninjahawk/livenerf.git
cd livenerf
uv sync
Windows (PowerShell):
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"
git clone https://github.com/ninjahawk/livenerf.git
cd livenerf
uv sync
uv sync instala las dependencias fijadas en uv.lock, así que corrés exactamente el mismo entorno que el proyecto usó para sus seis corridas registradas. Los comandos exactos para lanzar una evaluación (qué script de scripts/ invocar y con qué flags) cambian entre versiones, así que conviene seguir el README oficial del repositorio en vez de adivinarlos.
⚠️ Ojo: sin una suscripción a Claude Max activa no hay forma de correr la evaluación tal como está diseñada; el proyecto explícitamente no soporta correr contra una API key.
Solo 78 de 2.336 preguntas resultaron lo bastante inciertas para el panel.Casos de uso reales
Un equipo que fija la versión de un modelo en producción puede correr un panel chico antes de cada actualización, para no heredar una regresión silenciosa. Una empresa que paga por token puede vigilar el conteo de tokens de salida como alerta temprana, antes de que la precisión se mueva lo suficiente para notarse en las métricas de negocio.
Un investigador independiente puede usar el mismo método para separar una queja real de ruido estadístico cuando la comunidad dice que 'el modelo está peor' en redes, sin depender de vibras ni de capturas de pantalla sueltas.
Errores comunes y buenas prácticas
No congelar el prompt exacto invalida la comparación: una paráfrasis, aunque diga lo mismo, cambia la dificultad percibida por el modelo. Confundir un cambio de familia de modelo con la deriva de modelos de IA dentro de la misma versión es otro error frecuente: LiveNerf probó reemplazar Opus 5.5 por Opus 5 y no pudo distinguirlo al 99% de confianza (−3,8 ± 6,3 puntos, −23% de tokens), así que este método tiene un límite claro de sensibilidad.
Elegir preguntas 'difíciles' sin corregir el sesgo de selección infla artificialmente la incertidumbre; por eso LiveNerf recalculó la tasa de acierto en muestras frescas antes de fijar el poder estadístico. Ignorar la ruta de servicio también distorsiona resultados: a veces el clasificador de seguridad responde con otro modelo o se niega a contestar preguntas de biología o matemática, y esas muestras hay que rechazarlas y contarlas aparte, no promediarlas como si fueran respuestas normales.
Por último, no versionar el propio arnés de evaluación es el error más silencioso de todos: si el código que corre el benchmark cambia sin dejar rastro, ya no se puede saber si la diferencia viene del modelo o del harness.
Comparativa con alternativas
OpciónCuándo usarlaVentajaLimitaciónReportes sueltos en redes socialesComo primera señal de alerta comunitariaAparecen antes que cualquier medición formalSin línea base ni control estadísticoBenchmark público general sin calibrar (MMLU, GPQA)Para comparar modelos distintos entre sí una vezYa existe, no hay que diseñarloLa mayoría de preguntas siempre se acierta o siempre se falla, el ruido tapa cambios chicosBenchmark propio calibrado, al estilo LiveNerfPara vigilar un modelo específico durante semanasDetecta cambios de pocos puntos con significancia estadísticaExige diseño previo y meses de corridas diarias antes del primer veredicto
Profundizando: la estadística detrás del veredicto
La métrica principal de LiveNerf es la diferencia pareada por ítem contra la línea base, con errores estándar agrupados, siguiendo el enfoque que Anthropic describe en su investigación sobre márgenes de error en evaluaciones. Agrupar por pregunta hace que la dificultad de cada ítem se cancele en la resta, en vez de sumarse como ruido extra.
El proyecto documenta también sus propios problemas de datos: una auditoría de las 78 preguntas del panel (más 2 excluidas después) encontró 8 respuestas correctas que parecen erróneas y 30 preguntas ambiguas. En vez de descartar esas preguntas sin más, el diseño incluye un análisis de sensibilidad pre-registrado que recalcula el resultado sin ellas, documentado en su archivo de pre-registro. Esa disciplina, más que el resultado final, es lo que separa una medición seria de una anécdota con gráfico.
El cronograma es largo a propósito: los primeros diez días son solo línea base, después vienen dos ventanas de diez días cada una, y la primera comparación posible cae recién alrededor del 24 de octubre de 2026, con la primera fila de resultados publicada después del día 20.
📖 Resumen en Telegram: Ver resumen
Tu próximo paso: cloná el repositorio de LiveNerf, corré uv sync y revisá docs/DESIGN.md para replicar el mismo filtro de 'a veces acierta' con un set de preguntas propio.
Preguntas frecuentes
¿Qué diferencia hay entre model drift y un mal día puntual del modelo?
Un mal día es ruido de una sola muestra; el model drift es una diferencia que se sostiene contra una línea base fija, con suficientes corridas como para que el error estándar la respalde.
¿LiveNerf necesita acceso a la API de Anthropic?
No. Corre sobre una suscripción a Claude Max usando la CLI headless de Claude Code (claude -p), sin API key.
¿Cuántos días hay que esperar para tener un veredicto con LiveNerf?
Diez días de línea base y luego ventanas de diez días cada una; la primera comparación posible cae alrededor del 24 de octubre de 2026.
¿La degradación de modelos de IA afecta igual a modelos abiertos y cerrados?
El método de LiveNerf no distingue entre ambos por diseño: cualquier modelo servido por una API o una CLI fija puede auditarse igual, siempre que el proveedor no cambie el prompt ni el harness.
¿Puedo adaptar el método de LiveNerf a otro proveedor como OpenAI o Google?
Sí, la parte estadística (comparación pareada con errores agrupados) es independiente del proveedor; lo que cambia es cómo se dispara la corrida diaria sin usar una API con parámetros de sampling variables.
¿Qué pasa si el panel de preguntas tiene errores en las respuestas correctas?
LiveNerf documentó 8 posibles respuestas erróneas en su panel y corre un análisis de sensibilidad que recalcula el resultado sin esas preguntas, en vez de ignorarlas.
Referencias
- GitHub - ninjahawk/livenerf: repositorio oficial del benchmark, con progreso, metodología y logs.- Inspect (UK AI Security Institute): framework de evaluación abierto sobre el que corre LiveNerf.- Anthropic Research: metodología de errores estándar para evaluaciones de modelos.- Wikipedia: Concept drift: concepto estadístico relacionado con el cambio de rendimiento de un modelo a lo largo del tiempo.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)