Agentes de voz y correcciones: por qué no basta con oír bien el número de pedido
Un agente de voz repitió el número de pedido corregido y aun así modificó el pedido equivocado. Cómo sobreviven las llamadas a herramientas obsoletas a una interrupción y cómo las detectan las máquinas de estados y las trazas.
Una confirmación que sonaba bien
Un cliente pide a un agente de voz que pase la entrega del pedido 4821 al viernes. Antes de que el agente termine de responder, el cliente lo interrumpe con una corrección: el número es 4281, no 4821. El agente se detiene a mitad de frase, asiente y promete actualizar el pedido 4281.
La llamada termina con buen ambiente. Sin embargo, el sistema modificó el pedido 4821 y nadie tocó el pedido 4281.
El reconocimiento de voz captó bien los dos números. El agente incluso repitió el corregido palabra por palabra. No hay nada mal en la transcripción, y aun así algo se rompió.
Por qué una transcripción no es un estado
La depuración empieza descartando a los sospechosos obvios. No fue un error de reconocimiento, y el agente no se inventó ningún número. La canalización simplemente trató cuatro cosas distintas como si fueran una sola:
Conversation history → 4821, then a correction to 4281
Active intent → the order the customer currently means
Pending action → the order ID already loaded into the tool call
Backend state → the order that was actually written
Una transcripción es un registro de eventos. Guarda todo lo dicho, en orden y para siempre. Los dos números de pedido están ahí con razón, porque se pronunciaron los dos. Pero tras la corrección solo uno de ellos debe estar en el estado activo de la tarea, y si la transcripción hace también de estado, nada puede marcar el valor anterior como obsoleto.
El registro de lo que se dijo era exacto. Lo que falló fue la transición de estado.
Cómo sobrevivió el valor obsoleto
Basta con tres decisiones de diseño corrientes para provocarlo, y la mayoría de las pilas de voz tienen las tres.
Un historial que solo crece
La corrección llega como un mensaje más y nadie invalida explícitamente el valor antiguo. En cada turno el modelo tiene que averiguar cuál de varios valores plausibles es el actual. Cuando la latencia es ajustada, ese razonamiento puede perder la carrera frente a la siguiente acción.
Herramientas preparadas demasiado pronto
Los agentes de voz están afinados para responder rápido, así que las llamadas a herramientas suelen empezar a rellenar argumentos antes de que el cliente acabe la frase. La interrupción silencia el audio. No cancela automáticamente una petición a la API que ya está en curso.
Varias copias de un mismo dato
El modelo conversacional, la capa de orquestación y la capa de llamadas a herramientas suelen guardar cada una su propia copia del identificador del pedido, y actualizar una no actualiza las demás. De ahí sale el peor resultado. En voz alta el agente anuncia 4281, pero la herramienta sigue teniendo 4821, así que la llamada suena correcta mientras la acción es errónea.
Lo que muestra la traza
Ni la transcripción ni la última respuesta hablada revelan nada de esto. Solo lo muestra una traza de ejecución con marcas de tiempo:
10:03:12.100 Customer mentions order 4821
10:03:12.420 Active state set: order_id = 4821
10:03:13.000 Update tool prepared: order_id = 4821
10:03:13.250 Customer interrupts: "Sorry, I meant 4281."
10:03:13.510 Conversation state updated: order_id = 4281
10:03:13.700 Previously prepared tool executes: order_id = 4821
10:03:14.100 Agent says: "I've updated order 4281."
La corrección llegó en 13.510, pero la llamada a la herramienta se había confirmado ya en 13.000. Todo lo posterior a esa confirmación, incluida la confirmación hablada, refleja un valor que ya no coincide con lo que quiere el cliente. Una evaluación que preguntara si la transcripción recogió la corrección, o si la respuesta nombró el pedido correcto, daría por buena esta llamada. Solo la traza deja ver la divergencia.
Las correcciones deben cancelar el trabajo pendiente
Un prompt más ingenioso no es la cura. La conversación debe funcionar como una máquina de estados por etapas, y una corrección tiene que deshacer cada paso que dependía del valor sustituido:
→ Intent detected
→ Parameters collected
→ Parameters validated
→ Customer confirmation
→ Action committed
→ Backend result verified
Cuando cambia el identificador del pedido, queda obsoleta toda una cadena: el registro del pedido cargado, el resultado de la comprobación de elegibilidad, los argumentos en cola para la herramienta, una confirmación que el cliente ya dio y cualquier escritura que no haya terminado. El flujo vuelve a la etapa de «parámetros recogidos» y avanza de nuevo. En la práctica, eso exige varias piezas trabajando juntas:
- estado de la tarea estructurado en lugar de un estado deducido de la transcripción
- números de versión en el estado, para poder detectar y rechazar una escritura obsoleta
- claves de idempotencia, para que una acción duplicada o superada no se aplique dos veces sin que nadie lo note
- cancelación explícita de las llamadas a herramientas en curso cada vez que hay una interrupción
- una confirmación ligada al estado actual y no al estado del momento en que empezó la confirmación
- una comprobación contra el backend tras la ejecución, en vez de fiarse de lo que devolvió la herramienta
Cómo probarlo
Una prueba que mida la exactitud de la transcripción nunca encontrará este tipo de error, porque la transcripción está bien. Para atraparlo hacen falta llamadas sintéticas que interrumpan en tres momentos concretos: antes de preparar la herramienta, durante la preparación y después del envío. Conviene ejecutarlas con varios tipos de corrección: número de pedido, cantidad, fecha de entrega, dirección, identidad del cliente y negación, como un cliente que pide confirmar y enseguida dice que no.
Cada ejecución se puntúa con siete preguntas:
- ¿Se captó la corrección?
- ¿Se actualizó el estado activo?
- ¿Se invalidó el valor antiguo?
- ¿Recibió la herramienta los argumentos correctos?
- ¿Se intentó una acción duplicada u obsoleta?
- ¿Era correcto el estado final del backend?
- ¿Coincidió la confirmación hablada con el backend?
La distancia entre la sexta pregunta y las comprobaciones de la confirmación hablada a nivel de transcripción es justo donde se esconde este fallo. Solo se hace visible con un conjunto de pruebas que mida la verdad del backend y no la verosimilitud de la conversación.
Oír no es aplicar
Un agente de voz no merece ningún mérito por oír una corrección ni por repetirla con claridad. Esas son afirmaciones conversacionales. Para que una corrección cuente, tiene que actualizar el estado activo, cancelar o sustituir la acción pendiente, llegar a la herramienta con los argumentos correctos y, al final, aparecer en el backend.
En la IA de voz, decir «le he entendido» es una afirmación conversacional, mientras que decir «la corrección está aplicada» es una afirmación sobre la gestión del estado. Los sistemas en producción tienen que verificar la segunda, porque si no lo hacen la transcripción no lo va a revelar.