¿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 laAI 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 adversas y de seguridad
• Mejores prácticas para redactar Reference Goals
• Mejores prácticas para la gestión de conjuntos de datos
• Mejores prácticas para elegir métricas
• Mejores prácticas para ejecutar e iterar

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 obtener más información, consulte [Vista previa] Agent Evaluation: Resumen en este artículo.

Mejores prácticas para crear conjuntos de datos

• Comience por algo pequeño y abarque primero las rutas críticas:Entre 10 y 20 escenarios precisos que cubran los flujos de mayor valor superan a 200 que se descuiden. La amplitud solo debe añadirse una vez que se hayan consolidado las rutas críticas.
• Mantenga 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 rutas satisfactorias con las pruebas adversas. Los conjuntos de datos mixtos ocultan ambas señales detrás de una tasa global de aprobación.
• Ponga nombre a los casos de prueba a efectos de clasificación, y no una secuencia: "T007 — Divulgación de datos del cliente — Objetivo: Usuarios autorizados" es preferible a "Caso de prueba 12".
• Cumplimente únicamente los campos de referencia que necesitan las métricas elegidas: Cada campo de referencia se corresponde con una métrica: "Objetivo de referencia" con la precisión del objetivo, "Llamadas de herramienta de referencia" con la precisión de las llamadas de herramienta, "Salida de aplicación de referencia" con la precisión de la salida de la aplicación y "Respuesta de referencia" con la precisión de la respuesta. Instruction Adherence y Guardrails no requieren un campo de referencia.

Mejores prácticas para diseñar 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. 
• Instrucciones: Comportamiento del usuario: Ritmo, tono y qué no ofrecer voluntariamente. 
• Objetivos: Lo que el usuario está intentando obtener: Los hechos que debe desvelar y el orden en el que debe hacerlo.
   
• La divulgación progresiva debe utilizarse 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 instrucciones se puede volver a utilizar textualmente en todo un conjunto de datos. Solo Persona y Goals deben variar en cada escenario (como se ve en un conjunto de datos de enrutamiento 294-scenario MasOrange).
• Proporcione datos de prueba confidenciales solo cuando se solicite. Se debe añadir "Proporcionar solo cuando se solicite" 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.
• Nunca utilice datos de apariencia realista 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 "que sea breve", esta debe trasladarse a las instrucciones. 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.

• Fije una redacción exacta dentro de Simulated Instructions: El mensaje literal puede estar incrustado, por ejemplo: "Su primer mensaje siempre debe hacer su pregunta. Use el siguiente mensaje: ¿Cómo puedo obtener un presupuesto en línea?" El simulador lo envía de forma literal mientras el conjunto de datos mantiene el acceso completo a la métrica de Simulado. (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).
• Reserve Guionizado para la única restricción difícil que lo requiera: Answer Accuracy es solo Scripted y con un 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.
• Limite los casos Guionizados cuando se utilicen para Answer Accuracy: Se deben utilizar una pregunta y una respuesta de referencia por cada caso de prueba.
• Añada casos de prueba de variantes de frases para los principales intents: Se debe repetir una pregunta con pequeñas diferencias en la redacción (un saludo añadido, palabras de relleno) respecto a un Reference Goal compartido, para detectar la sensibilidad 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 adversos y de seguridad

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

• Ponga nombre a la técnica de ataque y el rigor 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. 
• Escriba los Reference Goals como un permiso 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".
• Guionice una prueba de presión de segundo impulso. 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.
• Mantenga los escenarios adversos en un conjunto de datos específico, sin mezclarlas con la regresión de la ruta satisfactoria, con un umbral de promoción más estricto para ello.

Mejores prácticas para redactar Reference Goals

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.

• Son preferibles varios objetivos pequeños e independientes en lugar de un objetivo compuesto: Cada uno tiene su propia aprobación/desaprobación y razonamiento en lugar de un veredicto ambiguo.
• Se cubren ambas direcciones de una restricción: "El agente debe pedir X" puede aprobarse por el motivo equivocado si el usuario ofrece voluntariamente X y la barrera de seguridad 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

• Trate los conjuntos de datos como inmutables: Duplique 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.
• Control de versiones con una convención de nomenclatura explícita (por ejemplo, <usecase>_v2 o <usecase>_20260420) para que el linaje sea obvio sin abrir el conjunto de datos.
• Amplíe 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.
• Construya 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.
• Observe el límite de 500-scenario. Los conjuntos de grandes dimensiones deben planificarse como conjuntos de datos con múltiples ámbitos de propósito.
• Elimine conjuntos de datos que ya no reflejen la orquestación en lugar de acumular versiones desactualizadas.

Mejores Prácticas para elegir las 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 información de identificación personal. RAG se refiere a generación aumentada por recuperación.

• Precisión del objetivo: Debe utilizarse para obtener un resultado puntual y específico de un escenario. Es el más rápido de redactar.
• Custom Metric: Debe utilizarse cuando una comprobación se puede reutilizar en varios escenarios, necesita una aprobación/no aprobación por criterio o debe 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 frente a 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.

• Reserve Critical para ser utilizado para cuestiones genuinas no negociables, como los requisitos de cumplimiento o las promesas que el agente no puede incumplir. Lo mejor es dejar los controles de calidad y tono como no críticos.
• Dé prioridad a Goal Accuracy sobre Tool Call Accuracycuando 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.
• Establezca el número de ejecuciones > 1 antes de confiar en un veredicto, ya que los jueces no son deterministas.

Mejores prácticas para ejecutar e iterar

• Pruebe los cambios de uno en uno en las instrucciones o la orquestación del agente, luego vuelva a ejecutar antes de realizar otro cambio.
• Evalúe siempre la versión destinada a la promoción. La orquestación y la versión deben confirmarse en el asistente, no deben dejarse en un borrador antiguo.
• Vuelva a ejecutar antes de escalar un resultado sorprendente. Un fallo inesperado no es aún evidencia de una regresión.
• La promoción se limita a un umbral acordado con anticipación, antes de analizar los resultados.