Saltar a contenido

Razonamiento en LLMs

En un LLM, razonar significa producir o ejecutar cómputo intermedio que ayuda a resolver una tarea antes de emitir la respuesta final. Ese cómputo puede tomar la forma de pasos textuales, búsqueda entre candidatos, uso de herramientas, verificación o iteraciones de corrección.

No es una propiedad binaria. Un modelo puede resolver bien una clase de problemas y fallar ante una variación mínima. También puede llegar a una respuesta correcta con una explicación falsa, o escribir una cadena convincente que termina en un resultado incorrecto.

Por eso conviene separar tres preguntas:

  1. ¿La respuesta final es correcta?
  2. ¿El proceso utilizado es robusto?
  3. ¿La explicación visible refleja realmente ese proceso?

La idea central

CÓMPUTO EN INFERENCIA
Razonar no es escribir una explicación larga: es gastar cómputo para llegar a una decisión mejor
El sistema puede crear estados intermedios, explorar alternativas y verificar resultados antes de responder. La explicación visible es otra capa: puede resumir evidencia, pero no debe confundirse con una traza causal perfecta.
RESPUESTA FINALLa salida que recibe el usuarioPuede incluir una justificación breve y verificable.
TRAZA OPERACIONALLo que realmente ocurriótools · argumentos · resultados · tiempos · cambios de estado
Idea claveCorrección final, robustez del proceso y fidelidad de la explicación son preguntas distintas.
Fuentes: Wei et al. (2022) · Turpin et al. (2023)

Los modelos razonadores modernos dedican más cómputo durante la inferencia. Esa estrategia se conoce como test-time compute o inference-time compute. En lugar de fijar todo el rendimiento durante el entrenamiento, el sistema puede gastar más pasos en consultas difíciles.

La ventaja es capacidad adaptable. El coste aparece en latencia, tokens, variabilidad y operación. La calculadora de coste y latencia LLM permite hacer explícito ese intercambio al comparar modelo, volumen de tokens y tiempo de respuesta bajo distintos supuestos.

Chain of thought

Chain of thought (CoT) induce al modelo a producir pasos intermedios antes de la respuesta. Wei et al. mostraron que ejemplos con razonamientos encadenados podían mejorar el rendimiento de modelos grandes en tareas aritméticas, simbólicas y de sentido común.1

CHAIN OF THOUGHT
Los pasos intermedios pueden ayudar a resolver; no demuestran cómo tomó la decisión el modelo
CoT hace explícita una secuencia intermedia antes de la respuesta. El ejemplo muestra una descomposición útil, pero la explicación visible no debe tratarse como una traza causal perfecta.
UTILIDAD más espacio para variables y dependencias Puede ayudar en tareas donde una solución se beneficia de pasos intermedios.
RIESGO un error temprano puede propagarse Una cadena más larga añade puntos donde una suposición incorrecta puede contaminar lo que sigue.
FIDELIDAD explicación visible ≠ traza causal Evalúa la respuesta y la evidencia; no asumas que cada paso textual revela el mecanismo interno real.
Fuentes primarias: Wei et al. (2022) · Turpin et al. (2023).

La técnica ayuda porque ofrece espacio para representar variables y dependencias. También puede empeorar la respuesta si los primeros pasos contienen un error que se propaga.

La cadena visible tampoco debe tratarse como una traza causal perfecta. Un modelo puede racionalizar una decisión influida por señales que no menciona. Turpin et al. documentaron explicaciones que parecían coherentes pero omitían factores decisivos del prompt.3

La conclusión práctica es clara: una explicación textual puede ser útil para inspección, pero no sustituye a una evaluación de corrección ni a telemetría del sistema.

Self-consistency y muestreo de candidatos

Una respuesta única depende de una trayectoria de generación. Self-consistency genera varias cadenas y elige la respuesta que aparece con mayor consistencia entre ellas.2

