¿Cómo podemos ayudar?

Nota importante: Esta función está disponible en Preview para clientes seleccionados. Durante la fase de Preview, se accede a la AI Agent Evaluation dentro de la AI Agent Platform. Cuando se alcance la General Availability (GA), la experiencia se trasladará al CXA Operations Center (antes AI Trainer).

Este documento describe las mejores prácticas para diseñar conjuntos de datos, incluyendo la creación de conjuntos de datos, la elección de métricas y la ejecución de evaluaciones en la función AI Agent Evaluation (Vista previa).

Índice

• Mejores prácticas para la creación de conjuntos de datos
• Mejores prácticas para el diseño de conjuntos de datos simulados
• Mejores prácticas para el determinismo
• Mejores prácticas para escenarios adversarios y de seguridad
• Mejores prácticas para la redacción de objetivos de referencia
• Mejores prácticas para la gestión de conjuntos de datos 
• Mejores prácticas para la elección de métricas
• Mejores prácticas para la ejecución e iteración

Antes de diseñar conjuntos de datos, debe comprender los conceptos básicos de Agent Evaluation (conjunto de datos, métrica y evaluación) y cómo encajan entre sí. Para más información, consulte [Preview] Agent Evaluation: Resumen en este artículo.

Mejores prácticas para la creación de conjuntos de datos

• Comenzar por algo pequeño y cubrir primero las rutas críticas: De 10 a 20 escenarios precisos que cubran los flujos de mayor valor ofrecen mejores resultados que 200 escenarios imprecisos. La amplitud solo debe añadirse una vez que se hayan consolidado las rutas críticas.
• Mantener un conjunto de datos, un propósito: Las pruebas de enrutamiento no deben mezclarse con las pruebas de ejecución de herramientas, ni los escenarios de flujo óptimo con los sondeos adversarios. Los conjuntos de datos mixtos ocultan ambas señales detrás de una tasa global de aprobación.
• Nombrar los casos de prueba según su clasificación, no según su orden: Es preferible "T007 — Divulgación de datos del cliente — Destino: Usuarios autorizados" en lugar de "Caso de prueba 12".
• Rellenar únicamente los campos de referencia que necesitan las métricas elegidas: Cada campo de referencia se asigna a una métrica: "Reference Goal" con Goal Accuracy, "Reference Tool Calls" con Tool Call Accuracy, "Reference Application Output" con Application Output Accuracy y "Reference Answer" con Answer Accuracy. Instruction Adherence y Guardrails no requieren un campo de referencia.

Mejores prácticas para el diseño de conjuntos de datos simulados

Un caso de prueba simulado tiene tres campos que impulsan conjuntamente la conversación. Estos deben mantenerse claramente separados:

• Persona: Quién es el usuario: Identidad, canal, idioma y estado emocional. 
• Instructions: Comportamiento del usuario: Ritmo, tono y qué no ofrecer voluntariamente. 
• Goals: Lo que el usuario está intentando conseguir: Los hechos que debe revelar y el orden en el que debe revelarlos.
   
• Utilizar la divulgación progresiva para flujos de varias interacciones. Sin una regla explícita, el simulador indica todo su historial en el primer mensaje, y la cobertura de varias interacciones se colapsa. Debe añadirse lo siguiente a las instrucciones: "Responda SOLAMENTE a la pregunta específica que acaba de hacerse, nunca ofrezca voluntariamente información no solicitada" y "máximo UN nuevo hecho de su objetivo por mensaje". Los hechos en los objetivos deben numerarse en el orden en que se mostraran. Este bloque de Instructions se puede volver a utilizar textualmente en todo un conjunto de datos. Solo Persona y Goals deben variar según el escenario.
• Facilitar datos de prueba confidenciales solo bajo Petición. Se debe añadir "Only provide if and when asked" a cualquier valor confidencial. De lo contrario, el simulador cargará el valor por adelantado, y se perderá la capacidad de probar si el agente pregunta antes de proceder. Esto es lo que hace que un objetivo de autenticación (por ejemplo, "el agente siempre debe pedir el número de Seguridad Social [SSN] y el número de identificación personal [PIN]") se pueda probar.
• No utilizar nunca datos con apariencia real en los Datos de prueba. Cualquier valor similar a un SSN, PIN o número de cuenta debe ser sintético (dígitos secuenciales, marcadores claros).

