Modelos de razonamiento: cómo funcionan, qué mejoran y qué límites muestran

Los modelos de razonamiento son modelos de lenguaje entrenados para resolver mejor determinadas tareas de varios pasos, a menudo dedicando más cómputo a cada respuesta. Mejoran, entre otros, los resultados en matemáticas y programación, pero sus explicaciones no garantizan que la respuesta sea correcta ni que el proceso descrito refleje lo que realmente ocurrió. Su utilidad debe medirse en una tarea concreta, con un presupuesto y un protocolo explícitos.

Qué se entiende por modelo de razonamiento

La expresión designa una familia de comportamientos y métodos de entrenamiento, no una arquitectura única. Un modelo puede descomponer un problema, explorar una hipótesis, detectar una contradicción y empezar de nuevo antes de responder. Aquí, la palabra razonamiento describe una capacidad evaluada; por sí sola no demuestra una equivalencia con el pensamiento humano.

Conviene distinguir la respuesta dirigida al usuario de los pasos intermedios que se generan para prepararla. Estos pasos suelen formar una cadena de pensamiento. Según el sistema, pueden mostrarse, ocultarse o sustituirse por un resumen: la interfaz no revela necesariamente todo el cómputo realizado.

El trabajo de Jason Wei y sus coautores, publicado inicialmente en enero de 2022, muestra que incluir ejemplos de resoluciones detalladas en el contexto puede mejorar el rendimiento en tareas aritméticas, simbólicas y de sentido común. Este método de chain-of-thought prompting cambia la forma de solicitar una respuesta a un modelo ya entrenado.

Un entrenamiento especializado va más allá: busca que esos comportamientos útiles aparezcan con mayor frecuencia. Por tanto, añadir una instrucción que pida reflexionar no reproduce automáticamente las capacidades de un modelo entrenado para hacerlo.

Esta página se centra en esos mecanismos y en sus resultados observables. El artículo relacionado ¿Los LLM razonan realmente? aborda de forma más directa el vocabulario empleado y sus posibles interpretaciones.

Cómo favorece el entrenamiento los pasos útiles

El preentrenamiento proporciona al modelo patrones lingüísticos, conocimientos y ejemplos de resolución. Después, el entrenamiento posterior busca orientar su comportamiento: seguir una solicitud, presentar una respuesta aprovechable o resolver más problemas. Los modelos de razonamiento parten de esta base, con procedimientos que varían según el equipo que los desarrolla.

El aprendizaje supervisado consiste en entrenar el modelo con ejemplos de respuestas o de procesos de resolución. En el aprendizaje por refuerzo, el modelo genera intentos y recibe una señal de recompensa que modifica las probabilidades de sus comportamientos futuros. Una respuesta matemática verificable o un programa sometido a pruebas ofrece una señal que puede comprobarse de manera más directa que una valoración general del estilo.

En su publicación inicial de enero de 2025, los investigadores de DeepSeek describen DeepSeek-R1-Zero, entrenado mediante refuerzo sin una fase previa de ajuste supervisado. Observan comportamientos de comprobación y revisión, pero también problemas de legibilidad y mezcla de idiomas. DeepSeek-R1 combina después varias etapas de entrenamiento y datos iniciales de resolución. Aquí se presentan como ejemplos históricos documentados, no como recomendaciones de productos actuales.

Sin embargo, una recompensa basada en la respuesta final no garantiza que cada paso sea válido. El resultado puede ser correcto pese a una justificación defectuosa; un verificador incompleto también puede aceptar una solución inadecuada. Por eso hay que examinar qué recompensa realmente el entrenamiento.

La destilación ofrece otra vía: un modelo aprende a partir de respuestas generadas por otro. Una mejora obtenida de este modo aporta información sobre las capacidades transferidas, pero no demuestra que ambos sistemas utilicen exactamente los mismos mecanismos internos.

Más cómputo al preparar la respuesta

El cómputo de entrenamiento se consume antes de que usted envíe su solicitud. El cómputo de inferencia se consume cuando un sistema la procesa. Dedicar más tiempo a preparar una respuesta traslada, por tanto, parte del esfuerzo al momento de uso, con un costo que se repite en cada solicitud.

Existen varias estrategias:

• Profundizar en un intento: desarrollar pasos intermedios, comprobar un resultado y corregir una vía de resolución.
• Generar más intentos: producir varias soluciones y compararlas después.
• Seleccionar mediante un verificador: evaluar las respuestas candidatas con pruebas, reglas o un modelo especializado.
• Utilizar una herramienta: ejecutar un cálculo o un programa y aprovechar su resultado.

Estas estrategias no son intercambiables. Varios intentos pueden repetir el mismo error; una votación por mayoría no constituye una demostración. Un verificador aporta valor sobre todo cuando distingue de forma efectiva las soluciones correctas de las que solo parecen plausibles.

En su estudio de agosto de 2024, Charlie Snell y sus coautores muestran que la eficacia del cómputo adicional depende de la dificultad del problema y del método utilizado para asignar los recursos. Su trabajo sobre el cómputo en la inferencia estudia, entre otras vías, la búsqueda guiada por un verificador y la revisión de respuestas. No respalda una regla universal según la cual esperar más siempre mejora el resultado.

También hay que distinguir entre cómputo adicional y aprendizaje adicional. Generar una resolución extensa no implica necesariamente modificar los pesos del modelo. Nuestra página sobre la adaptación en el momento de la prueba explica esta diferencia entre aprovechar el contexto, buscar soluciones y adaptar los parámetros.

Respuesta directa, razonamiento prolongado y herramientas

Para elegir una configuración, compare sistemas completos en lugar de guiarse por sus etiquetas. Una respuesta directa puede bastar para extraer información; una búsqueda más larga puede ayudar con un problema ambiguo; un cálculo exacto puede requerir una herramienta especializada.

Criterio	Respuesta directa	Razonamiento prolongado	Razonamiento con herramientas
Trabajo realizado	Genera una respuesta rápidamente	Explora y revisa pasos intermedios	Añade observaciones o ejecuciones externas
Uso que conviene evaluar	Reformulación, extracción, solicitud sencilla	Problema con restricciones, resolución de varios pasos	Cálculo exacto, pruebas de código, consulta de datos
Comprobación posible	Comparación con una referencia	Verificación del resultado y de los pasos útiles	Inspección de los resultados de las herramientas y del resultado final
Recursos que deben contabilizarse	Entrada y generación	Preparación y generación adicionales	Llamadas al modelo, herramientas e infraestructura
Límite habitual	Respuesta demasiado precipitada	Exploración extensa pero equivocada	Herramienta inadecuada, entrada incorrecta o interpretación errónea

La tabla sirve como guía para elegir, no como clasificación de rendimiento. Las diferencias entre columnas también pueden darse dentro de un mismo sistema, que adapta su esfuerzo a cada solicitud.

Piense en un ejemplo hipotético: necesita explicar una diferencia entre dos totales contables. El modelo puede proponer hipótesis, pero hay que contrastarlas con los registros correspondientes. Un cálculo ejecutado sobre los datos permite una comprobación más sólida que una explicación convincente basada en importes supuestos.

El procedimiento adecuado consiste en identificar los datos necesarios, realizar la conciliación y presentar las diferencias que puedan verificarse. El razonamiento organiza el trabajo; los documentos y los cálculos sustentan el resultado.

Qué permiten afirmar las mejoras publicadas

Las tareas cuyo resultado puede verificarse ofrecen evidencias especialmente claras. Una respuesta numérica, una solución que cumple unas restricciones o un programa que supera unas pruebas permiten medir algo más que la calidad de la redacción.

En el informe inicial de DeepSeek-R1, de enero de 2025, los autores anuncian que, en su experimento de aprendizaje por refuerzo, R1-Zero pasa del 15,6 % al 71,0 % en AIME 2024. El mismo informe atribuye a R1 un 79,8 % en esa evaluación. Son resultados publicados por los autores dentro de su protocolo histórico, no mediciones de los modelos disponibles en octubre de 2026.

La métrica pass@1 estima el éxito de un intento según las condiciones de muestreo de la evaluación. No debe confundirse con un procedimiento que genera varios candidatos y después selecciona una respuesta. El número de intentos y el método de selección forman parte del resultado.

Estos datos respaldan una conclusión acotada: algunos métodos de entrenamiento mejoran considerablemente la resolución de problemas verificables. No permiten atribuir la misma fiabilidad a una auditoría documental, una decisión comercial o una tarea de desarrollo de software abierta.

Para aplicarlos a su caso, identifique qué mide la puntuación: una respuesta final, un programa funcional, una demostración completa o la selección entre varias propuestas. Revise también las condiciones del experimento. La guía para interpretar las clasificaciones de LLM explica por qué porcentajes parecidos pueden corresponder a protocolos distintos.

Los límites aparecen cuando cambia la complejidad

Una media no muestra cómo evolucionan los errores a medida que aumenta la dificultad. Un sistema puede resolver una familia de problemas sencillos, mejorar en los casos intermedios y fallar cuando crece el número de restricciones o la longitud de la solución.

El estudio de Apple The Illusion of Thinking, de junio de 2025 utiliza rompecabezas controlables para variar esa complejidad. Los autores describen distintos regímenes: ventaja de los modelos estándar en algunas tareas sencillas, beneficio del razonamiento prolongado con una dificultad intermedia y, después, un desplome del rendimiento en los niveles de dificultad elevados de sus experimentos. También observan una reducción del esfuerzo generado a partir de determinados umbrales.

El alcance de estos resultados depende del diseño de la prueba. Pedir una lista exhaustiva de movimientos no evalúa exactamente la misma capacidad que pedir un algoritmo capaz de producirla. Hay que distinguir entre una salida interrumpida, una infracción de las reglas y un problema imposible de resolver.

En Rethinking the Illusion of Thinking, de julio de 2025, Iñaki Dellibarda Varela y sus coautores reexaminan las torres de Hanói y los problemas de cruce de ríos. Describen tanto dificultades que persisten en Hanói tras modificar el protocolo como la presencia de configuraciones sin solución en las pruebas de cruce.

Este desacuerdo impide emitir veredictos demasiado amplios. Los fallos medidos requieren una explicación; sus causas pueden combinar capacidades del modelo, restricciones de salida y diseño de la prueba. Para obtener una evaluación útil, varíe por separado la dificultad, el formato de respuesta y el acceso a herramientas. Después, clasifique los errores antes de agruparlos en un único resultado.

Una explicación detallada puede ocultar su causa

Hay que distinguir entre la corrección de una respuesta y la fidelidad de su explicación. Una respuesta puede ser correcta y tener una explicación incompleta. Una explicación coherente también puede justificar a posteriori una elección influida por una pista sin reconocer esa influencia.

En un estudio publicado en abril de 2025, los investigadores de Anthropic introducen pistas en las solicitudes y después examinan si los modelos reconocen su influencia. En las condiciones probadas, Claude 3.7 Sonnet menciona, de media, las pistas utilizadas en el 25 % de los casos, frente al 39 % de R1. Estas proporciones describen ese experimento, no una tasa universal de transparencia.

Leer una cadena de pensamiento puede aportar información, pero no equivale a realizar una auditoría completa. Un paso aparentemente razonable no demuestra por sí solo por qué el modelo eligió su respuesta.

Para un uso profesional, solicite elementos que puedan comprobarse: supuestos explícitos, fuentes consultadas, cálculos reproducibles, pruebas ejecutadas y aspectos que siguen siendo inciertos. Estos elementos sirven para verificar el resultado. No proporcionan un acceso exhaustivo al funcionamiento interno del modelo.

Una alucinación sigue siendo problemática aunque esté rodeada de un desarrollo lógico. Cuando la tarea depende de información ausente o reciente, la prioridad es conseguir una fuente adecuada. Prolongar el razonamiento sobre una premisa falsa puede limitarse a producir un error más elaborado.

Razonamiento y generalización siguen siendo cuestiones distintas

Resolver un ejercicio difícil demuestra una competencia en las condiciones de ese ejercicio. Para evaluar la generalización, también hay que examinar hasta qué punto la tarea es nueva, qué conocimientos previos existen y qué recursos hacen falta para llegar a la solución.

En On the Measure of Intelligence, publicado en noviembre de 2019, François Chollet defiende una definición de inteligencia centrada en la eficiencia para adquirir nuevas habilidades. Distingue esa eficiencia del nivel de habilidad alcanzado tras acumular mucha experiencia. Su propuesta exige tener en cuenta los conocimientos iniciales, la experiencia y la dificultad de generalización.

Aplicada a los modelos de razonamiento, esta distinción lleva a examinar el costo de la búsqueda y los ejemplos disponibles, además de la puntuación final. Es una forma de análisis derivada de ese marco, no un veredicto de aquella publicación sobre sistemas posteriores.

Los trabajos de Snell y DeepSeek se centran más en otra pregunta experimental: qué capacidades adicionales pueden obtenerse mediante el cómputo y el entrenamiento. Estos enfoques aportan resultados útiles, pero no bastan por sí solos para resolver toda la cuestión de la inteligencia general.

Una mejora puede, por tanto, ser relevante para un usuario y dejar abierta su interpretación científica. La página sobre la generalización según François Chollet desarrolla este marco; el dossier sobre AGI e investigación reúne otros enfoques de medición.

Medir el costo por resultado aceptable

