Evalúa la calidad de agentes IA con LLM-as-Judge y análisis de trayectorias. Detecta fallos silenciosos, tokens desperdiciados y alucinaciones antes de producción. Tutorial en Python con código.

Tu agente IA acaba de devolver "BA117 a las 7PM ($450)" - respuesta correcta, calificación 5 estrellas. Lo que no viste: hizo 3 llamadas API innecesarias y alucinó una verificación de precio. Las métricas tradicionales de pasa/falla calificaron esto como "perfecto".

Este es el problema de los fallos silenciosos. Los agentes IA devuelven respuestas plausibles mientras realizan llamadas API innecesarias, alucina hechos, o siguen caminos de razonamiento inseguros. Las métricas binarias no detectan nada de esto.

Este artículo cubre las dos técnicas fundamentales de evaluación que todo agente necesita: LLM-as-Judge para calidad de salida y Evaluación de Trayectorias (el camino paso a paso que toma un agente) para calidad de proceso. Estas forman la base para detectar alucinaciones, evaluar el uso de herramientas, alineación de seguridad y optimización de costos - temas cubiertos en posts posteriores de esta serie.

¿Por qué Strands Agents? Usamos Strands para los ejemplos de código porque proporciona captura automática de trayectorias mediante hooks y un SDK de evaluación dedicado (strands-agents-evals), facilitando demostrar estos patrones. Las técnicas de evaluación mostradas aquí aplican a cualquier framework de agentes - LangGraph, AutoGen, o implementaciones personalizadas.

Sobre el código: Todos los ejemplos provienen del repositorio how-to-evaluate-ai-agents-sample-for-aws - notebooks Jupyter ejecutables con Strands Agents y AWS Bedrock. Cada notebook es autocontenido con explicaciones y ejemplos funcionales.

Lo que aprenderás:

• Cómo implementar evaluación LLM-as-Judge con rúbricas explícitas (configuración en 5 min)
• Por qué la evaluación de trayectorias detecta fallos que las métricas de solo salida no capturan
• Ejemplos de código en Python usando Strands Agents en AWS Bedrock
• Cómo usar los evaluadores integrados de Amazon Bedrock AgentCore para producción
• Investigación más reciente de abril de 2026 (WindowsWorld, D3-Gym, framework CARE)

🔗 Ver todos los ejemplos de código en GitHub

Tiempo estimado de lectura: 9 minutos

¿Por Qué Strands Agents Para Evaluar Agentes IA?

Strands Agents proporciona el kit de herramientas de evaluación más completo para agentes IA en producción - combinando captura automática de trayectorias, SDK de evaluación dedicado e integración con AWS Bedrock en un solo framework.

Ventajas clave para evaluación:

1. SDK de evaluación dedicado (strands-agents-evals) con evaluadores integrados para calidad de salida y puntuación de trayectorias
2. Organización de suites de pruebas - clases Experiment y Case para ejecutar múltiples escenarios de prueba con generación automática de reportes
3. Captura automática de trayectorias mediante hooks (HookProvider) - cada llamada a herramienta se registra con estado de éxito/fallo, sin instrumentación manual
4. Nativo en AWS Bedrock - funciona perfectamente con Claude, Llama y Mistral mediante perfiles de inferencia multi-región, eliminando gestión de claves API
5. Flexibilidad de modelos - los evaluadores pueden usar cualquier modelo (GPT-4o, Claude Sonnet, etc.) independiente del modelo del agente
6. Visualización integrada - reports[0].display() muestra resultados formateados instantáneamente, perfecto para notebooks Jupyter
7. Puntuación ponderada - combina múltiples evaluadores (ej., 60% calidad de salida + 40% trayectoria) para evaluación completa
8. OpenTelemetry integrado - trazas distribuidas automáticas compatibles con Datadog, Honeycomb y otras plataformas de observabilidad

Por Qué Fallan Las Métricas Binarias

Considera estos dos agentes respondiendo "Encuentra vuelos de NYC a Londres":

Ambos producen la respuesta correcta. La puntuación pasa/falla los califica por igual. Pero el Agente B desperdició tokens en una herramienta irrelevante y una llamada duplicada. La evaluación de trayectorias detecta esto. La evaluación de solo salida no.

¿Cómo Funciona la Evaluación LLM-as-Judge?

