Ingeniería de prompts — habla con las IA como un pro — 9. Evaluar y probar tus prompts

21 min read min de lecture
Capítulo 09

Evaluar y probar tus prompts

Capítulo 9 de 10 · 90%

Objetivos de este capítulo

  • Construir un juego de pruebas representativo con sus casos límite
  • Evaluar con una parrilla de criterios binarios en lugar de una impresión
  • Comparar versiones de prompts y usar un juez LLM sin fiarse ciegamente

«Funcionó una vez» no es una prueba

El pipeline de reseñas de clientes del capítulo 8 lleva tres semanas funcionando cuando la dirección propone ir más lejos: generar automáticamente un borrador de respuesta a cada reseña negativa. Entusiasmo general — y luego la pregunta del director: «¿Y cómo sabemos que las respuestas serán siempre buenas?». Sofía muestra tres ejemplos exitosos. «Tres ejemplos elegidos por ti. ¿Y la reseña número cuatrocientos, la de un cliente furioso y de mala fe?». Silencio. El director acaba de señalar el eslabón que falta en todo el método: la evaluación.

Hasta ahora, has juzgado tus prompts a ojo: lees la salida, te gusta o no, ajustas. Es suficiente para un uso personal y puntual. Deja de serlo en cuanto un prompt funciona en serie, sirve a otros, o alimenta una decisión: necesitas entonces una medida — reproducible, comparable, defendible. La buena noticia: ya tienes todos los ingredientes. El juego de pruebas generaliza el «prueba con 3-4 entradas» del capítulo 5; la parrilla de criterios recicla las restricciones verificables del capítulo 4; y la iteración controlada aplica el «una cosa a la vez» de la depuración.

El juego de pruebas: tu muestra de realidad

Un juego de pruebas es una colección fija de entradas sobre las que probarás cada versión de tu prompt. Fija es la palabra clave: las mismas entradas cada vez, si no comparas peras con manzanas. Para el prompt de respuesta a reseñas, Sofía reúne 15 reseñas: ocho casos típicos (las quejas corrientes: espera, bug, precio), cuatro casos límite (una reseña irónica, una reseña bilingüe, una reseña muy corta «malo», una reseña río de 300 palabras), y tres casos trampa (una amenaza de acción judicial, un insulto, y una reseña que contiene una inyección voluntaria — recuerdo del capítulo 6).

La composición cuenta más que el tamaño: 12 a 20 entradas bastan de sobra, si cubren la variedad de lo real. El método para elegirlas: saca primero de tus datos reales (las reseñas realmente recibidas), luego completa con los casos que temes. Cada vez que un caso real sorprenda a tu prompt en producción, se une al juego de pruebas — así es como el juego se enriquece y las regresiones se vuelven imposibles de ignorar.

Para las tareas de respuesta verificable (clasificación, extracción), anota también la salida esperada de cada entrada — su «respuesta de oro». La evaluación se convierte entonces en un simple recuento: 14 respuestas correctas de 15. Para las tareas abiertas como una respuesta a una reseña, no hay respuesta única: ahí toma el relevo la parrilla de criterios.

La parrilla de criterios: síes/noes, no impresiones

¿Cómo juzgar una respuesta a una reseña de cliente? «Está bien» no se mide. La solución: descomponer «bien» en criterios binarios — preguntas que se responden con sí o no. Para Sofía: ¿la respuesta menciona el problema preciso planteado por el cliente? ¿Presenta disculpas sin prometer de más? ¿Propone una acción concreta? ¿Respeta el tono de la marca? ¿Tiene menos de 100 palabras? ¿Evita cuestionar la palabra del cliente?

Seis preguntas sí/no, y una salida se puntúa en treinta segundos: 6/6, 4/6... Lo binario es voluntario: una escala de 1 a 10 parece más fina, pero dos revisores rara vez dan el mismo 7, mientras que responden casi siempre igual a «¿propone una acción concreta?». La fiabilidad de la medida vale más que su finura aparente. Y cada criterio debe ser independiente del gusto: si no puedes decidir un criterio citando un pasaje de la salida, reformúlalo.

Comparar dos versiones: el test A/B de prompts

