1. Introducción: Si No Mides, No Mejoras

Descripción

El problema: "se ve bien" no es una métrica. La mayoría de prompt engineers evalúan con vibes. Evaluation como disciplina de ingeniería: métricas objetivas, benchmarks, regression testing, A/B testing.

El Problema: Evaluación por Intuición

Cuando construyes un sistema LLM, probablemente haces algo así:

1. Escribes un prompt
2. Pruebas 3-5 casos manualmente
3. "Se ve bien" → deploys
4. Semanas después: "Oye, ¿por qué está fallando esto?"

Este es el flujo de trabajo estándar en la mayoría de proyectos LLM. Y es un problema enorme.

Por Qué "Se Ve Bien" No Funciona

Problema 1: Sesgo de confirmación
→ Pruebas los casos que esperas que funcionen
→ No pruebas los casos difíciles o raros
→ Tu muestra de 5 ejemplos no es representativa

Problema 2: No tienes baseline
→ Cambias el prompt la próxima semana
→ ¿Mejoró? ¿Empeoró? No tienes datos para saberlo

Problema 3: Sin regresión
→ Arreglas un bug en el prompt
→ Sin darte cuenta, rompes algo que antes funcionaba
→ Tus usuarios lo descubren antes que tú

Problema 4: Escala no lineal
→ 5 casos = "funciona"
→ 1000 casos reales = el 8% falla silenciosamente
→ En producción, ese 8% son usuarios insatisfechos

Por Qué Evaluar

La evaluación sistemática de prompts no es burocracia académica. Es la diferencia entre un sistema LLM que funciona en producción y uno que falla de maneras invisibles.

Beneficios Concretos

• Reproducibilidad: Saber con certeza si un cambio mejora o empeora el sistema
• Regresión: Detectar automáticamente cuando un prompt deja de funcionar
• Comparación objetiva: Zero-shot vs few-shot, prompt A vs B, modelo X vs modelo Y
• Confianza en deploy: No deployar sin saber que el sistema pasa sus métricas
• Debugging informado: Cuando algo falla, saber exactamente qué falló y en qué porcentaje

Ejemplo Real: El Valor de Tener Métricas

Escenario: Sistema de clasificación de tickets de soporte

Sin métricas:
- "El clasificador parece funcionar"
- Deploy en producción
- 3 semanas después: cliente reporta que tickets urgentes se categorizan como "baja prioridad"
- Investigas: el problema existía desde el día 1 para tickets con ciertos patrones

Con métricas:
- Golden set de 200 tickets con categorías correctas
- Accuracy baseline: 94%
- Al cambiar el prompt: accuracy cae a 87%
- Regresión detectada ANTES del deploy
- Corriges antes de que afecte usuarios reales

Evaluation vs Vibes

La diferencia fundamental entre evaluación sistemática y evaluación por intuición:

Las Tres Capas de Evaluation

Un framework de evaluación completo tiene tres capas:

Capa 1: Métricas Automatizadas

Calculadas con código, sin intervención humana:

• Accuracy: Predicción == ground truth
• Format compliance: ¿El output tiene el formato esperado (JSON, etc.)?
• BLEU/ROUGE: Para generación de texto, comparar con referencia

Capa 2: LLM-as-Judge

Un LLM evalúa el output de otro LLM:

• Faithfulness: ¿El output es fiel al input? ¿Inventa información?
• Relevance: ¿El output responde la pregunta?
• Quality: Rubric multi-criterio (corrección, claridad, completitud)

Capa 3: Evaluación Humana

Para decisiones críticas y calibración:

• Validar golden sets
• Revisar muestras del LLM-as-judge
• Decisiones finales sobre deploy

Capa 1 (Automatizada) ← Rápida, barata, frecuente (en cada commit)
Capa 2 (LLM-as-Judge) ← Más cara, menos frecuente (en cada PR o daily)
Capa 3 (Humana)       ← Costosa, periódica (semanal/mensual, o en hitos)

Tipos de Evaluation

Offline Evaluation

Evalúas el prompt contra un dataset fijo antes de deployar.

from openai import OpenAI

client = OpenAI()

