Respuesta breve.
Prueba el chatbot con preguntas habituales, ambiguas, fuera de alcance y sin respuesta en sus fuentes. Verifica datos, permisos, derivación y acciones conectadas. Conserva casos repetibles y vuelve a evaluar cuando cambie la implementación.
- Define una respuesta aceptable para cada caso.
- Comprueba herramientas y recuperación de errores.
- Evalúa límites además de respuestas exitosas.
Un chatbot puede responder correctamente a la pregunta preparada para una demostración y fallar con una consulta real. Antes de lanzarlo, conviene evaluar variaciones, información ausente y acciones conectadas. La prueba debe considerar tanto la conversación como lo que ocurre detrás.
Construye casos desde las dudas del negocio
Reúne preguntas frecuentes autorizadas y crea variantes: escritura informal, dos dudas en una frase, cambio de tema o información incompleta. Incluye preguntas que el bot no debe contestar y solicitudes que requieren una persona.
Para cada caso, define qué sería una respuesta aceptable. No necesitas exigir una redacción idéntica, pero sí comprobar datos, límites y siguiente paso. Un asistente de servicios debería reconocer qué información necesita para orientar y cuándo debe dejar de insistir.
Comprueba que no inventa condiciones
Prueba preguntas sobre precios, plazos, cobertura y disponibilidad que no están en las fuentes. La respuesta debería identificar lo que puede confirmar y preparar una consulta cuando falta contexto. Presentar una cifra inventada con seguridad es un fallo aunque el tono sea amable.
Ejemplo ilustrativo: alguien pide un precio cerrado para integrar IA sin explicar sus herramientas. El bot describe los factores del alcance y ofrece registrar la necesidad. No promete una integración específica hasta revisar compatibilidad, datos y permisos.
Prueba también herramientas y derivación
Si el asistente crea registros o consulta sistemas, verifica entradas, permisos y resultado de cada acción. Mostrar “consulta enviada” exige confirmar que el sistema la aceptó. Una respuesta del modelo no sustituye esa comprobación.
Simula fallos del destino y repeticiones de la solicitud. Asegura que el cliente pueda continuar sin duplicar registros. Al derivar, entrega el resumen pertinente y conserva un camino claro si la persona solicita hablar directamente con el equipo.
- Pregunta sin respuesta en las fuentes.
- Solicitud de información restringida.
- Cambio de objetivo durante la conversación.
- Herramienta que responde con error.
- Acción repetida o datos incompletos.
Define criterios y vuelve a probar cuando cambia
La documentación de evaluación de OpenAI recomienda considerar casos variados y situaciones límite. Para el negocio, traduce esa práctica en criterios claros: exactitud de datos, derivación correcta, acciones verificadas y tiempo de respuesta aceptable para el recorrido.
Registra incidencias y conserva una colección de pruebas que puedas repetir al cambiar fuentes, instrucciones o herramientas. Revisa muestras autorizadas después del lanzamiento. El asistente seguirá necesitando mantenimiento cuando cambien los servicios y las condiciones de atención.
Evalúa respuestas y acciones con casos difíciles. Un lanzamiento necesita criterios de aceptación, recuperación de fallos y seguimiento.
Preguntas frecuentes.
¿Una demostración exitosa basta para lanzar?
No. Puede omitir variaciones y errores frecuentes. La evaluación debe incluir casos difíciles y acciones reales del recorrido.
¿Cuándo debo repetir las pruebas?
Al cambiar instrucciones, fuentes, modelos o herramientas y después de incidencias que revelen situaciones no contempladas.
Guía de Grupo Astra Digital. Los ejemplos son ilustrativos; el alcance de una implementación depende del proceso y las herramientas del negocio.
Para llevarlo a tu operación: Bots con inteligencia artificial en Chile y Latinoamérica ↗
← Volver al blog