Por PromptRentable 
Durante meses trabajé así: escribía un prompt largo, lo mandaba, leía el resultado, encontraba un error, añadía más instrucciones al prompt, lo volvía a mandar. Una y otra vez. Cada intento era más largo que el anterior y los resultados no mejoraban de forma proporcional al esfuerzo.
El problema no era la longitud del prompt. Era que estaba intentando que un único modelo hiciera dos cosas a la vez: crear y evaluar. Y eso no funciona bien, del mismo modo que no funciona pedirle a un escritor que corrija su propio texto en el mismo momento en que lo escribe.
La solución fue separar esas dos funciones en prompts distintos. Lo que llevo usando desde entonces es lo que se conoce como un bucle de retroalimentación: un sistema donde un prompt crea, otro evalúa, y si hay errores, un tercero corrige. Es más trabajo de configuración inicial, pero una vez montado funciona solo y los resultados son notablemente más fiables.
La idea básica: un creador y un evaluador
El principio es sencillo. En lugar de pedirle a la IA que lo haga todo en un solo paso, divides el trabajo en roles separados.
El primer prompt, el creador, tiene una tarea concreta y acotada. No «escribe un análisis completo de esto», sino algo medible: «escribe una función en Python que procese este JSON y calcule la media de ventas ignorando valores nulos, usando solo la librería estándar, sin comentarios en el código».
El segundo prompt, el evaluador, no crea nada. Solo revisa. Su único trabajo es comparar el output del creador contra una lista de criterios específicos y responder con una etiqueta simple: [APROBADO] si todo está bien, o [ERROR] seguido de una lista concreta de fallos si algo no cumple.
La clave de que esto funcione está en que el evaluador sea implacable. Si le pides que sea «constructivo» o «amable», empezará a aprobar cosas que no debería. Tiene que buscar fallos activamente, no confirmar que todo parece bien.
Cómo encadenar los tres pasos
Una vez tienes el creador y el evaluador, la lógica del sistema es sencilla:
Lanzas el prompt del creador y guardas el resultado. Luego lanzas el prompt del evaluador pasándole ese resultado como contexto. Si responde [APROBADO], el trabajo está listo. Si responde [ERROR], entra en juego el tercer prompt: el refinador.
El refinador es el más interesante de los tres. Recibe tres cosas: el prompt original, el resultado con errores, y el reporte del evaluador. Su instrucción es algo así: «Analiza por qué el resultado anterior no cumple los criterios del reporte. Reescribe corrigiendo específicamente los puntos señalados, manteniendo lo que ya funcionaba.»
Este proceso de autorreflexión, donde el modelo examina su propio error antes de corregirlo, produce mejoras mucho más precisas que simplemente volver a generar desde cero.
Un límite que no puedes olvidar
Hay un problema práctico que aparece enseguida si no lo previenes: los bucles infinitos. Si el evaluador es demasiado estricto o la tarea es genuinamente difícil, el sistema puede entrar en un ciclo donde el creador siempre falla y el evaluador siempre rechaza, sin llegar nunca a un resultado.
La solución es poner un límite de reintentos, normalmente tres. Si al tercer intento el evaluador sigue devolviendo [ERROR], el sistema para y lo escala a revisión humana. Esto es importante no solo por coste, sino porque hay tareas donde la IA simplemente no puede llegar sola al resultado que necesitas, y es mejor saberlo rápido que gastar tokens indefinidamente.
Cómo no gastar una fortuna en el proceso
El punto débil de este sistema es el coste. Si cada paso usa un modelo potente, el gasto en tokens se multiplica rápido.
La solución que uso es lo que llamo escalada de modelos. El creador usa un modelo barato y rápido, como GPT-4o-mini o cualquier modelo ligero. El evaluador, en cambio, usa el modelo más potente que tengas disponible, pero como solo escribe [APROBADO] o una lista corta de errores, el consumo de tokens es mínimo. Obtienes criterio de calidad profesional a coste de evaluación básica.
El refinador puede volver a usar el modelo barato, porque ya tiene instrucciones muy concretas sobre qué corregir y no necesita tanto «criterio» propio.
Dónde esto marca una diferencia real
El sistema funciona especialmente bien en tres situaciones que me encuentro constantemente.
La primera es generación de código. El evaluador puede comprobar que el código cumple restricciones específicas, que no usa librerías no permitidas, que el formato de salida es el correcto. Mucho más fiable que confiar en que el modelo lo haga bien a la primera.
La segunda es extracción de datos de documentos. Cuando pides a una IA que saque cifras o datos de un texto largo, las alucinaciones son frecuentes: el modelo inventa números que suenan plausibles pero no están en el documento. Un evaluador que coteja el output contra el texto original detecta esto casi siempre.
La tercera es generación de contenido largo con consistencia interna, como guiones o informes. El evaluador comprueba que los nombres de personajes no cambien, que los datos sean coherentes entre secciones, que el tono sea uniforme.
La versión avanzada: dos evaluadores en lugar de uno
Si quieres llevar esto un paso más allá, puedes separar la evaluación en dos agentes con criterios distintos. Uno revisa la forma: estructura, formato, cumplimiento técnico. Otro revisa el fondo: veracidad de los datos, coherencia lógica, ausencia de contradicciones.
Solo cuando los dos dan el visto bueno, el resultado sale. Es más lento y más caro, pero para contenido donde los errores tienen consecuencias reales, como informes técnicos o análisis que alguien va a usar para tomar decisiones, la diferencia en fiabilidad justifica el coste.
Lo que cambia cuando empiezas a pensar así
El salto mental más importante de todo esto no es técnico. Es entender que un prompt no es una solución, es una parte de un sistema. Mientras sigas intentando que un solo prompt perfecto resuelva todo, estarás limitado por lo que un modelo puede hacer en un solo paso.
Cuando empiezas a diseñar flujos donde varios prompts trabajan juntos, con roles distintos y criterios claros, la fiabilidad sube a un nivel diferente. No porque la IA sea más inteligente, sino porque el sistema está diseñado para detectar y corregir sus propios fallos antes de que lleguen al resultado final.
Eso es lo que separa usar IA de forma casual de usarla de forma profesional.