Un agente que ejecuta una tarea y entrega el resultado sin revisarlo tiene la misma confiabilidad que un desarrollador que hace push directo a producción sin correr los tests. El patrón de reflexión es, en esencia, ese paso de verificación aplicado a agentes.
Reflexión (o self-critique) es un patrón arquitectónico donde, después de que un agente genera un resultado o completa una acción, un paso separado — ya sea el mismo modelo en otra llamada, un modelo distinto, o un subagente dedicado — evalúa ese resultado contra criterios explícitos antes de considerarlo final. Si la evaluación encuentra un problema, el agente revisa y vuelve a intentar; si no, el resultado se entrega.
La diferencia clave con "pedirle al modelo que revise su propio trabajo en la misma respuesta" es que la reflexión ocurre en un contexto separado, con un objetivo distinto (criticar, no generar) y frecuentemente con un modelo o nivel de esfuerzo diferente dedicado exclusivamente a esa evaluación.
Cuando le pides al mismo modelo, en la misma pasada de generación, que "revise su trabajo antes de responder", el modelo tiende a confirmar su propio razonamiento — el mismo sesgo que hace difícil para un humano encontrar sus propios errores de tipeo. Separar la crítica en una llamada distinta, con un prompt enfocado únicamente en encontrar fallas (no en producir el resultado), rompe ese sesgo de confirmación.
El error más común al implementar reflexión: pedirle al evaluador "revisa si esto está bien" sin criterios explícitos. Esto produce evaluaciones inconsistentes que a veces aprueban resultados malos y a veces rechazan resultados buenos. La evaluación necesita un rubric — criterios concretos, cada uno verificable de forma independiente.
Criterios vagos ("¿está bien escrito?") producen evaluaciones ruidosas. Criterios específicos y verificables producen evaluaciones que puedes confiar para gatear automáticamente si algo se reintenta o se entrega.
En agentes que ejecutan acciones (llamadas a APIs, escritura en bases de datos, cambios en sistemas), la reflexión debe verificar el efecto de la acción, no solo el texto generado. Un patrón efectivo: después de una acción con efectos secundarios, el agente ejecuta un paso de verificación que lee el estado resultante y confirma que coincide con lo esperado — antes de reportar éxito al usuario.
Este paso adicional, en un agente que borra registros, envía correos, o modifica configuraciones, es la diferencia entre "el agente dijo que lo hizo" y "el agente confirmó que efectivamente pasó".
La reflexión duplica (como mínimo) el costo y la latencia de cada tarea — no es gratis, y no todo justifica el gasto. Aplica el mismo criterio de "¿vale la pena el agente?" de cualquier decisión de arquitectura:
- **Costo del error:** si un error se detecta y corrige fácilmente después (un typo en un borrador), la reflexión agrega poco valor. Si un error es costoso o difícil de revertir (una transacción, un mensaje enviado a un cliente), la reflexión se paga sola. - **Complejidad de la tarea:** para clasificación simple o extracción determinística, el paso de reflexión rara vez encuentra algo que valga la pena el costo extra. - **Volumen:** en pipelines de alto volumen, considera reflexión solo en un porcentaje muestral de las salidas (para monitoreo de calidad) en vez de en el 100%, si el costo de reflexionar todo es prohibitivo.
Sin un límite explícito, un ciclo de generar-criticar-revisar puede quedarse dando vueltas indefinidamente en una tarea genuinamente ambigua o imposible de satisfacer con los criterios dados. Define un `max_iteraciones` explícito, y ten un camino de salida claro cuando se agotan — nunca un loop silencioso sin fondo.
El patrón de reflexión funciona mejor combinado con las otras técnicas de esta serie — no como sustituto de ellas. Un contexto bien estructurado (RAG preciso) reduce la necesidad de reflexión al minimizar errores desde el origen; instrucciones de calibración explícitas (que el modelo admita incertidumbre) reducen falsos "aprobados" en la etapa de crítica; y un set de regresión versionado (del artículo de prompts versionados) te dice si el paso de reflexión mismo está degradando con el tiempo.
Bien implementado, el patrón de reflexión no es "hacer que el agente piense dos veces" de forma genérica — es construir un segundo par de ojos con criterios explícitos, separado del primer paso de generación, exactamente donde el costo del error lo justifica.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel