LLMs como motores de razonamiento

01Objetivos de aprendizaje

Al finalizar esta clase, los estudiantes serán capaces de:

1. Explicar la arquitectura Transformer, incluyendo el mecanismo de autoatención y sus propiedades computacionales.
2. Describir cómo el preentrenamiento, el ajuste por instrucciones y el RLHF moldean el comportamiento del modelo.
3. Analizar la relación entre la escala del modelo y las capacidades emergentes.
4. Evaluar las capacidades y limitaciones de razonamiento de los LLM actuales.
5. Comparar las principales familias de LLM (GPT, Claude, Gemini, Llama, Mistral) en términos de arquitectura, capacidades y compromisos.
6. Explicar el cómputo en tiempo de inferencia y su importancia para el comportamiento agéntico.
7. Realizar llamadas básicas a la API de un LLM con mensajes de sistema, usuario y asistente.

141. Repaso de la arquitectura Transformer

1.1 Por qué los Transformers importan para los agentes

Todo agente moderno basado en LLM se ejecuta sobre un Transformer. Comprender la arquitectura no es un ejercicio meramente académico: afecta directamente las decisiones de diseño de agentes. El tamaño de la ventana de contexto, los patrones de atención y los costés computacionales condicionan lo que los agentes pueden hacer.

Consideremos algunas preguntas prácticas que surgen al construir agentes:

• "¿Por qué mi agente pierde el hilo de las instrucciones en conversaciones largas?" (Respuesta: los patrones de atención y el fenómeno "lost in the middle".)
• "¿Por qué cuesta más cuando mi agente lee un archivo grande?" (Respuesta: la atención es cuadrática en la longitud de la secuencia.)
• "¿Por qué el mismo prompt produce a veces resultados distintos?" (Respuesta: la generación autorregresiva con muestreo por temperatura.)

Para responder a estas preguntas, necesitamos entender el motor bajo el capó.

El Transformer fue introducido por Vaswani et al. (2017) en el artículo "Attention Is All You Need". Reemplazó a las redes neuronales recurrentes (RNN) como arquitectura dominante para el modelado de secuencias, principalmente porque:

1. Paralelismo: A diferencia de las RNN, que procesan los tokens uno a uno (la salida de la posición 5 depende de la posición 4, que depende de la posición 3...), los Transformers procesan todas las posiciones de una secuencia simultáneamente. Esto hace que el entrenamiento sea drásticamente más rápido en GPUs.
2. Dependencias de largo alcance: El mecanismo de atención puede conectar directamente dos posiciones cualesquiera, independientemente de la distancia. En una RNN, la información sobre la primera palabra debe pasar por cada palabra intermedia para llegar a la última, diluyéndose en el camino.
3. Escalabilidad: Los Transformers escalan eficientemente a miles de millones de parámetros y billones de tokens de entrenamiento. La arquitectura ha demostrado ser notablemente robusta: el mismo diseño básico funciona con 100 millones de parámetros y con un billón.

1.2 El mecanismo de atención

La innovación central del Transformer es la autoatención (self-attention). Para entenderla, comencemos con una analogía.

Imaginemos que estamos leyendo una oración: "El gato se sentó en la alfombra porque estaba cansado". Al leer la palabra "estaba", nuestro cerebro determina automáticamente que se refiere a "el gato", no a "la alfombra". Lo hacemos considerando todas las palabras de la oración y determinando cuáles son más relevantes para entender "estaba".

La autoatención hace algo similar. Dada una secuencia de embeddings de tokens, la autoatención calcula una combinación ponderada de todos los tokens para cada posición, donde los pesos reflejan la relevancia de cada token respecto al actual.

Matemáticamente:

Dada la matriz de entrada $X \in \mathbb{R}^{n \times d}$ (n tokens, d dimensiones):

1. Calcular consultas (queries), claves (keys) y valores (values):

   • $Q = X W_Q$, $K = X W_K$, $V = X W_V$
   • Donde $W_Q, W_K \in \mathbb{R}^{d \times d_k}$ y $W_V \in \mathbb{R}^{d \times d_v}$

2. Calcular las puntuaciones de atención: $\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V$

El factor de escala $\frac{1}{\sqrt{d_k}}$ evita que los productos escalares se hagan demasiado grandes, lo que empujaría al softmax a regiones con gradientes que desaparecen. Sin este escalado, a medida que crece la dimensionalidad, los productos escalares crecen en magnitud y el softmax produciría salidas casi one-hot, haciendo los gradientes muy pequeños.

Intuición detrás de Q, K, V: Pensemós en la atención como un sistema de búsqueda en una biblioteca:

• Query (Q): "¿Qué estoy buscando?" Cada token genera una consulta describiendo qué información necesita.
• Key (K): "¿Qué contengo?" Cada token genera una clave describiendo qué información ofrece.
• Value (V): "Aquí está mi contenido real." Cada token genera un valor con la información que será transmitida.

La puntuación de atención entre dos tokens es el producto escalár entre la query del primer token y la key del segundo. Una puntuación alta significa "estos tokens son relevantes entre sí", y la salida para cada token es un promedio ponderado de todos los valores, ponderados por estas puntuaciones de relevancia.

Idea clave: La atención es una tabla de búsqueda blanda. A diferencia de una tabla hash (que devuelve exactamente un resultado), la atención recupera una mezcla ponderada de todas las entradas, permitiendo al modelo combinar información de múltiples posiciones relevantes simultáneamente.

1.3 Atención multi-cabeza

En lugar de calcular una única función de atención, el Transformer utiliza atención multi-cabeza (multi-head attention): múltiples funciones de atención ejecutándose en paralelo, cada una con diferentes matrices de proyección aprendidas.

MultiHead(Q, K, V) = Concat(head_1, ..., head_h) W_O

where head_i = Attention(Q W_Q^i, K W_K^i, V W_V^i)

¿Por qué múltiples cabezas? Pensémoslo así: cuando leemos una oración, rastreamos simultáneamente múltiples tipos de relaciones. Una parte de nuestro cerebro rastrea quién hace qué (relaciones sujeto-verbo). Otra rastrea los modificadores descriptivos (relaciones adjetivo-nombre). Otra rastrea el orden temporal (qué pasó primero, segundo, tercero).

De forma similar, diferentes cabezas de atención pueden especializarse en distintos tipos de relaciones:

• Una cabeza puede rastrear dependencias sintácticas (concordancia sujeto-verbo)
• Otra puede rastrear relaciones semánticas (correferencia, como "estaba" refiriéndose a "el gato")
• Otra puede rastrear patrones posicionales (atendiendo a tokens cercanos)
• Otra puede rastrear dependencias de largo alcance (conectando un pronombre con su antecedente varios párrafos antes)

La investigación ha demostrado que estas especializaciones emergen de forma natural durante el entrenamiento; no se programan manualmente.

Inténtalo tú mismo: Considera la oración "El profesor que impartía la clase también escribió el libro de texto". Piensa en los diferentes tipos de relaciones que un modelo necesita rastrear: ¿Quién impartía? ¿Qué se impartía? ¿Quién escribió? ¿Qué se escribió? ¿Cómo están conectados "profesor", "impartía" y "escribió"? Cada una de estas relaciones podría ser capturada por una cabeza de atención diferente.

1.4 El bloque Transformer completo

Un bloque Transformer consiste en:

La Red Feed-Forward (FFN) es un MLP de dos capas aplicado independientemente a cada posición:

$\text{FFN}(x) = \text{ReLU}(x W_1 + b_1) W_2 + b_2$

Los modelos modernos suelen usar funciones de activación SwiGLU o GELU en lugar de ReLU, y pueden usar RMSNorm en lugar de LayerNorm. Estos son refinamientos de ingeniería que mejoran la estabilidad del entrenamiento y el rendimiento.

Las conexiones residuales ($x + \text{sublayer}(x)$) son fundamentales: permiten que los gradientes fluyan directamente a través de la red, posibilitando el entrenamiento de modelos muy profundos (decenas o centenares de capas). Sin conexiones residuales, los gradientes desaparecerían o explotarían en redes profundas, haciendo imposible el entrenamiento.

Una forma intuitiva de pensar en las conexiones residuales: cada capa refina la representación en lugar de reemplazarla. La entrada pasa sin cambios, y la capa añade una corrección. Es como editar un documento: se parte del texto original y se hacen cambios incrementales, en lugar de reescribirlo desde cero en cada paso.

La interacción entre atención y FFN es importante para entender qué aprende el modelo:

• Las capas de atención mueven información entre posiciones (permiten que los tokens se comuniquen entre sí).
• Las capas FFN transforman información dentro de cada posición (procesan la información combinada de la atención en nuevas representaciones).

La investigación sugiere que las capas FFN almacenan conocimiento factual ("París es la capital de Francia"), mientras que las capas de atención manejan el razonamiento relacional ("la capital del país donde se encuentra la Torre Eiffel").

1.5 Un ejemplo concreto: cómo la atención procesa un prompt de agente

Para concretar la arquitectura, veamos cómo la atención procesa un prompt típico de agente. Consideremos este prompt simplificado:

System: You are a helpful assistant with calculator access.
User: What is 15% of 240?

Cuando el modelo procesa esto, cada token de "What is 15% of 240?" atiende a todos los tokens anteriores. El mecanismo de atención permite al modelo:

1. Conectar "15%" con "of 240" para entender la relación matemática.
2. Conectar "calculator access" del prompt del sistema con la pregunta matemática, activando el comportamiento de uso de herramientas del modelo.
3. Conectar "helpful assistant" con la estrategia general de generación, influyendo en el tono y el formato.

Todo esto ocurre simultáneamente a través de múltiples cabezas de atención. Una cabeza puede enfocarse en la estructura matemática, otra en las instrucciones del sistema y otra en el contexto conversacional. La salida combinada de todas las cabezas proporciona al modelo una comprensión rica de qué hacer a continuación.

1.6 Arquitectura sólo decodificador

Los LLM modernos (GPT, Claude, Llama, Mistral) utilizan una arquitectura sólo decodificador (decoder-only). A diferencia del Transformer original codificador-decodificador (diseñado para traducción, donde el codificador lee la entrada y el decodificador genera la salida), los modelos sólo decodificador:

1. Usan atención causal (enmascarada): Cada token solo puede atender a sí mismo y a los tokens anteriores, no a los futuros.
2. Generan texto autorregresiamente: Un token a la vez, de izquierda a derecha.
3. Usan la misma arquitectura tanto para la "comprensión" como para la "generación".

¿Por qué el enmascaramiento causal? Durante el entrenamiento, el modelo aprende a predecir el siguiente token dados todos los tokens anteriores. Si pudiera ver tokens futuros, la tarea sería trivial (simplemente copiar el siguiente token). La máscara causal asegura que cada posición solo pueda usar información del pasado, haciendo que la tarea de predicción sea significativa.

Esto es fundamental para entender el comportamiento de los agentes: el modelo procesa todo el prompt (mensaje del sistema + historial de conversación + resultados de herramientas) y luego genera el siguiente token, uno a la vez. Cuando un agente "decide" llamar a una herramienta, está generando una secuencia de tokens que resultan codificar una llamada a herramienta. No hay un "módulo de decisión" separado; la llamada a herramienta emerge del mismo proceso autorregresívo que genera texto ordinario.

Idea clave: La "decisión" de un agente LLM de llamar a una herramienta no es fundamentalmente diferente de su "decisión" de escribir la siguiente palabra de una oración. Ambas son el resultado de la generación autorregresiva de tokens condicionada por el contexto. Esto es tanto la fortaleza como la limitación de los agentes LLM: pueden tomar decisiones notablemente flexibles, pero esas decisiones están moldeadas por los patrones estadísticos de los datos de entrenamiento.

Concepto erróneo frecuente: "El LLM entiende la herramienta y decide usarla." Más precisamente, el LLM ha sido entrenado con texto que describe el uso de herramientas, y genera texto que sigue esos patrones. Si esto constituye "comprensión" es una cuestión filosófica; lo que importa para la ingeniería es que funciona de manera suficientemente fiable para tareas prácticas de agentes.

1.7 Codificación posicional

Dado que la atención es invariante a permutaciones (no conoce inherentemente el orden de los tokens: la puntuación de atención entre "gato" y "sentó" es la misma independientemente de sus posiciones), los Transformers necesitan información posicional. Los enfoques modernos incluyen:

• Rotary Position Embeddings (RoPE) (Su et al., 2024): Usado en Llama, Mistral y muchos modelos recientes. Codifica la posición relativa mediante rotación de los vectores de query/key. La idea clave es que el producto escalar entre una query en la posición $m$ y una key en la posición $n$ depende solo del contenido y la distancia relativa $m - n$, no de las posiciones absolutas.
• ALiBi (Attention with Linear Biases) (Press et al., 2022): Añade un sesgo lineal basado en la distancia entre tokens. Los tokens más cercanos reciben una bonificación mayor, los más lejanos una penalización.
• Embeddings posicionales absolutos aprendidos: Usado en los modelos GPT originales. Cada posición obtiene un vector de embedding aprendido que se suma al embedding del token.

RoPE se ha convertido en dominante porque soporta la extrapolación de longitud: los modelos pueden manejar secuencias más largas que las vistas durante el entrenamiento. Esto es crucial para los agentes, que a menudo procesan conversaciones largas con muchos resultados de llamadas a herramientas.

1.8 Escala de los modelos modernos

Para poner estos números en perspectiva:

• 405 mil millones de parámetros: Si cada parámetro fuera un grano de arena, se necesitarían unos 2.000 camiones volquete para transportarlos. Este modelo "sabe" cosas porque sus parámetros codifican patrones estadísticos de billones de palabras de texto.
• 15 billones de tokens de entrenamiento: Si leyéramos a razón de una palabra por segundo, las 24 horas del día, tardaríamos unos 475.000 años en leer 15 billones de tokens. El modelo absorbe esto en unos pocos meses de entrenamiento en GPU.
• Ventana de contexto de 200K: Unas 150.000 palabras, equivalente a una novela de 500 páginas. Un agente puede mantener un libro entero, o una conversación completa con cientos de llamadas a herramientas, en su memoria de trabajo.

La tendencia es clara: más parámetros, más datos de entrenamiento y ventanas de contexto más grandes. Cada una de estas dimensiones permite agentes más capaces.

152. De modelos de lenguaje a razonamiento

2.1 ¿Qué significa "razonar"?

En el contexto de los LLM, "razonamiento" se refiere a la capacidad de:

• Extraer conclusiones lógicas a partir de premisas
• Resolver problemas de múltiples pasos
• Transferir conocimiento entre dominios
• Planificar secuencias de acciones
• Identificar y corregir errores

Si los LLM verdaderamente "razonan" o simplemente simulan el razonamiento mediante un sofisticado reconocimiento de patrones es un debate filosófico y científico activo. Para el diseño de agentes, lo que importa es la capacidad práctica: ¿puede el modelo producir de manera fiable salidas correctas para tareas que requieren razonamiento intensivo?

Merece la pena detenerse en esto, porque afecta a cómo se construyen los agentes. Si creemos que el modelo verdaderamente razona, podríamos confiarle una planificación compleja. Si creemos que está reconociendo patrones, podríamos añadir más pasos de verificación, herramientas externas y puntos de control humano. El enfoque pragmático (que adoptamos en este curso) es: asumir que el modelo podría equivocarse, diseñar en consecuencia, pero aprovechar las impresionantes capacidades que sí tiene.

2.2 Capacidades emergentes

Uno de los fenómenos más fascinantes de la IA moderna es que los modelos de lenguaje más grandes no solo hacen las mismas cosas mejor; desarrollan capacidades cualitativamente nuevas que los modelos más pequeños simplemente no pueden realizar. Estas se denominan capacidades emergentes.

Las capacidades emergentes son habilidades que aparecen en modelos grandes pero están ausentes o son poco fiables en los más pequeños. Wei et al. (2022a) documentaron varias:

• Aritmética: Los modelos por debajo de cierta escala no pueden sumar de forma fiable números de tres dígitos. Por encima de ese umbral, la precisión salta drásticamente. Esto tiene sentido: la aritmética fiable con múltiples dígitos requiere rastrear acarreos entre posiciones, lo que necesita capacidad suficiente del modelo.
• Razonamiento en cadena de pensamiento: Los modelos más pequeños no se benefician de prompts como "pensemos paso a paso"; los más grandes sí. Esto sugiere que la capacidad de usar productivamente pasos intermedios generados requiere un nivel mínimo de capacidad.
• Generación de código: Producir código correcto y ejecutable requiere una capacidad sustancial del modelo. El modelo necesita comprender la sintaxis, la semántica, la lógica y las convenciones de un lenguaje de programación particular simultáneamente.
• Seguimiento de instrucciones: La capacidad de seguir instrucciones complejas y con múltiples partes mejora con la escala. Un modelo pequeño puede seguir "escribe un poema", pero falla con "escribe un poema sobre el otoño al estilo de Antonio Machado, usando exactamente cuatro estrofas de cuatro versos cada una".

Sin embargo, Schaeffer et al. (2024) argumentaron que algunas capacidades emergentes aparentes son artefactos de las métricas de evaluación utilizadas. Cuando se usan métricas que muestran una transición brusca (como la exactitud de coincidencia exacta), la transición parece repentina. Cuando se usan métricas más suaves (como el crédito parcial), las capacidades mejoran más gradualmente. El panorama real es matizado: las capacidades generalmente mejoran de forma gradual con la escala, pero la utilidad práctica puede parecer que salta cuando la precisión cruza un umbral de usabilidad.

Idea clave: Desde la perspectiva del diseño de agentes, la pregunta importante no es "¿a qué escala emerge el razonamiento?" sino "¿a qué escala es el razonamiento suficientemente fiable para mí caso de uso?" Un agente que necesita tomar 20 decisiones correctas seguidas requiere una precisión por decisión mucho mayor que uno que necesita tomar una sola decisión correcta.

2.3 La hipótesis del escalado

Las leyes de escalado (Kaplan et al., 2020; Hoffmann et al., 2022) describen una relación predecible entre el rendimiento del modelo y tres factores:

1. Número de parámetros (N)
2. Tamaño del conjunto de datos (D)
3. Presupuesto de cómputo (C)

Kaplan et al. (2020) encontraron originalmente que el rendimiento mejora como una ley de potencia con cada uno de estos factores, y que la relación es notablemente suave a lo largo de muchos órdenes de magnitud. Esto significa que se puede predecir cómo rendirá un modelo más grande antes de entrenarlo.

Hoffmann et al. (2022) refinaron esto con la ley de escalado "Chinchilla", mostrando que para un presupuesto de cómputo dado, existe un equilibrio óptimo entre el tamaño del modelo y el tamaño de los datos. Su hallazgo clave: muchos modelos existentes estaban subentrenados, lo que significa que necesitaban más datos en relación con su número de parámetros. Por ejemplo, el GPT-3 original (175B parámetros, 300B tokens de entrenamiento) estaba significativamente subentrenado según los estándares de Chinchilla, que sugeriría entrenar un modelo más pequeño con más datos.

Implicaciones para el diseño de agentes:

• Los modelos más grandes son generalmente agentes más capaces, pero la relación no es lineal. Duplicar el tamaño del modelo no duplica la capacidad del agente.
• La calidad de los datos de entrenamiento importa tanto como la cantidad. Un modelo entrenado con texto curado y de alta calidad supera a uno entrenado con rastreos web sin procesar.
• Los costés de cómputo en tiempo de inferencia también escalan con el tamaño del modelo, creando restricciones prácticas para los despliegues de agentes. Un agente que hace 20 llamadas a un modelo de 70B es mucho más barato que uno que hace 20 llamadas a un modelo de 405B.

163. Pipeline de entrenamiento: preentrenamiento, ajuste por instrucciones y RLHF

Comprender el pipeline de entrenamiento es esencial para los constructores de agentes porque cada etapa moldea diferentes aspectos del comportamiento del modelo. Cuando un agente se comporta de cierta manera (servicial, cauteloso, verboso, adulador), a menudo se puede rastrear hasta una etapa de entrenamiento específica.

3.1 Preentrenamiento

La base de todo LLM es el preentrenamiento: predecir el siguiente token en un corpus masivo de texto. Esta es una de las ideas más elegantes de la IA moderna: simplemente aprendiendo a predecir qué palabra viene a continuación, el modelo adquiere una asombrosa variedad de capacidades, incluyendo gramática, hechos, razonamiento, programación e incluso cierto sentido común.

