Cómo evaluar agentes de IA: frameworks, métricas y errores comunes

En 2026 construir un agente es relativamente barato. Saber si funciona bien, no. Los equipos que han llevado agentes a producción coinciden en algo: lo que mata un agente no es la primera demo, es el segundo mes en producción, cuando un cambio sutil en el prompt o el modelo rompe casos que antes funcionaban — sin que nadie lo note.

La disciplina que ataca esto es evaluation o eval. Esta guía explica qué medir, qué frameworks usar, y los errores que dejan a los equipos volando a ciegas. Encaja en el cluster Agentes de IA.

Por qué los agentes son distintos a chatbots para evaluar

Un chatbot es input → output. Mides una sola respuesta.

Un agente es input → trayectoria de decisiones → output. La misma pregunta puede recorrer 5 caminos distintos. Tienes que evaluar:

1. El output final (¿es correcto?).

2. La trayectoria (¿usó las tools adecuadas?, ¿las usó en orden razonable?).

3. Los costes (¿cuántos tokens?, ¿cuántas iteraciones?, ¿cuánto tardó?).

4. La fiabilidad (si lo corres 10 veces, ¿cuántas veces acierta?).

Esto multiplica la complejidad del eval frente a un chatbot. Y por eso los frameworks de eval para agentes son distintos a los de eval clásicos.

Qué medir: las 5 dimensiones

1. Task success rate

¿El agente completa la tarea?

Métrica binaria (1 = éxito, 0 = fallo) o por niveles (éxito completo, parcial, fallo). Necesitas un dataset de tareas con criterio claro de "éxito".

Para tareas con output verificable (código que pasa tests, JSON que valida un schema) → automático.

Para tareas subjetivas (calidad de un informe) → LLM-as-judge o anotación humana.

2. Trajectory quality

¿El agente tomó decisiones razonables?

Métricas:

• Tool selection precision: ¿llamó a las tools correctas?

• Step efficiency: ¿lo hizo en pocos pasos o dio rodeos?

• Order correctness: ¿el orden tiene sentido?

Esto se mide comparando la trayectoria del agente con una "reference trajectory" o usando un LLM-as-judge que califica el camino.

3. Cost

Tokens consumidos por tarea. Crítico porque agentes con bucles infinitos o context bloating queman presupuesto.

Métricas:

• Tokens medios por tarea.

• Coste medio por tarea.

• p95 / p99 de coste (los outliers que rompen budget).

4. Latency

Tiempo total y por turno.

Para agentes user-facing: p50 y p95 importan más que la media.

5. Reliability / determinism

Corre la misma tarea N veces. ¿Cuántas veces acierta? ¿Cuánta varianza hay en el output?

Métrica útil: pass@k (de k intentos, ¿cuántos pasan?). Tomada de SWE-bench y similares.

Eval offline vs online

Offline eval

Tienes un dataset fijo de tareas con resultados esperados. Corres el agente, comparas. Repetible, controlable.

Útil para:

• Regresiones: cuando cambias prompt o modelo, ¿se mantiene el rendimiento?

• CI/CD gates: bloquear deploy si el score baja.

• Comparar modelos: Sonnet vs Opus, GPT-5.5 vs Claude Opus 4.7.

Limitación: el dataset envejece. Casos reales que aparecen en producción pueden no estar cubiertos.

Online eval

Mides el agente en producción real. Capturas trazas, anotas, generas alertas.

Útil para:

• Detectar drift (el agente empieza a fallar más con tiempo).

• Casos nuevos que no estaban en el dataset offline.

• Feedback de usuario (thumbs up/down, encuestas).

Limitación: lento, ruidoso, requiere infraestructura.

Buena práctica: ambos. Offline en CI, online en producción, y el feedback de online alimenta nuevas filas del dataset offline.

Frameworks de eval para agentes en 2026

LangSmith

Parte del ecosistema LangChain. Tracing automático para agentes LangChain / LangGraph. Datasets de eval, anotación humana, prompt versioning, LLM-as-judge.

Cuándo elegir: si tu agente está construido con LangChain o LangGraph. La integración es nativa, el tracing es gratis.

Limitación: si no usas LangChain, la instrumentación es manual. Y el plan no es barato a escala.

langsmith.com

Braintrust

Foco en eval rigurosa. Datasets, scorers (pre-built y custom), comparación de experimentos lado a lado, CI/CD gates.

Cuándo elegir: si trabajas multi-framework (Claude SDK + LangGraph + custom), necesitas que el eval gate tu CI/CD, y quieres prompt optimization automático.

Limitación: curva más pronunciada que LangSmith.

braintrust.dev

Langfuse

Open-source. Tracing + evaluation. Self-host o cloud.

Cuándo elegir: quieres open-source, control total, posibilidad de self-host (data residency en EU si es requirement RGPD), o presupuesto cero.

Limitación: menos features pulidos que las opciones comerciales. El eval automático es más DIY.

langfuse.com

Latitude

Plataforma agent-first (no solo LLM-only). Evaluations específicas para agentes con tools.

Cuándo elegir: agentes complejos con muchos tools donde necesitas evaluar trajectory en detalle.

latitude.so

Arize Phoenix / OpenInference

Open-source, basado en OpenTelemetry. Compatible con cualquier framework que emita trazas OTel.

Cuándo elegir: ya tienes stack de observabilidad OTel y quieres añadir LLM/agent evals encima.

arize.com/phoenix

Comparativa rápida

LLM-as-judge: cómo usarlo bien

Para tareas subjetivas (calidad de respuesta, fidelidad a brand voice, completitud), un LLM evalúa otro LLM. Funciona razonablemente, con cuidado.

Buenas prácticas

1. Modelo evaluador distinto al evaluado. Si Claude genera, OpenAI evalúa (o viceversa). Reduce sesgo.

2. Rubric explícito. No "evalúa la calidad". Sí: "puntúa 1-5 según: precisión técnica (1-5), claridad (1-5), completitud (1-5)".

3. Few-shot examples. Da 3-5 ejemplos de outputs y sus puntuaciones esperadas.

4. Calibrar contra humanos. Anota 50-100 ejemplos con humanos. Compara con el LLM-judge. Si correlación >0.7, el judge es usable.

Errores típicos

• Self-evaluation bias: el mismo modelo se da notas mejores. Evita usar el modelo evaluado como judge.

• Position bias: en comparaciones A vs B, los modelos prefieren la primera opción. Aleatoriza el orden.

• Length bias: respuestas más largas reciben mejores notas. Pide al judge que ignore la longitud explícitamente.

Errores comunes que hunden el eval

"Eval con 10 ejemplos"

10 es demasiado poco. Una mejora de 1 punto puede ser ruido. Mínimo 50 ejemplos para señales fiables. Para producción, 200-500.

"Solo medimos task success"

Mides 1 cosa, ignoras 4. Un agente con 90% success y coste 10x del aceptable es un fracaso operacional, no un éxito.

"Eval solo cuando lanzamos algo"

El modelo cambia, las APIs cambian, el contexto cambia. Eval automatizado en CI para cada PR; eval scheduled diario en producción para detectar drift.

"El dataset es el de hace 6 meses"

Producción genera casos nuevos cada día. Un dataset estático envejece. Buena práctica: incorporar 5-10 casos nuevos cada semana desde producción real (con anonimización).

"Confiamos en LLM-as-judge sin calibrar"

LLM-judge sin calibración humana puede dar números bonitos que no correlacionan con calidad real. Anota humano una vez al mes y verifica.

"No medimos coste"

Un agente con context engineering malo crece en coste mes a mes silenciosamente. Sin medir cost p95, no lo detectas hasta que llega la factura.

Plan mínimo de eval

Si arrancas hoy, este es el plan razonable:

1. Crea un dataset de 50 tareas representativas de tu agente. Cada tarea con criterio de éxito claro.

2. Define 3-4 scorers:

   • Task success (binario o nivel).

   • Tool usage (¿llamó a las tools correctas?).

   • Cost (tokens consumidos).

   • LLM-judge para calidad subjetiva si aplica.

3. Engancha en CI: cada PR corre el eval. Si el score baja, bloqueo o aviso.

4. Tracing en producción (Langfuse self-host o Braintrust SaaS).

5. Revisión semanal de trazas: 20 muestras al azar, anota fallos, añade casos al dataset.

6. Alert de drift: si el score offline baja >5% entre runs, alerta a Slack.

Con esto cubres 80% del valor. El otro 20% (annotation queues, prompt optimization automático, A/B testing en producción) viene cuando tienes señal de que es el cuello de botella real.

Eval para agentes Claude Code y similares

Si tu agente es Claude Code o un fork, las dimensiones son:

• Task success: ¿pasa los tests al final?

• Trajectory: ¿editó solo lo necesario o tocó archivos no relacionados?

• Hooks compliance: ¿respetó los hooks configurados (linter, formatter)?

• Token budget: ¿se mantuvo bajo el límite?

Anthropic publica resultados de Claude Code en SWE-bench que sirven como referencia para tus propios benchmarks internos.

Conclusión

Sin eval, tu agente es una caja negra que va a empeorar con el tiempo sin que lo veas. Con eval básico (50 tareas + 3 scorers + CI) ya estás en el top 20% de equipos que ponen agentes en producción seriamente.

El error principal de 2026 no es elegir el framework de eval equivocado — es no implementar ninguno. Cualquiera de los 5 listados (LangSmith, Braintrust, Langfuse, Latitude, Phoenix) es mejor que nada.

Para profundizar:

• Agentes de IA en 2026: guía completa — pillar.

• Context engineering explicado — disciplina central.

• LangGraph vs Claude Agent SDK — frameworks comparados.

• Cómo crear un agente con Claude — tutorial práctico.

Fuentes verificadas

• LangSmith vs Braintrust comparison — comparativa oficial.

• Best LLM observability tools 2026 (Latitude) — análisis multi-framework.

• Top AI Agent Evaluation Tools 2026 (Goodeye) — landscape completo.

• Anthropic Building Effective Agents — eval guidelines.

• Datos verificados el 28 de abril de 2026.