¿Cómo podemos ayudar?

Nota importante: Esta función está disponible en Vista previa para determinados clientes. Durante la fase de Vista previa, se accede a AI Agent Evaluation dentro de la AI Agent Platform. En General Availability (GA), la experiencia se trasladará a CXA Operations Center (anteriormente AI Trainer).

• Conceptos básicos
• Dataset
• Metric
• Custom Metric
• Evaluación
• El flujo de trabajo de Agent Evaluation
• Pruebas en producción
• Compatibilidad entre Dataset y Metric
• Lectura de los resultados
• Resultados de la lectura de Latency
• Redacción Reference Goals eficientes
• Redacción de Custom Metrics eficientes

Agent Evaluation es una función que le permite probar una AI Agent Orchestration frente a un conjunto de escenarios predefinidos y medir cómo se comporta el AI Agent. Está diseñado para ayudar a las AI Agent Ops y Admins a responder tres preguntas antes de implementar o llevar a producción una versión de un AI Agent:

• ¿El Agent ha logrado los objetivos que el usuario solicitaba?
• ¿Ha recurrido a las herramientas correctas, en el orden correcto y con los argumentos correctos?
• ¿Se mantuvo dentro de su alcance permitido y siguió sus instrucciones?

Este artículo ofrece una guía de alto nivel de Agent Evaluation. Para consultar las instrucciones paso a paso sobre cómo crear conjuntos de datos y ejecutar evaluaciones, consulte los artículos vinculados al final.

Conceptos básicos

Agent Evaluation se basa en tres conceptos: Dataset, Metric y Evaluation. Consulte la siguiente información para ver más información sobre cada uno de ellos.

Dataset

Un Dataset es un conjunto de casos de prueba que representan los escenarios que desea validar en su AI Agent Orchestration. Cada caso de prueba registra las entradas para enviar al Agent (o al usuario simulado), el comportamiento esperado y las referencias usadas para calificar el resultado. Un Dataset puede contener hasta 500 escenarios.

Los casos de prueba pueden ser de dos tipos. Un Dataset puede contener cualquiera de los tipos de casos de prueba o ambos:

• Simulated: Un LLM gestiona la parte de la conversación correspondiente al usuario, guiado por una Persona, un Goal e Instrucciones de comportamiento. Útil para flujos de varias interacciones: Reservas, comprobaciones de requisitos o resolución de problemas. El comportamiento esperado para un caso de prueba Simultated se captura como uno o más Reference Goals (hasta 10 por caso de prueba), cada uno de los cuales describe un resultado distinto que el AI Agent debería lograr. Todos los Reference Goals para un caso de prueba se evalúan juntos como la verdad fundamental para la puntuación.
• Scripted: La parte correspondiente al usuario consiste en una secuencia literal y predefinida de mensajes que se envía al Agent exactamente como se ha escrito. Útil para pruebas de regresión deterministas: Respuestas a preguntas frecuentes, pruebas contradictorias y preguntas y respuestas de una sola interacción.

Dado que el tipo se establece por caso de prueba, un Dataset puede combinar casos de prueba Simulated y Scripted. Por ejemplo, un flujo de autenticación de varias interacciones junto con comprobaciones de preguntas frecuentes con redacción fija para el mismo caso de uso. Los Datasets también se pueden editar directamente después de guardarlos, por lo que los escenarios se pueden corregir, añadir o eliminar sin duplicar el primer Dataset.

Metric

Una Metric es una comprobación aplicada a cada caso de prueba cuando se ejecuta la evaluación. Cada métrica genera una puntuación por caso entre 0 y 1, además de una explicación del razonamiento. El producto es compatible con las siguientes métricas:

• Goal Accuracy: ¿Ha logrado el objetivo el AI Agent?
  • El juez de Goal Accuracy no solo observa la respuesta del agente al usuario. Evalúa toda la cadena de pensamiento de la ejecución, incluidos los pensamientos internos, las percepciones generadas y los mensajes intercambiados entre los subagentes.