def evaluar_offline(prompt_template: str, golden_set: list[dict]) -> dict:
    """
    Evaluación offline: antes del deploy.
    Compara outputs del prompt contra expected_outputs del golden set.
    """
    resultados = []
    
    for ejemplo in golden_set:
        # Construir el mensaje completo
        prompt = prompt_template.format(input=ejemplo["input"])
        
        response = client.chat.completions.create(
            model="gpt-4o-mini",
            messages=[{"role": "user", "content": prompt}],
            temperature=0  # Determinismo para reproducibilidad
        )
        
        output = response.choices[0].message.content
        expected = ejemplo["expected_output"]
        
        resultados.append({
            "input": ejemplo["input"],
            "output": output,
            "expected": expected,
            "correct": output.strip().lower() == expected.strip().lower()
        })
    
    accuracy = sum(r["correct"] for r in resultados) / len(resultados)
    return {"accuracy": accuracy, "resultados": resultados}

Online Evaluation

Evalúas el prompt en producción con usuarios reales:

• Sample del tráfico real
• A/B testing con usuarios
• Feedback implícito (clicks, correcciones, abandono)

Offline → Antes del deploy (siempre)
Online  → Después del deploy (para refinamiento continuo)

Cuándo Evaluar

La evaluación debe ser continua, no un evento único:

DESARROLLO:
│
├── Al crear un prompt nuevo → Evaluar contra golden set
│
├── Al modificar un prompt → Regression test vs baseline
│
├── Al cambiar el modelo (gpt-4o-mini → gpt-4o) → Comparar métricas
│
├── Periódicamente (semanal/mensual) → Detectar drift gradual
│
└── Antes de cada deploy → Checklist completa

PRODUCCIÓN:
│
├── Diariamente → Sample de requests reales con LLM-as-judge
│
└── Al recibir feedback negativo → Investigar con métricas

Terminología Clave del Módulo

Antes de avanzar, asegúrate de entender estos términos:

Roadmap del Módulo 7

Herramientas del Ecosistema

Para contexto, estas son las herramientas existentes en el ecosistema de evaluación de LLMs:

En este módulo construiremos nuestro propio framework para entender los fundamentos. Eso te permite luego usar cualquier herramienta del ecosistema con comprensión profunda.

El Costo de No Evaluar

Una reflexión final antes de profundizar:

Sistema LLM sin evaluación en producción:
→ Tarda semanas o meses en detectar degradación de calidad
→ No puede probar que una mejora es real (o que no es regresión)
→ Cada cambio de prompt es un salto de fe
→ Los usuarios descubren los bugs antes que el equipo
→ Imposible responder: "¿qué tan bien funciona esto?"

Sistema LLM con evaluación:
→ Detecta regresiones en minutos (en CI/CD)
→ Puede medir y probar mejoras objetivamente
→ Cada deploy viene con datos, no con esperanza
→ Dashboard en tiempo real de calidad en producción
→ Puede responder: "Accuracy 94%, faithfulness 0.91, p95 < 2.1s"

La evaluación sistemática es lo que separa los proyectos LLM de producción de los prototipos. Este módulo te da las herramientas para construirla.

Ejercicios

Ejercicio 1: Diagnóstico de tu sistema actual

Reflexiona sobre el último sistema LLM que construiste o en el que trabajaste. Responde:

1. ¿Tenías un golden set de ejemplos?
2. ¿Sabías la accuracy del sistema?
3. ¿Podías detectar regresiones automáticamente?

Ejercicio 2: Primer golden set mínimo viable

Crea un golden set de 10 ejemplos para un clasificador de sentimiento básico:

# Tu tarea: crear esta estructura
golden_set = [
    # 7 happy path (frases claramente positivas/negativas)
    # 2 edge cases (neutras, ambiguas)
    # 1 adversarial (intentando confundir al clasificador)
]