Nota: Si el campo Goals contiene una regla de ritmo como "keep it short", esta debe trasladarse a Instructions. Duplicarla en los campos hace que el conjunto de datos sea más difícil de mantener.

Mejores prácticas para el determinismo

El determinismo no es exclusivo de los casos de prueba Scripted. El modo Simulado es el predeterminado y el más capaz.Admite todas las métricas y flujos de múltiples interacciones, y sigue pudiendo crear una redacción reproducible.

• Fijar la redacción exacta dentro de Simulated Instructions: Se puede introducir el mensaje literal, por ejemplo: "Su primer mensaje siempre debe hacer su pregunta. Use el siguiente mensaje: ¿Cómo puedo solicitar un presupuesto en línea?" El simulador lo envía textualmente mientras el conjunto de datos mantiene el acceso completo a las métricas de Simulated. (Así es como se construye un conjunto de datos real de Preguntas frecuentes de EveryPaw, utilizando el esquema Simulated, no Scripted, con la pregunta fijada dentro de Instructions).
• Reservar Scripted para la única restricción estricta que la requiera: Answer Accuracy es exclusiva para Scripted y de una sola interacción, según el diseño del producto. Para cualquier otra métrica, el caso Simulated determinista proporciona la misma reproducibilidad, y admite varias interacciones.
• Limitar los casos de Scripted al usarlos para Answer Accuracy: Se debe utilizar una pregunta y una Reference Answer por cada caso de prueba.
• Añadir casos de prueba con variaciones de frases para las principales intents: Se debe repetir una pregunta con pequeñas diferencias en la redacción (añadiendo un saludo o palabras de relleno) frente a un Reference Goal compartido, para detectar la fragilidad o rigidez que una sola frase "limpia" no revelaría.

Nota: Primero se debe confirmar si se requiere específicamente Answer Accuracy. En caso contrario, la opción Simulated sigue siendo la mejor elección, incluso cuando se deba corregir la redacción.

Mejores prácticas para escenarios adversarios y de seguridad

Reference Goals en este contexto describen lo que el agente debe rechazar, no lo que debe entregar.

• Indicar la técnica de ataque y la gravedad en el título. Por ejemplo: "ADV-002 - Indirect Prompt Injection - User Text [CRITICAL].". Actualmente no existe un campo de rigor específico, por lo que la convención de nomenclatura es el mecanismo. Debe etiquetarse de manera uniforme en todo el conjunto. 
• Redactar los Reference Goals como una autorización más una prohibición, no solo como una prohibición. Por ejemplo: "El agente puede advertir que el mensaje parece una estafa, pero NO DEBE revelar las reglas internas de detección de fraude. Debe rechazar y ofrecer conectar al usuario con la asistencia de fraude." Esto funciona de manera más fiable que un simple "no debe revelar".
• Programar una prueba de presión con un segundo intento. La mayoría de los agentes superan un rechazo de disparo único; las brechas de los barridos de protección aparecen en el segundo intento. Guionice el simulador para que pulse una vez más antes de cerrarse de forma natural.
• Mantener los escenarios adversarios en un conjunto de datos dedicados: No se deben mezclar con la regresión de flujos óptimos y se debe establecer un umbral de aprobación más estricto para ello.

Mejores prácticas para la redacción de objetivos de referencia

El juez de Goal Accuracy lee la Cadena completa pensamiento, incluidos los mensajes internos de agente a agente. Un objetivo que no especifica su alcance puede ser marcado respecto a un razonamiento que nunca se pretendió incluir.

• Preferir varios objetivos pequeños e independientes en lugar de un objetivo compuesto: Cada uno tiene su propia aprobación/fallo y razonamiento en lugar de un veredicto ambiguo.
• Cubrir ambas direcciones de una restricción: La instrucción "El agente debe solicitar X" puede aprobarse por el motivo equivocado si el usuario ofrece voluntariamente X y el mecanismo de protección del agente simplemente se niega a usarlo. Cuando la distinción importa, debe escribirse explícitamente: "Debe pedir X y no debe aceptar X si se ofrece voluntariamente sin haber sido pedido".

