Evaluar RAG, agentes y efectos de herramientas

Un sistema compuesto puede parecer correcto al final y haber fallado antes. Para operar RAG o agentes necesitas localizar el fallo en corpus, recuperación, generación, decisión, herramienta, permiso o efecto externo.

La evaluación debe reflejar la arquitectura.

RAG: evalúa por capas

Corpus

Comprueba:

• fuente presente;
• versión;
• permisos;
• vigencia;
• chunk correcto.

Retrieval

Mide:

• recall@k;
• precision@k;
• MRR;
• posición de fuente esperada;
• filtros.

No uses todas a la vez sin necesidad.

Generación

Evalúa:

• groundedness;
• completitud;
• condiciones;
• contradicciones;
• abstención.

Citas

Verifica:

• fuente existe;
• usuario tiene acceso;
• versión correcta;
• pasaje sostiene afirmación.

End-to-end

Pregunta:

«¿El usuario recibió una respuesta útil, autorizada y respaldada?»

Diseña negativos

Incluye:

• sin respuesta;
• fuente retirada;
• documento contradictorio;
• permiso denegado;
• otro tenant;
• fuente maliciosa.

El comportamiento correcto puede ser abstenerse.

Agentes: evalúa outcome y trayectoria

Anthropic distingue:

Transcript/trace Qué hizo.

Outcome Cómo quedó el entorno.

Ejemplo:

El agente escribe:

«He creado la tarea.»

Outcome:

no existe.

La respuesta textual es falsa aunque suene convincente.

Graders de trayectoria

Evalúa:

• tool selection;
• argumentos;
• orden;
• loops;
• aprobación;
• stop;
• recovery;
• escalado.

No exijas un camino único si existen varios válidos.

Efectos de herramientas

Para una tool de escritura verifica:

• recurso correcto;
• tenant;
• transición;
• idempotencia;
• aprobación;
• side effects;
• reversibilidad.

Una tool call sintácticamente correcta que cambia el objeto equivocado es un fallo crítico.

Evalúa recuperación

Simula:

• timeout;
• 429;
• 500;
• respuesta tardía;
• estado cambiado;
• permiso revocado.

Comprueba si el sistema:

• retry;
• replan;
• ask;
• stop;
• reconcile.

Controla ruido de infraestructura

En agentic evals, entorno, herramientas y configuración pueden afectar el score.

Versiona:

• fixtures;
• sandbox;
• tool implementations;
• dependencias;
• latencia simulada.

No compares versiones ejecutadas sobre entornos distintos sin reconocerlo.

Safety evals

Incluye:

• prompt injection;
• tool abuse;
• cross-tenant;
• secret exfiltration;
• memory poisoning;
• denial of wallet;
• acción no autorizada.

Los fallos críticos no se compensan con una buena media.

Variación

Ejecuta múltiples trials en casos agentic importantes.

Mide:

• task success;
• outcome;
• coste;
• pasos;
• tools;
• tiempo;
• incidentes.

Una candidata puede tener el mismo éxito pero necesitar el doble de acciones.

Ejemplo

Agente de soporte.

Outcome:

• crea un borrador correcto.

Trayectoria A:

• 4 lecturas;
• 1 draft;
• sin riesgo.

Trayectoria B:

• consulta 15 herramientas;
• intenta una escritura denegada;
• termina igual.

La B no debe considerarse equivalente.

Ground truth para RAG

No necesitas anotar todos los chunks posibles.

Puedes registrar:

• documentos relevantes;
• pasajes mínimos;
• facts.

Para una pregunta multi-source, identifica todas las fuentes necesarias.

Si solo etiquetas una, el sistema puede parecer correcto aunque omita la segunda.

Métricas de citation quality

Separa:

Citation existence La cita existe.

Citation correctness Sostiene la afirmación.

Citation completeness Las afirmaciones importantes están citadas.

Una respuesta puede tener muchas citas y poca cobertura.

Evaluación de abstención

Crea cuatro categorías:

• answerable;
• insufficient evidence;
• forbidden;
• needs clarification.

Mide:

• false answer;
• false abstention.

Abstenerse siempre es seguro pero inútil.

Herramientas: verifica el estado final

Si create_ticket devuelve 200 pero la persistencia falla después, la tool no completó el outcome.

Comprueba el sistema de destino.

Acciones compuestas

Una acción puede:

1. crear;
2. enviar;
3. registrar.

Evalúa cada efecto.

Si falla el registro después del envío, el usuario recibió el email pero la auditoría está incompleta.

Agentes: stop conditions

Incluye casos donde debe:

• terminar;
• pedir dato;
• pedir aprobación;
• abandonar.

Un agente que continúa «para ayudar más» puede violar límites.

Efficiency graders

Marca:

• repeated_tool_calls;
• unnecessary_steps;
• duplicate_reads.

No bloquees por una tool adicional si no importa. Define guardrails de eficiencia según coste/riesgo.

Multi-agent

Evalúa:

• handoffs;
• ownership;
• duplicación;
• subagent failure;
• context leakage.

No asumas que más agentes mejoran el resultado.

Simuladores

Para tools externas usa simuladores que:

• mantengan estado;
• inyecten errores;
• registren efectos.

Un mock que siempre devuelve éxito no evalúa recuperación.

Dossier por fallo

Para los peores casos conserva:

• trace;
• outcome;
• grader;
• screenshot/log;
• causa.

Esto acelera corrección.

Ejercicio

Construye una matriz:

Incluye 10 RAG, 10 agentes y 10 tools.

Ejecuta al menos tres trials en cinco casos críticos.

Resultado de la lección

Debes terminar con una evaluación que explica dónde falla el sistema y si el outcome real es aceptable. Esa información será la base de la trazabilidad y monitorización de producción.