Evaluar un asistente de IA significa medir, con preguntas reales y criterios definidos de antemano, si responde correctamente, se apoya en las fuentes correctas, se abstiene cuando debe y lo hace a un costo y una velocidad aceptables. Se hace antes del lanzamiento, en cada cambio de prompt o de modelo, y de forma continua en producción. Sin esto, la calidad de tu asistente es una opinión; con esto, es un número que puedes mejorar.
Por qué "se veía bien en el demo" no es suficiente
Casi todos los asistentes de IA impresionan en la primera demostración. El problema es que el demo se arma con las preguntas que el equipo ya sabe que funcionan. En producción llegan otras:
- La cola larga: clientes que preguntan con faltas de ortografía, mezclan tres temas en un mensaje de WhatsApp o piden algo que el asistente no debería responder.
- Variabilidad: el mismo modelo puede responder distinto a la misma pregunta. Una prueba exitosa no garantiza la siguiente.
- Cambios invisibles: un ajuste "pequeño" al prompt arregla un caso y rompe otros diez. El proveedor actualiza o retira un modelo. Se agregan documentos nuevos al índice.
- Errores seguros: un modelo de lenguaje casi nunca dice "no estoy seguro" por iniciativa propia. Una respuesta incorrecta bien redactada pasa desapercibida si nadie la mide.
La solución no es probar más a mano, sino construir un sistema de evaluación que se ejecute igual cada vez.
El set dorado: preguntas reales con respuestas esperadas
Un set dorado (golden set) es una colección de preguntas reales con la respuesta correcta, la fuente que la respalda y los criterios para calificarla, que se usa como referencia fija para medir el asistente. Es el activo más valioso del proyecto y debe construirlo alguien que conozca el negocio, no solo el equipo técnico.
- Recolecta preguntas reales: chats de WhatsApp, correos de soporte, tickets, búsquedas en la intranet. Anonimiza datos personales antes de usarlas.
- Empieza con 50 a 100 preguntas y crece a varios cientos con el tiempo. Más preguntas con calificación automática valen más que pocas revisadas a mano.
- Cubre categorías: preguntas frecuentes, casos difíciles, preguntas ambiguas, fuera de alcance (el asistente debe derivar o abstenerse), y preguntas que intentan manipularlo.
- Para cada pregunta registra: la respuesta esperada o los hechos que debe contener, el documento fuente, lo que no debe decir nunca y si corresponde escalar a una persona.
- Versiona el set: cuando cambia una política, actualiza la respuesta esperada; cuando aparece un error en producción, agrégalo como nuevo caso.
Qué métricas medir
Ninguna métrica sola describe la calidad. Estas son las que recomendamos para un asistente empresarial:
- Exactitud: ¿la respuesta es correcta y completa frente a la esperada?
- Fundamentación (groundedness): ¿cada afirmación está respaldada por los documentos recuperados, o el modelo agregó cosas de su cosecha? Es clave en sistemas RAG empresariales.
- Precisión de citas: ¿la fuente citada realmente dice lo que la respuesta afirma?
- Comportamiento de rechazo: ¿se abstiene cuando no tiene evidencia o la pregunta está fuera de alcance? Y lo contrario: ¿evita rechazar preguntas legítimas por exceso de cautela?
- Seguridad: no revela datos personales de otros, no sigue instrucciones inyectadas, no inventa precios ni promesas comerciales.
- Latencia: tiempo hasta la primera palabra y tiempo total, en percentil 50 y 95. En un canal como WhatsApp, la demora se nota.
- Costo por conversación: tokens de entrada y salida, búsquedas y llamadas a herramientas, sumados por conversación completa, no por mensaje.
- Tasa de resolución: porcentaje de conversaciones que terminan resueltas sin intervención humana, confirmado por el usuario o por ausencia de reclamo posterior.
- Tasa de escalamiento: cuántas conversaciones pasan a una persona, y si esos escalamientos fueron correctos. Escalar poco no siempre es bueno: puede significar que el asistente responde lo que no debería.
Cómo calificar: reglas, personas y LLM como juez
Hay tres formas de calificar y conviene combinarlas:
- Reglas automáticas: ¿el JSON es válido?, ¿incluye una cita?, ¿menciona el número de póliza correcto?, ¿la respuesta contiene un precio que no está en el catálogo? Son baratas, rápidas y deterministas.
- Revisión humana: la referencia de calidad, pero lenta y costosa. Se usa para calibrar y para revisar muestras, no para cada ejecución.
- LLM como juez: un modelo califica las respuestas con una rúbrica. Un estudio de 2023 (Zheng y colegas) encontró que jueces fuertes como GPT-4 coinciden con las preferencias humanas en más del 80 % de los casos, un nivel similar al acuerdo entre personas, pero también documentó sesgos: preferir la primera respuesta mostrada, preferir respuestas largas y favorecer las de su propio modelo.
Para que un juez automático sea confiable:
- Usa criterios concretos y binarios ("¿menciona el plazo de 30 días? sí o no") en lugar de "califica del 1 al 10".
- Usa un modelo distinto del que genera las respuestas, como recomienda la documentación de evaluación de Anthropic.
- Calibra con personas: que un experto califique 50 a 100 respuestas, compara con el juez y ajusta la rúbrica hasta que el acuerdo sea alto. Repite la calibración cuando cambies de modelo juez.
- Revisa a mano los casos donde el juez y las reglas no coinciden.
Pruebas de regresión en cada cambio
Cada cambio de prompt, de modelo, de configuración de búsqueda o del conjunto de documentos debe pasar por el set dorado antes de llegar a producción, igual que el código pasa por pruebas automáticas.
- Línea base: guarda los resultados de la versión actual para comparar.
- Compara por categoría: un promedio estable puede esconder que mejoraron las preguntas frecuentes y empeoraron las de seguridad.
- Umbrales de bloqueo: por ejemplo, ninguna regresión en casos de seguridad y no más de un punto de caída en exactitud general.
- Fija versiones de modelo en lugar de usar alias que cambian solos, y reevalúa antes de migrar cuando el proveedor anuncie el retiro de un modelo.
- Automatiza: que la evaluación corra en el pipeline de despliegue y deje un reporte.
Monitoreo en producción y ciclo de mejora
El set dorado mide lo que esperabas; la producción te muestra lo que no esperabas. Un buen monitoreo incluye:
- Retroalimentación explícita: pulgar arriba o abajo, y un motivo opcional.
- Revisión de muestras: cada semana, alguien del negocio revisa una muestra aleatoria de conversaciones y todas las marcadas como negativas o escaladas.
- Evaluación automática en línea: el juez califica un porcentaje de conversaciones reales para detectar caídas de fundamentación o de citas.
- Alertas operativas: picos de latencia, de costo por conversación, de errores de herramientas o de preguntas sin respuesta.
- Cerrar el ciclo: cada fallo real se convierte en un caso del set dorado, para que no vuelva a ocurrir sin que alguien lo note.
Ojo con la privacidad: los registros de conversaciones contienen datos personales. En Ecuador, la LOPDP exige medidas de seguridad adecuadas (art. 37); define quién puede leer los registros, cuánto tiempo se guardan y anonimiza lo que uses para evaluación.
Red teaming: atacar tu propio asistente
Red teaming es intentar que el asistente falle a propósito antes de que lo haga un usuario malintencionado. Como mínimo, prueba:
- Instrucciones inyectadas en el mensaje o en documentos y páginas que el asistente lee. Lo explicamos en la guía de prompt injection.
- Intentos de obtener el prompt del sistema, datos de otros clientes o documentos fuera de los permisos del usuario.
- Pedidos de descuentos, promesas o compromisos que el asistente no está autorizado a hacer.
- Acciones peligrosas si el asistente usa herramientas: cancelar pedidos, enviar correos, modificar registros.
El OWASP Top 10 para LLMs es una buena lista de verificación. Los ataques exitosos también se agregan al set dorado.
Un scorecard simple para empezar
| Métrica | Cómo se mide | Meta de ejemplo | Frecuencia |
|---|---|---|---|
| Exactitud | Set dorado con juez calibrado | Definida con el negocio según el riesgo del caso de uso | Cada cambio |
| Fundamentación y citas | Juez + verificación de que la cita contiene la afirmación | Sin afirmaciones sin respaldo en casos críticos | Cada cambio y muestra semanal |
| Abstención correcta | Preguntas fuera de alcance del set | El asistente deriva o se abstiene en todas | Cada cambio |
| Seguridad | Casos de red teaming | Cero regresiones | Cada cambio y trimestral |
| Latencia p95 | Telemetría | Según el canal (chat, WhatsApp, voz) | Continua |
| Costo por conversación | Telemetría de tokens y herramientas | Dentro del presupuesto del caso de negocio | Semanal |
| Resolución y escalamiento | Registros + revisión de muestra | Tendencia al alza en resolución sin escalamientos incorrectos | Mensual |
Las metas exactas dependen del caso: un asistente que responde horarios de atención tolera más error que uno que explica condiciones de un crédito. Si estás implementando un asistente en WhatsApp, revisa también nuestra guía de chatbot con IA en WhatsApp Business. En nuestro servicio de desarrollo con IA incluimos esta evaluación desde el primer prototipo.
Preguntas frecuentes
¿Cuántas preguntas necesito para evaluar un chatbot con IA?
Para empezar, entre 50 y 100 preguntas reales bien elegidas son suficientes para detectar problemas grandes y comparar versiones. Con el tiempo conviene llegar a varios cientos, cubriendo preguntas frecuentes, casos difíciles, preguntas fuera de alcance e intentos de manipulación. Importa más la representatividad que el número: deben salir de conversaciones reales de tus clientes o empleados, no inventadas por el equipo.
¿Qué es LLM como juez y es confiable?
Es usar un modelo de lenguaje para calificar las respuestas de otro según una rúbrica. Es confiable si se calibra: un experto califica una muestra, se compara con el juez y se ajusta la rúbrica hasta lograr un acuerdo alto. Conviene usar criterios concretos, un modelo distinto del evaluado y revisar periódicamente, porque estos jueces tienen sesgos conocidos, como preferir respuestas largas.
¿Cada cuánto hay que volver a evaluar un asistente de IA?
En cada cambio de prompt, de modelo, de configuración de búsqueda o de documentos, antes de publicarlo. Además, de forma continua en producción con muestras semanales de conversaciones reales y alertas de costo y latencia. También es necesario reevaluar cuando el proveedor anuncia una nueva versión o el retiro de un modelo, aunque tú no hayas cambiado nada.
¿Qué métricas importan más para un asistente de atención al cliente?
Para el negocio, la tasa de resolución sin intervención humana, la tasa de escalamientos correctos y el costo por conversación. Para la calidad, la exactitud frente a respuestas esperadas, la fundamentación en documentos vigentes y la abstención cuando no hay información. Y como requisito, cero regresiones en seguridad: no revelar datos de otros clientes ni hacer promesas no autorizadas.
¿Qué es red teaming en inteligencia artificial?
Es atacar deliberadamente tu propio asistente de IA para encontrar fallas antes que un usuario malintencionado: inyección de instrucciones, extracción del prompt del sistema, acceso a datos fuera de los permisos o acciones no autorizadas con herramientas. Se hace antes del lanzamiento y periódicamente, y cada ataque exitoso se agrega a las pruebas automáticas para evitar que reaparezca.
Conclusión
Un asistente de IA confiable no se logra con el mejor modelo, sino con un proceso: un set dorado de preguntas reales, métricas que reflejan el negocio, un juez automático calibrado con personas, pruebas de regresión en cada cambio, monitoreo en producción y red teaming. Ese proceso convierte la calidad en algo que se puede gestionar y mejorar semana a semana.
Si quieres lanzar un asistente con este nivel de control o medir el que ya tienes, conoce nuestro servicio de desarrollo con IA o agenda una consulta gratuita.