Los modelos de razonamiento piensan 20 veces más de lo necesario en 2+3, pero se relajan con lo difícil

Los modelos de lenguaje han aprendido a razonar antes de responder, y enseguida surgió una pregunta que todo ingeniero conoce: ¿cuánto tiempo dedicar a cada tarea? Sherlock Holmes leía la biografía de un cliente en sus manos con solo mirarlo, pero para un caso enrevesado pedía tres pipas y cincuenta minutos de silencio. Su habilidad principal era saber de antemano qué necesitaba cada problema. A los modelos todavía se les da mal.

Piensan de más lo simple

En diciembre de 2024, investigadores de Tencent AI Lab hicieron a modelos de razonamiento una pregunta elemental: «¿cuánto es 2+3?». QwQ-32B-Preview halló la respuesta correcta en 39 tokens, pero no se detuvo: resolvió el problema otras doce veces de distintas maneras y gastó 901 tokens. De media, los modelos de nueva generación consumieron casi veinte veces más tokens que los convencionales para llegar al mismo resultado.

No se trata solo de dinero. Un trabajo de Meta y la Universidad Hebrea, presentado en ICLR 2026, mostró que la cadena de razonamiento más corta de un modelo puede ser un 34,5 % más precisa que la más larga. La precisión crece con la longitud hasta cierto umbral y luego cae; la gráfica se parece a una U invertida. Investigadores de Anthropic añadieron un detalle distractor a un problema sencillo de contar frutas, y cuanto más pensaban Claude Opus 4 y DeepSeek R1, más se equivocaban. A veces el modelo encuentra la respuesta correcta y luego se disuade a sí mismo.

Piensan de menos lo complejo

El problema inverso apareció cuando los desarrolladores empezaron a enseñar a los modelos a ahorrar. En febrero de 2026, Anthropic convirtió el pensamiento adaptativo en el modo predeterminado de Claude Opus 4.6: el modelo decide por sí mismo si piensa en un paso.

En primavera, los programadores empezaron a quejarse de que Claude Code se había vuelto superficial: inventaba versiones de la API de Stripe, hashes de commits y paquetes inexistentes. Boris Cherny, creador de Claude Code, analizó la telemetría y descubrió que en los pasos en que el modelo fabricaba hechos no había gastado ni un token en pensar. Donde pensaba, respondía bien.

Es el clásico problema del bate y la pelota: el sistema rápido da una respuesta verosímil y el lento no se activa, porque el despachador consideró innecesaria la comprobación.

Enseñar a un modelo a elegir el modo es difícil. Primero, los datos para el modo rápido y el de razonamiento difieren mucho, y mezclarlos con descuido produce algo «mediocre en ambas direcciones», como dijo Junyang Lin, de Qwen. Segundo, al entrenar con recompensas, el modelo se atasca pronto en un modo que, de media, da más recompensa.

Qué se está probando

El método Thinkless enseña al modelo a empezar su respuesta con la palabra «corto» o «pensar», separando la recompensa por elegir el modo de la recompensa por la calidad. En problemas de álgebra, el razonamiento se activaba en uno de cada cuatro problemas, se usaban 2,6 veces menos tokens y la precisión caía menos de un uno por ciento. AdaptThink, de Tsinghua, fuerza a responder sin razonamiento en la mitad de los ejemplos. Un modelo de 1500 millones de parámetros pasó a usar entre un 45 y un 65 % menos de tokens y ganó algo de precisión.

La industria ha resuelto la elección de formas distintas. Anthropic empezó con un presupuesto manual en Claude 3.7 Sonnet, pasó a un modo adaptativo y en las versiones 5.x el pensamiento no se puede desactivar: solo queda el nivel de esfuerzo. Alibaba creó el Qwen3 híbrido, lo abandonó y separó Instruct y Thinking, y en Qwen3.5 volvió al híbrido. OpenAI incorporó en GPT-5 un enrutador invisible que falló el día del lanzamiento, y en otoño de 2026 sustituyó Auto por un control deslizante con niveles desde Instant hasta Extra High. DeepSeek unió R1 y V3 en un solo modelo con los modos Non-Think, Think High y Think Max.

Qué hacer en la práctica

Si construyes un producto sobre modelos de razonamiento, no confíes a ciegas en la selección automática de profundidad. Para tareas donde el coste del error es alto (llamadas a API, trabajo con código, datos factuales), fija un nivel de esfuerzo alto y comprueba que el modelo realmente razona en los pasos críticos. Para consultas simples, al contrario, activa el modo rápido: así ahorras tokens y tiempo, y de paso evitas dudas innecesarias. Y mide ambos sesgos, porque un modelo puede equivocarse tanto por exceso de reflexión como por falta de ella.