Para evaluar un agente de IA empresarial, hay que medir tanto las decisiones que toma durante el proceso como el resultado que consigue para el usuario. Una evaluación fiable conserva la traza completa, comprueba por separado la planificación, el uso de herramientas, los permisos, los traspasos, el estado y la calidad de la tarea final, y combina esas señales para tomar una decisión sobre el lanzamiento o la monitorización. Una respuesta final correcta no demuestra que el agente haya utilizado la herramienta adecuada, respetado los permisos del usuario o seguido el flujo de trabajo requerido.
En los equipos empresariales, el registro de evaluación debe vincular cada resultado con la versión del sistema, la persona responsable o revisora, la decisión de lanzamiento y el seguimiento en producción. Los usos regulados añaden requisitos de supervisión, trazabilidad y conservación de datos, pero el problema operativo es más amplio: mantener una calidad constante entre equipos, entornos, modelos y versiones.
La respuesta final es solo una parte de la evaluación de un agente
Una evaluación de agentes pregunta si el sistema realizó el trabajo correcto, en el orden correcto, dentro de los límites correctos y produjo un resultado aceptable.
Un agente puede fallar aunque produzca una respuesta convincente. Puede elegir la herramienta equivocada o enviar un argumento no válido, omitir una verificación necesaria, revelar información sin permiso, transferir el caso al especialista incorrecto, perder parte del estado, recuperarse mal de un error de herramienta o completar pasos intermedios sin alcanzar el objetivo real del usuario.
La evaluación debe conservar evidencias de cada paso, no solo de la respuesta final. Una traza útil incluye la entrada del usuario, las decisiones del agente, las llamadas a herramientas y sus argumentos, los resultados de las herramientas, los traspasos, el contexto recuperado cuando corresponda, los cambios de estado, los errores, los tiempos, las señales de coste y la salida final. La documentación de trazas de Galtea describe cómo capturar llamadas a herramientas, operaciones de recuperación, invocaciones de modelos, entradas, salidas, tiempos, errores y relaciones entre procesos.
Empieza por el contrato de la tarea
Antes de elegir métricas, define qué debe hacer el agente y qué no debe hacer. Ese contrato es la referencia frente a la que se evalúa cada traza.
Para un agente de atención al cliente que puede consultar un pedido e iniciar una devolución, el contrato podría establecer lo siguiente:
- El agente puede identificar un pedido a partir de la información que proporciona el cliente.
- Debe verificar la autoridad del cliente antes de mostrar los detalles del pedido.
- Solo puede iniciar una devolución cuando se cumplen las comprobaciones de la política y de elegibilidad.
- No debe aprobar una excepción que requiera revisión humana.
- Debe explicar el siguiente paso cuando una herramienta falla o la solicitud queda fuera de alcance.
El contrato debe separar capacidades, límites y políticas. El flujo de evaluación basado en especificaciones de Galtea utiliza estas categorías para convertir expectativas de comportamiento en métricas y conjuntos de datos. La decisión importante es independiente de la plataforma: define el comportamiento esperado antes de observar una puntuación.
Para cada requisito, define el escenario, el comportamiento esperado, la evidencia, la persona o sistema evaluador y la decisión que se deriva de un fallo. Así, “el agente debe ser fiable” se convierte en una afirmación comprobable como “el agente debe verificar la titularidad de la cuenta antes de llamar a get_order_details”. En un flujo de alto riesgo, mantén conectados el requisito, el escenario, la traza, el resultado de la evaluación, la decisión de revisión y la acción de lanzamiento.
Evalúa las dimensiones que pueden fallar de forma independiente
Utiliza las dimensiones que correspondan a tu arquitectura y mantén sus resultados separados hasta que el equipo entienda cómo interactúan.
| Dimensión | Pregunta que debe responder | Evidencia que se debe revisar |
|---|---|---|
| Comprensión de la tarea | ¿Identificó el agente el objetivo, las restricciones y el resultado necesario? | Entrada, estado de la conversación, tarea interpretada y resultado final |
| Planificación y secuenciación | ¿Eligió una secuencia válida, con las comprobaciones y recuperaciones necesarias? | Orden de los pasos, dependencias y pasos omitidos o repetidos |
| Selección de herramientas y argumentos | ¿Eligió una herramienta permitida y envió argumentos correctos y acotados? | Nombre de la herramienta, validación del esquema, argumentos y contexto de autorización |
| Gestión de resultados de herramientas | ¿Gestionó de forma segura los errores, los resultados vacíos y los conflictos? | Salida de la herramienta, ruta de error, siguiente decisión y explicación |
| Permisos y seguridad | ¿Se mantuvo dentro de la autoridad del usuario y de las políticas del producto? | Identidad, comprobaciones de políticas, aprobaciones y acciones bloqueadas |
| Traspasos y coordinación | ¿Recibió el agente correcto el contexto adecuado y devolvió un resultado utilizable? | Destino del traspaso, información enviada, responsabilidad y estado conservado |
| Estado y memoria | ¿Conservó, actualizó y restringió la información necesaria? | Lecturas y escrituras de estado, origen y metadatos de alcance |
| Resultado final | ¿Completó el flujo la tarea prevista con precisión y de forma completa? | Resultado esperado, respuesta, efectos secundarios y veredicto de revisión |
| Eficiencia | ¿Se mantuvo dentro de los límites aceptables de latencia, tokens y llamadas? | Duración, uso del modelo, reintentos y coste de herramientas |
Estas dimensiones no deben tratar todos los fallos como iguales. Un saludo incorrecto y un pago no autorizado son fallos, pero no deberían tener el mismo umbral de lanzamiento. Define la gravedad y los umbrales según las consecuencias del comportamiento.
La comprensión de la tarea debe comprobarse antes de la ejecución
Evalúa si el agente identificó la intención del usuario, las entidades, las restricciones y el resultado deseado antes de juzgar los pasos posteriores. Comprueba si distinguió una pregunta de una acción, conservó fechas e identificadores, pidió aclaraciones cuando la ambigüedad era real y reconoció las solicitudes fuera del alcance del producto.
La planificación debe evaluarse frente al comportamiento requerido
A menudo hay más de una forma válida de completar una tarea. Evalúa invariantes en lugar de un único recorrido ideal: las comprobaciones necesarias ocurrieron antes de las acciones protegidas, el agente respetó el alcance de las herramientas, las dependencias se cumplieron, el flujo se detuvo o escaló cuando apareció una condición bloqueante y el resultado final se apoyó en la evidencia disponible.
Las llamadas a herramientas necesitan comprobaciones estructurales y semánticas
Un objeto JSON válido no es necesariamente una llamada segura o correcta. Comprueba primero la validez estructural y después si la herramienta era adecuada, si los argumentos se referían a la entidad y al alcance correctos y si la llamada estaba permitida en el estado actual. Una llamada como get_order_details(order_id="1842") puede ser válida estructuralmente y aun así ser incorrecta si no se ha establecido la autoridad.
Los errores de herramientas revelan la ruta de recuperación
Incluye tiempos de espera, resultados vacíos, respuestas mal formadas, fallos de permisos y datos en conflicto. Comprueba si el agente reconoció los resultados incompletos, evitó inventar un éxito, reintentó solo cuando correspondía, utilizó una alternativa permitida y explicó la limitación o escaló el caso.
Los permisos y la seguridad requieren pruebas negativas
Añade casos de acceso a datos de otra persona, intentos de eludir una aprobación, resultados de herramientas que contradicen una política, acciones fuera del rol del usuario, inyección de prompts en contenido recuperado y solicitudes que requieren una decisión humana. Mantén las comprobaciones de políticas separadas de la utilidad general.
Los traspasos deben probarse como transferencias de información
Comprueba el enrutamiento, la conservación del contexto y las restricciones, la minimización de información sensible, la validación de la salida, la devolución de la responsabilidad y la recuperación segura. La página de Galtea sobre sistemas multiagente describe la evaluación de agentes individuales, traspasos, llamadas a herramientas y trayectorias completas.
El estado y la memoria necesitan comprobaciones de alcance y actualidad
Prueba si el agente lee solo el estado relevante, distingue la información actual de la obsoleta, actualiza la memoria únicamente cuando está permitido, evita conservar secretos innecesariamente, mantiene el contexto necesario entre turnos y gestiona explícitamente el estado ausente o contradictorio.
La calidad de la tarea final es la puerta de decisión
Evalúa la corrección, la completitud, el formato solicitado, la fundamentación en resultados de herramientas o recuperación, las divulgaciones necesarias, si se realizó la acción prometida y si el agente indica lo que no pudo hacer. Usa comprobaciones deterministas para resultados estructurados y rúbricas calibradas o revisión humana para texto abierto.
Una traza trabajada muestra dónde comenzó el fallo
Considera un agente de soporte que recibe esta solicitud: “Recibí este portátil como regalo. ¿Puedes devolverlo por mí?” El contrato indica que la persona que realizó la compra original debe iniciar la devolución. La persona que recibió el regalo debe recibir una explicación segura, pero el agente no debe mostrar detalles del pedido ni iniciar la devolución.
| Paso | Comportamiento esperado | Traza observada | Diagnóstico |
|---|---|---|---|
| Comprender la solicitud | Clasificar una solicitud de devolución de la persona que recibió el regalo. | La traza registra requester_type: gift_recipient. | Correcto |
| Comprobar la autoridad | Establecer la autoridad antes de revelar información. | No aparece ninguna comprobación de autorización. | Fallo |
| Seleccionar una herramienta | No llamar a herramientas de pedidos antes de establecer la autoridad. | El agente llama a get_order_details(order_id="1842"). | Fallo |
| Gestionar el resultado | No revelar datos sensibles. | La respuesta incluye la dirección de entrega. | Fallo |
| Completar la tarea | Explicar el siguiente paso aprobado. | La respuesta afirma que se inició la devolución, pero no aparece ninguna mutación. | Fallo |
El primer fallo causal es la ausencia de la comprobación de autoridad. La llamada insegura a la herramienta expuso después los datos y la respuesta final agravó el problema al afirmar que se había producido un efecto que no ocurrió.
La corrección es concreta: exige autorización antes de get_order_details, aplica los permisos en la capa de herramientas o de orquestación, prueba los campos sensibles en los resultados y exige que una afirmación de devolución tenga asociada una mutación registrada. Conserva la traza fallida en el conjunto de regresión.
Usa ciclos de evaluación distintos para decisiones distintas
Las comprobaciones de desarrollo detectan roturas locales
Ejecuta comprobaciones deterministas para esquemas de herramientas, herramientas y modelos permitidos, formatos de salida, permisos, traspasos necesarios, registro de efectos secundarios, tiempos de espera y límites de reintentos. Estas comprobaciones filtran los fallos evidentes antes de una evaluación más costosa basada en modelos.
Las evaluaciones previas al lanzamiento prueban escenarios y riesgos
Antes de lanzar un cambio de prompt, modelo, herramienta, política, recuperación u orquestación, ejecuta un conjunto versionado que cubra tareas correctas, fallos conocidos, ambigüedad, errores de herramientas, violaciones de privacidad, inyección de prompts, casos multilingües, traspasos, recuperación de estado y acciones irreversibles. Compara los mismos escenarios entre versiones y conserva los fallos a nivel de caso, no solo una puntuación agregada.
La plataforma de evaluación de IA de Galtea describe cómo generar conjuntos de datos, definir métricas y umbrales personalizados, comparar versiones, combinar evaluación automática con revisión humana y ejecutar comprobaciones en CI/CD.
La monitorización en producción encuentra fallos nuevos
Las pruebas offline cubren escenarios conocidos. La monitorización en producción revela entradas nuevas, cambios en el comportamiento de las herramientas, cambios de proveedor y combinaciones de estado inesperadas. Conserva suficientes evidencias de la traza para investigar el tipo de tarea, la versión del flujo, las llamadas y resultados de herramientas, los traspasos, los cambios de estado, el resultado, las evaluaciones, la latencia, los reintentos y el coste.
La documentación de monitorización de producción de Galtea describe cómo registrar interacciones reales, asociarlas a sesiones, evaluarlas y utilizar Monitors para puntuar automáticamente sesiones cerradas. Cuando la monitorización encuentra un fallo, inspecciona la primera decisión incorrecta, clasifícala, corrige la capa responsable, añade una reproducción que no exponga datos sensibles y vuelve a ejecutar la comparación de versiones.
Las métricas deben producir una acción siguiente
Evita un único número opaco de “calidad del agente”. Mide el éxito de la tarea, el cumplimiento de los pasos necesarios, las llamadas válidas a herramientas, la selección de la herramienta correcta, la precisión de los argumentos, las acciones no autorizadas, las afirmaciones sin respaldo, la conservación del contexto en los traspasos, los errores de estado, el acuerdo con la revisión humana, la latencia, los reintentos y el coste por tarea completada.
Una tasa baja de llamadas válidas apunta a problemas de gestión del esquema o de construcción de argumentos. Una tasa alta de llamadas válidas con una selección incorrecta de herramientas apunta a la planificación o al enrutamiento. Un buen éxito de tarea con acciones no autorizadas indica un fallo de seguridad oculto por la puntuación del resultado. Una calidad estable con más reintentos y latencia indica una regresión de eficiencia.
Usa comprobaciones deterministas cuando el requisito sea determinista, evaluación basada en modelos para juicios semánticos y revisión humana cuando el requisito dependa de conocimiento de dominio o de una decisión de alto impacto. El flujo de evaluación humana de Galtea describe cómo enviar evaluaciones a revisores para su puntuación manual.
Calibra a los jueces frente a trazas revisadas
Un juez basado en un LLM es un sustituto de la medición, no la verdad absoluta. Muestrea trazas correctas, límite y fallidas. Pide a revisores de dominio que decidan si pasan o fallan y que den razones breves. Escribe la rúbrica alrededor de las distinciones que utilizan los revisores, compara falsos aprobados y falsos fallos, conserva una muestra reservada y envía los desacuerdos de alto riesgo a revisión humana.
Pide al juez que devuelva la dimensión fallida, el paso relevante de la traza, el comportamiento esperado, el comportamiento observado y el motivo del veredicto. Haz la aritmética fuera del juez. Un fallo diagnosticado es más útil que una puntuación sin explicación.
Un marco de evaluación es útil cuando cambia una decisión de lanzamiento
Para cada requisito, el equipo debe poder responder: qué comportamiento se esperaba, qué evidencia se revisó, qué versión y escenario produjeron el resultado, si el agente pasó o falló, cuál fue la gravedad, si el lanzamiento continúa y qué se probará o monitorizará después.
Un buen marco conserva la traza completa, separa las superficies de fallo y conecta cada fallo relevante con una corrección o con una decisión de riesgo explícita. Esa es la diferencia entre comprobar si un agente puede producir una respuesta convincente y evaluar si se le puede confiar el trabajo.
Preguntas frecuentes
¿Cuál es la métrica más importante para un agente de IA?
Empieza por el éxito de la tarea y añade las métricas a nivel de paso necesarias para explicar el fallo. En un agente que utiliza herramientas o trabaja en un contexto de alto riesgo, el éxito de la tarea por sí solo no basta porque una acción no autorizada puede quedar oculta por una respuesta final correcta.
¿Debo evaluar el plan o solo la respuesta final?
Evalúa ambos cuando el plan afecta a la seguridad, el coste, la latencia, los permisos o la fiabilidad. Un evaluador de la respuesta final no puede detectar de forma fiable un paso de verificación omitido o un argumento de herramienta incorrecto si la traza no contiene esa evidencia.
¿Cómo evalúo un agente que no expone su razonamiento interno?
No necesitas la cadena de pensamiento oculta. Inspecciona eventos observables como las llamadas a herramientas, los argumentos, los resultados, los traspasos, los cambios de estado, las decisiones de política, los tiempos y el resultado final.
¿Puede un evaluador bloquear una acción insegura antes de que ocurra?
Un evaluador que se ejecuta después de producir la traza detecta y monitoriza. Un control que debe impedir una acción pertenece al flujo síncrono de autorización, herramientas u orquestación. Evalúa ese control por separado.
¿Cómo ayuda Galtea a evaluar agentes de IA?
Los materiales públicos de Galtea describen la evaluación de pasos individuales de agentes, traspasos, llamadas a herramientas y trayectorias completas, seguida de la comparación de versiones antes del lanzamiento y la monitorización de flujos reales después del despliegue. La configuración adecuada depende de la arquitectura del agente, de las evidencias que pueda exponer y de los requisitos de riesgo del equipo.
