Un paper de Apple mide límites de los modelos de razonamiento
Un estudio de Apple usa puzles controlables para observar dónde varios modelos de razonamiento pierden precisión y reducen su esfuerzo. El resultado delimita esos entornos, no todo razonamiento de máquina.
El 10 de junio de 2025, investigadores vinculados a Apple publicaron un experimento con puzles controlables sobre modelos de razonamiento. La fuente original sostiene el núcleo documental del hecho; el trabajo observa límites en esos entornos; no prueba que todo razonamiento de máquina sea ilusorio.
Los modelos de razonamiento, conocidos técnicamente como LRM (Large Reasoning Models), son la generación de sistemas que antes de responder generan un proceso de pensamiento explícito, paso a paso, que el usuario puede leer. Esta capacidad ha sido el gran argumento de venta de los últimos meses: modelos que no solo contestan, sino que muestran cómo llegan a la respuesta, y que en teoría deberían resolver mejor problemas matemáticos y lógicos complejos.
Un laboratorio de puzles para medir el pensamiento
Hasta ahora, la mayoría de las evaluaciones de estos modelos se han apoyado en benchmarks de matemáticas y programación que solo miden si la respuesta final es correcta. El problema, señalan los autores, es que esos benchmarks suelen estar contaminados —es decir, es probable que el modelo haya visto ejercicios muy parecidos durante su entrenamiento— y no dicen nada sobre cómo piensa el modelo por dentro.
Para evitarlo, el equipo de Apple diseñó entornos de puzles controlables, como variantes de la Torre de Hanoi, donde se puede subir o bajar la dificultad de forma precisa mientras la estructura lógica del problema se mantiene idéntica. Esto permite algo que los benchmarks tradicionales no ofrecen: aislar el efecto de la complejidad y, de paso, examinar no solo si el modelo acierta, sino el rastro de razonamiento que genera antes de responder.
Tres regímenes y un colapso total
Comparando los LRM con sus versiones estándar equivalentes (modelos sin ese paso explícito de "pensar antes de responder") bajo el mismo presupuesto de cómputo, los autores identifican tres comportamientos distintos según la dificultad del problema:
- Baja complejidad: los modelos estándar, sin razonamiento explícito, rinden mejor que los LRM.
- Complejidad media: aquí sí aparece la ventaja de los modelos de razonamiento, que superan a sus versiones estándar.
- Alta complejidad: ambos tipos de modelo se hunden por igual. El paper habla literalmente de un "colapso completo de precisión" a partir de cierto umbral, con resultados que se acercan al 0% de acierto.
Lo más llamativo, según describen los autores, no es solo que fallen, sino cómo fallan. A medida que un problema se complica, el esfuerzo de razonamiento —medido en la longitud del proceso de pensamiento que genera el modelo— aumenta, como cabría esperar. Pero solo hasta un punto: superado ese umbral, el esfuerzo disminuye, y lo hace pese a que el modelo todavía dispone de margen de tokens para seguir pensando. Es decir, el modelo no se queda sin espacio para razonar más; simplemente deja de intentarlo cuando el problema se vuelve demasiado difícil.
Fallos en el cálculo exacto
El estudio también documenta que estos modelos tienen limitaciones concretas para la computación exacta: no logran aplicar de forma consistente algoritmos explícitos y razonan de manera desigual según la escala del problema, incluso cuando la lógica subyacente no cambia. Los autores profundizan además en los propios rastros de razonamiento, analizando qué soluciones exploran los modelos y cómo se comportan computacionalmente, en un intento de entender mejor sus fortalezas y sus límites reales.
Por qué importa este debate
El título del paper no es casual. "Ilusión del pensamiento" apunta directamente al corazón de la discusión que ha dominado la industria de la IA en el último año: si el proceso de "pensar en voz alta" que muestran estos modelos refleja un razonamiento genuino o es, en la práctica, un patrón aprendido que se derrumba en cuanto el problema deja de parecerse a algo visto en el entrenamiento.
La pregunta no es académica. Empresas y desarrolladores llevan meses adoptando estos modelos de razonamiento precisamente para tareas que exigen fiabilidad en problemas complejos: planificación, depuración de código, análisis financiero o científico. Si el propio rendimiento se desploma más allá de cierta complejidad —y encima el modelo reduce su esfuerzo justo cuando más se necesitaría— conviene calibrar expectativas antes de delegar decisiones críticas en estos sistemas sin supervisión.
El trabajo es, por ahora, un preprint: no ha pasado por revisión de pares ni ha sido publicado en una conferencia. Eso no resta valor a la metodología, pero sí invita a esperar réplicas y contraargumentos de otros laboratorios en las próximas semanas, especialmente de las compañías que desarrollan estos modelos de razonamiento y que tienen mucho en juego en este debate.
Cómo convertir el titular en una comprobación
Un resultado experimental comienza por su variable observable. Hay que anotar qué cuenta como acierto, qué conducta activa una etiqueta y qué casos quedan fuera. el trabajo observa límites en esos entornos; no prueba que todo razonamiento de máquina sea ilusorio. Si el fenómeno no puede reconocerse sin interpretar la intención del modelo, la conclusión necesita todavía más cautela y una definición reproducible.
El protocolo importa tanto como la puntuación. Se documentan instrucciones, herramientas, tiempo, presupuesto de cómputo, número de intentos, selección de ejemplos y regla de corrección. Cambiar cualquiera de esas piezas puede cambiar el resultado sin que el modelo haya aprendido nada nuevo. Por eso comparar dos titulares exige primero comprobar que miden el mismo eje.
Una réplica fuerte intenta romper la conclusión. Añade datos no vistos, variantes pequeñas, controles negativos y tareas donde la respuesta correcta sea abstenerse. Conserva también los fallos, no solo ejemplos elegidos. Para valorar cómo leer dominio, complejidad, métrica y réplica antes de generalizar un benchmark, el conjunto debe parecerse al uso previsto y reflejar el coste de cada clase de error.
Qué debe quedar registrado
El estudio puede enseñar un patrón sin resolver todo el campo. La formulación honesta conserva dominio, muestra y fecha, y evita convertir «observamos» en «demostramos para siempre». La evidencia gana valor cuando otro equipo puede repetirla con los materiales disponibles o explicar qué elemento falta. Esa trazabilidad es más útil que una etiqueta grandiosa.
Una ficha de evidencia separa cuatro columnas: lo que afirma la fuente, lo que muestra, lo que no midió y qué tendría que ocurrir para cambiar la conclusión. Esa disciplina evita que una ausencia se convierta en promesa y que una condición desaparezca al resumir. También permite actualizar la pieza sin reescribir la historia desde el resultado posterior.
Conviene incluir un caso negativo antes de decidir. Se busca una situación donde el sistema, norma, operación o estudio no resuelva la necesidad y se anota la señal que obligaría a parar. Los éxitos seleccionados muestran que algo puede ocurrir; el caso negativo revela el límite y reduce el coste de descubrirlo después del despliegue.
La capacidad que sobrevive al anuncio
La comparación válida conserva denominador y eje. No enfrenta una cifra puntual con un promedio, una capacidad futura con una instalada ni una predicción con una observación. Cuando dos fuentes usan palabras parecidas, se reconstruye qué contaron y durante qué periodo. Si no coinciden, se publican como medidas distintas en vez de fabricar una clasificación.
El registro debe sobrevivir al cambio de versión. Guarda URL, fecha de consulta, documento, configuración y decisión tomada. Al aparecer nueva evidencia, se añade con su fecha y se explica qué modifica. Esa trazabilidad protege contra dos errores opuestos: mantener una conclusión caducada o fingir que un dato posterior ya se conocía el día del hecho.
La capacidad transferible de esta pieza es cómo leer dominio, complejidad, métrica y réplica antes de generalizar un benchmark. El procedimiento es breve: nombrar el documento, conservar la fecha, fijar el eje, buscar la condición y diseñar una comprobación que pueda fallar. Con esos pasos, el lector no necesita aceptar ni rechazar el anuncio por intuición; puede decidir con una cadena visible de evidencia.
Este artículo se ha elaborado con inteligencia artificial bajo supervisión editorial humana.