La respuesta corta
La prueba de agentes no es una prueba de software clásica. No existe una única respuesta correcta, la misma pregunta puede formularse de veinte maneras y, a menudo, un fallo no es un error, sino una respuesta razonable a la que le falta una condición fundamental. Por lo tanto, se necesita un método diferente: un conjunto de casos representativos, criterios de aceptación en lugar de respuestas exactas y una medición en varias dimensiones de forma independiente.
La separación de las dimensiones es lo que hace que una prueba sea útil. "La respuesta no es buena" no es un hallazgo; "El tema se identificó correctamente, pero no se recuperó la fuente relevante" es un hallazgo que se puede corregir.
Las cuatro dimensiones de la medición
| Dimensión | Qué se evalúa | Cómo se mide | Quién corrige |
|---|---|---|---|
| Identificación del tema | Si el agente entendió el asunto | Comparación con el tema esperado | Quien escribe las instrucciones y descripciones de las Actions |
| Recuperación | Si se recuperó la fuente correcta | Si el fragmento esperado apareció en la recuperación | El propietario del contenido y el etiquetado |
| Respuesta | Si el contenido es correcto y completo | Criterios de aceptación: obligatorio, prohibido, citación | Contenido e instrucciones |
| Proceso | Si se realizó la acción correcta y se mantuvo la escalada | Verificación de la secuencia de acciones y la decisión de detención | Actions y reglas de escalada |
Construcción de un conjunto de pruebas representativo
El material de origen son consultas reales y no escenarios escritos en una reunión. Transcripciones, correos electrónicos y descripciones de Case contienen lo que falta en los escenarios inventados: errores ortográficos, formulación parcial, dos preguntas en una sola frase e información incompleta.
Composición recomendada: aproximadamente la mitad de los casos son comunes, una cuarta parte son casos extremos (excepciones, condiciones de elegibilidad límite, preguntas multifacéticas) y una cuarta parte son casos que deberían fallar intencionadamente: solicitudes fuera de Scope, intentos de obtener información no autorizada y un cliente que solicita ser atendido por una persona.
Para cada caso, se definen cuatro campos: la consulta tal como se formuló, el tema esperado, el criterio de aceptación para la respuesta y el comportamiento de proceso esperado, incluyendo "debe escalar" como un resultado válido y no como un fallo.
Criterio de aceptación en lugar de respuesta precisa
Este es el principio que permite realizar la prueba en absoluto. En lugar de escribir la respuesta correcta, se redactan tres listas cortas: hechos que deben aparecer, afirmaciones que no deben aparecer y la fuente que debe citarse.
El ejemplo típico: una pregunta sobre la elegibilidad para un reembolso. Es obligatorio que aparezca el período de tiempo y las condiciones de estado del producto; no debe aparecer ningún compromiso de reembolso; la fuente debe ser el procedimiento de devolución en su versión vigente. Dos formulaciones completamente diferentes pueden pasar la prueba.
Esta es también la forma que permite una clasificación automática fiable: la verificación de la presencia de un hecho definido es mucho más precisa que pedirle a un modelo que evalúe la "calidad".
Automatización versus juicio humano
Los Scorers automáticos son adecuados para la identificación de temas, la presencia de una cita válida, el cumplimiento del formato, la longitud y la identificación de afirmaciones prohibidas. Estos se ejecutan en todo el conjunto en cada versión, a bajo costo.
El juicio humano es necesario para la precisión del contenido en áreas sensibles y para la formulación de cara al cliente. No es necesario todo el conjunto, sino una muestra constante de veinte a treinta casos en cada versión, seleccionada para incluir los casos extremos.
El riesgo de depender completamente de un evaluador automático es el sesgo hacia respuestas que suenan autoritarias. Una respuesta convincente que omite una condición de elegibilidad pasará automáticamente y será detectada por un evaluador humano.
La relación entre los resultados de las pruebas y la supervisión en producción se explica en Observabilidad para Agentforce.
Casos límite que siempre deben incluirse
Una pregunta con dos temas en una frase. Una consulta a la que le falta información esencial: si el agente pregunta por una aclaración o adivina. Un cliente que formula la pregunta en un tono negativo: si se activa la escalada. Una solicitud de una acción que no está permitida para ese usuario. Una pregunta sobre un producto que no existe: si el agente lo admite o lo inventa. Contenido que contiene una instrucción disfrazada que intenta cambiar el comportamiento.
Estos seis cubren la mayoría de los fallos que hemos visto llegar a producción, y son económicos de ejecutar repetidamente.
Los escenarios de evasión se relacionan con las pruebas de seguridad detalladas en Seguridad en Agentforce y responsabilidad compartida.
Umbrales para la puesta en marcha
El umbral no es un número uniforme, sino que se deriva del canal y del riesgo. Un agente interno para la asistencia a un representante puede lanzarse con un nivel de precisión más bajo, porque el representante filtra. Un agente que interactúa con los clientes requiere un umbral significativamente más alto y, sobre todo, cero fallos en las categorías críticas.
La regla más importante que el número: cero fallos en las categorías obligatorias. La exposición de información no autorizada, una acción irreversible sin aprobación, la no escalada de una solicitud explícita de una persona, cualquiera de estos bloquea la puesta en marcha, independientemente de la puntuación general.
Escenario: un conjunto pequeño que evitó un lanzamiento deficiente
Una empresa de turismo planeaba lanzar un agente de atención al cliente después de que el piloto interno mostrara un buen rendimiento. El conjunto de pruebas construido incluía 90 casos, de los cuales 22 eran casos extremos de consultas reales.
La ejecución reveló un patrón: en las preguntas sobre cambios de fecha con condiciones de cancelación especiales, el agente dio una respuesta esencialmente correcta, pero omitió las tarifas de cambio en un tercio de los casos. En las pruebas internas no se detectó porque los representantes sabían cómo añadir la información por sí mismos.
El lanzamiento se pospuso tres semanas. La corrección se hizo en el contenido: las condiciones de facturación se trasladaron a una sección separada y marcada en cada artículo relevante, y se añadió un criterio de aceptación explícito. La nueva ejecución pasó la prueba y el lanzamiento se realizó sin incidentes.
Riesgos y acciones preventivas
| Riesgo | Cómo se detecta | Acción preventiva |
|---|---|---|
| Conjunto de pruebas inventadas | Todo pasa en las pruebas y falla en producción | Casos a partir de consultas reales |
| Prueba solo de la puntuación total | Se desconoce qué corregir | Medición separada de las cuatro dimensiones |
| Dependencia de un evaluador automático | Las respuestas convincentes con omisiones pasan | Muestra humana constante en cada versión |
| No hay casos que deban fallar | El agente responde a lo que no debe | Un cuarto del conjunto: fuera de Scope y evasión |
| No hay regresión | Una pequeña corrección rompe otro escenario | Ejecutar el conjunto antes de cada lanzamiento de versión |
Métricas de prueba
| Métrica | Definición | Umbral principal |
|---|---|---|
| Topic accuracy | Porcentaje de identificación correcta del tema | Alto; un fallo aquí rompe todo lo demás |
| Retrieval hit rate | Porcentaje de casos en los que se recuperó la fuente esperada | Alto en el canal del cliente |
| Answer acceptance | Porcentaje de respuestas que cumplieron con el criterio de aceptación | Derivado del canal y del riesgo |
| Process compliance | Porcentaje de casos en los que se ejecutó la acción o escalada correcta | Cero desviaciones en categorías obligatorias |
| Regression delta | Cambio en las puntuaciones respecto a la versión anterior | Sin disminución inexplicable |
Cuando se requiere asistencia en la construcción de un conjunto de pruebas y la definición de umbrales de puesta en marcha, el servicio de Agentforce e IA es el camino práctico a seguir.
Lista de verificación para pruebas
- ☐ El conjunto de pruebas se construyó a partir de consultas reales
- ☐ La composición incluye casos comunes, casos límite y casos que deben fallar
- ☐ Cada caso tiene un criterio de aceptación: obligatorio, prohibido, fuente
- ☐ La medición se divide en tema, recuperación, respuesta y proceso
- ☐ Los Scorers automáticos se ejecutan en todo el conjunto
- ☐ Se prueba una muestra humana constante en cada versión
- ☐ Se incluyeron escenarios de evasión e instrucciones disfrazadas
- ☐ Se definieron categorías obligatorias con tolerancia cero
- ☐ El conjunto se ejecuta como regresión antes de cada lanzamiento de versión
- ☐ Los resultados de las pruebas se documentan y comparan con la versión anterior