Iteración y depuración de prompts

La ingeniería eficaz de prompts no consiste en encontrar una fórmula mágica: es un proceso empírico e iterativo, más parecido a la depuración que a la redacción. Escriba un prompt, ejecútelo con entradas de prueba, observe dónde falla, formule una hipótesis sobre la causa del fallo y modifique el prompt para corregirlo. La intuición por sí sola no es fiable: necesita datos.

Muchos desarrolladores cometen el error de probar su prompt con uno o dos ejemplos creados manualmente, observar buenos resultados y ponerlo en producción, solo para descubrir que el prompt falla en el 30 % de las entradas reales. Un flujo de evaluación sistemático evita esto al exponer el prompt a ejemplos diversos y representativos antes de ponerlo en marcha.

Antes de escribir el prompt, cree un conjunto de pruebas de referencia: una colección de entre 20 y 100 ejemplos de entrada representativos, emparejados con la salida esperada o con los criterios de aprobación. Este conjunto se convierte en la referencia objetiva para evaluar cualquier cambio en el prompt.

Los buenos conjuntos de pruebas incluyen: entradas típicas, casos límite (cadenas vacías, entradas muy largas y casos ambiguos), entradas adversarias diseñadas para romper el prompt y entradas de diferentes segmentos de su población de usuarios. Cuanto más diverso sea el conjunto de pruebas, más confianza podrá tener en que un cambio en el prompt supone una mejora real, en lugar de un sobreajuste a los pocos ejemplos que tenía en mente.

Escribir un script sencillo de evaluación lleva una hora y ahorra días de depuración de problemas en producción. El script ejecuta el prompt con cada caso de prueba, compara la salida con el resultado esperado e informa de la tasa de aprobación. Después puede iterar sobre el prompt y comprobar inmediatamente si los cambios han mejorado la puntuación general.

Cuando el prompt falla en los casos de prueba, agrupe los fallos por tipo para identificar patrones. Algunos tipos de fallo habituales son:

• Fallos de formato: el modelo produce la respuesta correcta, pero con el formato equivocado
• Fallos por ambigüedad: el modelo interpreta la tarea de forma distinta a la prevista
• Fallos en casos límite: el modelo funciona con entradas típicas, pero falla con entradas inusuales
• Fallos por alucinación: el modelo produce contenido factual incorrecto con seguridad
• Ignorar instrucciones: el modelo sigue parcialmente las instrucciones, pero omite restricciones específicas

Cada tipo de fallo requiere una solución diferente. Los fallos de formato requieren instrucciones de salida más explícitas; los fallos por ambigüedad requieren una definición más clara de la tarea o ejemplos.

El OpenAI Playground (platform.openai.com/playground) es la herramienta más rápida para iterar sobre prompts sin escribir código. Permite cambiar de modelo, ajustar parámetros con controles deslizantes, guardar versiones de prompts y comparar resultados uno al lado del otro.

Utilice Playground durante la fase de exploración del desarrollo de prompts: pruebe diferentes formulaciones, analice casos límite de forma interactiva y desarrolle su intuición sobre lo que funciona. Cuando haya convergido en un prompt prometedor, páselo al código con un sistema de evaluación para validarlo sistemáticamente con todo el conjunto de pruebas antes de ponerlo en producción.

Los prompts son código. Deben someterse a control de versiones, revisarse e implementarse con el mismo rigor que el código de la aplicación. El enfoque más básico consiste en almacenar las plantillas de prompts como cadenas en un archivo de constantes del repositorio, de modo que los cambios se registren en git y requieran una revisión de código.

Entre los enfoques más sofisticados se incluyen almacenar los prompts en una base de datos específica de gestión de prompts (LangSmith, PromptLayer o una tabla sencilla de Supabase), etiquetar las versiones y realizar pruebas A/B entre versiones de prompts en producción. Esto es especialmente importante cuando varios miembros del equipo trabajan en los mismos prompts o cuando necesita revertir un cambio que haya reducido la calidad en producción.

Cuando tenga dos versiones de prompt en competencia, ejecute ambas con todo su conjunto de pruebas y compare las puntuaciones. Incluso una mejora del 5 % en la precisión de un sistema en producción que procesa miles de solicitudes al día justifica el esfuerzo de la evaluación. Nunca elija un prompt basándose en uno o dos ejemplos probados manualmente: compárelos siempre con todo el conjunto de pruebas.

