Por qué no deberías leer los thinking traces de un LLM

Cuando le pedís a un modelo como o3, Claude Opus 5 o DeepSeek-R1 que resuelva un problema de matemática, lo que obtenés es un bloque de texto que arranca con frases del estilo "hmm, a ver...", "esperá que me confundo...", "voy por otro camino..." y termina con una respuesta. Esa primera parte es lo que la industria llama "thinking trace" o "reasoning trace". Durante mucho tiempo se asumió que leer ese trace era como mirar por encima del hombro a alguien resolviendo un problema: si ves que se traba o que llega a la respuesta por un atajo raro, podés juzgar la calidad del resultado.

Un position paper aceptado en ICML 2026, escrito por Subbarao Kambhampati y un equipo de Arizona State University (arXiv:2504.09762), argumenta que esa lectura es equivocada y peligrosa. El paper se titula, sin rodeos, Stop Anthropomorphizing Intermediate Tokens as Reasoning/Thinking Traces! — "Dejen de antropomorfizar los tokens intermedios como traces de razonamiento o pensamiento". En este post te cuento qué dicen los autores, qué evidencia aportan, qué contestó la comunidad en Hacker News cuando se publicó la versión revisada, y por qué esto cambia la forma en que tenés que usar estos modelos en producción.

Qué son en realidad los thinking traces

Los autores proponen usar un término neutral: derivational trace (traza derivacional). El flujo real es este:

1. El modelo recibe la pregunta.
2. Emite una secuencia larga de tokens antes de la respuesta — eso es el "trace".
3. Emite una secuencia final delimitada, la "answer".
4. Un verificador formal (no el LLM) chequea si la respuesta es correcta.
5. Solo el veredicto del verificador ajusta los pesos del modelo en entrenamiento.

Lo crítico está en el punto 5: al modelo no se le entrena para que el trace sea correcto. Solo se le entrena para que la respuesta final sea correcta. Si el trace dice "voy a probar X", y X estaba mal, pero después de seis párrafos de idas y vueltas el modelo termina acertando por motivos distintos a los que dijo, el entrenamiento premia el resultado, no la narrativa.

Los autores lo dicen textual: "there is no guarantee of trace correctness". No es un descuido de DeepSeek o de OpenAI — es una propiedad de cómo se entrenan estos modelos. OpenAI ni siquiera muestra el trace crudo de o1; te da un resumen editado. Y si te detenés a pensar, el motivo puede ser exactamente este: los traces originales no son interpretables y son ruidosos. DeepSeek-R1 los muestra tal cual salen, y el paper apunta que "a menudo se extienden por páginas, incluso para problemas simples".

Por qué el término "razonamiento" es un problema

La palabra "razonamiento" no es decorativa. Implica que lo que estás leyendo es:

• Una representación fiel del cómputo que hizo el modelo.
• Una ventana a su proceso de toma de decisiones.
• Algo que podés auditar para entender por qué llegó a una conclusión.

El paper argumenta que las tres son falsas. Los traces son intermediate token generation (ITG) — generación de tokens intermedios — y sirven de andamiaje para que el modelo ajuste su propia distribución de salida hacia la respuesta correcta, no para que un humano pueda verificar nada.

El ejemplo más claro que dan los autores es el famoso "aha moment" en los traces de DeepSeek-R1. Cuando el modelo escribe algo como "¡Ah, ya lo veo!", nosotros leemos eso como un súbito cambio de estado mental, como cuando a vos te cae una ficha. Pero el modelo no tiene un estado interno distinto antes y después del "aha": lo único que cambió fue que el token "aha" se agregó al contexto que verá el próximo forward pass. No hubo un click, no hubo un insight, hubo una palabra. Tratar eso como un momento significativo es exactamente el tipo de antropomorfización que el paper cuestiona.

La evidencia concreta que mencionan

El paper no se queda en la tesis — cita una serie de trabajos que muestran la desconexión entre trace y resultado:

• Estudios que inyectan errores deliberados en los traces para ver si el modelo "se da cuenta" — y no se da.
• Trabajos que demuestran que podés cambiar el trace sin que cambie la respuesta, o viceversa.
• Análisis que muestran que los traces son útiles para el modelo como andamiaje pero no como explicación verificable.

La conclusión operativa es: los traces tienen una correlación laxa con la corrección de la respuesta final, y la forma en que los presentamos al usuario — como "acá está pensando en tiempo real" — induce a confiar en ellos como si fueran una explicación cuando en el mejor de los casos son un borrador descartable.

Lo que dijo Hacker News

El thread donde se discutió el paper el 19 de agosto (104 puntos) recogió reacciones interesantes. Un comentarista con experiencia práctica lo resumió así: "Los thinking traces deberían tratarse como cajas negras. No tiene sentido leerlos. Solo la conclusión del LLM importa. Esto es particularmente cierto en Opus 5, que usa razonamiento que parece muy cuestionable pero llega a conclusiones excelentes".

Otro lo planteó con humor: "Llevo tiempo llamándolos monólogos internos de film noir dentro de los documentos que genera el LLM, que parecen guiones de película. 'Mantené el queso en tu pizza con pegamento' es el mismo problema sea un personaje diciéndolo en voz alta o no". O sea: la forma narrativa del trace no le agrega confiabilidad al contenido.

Y hubo una observación de ingeniería que me pareció la más útil de toda la discusión: si los intermediate tokens no son una representación fiel del cómputo, entonces son un artefacto de auditoría muy malo. En lugar de pedirle al modelo que explique lo que pensó, lo que hay que hacer es registrar las entradas reales, el modelo/versión/configuración, las observaciones de herramientas y los outputs, y hacer la ejecución lo suficientemente replayable como para poder aislar diferencias entre corridas. El comentario exacto: "don't ask the model to explain what it thought, and instead make the system able to show what actually happened".

Qué cambia para los que usamos estos modelos desde la API

Esta parte es la que más me interesa como developer. Si los traces no son auditables, ¿para qué seguir gastando tokens en emitirlos? Tres implicaciones concretas:

1. Costo. Cada token del trace es un token que pagás. Si no lo vas a leer, podés desactivar la salida extendida en muchos providers y ahorrar 30-50% del costo por request en reasoning tasks. El paper de Graft que cubrí hace una semana (graft-capa-contexto-coding-agents-42-menos-tokens) mostraba una economía similar — el costo de los coding agents escala exponencial porque pagamos por tokens de contexto que no aportan. El mismo principio aplica acá.

2. Decisiones de producto. Si estás armando un sistema agéntico que usa un modelo con reasoning, no muestres el trace al usuario final. Mostrá solo la respuesta. Si necesitás un audit trail, capturá el trace internamente pero no lo presentes como "te explico qué hizo". Como dice el paper, es una racionalización post-facto, no una exposición del cómputo real.

3. Debugging. Si tu agente está fallando y querés entender por qué, el trace no es donde tenés que mirar. El trace te dice qué palabras emitió el modelo; lo que necesitás es la secuencia reproducible de llamadas a herramientas, sus inputs, sus outputs, y la decisión de qué hacer después. Eso sí es auditable. El trace es decorado.

En resumen: el trace no es el razonamiento. Es el soporte que usa el modelo para llegar a la respuesta. La diferencia entre ambos es la misma que hay entre los borradores tachados de un escritor y el pensamiento que llevó a la frase final: los borradores existen, pero no son la fuente de verdad sobre por qué la frase dice lo que dice.

Qué queda abierto

El paper deja varias preguntas sin cerrar, y los autores son honestos al respecto:

• Si los traces no son audit del cómputo, ¿qué los hace mejorar la performance? La hipótesis que manejan es que proveen un andamiaje para que el modelo encaje mejor sus soluciones — un "scaffold" para self-fit. Pero no tienen demostración formal de por qué funciona.
• La posición es sobre tokens intermedios crudos, no sobre las racionalizaciones post-facto que a veces da OpenAI. Esas últimas son otro problema y caen en otra literatura (Nisbett & Wilson 1977, citado en el paper, sobre humanos que racionalizan decisiones sin acceso real al proceso).
• No niegan que los traces sean legibles — sí niegan que sean fieles.

Lo que el paper sí pide es un cambio de vocabulario y de práctica: dejá de llamarlos "razonamiento" cuando describís lo que hace el modelo en tu paper, en tu blog, en tu README. Llamalos por lo que son: intermediate token generation. Y cuando armes un sistema, tratá los traces como outputs descartables y la ejecución reproducible como la fuente de verdad.

Si querés ir a la fuente, el paper es open access en arXiv (2504.09762) y fue aceptado en ICML 2026. La discusión completa, con las voces críticas incluidas, está en el thread de Hacker News — incluyendo uno que tiró la pulla de que "es bastante salvaje vestir un blog post como paper científico", que también es una conversación válida sobre cómo comunica la academia de AI hoy.

Lecturas relacionadas del blog:

• Graft: capa de contexto para coding agents con 42% menos tokens — el costo de los tokens de reasoning en sistemas agénticos.
• Tokenpocalypse: 4 palancas para bajar el costo de tus coding agents — economía de los traces cuando se usan en agentes.
• Anthropic CRI: medir razonamiento conceptual sin ground truth — otro ángulo sobre cómo medimos lo que los LLMs "razonan".