Evaluación de agentes de IA en soporte: métodos y métricas

La evaluación de agentes de IA es la forma en que un equipo de soporte demuestra que su agente de IA da respuestas correctas, permitidas y útiles. Tiene dos fases: las evals antes del lanzamiento, en las que se ejecutan conversaciones de prueba con criterios de éxito escritos, y la evaluación en producción, en la que se evalúan las conversaciones reales con una scorecard. Necesita ambas, un juez calibrado y un responsable con nombre.

En resumen

• Las evals previas al lanzamiento indican si un cambio es seguro; la evaluación en producción indica qué hizo realmente el agente de IA con los clientes.
• Mida la resolución correcta, el cumplimiento de políticas, la exactitud de las acciones, la calidad del escalamiento y el tono; trate la contención como contexto, nunca como nota de calidad.
• Use un LLM como juez para el volumen y revisores humanos para la calibración y los casos de alto riesgo, y compruebe su grado de acuerdo criterio por criterio.
• Las muestras pequeñas pasan por alto fallos poco frecuentes pero costosos: con 40.000 conversaciones al mes, una muestra del 1% tiene un 45% de probabilidad de no mostrar ni un caso de un fallo que afecta a 80 clientes.
• Asigne a cada métrica un responsable, un umbral y una frecuencia; la tabla del marco de evaluación que encontrará más abajo es un punto de partida que puede copiar.

Esta guía está pensada para el responsable de soporte que rinde cuentas por el agente cuando ya habla con clientes, no para los ingenieros que lo construyen. Para lo básico, consulte el control de calidad de agentes de IA; si aún está decidiendo hasta dónde automatizar, empiece por la atención al cliente agéntica.

¿Qué es la evaluación de agentes de IA en atención al cliente?

La evaluación de agentes de IA en atención al cliente es el proceso repetible de comprobar las conversaciones de un agente de IA con criterios de éxito escritos: si la respuesta era correcta, si la política la permitía, si la acción prometida se produjo de verdad, si el agente derivó cuando debía y si el tono era el adecuado. Se aplica antes del lanzamiento con casos de prueba y después con conversaciones reales.

Su equipo de IA usará estos términos de las guías para desarrolladores:

La última fila es la que más importa en soporte. Una transcripción en la que el agente dice “su reembolso está en camino” no equivale a un reembolso en el sistema. Quienes gestionan agentes de soporte describen exactamente este fallo: el agente da una acción por hecha cuando la llamada a la API que la sustentaba falló.

¿Qué significa “Demystifying evals for AI agents” de Anthropic para los equipos de soporte?

El artículo técnico de Anthropic Demystifying evals for AI agents (en inglés) es la guía que más gente busca por su nombre. Para los equipos de soporte se resume en cinco puntos: empezar con pocos fallos reales, comprobar resultados y no solo palabras, medir la consistencia, probar ambos lados de cada decisión y seguir leyendo transcripciones.

1. Empiece con 20 a 50 fallos reales. El artículo considera que 20 a 50 tareas sencillas extraídas de fallos reales son “un gran comienzo” y cita la cola de soporte como fuente. Su equipo de QA ya las tiene.
2. Evalúe el resultado, no la narración. El ejemplo de reembolso del artículo combina una comprobación de estado (ticket resuelto, reembolso procesado), comprobaciones de las acciones del agente (identidad verificada, reembolso dentro de los límites) y una rúbrica de LLM para la empatía y la claridad.
3. Mida la consistencia con pass^k, la probabilidad de que las k ejecuciones de una tarea tengan éxito. El artículo señala que esto “importa especialmente en los agentes de cara al cliente, donde los usuarios esperan un comportamiento fiable siempre”. Un agente que supera una tarea el 75% de las veces supera las 3 ejecuciones solo alrededor del 42% de las veces.
4. Pruebe en ambos sentidos. Compruebe cuándo debe actuar el agente y cuándo no. Un conjunto lleno de casos de “debe reembolsar” produce un agente que reembolsa demasiado.
5. Lea las transcripciones. “No sabrá si sus graders funcionan bien a menos que lea las transcripciones y las notas de muchas ejecuciones.”

El artículo también califica la monitorización en producción de reactiva: los clientes encuentran el problema antes que usted. Los equipos de soporte necesitan ambas fases.

Evals previas al lanzamiento frente a evaluación en producción: ¿cuál es la diferencia?

Las evals previas al lanzamiento ejecutan su agente de IA con conversaciones de prueba antes de que un cambio entre en producción, para bloquear un prompt, un modelo o una actualización de conocimiento defectuosos. La evaluación en producción puntúa las conversaciones reales de los clientes, para encontrar fallos que su conjunto de pruebas nunca imaginó. La primera es un filtro; la segunda, el control de calidad continuo.

Las dos fases se alimentan mutuamente: cada fallo encontrado en producción se convierte en un nuevo caso de prueba. La simulación, en la que un segundo modelo hace de cliente, pertenece a la fase previa al lanzamiento; benchmarks como τ-bench (en inglés) la usan para tareas de soporte de comercio minorista y aerolíneas.

¿Cómo se escriben evals para un agente de IA?

Para escribir evals para un agente de IA, reúna de 20 a 50 conversaciones reales en las que el agente o su equipo se equivocaron, describa cómo sería un resultado correcto en cada una, añada casos en los que lo correcto sea rechazar o escalar, dé a cada criterio su propio grader y ejecute cada caso varias veces antes de cada cambio.

El equipo de soporte lo define; el equipo de IA lo implementa:

1. Saque los casos de QA. Conversaciones fallidas o escaladas de los últimos 90 días, agrupadas por intención.
2. Escriba el resultado esperado en una frase. “Rechaza el reembolso, cita la política de 30 días, ofrece un vale de compra, no escala.”
3. Añada los casos espejo. Por cada caso de “debe rechazar”, uno de “debe hacerlo”; por cada caso de “debe escalar”, uno en el que escalar sería un error.
4. Separe los criterios. Corrección, política, acción, escalamiento y tono tienen cada uno su propia comprobación; el artículo de Anthropic recomienda un juez por dimensión de la rúbrica.
5. Compruebe el sistema, no la frase. Cuando el agente ejecuta una acción, el grader lee el registro del pedido o del helpdesk, no lo que afirma el agente.
6. Ejecute cada caso de 3 a 5 veces y considérelo superado solo cuando lo superen todas las ejecuciones. Eso es pass^k en la práctica.
7. Mantenga dos conjuntos. Un conjunto de regresión que debería superarse casi el 100% de las veces y un conjunto de capacidades más difícil para las intenciones que piensa automatizar a continuación.

La versión mínima, tal como la describen los profesionales, es unas cuantas docenas de tickets reales que salieron mal, que se vuelven a ejecutar cada vez que cambia el prompt. Nuestra guía de pruebas de agentes de IA trata en profundidad el diseño de pruebas, las ejecuciones de regresión y la simulación.

¿Qué métricas de evaluación de agentes de IA importan en atención al cliente?

Las métricas de evaluación de agentes de IA que importan en atención al cliente son la resolución correcta, la corrección de las respuestas, el cumplimiento de políticas, la exactitud de las acciones, la calidad del escalamiento y el tono, respaldadas por el nuevo contacto y la opinión del cliente. La contención y la deflexión solo indican que el cliente no llegó a una persona, así que van en la columna de contexto, no en la nota de calidad.

Combine la tasa de contención (en inglés) con una comprobación de resolución, consulte cómo medir el rendimiento de los agentes de IA para comparar con justicia la atención de la IA y la humana, y lleve los criterios a una scorecard para agentes de IA.

¿LLM como juez o revisión humana? ¿Cómo se calibran?

Use un LLM como juez para evaluar cada conversación y revisores humanos para calibrarlo y hacerse cargo de los casos de alto riesgo. Para calibrar, haga que dos revisores y el juez evalúen a ciegas las mismas 100 a 200 conversaciones, mida el acuerdo de cada criterio por separado y corrija la redacción del criterio allí donde el juez y las personas discrepen.

LLM como juez (LLM-as-a-judge) significa que un modelo de lenguaje evalúa una conversación con sus criterios escritos (nuestra definición, en inglés). El artículo Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (en inglés) concluyó que GPT-4 alcanzó más de un 80% de acuerdo con las preferencias humanas, el mismo nivel de acuerdo que hay entre personas. También enumera los puntos débiles del juez: sesgos de posición, de verbosidad y de autopromoción, y un razonamiento limitado.

Una rutina de calibración que se sostiene:

• Evalúe a ciegas. Dos revisores y el juez evalúan el mismo conjunto por separado. Primero se ponen de acuerdo los revisores y después comparan con el juez.
• Mida por criterio. Un 90% global puede esconder un criterio de tono al 70%. En los criterios de aprobado o suspenso, siga el recall: de los incumplimientos de política reales, ¿cuántos detectó el juez?
• Deje que el juez diga “no lo sé”. El artículo de Anthropic recomienda dar al juez una salida para reducir las notas inventadas. Derive esos casos a una persona.
• Vuelva a calibrar tras cada cambio en la scorecard, el modelo del juez o el alcance del agente, y como mínimo cada mes.