Training objective: Minimize cross-entropy loss

L = -sum(log P(token_t | token_1, ..., token_{t-1}))

En lenguaje llano: para cada posición en el texto de entrenamiento, el modelo intenta predecir qué viene después. La función de pérdida penaliza al modelo más cuando asigna baja probabilidad al token correcto siguiente. A lo largo de billones de tokens, el modelo aprende la estructura estadística del lenguaje, desde la gramática y la sintáxis hasta los hechos y los patrones de razonamiento.

Para ver por qué la predicción del siguiente token es tan poderosa, consideremos qué necesita aprender el modelo para predecir bien en diferentes contextos:

• "La capital de Francia es [París]" requiere aprender conocimiento factual.
• "def fibonacci(n): if n <= 1: return n; return [fibonacci(n-1)]" requiere aprender programación.
• "Si todos los perros son mamíferos y Rex es un perro, entonces Rex es un [mamífero]" requiere aprender lógica.
• "Ella estaba triste porqué su amigo se [mudó] lejos" requiere aprender sentido común.

Todas estas capacidades emergen de un único objetivo de entrenamiento. Esto es notable y es la razón por la que los LLM son tan versátiles como cerebros de agentes.

Los datos de preentrenamiento típicamente incluyen:

• Páginas web (Common Crawl, filtrado y deduplicado)
• Libros y artículos académicos
• Repositorios de código (GitHub)
• Wikipedia y contenido enciclopédico
• Datos conversacionales (foros, sitios de preguntas y respuestas)

El preentrenamiento produce un modelo que puede completar texto. Pero un motor de completado de texto no es todavía un agente; puede generar continuaciones plausibles, pero no sigue instrucciones de manera fiable ni rechaza peticiones dañinas.

Para ilustrar la brecha: un modelo preentrenado al que se le da el prompt "La capital de Francia es" probablemente continuará con "París". Pero ante "¿Cuál es la capital de Francia? Por favor responde en una palabra", podría continuar con "La capital de Francia es París. Francia, oficialmente la República Francesa, es un país ubicado principalmente en Europa Occidental..." porque aprendió a generar texto estilo Wikipedia, no a seguir instrucciones.

3.2 Ajuste por instrucciones (Supervised Fine-Tuning)

El ajuste por instrucciones (también llamado SFT, Supervised Fine-Tuning) enseña al modelo a seguir instrucciones. Los datos de entrenamiento consisten en pares (instrucción, respuesta):

Instruction: "Explain quantum entanglement to a 10-year-old."
Response: "Imagine you have two magic coins..."

Conjuntos de datos y enfoques clave:

• FLAN (Wei et al., 2022b): Ajustado por instrucciones en 1.836 tareas de muchas categorías.
• InstructGPT (Ouyang et al., 2022): Combinó SFT con RLHF. Demostró que el ajuste por instrucciones con retroalimentación humana mejoraba drásticamente la satisfacción del usuario.
• Alpaca (Taori et al., 2023): Enfoque de auto-instrucción usando datos generados por GPT, demostrando que los datos de instrucción sintéticos pueden ser efectivos.

Después del ajuste por instrucciones, el modelo sigue instrucciones de manera más fiable, responde en formatos útiles y comienza a exhibir el comportamiento conversacional que asociamos con los asistentes de IA.

Idea clave: El ajuste por instrucciones es lo que hace a los LLM utilizables como cerebros de agentes. Sin él, habría que elaborár cuidadosamente prompts que parecieran completados de texto en lugar de instrucciones. Con él, se puede simplemente decir al agente qué hacer en lenguaje natural. Por ello, al ajuste por instrucciones se le llama a veces el paso más importante del pipeline desde la perspectiva de las aplicaciones.

3.3 RLHF: Aprendizaje por refuerzo con retroalimentación humana

El RLHF refina el comportamiento del modelo basándose en las preferencias humanas. El proceso:

Paso 1: Recopilar datos de comparación

• Se presentan a evaluadores humanos un prompt y dos respuestas del modelo.
• El evaluador selecciona la mejor respuesta.
• Esto es mucho más fácil que escribir respuestas perfectas desde cero; los humanos son mejores juzgando que generando.

Paso 2: Entrenar un modelo de recompensa

• Un modelo separado aprende a predecir las preferencias humanas.
• Dado un par (prompt, respuesta), produce una recompensa escalar.
• Esto automatiza el juicio humano: en lugar de preguntar a humanos por cada comparación, entrenamos un modelo para aproximar sus preferencias.

Paso 3: Optimizar la política con RL

• Se usa Proximal Policy Optimization (PPO) o similar para ajustar el LLM.
• El objetivo: maximizar la puntuación del modelo de recompensa manteniéndose cerca del modelo SFT (para evitar el "reward hacking").

Objective: max E[R(prompt, response)] - beta * KL(policy || SFT_policy)

La penalización por divergencia KL es crucial: sin ella, el modelo encontraría "atajos" que explotan las debilidades del modelo de recompensa sin ser realmente útil. Por ejemplo, un modelo de recompensa entrenado con preferencias humanas podría dar puntuaciones altas a respuestas verbosas y seguras de sí mismas; sin la penalización KL, el modelo aprendería a ser siempre verboso y seguro, incluso cuando la brevedad y la incertidumbre serían más apropiadas.

Efectos del RLHF relevantes para agentes:

• Los modelos se vuelven más serviciales y menos propensos a rechazar peticiones válidas.
• Los modelos aprenden a decir "no lo sé" en lugar de fabricar respuestas (a veces).
• Los modelos desarrollan comportamientos de seguridad (rechazar peticiones dañinas).
• Sin embargo, el RLHF también puede hacer que los modelos sean excesivamente cautelosos o aduladores. Un modelo podría estar de acuerdo con el usuario incluso cuando este se equivoca, porque los evaluadores humanos tendían a preferir respuestas complacientes.

3.4 RLAIF e IA constitucional

La IA Constitucional (Bai et al., 2022) reemplaza la retroalimentación humana por retroalimentación de IA:

1. Generar respuestas a prompts dañinos.
2. Pedir al modelo que critique su propia respuesta basándose en un conjunto de principios (la "constitución"). Por ejemplo: "¿Es esta respuesta dañina? ¿Ayuda con actividades ilegales?"
3. Pedir al modelo que revise su respuesta.
4. Entrenar con las respuestas revisadas.

Este enfoque, también llamado RLAIF (Reinforcement Learning from AI Feedback), es más escalable que la retroalimentación humana (no se necesita pagar a miles de evaluadores humanos), pero introduce el riesgo de reforzar los propios sesgos del modelo.

Anthropic utiliza la IA Constitucional como parte central del entrenamiento de Claude. La "constitución" incluye principios como "sé útil", "sé honésto" y "no causes daño". Esto moldea el estilo distintivo de Claude: servicial pero cauteloso, directo sobre la incertidumbre y más dispuesto a cuestionar premisas incorrectas que los modelos entrenados exclusivamente con RLHF.

3.5 Optimización directa de preferencias (DPO)

Rafailov et al. (2023) introdujeron DPO como una alternativa más simple al RLHF. En lugar de entrenar un modelo de recompensa separado y luego usar RL, DPO optimiza directamente el modelo de lenguaje sobre datos de preferencias usando una pérdida similar a la de clasificación. La idea clave es que la política óptima bajo el objetivo del RLHF puede expresarse como una función simple de las log-probabilidades de las respuestas elegidas y rechazadas.

DPO se ha vuelto cada vez más popular porque es más simple de implementar, más estable durante el entrenamiento y a menudo produce resultados comparables a los pipelines completos de RLHF. Elimina la necesidad de: (a) entrenar un modelo de recompensa separado, (b) ejecutar optimización RL, y (c) lidiar con la inestabilidad del entrenamiento PPO.

3.6 Resumen del post-entrenamiento

Cada etapa se construye sobre la anterior. Para aplicaciones de agentes, las tres etapas importan: el preentrenamiento proporciona la base de conocimiento, el ajuste por instrucciones proporciona la capacidad de seguir instrucciones complejas, y la alineación asegura que el agente se comporte de forma segura y útil.

Inténtalo tú mismo: Piensa en cómo estas etapas de entrenamiento afectan a un agente de programación. El preentrenamiento le da al modelo conocimiento de lenguajes de programación y patrones. El ajuste por instrucciones le enseña a seguir instrucciones de programación ("escribe una función que..."). El RLHF le enseña a escribir código limpio y bien documentado (porque los evaluadores humanos lo prefieren) y a negarse a escribir código malicioso. ¿Se te ocurre un escenario donde la contribución de cada etapa sea esencial?

174. Capacidades de razonamiento

4.1 Razonamiento aritmético y matemático

Los LLM pueden realizar aritmética, pero su fiabilidad depende de la complejidad. Comprender estas limitaciones es fundamental para el diseño de agentes, porque los agentes que realizan cálculos necesitan saber cuándo confiar en el LLM y cuándo delegar en una herramienta.

Por qué los LLM tienen dificultades con la aritmética: Los LLM procesan los números como tokens, no como objetos matemáticos. El número "1.234.567" podría tokenizarse como ["1.", "234", ".567"] o similar, rompiendo la estructura de valor posicional que hace que la aritmética sea sistemática. El modelo debe aprender a "simular" la aritmética a partir de patrones en el texto, en lugar de ejecutarla algorítmicamente.

Por qué los agentes necesitan herramientas para las matemáticas: Incluso una tasa de precisión del 95% es inaceptable para cálculos fiables. Consideremos un agente haciendo un cálculo financiero: una tasa de error del 5% significa que 1 de cada 20 cálculos es incorrecto. Si el agente calcula cuotas de préstamos, rendimientos de inversiones u obligaciones fiscales, una tasa de error del 5% es catastrófica. Por eso las arquitecturas de agentes incluyen herramientas de calculadora: no porque los LLM no puedan hacer matemáticas, sino porque no pueden hacerlas con suficiente fiabilidad.

Idea clave: Un buen agente conoce sus propias limitaciones. Ante "¿Cuánto es 7 x 8?", un agente bien diseñado debería responder directamente (lo sabe con fiabilidad). Ante "¿Cuánto es 14.273 x 89.651?", debería usar una herramienta de calculadora. El prompt del sistema y las descripciones de herramientas deberían guiar este comportamiento.