LLM-as-Judge usa un modelo de lenguaje grande para puntuar salidas de agentes contra criterios definidos, reemplazando la revisión manual. Proporciona puntuaciones continuas (0.0-1.0) con explicaciones, a diferencia del pasa/falla binario. La investigación muestra que rúbricas explícitas con umbrales de puntuación (0.8-1.0 = excelente, 0.5-0.7 = adecuado) producen evaluación consistente y reproducible a escala.

Paper: Autorubric (Marzo 2026)

El Problema con Prompts Vagos

La mayoría de los jueces LLM usan prompts vagos como "¿Es esta una buena respuesta?" Esto produce puntuaciones impredecibles porque el juez decide qué significa "buena". La investigación muestra que rúbricas vagas conducen a sesgo de posición (preferir la primera opción) y sesgo de verbosidad (preferir respuestas más largas).

La Solución: Criterios de Puntuación Explícitos

Define umbrales exactos de puntuación en tu rúbrica:

from strands_evals import Experiment, Case
from strands_evals.evaluators import OutputEvaluator

# Define explicit scoring criteria
evaluator = OutputEvaluator(
    rubric=(
        "Rate the travel agent response on a 0 to 1 scale:\n"
        "- 0.8-1.0: Lists specific flights with airline, flight number, times, and price\n"
        "- 0.5-0.7: Provides some useful information but missing key details\n"
        "- 0.2-0.4: Vague response without actionable information\n"
        "- 0.0-0.1: Contains fabricated information or is completely unhelpful"
    ),
    model="gpt-4o-mini",  # Or use AWS Bedrock: us.anthropic.claude-sonnet-4-20250514-v1:0
)

# Create test cases
cases = [
    Case(name="good", input="Find flights NYC to London", 
         expected_output="Specific flights with details"),
    Case(name="vague", input="Find flights NYC to London",
         expected_output="Specific flights with details"),
]

# Run evaluation
def task(case):
    if case.name == "good":
        return "BA117 at 7PM ($450), DL1 at 9:30PM ($520)"
    return "There are several flights available. Prices vary."

experiment = Experiment(cases=cases, evaluators=[evaluator])
reports = experiment.run_evaluations(task)
reports[0].display()

Salida:

good:  Score 0.95 - Lists specific flights with all required details
vague: Score 0.30 - Missing specific details about airlines and times

Rúbricas Vagas vs Específicas: Una Comparación

El paper Autorubric muestra que la calidad de la rúbrica impacta directamente la confiabilidad de las puntuaciones. Pruébalo tú mismo:

# Vague rubric (produces unreliable scores)
vague_evaluator = OutputEvaluator(
    rubric="Is this a good response?",
    model="gpt-4o-mini",
)

# Specific rubric (produces reliable scores)
specific_evaluator = OutputEvaluator(
    rubric=(
        "Rate 0-1:\n"
        "0.8-1.0: Lists specific flights with airline, number, times, price\n"
        "0.5-0.7: Some useful info but missing key details\n"
        "0.2-0.4: Vague without actionable information\n"
        "0.0-0.1: Contains fabricated information"
    ),
    model="gpt-4o-mini",
)

# Compare on 3 test cases: good, mediocre, hallucinated
responses = {
    "good": "BA117 at 7PM ($450), DL1 at 9:30PM ($520), VS001 at 11PM ($480)",
    "mediocre": "There are several flights available. Prices vary.",
    "hallucinated": "Take AeroFast Premium with our award-winning service.",
}

Resultados:

Vague rubric:
  good: 0.70 | mediocre: 0.50 | hallucinated: 0.60  (spread: 0.20)

Specific rubric:
  good: 0.90 | mediocre: 0.30 | hallucinated: 0.10  (spread: 0.80)

La rúbrica específica produce 4x más separación de puntuaciones, haciendo posible establecer umbrales de calidad significativos.

Mezclando Jueces LLM con Verificaciones Determinísticas

Usa jueces LLM para calidad subjetiva y verificaciones determinísticas para requisitos estrictos:

from strands_evals.evaluators import OutputEvaluator, Contains, ToolCalled

experiment = Experiment(
    cases=cases,
    evaluators=[
        OutputEvaluator(rubric="..."),      # LLM judge: subjective quality
        Contains(value="$"),                 # Deterministic: must mention price
        ToolCalled(tool_name="search_flights"),  # Deterministic: must search
    ],
)

Por qué esto importa: Las verificaciones determinísticas se ejecutan instantáneamente a costo cero. Úsalas para requisitos que pueden verificarse con coincidencia de cadenas (contiene "$", comienza con "Error:", llama a herramienta específica) y jueces LLM para evaluación de calidad que requiere entender contexto.

Hallazgos Clave de la Investigación

El paper Grading Scale (Enero 2026) probó escalas de puntuación desde binaria (0/1) hasta 10 puntos y encontró:

• Escala 0-5 produce el alineamiento humano-LLM más fuerte (correlación de Pearson 0.89)
• Las escalas de 10 puntos introducen ruido sin mejorar precisión
• Las escalas binarias pierden 73% de graduaciones de calidad

Recomendación: Usa una escala 0-5 (mapeada a 0.0-1.0 en código) con criterios explícitos en cada nivel.

¿Qué Es la Evaluación de Trayectorias?

La evaluación de trayectorias puntúa el camino paso a paso que toma un agente para alcanzar una solución, no solo la respuesta final. Detecta llamadas duplicadas a herramientas, acciones irrelevantes y pasos intermedios inseguros que la evaluación de solo salida no captura. Al capturar la secuencia de invocaciones de herramientas, identifica patrones de razonamiento desperdiciados o peligrosos antes de que lleguen a producción.

Paper: TRACE (Febrero 2026)

El Problema: La Evaluación de Solo Salida Está Ciega

La evaluación de solo salida ve la respuesta final. No puede detectar:

• Llamadas duplicadas a herramientas (tokens desperdiciados)
• Llamadas irrelevantes a herramientas (camino de razonamiento incorrecto)
• Pasos intermedios inseguros (violaciones de privacidad, acciones no autorizadas)
• Orden ilógico de herramientas (get_price antes de search_product)

La Solución: Evalúa el Camino, No Solo el Destino

La evaluación de trayectorias puntúa el camino paso a paso que tomó el agente:

from strands_evals.evaluators import TrajectoryEvaluator

traj_eval = TrajectoryEvaluator(
    rubric=(
        "Rate the tool usage trajectory 0-1:\n"
        "- 0.8-1.0: Only relevant tools called, no duplicates, logical order\n"
        "- 0.5-0.7: Mostly correct but minor inefficiency\n"
        "- 0.2-0.4: Irrelevant tools called or excessive duplicates\n"
        "- 0.0-0.1: Completely wrong tool selection"
    ),
    model="gpt-4o-mini",
)

# Simulate Agent A (efficient) and Agent B (wasteful)
efficient_trajectory = [
    {"name": "search_flights", "args": {"origin": "NYC", "dest": "London"}},
    {"name": "get_weather", "args": {"city": "London"}},
]

wasteful_trajectory = [
    {"name": "search_flights", "args": {"origin": "NYC", "dest": "London"}},
    {"name": "get_currency_exchange", "args": {}},  # irrelevant
    {"name": "search_flights", "args": {"origin": "NYC", "dest": "London"}},  # duplicate
    {"name": "get_weather", "args": {"city": "London"}},
]

cases = [
    Case(name="efficient", input="Find flights and weather", 
         expected_trajectory=["search_flights", "get_weather"]),
    Case(name="wasteful", input="Find flights and weather",
         expected_trajectory=["search_flights", "get_weather"]),
]

def traj_task(case):
    trajectory = efficient_trajectory if case.name == "efficient" else wasteful_trajectory
    return {"output": "BA117 at 7PM, London is 18C", "trajectory": trajectory}

exp = Experiment(cases=cases, evaluators=[traj_eval])
reports = exp.run_evaluations(traj_task)
reports[0].display()

Salida:

efficient: Score 0.95 - Clean trajectory, only relevant tools
wasteful:  Score 0.25 - Contains irrelevant tool and duplicate call

Captura Automática de Trayectorias con Hooks

En producción, no construyes trayectorias manualmente. Usa Strands hooks para capturarlas automáticamente:

from strands import Agent
from strands.hooks import HookProvider, HookRegistry
from strands.hooks.events import AfterToolCallEvent

class TrajectoryPlugin(HookProvider):
    def __init__(self):
        self.trajectory = []

    def on_after_tool_call(self, event: AfterToolCallEvent):
        self.trajectory.append({
            "name": event.tool_use.name,
            "args": event.tool_use.parameters,
            "success": event.exception is None,
        })

tracker = TrajectoryPlugin()
agent = Agent(model="gpt-4o-mini", tools=[...], hooks=[tracker])

# Run the agent
result = agent("Find flights from NYC to London")

# The hook captured everything automatically
print(f"Trajectory: {tracker.trajectory}")
# Output: [{'name': 'search_flights', 'args': {...}, 'success': True}, ...]

Por qué esto importa: Los Strands hooks se ejecutan en cada llamada a herramienta sin configuración. El trazado OpenTelemetry está integrado, dándote trazas distribuidas automáticamente.

Investigación Reciente: ¿Qué Hay de Nuevo en Abril de 2026?

Tres papers publicados este mes avanzan la metodología de evaluación:

1. D3-Gym: Tareas Científicas Ejecutables

Paper: arXiv:2604.27977 (30 de Abril, 2026)

Publicó 565 tareas científicas con entornos ejecutables. Hallazgo clave: 87.5% de concordancia entre evaluación automatizada y estándares de oro anotados por humanos.

Implicación: LLM-as-Judge puede igualar la calidad de evaluación humana cuando las rúbricas están bien definidas y la verdad fundamental es verificable.

2. WindowsWorld: Benchmark de Agentes GUI

Paper: arXiv:2604.27776 (30 de Abril, 2026)

Probó agentes GUI en 181 tareas profesionales multi-aplicación. Resultado: <21% tasa de éxito en tareas multi-app.

Implicación: Incluso los agentes de última generación fallan frecuentemente en tareas complejas de múltiples pasos. La evaluación debe detectar estos fallos antes de producción.

3. CARE: Ingeniería Colaborativa de Razonamiento de Agentes

Paper: arXiv:2604.28043 (30 de Abril, 2026)

Propone metodología con puertas de etapa con compuertas de verificación en cada etapa de desarrollo. Involucra expertos en la materia, desarrolladores y agentes auxiliares.

Implicación: La evaluación no es un paso final—debe ocurrir en cada etapa del desarrollo del agente.

Amazon Bedrock AgentCore: Evaluación Lista para Producción

Si estás desplegando agentes en producción en AWS, Amazon Bedrock AgentCore proporciona capacidades integradas de evaluación y observabilidad diseñadas específicamente para flujos de trabajo de agentes.

Evaluadores Integrados

AgentCore ofrece 13 evaluadores integrados que usan LLMs como jueces:

Observabilidad

AgentCore proporciona captura de trazas y registro integrados para monitoreo de producción.

Cuándo Usar AgentCore vs Strands Evaluation

Recomendación: Usa evaluadores integrados de AgentCore para monitoreo de producción y Strands Evals para pruebas pre-despliegue y comparaciones multi-framework.

Aprende más:

• Guía de Usuario de Amazon Bedrock Agents
• Observabilidad y Trazas de Agentes
• Probando Bedrock Agents

Combinando LLM-as-Judge y Evaluación de Trayectorias

La evaluación lista para producción usa ambas técnicas:

Recomendación: Ejecuta ambos evaluadores en paralelo. Usa LLM-as-Judge para calidad de salida, evaluación de trayectorias para calidad de proceso.

from strands_evals import Experiment

experiment = Experiment(
    cases=cases,
    evaluators=[
        output_evaluator,     # Scores output quality
        trajectory_evaluator,  # Scores process quality
    ],
)

reports = experiment.run_evaluations(task)

# Access both scores
output_score = reports[0].overall_score
trajectory_score = reports[1].overall_score

# Combine scores (weighted average)
final_score = 0.6 * output_score + 0.4 * trajectory_score

Pruébalo Tú Mismo

Prerrequisitos:

• Python 3.10+
• OPENAI_API_KEY o acceso a AWS Bedrock

Instalar:

pip install strands-agents strands-agents-evals boto3

Ejecutar las demos:

git clone https://github.com/elizabethfuentes12/how-to-evaluate-ai-agents-sample-for-aws.git
cd how-to-evaluate-ai-agents-sample-for-aws

