Iteración y evaluación de prompts: testing, métricas y versionado
40 min
Intermedio-Avanzado
Claude
ChatGPT
cualquier LLM
hojas de cálculo
Iterar prompts sin metodología es optimización por casualidad. Con métricas claras, datasets de evaluación, A/B tests y versionado, convertís el prompting en ingeniería reproducible. Que el prompt "funcione" no alcanza — necesitás saber POR QUÉ funciona y CUÁNTO mejor es que las alternativas.
01 —
El problema
Los prompts evolucionan de forma caótica sin metodología.
Situación típica 1 — Iteración por intuición: v1 "Resume este texto" → muy largo. v2 "...en 3 frases" → pierde información clave. v3 "...en 3 frases, incluyendo la conclusión principal" → mejor, pero ¿es realmente mejor que v1 para TODOS los textos? Nadie sabe cuál es mejor ni por qué.
Situación típica 2 — Sin métricas claras: "Este prompt es mejor" — "¿Por qué?" — "Se siente mejor" — "¿Mejor en qué sentido?" — "...no sé, las respuestas son más útiles".
Situación típica 3 — Regresiones invisibles: semana 1 el prompt funciona bien; semana 2 alguien lo "mejora"; semana 3 los resultados empeoran pero nadie sabe qué cambió; semana 4 nadie recuerda cómo era el prompt original.
Por qué es importante: sin metodología de iteración, las mejoras son por casualidad y no por diseño, no podés demostrar que un cambio es mejor, las regresiones pasan desapercibidas, el conocimiento se pierde cuando alguien deja el equipo, y no podés escalar a múltiples prompts o proyectos.
02 —
La solución: framework de iteración sistemática
1. DEFINIR → Qué significa "bueno" para este prompt
2. MEDIR → Evaluar el prompt actual con métricas objetivas
3. CAMBIAR → Hacer UN cambio específico e hipótesis
4. COMPARAR → A/B test con mismos datos
5. DECIDIR → Adoptar, rechazar, o iterar más
6. VERSIONAR → Documentar y guardar
03 —
Cómo funciona
1. Definir — ¿qué significa "bueno"?
Antes de mejorar un prompt, definí criterios objetivos de éxito.
| Dimensión | Pregunta | Cómo medir |
|---|
| Correctitud | ¿La respuesta es factualmente correcta? | Comparar con ground truth |
| Completitud | ¿Incluye toda la información necesaria? | Checklist de elementos requeridos |
| Formato | ¿Sigue la estructura solicitada? | Match contra template |
| Consistencia | ¿Mismo input → mismo output? | Ejecutar N veces, medir varianza |
| Concisión | ¿Es breve sin perder información? | Contar palabras, evaluar densidad |
| Costo | ¿Cuántos tokens consume? | Contar tokens de entrada/salida |
Según el caso de uso: para clasificación, accuracy y distribución de categorías; para generación de código, ejecutabilidad y si pasa los tests; para extracción, precisión y recall de campos; para resúmenes, si cumple el límite de longitud y no inventa información (fidelidad).
plantilla# Prompt: [nombre descriptivo]
# Propósito: [qué hace este prompt]
## Métricas de éxito
### Críticas (must have)
1. [Métrica 1]: [definición] - Umbral mínimo: [X%]
### Importantes (should have)
2. [Métrica 2]: [definición] - Objetivo: [X]
## Dataset de evaluación
- Tamaño: [N ejemplos]
- Incluye: [casos normales, edge cases, casos de error]
2. Medir — evaluación objetiva
Un buen dataset de evaluación mezcla: casos normales (60%) — representativos del uso típico; edge cases (25%) — situaciones límite o inusuales; casos de error (15%) — inputs que deberían fallar o rechazarse.
// Ejemplo real (clasificador de tickets, lección anterior): edge case "no puedo acceder a ver mi factura" → esperado ACCOUNT, no BILLING, porque mezcla acceso + facturación y el problema real es el acceso.
matriz de evaluación# Evaluación: Prompt v1.0
| ID | Input (resumen) | Esperado | Obtenido | ¿Correcto? | Notas |
| N1 | "No puedo pagar..." | BILLING | BILLING | ✅ | |
| N3 | "Olvidé contraseña" | ACCOUNT | TECHNICAL | ❌ | Confundió con error |
| E1 | "No accedo factura" | ACCOUNT | BILLING | ❌ | Prioriza billing |
## Resumen
- Total: 20 casos · Correctos: 15 · Accuracy: 75%
## Errores frecuentes
1. Confunde ACCOUNT con TECHNICAL cuando menciona "error"
2. Prioriza BILLING cuando se menciona dinero aunque no sea el problema
3. Cambiar — iterar con hipótesis
Principio: un cambio a la vez.
✗ malv1 → v2: Cambié el formato, añadí ejemplos, modifiqué el tono,
y reestructuré las instrucciones
[Si mejora, ¿qué cambio fue? Si empeora, ¿qué revertir?]
✓ bienv1 → v1.1: Solo añadí 2 ejemplos few-shot
v1.1 → v1.2: Solo cambié "clasifica" por "determina la categoría"
v1.2 → v1.3: Solo añadí regla de desempate ACCOUNT vs TECHNICAL
formato de hipótesis# Cambio propuesto: v1.2 → v1.3
## Problema observado
El prompt confunde ACCOUNT con TECHNICAL cuando el usuario menciona
"error" junto con problemas de acceso.
## Hipótesis
Si añado una regla explícita de desempate que priorice ACCOUNT cuando
se menciona "contraseña", "login", o "acceder", la accuracy mejorará.
## Cambio específico
Añadir en reglas: "Si el texto menciona 'contraseña', 'login', 'acceso'
o 'entrar', clasificar como ACCOUNT aunque mencione 'error'."
## Predicción
- Accuracy general: 75% → 80%
## Riesgo
Podría sobre-clasificar como ACCOUNT casos que son realmente TECHNICAL
pero mencionan login de pasada.
| Problema | Tipo de cambio | Ejemplo |
|---|
| Baja accuracy | Añadir ejemplos few-shot | Incluir 2-3 ejemplos de casos que falla |
| Formato inconsistente | Restricciones más estrictas | "DEBES responder solo con X" |
| Confusión entre categorías | Reglas de desempate | "Si X e Y, priorizar X" |
| Alucinaciones | Restricciones de fidelidad | "Solo información explícita en el texto" |
4. Comparar — A/B testing
A/B test# A/B Test: Clasificador de tickets v1.2 vs v1.3
## Setup
- Dataset: 20 tickets (mismo para ambos) · 3 ejecuciones por prompt
## Resultados
### Accuracy
| Prompt | Run 1 | Run 2 | Run 3 | Promedio |
| v1.2 | 75% | 70% | 75% | 73.3% |
| v1.3 | 80% | 85% | 80% | 81.7% |
Δ Accuracy: +8.4 puntos porcentuales
### Consistencia (respuestas idénticas en 3 runs)
| v1.2: 16/20 (80%) | v1.3: 18/20 (90%) | Δ: +10pp
### Regresiones
- Caso T5 ("error 404 al login"): v1.2=TECHNICAL ✅, v1.3=ACCOUNT ❌
- La regla de "login" se activa aunque el caso es error técnico real
## Decisión
✅ ADOPTAR v1.3 — mejora significativa en accuracy y consistencia,
1 regresión identificada, menor que las mejoras.
Auditoría
El delta de +8.4pp de accuracy sale de un dataset de apenas 20 casos y 3 corridas. Con muestras tan chicas, una diferencia de uno o dos casos ya mueve varios puntos porcentuales — puede ser ruido, no una mejora real, y acá no hay intervalo de confianza ni test estadístico de por medio. Sirve como punto de partida razonable para iterar rápido, pero antes de confiar en un delta de pocos puntos para una decisión de producción conviene ampliar el dataset (50+ casos, como recomienda el troubleshooting más abajo) o repetir el experimento con otro conjunto de datos.
Cómo funciona (continuación)
5. Versionar — control de versiones para prompts
estructuraprompts/
└── clasificador-tickets/
├── v1.0.md # Versión inicial
├── v1.1.md # Añadidos ejemplos
├── v1.2.md # Ajuste de formato
├── v1.3.md # Regla de desempate
├── CURRENT.md # Copia de la versión activa
├── CHANGELOG.md # Historial de cambios
└── evaluation/
├── dataset.md
└── v1.3-results.md
archivo versionado---
version: 1.3
fecha: 2024-01-15
status: producción
modelo_probado: claude-sonnet-4-20250514
accuracy: 81.7%
---
# Clasificador de Tickets v1.3
## Changelog desde v1.2
- Añadida regla de desempate ACCOUNT vs TECHNICAL
## Prompt
[el prompt completo]
## Métricas
- Accuracy: 81.7% (dataset de 20 casos) · Consistencia: 90%
## Limitaciones conocidas
- Puede clasificar como ACCOUNT errores técnicos que mencionan "login"
- No probado con textos > 500 palabras
6. Decidir — criterios para adoptar cambios
¿El cambio mejora la métrica principal?
├── NO → Rechazar (a menos que mejore métrica secundaria importante)
└── SÍ → ¿Introduce regresiones?
├── NO → ✓ Adoptar
└── SÍ → ¿Regresiones < Mejoras?
├── SÍ → ✓ Adoptar con nota de regresión
└── NO → Iterar más o rechazar
umbrales de decisión## Para adoptar un cambio DEBE cumplir:
- Accuracy ≥ accuracy actual O justificación documentada
- Consistencia no disminuye más de 5pp
- No introduce regresiones en casos críticos
- Probado con dataset completo (20+ casos)
## Regresiones inaceptables (nunca adoptar si ocurren):
- Clasificar incorrectamente casos de BILLING (impacto económico)
- Generar outputs que no son JSON válido
- Exceder límite de tokens en >10% de casos
04 —
Ejercicio práctico
Objetivo: aplicar el framework completo de iteración en un prompt real.
Paso 1 — Definir métricas para este prompt
prompt base v1.0Clasifica la urgencia de emails de clientes.
# CATEGORÍAS
- URGENTE: Requiere respuesta en <4 horas (problema bloqueante, pérdida de dinero)
- ALTA: Requiere respuesta en <24 horas (problema importante pero no crítico)
- NORMAL: Respuesta en 2-3 días aceptable (consultas, feedback)
- BAJA: Sin expectativa de respuesta rápida (sugerencias, comentarios)
# FORMATO
Responde solo con la categoría en mayúsculas.
# EMAIL
---
[email aquí]
---
Tu tarea: definí 3 métricas para evaluar este prompt (por ejemplo, accuracy contra la urgencia esperada, consistencia entre ejecuciones, y distribución entre las 4 categorías).
Paso 2 — Crear dataset de evaluación
Creá 10 ejemplos de emails con su urgencia esperada: 6 normales, 3 edge cases (ambiguos entre dos categorías), 1 caso de error (ej: un email vacío o sin contenido claro).
Paso 3 — Evaluar v1.0
Ejecutá el prompt base con tus 10 emails, registrá esperado vs obtenido para cada uno, y calculá el accuracy.
Paso 4 — Identificar problema e hipotetizar
Basándote en los errores más frecuentes, armá un "Cambio propuesto: v1.0 → v1.1" con problema observado, hipótesis, el cambio específico al prompt, y una predicción de accuracy.
Paso 5 — Ejecutar A/B test
Evaluá v1.1 con los mismos 10 emails. Armá la tabla comparativa (Esperado, v1.0 ✓/✗, v1.1 ✓/✗), calculá el accuracy de cada versión, la diferencia (Δ), y tomá una decisión: ADOPTAR, RECHAZAR, o ITERAR.
Paso 6 — Documentar la versión final
Escribí el frontmatter (versión, fecha, accuracy), el prompt final, las métricas, las limitaciones conocidas, y un changelog breve con las versiones que probaste.
05 —
Troubleshooting rápido
| Si ves esto... | Causa | Solución |
|---|
| Accuracy no mejora con ningún cambio | Dataset demasiado difícil o prompt cerca del límite del modelo | Simplificá la tarea o dividí en sub-tareas |
| Mejora en unos casos, empeora en otros | Cambios contradictorios | Dividí en prompts especializados para cada tipo |
| Consistencia baja (mucha variación entre runs) | Prompt ambiguo o tarea inherentemente subjetiva | Añadí más ejemplos few-shot o criterios más explícitos |
| No sé qué métrica usar | Tarea no bien definida | Preguntá: "¿Cómo sabría un humano si esta respuesta es buena?" |
| Dataset muy pequeño, resultados no confiables | Pocos ejemplos | Mínimo 20 ejemplos; 50+ para producción |
| Cambios pequeños no tienen efecto | Problema no es de prompting sino del modelo | Considerá cambiar de modelo o reformular la tarea |
06 —
Puntos clave
Concepto central: iterar prompts sin metodología es optimización por casualidad. Con métricas claras, datasets de evaluación, A/B tests, y versionado, convertís el prompting en ingeniería reproducible. El prompt que "funciona" no es suficiente; necesitás saber POR QUÉ funciona y CUÁNTO mejor es que las alternativas.
Para recordar:
- ✓ Definí métricas ANTES de iterar — "mejor" debe ser medible
- ✓ Un cambio a la vez — para saber qué funcionó
- ✓ Dataset con edge cases — los casos fáciles no revelan problemas
- ✓ Ejecutá múltiples veces — una ejecución no mide consistencia
- ✓ Documentá regresiones — no solo mejoras
- ✓ Versioná como código — los prompts SON código
- ✗ No iteres por intuición — "se siente mejor" no es métrica
- ✗ No descartes regresiones pequeñas — se acumulan
- ✗ No pruebes solo happy path — los edge cases rompen producción