Los LLMs fallan en tareas complejas cuando intentan dar una respuesta directa sin descomponer el problema.
Situación típica 1 — Respuesta incorrecta por falta de pasos: preguntás "¿Cuántos días pasaron entre el lanzamiento del iPhone original y el primer Android?" y recibís "Aproximadamente 18 meses" — vago, sin mostrar el cálculo, posiblemente incorrecto.
Situación típica 2 — Alucinación por falta de verificación: preguntás por el CEO actual de una empresa y su fecha de asunción, y el LLM responde con confianza usando datos desactualizados, porque no puede verificar información actual.
Situación típica 3 — Tarea multi-paso resuelta de forma incompleta: pedís "analiza si esta empresa es buena inversión: revisa sus finanzas, competencia y tendencias" y obtenés un análisis superficial que mezcla todo sin estructura, omite pasos, y no indica qué información usó para cada conclusión.
Por qué es importante: sin estructura de razonamiento + acción, el LLM "adivina" en lugar de razonar paso a paso, no podés verificar cómo llegó a una conclusión, se salta pasos críticos en tareas complejas, y no reconoce cuándo necesita información externa.
ReAct es un patrón donde el LLM alterna entre:
Origen: el patrón viene del paper "ReAct: Synergizing Reasoning and Acting in Language Models" (Yao et al., 2022), donde demostró mejoras significativas en tareas de razonamiento y QA.
Incluye: ¿qué información necesito? ¿qué paso debo tomar ahora? ¿qué sé hasta ahora y qué me falta?
El LLM especifica una acción concreta a ejecutar. Las acciones típicas son:
Search[término] — Buscar informaciónCalculate[expresión] — Realizar cálculoLookup[fuente, dato] — Consultar una fuente específicaCompare[A, B] — Comparar dos elementosVerify[afirmación] — Verificar si algo es correctoEn una conversación real, vos proporcionás este resultado. En sistemas automatizados, una herramienta lo proporciona.
El proceso se repite hasta que el LLM tiene suficiente información para dar una respuesta fundamentada:
Search[término], WikiLookup[artículo], NewsSearch[tema], FactCheck[afirmación]Calculate[expresión], Compare[A, B, criterio], Aggregate[lista, operación], Trend[datos]ReadFile[ruta], SearchCode[patrón], RunTest[archivo], CheckSyntax[código]ListPros[opción], ListCons[opción], Evaluate[opción, criterio], Recommend[opciones]| Usá ReAct cuando... | NO uses ReAct cuando... |
|---|---|
| La tarea requiere múltiples pasos de razonamiento | La tarea es directa y simple |
| Necesitás verificar información antes de responder | Ya tenés toda la información necesaria |
| El problema requiere cálculos intermedios | Es una tarea creativa sin respuesta verificable |
| Querés auditar el razonamiento del LLM | La velocidad es más importante que la trazabilidad |
| La respuesta incorrecta tiene alto costo | Es brainstorming o exploración libre |
| Hay múltiples fuentes de información a consultar | Solo hay una fuente obvia |
Objetivo: aplicar el patrón ReAct para resolver tareas multi-paso, actuando vos como el "proveedor de observaciones" en una conversación con el LLM.
Contexto inicial: usá Claude.ai, ChatGPT, o cualquier interfaz de LLM. Vos simulás las herramientas proporcionando las observaciones cuando el LLM solicite una acción.
Copiá este prompt y envialo al LLM:
El LLM debería responder con un Thought y un Action: Search[ciudad más poblada de España], deteniéndose ahí. Le respondés vos con la Observation:
El LLM continúa pidiendo la ciudad de Portugal; le respondés:
El LLM debería notar la inconsistencia de unidades (ciudad vs. área metropolitana) y elegir un criterio consistente antes de calcular — anotá si lo hace explícito en su Thought. Verificá al final: ¿esperó tus observaciones o inventó datos? ¿mostró su razonamiento en cada Thought? ¿la respuesta final cita las fuentes/datos usados?
Diseñá un verificador de hechos con herramientas Search[consulta], Verify[afirmación], Conclude[veredicto], que termine con Verdict: VERDADERO/FALSO/PARCIALMENTE VERDADERO + explicación. Probalo con esta afirmación compuesta, que mezcla datos verdaderos y falsos a propósito:
El LLM debería descomponerla en las 4 partes verificables (década, creador, empleador, origen del nombre) y pedir observaciones para cada una. Las reales son: Guido van Rossum sí es el creador; el desarrollo empezó en 1989 pero la primera versión (0.9.0) se publicó en 1991, en el CWI (Centrum Wiskunde & Informatica) de Países Bajos — no en Google; y el nombre sí viene del grupo de comedia Monty Python's Flying Circus. El resultado esperado es PARCIALMENTE VERDADERO, con el desglose punto por punto de qué era cierto y qué no.
Usá el patrón para una decisión técnica real: herramientas Research[tema], ListPros[opción], ListCons[opción], Score[opción, criterio] (puntúa 1-10), Decide[opciones]. Tarea: un equipo debe elegir entre PostgreSQL y MongoDB para una app de e-commerce, considerando escalabilidad, flexibilidad del schema, transacciones, y ecosistema/soporte. Cuando el LLM pida ListPros[PostgreSQL], podés responder con: transacciones ACID completas, SQL estándar, excelente para relaciones complejas, maduro y estable, extensiones potentes (PostGIS, full-text search). Seguí dando observaciones reales para cada pedido hasta que llegue a una Final Decision con Reasoning explícito.
Para tareas donde el LLM ya tiene el conocimiento necesario, puede generar sus propias observaciones por lógica pura — es el caso de un problema de deducción:
Acá el formato usa Action: [Analyze/Deduce/Check][parámetro] y el LLM mismo genera la Observation basándose en lógica, empezando por las pistas más restrictivas (Bruno no es médico ni abogado → es ingeniero → vive en Barcelona por la pista 2), y encadenando el resto hasta resolver el sistema completo.
Elegí uno de estos escenarios y armá el prompt completo:
SearchAttractions, CheckWeather, EstimateCost, PlanDayReadCode, IdentifyError, ProposeFix, ValidateFixListCompetitors, CompareFeature, AnalyzePrice, SWOTAnalysisTu prompt debe incluir: lista de herramientas con descripción, formato Thought/Action/Observation, reglas claras (esperar observaciones, no inventar), y la tarea específica.
| Si ves esto... | Causa | Solución |
|---|---|---|
| El LLM inventa las observaciones en lugar de esperar | No enfatizaste que debe esperar | Añadí: "DETENTE después de cada Action. NO generes Observation, espera mi respuesta." |
| Salta directamente a la respuesta sin razonar | No usó el formato | Incluí un ejemplo completo del ciclo T/A/O en el prompt |
| Actions demasiado vagas ("Search[info]") | Herramientas no bien definidas | Definí parámetros esperados: "Search[consulta específica sobre X]" |
| Se pierde en loops infinitos | No definiste condición de parada | Añadí: "Máximo 5 ciclos. Si no tenés respuesta, indicá qué información falta." |
| Mezcla Thought y Action en una línea | Formato no lo suficientemente estricto | Mostrá un ejemplo con saltos de línea claros entre cada componente |
| No cita las observaciones en la respuesta final | No lo requeriste | Añadí: "Tu Answer debe referenciar las Observations que usaste como evidencia" |
El ciclo Thought/Action/Observation te da razonamiento visible, pero visible no es lo mismo que fiel. Un LLM puede generar un Thought que suena coherente sin que sea realmente lo que determinó la Action siguiente — es razonamiento post-hoc, no una traza interna verificada. ReAct es una herramienta de auditoría muy útil, pero no una garantía de que el modelo "pensó" exactamente lo que escribió. Cuando algo importa de verdad, seguí verificando las Observations contra fuentes reales, no solo contra la coherencia narrativa del Thought.
Concepto central: ReAct convierte al LLM de un "oráculo que adivina" a un "agente que razona y actúa". Al forzar el ciclo Thought → Action → Observation, el LLM descompone problemas complejos, verifica información antes de usarla, y produce respuestas trazables y auditables.
Para recordar: