Evaluation Harness para AI Agents: El Sistema que Mide Si Tu Agent Realmente Funciona
Aprende a construir evaluation harnesses para AI agents que miden accuracy, reliability y cost. Framework de evaluación estratificada con código.
El 95% de Tus AI Agents No Saben Si Están Funcionando Bien
Tienes un agent en producción. Responde requests. Devuelve outputs. Parece que funciona.
Pero no tienes forma de saber si la mitad de sus respuestas son basura.
La mayoría de developers despliega AI agents sin evaluación sistemática. Confían en "ya lo veremos si falla". Confían en feedback de usuarios. Confían en el número de errores en los logs.
*El problema real no es que los agents fallen. Es que no estás midiendo si funcionan.*
La autonomía total no es el objetivo. La visibilidad total sí lo es.
Y los sistemas que alcanzan 95% de correctness en error recovery comparten algo que la mayoría ignora: construyen evaluation harnesses antes de construir agents.
Por Qué Tus Métricas Actuales Son Inútiles
Las métricas que la mayoría usa para evaluar AI agents son papel mojado.
"Mensajes procesados" no dice nada sobre calidad. "Tiempo de respuesta" no dice nada sobre correctness. "Número de errores" no dice nada sobre si el agent está generando contenido correcto o incorrecto pero sin crashear.
El problema es que los AI agents no fallan como software tradicional. Un agent puede completar una tarea sin errores en los logs y entregar una respuesta completamente incorrecta. El sistema no lanza excepciones. No hay stack trace. Solo hay un output malo que el usuario recibe y asume que es válido.
❌ Métrica tradicional: Error rate
→ Solo mide crashes, no quality
❌ Métrica tradicional: Response time
→ Un agent lento puede ser correcto, uno rápido puede ser inútil
❌ Métrica tradicional: User complaints
→ Feedback lagging que llega cuando el daño ya está hecho
✅ Lo que necesitas: Correctness rate medido sistemáticamente
→ El porcentaje de outputs que superan validación específica del dominio
Los evaluation harnesses resuelven esto. Son sistemas diseñados para medir accuracy, reliability y cost de forma continua, no retrospectively.
El Framework de Evaluación Estratificada (FEE)
Necesitas un sistema que evalúe tu agent antes de que los usuarios lo usen. Que mida correctness contra ground truth conocido. Que capture failures donde ocurren, no después de que causen daño.
El Patrón de las Tres Capas (FEE) descompone la evaluación en:
Capa 1: Unit Testing de Prompts
Test individuales para cada task type que el agent debe manejar. Inputs conocidos, outputs esperados, validation rules específicas del dominio.
Capa 2: Integration Testing del Pipeline
El agent completo integrado con sus herramientas. Verifica que las chains de herramientas funcionen, que el routing entre steps sea correcto, que los outputs de una step alimenten correctamente la siguiente.
Capa 3: Shadow Mode Production
El agent real procesando requests reales en paralelo. Sin mostrar outputs al usuario todavía. Solo midiendo. Comparando contra baseline. Capturando divergences.
Cada capa tiene su propia métrica target. Unit testing busca 98% de task completion. Integration testing busca 95% de pipeline integrity. Shadow mode busca detectar regressions antes de queimpacten usuarios.
Step 1: Define Tu Taxonomy de Task Types
Antes de escribir un solo test, documenta qué tipos de tareas ejecutará tu agent. Esta taxonomy es tu ground truth.
No todos los tasks son iguales. Un agent que responde FAQs necesita validación diferente a uno que ejecuta transacciones o genera código.
```python
Taxonomy de task types para un agent de soporte técnico
TASK_TYPES = {
"faq_response": {
"accuracy_threshold": 0.95,
"requires_human_review": False,
"failure_impact": "low"
},
"ticket_routing": {
"accuracy_threshold": 0.90,
"requires_human_review": True,
"failure_impact": "medium"
},
"refund_processing": {
"accuracy_threshold": 0.99,
"requires_human_review": True,
"failure_impact": "high"
}
}
```
Cada task type tiene thresholds diferentes porque el coste de failure varía. refund_processing con 90% de accuracy es inaceptable. faq_response con 90% es perfectamente válido.
Step 2: Construye Tu Evaluation Harness
Un evaluation harness es un sistema que corre tests automáticamente, mide resultados contra baselines, y genera reports de correctness, reliability y cost.
```python
class EvaluationHarness:
def __init__(self, agent, test_suite):
self.agent = agent
self.test_suite = test_suite
self.results = []
def run_evaluation(self):
"""Ejecuta todos los tests y retorna métricas agregadas"""
for test_case in self.test_suite:
result = self._run_single_test(test_case)
self._store_result(result)
return self._aggregate_metrics()
def _run_single_test(self, test_case):
"""Ejecuta un test individual con medición detallada"""
start_time = time.time()
try:
output = self.agent.execute(test_case.input)
elapsed = time.time() - start_time
correctness = self._validate_output(
output,
test_case.expected,
test_case.validation_rules
)
return {
"test_id": test_case.id,
"task_type": test_case.task_type,
"correctness": correctness,
"latency": elapsed,
"cost": self._estimate_cost(test_case.input, output),
"status": "success" if correctness >= test_case.threshold else "failure"
}
except Exception as e:
return {
"test_id": test_case.id,
"task_type": test_case.task_type,
"correctness": 0.0,
"latency": time.time() - start_time,
"status": "error",
"error_type": type(e).__name__
}
def _validate_output(self, output, expected, rules):
"""Valida output contra expected y validation rules del dominio"""
if rules.get("type") == "exact_match":
return float(output.strip() == expected.strip())
if rules.get("type") == "contains":
return float(all(
keyword in output for keyword in rules["keywords"]
))
if rules.get("type") == "structured":
return self._validate_structured(output, rules["schema"])
Para outputs complejos, usa LLM como judge
if rules.get("type") == "llm_judge":
return self._llm_judge(output, expected, rules["criteria"])
def _aggregate_metrics(self):
"""Agrega resultados por task type y genera insights"""
metrics = {
"overall_correctness": mean([r["correctness"] for r in self.results]),
"by_task_type": defaultdict(list),
"reliability_score": self._calculate_reliability(),
"cost_efficiency": self._calculate_cost_efficiency()
}
for result in self.results:
metrics["by_task_type"][result["task_type"]].append(result)
return metrics
```
Este harness no es opcional. Es la diferencia entre operar a ciegas y tener visibility real.
Step 3: Implementa Shadow Mode
Shadow mode te permite evaluar tu agent contra traffic real sin impactar usuarios. El agent procesa requests en paralelo, tú comparas outputs contra tu baseline sin mostrar nada externally.
```python
class ShadowModeEvaluator:
def __init__(self, production_agent, shadow_agent, evaluator):
self.production_agent = production_agent
self.shadow_agent = shadow_agent # Misma config, mismo model
self.evaluator = evaluator
def process_request(self, user_request):
"""Procesa request en producción y evalúa en shadow"""
Production path - lo que el usuario ve
production_output = self.production_agent.execute(user_request)
Shadow path - lo que evaluamos
shadow_output = self.shadow_agent.execute(user_request)
Evalúa shadow contra production
divergence = self._measure_divergence(
production_output,
shadow_output
)
if divergence > 0.1: # Threshold configurable
self._flag_for_human_review(user_request, production_output, shadow_output)
return production_output # Usuario solo ve production
def _measure_divergence(self, output_a, output_b):
"""Mide divergencia entre dos outputs"""
Para outputs estructurados
if isinstance(output_a, dict):
return self._dict_divergence(output_a, output_b)
Para texto, usa embedding similarity
embedding_a = self._get_embedding(output_a)
embedding_b = self._get_embedding(output_b)
return 1 - cosine_similarity([embedding_a], [embedding_b])[0]
```
Shadow mode te descubre edge cases que no anticipaste en testing. Traffic real revela failures que tu test suite no cubre.
Step 4: Configura Alerting Basado en Métricas
Los números sin acción son vanity metrics. Configura alerts que se activen cuando las métricas crucen thresholds.
```python
Configuración de alerts
ALERT_RULES = {
"correctness_below_threshold": {
"metric": "correctness",
"threshold": 0.90,
"task_types": ["refund_processing", "escalation_routing"],
"action": "page_on_call",
"severity": "critical"
},
"latency_spike": {
"metric": "p95_latency",
"threshold": 5000, # milliseconds
"action": "slack_alert",
"severity": "warning"
},
"cost_anomaly": {
"metric": "cost_per_request",
"threshold": "2x_baseline",
"action": "log_and_continue",
"severity": "info"
}
}
```
No alertes sobre todo. Alertas sobre lo que importa: correctness en tasks críticos, latencia que degrada UX, anomalías de cost que indican problems.
El Costo Oculto de No Evaluar
Cada día que operas sin evaluation harness es un día de technical debt acumulándose.
Los problems no detectados se convierten en user complaints. Las user complaints se convierten en churn. El churn se convierte en revenue impact.
Además, sin métricas baseline, no puedes hacer cambios con confianza. Cada modification al agent es un acto de fe. "¿Mejorará esto o lo romperá?" No lo sabes hasta que un usuario te lo reporta.
Los developers que construyen evaluation harnesses desde day one iteran más rápido. Tienen feedback loop corto. Cambian el prompt, corren el harness, ven el impacto en correctness en minutes. No weeks.
Los developers que no lo hacen están ciegos. Y operar ciego en producción es la forma más cara de trabajar.
Lo Que Realmente Necesitas Medir
No todas las métricas importan igual. Estas son las que determinan si tu agent está funcionando:
Correctness Rate por Task Type
El percentage de outputs que superan validation para cada task type. Este es tu primary metric. Si refund_processing está por debajo de 99%, tienes un problem.
Failure Transformation Rate
El percentage de failures que tu system recupera automáticamente versus los que escalan a intervención humana. Un buen agent transforma más failures que los que reporta.
Recovery Time
Cuánto tarda el agent en detectar un failure y ejecutar su recovery path. Target: menos de 30 segundos para failures predecibles.
Cost per Task
El cost computacional de ejecutar cada task type. Tasks complejos cuestan más. Si el cost por request excede el value entregado, tienes un problem de unit economics.
Latency Distribution
No midas latency promedio. Mide p50, p95 y p99. El p99 es lo que tus usuarios experimentan en worst case. Si el p99 es inaceptable, tu UX está broken.
El Patrón de Intervención Estratégica
Los systems que alcanzan 95% de correctness no lo logran siendo autónomos al 100%. Lo logran sabiendo exactamente dónde necesitan intervención humana y automatizando todo lo demás.
El Patrón de Intervención Estratégica define tres categorías de tasks:
Tasks Automatizados al 100%
Tareas de baja complejidad y bajo impacto donde el agent puede operar sin supervisión. FAQ responses, formatting de datos, simple routing.
Tasks con Validación Automática
Tareas donde el agent ejecuta pero un sistema automatizado valida el output antes de enviarlo. Si la validación falla, se enroutea a revisión humana.
Tasks que Requieren Human-in-the-Loop
Tareas de alto impacto donde cada decisión necesita validación humana. Transactions financieras, escalaciones complejas, contenido sensible.
La clave es que la intervención humana no es un признак de debilidad del system. Es un компонент diseñado. Y cuando está bien diseñada, permite que el agent opere en 95% de casos de forma autónoma mientras humans validan el 5% crítico.
Resumen de Implementación
Construir evaluation harnesses efectivos requiere cuatro elementos:
→ taxonomy clara de task types con thresholds específicos
→ harness automatizado que mide correctness contra ground truth
→ shadow mode para validar contra traffic real
→ alerting basado en métricas, no en logs
El 95% de correctness que los systems híbridos alcanzan no es un techo. Es un target. Y lo consigues no con modelos más potentes, sino con mejor evaluación.
Cada intervention humana que tu system captura es un insight que mejora el agent. Cada test que ejecutas antes de desplegar es un failure potencial evitado.
Construye el harness primero. Despliega el agent después.
Tienes visibility o tienes problemas que no ves venir.
Lee el artículo completo en brianmenagomez.com
Más sobre mis servicios en brianmenagomez.com
Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF