Patrón Reflection Agent: control de calidad en una pasada

Esencia Del Patrón

Reflection Agent es un patrón donde, después de un borrador, el agente hace una revisión rápida de calidad: detecta problemas obvios (redacción poco clara, contradicciones, afirmaciones demasiado seguras) y los corrige una vez antes de la respuesta final.

Importante: Reflection es una revisión ligera antes de enviar. No es una validación completa por reglas o políticas.

Cuándo usarlo: cuando antes de enviar necesitas una auto-revisión corta y controlada, con una sola revisión.

Reflection no reemplaza el flujo principal de trabajo del agente.

Añade una etapa breve de control:

• verificar rápido si la respuesta es clara, consistente y no omite advertencias importantes
• detectar riesgos obvios
• corregir solo lo necesario
• terminar sin crear un nuevo ciclo infinito

Problema

Imagina que un agente prepara una respuesta para un cliente en una solicitud de alto riesgo.

El borrador es correcto en general, pero tiene riesgos pequeños:

• formulación demasiado categórica sin base
• contradicción entre párrafos
• advertencia faltante
• límite de aplicabilidad poco claro

Sin una pasada de control, este borrador va directo al usuario.

Los errores más peligrosos suelen no ser groseros, sino "casi invisibles" dentro de un texto aparentemente normal.

Consecuencias:

• baja la confianza en la respuesta
• aparece falsa seguridad
• sube el riesgo de decisiones equivocadas

Ese es el problema: incluso un buen borrador sin revisión puede salir con imprecisiones críticas.

Solución

Reflection añade reflection-policy antes del envío final.

Analogía: es como un sastre antes de entregar un traje. Primero revisa el ajuste y luego hace una corrección precisa. Eso mejora el resultado, pero no convierte el proceso en pruebas infinitas.

Principio clave: una revisión corta de calidad y una corrección, sin "hazlo aún mejor" infinito.

El agente puede proponer cambios, pero la política define:

• si hace falta revisión
• qué exactamente está permitido corregir
• cuándo aplicar stop/escalate

Proceso controlado:

1. Borrador: generar la primera versión
2. Revisión: ejecutar una comprobación estructurada
3. Decisión: ok/revisar/escalar
4. Revisión: hacer una corrección patch-only según fix_plan
5. Finalización: devolver el resultado final sin nuevo ciclo

Esto te da:

• eliminación de riesgos obvios antes del envío
• mejora notable de calidad con poco overhead
• control de revisiones dentro de fix_plan
• protección contra self-edit infinito

Funciona bien si:

• se aplica no_new_facts
• los cambios son solo patch-only
• los casos high-risk se escalan en lugar de reescribirse sin fin

El modelo puede "querer" editar una y otra vez, pero la reflection-policy es la que cierra el proceso dentro de límites previsibles.

Cómo Funciona

Regla clave: reflection debe ser acotado.

Eso significa:

• máximo 1 pasada de revisión
• máximo 1 pasada de corrección
• no agregar hechos nuevos
• la revisión debe ser patch-only y solo dentro de fix_plan
• escalar si hay problemas high-risk

En Código Se Ve Así

draft = writer.generate(goal, context)

review = reflector.review_once(
    draft=draft,
    rubric=[
        "no_new_facts",
        "preserve_uncertainty",
        "consistency_check",
    ],
)

if review.high_risk:
    return escalate_to_human(review.reason)

if review.ok:
    return draft

revised = writer.revise_once(
    draft=draft,
    fix_plan=review.fix_plan,
    rules=["no_new_facts", "keep_scope"],
)

# opcional: verificar que la revisión se quedó dentro de `fix_plan`
approved = supervisor.review_output_patch(
    original=draft,
    revised=revised,
    allowed_changes=review.fix_plan,
)

return approved

Reflection no debe ejecutarse "hasta que quede perfecto". Una pasada de revisión, una mejora con revise, y una verificación de que la revisión no salió de fix_plan.

Cómo Se Ve En Ejecución

Goal: preparar respuesta precisa con redacción correcta de SLA

Draft:
"SLA para todos los clientes es 99.99%."

Review:
- problema: afirmación demasiado categórica
- problema: no especifica nivel de plan
- fix: añadir condición y fuente

Revised:
"El SLA depende del nivel de plan. Para enterprise es 99.99% según la política de soporte."

Cuándo Encaja - Y Cuándo No

Encaja

No Encaja

Porque reflection añade otra pasada de generación y aumenta tiempo y costo de respuesta.

Diferencia Frente A Self-Critique

Reflection es una pasada de control rápida y acotada. Self-Critique es una pasada más profunda con reescritura.

Cuándo Usar Reflection Entre Otros Patrones

Usa Reflection cuando necesitas verificar rápido la respuesta antes de enviarla: que sea clara, lógica y sin errores obvios.

Prueba corta:

• si necesitas "revisar breve y corregir antes del final" -> Reflection
• si necesitas "criticar a fondo por checklist y reescribir" -> Self-Critique Agent

Cómo Combinar Con Otros Patrones

• Reflection + RAG: Reflection verifica que las conclusiones realmente coincidan con las fuentes recuperadas.
• Reflection + Supervisor: conclusiones high-risk no se corrigen automáticamente, se envían a aprobación humana.
• Reflection + ReAct: después de una serie de pasos ReAct, el agente hace una revisión final antes de responder.

Resumen

Ventajas Y Desventajas

FAQ

Q: ¿Reflection puede reemplazar fact-checking y tests?
A: No. Es una capa adicional de calidad. Fact-checking, validación y controles de policy siguen siendo necesarios aparte.

Q: ¿Por qué limitar cantidad de pasadas?
A: Si no, reflection se convierte en segundo ciclo: suben latencia, costo y riesgo de nuevos errores.

Q: ¿Qué hacer si reflection encuentra un problema high-risk?
A: No continuar automáticamente. Parar el proceso o escalar a revisión humana / policy de Supervisor.

Qué Sigue

Reflection añade control de calidad acotado antes de la respuesta final.

¿Qué hacer cuando necesitas crítica más estricta y un proceso de revisión con reglas estructuradas de cambio?