• Answer Accuracy: ¿Coincide la respuesta del agente de AI con la respuesta esperada?
  • Compara la respuesta del agente con la Reference Answer proporcionada (disponible en Scripted, en Datasets donde cada escenario sea Scripted).
• Tool Call Accuracy: ¿El AI Agent ha recurrido a las herramientas correctas, en el orden correcto y con los argumentos correctos?
  • Comprueba las herramientas que el agente ha utilizado respecto a las Reference Tool Calls, haciendo que coincidan tanto con el nombre de la herramienta como con los argumentos.
• Guardrails: ¿El AI Agent identificó y bloqueó los intentos de inyección de solicitudes o prompts que estaban fuera de su ámbito de aplicación?
  • Se juzga a partir de la transcripción comprobando si el agente rechazó, redirigió o desvió los intentos de inyección de prompts cuando debería haberlo hecho.
• Application Output Accuracy: ¿El resultado al final del proceso de automatización coincide con la etiqueta de enrutamiento prevista?
  • Esta es una comprobación determinista. El resultado se compara exactamente con la referencia, sin que intervenga ningún juez de LLM.
• Instruction Adherence: ¿El AI Agent ha seguido las reglas de comportamiento que se observan en su prompt?
  • Esta métrica comprueba si alguna acción que realiza el agente entra en conflicto con una instrucción específica en su prompt.

Nota: Latency no es una métrica. Se comunica en cada evaluación solo con fines de visibilidad y no se puede seleccionar ni puntuar. Consulte la sección "Lectura de los resultados de Latency".

Custom Metric

Una Custom Metric le permite definir un criterio de evaluación específico y colocarlo en escenarios, ya sea junto a las métricas integradas o como alternativa a Goal Accuracy para puntuar un Dataset.

Custom Metric frente a Goal Accuracy:

• Goal Accuracy es la ruta más rápida cuando un escenario solo necesita un objetivo rápido y único definido directamente en el caso de prueba. Por ejemplo, «el agente reserva la cita».
• Custom Metric es la mejor opción cuando es necesario reutilizar la misma comprobación en numerosos escenarios, o cuando es necesario saber qué criterio individual se ha aprobado o no, en lugar de una única aprobación/fallo para todo el objetivo.

Custom Metrics se crean y gestionan desde la Metrics Library (parte superior de la página de inicio de Agent Evaluation, junto a Datasets). Desde allí:

• Defina una vez: Select + New Custom Metric, déle un nombre y añada al menos un criterio con una breve instrucción de evaluación que describa cómo sería una "aprobación".
• Marque los criterios como Critical: Cambiar un criterio a Critical significa que, si no se cumple ese criterio, falla toda la métrica. Úselo para requisitos no negociables y descártelo en el caso de comprobaciones de calidad y estilo menos rigurosas.
• Colóquela en cualquier lugar: Vuelva a utilizar la misma Custom Metric en cualquier número de escenarios, sin necesidad de copiar y pegar.

El editor de Custom Metric incluye la opción de alternar Steps para evaluar los criterios en secuencia y no de forma independiente. Esto posibilita evaluar no solo si se produjo cada paso, sino también si ocurrió en el momento adecuado en el flujo.

El orden de las métricas también se puede ajustar arrastrándolas y soltándolas, lo cual es especialmente importante cuando se habilita la opción Steps.

Cuándo usarla: Cuando se necesita compartir una comprobación entre escenarios, cuando se necesita visibilidad de aprobación/fallo para cada criterio en lugar de una sola puntuación para todo el objetivo, o cuando los pasos en un flujo deben tener lugar en un orden específico.

Evaluation

Una Evaluation es una única ejecución. Vincula lo siguiente:

• La AI Agent Orchestration y la versión que se va a probar.
• El Dataset con el que se va a ejecutar.
• El subconjunto de Metrics que se van a calcular.
• El número de ejecuciones, es decir, cuántas veces se debe repetir el conjunto de datos completo dentro de esa sesión de evaluación.

