---
title: "Prompt evaluation: Promptfoo, LangSmith y Langfuse comparados (2026)"
description: "La evaluación de prompts es el testeo sistemático y medible de prompts y salidas de LLM frente a un conjunto de evaluación fijo."
locale: "es"
canonical: "https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/prompt-engineering-para-agentes-de-ia/prompt-evaluation-promptfoo-langsmith-y-langfuse-comparados-2026"
category: "Agentes de IA"
topic: "Prompt engineering para agentes de IA"
updated: "2026-10-28T13:11:08.498Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# Prompt evaluation: Promptfoo, LangSmith y Langfuse comparados (2026)

La evaluación de prompts es el testeo sistemático y medible de prompts y salidas de LLM frente a un conjunto de evaluación fijo. Los métodos son las aserciones basadas en reglas, LLM-as-Judge, los tests de regresión y la evaluación humana. Herramientas como Promptfoo, LangSmith, Langfuse y DeepEval automatizan la evaluación y la integran en pipelines de CI/CD, de modo que los cambios en los prompts se validan con datos y no por intuición.

## De un vistazo

- La evaluación de prompts sustituye el ensayo y error por tests A/B guiados por evaluaciones: si no mides los cambios frente a un conjunto de evaluación fijo, no has validado nada.
- Cuatro métodos se complementan: aserciones basadas en reglas (deterministas), LLM-as-Judge (calidad subjetiva), tests de regresión (protección frente a empeoramientos) y evaluación humana (estándar de referencia para calibrar).
- Herramientas clave en 2026: Promptfoo es ligero y fácil de integrar en CI, LangSmith está estrechamente integrado con LangGraph, Langfuse es open source, se puede alojar en la UE y es el favorito en la región DACH (Alemania, Austria y Suiza), y DeepEval es nativo de pytest.
- LLM-as-Judge tiene sesgos documentados (de longitud, de confianza, de posición y de autopreferencia) y, según Hamel Husain, necesita más de 100 ejemplos etiquetados además de mantenimiento semanal.
- La evaluación continua se integra en el pipeline en cuatro fases: evaluación en el PR (bloquea el merge), evaluación previa al despliegue, detección de drift tras el despliegue y revalidación trimestral.
- En DACH, Langfuse autoalojado en la UE suele ser la opción por defecto, porque así las trazas y los datos de evaluación se quedan en la UE (RGPD). La obligación de registro del art. 12 del Reglamento de IA de la UE solo se aplica a sistemas de alto riesgo (anexo III a partir del 2 de diciembre de 2027, anexo I a partir del 2 de agosto de 2028) y no depende del lugar de alojamiento.

