Qué pasa después de entregar un chatbot o agente de IA

Después de entregar un chatbot de IA empieza su mantenimiento: lo vigilamos con trazas y alarmas, lo medimos cada semana con un golden dataset de conversaciones reales y lo ajustamos con las preguntas que no supo contestar. Hace falta porque cambian las preguntas de tus clientes, cambian tus reglas y el proveedor del modelo saca versiones nuevas.

La duda de quien lo contrata casi siempre es la misma: ¿y si se equivoca delante de mis clientes? Es razonable. Un modelo de lenguaje puede fallar, y nadie serio debería prometerte lo contrario. Aquí te contamos qué hacemos para verlo a tiempo y qué recibe tu empresa.

Cómo evaluamos un chatbot: el golden dataset (batería de pruebas)

Para saber si un chatbot sigue funcionando bien hace falta una referencia. Esa referencia es un golden dataset (batería de pruebas): conversaciones reales de tu negocio, cada una con la respuesta correcta anotada y revisada por una persona. Lo ideal es que esa persona sea alguien de tu equipo que conozca el negocio.

Los casos que valen salen de conversaciones reales. Lo aprendimos con nuestro propio producto. Los primeros casos de prueba los escribimos a mano y no sirvieron, porque nunca llegaron a validarse contra el sistema real.

También hace falta un listón claro: qué parte de los casos tiene que acertar el chatbot en total y en cada tipo de petición. En nuestro asistente de citas, por ejemplo, tiene que entender bien qué pide el paciente en al menos el 85 % del total de casos y en el 70 % de cada tipo.

Cómo vemos lo que hace el chatbot cada día

Cada vez que el chatbot trabaja queda una traza en Arize Phoenix: qué le llegó, qué hizo paso a paso, cuánto costó, cuánto tardó y qué modelo respondió de verdad. Phoenix es una herramienta de la empresa Arize para ver por dentro lo que hace un agente de IA. La usamos en los chatbots y agentes que mantenemos.

Las trazas no salen a la nube de un tercero. En los proyectos a medida, Phoenix va instalado en tu propio servidor, como contamos en la guía de IA y RGPD.

Con las trazas se ve qué cuesta el chatbot y si algo se está ralentizando. También se ve si el proveedor ha contestado con un modelo de respaldo sin avisar. En uno de nuestros chatbots, un control revisa este punto y no ha encontrado ningún modelo de respaldo en 29.041 llamadas.

Pruebas antes de cada cambio y revisión semanal

El chatbot vuelve a pasar sus pruebas en dos momentos: antes de cada cambio y una vez por semana. Cada cambio es un riesgo, aunque parezca pequeño.

En todos los proyectos, ningún cambio llega a producción si no pasa la batería de pruebas. Antes de aplicar el cambio se hace una copia de la base de datos y, si después el servicio no responde, el sistema vuelve automáticamente a la versión anterior. La batería crece con el tiempo. En nuestro asistente de citas ya son casi 5.000 pruebas automáticas.

Además, una vez por semana el golden dataset se ejecuta contra el modelo real. Esas pruebas cuestan dinero en cada pasada, así que no corren a todas horas. Corren cada semana y cada vez que cambia algo importante, y sus resultados quedan en Phoenix para comparar una semana con otra.

Qué hacemos con las preguntas que no sabe contestar

Las preguntas que el chatbot no supo contestar son la mejor lista de tareas que hay. Las revisamos contigo y decidimos qué hace falta en cada caso: añadir un término al glosario, cambiar las instrucciones del modelo (el prompt) o cambiar el diseño del chatbot. Cuando queda resuelta, la pregunta entra en el golden dataset y se comprueba cada semana.

Lo mismo pasa con los errores. En nuestro asistente de citas, si alguien pedía cita «el 11 de enero» en pleno junio, el chatbot lo entendía como un enero ya pasado. Desde que lo detectamos, el año lo calcula el código y no el modelo, y ese caso se vuelve a comprobar en cada cambio.

Alarmas para los fallos que nadie ve

También vigilamos que las alarmas funcionen, porque un fallo sin aviso puede pasar días sin que nadie lo vea. En nuestro asistente de citas, por ejemplo, hay un centenar de comprobaciones dentro del propio código que avisan en cuanto algo se sale de lo esperado. Una de ellas nos avisó de que las citas creadas a mano desde el panel no actualizaban la ficha del cliente, y dejamos una prueba que lo cubre.

Las alarmas también fallan. Una vez, una alarma que saltaba demasiadas veces agotó la cuota del servicio de avisos, y 13 recordatorios de citas se perdieron sin ningún aviso. Nos lo dijo la clínica. Desde entonces cada alarma tiene un tope diario, y una prueba comprueba que ese tope se respeta.

Cuando sale un modelo nuevo: ¿cambiar o no?

Un modelo nuevo o más barato no entra porque sí. Primero pasa el mismo golden dataset, y en Phoenix comparamos las dos versiones caso a caso. Si el nuevo acierta menos, no se cambia, aunque sea más barato.

La versión del modelo, además, está fijada. Actualizarla es una decisión nuestra y pasa las pruebas como cualquier otro cambio, así que una versión nueva del proveedor no llega sola a producción.

Qué recibe tu empresa cada semana

Todo lo que vemos nosotros lo ves tú también. Te entregamos:

• El panel de Phoenix, con las trazas, el gasto y la comparación entre versiones.
• Los resultados de cada ejecución semanal del golden dataset.
• Las preguntas que el chatbot no supo contestar, para decidir juntos qué ajustar.
• Un informe semanal que lo resume, si lo necesitas.

En los proyectos a medida, el código y la infraestructura quedan a tu nombre desde el primer día. El mantenimiento va en una cuota mensual sin permanencia, y los precios están en la guía cuánto cuesta un agente de IA.

No vas a tener un chatbot que nunca se equivoque, porque eso no existe. Vas a tener uno que se mide cada semana, que se prueba antes de cada cambio y que mejora con lo que no supo responder.