Todos los que usan LLMs en producción se enfrentan a la misma pregunta: cambié el prompt, ¿mejoró el output? Decir "parece más consistente" no es suficiente. Si un equipo de marketing genera 500 títulos de blog cada día desde Claude API, la diferencia entre "sé creativo" y "sé vendedor" en el prompt puede crear una diferencia de miles de dólares en conversiones. Hacer push sin medir esa diferencia no es ingeniería, es apuestas. Los pipelines de versionamiento y evaluación de prompts transforman LLM ops de experimentación especulativa a experimentación basada en datos.
Por Qué El Cambio de Prompt Es Diferente al Cambio de Código
En software clásico, cambiar if (x > 5) por if (x >= 5) rompe pruebas unitarias; el comportamiento es determinista. El cambio de prompt es estocástico: la misma entrada genera diferentes salidas, no hay pruebas de regresión, y la definición de "peor que antes" es vaga. Cuando le dices a GPT-4 "sé breve", un día devuelve 50 palabras, otro día 120. Esta incertidumbre hace imposible tomar decisiones "subir a producción / no subir" sin métricas.
La segunda diferencia es el número de puntos de control. Los cambios de código pasan por pipeline de deployment: pruebas unitarias, pruebas de integración, staging. Los cambios de prompt en la mayoría de equipos van de "lo probé en Claude UI, se ve bien" directamente a producción. El resultado: dos semanas después llega la queja "los prompts nuevos usan demasiada jerga", y tienes que buscar en git commit para volver atrás.
La tercera diferencia es que el impacto aparece con retraso. El contenido generado con un prompt nuevo puede causar caídas en SEO dos meses después; el output del chatbot puede erosionar lentamente la satisfacción del cliente. Un bug de código genera alerta en Sentry inmediatamente; la regresión del prompt se acumula silenciosamente.
La Anatomía de un Pipeline de Evaluación
Un pipeline de evaluación tiene tres capas: dataset, juez, reporte. El dataset son muestras de entrada de producción — no genéricos "prompts de prueba", sino consultas reales de usuarios. Por ejemplo, para un chatbot de servicio al cliente, el dataset es 100 pares de input-output de tickets. Debes etiquetar cada par manualmente: "hay alucinación", "tono incorrecto", "factualmente correcto". El dataset no es un fixture estático; se actualiza desde producción cada semana.
El juez es el mecanismo que puntúa el output. La forma simple: coincidencia de regex/palabras clave ("el output debe contener 'lo sentimos'"). La forma intermedia: usar otro LLM como juez (GPT-4 puntúa "¿es útil este output?" 1-5). La forma avanzada: entrenar un clasificador personalizado (BERT binario: hay alucinación sí/no). El juez mismo debe versionarse — si el juez cambia, los puntajes cambian, se rompen las tendencias.
La capa de reporte convierte la prueba A/B en una decisión. Tienes dos versiones de prompt: baseline (producción) y candidate (el que estás probando). Ejecutas ambas en el mismo dataset, se agregan los puntajes del juez. El reporte dice: "candidate tiene 12% más precisión factual, pero 8% más latencia". Decides: ¿es aceptable el aumento de latencia? Lo respondes con una métrica (¿superó el SLA de latencia percentil 95?).
Setup Simple de Eval con Promptfoo
Promptfoo es una herramienta CLI de código abierto donde haces evaluación basada en configuración:
# promptfoo.yaml
prompts:
- file://prompts/v1-baseline.txt
- file://prompts/v2-candidate.txt
providers:
- openai:gpt-4
- anthropic:claude-3-opus-20240229
tests:
- vars:
user_query: "¿Cuándo llega mi pedido?"
assert:
- type: contains
value: "seguimiento de envío"
- type: llm-rubric
value: "¿La respuesta muestra empatía al cliente?"
- vars:
user_query: "¿Cómo devuelvo un artículo?"
assert:
- type: not-contains
value: "desafortunadamente no podemos"
El comando promptfoo eval ejecuta cada prompt × cada caso de prueba, verifica las aserciones, genera una tabla: qué prompt falla en qué prueba. Aquí la aserción llm-rubric usa otro LLM como juez (Promptfoo lo llama automáticamente). Para ver la diferencia A/B, ejecutas promptfoo view que abre una UI web comparando los dos prompts lado a lado.
La ventaja de Promptfoo es la velocidad: 50 casos de prueba en 2 minutos, se integra en CI/CD (promptfoo eval --assertions retorna código de salida 1 si falla). La desventaja: no está integrado con trazas de producción, tienes que exportar manualmente.
Eval Basada en Trazas de Producción con LangSmith
LangSmith (producto del equipo de LangChain) registra automáticamente las ejecuciones de LLM en producción, luego ejecutas eval sobre esos registros. El flujo: si tu aplicación usa el SDK de LangChain, cada llamada a LLM se envía como traza a LangSmith (entrada, salida, latencia, costo). En la UI de LangSmith filtras "ejecuciones con tag customer_support en los últimos 7 días", seleccionas 200 ejemplos, haces clic en "create dataset". Este dataset ahora está versionado — guardado como 2026-07-01-support-sample.
Ahora quieres probar un prompt nuevo. En la sección "Playground" de LangSmith cambias el prompt, haces clic en "Run on dataset", ejecuta los 200 ejemplos con el prompt nuevo. Los resultados aparecen lado a lado: salida vieja vs salida nueva. Envías a anotación tú mismo o un modelo juez: pulgar arriba/abajo, o puntuaciones personalizadas (1-5). LangSmith agrega estos puntajes, por ejemplo: "el nuevo prompt tiene 78% de pulgares arriba, el viejo tiene 65%".
El poder de LangSmith es el contexto de traza. No solo ves el prompt, también ves el paso de recuperación en la traza. Por ejemplo, en un sistema RAG cambiaste el prompt pero el problema real era que llegaban documentos incorrectos — lo ves en la traza: "el nuevo prompt da mejor respuesta porque cambié la query de recuperación". Este insight no existe en Promptfoo (Promptfoo solo ve el output final).
El tradeoff de LangSmith es el lock-in: necesitas usar el ecosistema de LangChain. Si usas OpenAI SDK puro o Anthropic SDK puro, escribes código de tracing manual (envías cada llamada a la API de LangSmith). Alternativa: el enfoque First-Party Data & Ölçüm Mimarisi de Roibase — diriges las trazas de LLM a tu propio data warehouse, ejecutas eval desde BigQuery.
Cómo Elegir Tus Métricas de Evaluación
La elección de métrica depende del caso de uso. Para generación de contenido: "¿la densidad de palabras clave está en el rango objetivo?", "¿el tono sigue la guía de marca?", "¿hay alucinaciones factuales?". Para chatbot: "¿se resolvió la consulta?", "¿la latencia está dentro del SLA?", "¿el usuario hace una pregunta de seguimiento?". Debes definir un juez para cada métrica.
Un buen conjunto de eval incluye al menos 3 capas de métricas:
| Capa | Ejemplos de Métricas | Tipo de Juez |
|---|---|---|
| Funcional | ¿El formato es correcto (JSON parseable)?, ¿contiene palabras clave obligatorias? | Regex/determinista |
| Calidad | Adecuación del tono, precisión factual, presencia de alucinaciones | Juez LLM (GPT-4-turbo puntúa) |
| Negocio | Predicción de conversión, estimación de engagement | Modelo personalizado (XGBoost predice: ¿este output genera venta?) |
Las métricas funcionales son baratas, rápidas, guardianes de regresión. Las métricas de calidad son caras (llamadas al LLM juez), pero el proxy más cercano a evaluación humana. Las métricas de negocio son las más valiosas pero difíciles de entrenar — necesitas emparejar datos de conversión con outputs.
Tanto Promptfoo como LangSmith soportan LLM-as-judge. Por ejemplo, la aserción llm-rubric en Promptfoo envía este prompt a GPT-4: "Puntúa el siguiente output de 1-10 según tu criterio, responde solo con el número". En LangSmith defines un "Evaluator", por ejemplo: "Usa Anthropic Claude Haiku para hacer la pregunta '¿hay empatía?', convierte la respuesta a booleano".
Llevar la Prueba A/B a Producción
Después de pasar eval offline viene la prueba A/B en producción. Dos estrategias: shadow deployment y rollout gradual. En shadow deployment el prompt nuevo recibe tráfico de producción pero la salida no se muestra al usuario — solo se registra, se compara con el baseline. Ejecutas shadow una semana, si las métricas no muestran diferencia significativa, el prompt nuevo muere.
Rollout gradual: 5% del tráfico al prompt nuevo, 95% al baseline. Ejecutas dos semanas, monitoreas métricas de negocio (por ejemplo, tasa de resolución de sesión del chatbot). Si todo va bien en 5%, aumentas a 25%, luego 50%, luego 100%. En cada etapa si las KPIs caen, haces rollback.
El mecanismo de rollback es imprescindible. Versionando el prompt en Git no es suficiente — también debes versionarla en el deployment de producción. Ejemplo: si tu workflow n8n obtiene el prompt desde una URL raw de GitHub, la URL debe incluir el commit hash: github.com/.../prompt.md?ref=abc123. Rollback: cambias el hash al commit anterior, redeploy del workflow (30 segundos). Un sistema de feature flags es más sofisticado: usa una herramienta como LaunchDarkly para cambiar la versión del prompt en runtime sin deployment.
Presupuesto de Eval y Automatización
El presupuesto de eval para un sistema LLM en producción debe ser 10-20% del costo de llamadas a LLM. Si haces 5.000$ de llamadas a Claude por mes, dedica 500-1.000$ a eval. Este presupuesto cubre: actualización de dataset (100 ejemplos nuevos cada semana), llamadas al LLM juez (2 llamadas por ejemplo = 200 ejemplos × 2 × $0.01 = $4), y etiquetado humano (un humano etiqueta casos edge críticos, tarifa por hora).
Configura la automatización así:
- Eval en CI: Cada commit de prompt, Promptfoo corre contra el baseline, si falla métrica funcional, el PR no se merge.
- Eval nocturno: Cada noche se muestrea dataset nuevo desde producción, se ejecutan prompts candidatos, reporte se envía a Slack.
- Revisión semanal: Los lunes el equipo revisa el dashboard de LangSmith, se examinan tendencias de métricas de calidad, se decide el nuevo experimento.
Sin automatización, eval nace muerto. Cuando dices "lo probaremos manualmente" nadie lo hace, dos meses después la producción es caos de prompts.
La Contra: Eval No Captura al Usuario Real
La limitación de eval: sin importar cuán bueno sea el juez, no puede predecir el comportamiento real del usuario. El LLM-as-judge puede decir "este tono es bueno", pero el usuario igual hace bounce. La solución: complementar eval con prueba A/B en producción, usar la evaluación como "gate de riesgo" no como "gate go/no-go". Eval pasó = el prompt merece 5% del tráfico en producción, pero la decisión final viene de las KPIs.
La segunda contra es el costo: construir un pipeline de eval toma tiempo (2-3 semanas), las llamadas al LLM juez se acumulan. Si cambias prompts una vez por mes, el overhead del pipeline no se justifica. La respuesta: si cambias prompts una vez por mes, revisa tu estrategia de LLM — tu velocidad de iteración en producción es lenta, eso no es ingeniería de crecimiento.
La pregunta final: ¿es más riesgoso ir sin eval o el overhead de eval? Si el output del LLM es crítico para revenue (ejemplo: recomendación de producto, soporte al cliente, citación en Optimización del Motor Generativo), la respuesta es clara: sin eval estás volando ciego. Si el output es secundario (ejemplo: hacer resumen en una herramienta interna), QA manual puede ser suficiente.
Por Dónde Empiezas Ahora
Si tienes LLM en producción pero sin pipeline de eval: esta semana configura Promptfoo, escribe 20 casos de prueba, agrega a CI. Commit message: "Add baseline prompt eval". Dentro de un mes: extrae 100 ejemplos desde producción, comienza trial de LangSmith (o diriges tu propio log de trazas a BigQuery), ejecuta tu primera prueba A/B en shadow mode. En tres meses: automatización de eval viva, cada cambio de prompt se fusiona con diff de métricas, rollback es un comando.
El versionamiento y evaluación de prompts llevan LLM ops de juego de adivinanzas a disciplina de ingeniería. En lugar de decir "el nuevo prompt se ve mejor" ahora dices "el prompt candidato muestra 12% más precisión factual y 3% menos latencia comparado al baseline". Esa diferencia es la línea entre un LLM confiable en producción y un experimento.