Evaluación de AI Agents 2026: El Try-Catch es un Error Categorial — y el 95% de tus Agents se Rompe en Silencio
El 95% de los AI Agents fallan en su primer error real. El try-catch no los salva — es un error categorial. Aprende el sistema de 4 buckets para evaluar agents y detectar errores silenciosos.
Tu AI Agent Pasa el 100% de los Tests y Sigue Tomando Decisiones Catastróficas en Silencio
El try-catch no solo no lo soluciona. *Es un error categorial. *
La industria asume que evaluar AI Agents es una extensión natural del testing de software clásico. Unit tests. Tests de integración. Try-catch. Dashboard verde. Producción.
*Esto es profundamente incorrecto. *
Un AI Agent no falla con un crash. No lanza una excepción. No devuelve `null`. Falla con una respuesta perfectamente redactada, gramaticalmente impecable, confiada, y completamente errónea.
El 95% de los AI Agents se rompen en su primer error real en producción. No porque el modelo sea malo. Sino porque los equipos los evalúan con herramientas diseñadas para software determinista — y los AI Agents son sistemas probabilísticos.
Este artículo no va de "cómo escribir mejores prompts". Va de construir un evaluation harness que mida lo que realmente importa: accuracy, errores silenciosos, y tasa de rechazo. Por separado. Sin promedios engañosos.
---
El Problema de Fondo: El Try-Catch es un Error Categorial
Gilbert Ryle, filósofo británico, acuñó el término "error categorial" en 1949. Es cuando aplicas un concepto diseñado para un dominio a otro dominio donde no tiene sentido. Como preguntar "¿de qué color es el miércoles?".
*El try-catch aplicado a AI Agents es exactamente eso. *
El try-catch está diseñado para capturar errores de tipo I: el código no ejecuta. La base de datos no responde. El JSON está mal formado. El array está vacío. El servidor devuelve un 500.
Pero los AI Agents producen errores de tipo II: el código ejecuta perfectamente, la tool call se completa, el JSON es válido, y la decisión es incorrecta.
❌ Testing tradicional (try-catch):
```
try {
const result = await agent.run(query);
// Test pasa porque result no es null
console.log("✅ Test pasado");
} catch (error) {
console.error("❌ Error capturado");
}
```
Este código te da una falsa sensación de seguridad. El test pasa. El dashboard está verde. Y tu agente está tomando decisiones equivocadas en producción.
✅ Lo que realmente necesitas:
```
const result = await agent.run(query);
// El test no pregunta "¿ejecutó?" sino "¿decidió correctamente?"
const bucket = classifyResult(result, groundTruth);
// bucket puede ser: VP, FP, FN, VN
```
Un test unitario que mide si el código ejecuta no puede detectar un error semántico. Es como usar un termómetro para medir la velocidad del viento. El instrumento no está diseñado para el fenómeno.
---
El Sistema de 4 Buckets: La Única Forma de Evaluar un AI Agent
El testing tradicional usa una dicotomía binaria: pasa / falla. Para AI Agents, eso es insuficiente. Necesitas cuatro categorías porque el espacio de outcomes de un LLM es más rico que el de una función determinista.
Aquí está el Sistema de 4 Buckets para Evaluación de AI Agents:
| Bucket | Nombre | ¿Qué significa? | Riesgo |
|--------|--------|----------------|--------|
| ✅ VP | Verdadero Positivo | Respondió correctamente cuando debía | Bajo |
| ❌ FP | Falso Positivo | Respondió con error silencioso (el más peligroso) | Crítico |
| ⚠️ FN | Falso Negativo | Dijo "no sé" cuando sabía la respuesta | Alto (oportunidad perdida) |
| ✅ VN | Verdadero Negativo | Rechazó correctamente lo que no debía responder | Bajo |
El Falso Positivo es el asesino silencioso. Es cuando tu agente de atención al cliente le dice al usuario "su pedido está en camino" cuando el pedido fue cancelado. La respuesta es gramaticalmente perfecta, cortés, y completamente falsa. Ningún try-catch del mundo va a detectar eso.
Ejemplo en Código: Clasificador de 4 Buckets
```typescript
type EvalBucket = 'VP' | 'FP' | 'FN' | 'VN';
function classifyAgentResponse(
agentOutput: string,
expectedOutput: string,
shouldRespond: boolean
): EvalBucket {
const isCorrect = agentOutput === expectedOutput;
const isRefusal = agentOutput.includes('No puedo responder')
|| agentOutput.includes('No lo sé');
if (shouldRespond && isCorrect) return 'VP';
if (shouldRespond && !isCorrect && !isRefusal) return 'FP'; // Error silencioso
if (shouldRespond && isRefusal) return 'FN'; // Falso rechazo
if (!shouldRespond && isRefusal) return 'VN';
if (!shouldRespond && !isRefusal) return 'FP'; // Habló cuando no debía
return 'FP'; // Default seguro: asumir error silencioso
}
```
Este es el corazón del evaluation harness. No intenta capturar una excepción. Clasifica la decisión. Es un cambio cualitativo en cómo piensas sobre testing.
---
La Evidencia: Un Caso Real de Error Silencioso
Construí un agente de atención al cliente para una gestoría. El agente recibía consultas sobre trámites fiscales y devolvía respuestas con el estado del expediente.
El test unitario tradicional:
```typescript
// Test tradicional: ✅ PASA
const response = await agent.run("¿Cuándo estará mi devolución?");
expect(typeof response).toBe('string');
expect(response.length).toBeGreaterThan(10);
// ✅ Test pasa. Todo bien.
```
El mismo agente evaluado con el sistema de 4 buckets sobre 100 consultas:
```
🔍 Resultados del Evaluation Harness (100 ejecuciones):
✅ VP (Correcto): 65
❌ FP (Error silencioso): 22 ← ¡22% de respuestas incorrectas pero convincentes!
⚠️ FN (Falso rechazo): 8
✅ VN (Rechazo correcto): 5
📊 Métricas separadas:
Accuracy: 70% (VP + VN)
Latent Error: 22% (FP — errores silenciosos) ← La métrica que importa
Refusal Rate: 8% (FN — falsos rechazos)
```
El agente pasaba el 100% de los tests unitarios. En producción, el 22% de las respuestas eran incorrectas pero perfectamente redactadas. Cada una de esas respuestas era un cliente recibiendo información falsa.
El test unitario tradicional no mintió: el código ejecutaba correctamente. Pero eso no es lo que importa. *Lo que importa es si la decisión es correcta. *
---
Cómo Construir un Evaluation Harness en 5 Pasos
1. Categoriza Cada Output en los 4 Buckets
No uses pasa/falla. Implementa el clasificador de 4 buckets que viste arriba. Cada respuesta de tu agente debe caer en uno de los cuatro.
El dataset de ground truth debe incluir:
Inputs normales: consultas típicas que el agente ve todos los días
Adversariales: intentos de jailbreak, prompts ambiguos, consultas maliciosas
Border case: preguntas en el límite de lo que el agente debería saber
Con ruido: consultas mal escritas, con typos, con información incompleta
2. Implementa el Harness con un Framework de Evaluación
Usa LangSmith, Weights & Biases, o Arize como infraestructura de logging. Pero implementa los 4 buckets como capa sobre ellos.
```typescript
interface EvalRun {
input: string;
output: string;
expected: string;
bucket: EvalBucket;
latency: number;
tokenCost: number;
timestamp: Date;
}
async function runEvaluationHarness(
agent: Agent,
testCases: TestCase[],
iterations: number = 3
): Promise<EvalRun[]> {
const results: EvalRun[] = [];
for (const testCase of testCases) {
for (let i = 0; i < iterations; i++) {
const start = Date.now();
const output = await agent.run(testCase.input);
const latency = Date.now() - start;
results.push({
input: testCase.input,
output,
expected: testCase.expectedOutput,
bucket: classifyAgentResponse(output, testCase.expectedOutput, testCase.shouldRespond),
latency,
tokenCost: estimateTokens(output),
timestamp: new Date()
});
}
}
return results;
}
```
El parámetro `iterations` es clave. Los LLMs son probabilísticos. Una misma consulta puede dar resultados diferentes en ejecuciones distintas. Evalúa siempre sobre N iteraciones, no sobre una sola.
3. Mide Tres Métricas por Separado — Nunca las Promedies
Esta es la regla de oro. No caigas en la trampa de la métrica compuesta.
❌ Mal:
```
"Accuracy: 92%" ← Oculta que el 8% son errores silenciosos
```
✅ Bien:
```
📊 Métricas separadas:
Accuracy: 92% (VP + VN / total)
Latent Error: 7% (FP / total) ← Errores silenciosos
Refusal Rate: 1% (FN / total) ← Falsos rechazos
```
Un agente con 95% de accuracy puede tener un 5% de errores silenciosos. En un dominio como trading, un 1% de FP puede significar pérdidas millonarias. En salud, un 0.1% de FP puede ser fatal.
Publicar métricas separadas no es pedantería técnica. Es una decisión de gobernanza de riesgo. Quien promedia accuracy sobre errores silenciosos está tomando una decisión de negocio sin decirlo.
4. Configura Monitoreo en Producción que Detecte Drift en los 4 Buckets
La evaluación no termina en pre-deploy. Los LLMs cambian. Los patrones de uso cambian. Los datos de entrada cambian.
```typescript
// Monitoreo continuo en producción
class ProductionMonitor {
private baseline: BucketDistribution;
checkForDrift(runBatch: EvalRun[]): Alert | null {
const currentDistribution = this.calculateDistribution(runBatch);
// Si los FP pasan del 5% al 15%, es alerta
if (currentDistribution.FP > this.baseline.FP * 1.5) {
return {
level: 'critical',
message: `Latent error rate ha aumentado de ${this.baseline.FP}% a ${currentDistribution.FP}%`,
action: 'Revisar logs de FP. Posible regresión o cambio en el modelo.'
};
}
return null;
}
}
```
Un aumento de FP del 5% al 15% es una señal de alerta que ningún test unitario tradicional capturaría. El código sigue ejecutando. No hay excepciones. No hay crashes. Pero el agente está tomando más decisiones incorrectas.
5. Establece un Post-Mortem Específico para Errores Silenciosos
Cuando detectas un FP en producción, el análisis no puede ser "arreglamos el prompt y ya". Necesitas responder:
¿Qué patrón tenía este error que el harness no anticipó?
¿Había un caso similar en el dataset de ground truth?
¿Es un error del modelo o del contexto que le pasamos?
¿Cómo alimentamos este caso de vuelta al dataset?
Cada error silencioso debe convertirse en un nuevo caso de test. Así tu evaluation harness mejora con el tiempo. Los errores no deben repetirse dos veces.
---
Por Qué la Métrica Compuesta es Engañosa en AI Agents
La industria de los sistemas de recomendación ya pasó por esto hace una década. Pasaron de evaluar con offline metrics (precision/recall) a online evaluation (A/B testing, long-term value). ¿Por qué? Porque descubrieron que un modelo con métricas offline perfectas podía generar una experiencia de usuario pésima.
Los AI Agents están repitiendo exactamente el mismo error.
Un agente con 95% de accuracy suena genial hasta que analizas qué hay en ese 5% restante. Si el 5% son errores silenciosos (FP), tu agente está tomando decisiones incorrectas el 5% del tiempo. En un sistema que ejecuta 10.000 decisiones al día, son 500 errores silenciosos diarios.
*La métrica compuesta no es información. Es ruido. *
Por eso el Sistema de 4 Buckets no es opcional para agents que ejecutan decisiones autónomas. Es el mínimo necesario.
---
Objeción: "Pero Usamos LangSmith, Eso Ya Lo Resuelve"
LangSmith, Weights & Biases, y Arize son herramientas excelentes. Pero no resuelven el problema categorial de cómo clasificar un output.
Puedes tener el mejor dashboard del mundo y seguir clasificando errores silenciosos como "correctos" si tu lógica de evaluación sigue usando `===` en lugar de los 4 buckets. El sistema de clasificación es una capa conceptual que debe implementarse sobre estas herramientas, no un reemplazo de ellas.
El framework no te salva de un error de framework.
---
Objeción: "Mi Modelo Está Fine-Tuned, No Hay Errores Silenciosos"
Ningún modelo, por bien entrenado que esté, tiene 0% de errores silenciosos. Los LLMs son sistemas probabilísticos — siempre hay una distribución de outputs incorrectos.
La evaluación no es un sustituto del fine-tuning. Es el sistema de detección necesario precisamente porque el fine-tuning nunca es perfecto.
Afirmar lo contrario es caer en la falacia del modelo perfecto. Y esa falacia es la razón por la que el 95% de los agents fallan en su primer error real.
---
El Framework: Sistema de 4 Buckets para Evaluación de AI Agents
Resumido en una tabla para que lo implementes hoy:
| Paso | Acción | Herramientas |
|------|--------|-------------|
| 1 | Clasifica outputs en VP, FP, FN, VN | Clasificador propio (5 líneas de código) |
| 2 | Ejecuta contra dataset de ground truth con variantes | LangChain, LangSmith, o script propio |
| 3 | Mide accuracy, latent error rate, refusal rate por separado | Dashboard con tres métricas, no una |
| 4 | Monitorea drift en producción | Script de monitoreo con alertas |
| 5 | Post-mortem de FP y retroalimentación al dataset | Issue tracker + dataset versionado |
---
Lo Que Debes Hacer Mañana
1. Revisa tu evaluation harness actual. Si solo tienes `try/catch` y `expect().toBe()`, lo has construido para software determinista. Necesitas reconstruirlo para sistemas probabilísticos.
2. Implementa el clasificador de 4 buckets. Son 5 líneas de código que cambian cómo piensas sobre evaluación. No esperes a tener el dataset perfecto — empieza con 20 casos de ground truth.
3. Separa tus métricas. Si alguien en tu equipo dice "nuestro agente tiene 95% de accuracy", pregúntale cuál es el latent error rate. Si no lo sabe, no sabe cómo funciona su agente.
4. Automatiza el post-mortem de errores silenciosos. Cada FP en producción debe generar un caso de test. Si no tienes este loop, tu agente va a repetir el mismo error una y otra vez.
El try-catch no es tu amigo aquí. No está diseñado para esto. *El error silencioso es el enemigo real, y solo lo detectas cuando dejas de medir si el código ejecuta y empiezas a medir si la decisión es correcta. *
El 95% de los agents fallan en su primer error. El tuyo no tiene por qué ser uno de ellos.
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