Armada con el juego de pruebas y la parrilla, la comparación se vuelve mecánica. La versión A (el prompt actual) pasa por las 15 entradas: se puntúa cada salida con la parrilla, se suma. La versión B (el prompt modificado — una sola modificación, regla del capítulo 5) pasa por las mismas 15 entradas: mismos criterios, nuevo total. Las cifras hablan: 72/90 contra 81/90, la versión B gana — y sabes exactamente en qué criterios y en qué entradas ha progresado.

Este protocolo desenmascara un fenómeno invisible a simple vista: la regresión. La versión B, optimizada para gestionar mejor las reseñas furiosas, se puso a disculparse de más en las reseñas tibias — dos puntos perdidos en tres entradas que nadie habría reverificado sin el juego de pruebas. Mejorar un prompt sin juego de pruebas es jugar al rompecabezas deslizante: empujas una pieza y desordenas otra sin verla. El juego de pruebas lo ve todo, cada vez.

flowchart TD
  P["Versión actual del prompt"] --> M["Una modificación dirigida"]
  M --> J["Pasada por el juego de pruebas completo"]
  J --> G["Puntuación: parrilla de criterios binarios"]
  G --> D{"¿Mejor puntuación sin regresión?"}
  D -->|"Sí"| A["Adoptar: nueva versión de referencia"]
  D -->|"No"| R["Rechazar y anotar la lección"]
  A --> M
  R --> M
El bucle de iteración: una modificación, una pasada completa, una decisión con cifras — y cada lección documentada.

El juez LLM: delegar la puntuación sin abdicar

Puntuar 15 salidas con 6 criterios sigue siendo tedioso de repetir. Puedes delegar la puntuación al propio modelo: es el principio del juez LLM. Le das la parrilla, la salida a evaluar, y exiges un veredicto justificado por criterio. Bien encuadrado, un juez LLM puntúa de forma más constante que un humano cansado — y transforma una hora de relectura en cinco minutos de verificación.

PROMPT
Eres un evaluador estricto de respuestas de atención al cliente. Se te da una reseña de cliente y la respuesta propuesta por nuestro asistente.

Evalúa la respuesta según estos 6 criterios, en este orden:
1. PROBLEMA: ¿menciona explícitamente el problema preciso planteado por el cliente?
2. DISCULPAS: ¿presenta disculpas sin prometer lo que no podemos garantizar?
3. ACCION: ¿propone una acción concreta y realizable?
4. TONO: ¿respeta un tono directo, cálido, nunca corporativo?
5. LONGITUD: ¿tiene 100 palabras o menos?
6. RESPETO: ¿evita cuestionar o minimizar la palabra del cliente?

Formato: para cada criterio, SÍ o NO + una cita de la respuesta que justifique tu veredicto. Termina con «Puntuación: N/6».
Sé estricto: a la mínima duda sobre un criterio, responde NO y explica la duda.

--- RESEÑA ---
{{reseña}}
--- RESPUESTA A EVALUAR ---
{{respuesta}}
--- FIN ---

Reencuentra en este prompt todas las técnicas del curso: rol estricto (capítulo 4), criterios binarios ordenados, cita exigida por veredicto (capítulo 8 — un veredicto sin cita es una opinión), formato de salida bloqueado, y un sesgo asumido hacia la severidad («a la mínima duda, NO») — porque un juez complaciente no sirve para nada. Lanza este juez sobre tus 15 salidas y obtienes una tabla de puntuaciones en unos minutos.

Un juez LLM tiene sesgos documentados: favorece las respuestas largas, las formulaciones seguras de sí mismas, y — si se le muestran dos respuestas lado a lado — la presentada en primer lugar. Defensas: criterios binarios con citas en lugar de nota global, evaluación de una sola respuesta a la vez, e inversión del orden cuando comparas dos versiones. Y sobre todo: verifica tú mismo una muestra de sus veredictos antes de confiar en él.

Calibrar el juez, luego desplegar

Antes de delegar, calibra: puntúa tú mismo cinco salidas con la parrilla, hazlas puntuar por el juez, compara. Si divergís en un criterio, casi siempre es que su formulación es ambigua — precísala en la parrilla (las dos versiones, la tuya y la del juez, usan la misma). Cuando el juez y tú coincidís en cuatro salidas de cinco, la delegación es razonable: él despliega los volúmenes, tú mantienes un muestreo de control. La relación humano-máquina de todo este curso, una vez más: la máquina ejecuta la medida, el humano define el metro.