SELF-CONSISTENCY
Una trayectoria puede equivocarse; varias permiten estimar qué respuesta es estable
En vez de confiar en una única cadena, se muestrean varias trayectorias y se agregan sus respuestas normalizadas. El método ayuda cuando caminos distintos convergen; no corrige un sesgo compartido por todas las muestras.
CUÁNDO AYUDAerrores parcialmente independientesmúltiples caminos razonables llegan a la misma solución.
CUÁNDO NOsesgo comúnsi todas las muestras comparten el mismo supuesto falso, la votación lo refuerza.
COSTE≈ número de muestrasmás candidatos implican más tokens, latencia y evaluación.
Fuente primaria: Wang et al., Self-Consistency Improves Chain of Thought Reasoning in Language Models (2022).

Esta estrategia funciona cuando existen caminos independientes que convergen en la solución. Su coste crece casi linealmente con el número de muestras y no ayuda si todas comparten el mismo sesgo.

En problemas abiertos, votar texto completo no tiene sentido. Se necesita normalizar respuestas, evaluar candidatos o usar un modelo juez.

Búsqueda y planificación

El razonamiento puede formularse como búsqueda sobre estados posibles. Tree of Thoughts hace explícita esta idea al mantener varias continuaciones intermedias, evaluarlas y decidir qué rama explorar a continuación.4

BÚSQUEDA Y PLANIFICACIÓN
Buscar no es generar más texto: es mantener estados, evaluarlos y decidir qué explorar después
El diagrama abstrae el mecanismo común: generar candidatos, aplicar una señal de evaluación, conservar una frontera y expandir o retroceder hasta encontrar un estado aceptable.
UNA TRAYECTORIA CoT lineal Una decisión temprana condiciona todo lo que sigue.
FRONTERA ACOTADA Beam / best-first Se conservan varios candidatos y la política decide cuál expandir.
ÁRBOL EXPLÍCITO Tree of Thoughts / MCTS La búsqueda puede ramificar, reevaluar y volver a estados anteriores.
CONDICIÓN NECESARIA La búsqueda solo aporta señal si el evaluador distingue estados prometedores de estados plausibles pero malos. Sin una señal útil, aumentar ramas aumenta coste y candidatos; no crea por sí solo una mejor política de selección.
Fuentes primarias: Yao et al. · Tree of Thoughts (2023) · Kocsis & Szepesvári · UCT (2006).

Los algoritmos concretos cambian la política de frontera:

  • beam search: conserva un conjunto acotado de candidatos según una puntuación;
  • Tree of Thoughts: permite ramificar, evaluar y retroceder entre estados intermedios;
  • Monte Carlo Tree Search / UCT: asigna exploración según el valor observado y la incertidumbre de las ramas.5
  • programas o tools: convierten parte del espacio de búsqueda en operaciones verificables;
  • planificación explícita: separa creación del plan y ejecución.

La búsqueda aporta valor cuando hay una señal que distingue estados prometedores. Sin un evaluador fiable, el sistema puede multiplicar candidatos plausibles sin mejorar la selección.

Verificadores y modelos de recompensa

Un verificador puntúa una respuesta, un paso o una trayectoria. La distinción importante es qué parte del proceso puede observar y contra qué fuente de verdad compara. Cuando existe una comprobación ejecutable —tests, solver, esquema o estado externo— esa señal suele ser más directa que pedir a otro modelo una opinión.6

DÓNDE ENTRA LA SEÑAL DE VERIFICACIÓN
Resultado, proceso y ejecución responden preguntas distintas
Elige el verificador más cercano a la verdad observable de la tarea. No todos ven la misma parte de la trayectoria.
01Si existe verdad ejecutable, úsala antes que una opinión generativa.
02Una respuesta correcta no demuestra que la trayectoria fuese correcta.
03Un PRM puntúa pasos observados; no demuestra la causalidad interna del modelo.
Fuentes primarias: Cobbe et al. (2021) · Lightman et al. (2023)

Un verificador de resultado u Outcome Reward Model (ORM) puntúa el outcome final. Es útil cuando la respuesta puede juzgarse de forma fiable, pero no identifica dónde apareció el primer error de una trayectoria. Un Process Reward Model (PRM) puntúa estados o pasos intermedios y ofrece una señal más fina para localizar errores o guiar búsqueda, a cambio de necesitar un criterio fiable a nivel de paso.7

