En el módulo 11 cerramos la teoría: vimos que una recompensa es una definición operativa de lo que quieres, que un modelo optimiza lo que mides y no lo que quieres decir, y que el reward hacking es la consecuencia inevitable de una recompensa mal especificada. Ya sabes cómo un modelo aprende de consecuencias y cómo un modelo compra capacidad pensando más. Este módulo cambia de plano: deja la teoría y hace la pregunta que un producto real termina haciendo siempre. No es “¿el modelo puede razonar?” — ya sabemos que sí. Es “¿me conviene pagarlo aquí?”. Porque el razonamiento no es gratis, y la ingeniería de producción es, en el fondo, decidir dónde vale la pena y dónde es un lujo que el usuario paga en segundos y tú pagas en factura.

La tesis del módulo

Un modelo que razona no es “mejor”: es más caro y más lento a cambio de más capacidad. El trabajo en producción no es poner razonamiento en todo — eso solo infla tu factura y tu latencia sin mover la métrica del negocio. El trabajo es gastar el razonamiento solo donde el problema lo paga: donde el paso extra de cómputo se convierte en una respuesta que antes fallaba.

El trade-off, sin adornos

Todo lo que aprendiste en los módulos de razonamiento — CoT (chain-of-thought, la cadena de pasos intermedios que el modelo escribe antes de responder) y test-time compute (gastar más cómputo en el momento de responder, no en el de entrenar) — tiene un precio que en el laboratorio se ignora y en producción es la primera línea del presupuesto. Ese precio tiene tres componentes:

Latencia. Un modelo de razonamiento piensa antes de contestar, y ese pensar son segundos reales. Una respuesta que un modelo rápido da en 400 ms puede tardar 8, 20 o 40 segundos si el modelo explora primero. Para un chat de soporte eso es la diferencia entre útil e insufrible.
Costo. La cadena de razonamiento son tokens de salida, y los tokens de pensamiento se cobran a la misma tarifa que los de la respuesta. Un problema que el modelo resuelve escribiendo 3.000 tokens de razonamiento interno cuesta como si hubiera escrito 3.000 tokens de respuesta, aunque el usuario nunca vea ni uno. Es fácil que el razonamiento sea la mayor parte de los tokens facturados de una consulta.
Capacidad. Lo que compras a cambio: problemas de varios pasos que el modelo rápido resuelve mal o no resuelve. Matemática, código no trivial, planificación, razonamiento lógico encadenado. Ahí el cómputo extra no es lujo: es la diferencia entre acertar y fallar.

La regla mental: el razonamiento convierte cómputo en acierto, pero solo en problemas donde el acierto dependía de dar más pasos. En una tarea de formato — “extrae estos tres campos de este texto”, “clasifica este correo” — no hay pasos que dar; el modelo rápido ya acierta, y el de razonamiento solo agrega latencia y factura para llegar a la misma respuesta.

	Modelo rápido	Modelo de razonamiento
Latencia	Baja (cientos de ms)	Alta (segundos a decenas de s)
Costo por consulta	Bajo	Alto (tokens de pensamiento)
Fuerte en	Formato, extracción, clasificación, respuestas directas, chit-chat	Mates, código, planificación, lógica multi-paso, análisis
Débil en	Problemas que exigen varios pasos encadenados	Nada — pero paga de más en lo fácil
Cuándo es la elección correcta	La mayoría del tráfico real	La minoría difícil que mueve la métrica

Fíjate en la última fila. En un producto típico, la mayoría de las consultas son fáciles: saludos, preguntas de formato, cosas que el modelo rápido resuelve perfecto. Meter razonamiento en todas ellas es como mandar a un equipo de expertos a contestar “¿a qué hora abren?”. La pregunta no es cuál modelo es mejor: es qué fracción de tu tráfico de verdad necesita pensar.

Cómo decidir: tres palancas

No hay una respuesta única. Hay tres palancas que se combinan según tu producto.

Palanca 1 — Enrutamiento por dificultad