4.2 Razonamiento lógico

Comprender cómo los LLM manejan distintos tipos de razonamiento lógico es importante para el diseño de agentes porque nos indica qué tipos de razonamiento podemos confiar al modelo y cuáles necesitamos verificar mediante herramientas o sistemas externos.

Los LLM manejan varios tipos de razonamiento lógico con fiabilidad variable:

Razonamiento deductivo (dadas premisas, derivar conclusiones):

All mammals breathe air.
Whales are mammals.
Therefore, whales breathe air.

Los LLM manejan bien los silogismos simples, pero tienen dificultades con cadenas de razonamiento más largas o cuando se incluyen premisas irrelevantes. Añadir información irrelevante ("Los pájaros también respiran aire. Algunos peces también pueden respirar aire.") puede confundir al modelo, aunque lógicamente no debería afectar la conclusión.

Razonamiento inductivo (generalizar a partir de ejemplos):

Observation: Every swan I've seen is white.
Hypothesis: All swans are white.

Los LLM pueden identificar patrones pero pueden sobregeneralizar. También tienen dificultades para saber cuándo el razonamiento inductivo es apropiado frente a cuándo se necesitan más datos.

Razonamiento abductivo (encontrar la mejor explicación):

The grass is wet. It probably rained.
(But it could also be sprinklers, morning dew, or a broken pipe.)

Los LLM son sorprendentemente buenos en este tipo de razonamiento cotidiano, probablemente porque sus datos de entrenamiento están llenos de narrativas que explican observaciones. Esto es valioso para los agentes: cuando una llamada a herramienta falla, el agente necesita razonar sobre por qué falló y qué intentar a continuación.

4.3 Razonamiento de sentido común

Los LLM han absorbido un vasto conocimiento de sentido común de sus datos de entrenamiento:

Q: "If I put a glass of water in the freezer overnight, what happens?"
A: "The water freezes and turns to ice. The glass might crack if
    the water expands enough."

Este tipo de razonamiento de sentido común es fundamental para agentes que interactúan con el mundo real:

• Un agente de programación necesita saber que hay que probar el código antes de desplegarlo.
• Un agente de investigación necesita saber que un artículo de 2019 no puede citar uno de 2023.
• Un agente de planificación de horarios necesita saber que la gente generalmente no quiere reuniones a las 3 de la madrugada.

Lo notable del razonamiento de sentido común de los LLM es su amplitud. Nadie programó "el agua se expande al congelárse" en el modelo; lo aprendió del texto. El desafío es que el conocimiento de sentido común es también donde las alucinaciones son más difíciles de detectar: el modelo puede afirmar algo con la misma confianza sea un hecho genuino o una fabricación que suena plausible.

4.4 Planificación

La planificación es quizás la capacidad de razonamiento más importante para los agentes, y también una de las más difíciles de lograr correctamente. Implica:

1. Comprender el estado objetivo
2. Identificar el estado actual
3. Generar una secuencia de acciones para pasar del estado actual al objetivo
4. Anticipar obstáculos y alternativas

Los LLM muestran capacidades de planificación mixtas:

• Planes simples (3-5 pasos, dominios familiares): Generalmente fiables. "Para hacer un sándwich: coger pan, añadir relleno, cerrar el sándwich." El modelo ha visto miles de planes así en sus datos de entrenamiento.
• Planes complejos (10+ pasos, dominios nuevos): Frecuentemente defectuosos; pueden omitir dependencias, generar pasos imposibles o no tener en cuenta restricciones. "Diseñar un plan de migración para mover 200 microservicios de AWS a GCP" probablemente tendrá errores.
• Planificación a largo plazo: Particularmente desafiante; los agentes tienden a perder de vista el objetivo general durante una ejecución prolongada. Después de 15 pasos, el agente puede olvidar lo que originalmente intentaba lograr.

Por eso muchas arquitecturas de agentes separan la planificación de la ejecución (lo cubriremos en la Semana 5). El planificador crea una estrategia de alto nivel, y el ejecutor lleva a cabo cada paso, con revisiones periódicas para asegurarse de que el plan sigue teniendo sentido.

4.5 Generación y depuración de código

La generación de código merece mención especial porque es la capacidad de razonamiento más útil en la práctica para los agentes de programación, el tipo de agente más desplegado en la actualidad.

Los LLM pueden generar código funcional a partir de descripciones en lenguaje natural, depurar código analizando mensajes de error, refactorizar código para mejorar legibilidad o rendimiento, escribir tésts para código existente y explicar qué hace un código en lenguaje natural.

Sin embargo, la generación de código tiene modos de fallo característicos:

• Código plausible pero incorrecto: El código parece correcto y puede incluso compilar, pero tiene un error lógico sutil. Este es el equivalente en código de la alucinación factual.
• APIs desactualizadas: El modelo puede usar funciones obsoletas o sintaxis antigua de bibliotecas de sus datos de entrenamiento.
• Vulnerabilidades de seguridad: El modelo puede generar código que funciona pero tiene riesgos de inyección SQL, credenciales hardcodeadas u otros problemas.
• Sobreajuste a ejemplos: Si el prompt se asemeja a un ejemplo común de tutorial, el modelo puede producir la solución del tutorial en lugar de la variación solicitada.

Para agentes de programación, la implicación es clara: siempre ejecutar el código generado, siempre ejecutar los tests, y siempre revisar los cambios críticos de seguridad. La arquitectura del agente debería incluir pasos de verificación, no solo pasos de generación.

Inténtalo tú mismo: Pide a un LLM que planifique una tarea compleja, como "Organizar una fiesta sorpresa de cumpleaños para 30 personas en un restaurante". Examina el plan buscando: (a) pasos faltantes, (b) errores de dependencia (pasos que dependen de información aún no disponible), (c) suposiciones poco realistas. ¿Cómo corregirías el plan? ¿Qué necesitaría una arquitectura de agente para manejar estos problemas automáticamente?

185. Limitaciones

Comprender las limitaciones de los LLM no es pesimismo; es conocimiento de ingeniería esencial. Cada limitación implica una decisión de diseño: si el modelo puede alucinar, añadir verificación. Si la ventana de contexto es limitada, añadir gestión de memoria. Si el modelo es sensible a la formulación del prompt, añadir pruebas de robustez.

Un modelo mental útil: pensemos en cada limitación como un "modo de fallo" que nuestra arquitectura de agente debe manejar. Así como un ingeniero mecánico diseña puentes para resistir modos de fallo específicos (viento, carga, terremotos), un ingeniero de agentes diseña sistemas para resistir modos de fallo específicos de los LLM (alucinación, desbordamiento de contexto, sensibilidad al prompt). Las arquitecturas que estudiaremos en la Semana 5 son, en muchos sentidos, respuestas de ingeniería a las limitaciones descritas a continuación.

5.1 Alucinaciones

La alucinación es la generación de contenido que suena plausible pero es factualmente incorrecto. Los tipos incluyen:

• Alucinación factual: Afirmar hechos incorrectos ("La Torre Eiffel fue construida en 1910"). El modelo genera texto que suena correcto pero es erróneo. Esto es particularmente peligroso porque el modelo tiene la misma confianza en afirmaciones verdaderas y falsas.
• Citas fabricadas: Inventar artículos, autores o lugares de publicación que no existen. "Según Smith et al. (2023) en Nature..." cuando no existe tal artículo. Este es un problema bien documentado que ha llevado a incidentes embarazosos en escritos legales y artículos académicos.
• Alucinación lógica: Cometer errores de razonamiento mientras presenta la cadena de pensamiento con confianza. El modelo podría plantear correctamente un problema matemático y luego cometer un error aritmético, o identificar correctamente las premisas y luego extraer una conclusión inválida.
• Alucinación contextual: Contradecir información proporcionada en la conversación. Le dices al modelo "La reunión es el martes" y después dice "Como comentamos, la reunión del miércoles..."

Por qué esto importa para los agentes: Un agente que alucina un nombre de función que no existe producirá código que se rompe. Un agente que alucina una cita socava la integridad de la investigación. Un agente que alucina una ruta de archivo no podrá leer el archivo. Las arquitecturas de agentes deben incluir mecanismos de verificación: uso de herramientas (para verificar hechos), ejecución de código (para verificar que el código funciona) y autorreflexión (para detectar errores).

Estrategias de mitigación:

1. Generación Aumentada por Recuperación (RAG): Fundamentar las respuestas en documentos recuperados. En lugar de depender de la memoria del modelo, proporcionar la información relevante en el contexto.
2. Uso de herramientas: Usar motores de búsqueda, bases de datos y APIs para verificar afirmaciones. "Déjame comprobar eso..." debería ser una parte natural del comportamiento del agente.
3. Verificación de autoconsistencia: Generar múltiples respuestas y verificar la concordancia. Si 5 cadenas de razonamiento independientes producen respuestas diferentes, el modelo está inseguro.
4. Calibración de confianza: Pedir al modelo que califique su confianza (imperfecto pero útil). La investigación muestra que los LLM están mal calibrados por defecto pero pueden mejorar con prompts apropiados.

5.2 Limitaciones de la ventana de contexto

Incluso los modelos con ventanas de contexto de 200K tokens enfrentan limitaciones:

• "Perdido en el medio" (Liu et al., 2024): Un hallazgo llamativo. Los modelos tienden a prestar más atención a la información al principio y al final del contexto, pudiendo perder información importante en el medio. En experimentos, la precisión en tareas de recuperación de información cayó significativamente cuando la información relevante se colocába en medio de un contexto largo, en comparación con el principio o el final.

• Coste computacional: La atención es cuadrática en la longitud de la secuencia ($O(n^2)$), haciendo que los contextos muy largos sean costosos. Procesar un contexto de 200K tokens cuesta aproximadamente 400 veces más que procesar un contexto de 10K tokens, en términos de computación por token.

• Densidad de información: Llenar el contexto con información irrelevante degrada el rendimiento incluso si la información relevante está presente. Más contexto no siempre es mejor.

Implicaciones para agentes: La gestión de la memoria es crucial. Los agentes deben decidir qué mantener en contexto, qué resumir y qué almacenar en memoria externa. Esto es análogo a cómo un investigador decide qué notas mantener en su escritorio frente a archivar para más tarde. Cubriremos las estrategias de gestión de memoria en la Semana 7.