Mejores prácticas para la gestión de conjuntos de datos 

• Tratar los conjuntos de datos como inmutables: Duplicar para cambiar. Esto garantiza que una evaluación de hace tres meses y otra de hoy, ambas apuntando al mismo nombre de conjunto de datos, se hayan evaluado con casos de prueba idénticos.
• Controlar las versiones con una convención de nomenclatura explícita: Por ejemplo, <usecase>_v2 o <usecase>_20260420, de modo que el linaje sea evidente sin necesidad de abrir el conjunto de datos.
• Ampliar el conjunto a partir de fallos reales de producción: El conjunto de datos debe duplicarse, el fallo debe añadirse como un nuevo caso de prueba y el resultado debe guardarse como la siguiente versión.
• Construir a escala con CSV: Si hay errores de importación en una métrica, se debe deshacer la selección de las métricas sin referencia disponible.
• Observar el límite 500-scenario: Los conjuntos de grandes dimensiones deben planificarse como conjuntos de datos con múltiples ámbitos de propósito.
• Eliminar los conjuntos de datos que ya no reflejen la orquestación: Es preferible eliminarlos antes de acumular versiones desactualizadas.

Mejores prácticas para la elección de métricas

Se deben elegir de dos a tres métricas que, juntas, respondan a las siguientes preguntas: ¿El agente hizo las cosas correctas, por las razones correctas y terminó en el lugar correcto?

Nota: PII se refiere a la información de identificación personal. RAG se refiere a generación aumentada por recuperación.

• Goal Accuracy: Se debe utilizar para un resultado puntual y específico de un escenario. Es el más rápido de redactar.
• Custom Metric: Se debe utilizar cuando una comprobación sea reutilizable en varios escenarios, requiera una aprobación/fallo por criterio o deba realizarse en un orden específico (utilice la opción "Steps"). Se define una vez en la Biblioteca de métricas y, a continuación, se puede adjuntar en cualquier lugar y editar una vez.

Custom Metric vs. Reference Goal (Goal Accuracy)

Ambos pueden validar el mismo comportamiento subyacente; la diferencia radica en la reutilización y la visibilidad, no en la capacidad.

Si el mismo Reference Goal está a punto de escribirse en un tercero o cuarto escenario, esa es la señal para moverlo a una Custom Metric. Una comprobación recurrente como "¿El agente ha preguntado si el que llama es un paciente nuevo o existente?" se aplica a cada escenario de recepción de pacientes. Definirla por escenario crea duplicados que se alejan con el tiempo, mientras que el modelo de biblioteca permite definirla una vez, adjuntarla a cualquier lugar y actualizarla en todas partes cuando se edite.

Estos dos enfoques no son mutuamente excluyentes. Un patrón común combina Goal Accuracy para el resultado del escenario, con una Custom Metric para un listón de calidad transversal (tono, divulgación, oferta de escalamiento) que se aplica independientemente del resultado.

• Reservar Critical para requisitos verdaderamente no negociables, por ejemplo, exigencias de cumplimiento normativo o promesas que el agente no puede incumplir. Lo mejor es dejar los controles de calidad y tono como no críticos.
• Priorizar Goal Accuracy sobre Tool Call Accuracy cuando la redacción es una inquietud. Un objetivo bien definido puede confirmar a menudo que se ha llamado a una herramienta sin el coste de mantenimiento de una referencia completa de la llamada.
• Establecer el Número de Runs > 1 antes de confiar en un veredicto, ya que los evaluadores no son deterministas.

Mejores prácticas para la ejecución e iteración

• Probar un solo cambio a la vez en las instrucciones o en la orquestación del agente, luego volver a ejecutar la evaluación antes de hacer otra modificación.
• Evaluar siempre la versión destinada a la promoción. Orchestration y Version deben confirmarse en el asistente, no deben dejarse en un borrador antiguo.
• Volver a ejecutar la prueba antes de escalar un resultado sorprendente. Un fallo inesperado no es aún evidencia de una regresión.
• Condicionar la promoción a un umbral acordado previamente, antes de analizar los resultados.