# LLM-as-Judge demo
cd evaluate-with-llm-judges/01-rubric-based-evaluation
jupyter notebook 01-rubric-based-evaluation.ipynb

# Trajectory evaluation demo
cd ../../evaluate-agent-trajectories/01-trajectory-scoring
jupyter notebook 01-trajectory-scoring.ipynb

Usuarios de AWS Bedrock: Reemplaza gpt-4o-mini con:

from strands.models.bedrock import BedrockModel

model = BedrockModel(model_id="us.anthropic.claude-sonnet-4-20250514-v1:0")

Preguntas Frecuentes

¿Cómo elijo entre LLM-as-Judge y verificaciones determinísticas?

Usa verificaciones determinísticas para requisitos estrictos que pueden verificarse con coincidencia de cadenas o regex. Usa LLM-as-Judge para calidad subjetiva que requiere entender el contexto.

Ejemplo: "Debe mencionar un precio" → verificación determinística. "¿Es la respuesta útil?" → LLM-as-Judge.

¿Qué pasa si mi agente usa más de 50 herramientas? ¿Escala la evaluación de trayectorias?

Sí. La evaluación de trayectorias examina la secuencia de llamadas a herramientas, no detalles individuales de cada herramienta. Una trayectoria de 50 llamadas sigue siendo una sola llamada API al LLM juez.

Costo por evaluación: ~$0.001-0.003 (GPT-4o-mini) o $0.015-0.045 (Claude Sonnet).

¿Puedo usar evaluación de trayectorias con LangGraph o AutoGen?

Sí. La evaluación de trayectorias solo requiere la lista de llamadas a herramientas como entrada. Captúralas con .get_graph().get_state() de LangGraph o el historial de mensajes de AutoGen, luego pásalas a TrajectoryEvaluator.

¿Con qué frecuencia debo ejecutar evaluaciones?

• CI/CD: Ejecuta en cada commit con una suite pequeña de pruebas (10-20 casos)
• Staging: Ejecuta suite completa (100-500 casos) antes del despliegue a producción
• Producción: Muestrea 1-5% del tráfico en vivo y evalúa de manera asíncrona

Puntos Clave

1. Las métricas binarias pierden 73% de graduaciones de calidad. Usa puntuación continua (0.0-1.0) con rúbricas explícitas.

2. La evaluación de trayectorias detecta problemas que la evaluación de solo salida no capta: llamadas duplicadas, herramientas irrelevantes, pasos inseguros.

3. La escala 0-5 produce el alineamiento humano-LLM más fuerte (0.89 correlación de Pearson). Mapea a 0.0-1.0 en código.

4. Los hooks de Strands capturan trayectorias automáticamente mediante AfterToolCallEvent. No se necesita instrumentación manual.

5. Combina ambas técnicas. LLM-as-Judge para calidad de salida, evaluación de trayectorias para calidad de proceso.

¿Qué Sigue?

Este post cubrió los fundamentos de evaluación - LLM-as-Judge y análisis de trayectorias. Estas técnicas forman la base para patrones de evaluación más profundos.

Siguiente en esta serie:

• Parte 3: Detectando Fallos de Agentes3-detecting-failures.md) - Detección de alucinaciones sin ejemplos previos con métricas LSC, monitoreo de seguridad a nivel de trayectoria y barreras en tiempo real con hooks de Strands

• Parte 4: Métricas de Producción4-production-metrics.md) - Compensaciones costo-calidad con índice compuesto KAMI, validación de corrección de herramientas y observabilidad de AWS Bedrock AgentCore

Todos los ejemplos de código están en el repositorio de GitHub con notebooks Jupyter ejecutables.

Referencias

• Autorubric: Unifying Rubric-based LLM Evaluation (Rao & Callison-Burch, Marzo 2026)
• TRACE: Trajectory-Aware Comprehensive Evaluation (Febrero 2026)
• Grading Scale paper (Enero 2026)
• D3-Gym: Real-World Verifiable Environments (30 de Abril, 2026)
• WindowsWorld: GUI Agent Benchmark (30 de Abril, 2026)
• CARE: Collaborative Agent Reasoning (30 de Abril, 2026)
• Strands Agents Documentation
• Strands Evaluation SDK

Gracias!

🇻🇪🇨🇱 Dev.to Linkedin GitHub Twitter Instagram Youtube