La verificación por proceso tampoco demuestra que una explicación visible sea la traza causal interna del modelo. Evalúa el artefacto intermedio que puede observarse. Para código, ejecutar tests sigue siendo preferible a juzgar la naturalidad de una explicación; para una tool call, conviene validar el esquema y comprobar el efecto real.

Test-time compute

El sistema puede asignar más cómputo de varias formas:

TEST-TIME COMPUTE
El presupuesto de inferencia debe aumentar cuando la tarea lo justifica, no por defecto
Más cómputo puede significar más deliberación, más candidatos, búsqueda, verificadores, tools o revisiones. La política útil es asignar ese presupuesto según dificultad, valor de la respuesta y latencia tolerable.
SEÑALES DE ROUTINGdificultad · incertidumbre · impacto del error · SLA de latencia
PRESUPUESTOtokens · muestras · profundidad · verificadores · tools · revisiones
DECISIÓNparar cuando el valor marginal ya no compensa el coste
No monotónicoMás cómputo también puede amplificar un supuesto falso, provocar deriva del objetivo o añadir latencia sin mejorar la respuesta.
Fuente primaria: Snell et al., Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters (2024).

Snell et al. estudiaron cómo escalar cómputo en inferencia y mostraron que la estrategia óptima depende tanto de la dificultad del problema como de la capacidad del modelo para aprovechar ese presupuesto.8

Más cómputo no produce una mejora monotónica. Puede aparecer:

  • sobrepensamiento
  • deriva del objetivo
  • propagación de un supuesto inicial falso
  • confianza reforzada en una respuesta incorrecta
  • latencia incompatible con la interacción
  • coste superior al de usar directamente un modelo mejor

La política correcta no es “pensar siempre más”. Es rutar el presupuesto según la dificultad y el valor de la respuesta.

Razonamiento visible y razonamiento interno

TRES SUPERFICIES · TRES CONTRATOS DE EVIDENCIA
Pensamiento, explicación y traza operacional no son lo mismo
Una interfaz auditable separa qué señal produce el modelo, qué explicación recibe la persona y qué acciones ocurrieron realmente en el runtime.
ENTRADAtarea + contexto
MODELO + RUNTIMEresolver · decidir · actuar
SALIDArespuesta + efectos
01
CÓMPUTO INTERNO / CoTSeñal intermedia usada durante la resolución
estado→pasos / búsqueda→candidato
PUEDE APORTARseñal útil de monitorización cuando el sistema la expone
NO GARANTIZAque el texto observado sea una traza causal completa de la decisión
SEÑAL DE MODELO
02
JUSTIFICACIÓN AL USUARIOExplica la respuesta con evidencia verificable
datofuente / cita
supuestoqué se da por válido
incertidumbrequé no se sabe
OBJETIVOque una persona pueda comprobar la conclusión sin leer cada paso interno
NO CONFUNDIRuna explicación clara con evidencia de causalidad interna
ARTEFACTO DE COMUNICACIÓN
03
TRAZA OPERACIONALRegistra lo que el sistema hizo fuera del texto
tool→args→resultado→estado
REGISTRAtools, argumentos, resultados, tiempos, permisos y cambios de estado
FUENTE DE VERDADpara responder qué acción ocurrió y qué efecto real produjo
EVIDENCIA DE RUNTIME
¿POR QUÉ AFIRMAS X?citas, datos, supuestos y verificación externa
¿QUÉ ACCIÓN OCURRIÓ?traza del runtime + estado observado
¿QUÉ RAZONAMIENTO USÓ?CoT si está disponible, pero con un contrato explícito de fidelidad limitada
PRINCIPIOLa transparencia útil no consiste en volcar más texto. Consiste en vincular cada afirmación a la superficie de evidencia que realmente puede sostenerla.
Fuentes primarias / oficiales: Turpin et al. (2023) · OpenAI, CoT monitorability (2025) · OpenAI Agents SDK — Tracing

