Dominar el patrón de reflexión (reflection): pedir a un modelo de lenguaje que revise su propia salida y la mejore. Al terminar, el lector sabrá:
Ruta del módulo
Qué es la reflexión → por qué supera a la generación directa → reflexión sobre gráficos → evaluar su impacto → retroalimentación externa → autoevaluación final.
Cuando una persona escribe deprisa, el primer borrador rara vez es el mejor. Al releerlo detecta cosas: «el mes que viene» no deja claro qué días está libre, hay una errata y se le olvidó firmar. Con esa crítica escribe una segunda versión más concreta: «¿estás libre para cenar entre el 5 y el 7?».
Un LLM (large language model, modelo de lenguaje grande) puede hacer lo mismo. Se le pide un primer borrador, la versión 1, y después se le pasa ese borrador, al mismo modelo pero con otro prompt, para que lo revise y escriba una versión 2 mejorada.
En este flujo, el paso de reflexión está fijado en el código (hard-coded): siempre se hace una primera llamada para el borrador y una segunda para revisarlo. Es uno de los patrones agénticos más fáciles de implementar:
El mismo esquema mejora otras salidas. Para programar, se pide al LLM el código de una tarea, se obtiene la versión 1 y se pide al mismo modelo, o a otro, que busque errores y escriba una versión corregida.
Cada modelo tiene puntos fuertes distintos, así que conviene probar combinaciones. Una que funciona bien: generar el primer borrador con un modelo rápido, por generación directa, y revisarlo con un modelo de razonamiento (también llamado thinking model, «modelo que piensa»), que suele ser bueno encontrando errores.
Hasta aquí, el modelo reflexiona solo con la información que ya tenía. La reflexión se vuelve mucho más potente cuando entra información nueva desde fuera del LLM (retroalimentación externa, external feedback). En el caso del código, la fuente más directa es ejecutarlo: la salida y los mensajes de error dicen exactamente qué falla.
Una advertencia: la reflexión no es magia. No hace que el modelo acierte siempre; a menudo aporta una mejora modesta. Pero la decisión de diseño es clara: siempre que exista la oportunidad de aportar información externa al paso de reflexión, hay que aprovecharla.
1. En el flujo básico de reflexión, ¿qué recibe la segunda llamada al LLM?
La reflexión consiste en pasar el borrador al modelo (el mismo u otro) con un prompt distinto que le pide criticarlo y mejorarlo.
2. ¿Por qué tiene sentido usar un modelo de razonamiento en el paso de reflexión sobre código?
No es obligatorio, pero combinar un generador rápido con un revisor que razona bien es una configuración que a menudo funciona mejor.
3. ¿Qué hace más potente a la reflexión?
Sin información nueva, el modelo reflexiona sobre lo mismo que ya sabía. Una señal externa le dice qué falla realmente.
Para cada salida, propone una fuente de retroalimentación externa que pueda alimentar el paso de reflexión: (a) una función Python que debe ordenar facturas por fecha; (b) un objeto JSON (notación de objetos de JavaScript) que debe cumplir un esquema; (c) un texto que debe ocupar como máximo 150 palabras; (d) una consulta SQL (lenguaje de consulta estructurado).
(a) Ejecutar pruebas unitarias con casos conocidos y pasar los fallos al modelo. (b) Un validador de esquema: los errores de validación indican qué campo falta o tiene el tipo equivocado. (c) Un contador de palabras. (d) Ejecutar la consulta en una base de datos de prueba: el mensaje de error, o un resultado vacío, es la crítica.
Un LLM redacta: «Estimado cliente: su pedido llegará pronto. Disculpe las molestias». Los datos del contexto son: pedido #8847, entrega prevista el 14 de marzo, retraso causado por el transportista. Escribe los criterios que pondrías en el prompt de reflexión y una versión 2 plausible.
Criterios: (1) ¿incluye el número de pedido?; (2) ¿da una fecha concreta en lugar de «pronto»?; (3) ¿explica la causa con datos del contexto?; (4) ¿todos los datos coinciden con el contexto? Versión 2: «Estimado cliente: su pedido #8847 llegará el 14 de marzo. El retraso se debe a una incidencia del transportista. Lamentamos las molestias».
En la generación directa se da una instrucción al LLM y este produce la respuesta de una sola vez: «escribe un ensayo sobre agujeros negros», «escribe una función Python que calcule el interés compuesto anual». A estos prompts se les llama zero-shot (de cero ejemplos), por contraste con técnicas que incluyen ejemplos de la salida deseada:
Lo importante para este módulo es la idea común: tanto con cero como con varios ejemplos, el modelo genera la respuesta de un tirón, sin revisarla.
Varios estudios muestran que la reflexión mejora a la generación directa en tareas muy variadas. El trabajo de Madaan y colaboradores (2023), Self-Refine: refinamiento iterativo con autorretroalimentación, comparó distintos modelos (entre ellos GPT-3.5 y GPT-4) con y sin reflexión en tareas como:
| Tarea | Qué se pide al modelo |
|---|---|
| Inversión del sentimiento | Reescribir una reseña con el sentimiento opuesto |
| Respuesta en diálogo | Contestar de forma útil en una conversación |
| Optimización de código | Hacer más eficiente un programa |
| Legibilidad de código | Hacer más claro un programa |
| Razonamiento matemático | Resolver problemas de matemáticas |
| Generación de acrónimos | Proponer acrónimos adecuados |
| Generación con restricciones | Escribir un texto que incluya una lista de palabras |
En casi todas las combinaciones de modelo y tarea, la versión con reflexión quedó claramente por encima de la versión directa. Aun así, la mejora depende de cada aplicación: hay que medirla, como se verá en la sección de evaluación.
| Ejemplo | Problema típico | Prompt de reflexión |
|---|---|---|
| Generar una tabla HTML (lenguaje de marcado de hipertexto) | Formato incorrecto, por ejemplo una > que falta | Validar el código HTML |
| Instrucciones para preparar una taza de té perfecta | Pasos que faltan | Comprobar la coherencia y la completitud de las instrucciones |
| Proponer nombres de dominio | Significados no deseados o difíciles de pronunciar | ¿Tiene el nombre connotaciones negativas? ¿Es difícil de pronunciar? |
Un matiz: con HTML básico, la reflexión aporta poco porque los modelos ya lo hacen bien. Rinde más con salidas estructuradas complejas, como un JSON con mucho anidamiento, donde es más probable que haya errores que detectar.
Dos reglas guían un buen prompt de reflexión: indicar claramente que se revise el borrador y especificar los criterios con los que debe criticarse. Los criterios concretos orientan al modelo hacia lo que de verdad importa.
El segundo prompt tiene sentido cuando el modelo recibió en su contexto los datos, fechas y compromisos que el correo debe respetar: así puede contrastarlos. Una forma eficaz de aprender a escribir buenos prompts es leer prompts escritos por otros; por ejemplo, los de proyectos de código abierto bien hechos.
Error común
Escribir un prompt de reflexión sin criterios, del tipo «revisa y mejora». El modelo reescribe a su gusto: cambia lo que estaba bien, añade relleno y, a veces, introduce errores nuevos. Sin criterios concretos tampoco hay forma de comprobar si la versión 2 es realmente mejor.
1. Un prompt incluye dos pares de entrada y salida de ejemplo antes de la entrada real. ¿Cómo se llama?
El nombre indica el número de ejemplos: cero, uno o varios. Sigue siendo generación directa, porque no hay revisión posterior.
2. ¿En cuál de estas salidas es más probable que la reflexión aporte una mejora apreciable?
En formatos sencillos el modelo ya acierta; en estructuras complejas hay más errores que una revisión puede detectar.
3. ¿Qué caracteriza a un buen prompt de reflexión?
Criterios como «¿es fácil de pronunciar?» o «verifica fechas y compromisos» guían la crítica hacia lo que importa.
Un prompt zero-shot dice: «Clasifica la prioridad de esta incidencia como ALTA, MEDIA o BAJA: {incidencia}». El modelo clasifica como ALTA casi todo. Reescríbelo como few-shot.
Se añaden ejemplos que muestren la frontera entre categorías:
«Clasifica la prioridad como ALTA, MEDIA o BAJA.
Incidencia: el servidor de correo está caído para toda la oficina → ALTA
Incidencia: una impresora de planta imprime con rayas → MEDIA
Incidencia: petición de cambiar el fondo de pantalla corporativo → BAJA
Incidencia: {incidencia} →»
Incluir al menos un ejemplo de MEDIA y otro de BAJA corrige la tendencia a sobreclasificar.
Un LLM genera instrucciones paso a paso para preparar una taza de té y a veces omite pasos. Escribe el prompt de reflexión.
«Revisa las instrucciones que escribiste: {instrucciones}. 1. Comprueba que estén en un orden lógico y que cada paso dependa solo de pasos anteriores. 2. Verifica que no falte ningún paso necesario (calentar el agua, la temperatura y el tiempo de infusión según el tipo de té, retirar las hojas). 3. Si encuentras problemas, escribe la versión corregida completa; si no, devuélvelas sin cambios.» Las claves son nombrar la revisión, dar criterios (coherencia y completitud) y definir el formato de salida.
La reflexión no se limita al texto. Se parte de los datos de una máquina de café: cada fila registra la fecha, el precio y la bebida vendida.
| date | price | coffee_name |
|---|---|---|
| 2024-01-12 | 3.87 | Latte |
| 2024-01-28 | 3.87 | Hot Chocolate |
| 2024-03-01 | 2.89 | Cappuccino |
| … | … | … |
| 2025-03-23 | 3.57 | Latte |
Se quiere que un agente cree un gráfico que compare las ventas del primer trimestre (T1) de 2024 y 2025 a partir de un archivo CSV (valores separados por comas).
El LLM escribe código Python (por ejemplo, con pandas y matplotlib) y, al ejecutarlo, se obtiene plot.png. En una ejecución real, la primera versión resultó ser un gráfico de barras apiladas, poco claro para comparar. El paso clave es entregar el código v1 y la imagen a un LLM multimodal, un modelo que también acepta imágenes, y pedirle que examine el gráfico, lo critique, proponga una visualización mejor y actualice el código. Los modelos multimodales razonan visualmente: «ven» el gráfico.
La versión 2 separa las ventas de 2024 y 2025 en barras normales agrupadas, mucho más fáciles de comparar.
Como cada LLM tiene puntos fuertes distintos, es habitual usar uno para la generación inicial y otro para la reflexión. El prompt de reflexión asigna un rol (analista de datos experto), aporta el contexto (código v1, imagen y, si se quiere, el historial de la conversación) y fija criterios concretos: legibilidad, claridad y completitud.
A veces un modelo de razonamiento funciona mejor en la reflexión que uno sin razonamiento. Qué modelo usar en cada paso es una configuración más que se puede probar en distintas combinaciones.
¿Mejora siempre la reflexión? Los estudios muestran que mejora un poco en algunas aplicaciones, mucho en otras y casi nada en algunas. Por eso hace falta medir su impacto en cada caso concreto.
1. ¿Qué tipo de modelo se necesita en el paso de reflexión del flujo de gráficos?
Para criticar el gráfico hay que verlo: el modelo multimodal recibe plot.png y razona visualmente sobre él.
2. ¿Qué entradas recibe el paso de reflexión en este flujo?
Con el código y su resultado visual, el modelo puede diagnosticar el problema y reescribir el código.
3. ¿Por qué el prompt de reflexión enumera criterios como legibilidad, claridad y completitud?
Igual que en los prompts de texto, los criterios explícitos dirigen la crítica hacia lo que importa.
Un agente genera gráficos de líneas con la temperatura horaria de una estación meteorológica durante una semana. Escribe el paso 1 del prompt de reflexión con criterios específicos.
«Paso 1: critica el gráfico adjunto comprobando: (1) que el título indique la estación y el periodo; (2) que el eje X muestre fechas legibles, sin etiquetas solapadas; (3) que el eje Y indique la unidad (°C) y tenga un rango ajustado a los datos; (4) que el tipo de gráfico (líneas) sea adecuado para una serie temporal; (5) que los huecos de datos se vean como huecos y no como rectas que los unen.» Criterios así son verificables mirando la imagen.
Tienes tres modelos: A (rápido, solo texto), B (multimodal) y C (multimodal y de razonamiento, más lento). ¿Qué combinaciones de generación y reflexión probarías y cómo elegirías?
La reflexión necesita ver la imagen, así que solo B o C pueden reflexionar. Combinaciones razonables: A→B, A→C, B→B y B→C. Para elegir, se prepara un conjunto de 10–15 peticiones de gráficos, se ejecuta cada configuración y se puntúan los gráficos con una rúbrica (sección siguiente), teniendo en cuenta también la latencia y el coste. Se escoge la configuración con mejor puntuación que encaje en el presupuesto de tiempo.
La reflexión suele mejorar el rendimiento, pero añade una llamada más y ralentiza el sistema. Antes de mantenerla conviene comprobar cuánto mejora realmente.
Ejemplo: una tienda responde preguntas como «¿qué color de producto tiene más ventas?». Un LLM genera una consulta SQL; otro LLM, o el mismo, reflexiona sobre ella y la mejora; se ejecuta la consulta y un LLM redacta la respuesta. ¿Mejora la reflexión la respuesta final?
Para medirlo se reúnen entre 10 y 15 preguntas con su respuesta correcta conocida (ground truth): «¿cuántos artículos se vendieron en mayo de 2025?» (1201), «¿cuál es el artículo más caro?» (Airflow sneaker), «¿cuántos estilos hay?» (14). Se ejecuta el flujo sin reflexión, usando la consulta v1, y con reflexión, usando la v2, y se cuenta el porcentaje de aciertos.
Con 87 % frente a 95 %, la reflexión mejora de forma apreciable la calidad de las consultas.
Con la evaluación en marcha, se pueden probar ideas rápidamente: añadir al prompt de reflexión «haz que la consulta sea más rápida» o «más clara», reescribir el prompt de generación… Se vuelve a ejecutar el conjunto y se compara el porcentaje de aciertos. Si se prueban muchos prompts, construir evaluaciones es imprescindible: es la forma sistemática de elegir entre ellos.
¿Cómo se sabe si el gráfico de barras agrupadas es mejor que el apilado? Es un criterio subjetivo. Una primera idea es dar ambas imágenes a un LLM multimodal y preguntarle cuál es mejor. Funciona peor de lo que parece:
En lugar de comparar parejas, se evalúa una sola imagen con una rúbrica: una lista de criterios claros (¿tiene título claro?, ¿están las etiquetas de los ejes?, ¿el tipo de gráfico es adecuado?, ¿el rango numérico de los ejes es apropiado?…). Y en vez de una nota del 1 al 5, en la que los modelos están mal calibrados, cada criterio recibe un 0 o un 1; la suma da la puntuación.
Con 10 criterios binarios, la puntuación va de 0 a 10. Se reúnen 10–15 peticiones de gráficos, se generan con y sin reflexión y se puntúan:
| Petición | Sin reflexión | Con reflexión |
|---|---|---|
| Petición 1 | 4 | 6 |
| Petición 2 | 5 | 8 |
| … | … | … |
| Petición 10 | 5 | 7 |
La media de las filas mostradas pasa de unos 4,7 a 7 puntos. Igual que antes, la evaluación permite volver a medir cada vez que cambia un prompt.
| Tipo de criterio | Herramienta de evaluación | Esfuerzo |
|---|---|---|
| Objetivo (hay una respuesta correcta) | Código que compara con un conjunto de respuestas correctas | Más fácil de gestionar |
| Subjetivo (calidad, claridad…) | LLM como juez, mejor con rúbrica binaria | Requiere ajustar la rúbrica para que el juez esté bien calibrado |
Error común
Dar por buena la comparación de un LLM juez presentando las dos opciones siempre en el mismo orden (por ejemplo, la versión con reflexión siempre en segundo lugar). El sesgo de posición puede fabricar una «mejora» o esconderla. Si se compara por pares, hay que alternar el orden; mejor aún, puntuar cada salida por separado con una rúbrica.
1. ¿Qué se necesita para evaluar objetivamente si la reflexión mejora un flujo de consultas SQL?
Con las respuestas correctas conocidas, basta código para contar aciertos en cada variante (87 % frente a 95 % en el ejemplo).
2. ¿Qué es el sesgo de posición de un LLM juez?
Al comparar parejas, muchos modelos favorecen la primera opción independientemente de su calidad.
3. ¿Por qué una rúbrica de criterios binarios da resultados más consistentes que una nota del 1 al 5?
Sumar decisiones simples (0 o 1) reduce la arbitrariedad de elegir un número en una escala.
Con un conjunto de 20 preguntas, el flujo acierta 17 sin reflexión y 19 con reflexión. La reflexión añade 2 segundos a cada respuesta. Calcula la mejora y razona en qué casos la mantendrías.
Diez puntos de mejora es mucho si una respuesta errónea tiene coste (decisiones de negocio, datos para clientes): se mantiene. Si la aplicación es interactiva y la latencia es crítica, se puede probar a reflexionar solo cuando la consulta v1 falla o devuelve un resultado vacío. Con 20 preguntas, conviene confirmar el resultado ampliando el conjunto.
Si aun así necesitas comparar dos gráficos por pares, ¿cómo reducirías el sesgo de posición? Esboza el código.
Se pregunta dos veces intercambiando el orden; solo se acepta un ganador si gana en ambos órdenes:
La proporción de resultados inconsistentes es, además, una medida útil de lo poco fiable que es el juez en esa tarea.
Al ajustar el prompt de un sistema de generación directa, el rendimiento mejora al principio y después se estanca: por mucho que se retoque el prompt, cuesta avanzar. Añadir reflexión antes da un salto, a veces pequeño y a veces grande, a cambio de algo más de complejidad. Y si además se aporta información externa, de modo que el modelo no reflexione solo sobre lo que ya sabía, el techo sube todavía más.
Regla práctica: si el esfuerzo de ajustar prompts da cada vez menos, conviene plantearse añadir reflexión o, mejor aún, alguna fuente de retroalimentación externa.
Además de ejecutar código, muchas herramientas de software producen hechos objetivos sobre la salida que se pueden pasar al paso de reflexión:
El patrón común: un fragmento de código encuentra hechos adicionales sobre la salida inicial (un nombre de competidor, un dato verificado, un recuento exacto) y esos hechos se convierten en la crítica del paso de reflexión.
1. Un equipo lleva semanas ajustando un prompt y cada cambio aporta menos. ¿Qué sugiere la curva de retorno?
El ajuste de prompts de generación directa tiende a estancarse; la reflexión, y más aún la información externa, elevan el techo.
2. ¿Qué herramienta aporta mejor retroalimentación cuando el modelo no respeta un límite de 300 palabras?
Los LLM cuentan mal las palabras; un fragmento de código da el dato exacto que guía la corrección.
3. En el ejemplo del Taj Mahal, ¿qué aporta la búsqueda web a la reflexión?
La búsqueda introduce información nueva y fiable que el modelo no tenía para corregir una afirmación imprecisa.
Propón una herramienta de software que genere información externa para cada caso: (a) un agente de investigación cita direcciones web (URL, localizador uniforme de recursos) que a veces no existen; (b) un traductor técnico no usa los términos del glosario de la empresa; (c) un generador de SQL produce consultas correctas pero muy lentas.
(a) Comprobar cada URL con una petición HTTP (protocolo de transferencia de hipertexto) y pasar al modelo las que devuelven error. (b) Un verificador de glosario: código que busca los términos de origen y comprueba si la traducción usa el término aprobado; las discrepancias son la crítica. (c) Medir el tiempo de ejecución o pedir el plan de ejecución de la base de datos; si supera un umbral, se le pasa el plan al modelo para que optimice la consulta.
Explica qué hace el bucle de reflexión con comprobaciones por código de la sección «Herramientas de verificación» (detector de competidores más contador de palabras) y por qué limita el número de intentos.
Genera un texto y, en cada vuelta, ejecuta dos comprobaciones por código: una expresión regular que busca competidores y un recuento de palabras. Si no hay problemas, termina; si los hay, se los pasa al LLM como crítica concreta y pide una versión corregida. El límite de 3 intentos evita bucles infinitos y costes descontrolados si el modelo no consigue cumplir las restricciones; en ese caso, la salida se puede derivar a revisión humana.
| Término | Significado |
|---|---|
| Reflexión | Patrón en el que un modelo revisa una salida (suya o de otro) con un prompt distinto y produce una versión mejorada. |
| Retroalimentación externa | Información nueva, obtenida fuera del LLM (ejecución de código, búsqueda web, contadores…), que alimenta la reflexión. |
| Zero-shot / one-shot / few-shot | Prompts con cero, uno o varios ejemplos de entrada y salida. |
| Modelo de razonamiento | LLM que dedica cómputo a «pensar» antes de responder; suele ser bueno detectando errores. |
| LLM multimodal | Modelo que acepta también imágenes (u otros formatos), por ejemplo para criticar un gráfico. |
| Respuesta correcta conocida | Valor de referencia (ground truth) con el que se compara la salida en una eval objetiva. |
| LLM como juez | Uso de un modelo para evaluar salidas con criterios subjetivos. |
| Sesgo de posición | Tendencia de un juez a preferir la opción que se le presenta primero. |
| Rúbrica binaria | Lista de criterios de sí/no cuya suma da la puntuación. |
1. ¿Qué diferencia un flujo de reflexión de una generación directa con few-shot?
Los ejemplos mejoran la generación, pero no añaden revisión. La reflexión es un segundo paso sobre la salida ya generada.
2. Un generador de código falla a menudo por errores de sintaxis. ¿Qué mejora es más eficaz?
El mensaje de error real indica con precisión qué falla; es retroalimentación externa.
3. ¿Cuál de estos prompts de reflexión está mejor planteado?
Indica que se revise el borrador, da criterios concretos y define qué entregar.
4. En el flujo de gráficos, ¿por qué se ejecuta el código v1 antes de reflexionar?
La imagen generada es información nueva: el modelo ve el resultado real en lugar de imaginarlo a partir del código.
5. Quieres saber si un cambio en el prompt de reflexión mejora las consultas SQL. ¿Qué haces?
La evaluación ya construida permite comparar variantes de prompt de forma sistemática.
6. Un LLM juez prefiere el gráfico A cuando va primero y el B cuando va primero el B. ¿Qué indica?
Si el veredicto depende del orden, refleja la posición y no la calidad. Mejor puntuar cada gráfico con una rúbrica.
7. Una rúbrica tiene 8 criterios binarios. Un gráfico cumple 6. ¿Cuál es su puntuación?
Cada criterio vale 0 o 1; la puntuación es la suma de criterios cumplidos sobre el total de criterios.
8. ¿En qué tipo de evaluación es más laborioso conseguir resultados fiables?
Con criterios objetivos basta comparar con la respuesta correcta; el juez requiere calibración mediante una rúbrica bien pensada.
9. ¿Qué tienen en común el detector de competidores, la búsqueda web y el contador de palabras?
Las herramientas no reescriben el texto: aportan información nueva y objetiva que el LLM usa para mejorarlo.
10. ¿Qué afirmación sobre la reflexión es correcta?
No es magia: su efecto varía según la tarea y cuesta un paso extra. Por eso se evalúa en cada caso.