Observabilidad de LLMs y Evaluation-Driven Development (EDD): cómo saber si tu agente realmente funciona
“El gateway reporta 99.9% de disponibilidad, el tiempo de respuesta es excelente, y el costo está bajo control. Pero el coordinador está clasificando mal el 15% de las quejas sensibles como ‘pregunta sobre política’, y nadie lo sabe.”
Este es el problema central de la observabilidad en sistemas con IA. Las métricas tradicionales —latencia, throughput, rate limits, uptime— dicen si el servidor está funcionando. No dicen si el agente está haciendo su trabajo correctamente.
Este capítulo responde preguntas que los logs del servidor no pueden responder: ¿el coordinador enruta correctamente? ¿el agente de vacaciones alucina fechas? ¿el RAG recupera los documentos correctos? ¿un cambio silencioso en el prompt rompió la clasificación de quejas? La respuesta vive en los datos de las interacciones, y en un nuevo paradigma: Evaluation-Driven Development (EDD).
El cambio de paradigma: del monitoreo de sistemas al monitoreo agéntico
| Métrica | Lo que mide | Lo que NO mide |
|---|---|---|
| Uptime | ¿El servidor está en ejecución? | Si el agente responde correctamente |
| Latencia | ¿Qué tan rápido responde? | Si la respuesta es útil |
| Tasa de error | ¿Hay errores 500? | Si el agente está alucinando |
| Throughput | ¿Cuántas solicitudes maneja? | Si el enrutamiento es correcto |
El gateway puede reportar 99.9% de disponibilidad, respondiendo instantáneamente — y aun así, el coordinador podría estar clasificando mal el 15% de las quejas sensibles como consultas rutinarias. Es exactamente el riesgo que identificamos en el Capítulo 6b de Parte II: una queja de acoso que nunca llega a un humano porque el sistema la clasificó mal. La fiabilidad del negocio depende de si la respuesta es correcta, no solo de si el servicio respondió.
Esto exige una transición de observabilidad de sistemas (SRE tradicional) a observabilidad agéntica. Con ella emerge el rol del AI Engineer — distinto del ML Researcher (entrena modelos y publica pesos) y del Full Stack Engineer (construye APIs y frontends). El AI Engineer orquesta prompts, contexto, agentes, y herramientas — es responsable de que el agente sea confiable y útil en producción, no solo de que el servidor esté arriba.
El ciclo de desarrollo roto: el “agujero negro” de los LLMs
El desarrollo de software tradicional es determinista: código → prueba unitaria → CI → producción, con feedback rápido y predecible. El desarrollo con LLMs es estocástico y opaco — el mismo prompt puede producir resultados distintos, y no siempre está claro por qué.
| Problema | Descripción | Ejemplo (nuestro coordinador) |
|---|---|---|
| Lógica no determinista | El modelo puede responder distinto al mismo prompt | Clasifica bien “quiero reportar acoso” hoy; mañana, con la misma frase, puede fallar |
| El “wow factor” | La demo impresiona con pocos casos, pero falla con la variedad real | Funciona con 5 ejemplos de prueba, falla con las 500 formas reales en que los empleados redactan quejas |
| Feedback perdido | Arreglar un caso rompe otro silenciosamente | Mejoras la detección de quejas, pero ahora clasifica mal preguntas de vacaciones |
| Opacidad de la orquestación | Las llamadas a herramientas intermedias no se capturan | El gateway solo ve “llegó solicitud, salió respuesta” — no el razonamiento intermedio |
La solución: convertir la evaluación en el quality gate del desarrollo de IA — EDD.
Evaluation-Driven Development (EDD): el quality gate de la IA
EDD es el paso de la “experimentación por intuición” a un proceso estructurado donde cada cambio se valida contra criterios de éxito predefinidos antes de llegar a producción.
Recordando el Capítulo 3 de Parte II, donde construimos un juez LLM con cinco opiniones de prueba: EDD es exactamente esa misma práctica, llevada a la escala de un equipo completo. En vez de “probé el nuevo prompt con tres ejemplos y parecía funcionar mejor”, la práctica correcta es “ejecuté el nuevo prompt contra el golden dataset de 500 mensajes etiquetados, y la precisión en quejas sensibles subió de 88% a 93% sin degradar otras categorías”. La diferencia es la evidencia, no la intuición.
Evals as Code — integración en CI/CD: si alguien ajusta el prompt del coordinador, ese cambio se somete como un Pull Request, igual que cualquier cambio de código — el CI ejecuta automáticamente la evaluación contra el golden dataset, compara con la versión anterior, y verifica que no haya regresiones antes de fusionar.
# tests/test_coordinador.py
import pytest
from deepeval import assert_test
from deepeval.metrics import AccuracyMetric
from deepeval.test_case import LLMTestCase
DATASET = [
{"input": "Quiero pedir vacaciones la semana que viene", "expected_route": "vacaciones"},
{"input": "Necesito reportar un problema de acoso", "expected_route": "queja_sensible"},
{"input": "¿Cómo puedo reembolsar un gasto?", "expected_route": "gastos"},
# ... 500 casos más
]
@pytest.mark.parametrize("test_case", DATASET)
def test_coordinador_enruta_correctamente(test_case):
resultado = coordinador(test_case["input"])
metric = AccuracyMetric()
assert_test(
LLMTestCase(
input=test_case["input"],
actual_output=resultado.route,
expected_output=test_case["expected_route"]
),
metrics=[metric]
)
La disciplina clave: el prompt del coordinador, y el conjunto de mensajes que lo valida, viven versionados en Git. Nadie edita el prompt “a mano” directamente en producción sin pasar por este proceso.
Los tres pilares de la observabilidad agéntica
1. Trazabilidad agéntica
Captura cada paso observable del agente, no solo la entrada y la salida. Para nuestro flujo de vacaciones (Capítulo 6 de Parte II):
Por qué es crucial: sin trazabilidad, si un empleado se queja de que el agente le dio información incorrecta, no hay forma de saber si el problema fue el servidor MCP (dato incorrecto), el RAG de políticas (cita errónea), o el razonamiento del LLM (combinó mal los datos). La traza dice exactamente dónde falló el sistema.
Lo que importa registrar es el contrato observable: inputs, outputs, herramientas invocadas, argumentos, resultados, latencia y errores. Una traza útil no necesita —ni debería exigir— la cadena de pensamiento privada del modelo. En muchos despliegues esa cadena no está disponible, y en otros no conviene persistirla.
2. Golden datasets
Un conjunto de casos de prueba etiquetados que representan el comportamiento esperado — no es un dataset de entrenamiento, es un dataset de validación.
| Dataset | Propósito | Tamaño típico |
|---|---|---|
| Coordinador | Validar enrutamiento entre dominios | 200-500 casos |
| Vacaciones | Validar el flujo de solicitud | 200-400 casos |
| Gastos | Validar el pipeline de gastos | 200-400 casos |
| Políticas (RAG) | Validar recuperación de políticas | 100-200 casos |
| Seguridad | Validar detección de quejas sensibles | 100-200 casos |
¿Por qué separados? Si mezclas todos en uno solo, no puedes diagnosticar en qué agente específico ocurrió una regresión. Datasets separados permiten aislar el problema.
Cómo se construye: recolección inicial de mensajes reales de producción, etiquetado humano por un experto en dominio, ampliación con casos borde y variaciones lingüísticas, y revisión periódica agregando casos nuevos que hayan causado problemas.
La trampa de la sobre-especificidad: si tu dataset solo tiene quejas escritas de forma muy directa (“quiero reportar acoso”), el coordinador puede sobreajustarse a esa redacción y fallar con una queja más indirecta (“me siento incómoda con el comportamiento de mi jefe”). La solución es variedad deliberada: sinónimos, paráfrasis, distintos niveles de formalidad.
3. Monitoreo continuo en producción
Los golden datasets son excelentes para pruebas pre-despliegue, pero no capturan todo lo que ocurre en producción real. El ciclo: muestreo aleatorio de conversaciones (1-5% de las interacciones), evaluación automática con un juez LLM contra una rúbrica, detección de deriva (comparar la precisión de esta semana contra la anterior — si baja de forma notable, alertar), y anotación humana periódica para confirmar que el juez sigue calibrado correctamente.
Métricas de calidad, más allá de la precisión
| Métrica | Definición | Ejemplo (coordinador) |
|---|---|---|
| Precisión de enrutamiento | % de mensajes enrutados correctamente | ¿“Quiero reportar acoso” fue a “queja_sensible” o a “política”? |
| Fidelidad | ¿La respuesta está respaldada por el contexto? | ¿El agente de vacaciones citó la política correcta? |
| Alucinación | % de respuestas con información falsa | ¿El agente inventó un saldo de vacaciones? |
| Consistencia | ¿La misma pregunta recibe la misma respuesta? | Repetir la misma pregunta varias veces y medir variación |
| Latencia funcional | Tiempo total, incluyendo herramientas | ¿Cuánto tarda consultar saldo + calendario + responder? |
| Tasa de escalamiento | % de casos escalados a humano | ¿Qué porcentaje de quejas sensibles llegan a un humano? |
| Satisfacción del usuario | ¿La respuesta fue útil? | Encuesta post-interacción, o análisis de sentimiento |
Ninguna métrica sola cuenta la historia completa: la precisión del coordinador puede ser 95%, pero si la tasa de escalamiento de quejas sensibles es 0% (porque nunca llegan a un humano), el sistema está fallando exactamente en su función más crítica — hay que mirar el conjunto, no una sola cifra aislada.
EDD en la práctica: integración con CI/CD
# .evals/config.yaml
golden_datasets:
coordinador: "datasets/coordinador.jsonl"
vacaciones: "datasets/vacaciones.jsonl"
seguridad: "datasets/seguridad.jsonl"
metrics:
- type: accuracy
threshold: 0.92
- type: hallucination
threshold: 0.05
- type: escalation_rate
threshold: 0.95
alerting:
- metric: accuracy
drop_threshold: 0.05
- metric: latency_p95
threshold_ms: 2000
El ciclo de vida de un cambio: Ana (AI Engineer) ajusta el prompt del coordinador para mejorar la detección de quejas sensibles. Crea una rama, abre un PR. El CI corre automáticamente los 500 casos del golden dataset — la precisión sube de 92% a 94%, sin regresiones en los otros datasets — y el PR se aprueba y despliega. Si en cambio el cambio mejorara quejas (+2%) pero degradara vacaciones (-3%), Ana recibiría ese reporte exacto y decidiría si ajustar de nuevo o aceptar el trade-off conscientemente. Sin CI, ese trade-off habría llegado a producción sin que nadie lo notara.
El ecosistema de herramientas
Ya documentamos este ecosistema con cifras verificadas en el Capítulo 3 de Parte II — DeepEval (integración con pytest, más de 50 métricas preconstruidas), RAGAS (las 4 métricas específicas para RAG: fidelidad, relevancia de respuesta, precisión y recall de contexto), LangSmith, Langfuse, Braintrust, Arize Phoenix, y Garak para red-teaming. La progresión natural sigue siendo la misma: DeepEval para evals como código en CI/CD, sumando trazabilidad en producción con Langfuse o LangSmith, RAGAS si hay sistemas RAG, y Garak si la seguridad es crítica.
La próxima frontera: “IA para IA”
Auto-optimización de prompts: en vez de que un humano ajuste manualmente el prompt cada vez que el golden dataset detecta una regresión, un sistema puede generar variantes del prompt, evaluar cada una contra el mismo dataset, y usar la mejor como base para la siguiente ronda — acelerando la iteración sin reemplazar todavía el juicio humano final.
Auto-recalibración de jueces: cuando un humano corrige la evaluación de un juez LLM durante su revisión periódica, esa corrección puede alimentar automáticamente un ajuste del propio juez — cerrando el ciclo para que mejore con el tiempo sin intervención manual constante en cada caso.
Detección de deriva: la deriva no solo ocurre en los datos de entrada (cómo preguntan los empleados cambia con el tiempo) sino en el comportamiento del propio modelo, que puede degradarse sin que cambie ni una línea de código. Ejecutar el golden dataset automáticamente cada semana, y alertar si la precisión baja más de un umbral definido, permite detectar esto antes de que se vuelva un problema visible para los usuarios.
Conexión con la Parte II y la Parte III
| Patrón (Parte II) | Desafío de observabilidad | Solución |
|---|---|---|
| Agente único | Monitorear razonamiento y herramientas en un solo flujo | Traza completa del agente |
| Secuencial | Saber en qué paso del pipeline falló | Traza cada paso por separado |
| Paralelo | Reconciliar resultados contradictorios | Traza cada agente y compara salidas |
| Coordinador | Detectar clasificaciones erróneas | Golden dataset del coordinador |
| ReAct | Detectar bucles improductivos | Contar vueltas, límite de iteraciones |
| Multi-agente | Confianza implícita entre agentes (el riesgo de Finnbot) | Trazas cruzadas, umbrales de confianza |
Con la Parte III: la latencia funcional (incluyendo herramientas) es una métrica crítica de por sí; la elección de latencia/throughput/costo del trilema afecta cuántos evals te puedes permitir correr en producción; el batch size incluso afecta cuánto tardan las evaluaciones dentro del propio pipeline de CI.
La tensión fundamental se mantiene intacta: cada capa de autonomía requiere una capa adicional de verificación. La observabilidad no es un extra — es el precio que se paga por tener un sistema que realmente funciona en el mundo real.
Mejores prácticas para lanzar con observabilidad
Ship small, ship early: no esperes un golden dataset “perfecto” con mil casos imaginados de antemano — lanza a un grupo piloto de 50 empleados, y usa sus mensajes reales (incluyendo los que el sistema clasificó mal) como los primeros casos reales del dataset.
Evalúa de extremo a extremo, no cada micro-paso: no fuerces que el agente siempre consulte el saldo antes que el calendario — lo que importa es si la respuesta final es correcta, dejando que la autonomía media que ya definimos decida el orden. Mide el resultado final; usa la traza solo cuando estés depurando un fallo específico.
Evita la sobre-especificidad: añade variedad deliberada al dataset — sinónimos, paráfrasis, distintos registros — para que el sistema generalice en vez de memorizar la redacción exacta de tus ejemplos de prueba.
La observabilidad es una inversión, no un costo: menos escalamientos innecesarios a humanos, menos quejas de usuarios, menos incidentes de seguridad (evitar el propio caso Finnbot), y más confianza que acelera la adopción real del sistema.
Resumen del capítulo
- El monitoreo de sistemas (uptime, latencia) no basta — hace falta observabilidad agéntica, que responde si el agente está haciendo bien su trabajo, no solo si el servidor responde.
- EDD convierte la evaluación en el quality gate del desarrollo de IA — cada cambio se valida con evidencia, no con intuición.
- Los tres pilares: trazabilidad (cada paso observable), golden datasets (casos etiquetados por agente), y monitoreo continuo (muestreo y detección de deriva en producción).
- Ninguna métrica de calidad basta sola — precisión, fidelidad, alucinación, consistencia, latencia funcional, tasa de escalamiento, y satisfacción deben verse en conjunto.
- La observabilidad no es un accesorio pasivo — es lo que separa a un prototipo que impresionó en la demo de un sistema en el que miles de personas pueden confiar todos los días.
El caso Finnbot, que veremos en detalle en el próximo capítulo de seguridad agéntica, es un recordatorio directo de lo que ocurre cuando la autonomía supera a la verificación. La observabilidad es la red de seguridad que evita que los errores se conviertan en desastres.
LinkedIn nelson.zepeda@simov.io SIMOV LABS
¿Encontraste un error? Sugerir una corrección