No hace falta mostrar cada token intermedio para ofrecer transparencia. Una explicación larga puede ocultar la evidencia importante; una respuesta auditable debería citar los datos relevantes, exponer supuestos, indicar incertidumbre y registrar las acciones reales fuera del texto mostrado.

Razonamiento con herramientas

Las tools cambian el problema. El modelo ya no necesita simular todas las operaciones dentro de una cadena textual: puede alternar decisiones con acciones sobre un entorno y usar resultados observables para actualizar el siguiente paso.9

FRONTERA DE AUTORIDAD
Una tool call es una propuesta, no un permiso
El modelo puede elegir una acción y construir argumentos. La autoridad para producir un efecto externo sigue en el runtime.
3 · RESULTADO OBSERVABLE { status, id, error? }
4 · ACTUALIZAR ESTADO pending → running → succeeded / failed
5 · SIGUIENTE DECISIÓN continuar · reintentar · responder · parar
PRINCIPIO El modelo propone la acción. El runtime decide si esa acción puede convertirse en un efecto.

Una calculadora reduce errores aritméticos. Un buscador aporta información actual. Un intérprete ejecuta código. Una API permite actuar sobre un sistema externo.

El reto se desplaza hacia el contrato:

  • cuándo llamar
  • con qué argumentos
  • cómo validar
  • qué hacer ante timeout o resultado parcial
  • cómo evitar duplicados
  • cómo reanudar después de una interrupción

La separación importante es operacional: el modelo propone; el runtime valida y ejecuta; el resultado real actualiza el estado; solo entonces se decide el siguiente paso. En implementaciones actuales, los runtimes de agentes exponen precisamente ese bucle y permiten aplicar guardrails alrededor de las tool calls.10 El playground de fiabilidad y evaluación de agentes permite inspeccionar ese tipo de trayectoria separando éxito final, primer intento, retries, timeouts y decisiones de herramientas.

La nota Agente reactivo, proactivo y tool calls desarrolla ese runtime.

El coste humano de la latencia

En un chat, varios segundos pueden ser aceptables si la tarea es compleja. En voz, la misma demora rompe el ritmo conversacional. El explorador de latencia de agentes de voz permite descomponer ese retraso por etapas y comprobar qué componente domina el tiempo hasta la primera respuesta audible.

LATENCIA INTERACTIVA · RELOJES SOLAPADOS
No midas una sola latencia
Marca eventos observables. Conversación, modelo, tools y playback pueden avanzar a la vez; el usuario percibe cuándo oye algo útil y cuándo recibe el resultado.
t₀ · HABLAtermina el turno
t₁ · ENDPOINTfin detectado
t₂ · DECISIÓNprimer paso útil
t₃ · AUDIOprimer audio oído
t₄ · ENTREGAresultado recibido
RELOJ CONVERSACIONAL¿Cuándo vuelve a sentirse viva la interacción?
detección modelo / runtime síntesis + playback
T_first_audio = t(audio_oído) − t(fin_turno)Incluye más que el tiempo del modelo.
RELOJ OPERACIONAL¿Cuándo termina el trabajo que produce el resultado?
dispatch tool / operación entrega
T_operation = t(resultado_listo) − t(inicio_operación)Puede solaparse con una respuesta hablada.
01FIN DE TURNOhabla → endpoint
02PRIMERA DECISIÓNhabla → decisión útil
03PRIMER AUDIOhabla → audio oído
04OPERACIÓNinicio → resultado listo
05ENTREGAhabla → resultado recibido
NO SUMAR A CIEGASLos relojes se solapan: una tool puede seguir mientras la conversación ya continúa.
MEDIR LA COLAUna media oculta esperas raras; conserva la distribución por etapa y por ruta.
BENCHMARK ≠ INTERACCIÓNMás acierto puede no compensar una ruta que tarda demasiado para la superficie de producto.
CONTRATOInstrumenta marcas reales del runtime, la tool y el playback. No infieras experiencia de usuario a partir de “latencia del modelo” solamente.
Fuentes oficiales: OpenAI Realtime API · OpenAI Agents SDK — Tracing

La serie Modelos razonadores y la comparación de arquitecturas para agentes de voz desarrollan estas fronteras con más detalle.

Esta separación evita optimizar solo el benchmark y olvidar la experiencia.

Cómo evaluar razonamiento

Una evaluación robusta no mira solo la exactitud final.

NO MIDAS SOLO LA RESPUESTA FINAL
Seis señales observan partes distintas del mismo sistema
Una evaluación útil conecta cada métrica con el punto del recorrido donde puede aparecer el fallo.
01Corrección
respuesta↔verdad / test

¿Resuelve la tarea y coincide con una referencia o comprobación ejecutable?

MIDE · resultado
02Robustez
AA′A″→consistencia

¿Se mantiene al reformular, añadir ruido o introducir distractores?

MIDE · sensibilidad a la entrada
03Eficiencia
calidad÷tokens · tiempo · coste

¿Qué presupuesto de inferencia necesita para alcanzar esa calidad?

MIDE · recursos del proceso
04Calibración
30
60
90

¿La incertidumbre declarada se relaciona con la frecuencia real de error?

MIDE · confianza frente a error observado
05Fidelidad
explicación↔evidencia observable

¿La justificación está respaldada por la evidencia que puede inspeccionarse?

NO DEMUESTRA · traza causal interna
06Acción
tool call→estado final

¿La acción autorizada, sus argumentos y el efecto externo fueron correctos?

MIDE · ejecución real
ALa exactitud final no cubre robustez, coste ni efectos externos.
BLa explicación visible se evalúa como evidencia observable, no como lectura de la causalidad interna.
CCompara también contra un baseline simple con el mismo contrato de tarea.
Fuentes primarias: Liang et al. · HELM (2022) · Turpin et al. (2023) · OpenAI Agents SDK · Running agents

También hay que comparar contra baselines más simples. A veces una regla, una consulta estructurada o un modelo pequeño con una tool supera a una deliberación larga.

La guía de evaluación de modelos de IA propone cómo construir ese conjunto de pruebas.

Preguntas frecuentes

¿Chain of thought hace que el modelo sea lógico?

No. Ofrece espacio para pasos intermedios y puede mejorar ciertas tareas. Los pasos siguen siendo generados por el modelo y pueden contener saltos, racionalizaciones o errores.

¿Cuanto más razona un modelo, mejor responde?

No siempre. La mejora depende de la tarea, el modelo, el verificador y el presupuesto. En consultas simples, más pasos pueden añadir coste y abrir nuevas oportunidades de error.

¿Un modelo juez puede verificar a otro modelo?

Puede aportar una señal útil, especialmente con una rúbrica clara y ejemplos. También hereda sesgos, sensibilidad al orden y errores. Debe calibrarse contra humanos o verificadores externos y no ser la única fuente de verdad en decisiones críticas.

¿RAG es razonamiento?

RAG es recuperación de información. Puede formar parte de un proceso de razonamiento, pero recuperar un documento no implica usarlo correctamente ni verificar la conclusión.

Fuentes primarias

  1. Jason Wei et al., Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, 2022. ↩

  2. Xuezhi Wang et al., Self-Consistency Improves Chain of Thought Reasoning in Language Models, 2022. ↩

  3. Miles Turpin et al., Language Models Don't Always Say What They Think: Unfaithful Explanations in Chain-of-Thought Prompting, 2023. ↩

  4. Shunyu Yao et al., Tree of Thoughts: Deliberate Problem Solving with Large Language Models, 2023. ↩

  5. Levente Kocsis y Csaba Szepesvári, Bandit Based Monte-Carlo Planning, ECML 2006. ↩

  6. Karl Cobbe et al., Training Verifiers to Solve Math Word Problems, 2021. ↩

  7. Hunter Lightman et al., Let's Verify Step by Step, 2023. ↩

  8. Charlie Snell et al., Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters, 2024. ↩

  9. Shunyu Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, ICLR 2023. ↩

  10. OpenAI Agents SDK — Guardrails, documentación oficial. ↩