Nuestro protocolo de una semana para validar la evaluación del QA con IA (en inglés) convierte esto en un plan día a día con umbrales de acuerdo.

¿Cuántas conversaciones hay que evaluar?

Para las evals previas al lanzamiento, de 20 a 50 casos de fallo reales bastan para empezar, y el conjunto crece hasta unos cientos a medida que automatiza más intenciones. Para la evaluación en producción de un agente de IA, evalúe todas las conversaciones si puede, porque los fallos más caros son poco frecuentes y los fallos poco frecuentes se esconden en las muestras. Mantenga la doble evaluación humana en 100 a 200 conversaciones al mes.

Ilustración (no son datos de clientes). Un agente de IA atiende 40.000 conversaciones al mes. El equipo de QA revisa una muestra del 1%: 400 conversaciones.

La probabilidad de no ver ninguno es (1 menos la tasa) elevado a 400. Incluso dos errores de reembolso detectados parecen ruido; evaluar las 40.000 conversaciones muestra 200 y 80 casos, agrupados por intención.

Tres reglas prácticas:

• Margen de error. Una tasa de resolución correcta del 90% medida en 400 conversaciones tiene una precisión de unos ±3 puntos (95% de confianza), así que una caída al 88% está dentro del ruido. Con 40.000 conversaciones, el margen es de unos ±0,3 puntos.
• Cero fallos no es cero riesgo. Si no ve ningún fallo en n conversaciones, la tasa real aún puede llegar a unos 3 dividido entre n: demostrar una tasa inferior al 1% exige unas 300 conversaciones sin fallos, e inferior al 0,1%, unas 3.000.
• Los conjuntos de calibración son pequeños a propósito. 200 conversaciones con doble evaluación y un 85% de acuerdo fijan ese acuerdo con una precisión de unos ±5 puntos: suficiente para encontrar un criterio mal redactado, no para clasificar a los revisores.

Las matemáticas se explican en nuestro artículo sobre estadística del muestreo de QA (en inglés).

El marco de evaluación de agentes de IA (copie esta tabla)

Este marco enumera qué evaluar, el método, la métrica, un umbral de ejemplo, el responsable y la frecuencia para un agente de IA de atención al cliente. Los umbrales son ejemplos para debatir, no referencias del sector: fije los suyos a partir de su propia referencia y de lo que le cuesta un solo fallo.

Por qué el umbral de consistencia es estricto: una tarea que supera el 98% de las ejecuciones individuales supera las 5 ejecuciones alrededor del 90% de las veces, y una al 95%, solo alrededor del 77% de las veces. Al cliente le toca la ejecución que le toque.

¿Quién debe ser responsable de la evaluación de agentes de IA?

La evaluación de agentes de IA necesita tres responsables: el responsable de IA o de automatización ejecuta las evals previas al lanzamiento y corrige prompts y herramientas, el responsable de QA dirige la evaluación en producción y la calibración del juez, y el responsable de CX fija los umbrales y decide si el agente se amplía, se mantiene o se restringe. Los responsables del conocimiento y de las políticas corrigen el contenido que señalan las notas.

El fallo habitual es que la evaluación dependa solo del equipo que construye el agente: quienes lo construyen miden lo que pueden cambiar, mientras que los responsables de soporte necesitan ver lo que recibieron los clientes. Ponga a una persona de soporte al frente de las cifras de producción; la tabla del marco anterior asigna un responsable a cada métrica. La evaluación es una parte de un modelo de supervisión más amplio, que trata nuestra guía de gobernanza de agentes de IA.

¿Qué herramientas de evaluación de agentes de IA usan los equipos de soporte?

Los equipos de soporte usan cuatro tipos de herramientas de evaluación de agentes de IA: plataformas de evals y observabilidad para desarrolladores, para las pruebas previas al lanzamiento y las trazas; herramientas de simulación que hacen de cliente; la analítica integrada en la plataforma del agente; y plataformas de QA de conversaciones que evalúan las conversaciones reales con una scorecard. La mayoría de los equipos enterprise acaba con una herramienta por fase.