Para las medidas de calidad subjetivas en las que no existe una única respuesta correcta, como el tono, la utilidad o la creatividad, puede utilizar LLM-as-judge: solicite a un modelo potente, como GPT-4o, que evalúe cuál de dos respuestas cumple mejor sus criterios de calidad. Esto permite ampliar la evaluación más allá de lo que puede abarcar la revisión humana.

De forma predeterminada, los resultados de los LLM no son deterministas. Establecer temperature=0 hace que los resultados sean casi deterministas (se selecciona el token más probable en cada paso), algo esencial para la depuración, ya que permite ejecutar el mismo prompt dos veces y obtener el mismo resultado. Durante la depuración, establezca siempre la temperatura en 0 para poder aislar si un cambio en el prompt provocó el cambio en el resultado o si este se debió simplemente a una variación aleatoria.

Una vez corregido el prompt, vuelva a habilitar cierto nivel de temperatura en producción si su caso de uso se beneficia de la variedad, como la escritura creativa o la lluvia de ideas. Sin embargo, mantenga la temperatura en 0 para las tareas de extracción estructurada y clasificación en las que necesite resultados coherentes y reproducibles.

Si su prompt está generando datos ficticios, añada restricciones que dificulten las alucinaciones. Entre las técnicas eficaces para combatirlas se incluyen:

• Citar las fuentes: «Responda únicamente basándose en el contexto proporcionado. Si la respuesta no se encuentra en el contexto, diga “No lo sé”».
• Cuantificar la confianza: «Indique su nivel de confianza del 1 al 5. Si es inferior a 3, no responda».
• Incluir un paso de verificación: «Antes de responder, verifique que cada dato que planea utilizar está presente en el documento proporcionado».

Ninguna técnica elimina por completo las alucinaciones, pero combinar la recuperación (RAG) con restricciones sólidas en el prompt las reduce drásticamente en aplicaciones que requieren mucho conocimiento.

Las investigaciones han demostrado que los LLM prestan más atención a las instrucciones situadas al principio y al final de un prompt que a las del centro. Este fenómeno se denomina problema de pérdida en el centro. Si tiene un prompt largo con instrucciones importantes enterradas en el centro y rodeadas de contexto, es posible que el modelo no las siga de forma fiable.

Práctica recomendada: coloque las instrucciones más importantes, como la definición de la tarea y las restricciones críticas, al principio del prompt del sistema y repita las restricciones clave al final. En el caso de documentos largos insertados como contexto, coloque la pregunta del usuario después del documento y no antes, ya que el modelo dará más peso al contenido más reciente.

El ciclo de desarrollo de prompts consta de tres fases:

• Exploración: utilice el Playground para experimentar libremente. Céntrese en comprender qué funciona a nivel conceptual, no en obtener un resultado perfecto.
• Evaluación: cree un conjunto de pruebas y un sistema de evaluación. Ejecute los prompts candidatos con todo el conjunto de pruebas y mida las tasas de aprobación. Repita el proceso hasta alcanzar su umbral de calidad.
• Producción: controle las versiones del prompt final, añada supervisión para realizar un seguimiento de las métricas de calidad en producción y configure alertas para detectar su deterioro. Planifique futuras iteraciones cuando cambien las versiones del modelo.

Omitir la fase de evaluación es la causa más común de las regresiones en la calidad de los prompts en producción. El tiempo invertido en crear un conjunto de pruebas adecuado se amortiza muchas veces.

Compruebe cuánto ha entendido de los conceptos de ingeniería de IA de esta lección.

En esta lección ha aprendido que la ingeniería de prompts requiere un conjunto de pruebas de referencia y un sistema de evaluación para medir las mejoras de forma fiable, que los modos de fallo deben categorizarse para identificar la solución adecuada para cada tipo y que la temperatura 0 es esencial para la depuración, mientras que el control de versiones de los prompts y la supervisión en producción completan el ciclo de calidad. A continuación, exploraremos cómo procesan el texto los LLM mediante tokens y por qué el número de tokens es importante para el coste y el contexto.