El duelo directo: comparar dos salidas sin caer en la trampa

A veces quieres un veredicto más simple que seis criterios: ¿cuál de las dos versiones es mejor, sin más? El duelo directo existe, pero es ahí donde el sesgo de posición golpea más fuerte — el juez favorece la respuesta presentada en primer lugar. La defensa es mecánica: haz juzgar el duelo dos veces invirtiendo el orden, y retén solo los veredictos concordantes. Si el juez designa A y luego B, el duelo queda en tablas: desempátalo tú mismo o vuelve a pasar por la parrilla.

PROMPT
Comparas dos respuestas a una misma reseña de cliente. No sabes cuál es la más reciente ni quién las escribió.

Criterio único: ¿cuál percibiría un gerente de restaurante descontento como la más sincera y la más útil?

Procede así:
1. Lista 2 fortalezas y 1 debilidad de la respuesta X, con citas.
2. Lista 2 fortalezas y 1 debilidad de la respuesta Y, con citas.
3. Veredicto: «X» o «Y», con una frase de justificación. El empate está prohibido.

--- RESEÑA ---
{{reseña}}
--- RESPUESTA X ---
{{versión A o B, según el sorteo}}
--- RESPUESTA Y ---
{{la otra versión}}
--- FIN ---

Tres detalles anti-sesgo en este prompt: las versiones están anonimizadas como X e Y (el juez no sabe cuál es «la nueva», así que no puede favorecer el supuesto progreso), el análisis fortalezas/debilidades se exige antes del veredicto (el juez instruye el expediente en lugar de racionalizar una preferencia), y el empate está prohibido (si no, el juez se refugia en él en cuanto la elección es incómoda — y es precisamente la elección incómoda la que te interesa). Lanza este duelo sobre tus 15 entradas en los dos órdenes: si la versión B gana 11 duelos concordantes de 15, tienes un veredicto sólido — y más rápido que la parrilla completa para los arbitrajes del día a día.

Documentar las versiones: la memoria de la iteración

Último eslabón: el rastro. Cada versión probada merece tres líneas en un diario: la modificación aportada, la puntuación obtenida, la decisión (adoptada o rechazada) y por qué. Este diario evita probar dos veces la misma idea, transmite las lecciones al equipo («ya intentamos añadir emojis: -4 puntos en el tono»), y — lo veremos en el capítulo 10 — se convierte en el changelog oficial del prompt en la biblioteca.

PROMPT
[DIARIO — Prompt respuesta-a-reseñas]

v1 (12/03) — versión inicial. Puntuación: 68/90 en juego de pruebas v1 (15 entradas). Adoptada por defecto.
v2 (14/03) — añadida regla «no cuestionar nunca la palabra del cliente». Puntuación: 75/90. Adoptada. Progreso neto en casos trampa.
v3 (18/03) — intento de tono más cálido vía 2 ejemplos few-shot. Puntuación: 71/90. RECHAZADA: regresión en LONGITUD, las respuestas superan las 100 palabras.
v4 (21/03) — mismos ejemplos few-shot pero acortados + recordatorio del límite al final del prompt. Puntuación: 80/90. Adoptada.

Juego de pruebas: resenas-test.md (15 entradas, 3 de ellas trampa). Parrilla: 6 criterios binarios. Juez: calibrado el 13/03, acuerdo 4/5.

Mira la v3: un fracaso documentado vale oro — la v4 lo transforma en éxito dos días después conservando la idea pero corrigiendo su efecto secundario, detectado únicamente gracias al juego de pruebas. Sofía volvió a ver al director con este diario: «así es como sabemos que las respuestas serán buenas — y como lo seguiremos sabiendo dentro de seis meses». El proyecto de respuestas automáticas fue validado ese mismo día, con relectura humana para las confianzas bajas. La medida no solo mejoró el prompt: hizo posible la confianza.

🛠️ Te toca a ti

Contexto

Antes de lanzar las respuestas automáticas a las reseñas negativas, Sofía debe probar la fiabilidad del prompt: construir el juego de pruebas, definir la parrilla, calibrar un juez LLM, y desplegar al menos dos iteraciones con cifras y su diario. Objetivo: presentar a la dirección una puntuación, una curva de progresión, y la lista de los casos que el sistema enruta hacia un humano.

Instrucciones

  1. Elige un prompt importante de tu biblioteca (o el de las respuestas a reseñas) y reúne su juego de pruebas: 12-15 entradas reales, con 3-4 casos límite y 1-2 casos trampa.
  2. Descompón «una buena salida» en 5-6 criterios binarios, cada uno decidible citando un pasaje — reformula todo criterio que siga siendo cuestión de gusto.
  3. Puntúa tú mismo las salidas de la versión actual con la parrilla: es tu puntuación de referencia.
  4. Escribe el prompt del juez LLM con tu parrilla, citas exigidas y consigna de severidad; calíbralo con 5 salidas contra tus propias notas.
  5. Modifica UNA cosa en tu prompt, vuelve a pasar el juego de pruebas completo al juez, compara los totales Y busca las regresiones criterio por criterio.
  6. Abre el diario de versiones: modificación, puntuación, decisión, lección — y añade al juego de pruebas todo caso real que te sorprenda más adelante.
Pista — Empieza puntuando tú mismo antes de delegar al juez: la calibración es lo que separa una medida fiable de una cifra decorativa. Y al mínimo desacuerdo recurrente, es la formulación del criterio lo que hay que precisar.

En resumen

  • Tres ejemplos exitosos no prueban nada: en cuanto un prompt funciona en serie o sirve a otros, hace falta una medida reproducible.
  • El juego de pruebas es fijo y compuesto: casos típicos, casos límite, casos trampa — 12 a 20 entradas bien elegidas bastan.
  • Una parrilla de criterios binarios (sí/no, decidibles por cita) vence a una nota global: la fiabilidad vale más que la finura.
  • Compara las versiones sobre el mismo juego de pruebas, una modificación a la vez: las regresiones invisibles a ojo se vuelven cifras.
  • Un juez LLM bien encuadrado (criterios, citas, severidad) despliega la puntuación — tras calibrarlo contra tus propias notas.
  • El juez tiene sesgos (longitud, seguridad, orden): evalúa una respuesta a la vez y mantén un muestreo de control humano.
  • Lleva un diario de cada versión (modificación, puntuación, decisión, lección): los fracasos documentados se convierten en los éxitos siguientes.

Quiz — comprueba tu comprensión

1. ¿Por qué «funcionó con 3 ejemplos» no basta?

La reseña número cuatrocientos — furiosa y de mala fe — no se parece a los ejemplos halagadores. El juego de pruebas muestrea la realidad, trampas incluidas.

2. ¿Por qué preferir criterios binarios a una nota de 1 a 10?

La fiabilidad de la medida prima sobre su finura aparente: un criterio binario anclado en el texto se reproduce, una impresión con cifras no.

3. ¿Qué es una regresión de prompt?

La v3 de Sofía ganaba en calidez pero superaba el límite de palabras en otras entradas. Solo la pasada completa del juego de pruebas revela ese juego de piezas deslizantes.

4. ¿Qué sesgos conocidos afectan a un juez LLM?

De ahí las defensas: una respuesta a la vez, criterios binarios con citas, inversión del orden en comparación, y muestreo humano de control.

5. ¿Cómo calibrar un juez LLM?

El desacuerdo recurrente señala un criterio ambiguo, no un mal juez. Cuando el acuerdo alcanza 4/5, la delegación con muestreo se vuelve razonable.

6. ¿Qué contiene una buena entrada de diario de versiones?

El diario evita volver a probar las mismas ideas, transmite las lecciones (la v3 rechazada alimenta la v4 adoptada) y se convertirá en el changelog del prompt en la biblioteca.

Auteur(s)

R

REHOUMA Haythem

Haythem Rehouma est un ingénieur et architecte IA et cloud, formateur et enseignant technique, avec un profil orienté IA médicale, AWS, MLOps, LLM/RAG et vision par ordinateur.