Barge-in: por qué poder interrumpir a un agente de voz cambia la conversación

El término ya se utilizaba en los sistemas de respuesta de voz interactiva. La recomendación VoiceXML 2.0 del W3C, publicada el 16 de marzo de 2004, lo describe así: si la plataforma lo permite, el autor de la aplicación decide si el usuario puede interrumpir un mensaje con la voz o con una tecla del teclado. El texto señala que esto agiliza las conversaciones, pero que no siempre es deseable: para una advertencia o un aviso legal que debe escucharse completo, el barge-in debe desactivarse.

Las plataformas conversacionales actuales han retomado el concepto. En Dialogflow CX, la documentación de Google indica que, cuando el barge-in está activado, el usuario puede interrumpir el audio de la respuesta: el agente deja entonces de enviar audio y procesa la nueva entrada. Amazon Lex V2 permite elegir, para cada dato que solicita el bot, si el usuario puede interrumpirlo mientras habla.

Entre dos personas, nos interrumpimos para corregir («no, el martes, no el miércoles»), para responder antes de que termine la pregunta o para indicar que hemos entendido. Un agente que termina su frase mientras quien llama está hablando le obliga a repetir y da la impresión de hablar con una pared.

La documentación de Amazon Lex cita un caso de uso: el usuario que ya conoce la respuesta a la pregunta planteada, por ejemplo cuando se le pide el código de seguridad de su tarjeta. La recomendación VoiceXML subraya otro efecto: detener el mensaje lo antes posible evita el efecto de «tartamudeo», en el que el usuario se detiene a mitad de frase y vuelve a empezar porque cree que no se le ha oído.

VoiceXML distingue dos tipos de barge-in. Con el tipo «speech», el mensaje se detiene en cuanto se detecta habla o una pulsación de tecla, corresponda o no la entrada a lo esperado. Con el tipo «hotword», el mensaje continúa mientras no se haya reconocido por completo una expresión esperada, y todo lo demás se ignora.

El compromiso es el mismo hoy: reaccionar rápido a riesgo de interrumpirse por nada, o esperar un habla significativa a riesgo de parecer lento. En la API Realtime de OpenAI, el parámetro interrupt_response determina, según la referencia de la API, si una respuesta en curso se interrumpe automáticamente cuando la detección de actividad de voz señala el inicio del habla. El modo semantic_vad, según la documentación, hace que el modelo sea menos propenso a interrumpir al usuario, y el parámetro eagerness regula la prisa del modelo por interrumpir al usuario.

Para poder ser interrumpido, el agente debe escuchar mientras habla. Pero su propia voz puede volver a la señal captada, por ejemplo cuando quien llama usa el altavoz de su teléfono. Sin tratamiento, el sistema corre el riesgo de tomar su propia voz por una interrupción.

La especificación Media Capture and Streams del W3C define la cancelación de eco como la eliminación, de la señal grabada por el micrófono, del sonido que se está reproduciendo. En el lado de las redes telefónicas, la Unión Internacional de Telecomunicaciones dedica una recomendación entera, la G.168, a los canceladores de eco de las redes digitales. El barge-in solo es fiable si esta etapa funciona.

La detección de actividad de voz (VAD) decide cuándo alguien está hablando. La documentación de Deepgram reconoce que un ruido de fondo importante, como música o el timbre de un teléfono, puede activar la VAD e impedir la detección del silencio que marca el final de una frase. Propone una alternativa basada en el intervalo entre las palabras transcritas, que ignora los sonidos no vocales como unos golpes en una puerta, el timbre de un teléfono o el ruido de la calle.

OpenAI indica por su parte que un umbral de activación más alto exige un sonido más fuerte para activar el modelo, lo que puede funcionar mejor en entornos ruidosos, y que una duración de silencio más corta hace que el final del turno se detecte antes. Son ajustes, no soluciones universales, y cada uno tiene su contrapartida: un umbral demasiado alto puede hacer que se pierdan las voces débiles, y un silencio demasiado corto, que se corte a alguien que está pensando.

El barge-in también tiene un coste. Google precisa que, en Dialogflow CX, activarlo aumenta la duración facturable de cada turno, ya que el agente escucha mientras habla.

Bastan unas cuantas pruebas para hacerse una idea: interrumpir al agente a mitad de frase para corregir una fecha, llamar con el altavoz, llamar con la radio encendida, intercalar un breve asentimiento mientras habla, hacer una pausa larga antes de terminar la frase. Anote cada vez si el agente se detiene, si retoma correctamente y si ha entendido la corrección. Alyas contesta al teléfono las 24 horas a partir de la información que usted le facilita y deja una transcripción y un resumen de cada llamada en su área de cliente, lo que permite revisar estas pruebas. La prueba gratuita de diez días, sin tarjeta bancaria, permite realizar estas pruebas con sus propios escenarios.