Montar un asistente que responde bien en una demostración es cuestión de una tarde. Sostenerlo atendiendo clientes reales, todos los días, es otro problema. Estos son los fallos que aparecen al cruzar esa línea, tal como nos los hemos encontrado operando nuestros propios sistemas.
La demo tiene guion, el cliente no
En una demostración las preguntas son las que uno mismo ha preparado y siguen un orden razonable. Un cliente real escribe a las once de la noche, manda tres mensajes seguidos sin esperar respuesta, cambia de tema a la mitad, escribe con errores, manda una foto sin explicar qué es y da por hecho que el negocio recuerda lo que habló hace dos semanas.
Ninguno de esos comportamientos es raro. Son la norma. Y cada uno rompe suposiciones que la demo nunca puso a prueba.
Fallo 1: promete cosas que no hace
Es el más difícil de detectar y el que más daño hace. El asistente responde "te acabo de enviar el catálogo" y no envía nada. El cliente espera, no llega nada y se va.
La causa suele ser de arquitectura, no del modelo: el historial de la conversación guarda lo que se dijo, pero no si la acción llegó a ejecutarse. Cuando el modelo vuelve a leer ese historial ve su propia frase, la interpreta como un hecho consumado y sigue adelante. Nunca se entera de que falló.
Se corrige registrando el resultado de cada acción junto al mensaje, y no dando por buena una acción hasta que el sistema confirma que ocurrió.
Fallo 2: rellena los huecos con invención
Preguntado por un producto que no existe, un modelo sin restricciones prefiere ofrecer algo antes que decir que no lo tiene. Nos ha pasado: el asistente ofreció un producto con un nombre verosímil que no estaba en el catálogo.
La solución no es pedirle por escrito que no invente, porque eso funciona casi siempre y casi siempre no basta. Lo que funciona es que los datos que puede citar vengan de una fuente que el sistema controla, y que cuando la búsqueda no devuelve nada la respuesta sea explícitamente que no hay resultado.
Fallo 3: agenda horas que no existen
Un asistente que agenda citas y no consulta el calendario antes de proponer horas acaba confirmando citas imposibles. El cliente se presenta y no hay nadie, o hay dos personas citadas a la misma hora.
La regla que nos funcionó es simple: el asistente solo puede cerrar una cita en un horario que el propio calendario le ofreció en esa misma conversación. Si el hueco ya se ocupó mientras hablaban, vuelve a preguntar en lugar de confirmar.
Fallo 4: no sabe cuándo callarse
Hay conversaciones que una máquina no debe seguir sosteniendo: un cliente enfadado, una reclamación, una petición fuera de lo previsto. Un asistente que insiste en responder ahí empeora la situación.
Conviene decidir de antemano y por escrito qué situaciones se escalan a una persona, y que el traspaso lleve el contexto para que quien recibe no tenga que pedir al cliente que repita todo desde el principio.
Fallo 5: el proveedor cambia el modelo debajo
Los proveedores retiran modelos y cambian versiones con poco preaviso. Si el sistema apunta a un modelo concreto y ese modelo deja de existir, la atención se cae entera, y suele descubrirse por una queja y no por una alarma.
Nos ocurrió y la lección fue doble. La primera, tener un modelo de reserva al que caer automáticamente. La segunda, y menos evidente: al comprobar si un modelo sigue vivo hay que hacerlo con una petición igual a la real. Un saludo corto puede responder bien mientras la petición de verdad, con su contexto y sus herramientas, falla.
Cómo se detecta esto antes que el cliente
La tentación es probar a mano, leer las respuestas y decidir si "suenan bien". No sirve: en cuanto hay unas decenas de casos nadie los revisa con el mismo criterio dos veces seguidas.
- Un banco de pruebas fijo: un conjunto de conversaciones que se ejecutan igual en cada cambio y se comparan con el resultado anterior.
- Verificación por código, no por opinión: comprobar que la cita quedó creada en el calendario, que el mensaje salió, que el precio citado existe en el catálogo. Son cosas que se consultan, no que se valoran.
- Alarmas sobre el negocio, no solo sobre el servidor: que el servicio responda no significa que esté atendiendo. Vigilar cuántas conversaciones se quedan sin respuesta.
Una advertencia sobre usar otro modelo como juez que puntúe las respuestas: es útil para ordenar candidatos y detectar bultos, pero su nota no debe decidir si algo sale a producción. Puntúa alto respuestas que suenan seguras aunque sean falsas, que es justo el fallo que se quiere atrapar.
La conclusión incómoda
La diferencia entre un asistente que impresiona y uno que sirve no está en el modelo que use, sino en lo que ocurre alrededor: de dónde saca los datos, qué se le prohíbe afirmar, qué hace cuando no sabe, a quién avisa cuando se atasca y cómo se comprueba que lo que dijo que hizo lo hizo de verdad.
Ese trabajo no se ve en una demostración. Es todo el trabajo.