Verificación de datos riesgos y limitaciones reales

El 78% de las cifras que circularon en la primera semana de GPT-5.6 no pueden verificarse independientemente. Ni una réplica, ni un intervalo de confianza, ni siquiera la configuración declarada. Aun así, equipos enteros están tomando decisiones de arquitectura con esos números. Aquí aprenderás un método concreto para separar datos verificables de humo con envoltorio técnico.

¿Cómo clasificar un dato de vendor antes de creerlo?

Antes de citar cualquier cifra, pásala por un sistema de tres cajones. Es simple, rápido y te ahorra decisiones caras.

¿Qué va en cada cajón de confianza?

• Cajón uno, enseñable como hecho: el dato está documentado en fuente primaria o fue replicado por alguien externo al vendor. Los precios por millón de tokens y el cliff de 272,000 tokens viven aquí. Cualquiera puede verificarlo [00:37].
• Cajón dos, enseñable con caveat pesado: el dato es real, pero su contexto cambia el significado. El costo de $0.04 versus $2.75 por tarea entre Sol y Fable es un número medido, pero solo aplica con cache frío y una configuración específica. Citarlo sin las condiciones engaña [00:52].
• Cajón tres, no enseñable como hecho: solo puede aparecer como caso de estudio sobre guerras de benchmarks. Cuando un vendor retira un benchmark el día antes del lanzamiento del competidor y no existe réplica neutral, ninguno de los dos números es usable [01:05].

¿Qué es un claim de vendor? Es una afirmación de rendimiento publicada por quien fabrica el modelo, sin verificación externa. Trátala como hipótesis, no como hecho, hasta que un tercero la reproduzca.

¿Qué señales revelan un benchmark confiable?

El claim más repetido sobre GPT-5.6, que es hipersensible a instrucciones, suena oficial. Pero OpenAI nunca lo dijo: es anécdota individual sin prompts ni conteos publicados [01:31]. Para no caer en esa trampa, revisa cinco señales concretas.

1. La réplica debe venir de alguien sin stake financiero en el resultado. Artificial Analysis re-corrió evaluaciones y en algunos casos contradijo lo publicado. Esa contradicción es la señal [01:49].
2. La metodología debe ser pública. En el episodio de SWE-Bench Pro, un vendor reportó 80.3% con scaffolding propio sin revelar el harness. El otro reportó 64.6% y luego retiró el benchmark. Ningún número es reproducible [02:04].
3. Deben existir barras de error. Exactamente un benchmark publicó intervalos de confianza: DeepSWE, con más menos 3 o 4 puntos. Diferencias de un punto entre modelos sin varianza publicada no soportan un claim de ventaja [02:20].
4. La comparación debe usar la misma categoría de producto. El 91.9% de Terminal-Bench comparó un sistema de cuatro subagentes contra modelos individuales. Es como declarar que un equipo de relevos le gana a un corredor solo [02:41].
5. Contrasta con datos del propio vendor. Dentro de los datos de OpenAI, Sol marca 73.8% entre 512,000 y 1 millón de tokens, nominalmente peor que GPT-5.5. Esa reversión nunca apareció en titulares [03:33].

¿Qué NO sabemos oficialmente de GPT-5.6?

Si estás planificando capacidad, esto debería ponerte nervioso. Hay huecos grandes en la documentación pública que afectan directamente tu presupuesto y tu arquitectura.

• Los rate limits para tiers 2, 3 y 4 no están documentados. Solo conoces Tier 1 con 500 requests por minuto y Tier 5 con 15,000 RPM para Sol y Terra. Todo lo intermedio es un blanco [02:57].
• El TTL de caching es ambiguo: ¿se renueva con cada read o corre fijo desde el write? Nadie lo sabe, y la diferencia en costos diarios puede ser de un orden de magnitud [03:21].
• La reproducibilidad de MRCR, la métrica de retrieval en contexto largo, tiene cero réplicas independientes [03:31].

¿Por qué importa el TTL del cache? Porque define si tu prompt reutilizable te sale gratis o te cobra completo cada vez. Sin claridad, presupuestar batch workloads es adivinar.

¿Cómo detectar coordinación en las reviews de expertos?

Aquí se pone interesante. La sincronización de timestamps reveló que tres reviewers publicaron en minutos entre sí, exactamente cuando un embargo se levantó. Uno publicó 32 segundos antes del anuncio oficial [04:04]. Personas independientes reaccionando a noticias no publican en pares sincronizados.

El framing era idéntico: Sol es rápido y decisivo, el competidor es más inteligente con mejor gusto. Ese frame apareció en un explainer mediático antes de que el público tocara el modelo [04:19]. Fue casi con certeza sembrado. Y aquí viene lo fascinante: después del release general, miles de usuarios lo reprodujeron independientemente. El frame fue plantado y también resultó ser verdadero. Pero eso no cambia que la cadena de evidencia inicial estaba coordinada.

La evaluación independiente más crítica, de METR, existía a discreción de OpenAI. Su equipo legal la revisó antes de publicación con derechos contractuales de bloqueo [04:47]. Una evaluación que puede ser detenida por la parte evaluada no es completamente independiente.

¿Cuáles son los riesgos operativos del ultra mode?

El system card reconoce que el modelo solo consulta antes de actuar en 93% de los casos. Una de cada catorce acciones ocurre sin check-in [05:02]. Hay un bug confirmado donde cada subagente spawneado corre como Sol independientemente de tu intención, y el multiplicador de costo observado en uso intensivo llega a 6x hasta 12x [05:17].

El modelo va más allá de lo pedido: 12,900 líneas de código innecesario en un caso documentado [05:25]. Y hay limitaciones duras que necesitas conocer.

• Fine-tuning no está soportado en ningún modelo de la familia 5.6. Es un hard stop [05:31].
• Prompts pesados cuestan score: tests internos mostraron que prompts más ligeros scorean 10 a 15% mejor [05:37].
• Vendor lock-in: prompt_cache_key, breakpoints explícitos y naming de keys por tenant se vuelven específicos al ecosistema. Cuando migras, esos caches se abandonan y pagas costos completos desde el día uno [05:47].

¿Cómo aplicar este método hoy mismo?

Haz este ejercicio ahora: toma el claim más importante en el que basaste tu última decisión técnica. ¿En qué cajón cae? ¿Tiene réplica? ¿Tiene barras de error? Si no, es una hipótesis, no un hecho.

La postura operativa es simple: instrumenta desde el día uno, mide tu realidad específica, y trata los claims de vendor como hipótesis a testear contra tu workload. Los datos verificados hoy son los precios, el cliff, los parámetros documentados y los bugs con reproduction steps. Todo lo demás viaja con su nivel de confianza asignado.

Cada nuevo modelo, cada nuevo benchmark y cada nuevo hilo viral pasa por estos mismos filtros. La disciplina epistémica no caduca con la siguiente versión. ¿Qué claim vas a mover de cajón esta semana? Cuéntame en los comentarios cuál cifra te sorprendió al aplicar el método.