La idea más rentable del módulo: no elijas un modelo para todo el producto, elige uno por consulta. Un componente barato — un clasificador, un modelo pequeño, incluso reglas — mira la consulta que llega, estima si es fácil o difícil, y la manda al modelo que corresponde. Lo fácil lo resuelve el rápido; solo lo difícil escala al que razona.

        ENRUTAMIENTO POR DIFICULTAD

 consulta
    │
    ▼
 ┌───────────────┐
 │ clasificador  │
 │ de dificultad │
 └───┬───────┬───┘
fácil│       │difícil
     ▼       ▼
 ┌───────┐ ┌──────────────┐
 │ modelo│ │   modelo de  │
 │ rápido│ │ razonamiento │
 └───┬───┘ └──────┬───────┘
     │            │
     └─────┬──────┘
           ▼
       respuesta

El clasificador no tiene que ser perfecto: tiene que ser barato y tener buen recall en lo difícil. Un falso “fácil” en algo que era difícil te da una mala respuesta; un falso “difícil” en algo fácil solo te cuesta un poco de más latencia y factura. Por eso conviene sesgarlo hacia mandar a razonar cuando duda: el error caro es no razonar cuando hacía falta.

Palanca 2 — El budget de razonamiento por consulta

Los modelos de razonamiento actuales no son una caja negra de “piensa todo lo que quieras”: exponen un control de cuánto pensar. Anthropic lo expone en la API de Claude como output_config.effort, con cinco niveles de esfuerzo — low, medium, high (el default en casi todos los modelos), xhigh y max — que regulan cuántos tokens gasta el modelo en toda la respuesta, pensamiento incluido. Un valor bajo minimiza el razonamiento y contesta rápido en tareas simples; uno alto explora a fondo en problemas complejos. Otros proveedores exponen la misma idea bajo nombres propios (OpenAI, por ejemplo, con reasoning_effort). Verifica siempre el nombre exacto y los valores en la doc de tu proveedor, porque cambian.

Dos matices importan en producción:

Es guía blanda, no un dial exacto. Con razonamiento adaptativo el modelo decide por consulta si pensar ayuda: una pregunta trivial puede contestarse directo aunque pongas un esfuerzo alto, y un problema genuinamente duro dispara más razonamiento. El esfuerzo pone el techo; el modelo decide cuánto de ese techo usa.
El budget es una palanca de costo, no solo de calidad. Subir el esfuerzo sube la factura y la latencia. Bajarlo las baja. La pregunta de producción no es “¿pongo el máximo?”, es “¿en qué punto un token más de pensamiento ya no mueve mi métrica?”.

"""Enrutamiento por dificultad con budget de razonamiento.

La firma exacta del parámetro de esfuerzo depende del proveedor y de la
versión de la API: verifica el nombre en la doc oficial antes de fijarlo.
Aquí 'effort' es ilustrativo del control de budget de razonamiento.
"""

def clasificar_dificultad(consulta: str) -> str:
    """Barato a propósito: reglas + un modelo pequeño. Sesgado a 'dificil'
    cuando duda, porque no razonar algo difícil es el error caro."""
    señales_dificil = ("demuestra", "calcula", "planifica",
                       "depura", "por qué", "paso a paso")
    if any(s in consulta.lower() for s in señales_dificil):
        return "dificil"
    if len(consulta) > 600:          # consultas largas suelen ser multi-paso
        return "dificil"
    return "facil"


def responder(consulta: str, cliente) -> str:
    nivel = clasificar_dificultad(consulta)
    if nivel == "facil":
        # Modelo rápido, sin budget de razonamiento: la mayoría del tráfico.
        return cliente.rapido(consulta)
    # Difícil: modelo de razonamiento con budget acotado, NO ilimitado.
    # 'high' explora a fondo; se sube a un nivel mayor solo si la métrica
    # de esa clase de problema lo justifica y el costo lo permite.
    return cliente.razonador(consulta, effort="high")

Palanca 3 — Medir si el razonamiento de verdad mueve tu métrica

La palanca que casi nadie usa y la única que cierra la decisión. El razonamiento es una hipótesis: “en esta clase de problema, pensar más sube el acierto lo suficiente para pagar la latencia y el costo”. Esa hipótesis se prueba, no se supone. Corres tu suite de evals dos veces sobre el mismo conjunto de casos — una con el modelo rápido, otra con el de razonamiento — y comparas no solo la métrica de calidad, sino también costo y latencia. Muchas veces el resultado incomoda: el razonamiento sube el acierto dos puntos y triplica el costo. Eso no es una mejora, es un mal negocio, y solo lo ves si mides. Todo el instrumental para hacerlo — casos, umbrales, separar señal de ruido — es el del red teaming y las suites de evals: el razonamiento en producción es una decisión de evals, no de fe.

