La primera versión de un prompt es un borrador. A menudo te da algo cercano a lo que quieres, y la distancia entre cercano y correcto se cierra iterando: cambiar el prompt a propósito, volver a ejecutarlo con la misma entrada y comprobar si el cambio ayudó. Hecho sin cuidado, iterar se convierte en reformular al azar hasta que una salida afortunada parece estar bien. Hecho como un pequeño experimento, te da un prompt que funciona con las próximas cien entradas, no solo con la que probaste.
El método tiene cinco pasos: define cómo es un buen resultado, mantén entradas de prueba fijas, cambia una sola cosa a la vez, compara las salidas y sabe cuándo parar.
Define cómo es una buena respuesta
Antes de editar nada, escribe lo que la salida debe hacer, como comprobaciones que puedas responder con sí o no. "Un buen mensaje de commit" no se puede comprobar. Esto sí:
- La línea de asunto tiene menos de 50 caracteres.
- Sigue el formato Conventional Commits (
fix:,feat:, etc.). - El cuerpo dice por qué hacía falta el cambio, no lo que ya muestra el diff.
- Menciona el número de la incidencia cuando lo hay.
Los criterios cumplen dos funciones. Te dicen qué añadir al prompt, ya que cada uno suele ser una instrucción que falta. Y evitan que juzgues las salidas por lo bien que suenan, que es la forma más fácil de aceptar una respuesta segura pero incorrecta.
Mantén un pequeño conjunto de entradas de prueba
Elige de tres a diez entradas y mantenlas fijas mientras trabajas. Incluye casos típicos, un par de casos incómodos (un campo vacío, una entrada muy larga, un idioma que el prompt no esperaba) y todas las entradas que hayan fallado antes. Un prompt ajustado con un solo ejemplo tiende a encajar con ese ejemplo y fallar con el siguiente.
Escribe el prompt como una plantilla con un hueco para la entrada, para que todas las versiones se ejecuten exactamente con el mismo material.
Cambia una sola cosa a la vez
Cuando cambias a la vez el rol, el formato y los ejemplos y la salida mejora, no sabes qué cambio lo consiguió, y puede que estés conservando dos ediciones inútiles. Cambia una cosa, ejecuta y compara. Las pestañas de abajo son tres versiones de un mismo prompt, cada una con un solo cambio respecto a la anterior.
- if len(password) > 8:
+ if len(password) >= 8:
return True
Actualiza la validación de la longitud de la contraseña
Este commit actualiza la lógica de validación de contraseñas cambiando el operador de comparación de > a >=. Como resultado, las contraseñas de exactamente 8 caracteres ahora se considerarán válidas. Este cambio mejora la precisión de la validación y ofrece una mejor experiencia a los usuarios que crean cuentas.
La versión 1 falla los criterios 2 y 3: el asunto no tiene prefijo de tipo y el cuerpo vuelve a contar el diff con más palabras. La versión 2 añade los requisitos de formato y cumple los criterios 1 y 2, pero su cuerpo sigue describiendo el diff. La siguiente edición obvia es otra instrucción ("explica por qué"), pero el modelo no puede explicar un motivo que nunca se le dio. La versión 3 añade en su lugar el contexto que faltaba, y el cuerpo y la referencia a la incidencia llegan sin pedirlos. Esa es la lección más común de iterar: cuando una instrucción no arregla una salida, al prompt suele faltarle información, no énfasis.
Compara las salidas lado a lado
Ejecuta cada versión con cada entrada de prueba, y ejecuta cada una más de una vez, porque los modelos de chat muestrean sus palabras y dos ejecuciones del mismo prompt varían. Pon las salidas una al lado de la otra y compruébalas con tus criterios, no con tu recuerdo de la ejecución anterior.
Para los criterios precisos, una segunda llamada al modelo puede hacer una primera pasada de calificación. Pega las salidas en un prompt de calificación con los criterios bien detallados:
| Criterio | Salida A | Salida B |
|---|---|---|
| 1. Asunto de menos de 50 caracteres | Aprobado: el asunto tiene 46 caracteres | Aprobado: mismo asunto, 46 caracteres |
| 2. Conventional Commits | Aprobado: empieza por "fix:" | Aprobado: empieza por "fix:" |
| 3. El cuerpo explica por qué | Suspenso: "Cambia la comprobación de longitud de > a >=" repite el diff | Aprobado: "los usuarios que seguían las instrucciones no podían registrarse" |
| 4. Menciona la incidencia | Suspenso: no hay número de incidencia | Aprobado: "Fixes #412" |
Trata a un modelo calificador como un ayudante, no como un árbitro. Zheng et al. 2023, "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena", documentaron sesgos en los modelos que hacen de jueces, entre ellos la preferencia por las respuestas más largas y por la respuesta en una posición concreta. Mantén criterios comprobables, pide evidencias citadas, intercambia el orden de A y B cuando compares dos y lee tú mismo una muestra de las salidas. Comprobaciones como contar caracteres son más fiables como una línea de código que como el juicio de un modelo.
Arregla el prompt, no la conversación
En un chat es tentador corregir la respuesta con mensajes de seguimiento: "más corto", "no, menciona la incidencia", "usa el otro formato". Eso te da una buena salida y deja el prompt tan mal como estaba. Cuando una corrección funcione, pásala al prompt y ejecútalo desde cero. La próxima vez que necesites el resultado, pegarás un mensaje en lugar de repetir cinco.
Guarda las versiones anteriores con una nota de una línea sobre qué cambió y qué arregló. Basta con un archivo de texto. Cuando una edición posterior empeore las cosas, podrás volver atrás en lugar de intentar recordar qué decía antes el prompt.
Hacer una comparación en código
Cuando un prompt se ejecuta a través de una API, un script corto puede producir la vista lado a lado para cada versión y cada entrada de prueba. Este usa el SDK de Python de OpenAI y escribe un archivo markdown que puedes leer de principio a fin.
from openai import OpenAI
client = OpenAI()
MODEL = "your-model-id" # e.g. from your provider's model list
# each prompt file contains {input} where the test diff goes
PROMPTS = {
"v2": open("prompts/commit_v2.txt").read(),
"v3": open("prompts/commit_v3.txt").read(),
}
TESTS = [open(f"tests/diff_{i}.txt").read() for i in range(1, 6)]
with open("results.md", "w") as out:
for i, test in enumerate(TESTS, 1):
out.write(f"## Test {i}\n\n")
for name, template in PROMPTS.items():
for run in (1, 2):
response = client.chat.completions.create(
model=MODEL,
messages=[{"role": "user", "content": template.replace("{input}", test)}],
)
out.write(f"### {name}, run {run}\n\n{response.choices[0].message.content}\n\n")
Cuándo parar
Para cuando todos los criterios se cumplan con todas las entradas de prueba en un par de ejecuciones. Añadir más a partir de ahí sobre todo añade longitud, y cada instrucción extra es una cosa más que puede chocar con las demás.
Para también cuando los cambios empiecen a intercambiar fallos: una edición arregla la prueba 2 y rompe la 4, y la siguiente lo invierte. Ese patrón significa que al prompt se le está pidiendo algo que una sola instrucción no puede fijar. Las salidas habituales son mostrar el formato con un par de ejemplos (prompting few-shot), dividir el trabajo en pasos con encadenamiento de prompts o pasar las partes deterministas, como contar caracteres o comprobar un formato, a un código que revise la salida. Si te quedas sin ideas, el metaprompting puede ayudar: dale a un modelo el prompt, la entrada y la mala salida, y pregúntale qué parte del prompt es la causa más probable.
Preguntas frecuentes
¿Cómo mejoro un prompt que da malas respuestas?
Mira la mala respuesta y nombra qué tiene de malo: formato incorrecto, falta un dato, público equivocado, demasiado larga. Luego busca qué dejó de decir el prompt que lo habría evitado, añade eso y ejecuta la nueva versión con la misma entrada. Las malas respuestas vienen más a menudo de un contexto o una instrucción de formato que faltan que de la redacción.
¿Cuántas entradas de prueba necesito para probar un prompt?
Para un prompt que vas a reutilizar, de tres a diez suelen bastar: unos cuantos casos típicos, uno o dos casos límite (muy corto, muy largo, poco habitual) y una entrada que ya falló antes. Mantenlas fijas mientras iteras, para que un cambio en la salida venga del prompt y no de una entrada distinta.
¿Por qué obtengo una respuesta distinta al ejecutar otra vez el mismo prompt?
Los modelos de chat eligen cada palabra mediante un muestreo sobre una distribución de probabilidades, así que las salidas varían entre ejecuciones. Cuando compares dos versiones de un prompt, ejecuta cada una más de una vez con las mismas entradas. Una diferencia que aparece en todas las ejecuciones probablemente es real; una que aparece en una sola puede ser casualidad. A través de una API también puedes bajar la temperatura para reducir la variación.
¿Puedo usar una IA para calificar las salidas de mi prompt?
Sí, para criterios que puedas formular con precisión, como "el cuerpo dice por qué hacía falta el cambio" o "menciona el número de la incidencia". Dale al calificador tus criterios exactos y pide aprobado o suspenso por criterio, con una cita como evidencia. Los modelos calificadores tienen sesgos conocidos, entre ellos favorecer las respuestas más largas y favorecer una posición sobre la otra, así que lee tú mismo algunas salidas e intercambia el orden cuando compares dos.
¿Cuándo debo dejar de mejorar un prompt?
Para cuando todos los criterios se cumplan con todas las entradas de prueba en un par de ejecuciones, o cuando cada cambio nuevo arregle un caso y rompa otro. En ese punto el problema no suele ser el prompt: puede que la tarea necesite ejemplos, dividirse en pasos o una comprobación en código.