Un razonamiento más largo consume recursos adicionales, pero la cantidad de texto visible no basta para estimarlos. Hay que revisar los contadores que realmente ofrece el servicio utilizado y sus reglas de facturación. Una respuesta final breve puede haber requerido una preparación considerable.

Para comparar dos configuraciones, mida el costo total de las tareas y divídalo entre el número de resultados aceptables. Una configuración más cara por llamada puede resultar conveniente si evita repetir trabajo. En cambio, una configuración rápida puede ser preferible cuando la comprobación es sencilla y los errores se corrigen con facilidad.

La latencia debe evaluarse por separado. Una resolución que tarda más puede encajar en un análisis preparatorio, pero dificultar una interacción en la que el usuario espera una respuesta inmediata. El plazo máximo aceptable depende del trabajo, no solo del rendimiento del modelo.

Establezca condiciones para detener el proceso: presupuesto agotado, tiempo excedido, falta de avances o necesidad de información que no está disponible. Un nuevo intento solo aporta valor si ofrece otra vía de resolución o una observación útil.

La calculadora de precios de LLM ayuda a estimar los gastos a partir de los volúmenes medidos. Añada después las herramientas, la infraestructura y el tiempo de revisión: el precio de los tokens representa solo una parte del costo del trabajo terminado.

Evaluar un modelo con sus propias tareas

Empiece por definir qué considera un resultado aceptable antes de comparar configuraciones. Para una extracción, puede ser la exactitud de los campos y el tratamiento explícito de los valores ausentes. Para el código, incluye el comportamiento esperado, las pruebas pertinentes y la ausencia de modificaciones no deseadas.

Prepare un conjunto de casos representativos: solicitudes habituales, restricciones contradictorias, información ausente y ejemplos que exijan una comprobación externa. Reserve una parte de los casos durante los ajustes, para evitar optimizar únicamente las solicitudes que ya conoce.

Compare después una configuración sencilla, otra con más razonamiento y, si la tarea lo justifica, una configuración con herramientas. Mantenga los mismos datos y criterios de éxito. Si cambia a la vez el modelo, el contexto y las herramientas, evaluará el sistema en su conjunto sin poder aislar la causa de la mejora.

Registre para cada intento:

• el éxito según una regla explícita;
• el tipo y la gravedad de los errores;
• el costo total y la duración;
• las intervenciones humanas necesarias;
• las evidencias que permiten comprobar el resultado.

Repita los casos sensibles para observar la variabilidad. Revise también los errores compartidos por las distintas configuraciones: que las respuestas coincidan no constituye una validación independiente. Por último, resolver mejor una tarea no concede automáticamente permiso para actuar; los permisos deben seguir ajustándose a las posibles consecuencias.

Puntos clave

• Un modelo de razonamiento combina capacidades aprendidas con una forma de asignar cómputo a la resolución.
• Las mejoras publicadas deben vincularse a su tarea, su fecha y su protocolo.
• Una cadena de pensamiento legible no garantiza la veracidad ni una transparencia completa.
• La mejor elección reduce el costo de obtener un resultado verificado dentro del plazo aceptable para su uso.

Preguntas frecuentes

¿Un modelo de razonamiento aprende en cada conversación?

Generar pasos intermedios no significa modificar sus parámetros. El modelo puede aprovechar los ejemplos presentes en su contexto sin adquirir un aprendizaje duradero. Modificar los pesos durante la prueba requiere un mecanismo adicional, que debe documentarse por separado.

¿Conviene activar siempre el nivel máximo de razonamiento?

Reserve esta opción para las tareas en las que una evaluación demuestre que aporta una mejora. En una solicitud sencilla, el principal efecto puede ser una mayor demora. Establezca también un límite de tiempo o de costo adecuado para su uso.

¿Se puede verificar una respuesta sin ver la cadena de pensamiento?

Sí: puede comprobar las fuentes, ejecutar el programa propuesto o revisar una demostración. Una justificación breve y reproducible puede resultar más útil que una larga explicación de los pasos intermedios. La comprobación debe centrarse en los elementos que sustentan el resultado.

¿Puede ejecutarse un modelo de razonamiento en local?

Sí, siempre que sus pesos estén disponibles y su equipo permita ejecutarlo. La memoria necesaria depende del modelo, de cómo se representen sus pesos y del contexto utilizado. Generar muchos pasos intermedios también aumenta el tiempo de cómputo.

¿Un buen resultado en matemáticas demuestra que el modelo es una AGI?

No: demuestra una capacidad dentro de una evaluación concreta. Una afirmación más amplia exige pruebas variadas, tareas nuevas y un control de los recursos y los conocimientos previos. El resultado por sí solo no permite esa extrapolación.