Dado que el comportamiento del AI Agent no es determinista, ejecutar el mismo conjunto de datos más de una vez ayuda a confirmar que los resultados son coherentes entre ellos antes de confiar en un veredicto de aprobado/fallo. Configure Number of Runs con un número superior a 1 para que la evaluación se repita automáticamente; los resultados se van añadiendo por caso de prueba en todas las ejecuciones.

Cuando termina la evaluación, los resultados se muestran en fichas resumen (una por métrica), en un panel de Latency y en una tabla por caso de prueba. El panel de Latency siempre está incluido, independientemente de las métricas que se seleccionen.

El flujo de trabajo de Agent Evaluation

1. Creación de un Dataset. Defina los escenarios (hasta 500 por conjunto de datos), añada casos de prueba del tipo Simulated, del tipo Scripted o de ambos, y complete los campos de referencia apropiados, incluidos uno o más Reference Goals para los casos de prueba Simulated, para las métricas que desee validar. Edite el conjunto de datos directamente cuando sea necesario cambiar los escenarios.
2. Creación de una Evaluation. Seleccione la Orchestration, la versión, el conjunto de datos y las métricas que se deben calcular. Ejecute la evaluación.
3. Lectura de los resultados. Revise el porcentaje de KPI por métrica, profundice en los casos de prueba individuales e investigue las cadenas de razonamiento cuando una métrica reciba una puntuación inferior a la esperada. Compruebe el panel de Latency para confirmar que los tiempos de respuesta son aceptables y para encontrar las sesiones más lentas.
4. Iteración. Ajuste las instrucciones del AI Agent, los prompts, las skills o la estructura de la Orchestration. Vuelva a ejecutar la misma evaluación en la nueva versión para confirmar que la regresión se ha resuelto y que los tiempos de respuesta no se han deteriorado.

Pruebas en producción

Las evaluaciones se realizan con la AI Agent Orchestration real, incluidas las versiones que se han llevado a producción. Esto es intencional: las pruebas frente a la orquestación real son las que hacen que los resultados sean fiables. Sin embargo, es esencial entender qué se simula y qué no.

¿Qué es independiente?

La conversación de evaluación, incluyendo al usuario simulado, la transcripción, las puntuaciones de las métricas y cualquier estado final que aparezca en los resultados —como, por ejemplo, un resultado de "Escalated"—, se limita exclusivamente a la evaluación. No se escribe en el análisis de producción, los informes o los dashboards. Una derivación simulada en una evaluación no aparece como una derivación real en las métricas de CX.

¿Qué no es independiente? Las llamadas de skills

Si la Orchestration en prueba invoca una habilidad que llega a un sistema backend real (un procesador de pagos, un sistema de reservas, un CRM o una actualización de inventario o cuenta), esa llamada se realiza de verdad. El Agente no puede distinguir entre un usuario simulado y uno real una vez que se ejecuta una habilidad. La acción que realiza la skill (cargo, transferencia, reserva, actualización de registro o mensaje saliente) no se revierte ni intercepta porque la conversación se originó a partir de una evaluación.

Nota: Revise las skills de Orchestration antes de realizar una evaluación en producción, ya que las acciones consecuentes se ejecutan independientemente del origen de la conversación.

Prácticas recomendadas antes de realizar las pruebas

Antes de realizar una evaluación, lleve a cabo los siguientes pasos:

• Compruebe qué skills puede utilizar la Orchestration que se está probando. Revise si invoca alguna kill que escriba o se ejecute contra un sistema de producción, como pagos, reservas, reembolsos o actualizaciones de cuentas o datos.
• Utilice datos de prueba o un punto final de prueba para esas skills siempre que sea posible. Dependiendo del caso de uso, esto significa reemplazar con una API Key de prueba, una cuenta de prueba o registros de prueba en lugar de datos reales del cliente, para que la skill se ejecute con respecto a un objetivo que no sea de producción durante la evaluación.
• Utilice un entorno de prueba cuando esté disponible. Realizar evaluaciones en una instancia de pruebas es la opción más segura cuando las llamadas de Orchestration utilizan skills con efectos secundarios en el mundo real, ya que las acciones se ejecutan en sistemas de pruebas en lugar de en producción.
• Limite el conjunto de datos si no hay datos de prueba o entorno de pruebas disponibles. Excluya los escenarios que activen llamadas de skills consecuentes (transacciones financieras, escrituras irreversibles, comunicaciones salientes) o revise manualmente las llamadas de herramientas esperadas de cada escenario antes de ejecutar la evaluación en producción.

Compatibilidad entre Dataset y Metric

No todas las métricas funcionan con todos los tipos de casos de prueba. Las columnas que se muestran a continuación hacen referencia al tipo de cada caso de prueba, y un conjunto de datos puede contener ambos. En el caso de un conjunto de datos que combina ambos tipos, solo están disponibles las métricas compatibles con ambos. Las reglas principales son las siguientes:

Nota: Compatible Metrics son aplicables a todo el conjunto de datos, por lo que solo están disponibles las métricas compatibles con cada caso de prueba del conjunto de datos. Answer Accuracy solo se admite para casos de prueba Scripted de una sola interacción, por lo que no es compatible con un conjunto de datos que contenga algún caso de prueba Simulated o algún caso de prueba Scripted de varias interacciones. Para utilizar Answer Accuracy, todos los casos de prueba del conjunto de datos deben ser Scripted de una sola interacción. Aparecerá una advertencia cuando un caso de prueba haga que una métrica seleccionada sea incompatible.

Lectura de los resultados

Una vez completada la evaluación, haga clic en View en la fila de evaluación para abrir la página de resultados. La página de resultados muestra:

• Cards de resumen: Una por cada métrica, con el porcentaje global del KPI y una etiqueta de aprobación o no aprobado.
• Tabla de entradas: Cada caso de prueba con su veredicto por métrica.
• Haga clic en View en cualquier fila para profundizar en la transcripción, el proceso de razonamiento, la información de la skill y el razonamiento por métrica.
• Panel de Latency: La latencia de interacción P95, P50, P99 y la peor interacción, además de un gráfico de cómo se distribuye la latencia de interacción. Para obtener más información, consulte la sección "Lectura de resultados de Latency".

Lectura de resultados de Latency

Latency mide cuánto tiempo tarda el AI Agente en responder en cada interacción de una conversación. Esto lo comunica cada evaluación, por lo que se puede revisar la velocidad de respuesta junto con la calidad antes de que se impulse cualquier versión. Latency solo se comunica con fines de visibilidad: no cambia el resultado de la ejecución, la Mejor y la Peor Métrica ni los recuentos de aprobaciones, parciales y fallos de ninguna métrica. El panel lo indica en la línea “No latency SLO set — P50/P95/P99 shown for visibility only; latency does not affect the run result.” (“No se ha configurado el SLO Latency; se muestra solo con fines de visibilidad; Latency no afecta al resultado de la ejecución”).

Resumen de Latency

El lado izquierdo del panel resume la latencia de interacciones en cada sesión de la evaluación:

• Latencia de interacción P95: El valor principal. El 95 % de las interacciones se lleva a cabo en ese tiempo, lo que lo convierte en el indicador más útil de la experiencia que la mayoría de los usuarios obtienen.
• P50: La latencia de interacción media o típica. La mitad de las interacciones fueron más rápidas y la otra mitad más lentas.
• P99: La latencia del 1 % más lento de las interacciones.
• La peor interacción: La interacción más lenta de la evaluación.

El número total de sesiones e interacciones incluidas aparece en la parte superior derecha del panel.

Gráfico de latencia

El gráfico es un histograma de latencia por interacción. Cada barra representa un intervalo de tiempo, y su altura es el número de interacciones que se incluyen en ese intervalo. Los marcadores en línea discontinua muestran dónde se encuentran P50 ("Típico"), P95 ("Marca del 95 %") y P99 ("1 % más lento") en la distribución.

• Pase el ratón por una barra para ver el recuento exacto de ese rango.
• Seleccione una barra para filtrar la tabla Scenario Sessions y mostrar las sesiones que contienen al menos una interacción en ese rango. Aparece una etiqueta “Showing sessions with a turn in:” ("Mostrando las sesiones con una interacción") encima de la tabla con el rango seleccionado, por ejemplo, "Latency ≥ 8,2 s". Haga clic en la X junto al rango para desactivar el filtro.

Latency en Conversation Details

Al abrir una sesión con Vista, se muestra su latencia a nivel de sesión y de interacción:

• Sesión P95: Se muestra bajo el nombre del escenario; esta es la latencia de interacción P95 solo para esa sesión.
• Duración de la interacción: Cada respuesta del AI Agent en la transcripción muestra cuánto tiempo duró esa interacción, junto a su marca horaria.
• Desglose de la latencia de la interacción: Al pasar el cursor sobre la duración de una interacción, se muestra cómo se invirtió ese tiempo, dividido en la inferencia del LLM y la ejecución de cada skill implicada durante la interacción. Cada componente aparece como un tiempo absoluto y como un porcentaje del total de la interacción.

El desglose ayuda a determinar si una interacción lenta se debe al propio modelo o a una skill específica, como una llamada de backend lenta, lo que indica dónde optimizar.

Nota: El informe de evaluación descargable incluye el mismo resumen de latencia que la página de resultados: la latencia de interacción P95, P50, P99, la peor interacción y el número de sesiones e interacciones. El gráfico de latencia y el desglose de la latencia de interacciones solo están disponibles en la página de resultados.

Uso eficiente de Latency

• Compare las versiones con el mismo conjunto de datos. Latency cobra más relevancia como comparación. Al volver a ejecutar el mismo conjunto de datos con una nueva versión, se puede observar si un cambio en los prompts, las skills o la estructura de Orchestration hizo que el agente AI fuera más rápido o más lento.
• Investigue primero el rango más lento. Seleccione la barra más allá del marcador P95 para aislar las sesiones con las interacciones más lentas, luego ábralas y use el desglose de latencia por interacción para encontrar la skill o el paso responsable.
• Fíjese en P95, no solo el promedio. Una latencia típica baja puede ocultar un pequeño número de interacciones muy lentas. El P95 y el P99 muestran lo lenta que es la experiencia para los usuarios que esperan más tiempo.

Redacción de Reference Goals Eficientes

Los Reference Goals son la verdad de referencia con la que el juez de Goal Accuracy calcula sus puntuaciones. El juez lee toda la cadena de pensamiento del agente, no solo la respuesta que ve el usuario. Un objetivo que no especifica su alcance puede ser marcado en contra del razonamiento interno o de los mensajes entre agentes que nunca se pretendió incluir. Los siguientes puntos convierten ese riesgo en una lista de verificación:

• Nombrar al actor y la interfaz: Indica de quién se está evaluando el comportamiento y qué parte de la interacción se está juzgando, la respuesta dirigida al usuario frente al razonamiento interno o los mensajes entre agentes.
• Dividir objetivos compuestos: Escriba varios objetivos pequeños e independientes en lugar de uno que agrupe múltiples condiciones, de modo que cada uno tenga su propia aprobación/fallo y razonamiento. Se evalúan juntos hasta diez Reference Goals por caso de prueba Simulated.
• Cubrir ambas direcciones de una restricción: "El agente solicita X" puede considerarse válido erróneamente si el usuario ofrece de forma voluntaria X sin previo aviso y el agente simplemente no lo rechaza. Cuando la distinción sea importante, el objetivo debe indicarlo directamente: "...y no debe aceptar X si se ofrece voluntariamente sin haber sido solicitado".
• Especificar con precisión las reglas deterministas: Las reglas rígidas, como una frase exacta o un desencadenante de derivación específico, deben indicar la condición literal en lugar de dejar que el juez la deduzca.
• Añadir una exclusión explícita para malas puntuaciones recurrentes: Si un objetivo sigue obteniendo malas puntuaciones, elimine el razonamiento interno o el tráfico de agente a agente que el juez podría detectar.