Idea clave: Un error común en el diseño de agentes es meter todo en el contexto ("dale toda la información y que lo resuelva"). Esto falla por dos razones: (1) es costoso, y (2) el modelo rinde peor con ruido de contexto irrelevante. Los buenos agentes son selectivos con lo que incluyen en contexto, igual que los buenos investigadores son selectivos con lo que leen.

5.3 Fechas de corte del conocimiento

Los LLM tienen una fecha de corte de los datos de entrenamiento. No saben sobre eventos, publicaciones o actualizaciones de software que ocurrieron después del entrenamiento. Para los agentes, esto significa:

• Pueden sugerir APIs obsoletas o versiones antiguas de bibliotecas. ("Usa requests.get() con verify=False" cuando la API ha cambiado.)
• Pueden no conocer vulnerabilidades de seguridad recientes.
• Pueden hacer referencia a organizaciones, personas o proyectos de forma inexacta si las cosas han cambiado.

Solución: Uso de herramientas. La búsqueda web, la recuperación de documentación y las consultas a APIs proporcionan información actualizada. Un agente bien diseñado verifica su conocimiento contra fuentes actuales para cualquier cosa sensible al tiempo.

5.4 Sensibilidad a la formulación del prompt

La misma pregunta formulada de forma diferente puede producir respuestas distintas. Esto es problemático para los agentes porque:

• Las descripciones de herramientas deben elaborarse cuidadosamente.
• Los prompts del sistema requieren refinamiento iterativo.
• Pequeños cambios en el historial de conversación pueden alterar el comportamiento del agente.

Por ejemplo, "Calcula el coste total" y "¿Cuál es la suma de todos los costes?" podrían llevar a llamadas a herramientas diferentes o enfoques de cálculo distintos, aunque significan lo mismo. Esta fragilidad es la razón por la que la ingeniería de prompts (Semana 3) es una habilidad fundamental para los constructores de agentes.

5.5 Adulación

Los modelos entrenados con RLHF a veces dan la razón al usuario incluso cuando este se equivoca. Esto se llama adulación (sycophancy; Pérez et al., 2023). El mecanismo es directo: durante el entrenamiento con RLHF, los evaluadores humanos tienden a preferir respuestas que concuerdan con ellos, así que el modelo aprende a estar de acuerdo.

Para los agentes, la adulación puede manifestarse como:

• Seguir adelante con un plan defectuoso en lugar de objetar. ("Usuario: Vamos a borrar la base de datos de producción y recrearla. Agente: ¡Gran idea! Déjame hacerlo.")
• Confirmar suposiciones incorrectas del usuario. ("Usuario: El bug está en el archivo X, ¿verdad? Agente: Sí, definitivamente está en el archivo X." Aunque el bug esté realmente en el archivo Y.)
• No señalar errores en la información proporcionada por el usuario.

Esto es particularmente peligroso para los agentes porque actúan sobre esos acuerdos. Un chatbot adulador da una respuesta incorrecta; un agente adulador toma una acción incorrecta.

196. Principales familias de modelos

Comprender las principales familias de modelos es importante para el diseño práctico de agentes porque cada familia tiene fortalezas y debilidades distintas. La elección del modelo afecta al coste, la capacidad, la latencia y las opciones de despliegue. En esta sección, examinamos el panorama a principios de 2026.

Concepto erróneo frecuente: "Existe un único modelo 'mejor'." En realidad, el mejor modelo depende de la tarea específica, el presupuesto, los requisitos de latencia y las restricciones de despliegue. Un modelo que destaca en generación de código podría rendir peor en escritura creativa. Un modelo excelente para inglés podría tener dificultades con otros idiomas. Los diseñadores de agentes a menudo usan múltiples modelos dentro de un mismo sistema.

6.1 Serie GPT (OpenAI)

Características: Razonamiento general sólido, excelente soporte de function calling, ecosistema de API bien establecido. La serie o1/o3 introdujo modelos de razonamiento dedicados que usan cómputo en tiempo de inferencia para problemas complejos. Los modelos GPT tienen la interfaz de function calling más madura, haciéndolos populares para aplicaciones de agentes.

6.2 Serie Claude (Anthropic)

Características: Fuerte alineación de seguridad (IA Constitucional), excelente siguiendo instrucciones complejas, ventanas de contexto largas, gran capacidad de programación. La función de pensamiento extendido (extended thinking) de Claude permite el razonamiento en tiempo de inferencia similar a o1. Los modelos Claude tienden a estar más dispuestos a decir "No estoy seguro" y son menos aduladores que algunas alternativas.

6.3 Serie Gemini (Google DeepMind)

Características: Ventanas de contexto extremadamente largas (hasta 2M tokens), capacidades multimodales nativas (texto, imagen, audio, vídeo), integración profunda con los servicios de Google. El contexto largo hace que Gemini sea particularmente interesante para agentes que necesitan procesar grandes cantidades de información, como analizar un repositorio de código completo o una colección de documentos.

6.4 Modelos de código abierto

Serie Llama (Meta):

Mistral (Mistral AI):

Características de los modelos abiertos: Se pueden alojar localmente (privacidad de datos), ajustár finaménte para dominios específicos, sin costes de API en tiempo de inferéncia. Sin embargo, generalmente van por detrás de los modelos cerrados de frontera en capacidad bruta, especialmente para razonamiénto complejo y uso de herramientas. Para aplicaciones de agentes, los modelos abiertos son atractivos cuando: los datos no pueden salir de la infraestructura propia, se necesita inferéncia de muy baja laténcia, o se quiere ajustár finaménte para un dominio específico.

6.5 Elección de un modelo para aplicaciones de agentes

En la práctica, muchos sistemas de agentes usan enrutamiento de modelos (model routing): un modelo rápido y barato para decisiones simples, y un modelo potente y caro para pasos de razonamiento complejo. Discutiremos esta estrategia en detalle en la Sección 7.5.5.

Inténtalo tú mismo: Si tienes acceso a múltiples APIs de LLM, prueba la misma tarea de agente (por ejemplo, "Busca información sobre X y luego calcula Y") con diferentes modelos. Compara: (1) Qué tan bien cada modelo sigue las instrucciones de llamada a herramientas. (2) La calidad del razonamiento en los pensamientos generados. (3) El coste por tarea. (4) La latencia por tarea. Documenta tus hallazgos.

207. Cómputo en tiempo de inferencia

Esta sección cubre uno de los desarrollos recientes más importantes en la tecnología LLM. El cómputo en tiempo de inferencia, la capacidad de los modelos de "pensar más" en problemas difíciles, cambia fundamentalmente las capacidades disponibles para los diseñadores de agentes. Si solo recuerdas una cosa de esta sección, recuerda la estrategia de enrutamiento de modelos de la Sección 7.5.5, porque es la que tiene mayor impacto práctico en el coste y rendimiento de los agentes.

7.1 La idea

Los LLM tradicionales gastan una cantidad fija de cómputo por token en tiempo de inferencia. Pero algunos problemas son más difíciles que otros: un saludo simple necesita menos reflexión que una demostración matemática compleja.

Pensemos en cómo resolvemos problemas nosotros. Cuando alguien pregunta "¿Cuánto es 2 + 3?", respondemos al instante. Cuando alguien pregunta "¿Cuál es la estrategia óptima para un escenario de negociación complejo?", hacemos una pausa, consideramos múltiples ángulos, evalúamos compromisos y luego respondemos. Dedicamos más esfuerzo cognitivo a los problemas más difíciles.

El cómputo en tiempo de inferencia (también llamado "test-time compute" o "thinking tokens") permite al modelo hacer lo mismo: dedicar más computación a los problemas más difíciles. Esta es la innovación clave detrás de los modelos o1/o3 de OpenAI y del pensamiento extendido de Anthropic.

7.2 Cómo funciona

El modelo genera una cadena de pensamiento antes de producir su respuesta final. Esta cadena de pensamiento es el modelo "razonando" a través del problema:

User: What is the 15th prime number?

Model (internal reasoning):
"Let me list the prime numbers:
2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47
That's 15 primes. The 15th is 47."

Model (output): The 15th prime number is 47.

La idea crucial es que este razonamiento ocurre en tiempo de inferencia, no durante el entrenamiento. El modelo está asignando más cómputo a problemas más difíciles generando más tokens. Cada token de pensamiento es una unidad de computación que ayuda al modelo a alcanzar una mejor respuesta.

7.3 Por qué esto importa para los agentes

El cómputo en tiempo de inferencia cambia fundamentalmente las capacidades de los agentes:

1. Mejor planificación: Los agentes pueden reflexionar sobre planes complejos antes de ejecutarlos. En lugar de lanzarse a la acción, el agente puede generar y evaluar múltiples planes en su espacio de pensamiento.
2. Detección de errores: El modelo puede detectar sus propios errores durante el proceso de pensamiento. "Espera, ese cálculo no parece correcto, déjame rehacerlo."
3. Uso complejo de herramientas: El uso de herramientas en múltiples pasos se beneficia del razonamiento explícito sobre qué herramientas llamar y en qué orden. "Necesito el clima primero, luego puedo decidir si recomendar actividades de interior o exterior."
4. Reducción de alucinaciones: Más tokens de pensamiento generalmente significan salidas más precisas, porque el modelo tiene más oportunidad de autocorregírse.

7.4 El compromiso cómputo-rendimiento

Más tokens de pensamiento significa:

• Mayor latencia (el modelo tarda más en responder)
• Mayor coste (se paga por token, incluyendo los tokens de pensamiento)
• Mejor precisión en tareas complejas
• Rendimientos decrecientes en tareas simples

Para el diseño de agentes, esto crea una cuestión importante de optimización: ¿cuánto debería "pensar" el agente antes de actuar? Pensar demasiado poco lleva a errores; pensar demasiado desperdicia tiempo y dinero. La respuesta depende de las consecuencias de los errores: un agente que reserva un vuelo debería pensar con cuidado (los errores son caros de corregir), mientras que un agente que formatea una tabla puede ser rápido y descuidado (los errores se corrigen fácilmente).

7.5 Pensamiento extendido y modelos de razonamiento