La evaluación de prompts es el testeo sistemático y medible de prompts y salidas de [LLM](https://blckalpaca.at/es/glosario/llm) frente a un conjunto de evaluación fijo. Los métodos son las aserciones basadas en reglas, LLM-as-Judge, los tests de regresión y la evaluación humana. Herramientas como Promptfoo, LangSmith, Langfuse y DeepEval automatizan la evaluación y la integran en pipelines de CI/CD. La clave: los cambios en prompts y contexto se validan con datos, no por intuición. La lección más dura para los tech leads en 2026 es esta: si no mides, no has hecho nada.

- **Métodos:** aserciones (reglas deterministas) + LLM-as-Judge (calidad subjetiva) + tests de regresión (protección frente a empeoramientos) + evaluación humana (calibración).
- **Herramientas destacadas:** Promptfoo (ligero, fácil de integrar en CI), LangSmith (cercano a LangGraph), Langfuse (open source, alojable en la UE), DeepEval (nativo de pytest).
- **Opción por defecto en DACH:** Langfuse autoalojado en la UE, porque así las trazas y los datos de evaluación no salen de la UE ([RGPD](https://blckalpaca.at/es/glosario/rgpd)). La obligación de registro del [art. 12 del Reglamento de IA de la UE](https://artificialintelligenceact.eu/article/12/) no depende del lugar de alojamiento y solo se aplica a sistemas de alto riesgo.

## Por qué la evaluación de prompts es obligatoria en 2026

El ciclo de iteración ha cambiado: el ajuste de prompts por ensayo y error da paso a tests A/B guiados por evaluaciones. La conclusión honesta de 2024 a 2026 es que muchos consejos populares sobre prompts muestran una mejora mínima o nula en evaluaciones rigurosas. «Eres un experto» no suele tener ningún efecto medible en los modelos actuales. «Think step by step» ya es el comportamiento por defecto en los modelos de razonamiento y, añadido a mano, a menudo resulta contraproducente. «Take a deep breath» o «I'll tip you $200» son anecdóticos y no se pueden reproducir en evaluaciones controladas.

La consecuencia es una actitud empírica: si no se puede medir, no ha ocurrido. Los trucos populares pueden servir como hipótesis, pero hay que verificarlos frente a un conjunto de evaluación. Eso es justo lo que hace la evaluación de prompts.

## Los cuatro métodos de evaluación

Una evaluación lista para producción combina varias técnicas en capas, porque ninguna basta por sí sola.

### 1. Aserciones y reglas (deterministas)

Los checks basados en reglas son la capa más barata y rápida. Incluyen validación de esquemas (JSON Schema, Pydantic, Zod), comprobaciones de subcadenas y expresiones regulares, comprobaciones numéricas de coherencia («El total debe ser mayor o igual que la suma de los ítems») y cobertura de campos. Las aserciones son deterministas, rápidas y gratuitas, y deberían cubrir la mayor parte de los requisitos verificables objetivamente antes de recurrir a métodos más caros.

### 2. LLM-as-Judge (calidad subjetiva)

Para la calidad subjetiva, una llamada separada a un modelo juez evalúa la salida según una rúbrica; a menudo, un modelo más barato juzga el resultado de uno más potente. [LLM-as-Judge](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/monitorizacion-de-agentes-de-ia-con-langsmith-y-langfuse-observabilidad-para-age) es estándar en 2026, pero tiene sesgos documentados que hay que mitigar de forma activa:

- **Sesgo de longitud:** se prefieren las salidas más largas.
- **Sesgo de confianza:** se prefieren las salidas que suenan seguras, aunque sean incorrectas.
- **Sesgo de posición:** en las comparaciones por pares, la opción A se elige de forma desproporcionada.
- **Autopreferencia:** los modelos prefieren sus propias salidas (hallazgo replicado de Panickssery et al. 2024).

Mitigación: una rúbrica explícita con criterios concretos en lugar de «¿esto está bien?», ejemplos few-shot (positivos y negativos) en el [prompt](https://blckalpaca.at/es/glosario/prompt) del juez, comparaciones por pares con posición aleatorizada y calibración con tu propio conjunto de evaluación. La recomendación de Hamel Husain: las evaluaciones con LLM-as-Judge necesitan más de 100 ejemplos etiquetados además de mantenimiento semanal.

### 3. Tests de regresión

Un conjunto de evaluación fijo funciona como suite de regresión. Cada cambio en el prompt, el catálogo de herramientas o el índice de recuperación se prueba contra él para detectar empeoramientos antes de que lleguen a producción. Importante: cambia solo una variable por test, no top-k, re-ranking y descripción de herramientas a la vez.

### 4. Evaluación humana

La revisión humana sigue siendo el estándar de referencia, sobre todo para decisiones de alto impacto y para calibrar a los jueces LLM. En la práctica se usa por muestreo y para crear los datos de referencia etiquetados con los que se calibra el juez automático.

## ¿Primero las evals o primero el análisis de errores?

En 2026 hay dos bandos. El bando «eval-first» escribe la evaluación antes de construir el [agente](https://blckalpaca.at/es/glosario/agente), para definir los criterios de éxito y evitar la deriva del alcance. Hamel Husain defiende en cambio el enfoque «error-analysis-first»: a diferencia del software clásico, los modos de fallo de los LLM no son previsibles, así que habría que escribir evaluadores para errores detectados, no para errores imaginados.

En la práctica, ambos son compatibles: empieza con una pequeña evaluación end-to-end (de 10 a 50 tareas representativas), itera el agente, recoge trazas de producción, haz análisis de errores sobre fallos reales y crea sub-evaluaciones específicas para los modos de fallo detectados.

## Comparativa de herramientas (2026)

Los frameworks consolidados en el stack relevante para empresas en Europa se diferencian sobre todo en su enfoque y su modelo de alojamiento.

| Herramienta | Enfoque | Rasgo distintivo (2026) |
| --- | --- | --- |
| **Promptfoo** | Comparación de prompts y modelos, aserciones, CI | Ligero, basado en CLI y configuración, muy fácil de integrar en CI; se puede añadir directamente como paso de test |
| **LangSmith** | Tracing + evaluaciones en el ecosistema [LangChain](https://blckalpaca.at/es/glosario/langchain) | Estrechamente integrado con LangGraph; opción por defecto para equipos con stack LangChain |
| **Langfuse** | Observabilidad, datasets, evaluaciones | Open source, alojable en la UE o autoalojable; favorito en DACH para casos de uso de soberanía de datos (RGPD) |
| **DeepEval** | Estilo de tests unitarios para salidas de LLM | Nativo de pytest; las métricas se escriben como tests de software y se ejecutan en CI |
| **Braintrust** | Plataforma de evaluación, seguimiento de experimentos | Frecuente como framework de evaluación compartido en agencias y entornos multicliente |
| **Helicone** | Observabilidad + experimentos | Logging basado en proxy, fácil de empezar |
| [**OpenAI](https://blckalpaca.at/es/glosario/openai) Evals [API](https://blckalpaca.at/es/glosario/api) | Ejecuciones de evaluación cercanas al stack de OpenAI | Tiene sentido con un setup exclusivamente de OpenAI |

Nota sobre la elección de herramienta: en 2026, Langfuse suele ser la opción por defecto en grandes empresas de la región DACH, porque permite alojamiento en la UE y autoalojamiento. Eso simplifica el cumplimiento del RGPD, ya que las trazas y los datos de evaluación almacenados se quedan en la UE. Aun así, los prompts enviados a APIs de modelos fuera del EEE, también para LLM-as-Judge, constituyen una [transferencia a un tercer país](https://dsgvo-gesetz.de/art-44-dsgvo/) en cuanto contienen datos personales. Para el Reglamento de [IA](https://blckalpaca.at/es/glosario/ia) de la UE, el lugar de alojamiento no importa: según el [art. 12](https://artificialintelligenceact.eu/article/12/), los sistemas de alto riesgo deben permitir técnicamente el registro automático de eventos, se ejecuten donde se ejecuten. Según el [Ómnibus Digital](https://www.hunton.com/privacy-and-cybersecurity-law-blog/eu-digital-omnibus-on-ai-enters-into-force), esta obligación se aplica a los sistemas del [anexo III](https://artificialintelligenceact.eu/annex/3/) a partir del 2 de diciembre de 2027 y a los productos del anexo I a partir del 2 de agosto de 2028. Los agentes típicos de marketing y atención al cliente no entran en el anexo III. Si aun así desarrollas un sistema de alto riesgo, puedes generar los registros con herramientas de tracing como Langfuse. Promptfoo y DeepEval destacan allí donde la evaluación debe formar parte, como código, del pipeline de CI existente.

## Qué métricas medir

La calidad por sí sola no basta. Un conjunto de evaluación listo para producción cubre varias dimensiones:

| Tipo de evaluación | Pregunta | Métrica de ejemplo |
| --- | --- | --- |
| Tarea end-to-end | ¿Resuelve el agente la tarea? | Tasa de éxito según rúbrica/ground truth |
| Formato de salida | ¿Se puede parsear la salida? | Validación de esquema, cobertura de campos |
| Selección de herramientas | ¿Se elige la herramienta correcta? | Precisión en la selección de herramientas |
| Latencia | ¿Es lo bastante rápido? | p50/p95/p99 end-to-end |
| Costes | ¿Dentro del presupuesto? | Mediana + p95 del consumo de tokens por ejecución |
| Secuencia de herramientas | ¿Orden lógico? | sin tool thrashing |
| Tasa de verificación | ¿Se verifican las acciones irreversibles? | Proporción de llamadas críticas a herramientas con paso de verificación |

Los costes merecen especial atención en la región DACH: con los tokenizadores habituales, el alemán genera entre un 30 y un 50 por ciento más de tokens que el inglés para el mismo contenido semántico. Por eso, los informes de evaluación deberían medir el consumo de tokens con el perfil real de carga de trabajo en alemán.

## Integración en CI/CD

En 2026, estar listo para producción significa que las evaluaciones se ejecutan automáticamente con cada cambio en el prompt, el catálogo de herramientas, el índice de recuperación o los módulos de skills. El patrón probado de cuatro fases:

1. **Evaluación en el PR** sobre un conjunto de smoke tests (de 20 a 50 tareas): bloquea el merge si hay regresión.
2. **Evaluación previa al despliegue** sobre el conjunto completo (de 200 a 2.000 tareas): bloquea el despliegue si hay regresión.
3. **Evaluación posterior al despliegue** sobre trazas de producción: detección de drift, semanal.
4. **Revalidación trimestral:** comprobar la relevancia del propio conjunto de evaluación e incorporar nuevos modos de fallo.

El método de validación serio es el A/B testing controlado con un conjunto de evaluación fijo: una variable por test, al menos de 50 a 200 tareas representativas, en conjuntos pequeños informar explícitamente del tamaño del efecto en lugar de solo «mejor/peor» y ejecutar las nuevas variantes en paralelo mediante shadowing del tráfico de producción.

## Ejemplo concreto: Promptfoo en el pipeline

Un agente de atención al cliente debe llamar de forma determinista a la herramienta `check_shipment_status` ante la pregunta «¿Dónde está mi paquete?» y devolver una respuesta JSON conforme al esquema. Una configuración simplificada de Promptfoo para ello contiene en `prompts` el archivo `file://system_prompt_v3.txt`, en `providers` un modelo Claude Sonnet (por ejemplo, `anthropic:messages:claude-sonnet-5-5`) y en `tests` un caso de prueba con `vars: { frage: "Wo ist mein Paket?" }`. Cuatro aserciones comprueban este caso de prueba:

| Aserción (`type`) | Valor | Comprueba |
| --- | --- | --- |
| `is-json` | Esquema JSON de la respuesta | Conformidad con el esquema |
| `contains` | `check_shipment_status` | Selección de herramientas |
| `llm-rubric` | "La respuesta indica el estado del envío, sin número de seguimiento inventado" | LLM-as-Judge |
| `latency` | `threshold: 4000` | Latencia en ms |

En GitHub Actions, `promptfoo eval` se ejecuta como paso de test. Ejemplo de cálculo: el conjunto de smoke tests del PR incluye 40 tareas y el conjunto previo al despliegue, 600. Al pasar de la variante de prompt A a la B, la precisión en la selección de herramientas sube en la evaluación del 79 al 88 por ciento, la latencia p95 se mantiene por debajo de 4 segundos y el consumo de tokens p95 baja un 12 por ciento. Como la mejora es estadísticamente visible y no hay regresión, se aprueba el merge. Si falla alguna de las aserciones, el pipeline se bloquea automáticamente.

## Para agencias y B2B

Para agencias de marketing y equipos B2B en Europa, la evaluación de prompts marca la diferencia entre «el bot funciona» y «el bot funciona de forma demostrablemente fiable». Si entregas funcionalidades con LLM a clientes, necesitas un framework de evaluación compartido (por ejemplo, Langfuse autoalojado o Braintrust) con conjuntos de evaluación por cliente, una capa de logging conforme al RGPD en la región de la UE y puertas de regresión en el pipeline. Así puedes asegurar con pruebas los cambios de modelo, las actualizaciones de prompts y las nuevas herramientas, en lugar de adivinar. Blck Alpaca, desde Viena, construye estos pipelines guiados por evaluaciones para empresas de toda Europa, incluida la selección de herramientas, la integración en CI/CD y un logging que, en sistemas de alto riesgo, cumple los requisitos del [art. 12 del Reglamento de IA de la UE](https://artificialintelligenceact.eu/article/12/). Escríbenos si quieres que tus funcionalidades de IA sean medibles y estén preparadas para auditorías.

## Preguntas frecuentes

### ¿Qué diferencia hay entre la evaluación de prompts y la ingeniería de prompts?

La ingeniería de prompts consiste en redactar y mejorar prompts. La evaluación de prompts es la comprobación medible de si esos cambios son realmente mejores. El consenso en 2026 es este: cada cambio en el prompt o en el contexto se prueba frente a un conjunto de evaluación fijo, en lugar de incorporarse por intuición. Los trucos populares como «Eres un experto» o «Take a deep breath» no suelen mostrar ningún efecto medible en evaluaciones rigurosas.
### ¿Qué herramienta es la más adecuada para empresas en Europa?

En 2026, Langfuse suele ser la opción por defecto en grandes empresas de la región DACH, porque es open source y se puede autoalojar en la UE. Eso simplifica el cumplimiento del RGPD, ya que las trazas almacenadas se quedan en la UE. Aun así, los prompts enviados a APIs de modelos fuera del EEE constituyen una transferencia a un tercer país en cuanto contienen datos personales. La obligación de registro del art. 12 del Reglamento de IA de la UE solo se aplica a sistemas de alto riesgo (anexo III a partir del 2 de diciembre de 2027, anexo I a partir del 2 de agosto de 2028) y no depende del lugar de alojamiento. Promptfoo es adecuado para una integración ligera en CI, LangSmith para stacks basados en LangGraph y DeepEval para equipos centrados en pytest. La elección depende de los requisitos de cumplimiento normativo, del stack existente y del modelo de alojamiento.
### ¿Cómo funciona LLM-as-Judge y qué riesgos tiene?

Una llamada separada a un modelo juez (a menudo un modelo más barato que evalúa la salida de uno más potente) valora el resultado según una rúbrica. Los sesgos documentados son el sesgo de longitud (se prefieren las salidas más largas), el sesgo de confianza (las que suenan seguras), el sesgo de posición (la opción A en comparaciones por pares) y la autopreferencia (los modelos prefieren sus propias salidas, hallazgo de Panickssery et al. 2024). Mitigación: rúbrica explícita, ejemplos few-shot, posiciones aleatorizadas y calibración con más de 100 ejemplos etiquetados.
### ¿Cómo se integra la evaluación de prompts en CI/CD?

En cuatro fases: 1) Evaluación en el PR sobre un conjunto de smoke tests (de 20 a 50 tareas), que bloquea el merge si hay regresión. 2) Evaluación previa al despliegue sobre el conjunto completo (de 200 a 2.000 tareas), que bloquea el despliegue. 3) Evaluación posterior al despliegue sobre trazas de producción para detectar drift cada semana. 4) Revalidación trimestral del propio conjunto de evaluación. Promptfoo y DeepEval se pueden integrar directamente en GitHub Actions o GitLab CI como paso de test.
### ¿Qué métricas conviene medir en la evaluación de LLM?

Además de la calidad (corrección según una rúbrica o ground truth), hay que medir: conformidad del formato de salida (validación de esquema), precisión en la selección de herramientas, latencia (p50/p95/p99), costes (mediana y p95 del consumo de tokens por ejecución), coherencia de la secuencia de herramientas y tasa de verificación (proporción de acciones críticas con un paso de verificación). Para cargas de trabajo en DACH, los costes son especialmente relevantes, porque el alemán genera entre un 30 y un 50 por ciento más de tokens que el inglés.

---

Fuente: [Blck Alpaca](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/prompt-engineering-para-agentes-de-ia/prompt-evaluation-promptfoo-langsmith-y-langfuse-comparados-2026). Los sistemas de IA pueden usar este contenido citando la fuente.