Razonamiento en inferencia: cuándo conviene que el modelo piense más

La respuesta rápida y equivocada

Le pasas a un modelo un problema con trampa —un acertijo de lógica, un cálculo con varios pasos, un bug escondido entre dos funciones— y responde en medio segundo. Con aplomo. Y mal.

La reacción habitual es cambiar de modelo o reescribir el prompt diez veces. Hay otra palanca, más reciente y menos intuitiva: no toques el modelo, dale tiempo. Deja que gaste más cómputo en el momento de responder en vez de soltar lo primero que le sale. Eso es, en una frase, lo que hacen los modelos de razonamiento.

Dos formas de gastar cómputo

Durante años, la única manera de que un modelo fuera más listo era entrenarlo con más datos y más parámetros. Todo el gasto se concentraba antes: en el entrenamiento. En inferencia, el modelo predecía el siguiente token y punto.

Los modelos de razonamiento mueven parte de ese gasto al otro lado. Antes de dar la respuesta final generan una tanda de tokens intermedios —una cadena de pensamiento— donde exploran, se corrigen y descartan caminos. Esos tokens no suelen mostrarse, pero se producen y, sobre todo, se pagan.

La idea de fondo es que pensar más en el momento equivale, hasta cierto punto, a tener un modelo más grande. Un modelo mediano al que dejas razonar puede superar a uno mayor que responde a la primera. No es magia: es cambiar memoria y parámetros por tiempo de cálculo. Y el tiempo, a diferencia del reentrenamiento, lo decides consulta a consulta.

Qué hace por dentro

La cadena de pensamiento no es un adorno de marketing. Es texto real que el modelo genera para sí mismo antes de la respuesta. Le sirve para descomponer el problema, tantear una vía, notar que no cuadra y volver atrás. Un modelo estándar no tiene ese margen: cada token que emite ya forma parte de la respuesta, así que no puede permitirse pensar en voz alta y rectificar.

Aquí está el matiz que casi todo el mundo pasa por alto: no controlas qué piensa el modelo, pero sí cuánto. La mayoría de las APIs de razonamiento exponen un mando de esfuerzo. En las de OpenAI es un parámetro de tres posiciones; en las de Anthropic, un presupuesto de tokens de pensamiento. Subir el esfuerzo mejora las tareas difíciles y encarece las fáciles sin darte nada a cambio.

from openai import OpenAI

client = OpenAI()

# Un problema que premia pensar antes de contestar
prompt = "Tres interruptores, una bombilla en otra habitación. Solo puedes entrar una vez. ¿Cómo sabes qué interruptor la enciende?"

resp = client.responses.create(
    model="o4-mini",
    reasoning={"effort": "high"},   # low | medium | high
    input=prompt,
)

print(resp.output_text)

# Los tokens de razonamiento van en la factura aunque no los veas:
detalle = resp.usage.output_tokens_details
print("pensamiento:", detalle.reasoning_tokens)
print("respuesta:  ", resp.usage.output_tokens - detalle.reasoning_tokens)

Ese último bloque es el que conviene mirar en producción. Los tokens de pensamiento pueden multiplicar por diez la salida visible. Si no los cuentas, tu estimación de coste va a estar mal por un margen que duele.

Estándar frente a razonador

Ninguno de los dos es mejor en abstracto. Resuelven cosas distintas y cuestan distinto.

La trampa es usar un razonador para lo que no lo necesita. Pedirle que clasifique un correo o rellene un JSON es pagar un taxi con taxímetro para cruzar el pasillo: más lento, más caro y sin mejor resultado. El razonamiento rinde cuando la respuesta depende de varios pasos encadenados, no cuando basta con reconocer un patrón.

El coste que nadie presupuesta

Un modelo de razonamiento rompe dos supuestos con los que sueles diseñar un sistema. El primero es la latencia: puede tardar segundos, a veces decenas, porque está generando cientos o miles de tokens que nunca verás. Eso descarta de entrada cualquier ruta síncrona de cara al usuario donde esperes respuesta al instante.

El segundo es el coste, y es más traicionero porque no se ve. Facturas por todos los tokens de salida, y los de pensamiento son salida. Una consulta que en un modelo estándar te cuesta 200 tokens puede irse a 2.000 en un razonador con esfuerzo alto. Multiplícalo por el volumen de producción y el ahorro que creías tener por usar un modelo mediano se evapora.

La regla práctica es tratar el esfuerzo como un dial, no como un interruptor. Empieza en el nivel más bajo que resuelva la tarea y súbelo solo si mides que hace falta. Muchos problemas que parecen exigir esfuerzo alto se resuelven igual de bien en medio, a mitad de precio.

Un patrón que sí compensa: enrutar

La forma más rentable de usar razonamiento no es ponerlo en todas partes, sino decidir por consulta. Clasificas la petición que entra —barato, con un modelo estándar— y solo mandas al razonador las que de verdad lo piden.

def responder(pregunta: str) -> str:
    # Enrutador barato: ¿esto necesita varios pasos de lógica?
    dificil = clasificar_dificultad(pregunta)  # modelo estándar, respuesta corta

    if dificil:
        return con_razonamiento(pregunta, effort="high")
    return directo(pregunta)  # la mayoría del tráfico cae aquí

Es la misma lógica del enrutado de modelos, aplicada al esfuerzo en vez de al tamaño. El grueso del tráfico —preguntas sencillas, formato, recuperación— se sirve rápido y barato. El puñado que requiere pensar paga su precio, y solo ese. Pagas la inteligencia donde rinde y no donde estorba.

Cuándo usarlo y cuándo no

Deja que el modelo piense cuando la respuesta correcta dependa de una cadena de pasos: demostraciones, depuración de código, planificación con restricciones, problemas donde un fallo intermedio arruina el resultado. Ahí el razonamiento no es un lujo, es lo que separa una respuesta útil de una plausible y falsa.

Evítalo cuando la tarea sea de reconocimiento directo, cuando la latencia importe de cara al usuario o cuando el volumen sea alto y el margen estrecho. Un clasificador, un extractor de campos o un resumidor no mejoran por pensar más; solo se vuelven lentos y caros.

El titular para llevarse a casa: el razonamiento es una palanca de coste y calidad, no un ajuste que dejas fijo. Elige el modelo por la tarea, arranca con el esfuerzo mínimo, mide antes de subirlo y enruta para no pagar por pensar cuando no hace falta. Un modelo que se toma su tiempo vale mucho el día que el problema lo merece, y sale carísimo el resto de los días.