Modelos razonadores¶
⏱️ Tiempo de lectura: 3 min
Los LLMs pueden parecer que razonan, pero “razonar” es una cualidad inherentemente humana. Lo podemos definir como un proceso con diferentes pasos que ejecutarlos consume tiempo físico (latencia), energía mental (cómputo) y no es infalible (alucinaciones).
En esta serie explicaremos que si el razonamiento es un proceso, entonces el tiempo de ejecución es una variable más. Puedes pagar más pasos, más muestras, más verificación o más interacción con herramientas para mejorar la calidad de la respuesta.
Índice¶
1. Qué es “razonar” para un LLM¶
- Veremos qué definiciones de razonamiento pueden encajar en el contexto de los LLMs.
- Nacimiento de los modelos razonadores: o1 de OpenAI como punto de salida.
- Repaso del paper de Apple sobre "The illusion of thinking" y la respuesta de Anthropic
2. Cómo se ven los fallos de estos sistemas¶
- Los fallos de este tipo de modelos no son aleatorios, definiremos sus diferentes tipos: Atajos, errores sistemáticos, deriva de objetivo y más.
- Veremos los métodos para detectarlos y mitigarlos al máximo.
3. Test-Time Compute¶
- Test-time compute como una nueva ley de escala para la IA generativa.
- Palancas para aprovechar al máximo esta nueva ley de escala: Más pasos internos, más generación de candidatos, más estructura.
- Relación entre una calidad superior de las respuestas asociada a un mayor coste y latencia.
4. Tiempo físico: latencia, streaming, interacción humana¶
- Veremos cómo “pensar más” en un paper es barato. En un producto, significa: El usuario espera, la sesión es más cara y el sistema tiene más puntos posibles de rotura.
- ¿Dónde está el umbral de latencia aceptable para esta tarea y este usuario? (Lanzamiento de GPT-5 como enrutador)
- Veremos que patrones nos pueden ayudar a optimizar al máximo los beneficios del test-time compute.
5. Riesgos: overthinking, coste, ataques, alineamiento¶
- Veremos por qué con más Test-Time Compute puede aparecer sobrepensamiento, bucles improductivos y degradación de la calidad.
- Aterrizaremos calidad vs coste vs latencia, y cómo se manifiesta en producto (SLOs, colas, facturas impredecibles, peor experiencia).
- Nuevas superficies de riesgo cuando hay herramientas / RAG / navegación: prompt injection, contaminación de contexto y uso indebido de tools.
- Cerraremos con criterios de diseño: presupuestos duros (tiempo/tokens/tools), señales de parada, verificación cuando sea crítico y fallbacks (pedir datos, degradar, abstenerse o derivar).