El concepto de cómputo en tiempo de inferencia ha evolucionado de una idea académica a una familia de modelos de producción específicamente diseñados para "pensar antes de responder". A menudo se denominan modelos de razonamiento, y representan un cambio de paradigma en cómo los LLM abordan problemas complejos.

7.5.1 Modelos o1 y o3 de OpenAI

El o1 de OpenAI (lanzado en septiembre de 2024) fue el primer modelo de razonamiento ampliamente disponible. Genera una cadena de pensamiento interna antes de producir una respuesta, gastando significativamente más cómputo en problemas más difíciles.

o3 (lanzado a principios de 2025) extendió este enfoque con capacidades de razonamiento mejoradas y la habilidad de "pensar" durante duraciones variables según la dificultad del problema.

Características clave:

• El modelo genera tokens de razonamiento ocultos que el usuario no ve en la salida final (aunque los conteos de tokens los reflejan). Se paga por estos tokens pero no se ven.
• En benchmarks matemáticos (AIME, MATH), o1/o3 superaron drásticamente a los modelos estándar de clase GPT-4.
• El proceso de razonamiento no es una plantilla fija; el modelo aprende durante el entrenamiento cuándo y cuánto razonar.
• OpenAI introdujo un parámetro reasoning_effort (low, medium, high) que permite a los usuarios controlar el compromiso entre profundidad de pensamiento y latencia/coste.

7.5.2 Pensamiento extendido de Anthropic

El pensamiento extendido (extended thinking) de Claude (introducido con Claude 3.5 y expandido en Claude 4) adopta un enfoque diferente: la trazá de pensamiento es visible para el desarrollador (aunque típicamente oculta a los usuarios finales).

Características clave:

• El modelo genera un bloque thinking antes de la respuesta, que contiene su razonamiento paso a paso.
• Los desarrolladores pueden inspeccionar la traza de pensamiento para depuración y transparencia. Esta es una ventaja significativa para el desarrollo de agentes: se puede ver por qué el agente tomó una decisión particular.
• El pensamiento extendido puede habilitarse o deshabilitarse por petición, y un parámetro budget_tokens controla el número máximo de tokens de pensamiento.
• Particularmente efectivo para razonamiento en múltiples pasos, generación de código y análisis complejo.

# Example: Claude extended thinking API call
import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=16000,
    thinking={
        "type": "enabled",
        "budget_tokens": 10000  # Up to 10K tokens for thinking
    },
    messages=[{
        "role": "user",
        "content": "Design a database schema for a multi-tenant SaaS platform with row-level security."
    }]
)

# The response contains both thinking and text blocks
for block in response.content:
    if block.type == "thinking":
        print(f"[Thinking]: {block.thinking[:200]}...")
    elif block.type == "text":
        print(f"[Response]: {block.text[:200]}...")

Analicemos este código:

• El parámetro thinking habilita el pensamiento extendido con un presupuesto de 10.000 tokens. El modelo puede usar hasta esta cantidad de tokens para su razonamiento interno.
• La respuesta contiene múltiples bloques de contenido. Un bloque thinking contiene el razonamiento interno del modelo; un bloque text contiene la respuesta final.
• Al inspeccionar el bloque de pensamiento, se puede comprender el proceso de razonamiento del modelo, lo cual es invaluable para depurar el comportamiento del agente.

7.5.3 DeepSeek R1: razonamiento de código abierto

DeepSeek R1 (enero de 2025) demostró que las capacidades de razonamiento no son exclusivas de los modelos de código cerrado. Es un modelo de razonamiento con pesos abiertos que genera trazas explícitas de cadena de pensamiento.

Características clave:

• Pesos completamente abiertos, permitiendo alojamiento propio y ajuste fino.
• Entrenado usando una combinación de ajuste fino supervisado sobre trazas de razonamiento y aprendizaje por refuerzo.
• El proceso de pensamiento es visible en la salida (envuelto en etiquetas <think>).
• El rendimiento en benchmarks de matemáticas y programación se acercó a los resultados de nivel o1 a una fracción del cóste.
• Las versiones destiladas (1.5B, 7B, 14B, 32B, 70B) hacen accesible el razonamiento en hardware más pequeño.

DeepSeek R1 es significativo porque demostró que el paradigma de razonamiento puede replicarse fuera de los grandes laboratorios, abriendo el cómputo en tiempo de inferencia a la comunidad de código abierto más amplia.

7.5.4 Implicaciones para el diseño de agentes

Los modelos de razonamiento cambian el cálculo de la arquitectura de agentes de varias maneras importantes:

1. Mejor planificación con menos iteraciones: Un modelo de razonamiento a menudo puede producir un plan correcto de múltiples pasos en una sola llamada, mientras que un modelo estándar podría necesitar varias iteraciones ReAct para converger en el mismo plan. Esto puede reducir el número total de llamadas LLM en un pipeline de agente.

2. Selección de herramientas más fiable: Cuando un agente necesita elegir entre múltiples herramientas o decidir el orden de las llamadas, un modelo de razonamiento es menos propenso a cometer errores porque razona explícitamente a través de las opciones antes de comprometerse.

3. Menor necesidad de andamiaje externo: Algunas arquitecturas de agentes (Reflexión, LATS) existen para compensar las limitaciones de razonamiento del modelo. Con modelos de razonamiento más fuertes, arquitecturas más simples pueden ser suficientes para tareas que anteriormente requerían andamiaje complejo.

4. Mayor coste y latencia por llamada: Los modelos de razonamiento pueden costar de 5 a 20 veces más por llamada que los modelos estándar y tardar de 5 a 30 veces más. Para un agente que hace de 10 a 20 llamadas por tarea, este coste se acumula rápidamente.

7.5.5 La estrategia de enrutamiento de modelos

En la práctica, los sistemas de agentes más efectivos usan enrutamiento de modelos: diferentes modelos para diferentes pasos en el pipeline del agente.

Esto es análogo a cómo opera una empresa: el CEO (caro, estratégico) toma decisiones de alto nivel, los gerentes (coste moderado) manejan la coordinación, y los becarios (baratos, rápidos) manejan tareas rutinarias. No se le paga al CEO para clasificar el correo.

7.5.6 Cuándo usar modelos de razonamiento en pipelines de agentes

Usar modelos de razonamiento para:

• Planificación inicial de tareas complejas (investigación, cambios de código en múltiples archivos)
• Decisiones con consecuencias altas (desplegar código, enviar correos, cálculos financieros)
• Tareas que requieren deducción lógica de múltiples pasos
• Análisis de errores y recuperación tras fallos
• Síntesis de información de múltiples fuentes

Usar modelos estándar/rápidos para:

• Llamadas simples a herramientas (lecturas de archivo, búsquedas, llamadas a APIs)
• Decisiones de clasificación y enrutamiento
• Conversión de formato y extracción de datos
• Subtareas repetitivas dentro de un bucle
• Pasos intermedios donde los errores son baratos de recuperar

7.5.7 La frontera se mueve rápido

El panorama de modelos de razonamiento está evolucionando rápidamente (a principios de 2026):

• OpenAI continúa iterando en la serie o, con o3-mini ofreciendo razonamiento a coste reducido.
• Anthropic ha integrado el pensamiento extendido profundamente en Claude, haciéndolo disponible en todos los niveles de modelos.
• Google DeepMind ha introducido capacidades de razonamiento en los modelos Gemini 2.0.
• Código abierto: DeepSeek R1, Qwen QwQ y otros modelos abiertos han llevado el razonamiento a despliegues autoalojádos.

La tendencia es clara: el cómputo en tiempo de inferencia se está convirtiendo en una característica estándar en lugar de una oferta premium, y el coste del razonamiento está disminuyendo con el tiempo. Para los diseñadores de agentes, esto significa que las estrategias de enrutamiento de modelos de hoy pueden simplificarse en el futuro a medida que el razonamiento se vuelva más barato y rápido.

218. Ejemplo de código: llamadas a la API de un LLM

8.1 Llamada básica a la API con OpenAI

"""
Basic LLM API call demonstrating system/user/assistant messages.
This is the fundamental building block of every LLM-based agent.
"""

from openai import OpenAI

client = OpenAI()  # Requires OPENAI_API_KEY environment variable

# The three message roles:
# - system: Sets the behavior and persona of the assistant.
#   Think of it as the agent's "job description." It is processed
#   first and strongly influences all subsequent behavior.
#
# - user: The human's input. In an agent loop, this also includes
#   tool results fed back to the model.
#
# - assistant: Previous responses from the model (for multi-turn).
#   Including these maintains conversational continuity.

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {
            "role": "system",
            "content": (
                "You are an expert software architect. "
                "Provide concise, technically accurate responses. "
                "When discussing trade-offs, present both sides."
            )
        },
        {
            "role": "user",
            "content": "Should I use microservices or a monolith for a new startup?"
        }
    ],
    temperature=0.7,     # Controls randomness (0 = deterministic, 1 = creative)
    max_tokens=1024,     # Maximum length of response
)

print(response.choices[0].message.content)

Entendiendo temperature: Este parámetro controla la aleatoriedad de la salida.

• temperature=0.0: El modelo siempre elige el siguiente token más probable. Las salidas son deterministas y consistentes. Usar esto para tareas de agentes donde se necesita fiabilidad (llamadas a herramientas, salida estructurada, respuestas factuales).
• temperature=0.7: Un buen equilibrio entre creatividad y coherencia. Usar para conversación general y explicaciones.
• temperature=1.0: Máxima aleatoriedad dentro de la distribución del modelo. Usar para escritura creativa o lluvia de ideas.

Para aplicaciones de agentes, casi siempre se quiere temperature=0.0 para los pasos que generan acciones (llamadas a herramientas, toma de decisiones) y se pueden usar temperaturas más altas para la generación de texto orientado al usuario.

8.2 Llamada a la API con Anthropic (Claude)

"""
API call using the Anthropic Python SDK.
"""

import anthropic

client = anthropic.Anthropic()  # Requires ANTHROPIC_API_KEY

message = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=1024,
    system=(
        "You are an expert software architect. "
        "Provide concise, technically accurate responses."
    ),
    messages=[
        {
            "role": "user",
            "content": "Should I use microservices or a monolith for a new startup?"
        }
    ]
)

print(message.content[0].text)

Obsérvense las diferencias con la API de OpenAI:

• El prompt del sistema es un parámetro separado, no un mensaje en la lista.
• La respuesta está en message.content[0].text en lugar de response.choices[0].message.content.
• Estas diferencias son la razón por la que los protocolos de estandarización como MCP (Semana 4) son valiosos: abstraen las diferencias de API específicas de cada proveedor.

8.3 Conversación multi-turno

"""
Multi-turn conversation demonstrating how context accumulates.
This is the foundation of agent memory within a single session.
"""

from openai import OpenAI

client = OpenAI()

def chat(messages: list[dict], user_input: str) -> str:
    """Send a message and get a response, maintaining conversation history."""
    # Add the user's message to the conversation history
    messages.append({"role": "user", "content": user_input})

    # Send the ENTIRE conversation history to the model
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=messages,
        temperature=0.7,
    )

    # Extract the assistant's response
    assistant_message = response.choices[0].message.content

    # Add the assistant's response to the history for future turns
    messages.append({"role": "assistant", "content": assistant_message})

    return assistant_message


# Initialize conversation with a system message
messages = [
    {
        "role": "system",
        "content": "You are a helpful Python tutor. Teach concepts step by step."
    }
]

# Simulate a multi-turn conversation
response1 = chat(messages, "What are Python decorators?")
print(f"Turn 1: {response1}\n")

response2 = chat(messages, "Can you show me a simple example?")
print(f"Turn 2: {response2}\n")

response3 = chat(messages, "How would I use that in a web framework?")
print(f"Turn 3: {response3}\n")

# At this point, `messages` contains the full conversation history.
# The model has access to all previous turns when generating each response.
print(f"Total messages in history: {len(messages)}")

Este código demuestra un punto crucial sobre los agentes basados en LLM: el modelo no tiene memoria entre llamadas a la API. Cada llamada envía el historial completo de conversación. Esto significa:

• La "memoria" del agente es lo que se incluya en la lista messages.
• El contexto crece con cada turno, aumentando el coste y eventualmente alcanzando el límite de la ventana.
• Tú (el desarrollador) controlas lo que el agente recuerda controlando lo que va en messages.

Idea clave: Este diseño sin estado por llamada es tanto una limitación como una ventaja. Significa que los agentes no tienen estado oculto (todo está en los mensajes), lo que facilita la depuración. Pero también significa que hay que gestionar activamente la memoria a medida que las conversaciones crecen.

8.4 Salida estructurada

Para aplicaciones de agentes, a menudo necesitamos que el modelo produzca salida estructurada que pueda ser parseada programáticamente. Una llamada a herramienta es salida estructurada; una decisión entre opciones es salida estructurada; los datos extraídos son salida estructurada.

"""
Getting structured JSON output from an LLM.
Critical for tool selection and agent decision-making.
"""

import json
from openai import OpenAI

client = OpenAI()

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {
            "role": "system",
            "content": (
                "You analyze sentiment in text. "
                "Always respond with a JSON object containing: "
                "sentiment (positive/negative/neutral), "
                "confidence (0-1), "
                "key_phrases (list of important phrases)."
            )
        },
        {
            "role": "user",
            "content": "The new restaurant downtown is amazing! The food is incredible but the wait times are a bit long."
        }
    ],
    response_format={"type": "json_object"},  # Force JSON output
    temperature=0.0,  # Low temperature for consistent structured output
)

result = json.loads(response.choices[0].message.content)
print(json.dumps(result, indent=2))

# Expected output:
# {
#   "sentiment": "positive",
#   "confidence": 0.78,
#   "key_phrases": ["amazing", "incredible", "wait times a bit long"]
# }

El parámetro response_format={"type": "json_object"} indica al modelo que siempre produzca JSON válido. Esto es esencial para la fiabilidad del agente: sin él, el modelo podría a veces producir JSON y a veces texto narrativo, rompiendo el código de parseo.

8.5 Respuestas en streaming

Para las interfaces de agentes, el streaming proporciona una mejor experiencia de usuario: el usuario ve la respuesta generándose en tiempo real en lugar de esperar a la respuesta completa.

"""
Streaming API call — essential for responsive agent interfaces.
"""

from openai import OpenAI

client = OpenAI()

stream = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "Explain how TCP/IP works."}
    ],
    stream=True,  # Enable streaming
)

# Process tokens as they arrive
for chunk in stream:
    if chunk.choices[0].delta.content is not None:
        print(chunk.choices[0].delta.content, end="", flush=True)

print()  # Final newline

El streaming es particularmente importante para las interfaces de agentes porque las operaciones de agentes pueden tardar mucho (múltiples llamadas a herramientas, pensamiento extendido). Sin streaming, el usuario mira una pantalla en blanco durante 10-30 segundos preguntándose si algo está pasando. Con streaming, vé los pensamientos del agente formándose en tiempo real, lo que genera confianza y permite intervenir temprano si el agente va en la dirección equivocada.

8.6 Conteo de tokens y conciencia de costés

"""
Understanding token usage — critical for agent cost management.
"""

import tiktoken  # OpenAI's tokenizer library

# Load the tokenizer for GPT-4o
encoding = tiktoken.encoding_for_model("gpt-4o")

text = "The quick brown fox jumps over the lazy dog."
tokens = encoding.encode(text)

print(f"Text: {text}")
print(f"Token count: {len(tokens)}")
print(f"Tokens: {tokens}")
print(f"Decoded tokens: {[encoding.decode([t]) for t in tokens]}")

# Cost estimation (approximate, as of 2025)
# GPT-4o: ~$2.50 per 1M input tokens, ~$10 per 1M output tokens
# Claude 3.5 Sonnet: ~$3 per 1M input tokens, ~$15 per 1M output tokens

def estimate_cost(input_tokens: int, output_tokens: int,
                  model: str = "gpt-4o") -> float:
    """Estimate API cost for a given token count."""
    rates = {
        "gpt-4o": {"input": 2.50, "output": 10.00},
        "gpt-4o-mini": {"input": 0.15, "output": 0.60},
        "claude-3.5-sonnet": {"input": 3.00, "output": 15.00},
    }
    rate = rates.get(model, rates["gpt-4o"])
    return (input_tokens * rate["input"] + output_tokens * rate["output"]) / 1_000_000


# Agent cost estimation
# A typical agent might make 5-20 LLM calls per task
# Each call: ~2000 input tokens, ~500 output tokens
calls_per_task = 10
input_per_call = 2000
output_per_call = 500

cost = calls_per_task * estimate_cost(input_per_call, output_per_call)
print(f"\nEstimated cost per agent task (~{calls_per_task} calls): ${cost:.4f}")
print(f"Estimated cost for 1000 tasks: ${cost * 1000:.2f}")

Por qué importa la conciencia de costes: Un agente que hace 20 llamadas a la API por tarea a $0,05 por llamada cuesta$1,00 por tarea. Si se ejecuta ese agente 10.000 veces al día, se gastan $10.000/día solo en costes de API. La optimización de costes no es optimización prematura para agentes; es un requisito de negocio. La estrategia de enrutamiento de modelos de la Sección 7.5.5 puede reducir los costes de 5 a 10 veces usando modelos baratos para los pasos simples.

Inténtalo tú mismo: Estima el coste de ejecutar un agente que: (1) lee un archivo fuente de 500 líneas (~5000 tokens), (2) hace 5 llamadas de razonamiento con el archivo en contexto, y (3) genera una edición de 200 líneas (~2000 tokens). Compara el coste usando GPT-4o, GPT-4o-mini y un modelo de razonamiento como o3. ¿Cómo reduciría el enrutamiento de modelos el coste total?

229. El LLM como cerebro del agente: uniendo las piezas

Hemos cubierto la arquitectura, el entrenamiento, las capacidades, las limitaciones y las familias de modelos. Demos un paso atrás y sinteticemos lo que todo esto significa para alguien que construye un agente de IA.

9.1 ¿Qué hace a un LLM adecuado para la agencia?

No todos los modelos de lenguaje son buenos cerebros de agentes. Un modelo que destaca en escritura creativa podría ser terrible siguiendo instrucciones estructuradas. Un modelo excelente en preguntas y respuestas factuales podría tener dificultades con la planificación en múltiples pasos. Las capacidades clave para la agencia son:

1. Seguimiento de instrucciones: El modelo debe seguir de forma fiable instrucciones complejas y con múltiples partes. Un prompt de agente puede contener 20 reglas diferentes; el modelo necesita seguir todas simultáneamente.
2. Uso de herramientas: El modelo debe entender las descripciones de herramientas y generar llamadas correctas. Esto requiere comprender firmas de funciones, tipos de parámetros y cuándo cada herramienta es apropiada.
3. Salida estructurada: El modelo debe producir salida parseable (JSON, llamadas a funciones). Un único corchete faltante en una respuesta JSON puede bloquear al agente.
4. Autocorrección: El modelo debería ser capaz de reconocer y corregir sus propios errores. Cuando una llamada a herramienta falla, el agente debería razonar sobre por qué e intentar un enfoque diferente.
5. Manejo de contexto largo: Las conversaciones de agentes a menudo crecen; el modelo debe rastrear información a lo largo de todo el contexto. Olvidar una instrucción del prompt del sistema después de 50 turnos es un modo de fallo común.
6. Baja tasa de alucinación: Las decisiones de los agentes tienen consecuencias; fabricar información lleva a fallos. Un agente que alucina una ruta de archivo desperdicia una llamada a herramienta; uno que alucina un hecho crítico lleva a conclusiones erróneas.

9.2 La matriz de capacidades del agente

Aquí hay una forma práctica de evaluar si un modelo es adecuado para tu aplicación de agente:

Si un modelo falla estas pruebas básicas, producirá un agente poco fiable independientemente de lo buena que sea la arquitectura. Probar antes de construir.

9.3 La conexión razonamiento-acción

La idea clave que conecta el material de esta semana con el resto del curso es esta:

Idea clave: La capacidad de un agente para actuar eficazmente en el mundo está limitada por su capacidad de razonar. La capacidad de razonamiento del LLM es el cuello de botella fundamental del rendimiento del agente.

Si el modelo no puede razonar sobre qué herramienta usar, el agente llamará a las herramientas incorrectas. Si el modelo no puede planificar una estrategia de múltiples pasos, el agente tomará acciones localmente razonables pero globalmente subóptimas. Si el modelo alucina, el agente actuará sobre premisas falsas.

