GPT-5 y Gemini-3 saben más de lo que responden, según Google

El problema no es lo que el modelo sabe, sino lo que te entrega

Un estudio de Google Research y Technion titulado Empty Shelves or Lost Keys? Recall Is the Bottleneck for Parametric Factuality (arXiv:2602.14080) llega a una conclusión incómoda para cualquier founder que esté construyendo producto con LLMs: cuando un modelo «alucina», la mayoría de las veces el dato está dentro de sus parámetros. No es un problema de ignorancia: es un problema de acceso. El paper demostró que modelos frontera como GPT-5 y Gemini-3 codifican entre el 95% y el 98% de los hechos probados, y aun así fallan al responder directamente entre el 26% y el 34% de esos mismos hechos. La buena noticia: dejar que el modelo «piense más» (chain-of-thought) recupera entre el 40% y el 65% de esas respuestas perdidas, según reportó VentureBeat al cubrir el paper.

Para un equipo técnico, esto cambia dónde mirar primero cuando un chatbot empresarial falla.

«Estantes vacíos» vs «llaves perdidas»: el nuevo mapa de fallos

El equipo, integrado por investigadores de Google Research y Technion, introdujo una distinción conceptual clave:

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Estantes vacíos (encoding failure): el hecho nunca se guardó en los parámetros del modelo. Ni siquiera completando el texto original de entrenamiento lo recupera.
Llaves perdidas (recall failure): el dato está dentro del modelo, pero el modelo no logra acceder a él. Completa el texto fuente sin problema, pero no contesta preguntas directas sobre el mismo hecho.
Recuperación con pensamiento (recall with thinking): el dato está codificado pero inaccesible en generación directa; solo aparece cuando el modelo razona paso a paso. Los autores llaman a esto recall facilitation.

La categoría mayoritaria en modelos frontera ya no es la primera. Como escriben los autores, «encoding failures call for pre-training interventions, such as scaling model size or data coverage. Recall failures suggest post-training interventions that often improve how models utilize what they already encode».

Qué midieron exactamente

Para llegar a estas cifras, los investigadores evaluaron 13 LLMs sobre más de 4 millones de respuestas, usando WikiProfile: un benchmark nuevo, público en Hugging Face, con 2.150 hechos extraídos de Wikipedia y probados en múltiples formatos (completado de contexto original, preguntas directas, opción múltiple, preguntas inversas). El costo de perfilar un modelo frontera completo con WikiProfile ronda los USD 500, según VentureBeat.

El hallazgo contraintuitivo: al escalar Gemma3 de 1.000 millones a 27.000 millones de parámetros, las encoding failures bajaron del 85% al 23%. Pero las recall failures subieron, llegando al 40% sin razonamiento explícito. Escalar memoria agranda el depósito, pero también lo hace más difícil de abrir.

¿Por qué fracasan los modelos en lo que sí saben?

El paper identifica tres patrones sistemáticos:

La formulación de la pregunta manda. «¿Dónde tocó Oasis su primer show?» puede fallar aunque «Oasis tocó su primer show en el Boardwalk» esté perfectamente codificado. El acceso depende de cómo se acerque el usuario al dato original.
Long-tail olvida más rápido. Los hechos raros se codifican a tasas similares a los populares, pero la brecha de recuperación entre hechos comunes y de cola larga supera el 25% en modelos frontera.
Las preguntas inversas son trampas. Pedir el sujeto en vez del objeto («¿Quién tocó en el Boardwalk?») es mucho más difícil que pedir el objeto. Y aun así, los mismos modelos reconocen la respuesta correcta cuando se les da en formato de opción múltiple. Saben, pero no pueden generar.

Por qué esto importa para tu startup

Si estás construyendo un producto con LLM y la respuesta «incorrecta» te cuesta dinero, reputación o tiempo de ingeniería, este estudio te da tres palancas concretas:

Deja de tirar dinero a RAG antes de tiempo. El paper muestra que hasta el 95–98% de hechos estándar ya están en los parámetros del modelo. Si tu pipeline lanza RAG por defecto ante cada fallo factual, estás pagando latencia y costo de infraestructura para resolver un problema que el modelo ya tenía resuelto internamente. Reserva RAG para datos en tiempo real, knowledge absent o dominios propietarios.
Diseña un primer intento barato y un segundo intento reflexivo. Como el chain-of-thought recupera entre 40% y 65% de las respuestas perdidas, una arquitectura práctica es: llamada rápida de bajo costo → si confianza baja, retry con razonamiento extendido. No gastes tokens de razonamiento en cada query.
Evalúa acceso, no solo exactitud. Un benchmark con accuracy agregada oculta si el modelo codifica el hecho o solo lo adivina. Probar el mismo dato en múltiples formulaciones (pregunta directa, inversa, opción múltiple, completado) revela el perfil real. WikiProfile es código abierto; cualquier equipo puede correrlo.

Cómo implementarlo esta semana

Acciones puntuales que podés aplicar en un sprint corto:

Mide recall failures antes de comprar más GPUs ni más datos. Pasá 100 preguntas representativas de tu dominio por WikiProfile o por un test equivalente: pregunta directa + inversa + opción múltiple. Si el modelo acierta opción múltiple pero falla la pregunta abierta, tenés un problema de prompt, no de modelo.
Añadí un escalón de razonamiento condicional. En tu pipeline, después de la respuesta rápida, corré un clasificador de confianza. Si está por debajo de tu umbral, reintentá con un prompt que pida explícitamente razonamiento paso a paso. Muchos proveedores exponen esta función como «thinking effort» configurable.
Reformulá cuando el modelo falla, en vez de descartar. Como la codificación está ahí pero el acceso depende de la formulación, generá reformulaciones automáticas de la pregunta (paráfrasis, añadir contexto, invertir la dirección) y volvé a preguntar. Esto es recuperación semántica barata, sin RAG.
Perfilá por dominio, no asumas frontera global. El paper advierte que WikiProfile se basa en hechos enciclopédicos. Tu métrica interna (métricas propietarias, jerga de tu industria) puede tener un perfil muy distinto. Construí tu propio WikiProfile interno: 200–500 hechos críticos probados en cuatro formatos.

Limitaciones honestas

El benchmark se construyó sobre Wikipedia, así que los resultados no se traducen directamente a dominios propietarios ultraespecializados (métricas internas, nomenclatura cerrada, regulations específicas). Además, perfilar un modelo frontera cuesta alrededor de USD 500; podés reducirlo omitiendo variantes de opción múltiple o usando menos muestras por pregunta. Pero el insight central — el cuello de botella cambió de almacenamiento a acceso — sí se sostiene: cuando un LLM falla, conviene distinguir «no lo sé» de «no lo encuentro todavía».