Phase 14 - Lesson 05

Self-Refine y CRITIC: Mejora Iterativa de Resultados

Self-Refine (Madaan et al., 2023) utiliza un único LLM en tres roles — generate, feedback, refine — en un bucle. Ganancia promedio: +20 absoluto en 7 tareas. CRITIC (Gou et al., 2023) refuerza el paso de feedback canalizando la verificación a través de herramientas externas. En 2026, este patrón se incluye en todos los frameworks como "evaluator-optimizer" (Anthropic) o un bucle de guardrails (OpenAI Agents SDK).

Type: Build Languages: Python (stdlib) Prerequisites: Phase 14 · 01 (Agent Loop), Phase 14 · 03 (Reflexion) Time: ~60 minutes

Learning Objectives

  • Explicar los tres prompts de Self-Refine (generate, feedback, refine) y por qué el historial es importante para el prompt de refinamiento.
  • Explicar la idea clave de CRITIC: los LLMs no son confiables en la autoverificación sin un respaldo (grounding) externo.
  • Implementar un bucle Self-Refine con stdlib que incluya historial y un verificador externo opcional.
  • Mapear este patrón al flujo de trabajo "evaluator-optimizer" de Anthropic y a los guardrails de salida del OpenAI Agents SDK.

The Problem

Un agente genera una respuesta que está casi bien. Quizás una línea de código tiene un error de sintaxis. Quizás un resumen es demasiado largo. Quizás un plan pasa por alto un caso límite. Lo que se busca es: el agente critica su propio resultado y luego lo corrige.

Self-Refine demuestra que esto funciona con un solo modelo, sin datos de entrenamiento y sin RL. Pero hay un problema: los LLMs son malos autoverificando hechos concretos. CRITIC define la solución: canalizar el paso de verificación a través de herramientas externas (búsqueda, intérprete de código, calculadora, ejecutor de pruebas).

Juntos, estos dos artículos definen el estándar de 2026 para la mejora iterativa: generar (generate), verificar (verify, de forma externa cuando sea posible), refinar (refine) y detenerse cuando el verificador sea aprobado.

The Concept

Self-Refine (Madaan et al., NeurIPS 2023)

Un LLM, tres roles:

generate(task)            -> output_0
feedback(task, output_0)  -> critique_0
refine(task, output_0, critique_0, history) -> output_1
feedback(task, output_1)  -> critique_1
refine(task, output_1, critique_1, history) -> output_2
...
stop when feedback says "no issues" or budget exhausted.

Detalle clave: refine ve el historial completo —todos los resultados y críticas anteriores— para no repetir errores. El artículo analiza esto (ablación): al quitar el historial, la calidad cae drásticamente.

Destaque: +20 de mejora absoluta promedio en 7 tareas (matemáticas, código, acrónimos, diálogo), incluyendo GPT-4. Sin entrenamiento, sin herramientas externas, un solo modelo.

CRITIC (Gou et al., arXiv:2305.11738, v4 Feb 2024)

La debilidad de Self-Refine: el paso de feedback consiste en que el LLM se califica a sí mismo. Para afirmaciones fácticas esto no es confiable (una alucinación a menudo parece convincente para el modelo que la produjo). CRITIC reemplaza feedback(task, output) con verify(task, output, tools), donde tools incluye:

  • Un motor de búsqueda para afirmaciones fácticas.
  • Un intérprete de código para verificar la corrección del código.
  • Una calculadora para aritmética.
  • Verificadores específicos del dominio (pruebas unitarias, verificadores de tipos, linters).

El verificador produce una crítica estructurada respaldada por los resultados de las herramientas. Luego, el refinador se condiciona a esta crítica.

Destaque: CRITIC supera a Self-Refine en tareas fácticas porque la crítica está respaldada. En tareas sin verificadores externos (escritura creativa, formato), CRITIC se reduce a Self-Refine.

La condición de parada

Dos formatos comunes:

  1. El verificador es aprobado. La prueba externa devuelve un resultado exitoso. Se prefiere cuando está disponible (pruebas unitarias, verificador de tipos, aserción de guardrails).
  2. No se emite feedback. El modelo indica que "el resultado está bien". Es más económico pero no confiable; se debe combinar con un límite máximo de iteraciones.

Estándar de 2026: combinarlos. "Detener si el verificador es aprobado O el modelo dice que está bien Y las iteraciones >= 2 O las iteraciones >= max_iterations."

Evaluator-Optimizer (Anthropic, 2024)

La publicación de Anthropic de diciembre de 2024 define este como uno de los cinco patrones de flujo de trabajo. Dos roles:

  • Evaluador (Evaluator): califica el resultado y produce una crítica.
  • Optimizado (Optimizer): revisa el resultado dada la crítica.

El bucle continúa hasta que el evaluador apruebe. Esto es Self-Refine/CRITIC en el enfoque de Anthropic. El detalle de ingeniería crítico que Anthropic añade es: los prompts del evaluador y del optimizador deben ser sustancialmente diferentes para que el modelo no se limite a aprobar automáticamente ("rubber-stamp").

OpenAI Agents SDK output guardrails

OpenAI Agents SDK distribuye este patrón como "guardrails de salida" (output guardrails). Un guardrail es un validador que se ejecuta sobre el resultado final de un agente. Si el guardrail se activa (lanza OutputGuardrailTripwireTriggered), el resultado se rechaza y el agente puede reintentarlo. Los guardrails pueden llamar a herramientas (estilo CRITIC) o ser funciones puras (estilo Self-Refine).

Armadillas de 2026

  • Bucles de aprobación automática (Rubber-stamp loops). El mismo modelo haciendo la generación y la crítica con el mismo estilo de prompt converge en "se ve bien". Use prompts estructuralmente diferentes, o un modelo más pequeño y económico para la crítica.
  • Refinamiento excesivo. Cada paso de refinamiento añade latencia y tokens. Presupueste entre 1 y 3 pasos; después de eso, escale a una revisión humana.
  • CRITIC en tareas triviales. Si no hay un verificador externo, CRITIC se degrada a Self-Refine; no pague la latência por un verificador simulado (stub).

Build It

El archivo code/main.py implementa Self-Refine y CRITIC en una tarea sencilla: producir una lista corta de viñetas sobre un tema. El verificador comprueba el formato (3 viñetas, cada una de menos de 60 caracteres). CRITIC añade un "verificador de hechos" externo que penaliza alucinaciones conocidas.

Componentes:

  • generate — productor guionado.
  • feedback — autocrítica al estilo de un LLM.
  • verify_external — verificador respaldado al estilo de CRITIC.
  • refine — reescribe el resultado considerando el historial.
  • Condición de parada — el verificador es aprobado o se alcanza un máximo de 4 iteraciones.

Ejecútelo:

python3 code/main.py

Compare las ejecuciones de Self-Refine y CRITIC. CRITIC detecta un error fáctico que Self-Refine pasó por alto porque el verificador externo cuenta con un respaldo del que carece el autocritico.

Use It

El esquema evaluator-optimizer de Anthropic es este patrón en un lenguaje amigable para Claude. Los guardrails de salida de OpenAI Agents SDK tienen la estructura de CRITIC (los guardrails pueden llamar a herramientas). LangGraph incluye un nodo de reflexión que funciona de forma similar a Self-Refine. Computer Use de Gemini 2.5 de Google añade un evaluador de seguridad por paso que es una variante de CRITIC: cada acción se verifica antes de confirmarse.

Ship It

El archivo outputs/skill-refine-loop.md configura un bucle evaluator-optimizer dado el formato de la tarea, la disponibilidad del verificador y el presupuesto de iteraciones. Emite prompts para el generador, el evaluador/verificador y el optimizador, además de una política de parada.

Exercises

  1. Ejecute el ejemplo sencillo con max_iterations=1. ¿Sigue siendo útil CRITIC?
  2. Reemplace el verificador externo por uno con ruido (30% de falsos positivos aleatorios). ¿Qué hace el bucle? Esta es la realidad de 2026 en la mayoría de los esquemas de guardrails.
  3. Implemente una variante de "generador-crítico en diferentes modelos": un modelo grande genera y uno pequeño hace la crítica. ¿Supera esto al uso del mismo modelo?
  4. Lea la Sección 3 de CRITIC (arXiv:2305.11738 v4). Nombre las tres categorías de herramientas de verificación y dé un ejemplo de cada una.
  5. Mapee los output_guardrails de OpenAI Agents SDK al rol de verificador en CRITIC. ¿Qué hace bien el SDK y qué hace mal?

Key Terms

Término Lo que la gente dice Lo que realmente significa
Self-Refine "LLM que se corrige a sí mismo" Bucle de generar -> feedback -> refinar en un solo modelo, con historial
CRITIC "Verificación respaldada por herramientas" Reemplazar el feedback con un verificador externo (búsqueda, código, calculadora, pruebas)
Evaluator-Optimizer "Patrón de flujo de trabajo de Anthropic" Dos roles —el evaluador califica, el optimizador revisa— ejecutados en bucle hasta la convergencia
Output guardrail "Comprobación post-hoc" Validador de OpenAI Agents SDK que se ejecuta después de que el agente genera un resultado
Verify step "Fase de crítica" La decisión fundamental: respaldada externamente o autoevaluada
Refine history "Lo que el modelo ya intentó" Resultados y críticas anteriores que se añaden al prompt de refinamiento; omitirlos degrada drásicamente la calidad
Rubber-stamp loop "Fallo de autoconcordancia" La crítica con el mismo estilo de prompt devuelve "se ve bien"; se corrige con prompts estructuralmente diferentes
Stop condition "Prueba de convergencia" El verificador aprueba O no hay feedback Y se alcanza el límite de iteraciones; nunca use una condición única

Further Reading

0 lifetime access. Curriculum based on AI Engineering from Scratch by Rohit Ghumare (MIT, used under attribution).