Reflexión (Reflection)
La reflexión hace que un modelo critique su propia salida y luego la revise, usando la crítica como feedback. Es una forma ligera, de un solo modelo, de atrapar errores y mejorar la calidad en tareas de razonamiento, código y escritura, a costa de llamadas extra.
Definición
La reflexión es un patrón en el que un modelo revisa y critica su propia salida frente a criterios explícitos y luego la corrige, cambiando inferencia adicional por mayor calidad.
Problema
Los modelos a menudo producen una primera respuesta defectuosa que podrían mejorar si se les pide revisar su propio trabajo, pero una sola pasada no les da la oportunidad.
Cuándo usarlo
Usa la reflexión cuando un paso de autorrevisión mejore la salida de forma medible y quieras una alternativa más simple al bucle evaluador de dos modelos —común en tareas de razonamiento y código.
Solución
Tras generar una respuesta, pide al mismo modelo que la critique frente al objetivo (y cualquier feedback de herramientas como resultados de tests o errores), y luego que produzca una respuesta revisada informada por esa crítica. Repite un número acotado de iteraciones.
La reflexión funciona mejor anclada en señales reales —errores de ejecución, salida de tests, hechos recuperados— que en la pura autoevaluación, que puede ser demasiado confiada.
Componentes
Beneficios
- Mejora la calidad con un solo modelo, sin segundo sistema.
- Eficaz cuando se ancla en feedback de herramientas o tests.
- Simple de añadir a una llamada existente.
Riesgos
- La autocrítica puede ser demasiado confiada o no ver sus errores.
- Las llamadas extra añaden latencia y coste.
- Sin anclaje, las ganancias son limitadas.
Cuándo no usarlo
- Cuando tienes una comprobación externa objetiva: usa evaluador-optimizador.
- Cuando una sola pasada ya alcanza el nivel.
- Cuando los presupuestos de latencia son muy ajustados.
Tecnologías
Ejemplos
- Un agente de código que lee fallos de tests y corrige su propio parche.
- Una tarea de razonamiento donde el modelo revisa sus pasos antes de responder.
- Un borrador que el modelo revisa en busca de lagunas antes de finalizar.
Evidencia de producción
- Contexto
- Tareas donde la calidad importa más que la latencia o el coste —redacción, generación de código, análisis— y donde los errores son detectables al revisar.
- Escenario
- Tras producir una primera respuesta, el modelo (o un crítico aparte) la evalúa frente a criterios concretos y produce una versión revisada; el bucle se limita a una o dos pasadas.
- Tecnología
- Una cadena de prompts criticar-luego-revisar, idealmente respaldada por señales externas (tests, herramientas, un evaluador aparte) para el trabajo de alto riesgo.
- Carga
- Cada pasada de reflexión al menos duplica las llamadas, así que se aplica de forma selectiva a las salidas que justifican el sobrecoste.
- Resultados
- Patrón observado: la reflexión mejora la calidad donde el modelo puede de verdad detectar sus propios errores, pero puede sobrerrevisar respuestas correctas y al menos duplica el coste. Mide la mejora frente a un conjunto de evaluación antes de confiar en ella, y prefiere señales externas cuando hay mucho en juego.
KPIs
- Mejora de calidad por reflexión
- Mejora medida en la calidad con el paso de reflexión frente a sin él; si no es medible, el paso no justifica su coste.
- Tasa de autocorrección
- Proporción de errores reales que el modelo detecta y corrige al revisar, distinta de ediciones cosméticas.
- Latencia y coste añadidos
- La reflexión al menos duplica las llamadas; vigila el sobrecoste frente a la calidad que aporta.
- Tasa de sobrerrevisión
- Con qué frecuencia la reflexión degrada una respuesta ya buena al cuestionarla en exceso.
Modos de fallo observados
- Puntos ciegos de autoevaluación: un modelo suele no ver sus propios errores, así que la reflexión los pasa por alto.
- Sobrerrevisión: el modelo 'corrige' una respuesta correcta y la empeora.
- Coste y latencia se duplican (o más) para una ganancia de calidad marginal o nula.
- Falsa confianza: el modelo afirma que la salida ya es correcta cuando no lo es.
Lecciones aprendidas
- Mide la mejora; la reflexión vale la pena solo donde mejora la calidad de forma demostrable.
- Prefiere señales externas (tests, herramientas, un evaluador aparte) sobre la pura autocrítica cuando hay mucho en juego.
- Limita la reflexión a una o dos pasadas: los rendimientos caen rápido y el coste se acumula.
- Da al paso de reflexión criterios concretos, no un vago 'mejora esto'.
FAQs
- ¿Reflexión o evaluador-optimizador?
- La reflexión usa un modelo para autocriticarse (más simple); el evaluador-optimizador usa un evaluador separado (más afilado, menos sesgado). Elige según cuán fiable sea la autoevaluación en tu tarea.
- ¿La reflexión siempre ayuda?
- Ayuda más cuando se ancla en feedback real como resultados de tests o errores. La pura autoevaluación puede ser demasiado confiada y aportar poco.
- ¿Cuántas rondas de reflexión?
- Mantenlo acotado, a menudo una o dos. Los rendimientos decrecientes y el coste creciente hacen que los bucles largos rara vez compensen.