Reliability, Escalación y Human-in-the-Loop
Reliability, Escalación y Human-in-the-Loop
Anterior: Gestión de Contexto · Índice · Siguiente: Escenarios del Examen
Error handling patterns
Los agentes en producción enfrentan tres tipos de errores, cada uno con una estrategia diferente:
Transient errors → Retry
Errores temporales de red, rate limits, timeouts:
- Retry con exponential backoff
- Máximo 3-5 intentos
- No modificar el request entre retries
- Logging de cada intento para debugging
Validation errors → Fail-fast
Errores de datos incorrectos, schema violations, inputs inválidos:
- No reintentar — el mismo input producirá el mismo error
- Retornar error descriptivo inmediatamente
- Incluir qué campo falló y por qué
- Permitir que el caller corrija y reenvíe
Business logic errors → Escalate
Situaciones que requieren juicio humano:
- Caso fuera de las reglas definidas
- Conflicto entre policies
- Decisión de alto impacto (refund > threshold, acceso a datos sensibles)
- Escalación con structured summary, no raw transcript
Human-in-the-loop workflows
Cuándo escalar a un humano
| Trigger | Ejemplo | Acción |
|---|---|---|
| Policy violation | Solicitud que contradice términos de servicio | Escalar con contexto |
| Ambigüedad | Instrucciones del usuario pueden interpretarse de 2+ formas | Pedir clarificación |
| Alto valor | Transacción > $10,000 | Requerir aprobación |
| Baja confianza | Modelo reporta confidence < threshold | Routing a humano |
| Excepción | Caso no cubierto por reglas existentes | Escalar para decisión |
Diseño de escalación
Efectivo: Structured summary
{
"escalation_reason": "Refund request exceeds $500 threshold",
"customer_context": "Premium tier, 3 years, no previous refunds",
"attempted_resolution": "Offered partial refund of $200, declined",
"recommended_action": "Approve full refund based on customer value",
"confidence": "medium"
}Inefectivo: Raw transcript
- El humano debe leer toda la conversación
- Información relevante enterrada en contexto irrelevante
- Consume tiempo del revisor innecesariamente
Para el examen: La escalación siempre debe incluir un structured summary con: razón, contexto, qué se intentó, y recomendación. No el transcript raw.
Self-evaluation y confidence routing
Pedir confidence score al modelo
Claude puede reportar su nivel de confianza, que sirve para routing:
- Alta confianza: Procesar automáticamente
- Media confianza: Queue para human review (no urgente)
- Baja confianza: Escalar inmediatamente
Calibración del routing
El threshold de confidence debe calibrarse empíricamente:
- Recopilar N casos con confidence reportada
- Comparar contra ground truth (humano verifica)
- Ajustar thresholds hasta que el routing sea efectivo
- Monitorear drift — recalibrar periódicamente
Limitaciones de self-evaluation
- Claude tiende a sobre-reportar confianza (overconfidence)
- Confidence no es una probabilidad calibrada
- Mejor usar como señal de routing que como métrica absoluta
- Combinar con validación programática para mayor fiabilidad
Monitoring y observability
Qué monitorear en agentes de producción
Métricas operativas:
- Latency por step del pipeline
- Tasa de errores por tipo (transient, validation, business)
- Token usage por request
- Tasa de escalación a humanos
Métricas de calidad:
- Tasa de resolución sin escalación
- User satisfaction (si aplica)
- Tasa de re-apertura de tickets resueltos por el agente
- Accuracy de extracción (sampling periódico)
Alertas:
- Spike en error rate → posible issue de infra o cambio en input
- Spike en escalation rate → posible drift en model behavior
- Aumento en token usage → posible loop infinito o contexto inflado
- Caída en resolution rate → posible degradación de calidad
Structured logging
Cada step del agente debe logear:
- Input recibido (sanitizado, sin PII)
- Tool calls realizados
- Output producido
- Tokens consumidos
- Duración
- Errores encontrados
Fallback strategies
Degradación graceful cuando tools fallan
Si una herramienta externa no está disponible:
- Retry transient — la tool puede estar temporalmente caída
- Fallback tool — usar herramienta alternativa si existe
- Partial response — completar lo que se pueda sin la tool
- Inform user — explicar qué no se pudo hacer y por qué
- Queue for later — guardar la tarea para cuando la tool vuelva
Fallback en pipelines multi-step
Si un step intermedio falla:
- NO continuar con datos incompletos (garbage in → garbage out)
- Retornar resultado parcial claramente marcado
- Indicar qué steps se completaron y cuáles no
- Permitir retry del step fallido sin re-procesar todo
Circuit breaker pattern
Para tools que fallan repetidamente:
- Después de N fallos consecutivos, dejar de intentar (abrir circuito)
- Periódicamente probar si la tool se recuperó (half-open)
- Cuando funcione de nuevo, restaurar uso normal (cerrar circuito)
- Evita cascadas de timeouts que degradan todo el sistema
Patrones de fiabilidad combinados
Pipeline robusto de producción
flowchart LR
A[Request] --> B[Validation]
B --> C[Processing]
C --> D[Verification]
D --> E[Response]
A -- error --> A1[Reject]
B -- error --> B1[Fail-fast]
C -- error --> C1[Retry 3x]
C1 -- falla --> C2[Fallback/Partial]
D -- error --> D1[Escalate]Cada stage tiene su propia estrategia de error handling:
- Validation: Fail-fast, no retry
- Processing: Retry con backoff para transient errors
- Verification: Escalate si no pasa validación semántica
- Response: Fallback a partial response si algo falla
Resumen
- Tres tipos de errores: transient (retry), validation (fail-fast), business (escalate)
- Escalación con structured summary, no raw transcript
- Self-evaluation sirve para routing, no como métrica absoluta
- Calibrar thresholds de confidence empíricamente
- Monitorear: latency, error rate, escalation rate, token usage
- Degradación graceful: partial response > crash total
- Circuit breaker para tools que fallan repetidamente
Anterior: Gestión de Contexto · Índice · Siguiente: Escenarios del Examen