golden_set = [
    # Happy path - positivos
    {"input": "Me encanta este producto, superó mis expectativas", "expected_output": "POSITIVO"},
    {"input": "Excelente servicio al cliente, muy recomendable", "expected_output": "POSITIVO"},
    {"input": "La calidad es increíble para el precio", "expected_output": "POSITIVO"},
    {"input": "Llegó rápido y en perfectas condiciones", "expected_output": "POSITIVO"},
    
    # Happy path - negativos
    {"input": "Terrible experiencia, no lo recomiendo", "expected_output": "NEGATIVO"},
    {"input": "Se rompió al primer uso, muy decepcionante", "expected_output": "NEGATIVO"},
    {"input": "El servicio fue pésimo y la espera horrible", "expected_output": "NEGATIVO"},
    
    # Edge cases
    {"input": "El producto llegó, lo usé una vez", "expected_output": "NEUTRO"},
    {"input": "No está mal, pero tampoco es lo mejor", "expected_output": "NEUTRO"},
    
    # Adversarial
    {"input": "No es malo, pero tiene problemas graves de calidad", "expected_output": "NEGATIVO"},
]

Ejercicio 3: Calcular el costo de no medir

Si tienes un sistema que procesa 10,000 requests/día y el 8% falla silenciosamente:

1. ¿Cuántos usuarios afectados por día?
2. Si cada usuario vale $10/mes en LTV, ¿cuánto vale detectar este problema en 1 día vs 30 días?

requests_dia = 10_000
tasa_fallo = 0.08
usuarios_afectados_dia = requests_dia * tasa_fallo  # 800

ltv_usuario = 10  # $10/mes ≈ $0.33/día

# Costo de detectar tarde:
# 30 días × 800 usuarios × $0.33/día = $7,920 en LTV erosionado
# Sin contar daño de reputación, churn, etc.

costo_30_dias = 30 * usuarios_afectados_dia * (ltv_usuario / 30)
print(f"Usuarios afectados: {usuarios_afectados_dia}/día")
print(f"Costo de no detectar en 30 días: ${costo_30_dias:,.0f}")
# → $7,920 — y ese es el cálculo conservador

Resumen

• Evaluation: Métricas objetivas, no vibes — la diferencia entre prototipos y sistemas de producción
• Tres capas: Automatizada (rápida), LLM-as-judge (profunda), humana (calidad)
• Golden sets: Inputs + expected outputs = la base de toda evaluación
• Regression: Detectar automáticamente cuando algo se rompe
• A/B testing: Comparar versiones con datos estadísticos, no intuición
• Timing: Evaluar siempre: al crear, al modificar, antes de deploy, en producción

Prerequisitos del Módulo

Antes de continuar, asegúrate de estar cómodo con:

• Python básico: Funciones, diccionarios, listas, f-strings
• OpenAI SDK: from openai import OpenAI, client.chat.completions.create()
• JSON parsing: json.loads(), json.dumps() para manejar outputs estructurados
• Pydantic (recomendado): Para validar schemas de golden sets y resultados
• Estadística básica: Media, porcentaje, desviación estándar — no necesitas ser un estadístico, pero debes poder calcular accuracy y entender qué es significancia estadística

Si vienes del Módulo 06, ya tienes todo lo necesario. Los pipelines que construiste ahí son exactamente lo que evaluarás aquí.

Preguntas Frecuentes

¿Necesito un golden set enorme para empezar? No. 50-100 ejemplos bien seleccionados son suficientes para detectar regresiones significativas. Lo importante es que cubran happy paths, edge cases y ejemplos adversariales. La Cápsula 04 te enseña a construirlos sistemáticamente.

¿LLM-as-judge es confiable? Es sorprendentemente bueno para evaluar calidad general, pero tiene sesgos conocidos (prefiere respuestas más largas, puede ser auto-complaciente). La Cápsula 03 cubre estos sesgos y cómo mitigarlos. La mejor práctica es usar LLM-as-judge como capa intermedia y validar periódicamente con evaluación humana.

¿Puedo integrar esto en CI/CD? Sí, y deberías. La Cápsula 05 muestra cómo crear regression tests que corren automáticamente en tu pipeline de CI/CD. Un cambio de prompt no se despliega si las métricas caen por debajo del baseline.

Recursos adicionales

1. OpenAI Evals — Framework de evaluación de OpenAI
2. LangSmith — Plataforma de observabilidad para LLMs
3. Ragas — Evaluación específica para sistemas RAG
4. HELM: Holistic Evaluation of Language Models — Benchmark comprehensivo
5. Evaluation of LLMs (Survey) — Paper académico sobre evaluation