EvalOps: Cómo Medir Si Tu Agente IA Está Funcionando (y Si Sigue Funcionando Mañana)

Por qué "pasa los tests" no significa nada en IA

Te llega un mensaje del cliente. "Algo va raro con el agente hoy." Lo miras. Los logs no dan error. El modelo responde. Las tools devuelven 200. El sistema no está caído. Lo que está pasando es más sutil: las respuestas se han vuelto más vagas, citan peor las fuentes, escalan más al humano de lo que solían. No hay un fallo binario. Hay una degradación.

En software clásico esto rara vez ocurre. Una función o pasa o no pasa los tests. En IA pasa todo el rato — y la diferencia entre un sistema en producción y un experimento expuesto es saber detectarlo antes de que el cliente avise.

Por eso decir "hicimos 100 tests y los pasó" no significa nada. Tres motivos:

El modelo es estocástico. La misma entrada produce salidas distintas. Un test pasa por la rúbrica que aplicaste; otra rúbrica habría dictaminado fallo.
El sistema cambia sin tocarlo. El proveedor actualiza el modelo, alguien añade 200 documentos al RAG, una tool conectada devuelve datos con un campo nuevo. Los tests del día 0 no detectan ninguno de estos.
El éxito es multi-dimensional. Una respuesta puede ser correcta y carísima. Útil y lenta. Bien citada y desactualizada. Un solo "PASA/FALLA" comprime demasiado.

EvalOps es la disciplina que se encarga de esto: medir continuamente la calidad de un sistema de IA con métricas operativas, alertar cuando se degrada, y dar al equipo herramientas para entender por qué — sin esperar a que un humano se queje.

Los tres ejes que hay que medir

Casi todos los proyectos miden una sola cosa — "está respondiendo bien" — y juntan dimensiones que conviene separar. Las que realmente importan son tres:

Retrieval. ¿El sistema recupera la información correcta para responder? Aplica especialmente a RAG, pero también a cualquier agente que busca antes de actuar. Métricas operativas:

recall@k — de los k fragmentos recuperados, cuántos eran realmente relevantes.
MRR (Mean Reciprocal Rank) — qué tan arriba aparece el primer fragmento útil.
nDCG — calidad del ranking completo, no solo del top-1.
Distribución de scores de similitud — si la media cae con el tiempo, algo en el índice está envejeciendo.

Acción del agente. ¿El agente eligió la tool correcta? ¿Ejecutó con los parámetros correctos? ¿Decidió escalar cuando tenía que escalar? Métricas:

Task success rate — porcentaje de tareas completadas extremo a extremo sin escalado y sin fallo.
Tool success rate — porcentaje de tool calls que devuelven sin error y con el resultado esperado.
Decision precision — sobre las acciones críticas (escalado, aprobación, rechazo), ¿el agente acertó?
Tiempo medio de ciclo — del input al output completo.

Calidad de la respuesta. ¿Lo que el agente devolvió al usuario es correcto, completo, y está bien fundamentado? Métricas:

Groundedness — porcentaje de afirmaciones de la respuesta respaldadas por las fuentes recuperadas.
Factual accuracy — porcentaje de hechos verificables que son correctos.
Tono y formato — la respuesta encaja con las normas que se le pidió al agente seguir.
Citation correctness — las citas apuntan al fragmento que respalda lo afirmado, no a otro.

Estas tres dimensiones se rompen por motivos distintos y conviene tener métricas separadas para cada una. Cuando la calidad baja, lo primero que mira un equipo serio es por qué eje: ¿retrieval malo? ¿acción mala? ¿respuesta mal generada a partir de retrieval bueno? Esa diagnosis decide dónde actuar.

LLM-as-judge: cuándo sirve y cuándo es mala idea

Para muchas de las métricas anteriores no existe una fórmula determinista. "¿Está bien fundamentada esta respuesta?" no se contesta con un regex. La alternativa común es usar otro LLM como juez: pasarle la pregunta, la respuesta y los fragmentos recuperados, y pedirle que puntúe.

LLM-as-judge funciona — bajo condiciones. La regla operativa que aplicamos:

Sirve cuando:

La rúbrica está bien definida con criterios concretos (no *"valora la calidad", sino "¿cada afirmación tiene un fragmento que la respalda?").
El juez es un modelo distinto al evaluado (evitar que el modelo se evalúe a sí mismo y se infle).
La rúbrica se ha calibrado contra revisión humana — se han pasado 50-100 casos por humano y por juez, se compara la concordancia, y la rúbrica se ajusta hasta que la concordancia es alta.
Las puntuaciones del juez se interpretan en agregado (tendencias), no en valor absoluto.

Es mala idea cuando:

Se usa para juzgar criterios sutiles (creatividad, tono empresarial, "elegancia") sin calibración humana previa.
El juez y el evaluado comparten arquitectura — los modelos tienden a preferir respuestas con su propio estilo.
Se interpreta como verdad absoluta. Una puntuación 4.3/5 del juez no es 4.3/5 real; es 4.3/5 según el juez.

Un patrón que sí escala: combinar LLM-as-judge para grandes volúmenes con muestreo humano semanal de 20-30 casos. El humano calibra al juez; el juez evalúa el volumen.

Drift detection: la degradación silenciosa

La parte más insidiosa de operar IA en producción no son los fallos. Son las degradaciones graduales que nadie nota hasta que llegan a una métrica de negocio.

Tres tipos de drift que hay que vigilar:

Drift de modelo. El proveedor actualiza el modelo sin cambiar el endpoint. Las respuestas cambian de forma sutil. Tu agente pasa de citar siempre las fuentes a olvidarlas en el 8% de los casos. Sin un eval continuo que muestrea cada día sobre un dataset fijo, no lo detectas.

Drift de datos. El RAG empieza a recuperar peor porque los documentos indexados ya no son representativos de las preguntas que llegan. La nomenclatura interna cambió, se añadieron 200 documentos nuevos que introducen ambigüedades, una fuente se desactualizó. Los embeddings que antes apuntaban a los fragmentos correctos ahora apuntan a otros.

Drift de uso. Los usuarios empiezan a preguntar cosas distintas. El agente fue diseñado para casos A, B y C; ahora le llegan D y E y va saliendo del paso, pero con calidad decreciente. Los logs muestran un aumento de respuestas largas, de escalados, de tiempos.

Los tres se detectan con la misma técnica: un eval continuo que corre sobre un dataset representativo y compara las métricas con la línea base histórica. Cuando una métrica se desvía más de un umbral, salta una alerta. Sin eso, el primer indicador es la queja de un usuario, y para entonces el problema lleva semanas activo.

Shadow runs y canary releases para agentes

En software clásico hay despliegues blue-green, canary, feature flags. En IA hay equivalentes que casi nadie está aplicando.

Shadow runs. Cuando vas a cambiar el modelo, el prompt o el pipeline de retrieval, no cambias en producción de golpe. Durante una o dos semanas, cada petición real corre por la versión antigua (que responde al usuario) y, en paralelo, por la versión nueva (cuya respuesta solo se guarda). Después comparas: ¿la nueva mejora las métricas o las empeora? ¿en qué clases de caso? Si los datos son buenos, se promueve. Si no, se ajusta sin que ningún usuario se haya visto afectado.

Canary releases. Cuando la versión nueva pasa shadow, se despliega a un porcentaje pequeño del tráfico real (1%, 5%) antes que al resto. Las métricas se vigilan en tiempo real y, si cualquier indicador se desvía, el rollback es automático. Solo cuando el canary aguanta varios días sin desviación, se pasa al 100%.

Replay de incidentes. Cuando algo va mal en producción, el equipo necesita poder reproducir la petición exacta con el contexto que tuvo el agente — el system prompt, los fragmentos RAG recuperados, las tools llamadas, todo. Si el incidente se puede replicar fuera de producción, se diagnostica en minutos. Si no, se especula durante días.

Estas técnicas no son exóticas. Son ingeniería normal aplicada a la rareza de la IA. La rareza concreta: en IA el "código" incluye el modelo, el prompt, los embeddings y los datos indexados. Cambiar cualquiera de los cuatro es desplegar — y cualquier despliegue serio merece shadow y canary.

EvalOps como pipeline

El EvalOps maduro no son scripts dispersos que alguien corre cuando se acuerda. Es un pipeline integrado en el ciclo de desarrollo:

Cambio en código, prompt o configuración → commit en el repo.
CI dispara los evals. El dataset de regression se corre automáticamente. Si métricas críticas caen más del umbral acordado, el build no pasa.
Si el build pasa, se ejecuta una eval más extensa (más casos, más métricas) en preproducción.
Si esa eval también pasa, se promueve a shadow run en producción.
Tras N días de shadow con métricas estables, canary release al X% de tráfico.
Tras canary estable, promoción al 100%.
En 100%, monitorización continua con alertas si cualquier métrica se desvía.

Lo que parece overhead en un proyecto pequeño es lo que permite operar un agente sin sustos en un proyecto serio. Y el coste de montarlo, una vez, se amortiza en proyectos sucesivos — porque el pipeline es plantilla reusable, no construcción ad-hoc.

FinOps: el coste también es una eval

Una respuesta correcta y carísima no es una respuesta buena. En IA en producción, el coste por tarea es una métrica que va junto a las de calidad — y se monitoriza con la misma exigencia.

Lo que se mide:

Coste por tarea completa — tokens de entrada y salida, llamadas a APIs externas, embeddings recalculados.
Distribución por tipo de consulta — saber qué clases de pregunta cuestan más permite optimizar las costosas y dejar las baratas como están.
Eficacia del prefix caching — si tu system prompt es largo y se repite, el caching debería estar comiendo gran parte del coste. Si no lo está, hay un problema de configuración.
Routing entre modelos — en agentes maduros, no todas las consultas van al modelo más capaz. Las simples van a uno barato, las complejas a uno potente. El router que decide cuál es una pieza del sistema que también se evalúa.

Tres tácticas que reducen coste sin bajar calidad y que aplicamos sistemáticamente:

Prefix caching agresivo. El system prompt, los fragmentos RAG estables y las descripciones de tools se cachean. Reduce el coste por llamada un 60-80% en consultas repetidas.
Routing barato/caro. Una primera capa decide la complejidad de la consulta. Las simples a un modelo barato; solo las complejas al caro. En un agente nuestro de soporte, esto bajó el coste medio por ticket alrededor de un 55%.
Compresión de historial. En lugar de enviar 20 turnos completos, se envía un resumen sintético de los primeros 15 y los últimos 5 literales. La pérdida de matiz es marginal; el ahorro es enorme.

Sin medir el coste, estas optimizaciones nunca llegan — porque nadie ve la oportunidad. Con un dashboard que muestre coste por tarea segmentado, las decisiones se toman solas.

Cómo lo construimos en producción

Cuando un cliente nos pide un agente IA serio, EvalOps no es un módulo opcional — es parte de la entrega desde el día uno. Sobre el mapa del rol del agente, definimos qué métricas miden si está cumpliendo, qué dataset de evaluación las representa y qué pipeline las ejecuta. Sin esas tres piezas el agente no entra en producción; entra en piloto.

El dataset de evals lo construimos con casos reales del cliente — incluyendo los que fallaron en el primer mes de uso. Cada caso tiene la entrada, la salida esperada, los fragmentos esperados (si aplica) y la rúbrica de juicio. Vive versionado en el repo del agente. Crece con el tiempo: cada caso interesante que aparece en producción se añade.

El dashboard de métricas (calidad, coste, drift, escalados) es del cliente. No de un servicio nuestro al que el cliente queda atado. Si dentro de seis meses decide internalizar o cambiar de partner, el dashboard sigue funcionando.

Detrás de esos pipelines hay un equipo de desarrolladores que cree que la ingeniería seria de IA empieza por preguntarse cómo se va a saber si esto funciona, no por construir lo más bonito que se pueda construir. La excelencia técnica no es que el agente responda bien hoy; es que el equipo lo sepa cuando empiece a responder mal — antes de que el cliente se entere.

Producción significa que el sistema te avisa cuando se está degradando, no que esperas a que un usuario se queje. Esa es la diferencia entre un agente operado y uno desplegado.

Si tienes un agente IA en producción y no estás seguro de si está rindiendo igual que hace tres meses — o no tienes forma de saberlo si dejara de hacerlo — podemos auditar tu sistema, montarte el pipeline de evals y entregarte el dashboard para que dejes de operar a ciegas.