El agente estuvo equivocado todo el martes
¿Quieres hablar de este ensayo? Escríbeme: amitkvint@gmail.comcopiado· o escríbeme por LinkedIn
Toda demo de soporte con IA corre en un mundo que el sistema ya conoce.
La documentación está al día. Los bugs son bugs que alguien ya reportó. Las preguntas son preguntas que los clientes ya hicieron.
En ese mundo, un agente puede parecer excelente. Y, para ser justos, normalmente lo es.
Producción es otra cosa.
Producción es un martes por la mañana.
Cómo es un martes
Sale un bug nuevo con una release. Algo cambia por debajo. O dos productos que nunca se habían cruzado empiezan a llevarse mal en el sitio de un cliente.
Sea cual sea la causa, en algún momento del martes por la mañana hay un problema real que nadie ha visto antes.
Escribe el primer cliente.
El reporte parece de lo más normal. No hay nada en la forma en que alguien describe un bug recién nacido que indique que es nuevo. Describen lo que están viendo. Los síntomas se parecen a algo ya documentado. El sistema toma la respuesta que ya existe y tira con ella.
Así que el agente responde.
Rápido. Con educación. Con seguridad.
Y mal.
Y luego hace lo mismo con el siguiente cliente, y con el siguiente.
Esa consistencia es una de las razones para poner un agente a gestionar una cola de unos 4.000 reportes al mes. No se cansa, y no se le olvida cómo hacer algo porque ha tenido una mañana complicada.
El martes, en cambio, eso es justamente el problema.
Un equipo de soporte humano tiene un sistema de alerta temprana que nadie diseñó. Alguien del segundo nivel dice: "Este es el tercero de estos hoy. Algo está pasando".
El agente no tiene un tercer ticket.
Todos los tickets son el primero.
La solución fue una puerta, no un modelo
Un puñado de decisiones pesaron más en ese despliegue que cualquier prompt que escribiéramos. Sobre algunas ya he escrito, pero esta es importante.
Construimos una forma de meter información nueva en el sistema de inmediato, en lugar de esperar al ciclo de actualización normal.
Ya está.
No era nada del otro mundo. Era el equivalente operativo de dejar una nota en la mesa de alguien:
Desde esta mañana, esto no es el problema de siempre. Es uno nuevo. Esto es lo que hay que saber.
Lo importante no era construir el mecanismo. Eso lo puede hacer cualquier equipo competente.
Lo importante fue decidir de antemano que la distancia entre "una persona lo sabe" y "el sistema lo sabe" era algo que teníamos que medir.
Y que la queríamos medida en minutos, no en ciclos de actualización.
Porque la alternativa no es que el agente se calle hasta que la documentación se ponga al día.
La alternativa es que siga dando la respuesta antigua. La que era correcta hasta esta mañana. Todo el día. A todo el mundo.
Alguien tiene que darse cuenta
Una puerta no sirve de nada si nadie la cruza.
Y esa parte no es una decisión tecnológica en absoluto.
El override solo funciona si alguien está leyendo lo que el agente les dice de verdad a los clientes, y si esa persona puede contradecirlo sin tener que convocar una reunión antes. En nuestro caso eso salió de la costumbre semanal de repasar las respuestas del agente, que es un tema en sí mismo y sobre el que volveré.
Creo que aquí es donde el "human in the loop" se suele quedar corto.
No es una persona aprobando respuestas de una en una. Eso no escala, y tira por la borda casi todo lo que acabas de comprar.
Es una persona cuyo trabajo es darse cuenta de que el mundo cambió esta mañana, y que tiene una forma de decírselo al sistema antes de comer.
Lo que cuesta ir lento
Los primeros problemas eran, en general, arreglables desde el punto de vista técnico. Una respuesta equivocada es un bug, y los bugs se arreglan.
Lo que costó mucho más reparar fue lo que clientes y gente de soporte pasaron a sentir respecto al agente.
Un cliente al que le dijeron algo incorrecto, con total seguridad, no vuelve a cero cuando arreglas el problema de fondo. Y tampoco lo hace quien se pasó la tarde del martes pidiendo perdón por algo que no había escrito.
Esa es la verdadera razón por la que el override importaba, y no aparece en ninguna métrica.
Después del despliegue completo, nuestro tiempo medio de resolución pasó de unas 24 horas a unas 10, y la satisfacción se mantuvo por encima del 95%.
Esos números describen semanas normales. Sobreviven a las otras solo si las otras se detectan la mañana en que empiezan.
La parte a la que sigo volviendo
Una demo pone a prueba el modelo.
Producción pone a prueba la distancia entre el momento en que una persona sabe algo y el momento en que lo sabe el sistema.
Así que si estás evaluando un agente para tu propia cola, yo preguntaría por esa distancia antes que por la precisión. ¿Cómo entra la información nueva? ¿Quién puede meterla? ¿Cuánto tarda?
¿Y qué dice el sistema mientras tanto, mientras no lo sabe?
"Estará en la próxima actualización" es una respuesta perfectamente válida para la documentación.
Es una mala respuesta para un martes.