Kaizo está en la última fila. AutoPilot evalúa cada conversación resuelta con su propia scorecard, y cada nota enlaza con las evidencias de la conversación. Usted prueba la evaluación con las valoraciones históricas de su equipo antes de ponerla en marcha, y los revisores se quedan con las conversaciones que requieren criterio. Nuestra página sobre QA para agentes de IA muestra cómo funciona dentro de Zendesk y Salesforce.

Véalo con sus propias conversaciones. Kaizo evalúa el 100% de sus conversaciones de atención al cliente y convierte los resultados en coaching. Reservar una demo.

Cuándo este nivel de evaluación no es para usted

Si su agente de IA atiende unas pocas docenas de conversaciones a la semana, prescinda del marco, del juez y de la herramienta: lea usted mismo cada transcripción durante una hora a la semana con una lista de comprobación breve (correcta, permitida, derivación adecuada, tono adecuado). Ponga en marcha el programa completo cuando el volumen supere lo que una persona puede leer, o cuando el agente empiece a ejecutar acciones como reembolsos o cambios en la cuenta.

Si lo que necesita es un conjunto de pruebas para desarrolladores en su proceso de publicación, se trata de otra herramienta; la plataforma de QA de Kaizo evalúa las conversaciones después de que terminan y puede funcionar junto a ella.

Cómo empezar a evaluar agentes de IA esta semana

Puede empezar a evaluar agentes de IA esta semana sin comprar nada. En cinco días, un equipo de soporte puede elegir tres intenciones, reunir 30 fallos reales, redactar cinco criterios de sí o no, evaluar 100 conversaciones recientes como referencia y acordar responsables y umbrales. Todo lo demás del marco crece a partir de ahí.

1. Lunes: elija la intención de mayor volumen, la de mayor riesgo (normalmente reembolsos o cambios en la cuenta) y la que más quejas genera.
2. Martes: saque 10 conversaciones malas por intención de QA, reclamaciones y escalamientos; escriba en una frase el resultado correcto de cada una.
3. Miércoles: redacte cinco criterios (respuesta correcta, política, acción coincidente con el sistema, escalamiento, tono), cada uno como una pregunta de sí o no con la evidencia que lo demuestra.
4. Jueves: dos revisores evalúan a ciegas 100 conversaciones recientes. Es su referencia y su primer conjunto de calibración.
5. Viernes: complete la tabla del marco con sus nombres, las cifras de referencia y una fecha para la primera revisión mensual.

Entregue los 30 fallos a su equipo de IA como primer conjunto de regresión: no se publica nada hasta que lo supere.

Preguntas frecuentes

¿Qué tasa de exactitud es buena para un agente de IA de atención al cliente?

No hay una cifra universal; depende de lo que cueste una respuesta errónea. Como umbral de ejemplo, apunte a un 98% o más de conversaciones sin errores factuales y a ningún incumplimiento crítico de política en su conjunto de regresión. Fije el umbral en producción a partir de su propia referencia e investigue cualquier caída de 3 puntos o más.

¿Con qué frecuencia hay que volver a ejecutar las evals de un agente de IA?

Vuelva a ejecutar el conjunto de regresión antes de cada cambio de prompt, modelo, herramienta o conocimiento, porque cada uno puede romper algo que funcionaba. Evalúe las conversaciones de producción de forma continua, revise las cifras cada semana y calibre el juez cada mes y después de los cambios en la scorecard.

¿Hay que evaluar a los agentes de IA con la misma scorecard que a los agentes humanos?

Use criterios comunes donde se apliquen a ambos, como una respuesta correcta y el tono adecuado, para que los resultados sigan siendo comparables. Después, añada los criterios que solo necesita un agente de IA: el anclaje en su contenido, la exactitud de las acciones, el alcance y los disparadores de escalamiento. Un único estándar con comprobaciones específicas para la IA funciona mejor que dos scorecards sin relación.

¿Qué diferencia hay entre pass@k y pass^k?

pass@k es la probabilidad de que al menos una de k ejecuciones tenga éxito, lo que encaja con herramientas en las que basta una buena respuesta. pass^k es la probabilidad de que las k ejecuciones tengan éxito. La atención al cliente necesita pass^k, porque cada cliente recibe una sola ejecución y espera la respuesta correcta siempre.

¿Es lo mismo evaluar un agente de IA que monitorizarlo?

No. La monitorización vigila el volumen en vivo, los errores y las alertas para que detecte un problema rápido. La evaluación juzga si cada respuesta fue correcta, permitida y bien gestionada, antes del lanzamiento con casos de prueba y después con conversaciones reales. La evaluación en producción alimenta la monitorización, y cada fallo que encuentra se convierte en un nuevo caso de prueba.