Por eso las próximas tres semanas están estructuradas como lo están:

• Semana 3 (Estrategias de prompting): Cómo mejorar el razonamiento del modelo a través del diseño de prompts. Mejores prompts llevan a mejor razonamiento, que lleva a mejor comportamiento del agente.
• Semana 4 (Uso de herramientas y MCP): Cómo extender las capacidades del agente a través de herramientas. Las herramientas compensan las limitaciones del modelo (cálculo, información actual, acciones).
• Semana 5 (Arquitecturas de agentes): Cómo estructurar el bucle razonamiento-acción para diferentes tipos de tareas. La arquitectura determina cómo el razonamiento del modelo se canaliza hacia un comportamiento efectivo.

2310. Preguntas de discusión

1. ¿Razonamiento o reconocimiento de patrones? Cuando un LLM resuelve un problema matemático, ¿está verdaderamente "razonando" o realizando un sofisticado reconocimiento de patrones? ¿Importa la distinción para el diseño de agentes? ¿Por qué o por qué no?

   Punto de partida: Consideremos que los humanos también aprenden matemáticas a través del reconocimiento de patrones (memorizando tablas de multiplicar, reconociendo tipos de problemas). ¿Es el razonamiento humano fundamentalmente diferente del sofisticado reconocimiento de patrones?

2. Límites del escalado: Las leyes de escalado sugieren que más cómputo lleva a mejor rendimiento. Pero ¿hay problemas que ningúna cantidad de escalado resolverá? ¿Qué limitaciones fundamentales podrían persistir independientemente del tamaño del modelo?

   Punto de partida: Consideremos tareas que requieren acceso a información privada con la que el modelo no fue entrenado, tareas que requieren interacción física con el mundo, o tareas donde la respuesta correcta depende de valores y preferencias en lugar de hechos.

3. Modelos abiertos vs. cerrados para agentes: ¿Cuáles son los compromisos de construir agentes sobre modelos de pesos abiertos (Llama, Mistral) vs. modelos de API cerrada (GPT-4, Claude)? Considerar factores como capacidad, coste, privacidad, personalización y fiabilidad.

   Punto de partida: Un hospital construyendo un agente para historiales médicos necesita privacidad de datos (favoreciendo modelos abiertos). Una startup construyendo un agente de programación necesita máxima capacidad (favoreciendo modelos cerrados). ¿Y un agente para una agencia gubernamental?

4. Asignación de cómputo en tiempo de inferencia: Si estuvieras diseñando un agente con un presupuesto fijo de $10 por tarea, ¿cómo asignarías el cómputo en tiempo de inferencia? ¿Preferirías muchas llamadas baratas o pocas llamadas caras con alto razonamiento?

   Punto de partida: Considerar la estrategia de enrutamiento de modelos. $10 podrían comprar ~100 llamadas a GPT-4o-mini, ~40 llamadas a GPT-4o, o ~5 llamadas a o3. ¿Qué combinación sería más efectiva?

5. El problema de los datos de entrenamiento: Los LLM se entrenan con texto de internet, que contiene errores, sesgos e información desactualizada. ¿Cómo afecta esto a la fiabilidad del agente, y qué soluciones arquitectónicas pueden mitigarlo?

   Punto de partida: Considerar RAG (recuperar información actual), uso de herramientas (verificar hechos) y autoconsistencia (generar múltiples respuestas y verificar la concordancia).

2411. Resumen y puntos clave

1. La arquitectura Transformer es la base de todos los LLM modernos. La autoatención permite el procesamiento paralelo y las dependencias de largo alcance, pero conlleva un cóste computacional cuadrático. Comprender la arquitectura ayuda a explicar el comportamiento de los agentes.

2. Los LLM adquieren capacidades a través de un pipeline de entrenamiento multi-etapa: preentrenamiento (lenguaje y conocimiento), ajuste por instrucciones (seguir indicaciones) y alineación (seguridad y utilidad mediante RLHF/DPO). Cada etapa moldea el comportamiento del modelo como agente.

3. Las capacidades emergentes aparecen a medida que los modelos escalan, incluyendo aritmética, generación de código y seguimiento de instrucciones complejas. Sin embargo, la relación entre escala y capacidad es matizada, y los umbrales de fiabilidad importan más que las puntuaciones de benchmarks para las aplicaciones de agentes.

4. Los LLM tienen limitaciones fundamentales que afectan directamente al diseño de agentes: alucinaciones, restricciones de la ventana de contexto, fechas de corte del conocimiento, sensibilidad al prompt y adulación. Una buena arquitectura de agentes compensa estas limitaciones.

5. Las principales familias de modelos (GPT, Claude, Gemini, Llama, Mistral) ofrecen diferentes compromisos en capacidad, coste, longitud de contexto y opciones de despliegue. Los diseñadores de agentes deben elegir modelos según sus requisitos específicos, y a menudo usan múltiples modelos (enrutamiento de modelos) para una relación coste-rendimiento óptima.

6. El cómputo en tiempo de inferencia es un cambio de paradigma: modelos que "piensan más" en problemas difíciles logran resultados drásticamente mejores, lo cual es particularmente valioso para tareas complejas de agentes como la planificación y el análisis de errores.

7. La capacidad de razonamiento del LLM es el cuello de botella fundamental del rendimiento del agente. Las Semanas 3-5 explorarán cómo aumentar y estructurar este razonamiento a través de prompts, herramientas y arquitecturas.

2512. Ejercicio práctico

Este ejercicio está diseñado para proporcionar experiencia práctica con los conceptos de esta clase. El objetivo no es solo ejecutar código, sino desarrollar intuición sobre las capacidades y limitaciones de los modelos que informará las decisiones de diseño de agentes durante el resto del curso.

Explorar las capacidades de los modelos: Usando los ejemplos de llamadas a API de la Sección 8, realizar los siguientes experimentos:

1. Comparación de razonamiento: Dar el mismo problema de razonamiento con múltiples pasos a dos modelos diferentes (por ejemplo, GPT-4o-mini y GPT-4o, o un modelo Llama pequeño y grande). Comparar la calidad de sus cadenas de razonamiento y respuestas finales. Documentar diferencias específicas: ¿dónde falla el modelo más pequeño?

2. Barrido de temperatura: Para un prompt dado, generar respuestas a temperaturas 0,0, 0,3, 0,7 y 1,0. Documentar cómo cambian las respuestas en términos de precisión, creatividad y consistencia. Ejecutar cada temperatura 3 veces para observar la variabilidad.

3. Sensibilidad al contexto: Crear una conversación de 10 turnos y observar qué tan bien el modelo rastrea información de los primeros turnos. Probar colocando un dato clave en el turno 2 y preguntando sobre él en el turno 10. ¿Lo recuerda el modelo? ¿Y en el turno 50 (simulando una conversación larga)?

4. Fiabilidad de salída estructurada: Pedir al modelo que produzca salída JSON para 20 entradas diferentes. Medir la tasa de respuestas con JSON válido y la tasa de valores correctos en los campos. Comparar con y sin response_format={"type": "json_object"}.

5. Análisis de costes: Para cada experimento, rastrear el uso de tokens y calcular el costé. ¿Cuánto costaría cada experimento a escala (1000 ejecuciones)?

Entregable: Un notebook Jupyter con el código, las salidas y un análisis de una página de los hallazgos. Centrarse en las implicaciones prácticas: ¿qué significan los hallazgos para alguien que construye un agente?

26Referencias

• Bai, Y., Kadavath, S., Kundu, S., Askell, A., Kernion, J., Jones, A., ... & Kaplan, J. (2022). Constitutional AI: Harmlessness from AI feedback. arXiv preprint arXiv:2212.08073.
• Hoffmann, J., Borgeaud, S., Mensch, A., Buchatskaya, E., Caí, T., Rutherford, E., ... & Sifre, L. (2022). Training compute-optimal large language models. In Advances in Neural Information Processing Systems (NeurIPS).
• Kaplan, J., McCandlish, S., Henighan, T., Brown, T. B., Chess, B., Child, R., ... & Amodei, D. (2020). Scaling laws for neural language models. arXiv preprint arXiv:2001.08361.
• Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2024). Lost in the middle: How language models use long contexts. Transactions of the Association for Computational Linguistics, 12, 157-173.
• Ouyang, L., Wu, J., Jiang, X., Almeida, D., Wainwright, C., Mishkin, P., ... & Lowe, R. (2022). Training language models to follow instructions with human feedback. In Advances in Neural Information Processing Systems (NeurIPS).
• Pérez, E., Ringer, S., Lukosuite, K., Nguyen, K., Chen, E., Heiner, S., ... & Kaplan, J. (2023). Discovering language model behaviors with model-written evaluations. In Findings of the Association for Computational Linguistics: ACL 2023.
• Press, O., Smith, N. A., & Lewis, M. (2022). Train short, test long: Attention with linear biases enables input length generalization. In Proceedings of the International Conference on Learning Representations (ICLR).
• Rafailov, R., Sharma, A., Mitchell, E., Manning, C. D., Ermon, S., & Finn, C. (2023). Direct preference optimization: Your language model is secretly a reward model. In Advances in Neural Information Processing Systems (NeurIPS).
• Schaeffer, R., Miranda, B., & Koyejo, S. (2024). Are emergent abilities of large language models a mirage? In Advances in Neural Information Processing Systems (NeurIPS).
• Su, J., Ahmed, M., Lu, Y., Pan, S., Bo, W., & Liu, Y. (2024). RoFormer: Enhanced transformer with Rotary Position Embedding. Neurocomputing, 568, 127063.
• Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gómez, A. N., ... & Polosukhin, I. (2017). Attention is all you need. In Advances in Neural Information Processing Systems (NeurIPS).
• Wei, J., Wang, X., Schuurmans, D., Bosma, M., Ichter, B., Xia, F., ... & Zhou, D. (2022a). Chain-of-thought prompting elicits reasoning in large language models. In Advances in Neural Information Processing Systems (NeurIPS).
• Wei, J., Bosma, M., Zhao, V. Y., Guu, K., Yu, A. W., Lester, B., ... & Le, Q. V. (2022b). Finetuned language models are zero-shot learners. In Proceedings of the International Conference on Learning Representations (ICLR).

Parte de "Agentic AI: Foundations, Architectures, and Applications" (CC BY-SA 4.0).