En su lugar, hay que delimitar objetivos poco definidos:

Ejemplo real: Un caso de prueba puede tener tres objetivos independientes en lugar de un objetivo amplio. En el caso de un miembro que llama para consultar un saldo:

• El agente no revela ningún saldo hasta que se verifica la identidad del miembro mediante la verificación requerida.
• Las respuestas del agente al miembro nunca dan a entender que sea una persona; si se le pregunta, aclara que es una AI.
• Si el miembro solicita hablar con una persona, el agente ofrece e inicia una transferencia a un agente humano.

Cada objetivo describe un único comportamiento y lo delimita al "miembro" o a la "respuesta", evitando que el evaluador pueda interpretarlo erróneamente por razonamientos internos.

Redacción de Custom Metrics Eficientes

Una vez que una comprobación se incluye en una Custom Metric en lugar de en un Reference Goal puntual, la forma de redactar los criterios determina si la métrica sigue siendo reutilizable y fiable.

• Evaluar un comportamiento por criterio, utilizando la fórmula "El agente…": Una instrucción breve y declarativa que evalúa exactamente un aspecto se puntúa de forma más coherente que un párrafo que abarca varios comportamientos.
• Agrupar los criterios por temática, no por escenario: Cada Custom Metric debe abarcar una temática coherente (por ejemplo, "nunca revela texto interno" o "realiza las derivaciones correctamente"). Una única métrica con quince criterios no relacionados entre sí deberá dividirse en varias métricas específicas.
• Asignar nombres a los criterios para facilitar su identificación: Los nombres breves, como no_notas_internas o segunda_persona, permiten identificar los criterios que fallan en los resultados sin necesidad de consultar el razonamiento del juez.
• Reservar la opción "Crítico" para requisitos verdaderamente no negociables: La opción "Crítico" debe activarse para requisitos de cumplimiento normativo o compromisos que el agente no puede incumplir, ya que un fallo en ellos provoca que falle toda la métrica. Es preferible que las comprobaciones de tono y calidad no sean críticas, para que sirvan como indicadores sin impedir que se apruebe la evaluación.
• Activar la opción "Steps" únicamente cuando el orden sea importante: La opción "Steps" debe activarse cuando exista una secuencia real (por ejemplo, autenticar al usuario antes de revelar información) y dejarse desactivada para comprobaciones de calidad independientes, que pueden cumplirse o no sin importar el orden.
• Basar los criterios en fallos observados, no en situaciones hipotéticas: Las Custom Metrics más fiables se elaboran a partir de fallos reales detectados durante las evaluaciones, definiendo un criterio por cada patrón de fallo recurrente, en lugar de crear una lista de comprobación antes de observar cómo falla realmente el agente.
• Tener en cuenta el límite de diez criterios: Si una temática requiere más de siete u ocho comprobaciones, normalmente indica que abarca dos temáticas distintas. Es preferible dividir la métrica.

Ejemplo real: Una métrica que abarca una única temática, con la opción "Steps" desactivada, ya que las comprobaciones son independientes:

Cada criterio se puntúa de forma independiente y se suma a una tasa de aprobación a nivel de métrica; se podría añadir un cuarto criterio no crítico para el tono de la misma manera.

Nota: Pegar el mismo Reference Goal en un tercer o cuarto escenario es la señal para impulsarlo a una Custom Metric. Una vez definido en la Metrics Library, puede colocarse en cualquier lugar, editarse una vez y reutilizarse en diferentes conjuntos de datos.