Ojo: “el modelo de razonamiento es más inteligente” no es una justificación de producto. La justificación es “en esta clase de consultas sube mi métrica X en Y puntos, y ese Y paga el costo Z”. Sin ese número medido, poner razonamiento en todo es quemar presupuesto para sentirte a la vanguardia.

Razonamiento + agentes

Aquí es donde el razonamiento deja de ser una decisión de una consulta y se vuelve una decisión de arquitectura. Un agente —repasa cómo funciona un agente— es un modelo en un bucle: observa, decide una acción (típicamente una tool call, la llamada a una herramienta), ve el resultado, y vuelve a decidir. Los modelos de razonamiento mejoran a los agentes por tres motivos concretos:

Planifican. Antes de lanzar la primera tool, un modelo que razona puede trazar la secuencia de pasos, y eso reduce los callejones sin salida.
Deciden mejor la tool call. Elegir qué herramienta usar y con qué argumentos es un problema de razonamiento: el modelo que piensa acierta más el “qué llamo ahora”.
Se recuperan de errores. Cuando una tool devuelve un error o un resultado inesperado, razonar sobre qué salió mal y replantear es exactamente donde el modelo rápido se atasca repitiendo la misma llamada fallida.

El costo, otra vez, es el otro lado. Si el agente piensa en cada paso de un bucle de diez pasos, pagas diez cadenas de razonamiento por una sola tarea del usuario. Un agente de razonamiento resolviendo algo trivial puede costar veinte veces lo que costaría el modelo rápido. La misma lógica de las tres palancas aplica adentro del agente: no todos los pasos de un bucle necesitan el mismo esfuerzo. Planificar la estrategia inicial merece razonamiento; ejecutar un paso mecánico ya decidido, no.

Agentic RL: la frontera

Hasta aquí todo el módulo asumió modelos ya entrenados que tú combinas y enrutas. La frontera actual va un paso más allá y cierra el arco completo del curso: entrenar al modelo con RL directamente sobre tareas agénticas.

Recuerda el RLHF y el GRPO de los módulos anteriores: se entrenaba al modelo sobre un turno —una pregunta, una respuesta, una recompensa por esa respuesta—. El agentic RL (RL aplicado a agentes) cambia la unidad. El modelo interactúa con un entorno ejecutable a lo largo de muchos pasos —produce una acción, ve la respuesta del entorno, produce la siguiente— y la recompensa se da por completar la tarea entera, no por un turno aislado. Aprende políticas de varios pasos: cuándo llamar una tool, cómo encadenarlas, cómo recuperarse de un error, todo optimizado contra el resultado final de la tarea.

Es un área en evolución, y vale ser honesto sobre por qué es difícil:

Recompensa escasa y tardía. La señal llega recién al final —“la tarea se completó o no”—, y repartir ese crédito entre las decenas de decisiones que llevaron ahí (el credit assignment, asignar el mérito a cada acción intermedia) es el problema central y todavía abierto.
Trayectorias largas. Cada paso es una cadena de razonamiento más una acción, así que las secuencias son muy largas y la varianza del entrenamiento se dispara.
Entornos no estacionarios. El mundo con el que el agente interactúa cambia, y muchas recompensas no son verificables de forma limpia.

Una línea activa combina la recompensa de resultado con señales por paso —dar algo de crédito en cada turno, no solo al final— para densificar el aprendizaje. No memorices métodos concretos: lo que importa es entender qué se persigue. El agentic RL es el intento de que el modelo no solo use un bucle de agente que tú diseñaste, sino que aprenda a operarlo. Es literalmente la unión de las dos mitades de este curso: el RL como forma de aprender de consecuencias, aplicado a la capacidad de razonar y actuar en varios pasos.

Consideraciones prácticas antes de exponerlo

Poner razonamiento frente a usuarios reales trae asuntos que el laboratorio no ve:

Privacidad de la cadena de razonamiento. El razonamiento interno puede contener PII, datos de otros usuarios traídos por retrieval, o fragmentos del system prompt. Trátalo como dato sensible: no lo guardes sin control ni lo mandes a terceros por descuido.
La cadena puede ser inconsistente con la respuesta. El razonamiento no es una explicación fiel de cómo el modelo llegó a la respuesta; es texto que el modelo genera y que a veces contradice su propia conclusión final. Usarlo como “justificación auditable” ante el usuario es una trampa.
No muestres la cadena cruda sin cuidado. Enseñar el razonamiento tal cual al usuario final puede filtrar información que no debía ver, exponer contradicciones que dañan la confianza, o revelar la estructura de tus tools. Si quieres mostrar el “pensamiento”, resúmelo y filtra — no vuelques el crudo.

Cuidado: es tentador mostrar la cadena de razonamiento completa “para dar transparencia”. Pero esa cadena no es una explicación fiel ni está pensada para ser pública: es scratchpad interno. Mostrarla cruda mezcla un problema de privacidad con uno de confianza, y ninguno de los dos se ve hasta que ya lo expusiste.

Errores comunes

Poner razonamiento en todo el tráfico. La mayoría de las consultas son fáciles y el modelo rápido ya las acierta. Razonar en ellas solo agrega latencia y factura sin mover la métrica.
Elegir el modelo a nivel de producto, no de consulta. Un solo modelo para todo desperdicia capacidad en lo fácil o la escatima en lo difícil. El enrutamiento por dificultad es casi siempre más rentable.
Tratar el budget de razonamiento como un dial exacto. El esfuerzo es guía blanda: pone el techo, no la cantidad. El modelo decide por consulta cuánto usar.
Justificar el razonamiento con “es más inteligente”. No es una métrica. Sin medir cuánto sube tu acierto y cuánto cuesta, es fe cara.
Hacer que el agente piense en cada paso del bucle. Diez pasos de razonamiento por una tarea trivial multiplica el costo. No todos los pasos merecen el mismo esfuerzo.
Mostrar la cadena de razonamiento cruda al usuario. Filtra información, expone contradicciones y no es una explicación fiel. Resume y filtra, nunca vuelques el crudo.
Confundir agentic RL con “usar un modelo de razonamiento en un agente”. Lo primero es entrenar; lo segundo es combinar piezas ya entrenadas. Son cosas distintas.

La frase para llevarse

“Un modelo que razona no es mejor: es más caro y más lento a cambio de más capacidad. La ingeniería de producción no es poner razonamiento en todo; es gastarlo solo donde el problema lo paga.”

Qué viene — cierre del curso

No viene un módulo siguiente: llegaste al final. Vale mirar el arco completo que recorriste.

Empezamos por los cimientos del RL: qué es aprender de consecuencias (agente, entorno, recompensa), la idea de valor y política y la ecuación de Bellman, Q-learning y su salto a deep RL, los policy gradients que optimizan la política directamente, el actor-critic que combina ambos mundos, y PPO como el algoritmo estable que hizo todo esto práctico. Con esa base pasamos al RLHF: usar RL para alinear un modelo de lenguaje con preferencias humanas, y sus sucesores más directos, DPO y GRPO, que buscan el mismo alineamiento con menos maquinaria.

De ahí saltamos al razonamiento: CoT como la cadena de pasos que sube el acierto, test-time compute como la idea de comprar capacidad gastando cómputo al responder, cómo se entrena a un modelo para razonar, y las recompensas que hacen o deshacen ese entrenamiento —con el reward hacking siempre acechando—. Y cerramos hoy con la pregunta que un producto real termina haciendo: cuándo ese razonamiento vale lo que cuesta.

El mensaje central del curso, en una línea: el RL es cómo un modelo aprende de consecuencias, y el razonamiento es cómo compra capacidad con cómputo. Todo lo demás —PPO, DPO, GRPO, CoT, budgets, enrutamiento, agentic RL— son formas concretas de esas dos ideas. Si te llevas eso, te llevas el curso.

Felicitaciones por completar el Curso de Razonamiento y RL. Recorriste desde la primera recompensa de un agente de juguete hasta las decisiones de costo de un sistema de razonamiento en producción. Ese es el camino completo.

Razonamiento y RL — Módulo 12: del laboratorio al producto