Algunos de los comentarios que recibimos sobre los datos de referencia publicados anteriormente, consulte aquí y aquí, se refería al hecho de que el Conjunto de datos de Jason Kincaid contenía algo de audio que producía un WER terrible en todos los reconocedores y, en la práctica, nadie utilizaría el reconocimiento de voz automático en esos archivos. Eso es cierto. En nuestra opinión, hay muy pocos casos de uso en los que un WER inferior al 20%, es decir, en los que una media de 1 de cada 5 palabras se reconoce incorrectamente, sea aceptable.

Nueva metodología

Lo que hemos hecho para esta entrada de blog es eliminar del conjunto denunciado aquellos archivos de referencia para los que ninguno de los reconocedores probados podía ofrecer un WER del 20% o menos. Como resultado de este criterio, se eliminaron 10 archivos: 9 del conjunto de 44 de Jason Kincaid y 1 archivo del conjunto de 20 de rev.ai. Los archivos eliminados se dividen en 3 categorías:

• grabaciones de reuniones: 4 archivos (esto equivale a la mitad de las grabaciones de reuniones del conjunto original),
• conversaciones telefónicas: 4 archivos (4 de las 11 conversaciones telefónicas del conjunto original),
• podcasts con varios presentadores y muy animados: 2 archivos (había muchos otros podcasts en el set que sí alcanzaron el límite).

Los resultados

Como puede ver, los reconocedores de Voicegain y Amazon coinciden de manera muy uniforme, con un WER promedio que difiere solo en un 0,02%, lo mismo ocurre con los reconocedores de Google Enhanced y Microsoft, con una diferencia de WER de solo el 0,04%. El WER de Google Standard es aproximadamente el doble que el de los demás reconocedores.

‍

[ACTUALIZACIÓN - 31 de octubre de 2021: Los resultados de referencia actuales de finales de octubre de 2021 están disponibles aquí. En el punto de referencia más reciente, Voicegain funciona mejor que Google Enhanced. Nuestro precio es ahora de 0,95 céntimos por minuto]

[ACTUALIZAR: Para los resultados notificados utilizando una metodología ligeramente diferente vea nuestra nueva entrada de blog.]

Se trata de una continuación del entrada de blog de junio donde informamos de los resultados anteriores de precisión de voz a texto. Te animamos a que lo leas primero, ya que establece un contexto para entender mejor la importancia de la evaluación comparativa de la conversión de voz a texto.

Además de esa introducción de fondo, las diferencias clave con respecto a la publicación anterior son:

• Hemos mejorado nuestro reconocedor y ahora estamos básicamente vinculados con Amazon.
• Añadimos otro conjunto de archivos de referencia: 20 archivos publicado por rev.ai. Consulte los datos enlazados aquí al intentar reproducir este punto de referencia.

Estos son los resultados.

Comparación con el índice de referencia de junio en 44 archivos.

‍

Han pasado menos de 3 meses desde la prueba anterior, por lo que no es sorprendente no ver ninguna mejora en los reconocedores de Google y Amazon.

El reconocedor Voicegain ha superado a Amazon por un pelo en cuanto a precisión media, aunque la precisión media de Amazon en este conjunto de datos es ligeramente superior a Voicegain.

El reconocedor de Microsoft ha mejorado durante este período: en los 44 archivos de referencia, ahora es, de media, mejor que Google Enhanced (en el gráfico, conservamos los pedidos de la prueba de junio). El único valor atípico negativo en los resultados de Google Enhanced no explica por sí solo el mejor promedio de WER de Microsoft en este conjunto de datos.

Google Standard sigue siendo muy malo y es probable que dejemos de informar sobre él en detalle en nuestras futuras comparaciones.

Resultados del análisis comparativo en 20 archivos nuevos.

El audio del archivo 20 rev.ai la prueba no es tan difícil como algunos de los archivos del conjunto de referencia de 44 archivos. En consecuencia, los resultados son, en promedio, mejores, pero la clasificación de los reconocedores no cambia.

Como puede ver en este gráfico, en este conjunto de datos, el reconocedor Voicegain es ligeramente mejor que el de Amazon. Tiene un WER más bajo en 13 de los 20 archivos de prueba y supera a Amazon en los valores medios y medianos. En este conjunto de datos, Google Enhanced supera a Microsoft.

Resultados combinados en 44+20 archivos

Finalmente, aquí están los resultados combinados de los 64 archivos de referencia que probamos.

‍

En el índice de referencia combinado, Voicegain supera a Amazon tanto en promedio como en promedio de WER, aunque la ventaja media no es tan grande como en el conjunto rev.ai de 20 archivos. [Tenga en cuenta que, a partir del 2 de octubre de 2021, el WER de Voicegain es ahora 16,46|14,26]

Lo que nos gustaría señalar es que, al comparar Google Enhanced con Microsoft, uno gana si comparamos el WER promedio, mientras que el otro tiene un valor de WER mediano mejor. Esto pone de relieve que los resultados varían mucho según el archivo de audio específico que se esté comparando.

Conclusiones

Estos resultados muestran que la elección del mejor reconocedor para una aplicación determinada solo debe hacerse después de realizar pruebas exhaustivas. El rendimiento de los reconocedores varía mucho según los datos de audio y el entorno acústico. Además, los precios varían significativamente. Le animamos a que prueba Voicegain Speech-to-Text motor para su aplicación. Puede que sea más adecuado para su aplicación. Aunque la precisión esté un par de puntos por detrás de la de los dos mejores jugadores, tal vez quieras considerar Voicegain porque:

• Nuestros modelos acústicos se pueden personalizar según el audio de su voz específico y esto puede reducir las tasas de error de palabras por debajo de las mejores opciones listas para usar. Consulte nuestra Precisión mejorada a partir de la entrada del blog Acoustic Model Training.
• Si la diferencia de precisión es pequeña, Voicegain aún podría tener sentido dado el precio más bajo.
• Estamos entrenando continuamente a nuestro reconocedor y solo es cuestión de tiempo que nos pongamos al día.

‍

Voicegain lanzó una extensión para Voicegain API /asr/recognize que apoya Twilio Transmisiones multimedia vía TwiML <Connect><Stream>. Con este lanzamiento, los desarrolladores que utilizan la voz programable de Twilio obtienen una preciso, asequible, y un ASR fácil de usar para crear Voice Bots /Speech-IVRs.

Actualización: Voicegain también anunció que su transcripción de vocabulario extenso (/asr/transcribe API) se integra con Twilio Media Streams. Los desarrolladores pueden usarlo para activar por voz un bot de chat desarrollado en cualquier plataforma de bots o desarrollar una aplicación de asistencia para agentes en tiempo real.

Características principales de la compatibilidad con Twilio Media Streams

La compatibilidad con Voicegain Twilio Media Streams ofrece a los desarrolladores las siguientes funciones:

1. Soporte gramatical para bots e IVR: Los desarrolladores ahora pueden escribir bots de voz o IVR que usen gramáticas. El uso de gramáticas puede mejorar la precisión del reconocimiento y simplificar el desarrollo de bots restringiendo el motor de conversión de voz a texto. Además, muchos IVR tradicionales de VoiceXML se crean utilizando gramáticas. <Gather>Hasta ahora, Twilio Twiml no admitía el uso de gramáticas de voz, ya que el comando solo admite la captura de texto. Esto dificultaba la creación de bots sencillos o la migración de las aplicaciones de IVR de VoiceXML existentes a la plataforma Twilio. La asignación del texto al significado semántico tenía que hacerse por separado, además de que un reconocedor de vocabulario extenso era más probable que devolviera reconocimientos falsos. Voicegain resuelve estos problemas al admitir ambos GRXML y JSGF gramáticas de voz en el nivel básico del motor de conversión de voz a texto (ASR). Esto ofrece una mayor precisión en comparación con un ASR que utiliza un modelo lingüístico de vocabulario extenso para reconocer el texto y, a continuación, aplica la gramática al texto reconocido.
2. Ahorro del 90% en los costos de licencias de ASR: Una gran ventaja para los desarrolladores de la plataforma de voz programable Twilio ha sido su precio asequible. Sin embargo, eso no era necesariamente cierto en el caso de las opciones de ASR existentes, ya <Gather>que tienen un precio de 8 céntimos por minuto (con un mínimo de 15 segundos). Con Voicegain, el ASR/STT precio es de 1,25 céntimos/minuto medido en incrementos de 1 segundo. Si incluyes el incremento de facturación, los desarrolladores obtenga un ahorro de costos del 90%.
3. Mejor soporte de tiempo de espera: Voicegain admite tiempos de espera configurables sin entrada, tiempo de espera completo y tiempo de espera incompleto. Gracias a que la gramática está integrada en el reconocedor, Voicegain ASR es capaz de ofrecer una respuesta precisa y completa cuando se agota el tiempo de espera, algo que no es posible con un <Gather>comando, ya que la única forma de saber si la persona que llama ha dejado de hablar es haciendo una pausa lo suficientemente larga.
4. Simplifica reproducción dinámica de mensajes<Stream>. -- Para que su uso sea lo más <Connect><Stream>fácil posible, admitimos pasar instrucciones al invocar. Las instrucciones se pueden proporcionar como texto o como URL. Si se proporciona como texto, Voicegain utilizará TTS o realizará una concatenación dinámica de las indicaciones pregrabadas. Como parte del portal web de Voicegain, se proporciona un administrador de mensajes para tales mensajes pregrabados. Configurable irrumpir es compatible con las indicaciones.
5. Afina y prueba las gramáticas. -- El portal web Voicegain incluye una herramienta para revisar y ajustar la gramática. La herramienta también admite pruebas de regresión. Con esta funcionalidad, nunca tendrá que implementar gramáticas sin saber qué tan bien funcionarán después de los cambios.

Cómo funciona Twilio Media Streams con Voicegain

‍

‍

TWiML <Stream>requiere una URL de websocket. Esta URL se puede obtener invocando la API Voicegain /asr/recognize/async. Al invocar esta API, se debe proporcionar la gramática que se utilizará en el reconocimiento. La URL del websocket se devolverá en la respuesta.

‍

Además de la URL wss, los parámetros personalizados del <Connect><Stream>comando se utilizan para transmitir información sobre la línea de pregunta que Voicegain reproducirá a la persona que llama. Puede ser un texto o una URL a un servicio que proporcionará el audio.

Una vez que <Connect><Stream>se ha invocado, la plataforma Voicegain se hace cargo de ella:

• Reproduce el mensaje a través del canal posterior de <Stream>
• Tan pronto como la persona que llama comience a hablar, la reproducción del mensaje se detiene (si aún se estaba reproduciendo) exactamente igual que en <Gather>
• Las palabras habladas se reconocen mediante la gramática. Luego, el resultado del reconocimiento se proporciona como una devolución de llamada desde la plataforma Voicegain. En caso de que no se introduzca ninguna información o no coincida, también se realizará una devolución de llamada adecuada.
• <Stream>la conexión se detiene y la aplicación TWiML continuará con el siguiente comando.

Por cierto, también admitimos la entrada DTMF como alternativa a la entrada de voz.

[ACTUALIZACIÓN: puedes ver más detalles sobre cómo usar Voicegain con Twilio Media Streams en esta nueva Entrada de blog.]

Otras funciones de la plataforma Voicegain

1. Soporte Edge local: Si bien las API de Voicegain están disponibles como un servicio de PaaS en la nube, Voicegain también admite la implementación local o perimetral. Voicegain se puede implementar como un servicio en contenedores en un clúster de Kubernetes de un solo nodo o en un clúster de Kubernetes de alta disponibilidad de varios nodos (en el hardware de la GPU o en la VPC).

2. Personalización del modelo acústico: Esto permite lograr una precisión muy alta más allá de lo que es posible sin los reconocedores listos para usar. La herramienta de ajuste gramatical y regresión mencionada anteriormente se puede utilizar para recopilar datos de entrenamiento para la personalización del modelo acústico.

Próximamente más funciones

En nuestra hoja de ruta a corto plazo para los usuarios de Twilio, tenemos varias funciones más:

• Avanzado Detección de contestador automático (AMD): se invocará mediante el <Connect><Stream>reconocimiento de voz y proporcionará una detección muy precisa del contestador automático.
• Modelo de lenguaje de amplio vocabulario para capturar solo las palabras habladas (no se utilizan gramáticas) e integrarlo con cualquier motor de NLU de su elección. <Gather>Creemos que será atractivo debido al menor costo en comparación con.
• Asistencia de agentes en tiempo real - estamos combinando nuestro reconocimiento de voz en tiempo real con el análisis de voz para ofrecer una API que permitirá crear aplicaciones de supervisión y asistencia a los agentes en tiempo real.

Puedes inscribirte en prueba nuestro plataforma. Ofrecemos 600 minutos de uso mensual gratuito de la plataforma. Si tienes preguntas sobre la integración con Twilio, envíanos una nota a support@voicegain.ai.

Twilio, TwiML y Twilio Programmable Voice son marcas comerciales registradas de Twilio, Inc.

‍

Empresas de todos los tamaños buscan desarrollar Voicebots para automatizar las llamadas de servicio al cliente o las interacciones de ventas basadas en la voz. Estos bots pueden ser versiones de voz de los chatbots existentes o bots basados exclusivamente en la voz. Si bien los chatbots automatizan las transacciones rutinarias en la web, a muchos usuarios les gusta poder usar la voz (aplicación o teléfono) cuando es conveniente.

Un cuadro de diálogo de un robot de voz consta de varias interacciones, en las que una sola interacción normalmente implica 3 pasos:

1. La expresión hablada de una persona que llama o un cliente se convierte en texto
2. La intención se extrae del texto transcrito
3. El siguiente paso de la conversación se determina en función de la intención extraída y del estado/contexto actual de la conversación.

Para el primer paso, los desarrolladores utilizan una plataforma de conversión de voz a texto para transcribir la expresión hablada en texto. El ASR o reconocimiento automático de voz es otro término que se utiliza para describir el mismo tipo de software.

Cuando se trata de extraer la intención del discurso del cliente, normalmente utilizan un motor de NLU. Esto es comprensible porque a los desarrolladores les gustaría reutilizar el flujo de diálogo o los turnos de conversación programados en su aplicación Chatbot para su Voicebot.

Una segunda opción es usar Gramáticas del discurso que coinciden con la expresión hablada y le asignan un significado (intención). Esta opción no está muy de moda hoy en día, pero las gramáticas de voz se han utilizado con éxito en los sistemas IVR de telefonía que permitían la interacción de voz mediante ASR.

Este artículo explora ambos enfoques para crear Voicebots.

El enfoque de la NLU

La mayoría de los desarrolladores actuales utilizan el enfoque NLU como opción predeterminada para los pasos 2 y 3. Los motores de NLU más populares incluyen Flujo de diálogo de Google, Microsoft LUIS, Amazon Lex y también cada vez más un marco de código abierto como RASA.

Un motor de NLU ayuda a los desarrolladores a configurar diferentes intenciones que coincidan con las frases de entrenamiento, especificar los contextos de entrada y salida que están asociados a estas intenciones y definir las acciones que impulsan los turnos de conversación. Este método de desarrollo es muy poderoso y expresivo. Te permite crear bots que sean verdaderamente conversacionales. Si usas NLU para crear un chatbot, generalmente puedes reutilizar la lógica de su aplicación para un Voicebot.

Sin embargo, tiene un inconveniente importante. Es necesario contratar desarrolladores de lenguaje natural altamente cualificados. Diseñar nuevas intenciones, gestionar los contextos de entrada y salida, las entidades, etc., no es fácil. Dado que se necesitan desarrolladores expertos, el desarrollo de bots con NLU es caro. No solo es caro de construir, sino que también es costoso de mantener. Por ejemplo, si quieres añadir nuevas habilidades al bot que superen su conjunto inicial de capacidades, modificar los contextos no es un proceso fácil.

El enfoque de NLU de Net-net es una muy buena opción si (a) quieres desarrollar un bot sofisticado que pueda soportar una experiencia verdaderamente conversacional (b) puedes contratar e involucrar a desarrolladores de PNL expertos y (c) tienes los presupuestos adecuados para desarrollar dichos bots.

El enfoque de la gramática del habla

Un enfoque que se utilizó en el pasado y que parece haberse olvidado en estos días es el uso de Gramáticas del discurso. Las gramáticas se utilizaron ampliamente para crear IVR de voz tradicionales basados en telefonía desde hace más de 20 años, pero la mayoría de los desarrolladores web y de PNL no las conocen.

La gramática de un discurso proporciona una lista de todos los enunciados que se pueden reconocer o, más comúnmente, un conjunto de reglas que pueden generar los enunciados que se pueden reconocer. Esta gramática combina dos funciones:

1. proporciona un modelo lingüístico que guía al motor de conversión de voz a texto en la evaluación de las hipótesis, y
2. puede atribuir un significado semántico a los enunciados de texto reconocidos.

La segunda función se logra adjuntando etiquetas a las reglas de las gramáticas. Existen formatos de etiqueta que permiten evaluar expresiones complejas en gramáticas con muchas reglas anidadas. Estas etiquetas permiten al desarrollador básicamente codificar la extracción de la intención directamente en la gramática.

Además, el paso 3, que es la gestión del flujo de diálogos y conversaciones, se puede implementar en cualquier lenguaje de programación de backend (Java, Python o Node.js). Los desarrolladores de bots de voz que dispongan de un presupuesto limitado y quieran crear un bot sencillo con pocas intenciones deberían considerar seriamente la gramática como un enfoque alternativo a la NLU.

Comparación de la NLU y la gramática del habla

Ventajas de la NLU

• La NLU se puede aplicar al texto que se ha escrito, así como al texto que proviene del motor de conversión de voz a texto. En principio, esto permite utilizar la misma lógica de aplicación tanto para un chatbot como para un voicebot. La gramática oral no es buena para ignorar el texto de entrada que no coincide con las reglas gramaticales. Esto hace que la gramática de voz no sea directamente aplicable a los chatbots, aunque se han ideado formas de permitir que la gramática del habla haga «coincidencias difusas».
• Una NLU bien entrenada puede captar las intenciones correctas en situaciones más complejas que una gramática oral. Sin embargo, tenga en cuenta que algunas de las técnicas de la NLU se pueden utilizar para generar automáticamente gramáticas con etiquetas que podrían ser más adecuadas para el rendimiento de la NLU.

Ventajas de las gramáticas

• El reconocimiento de la intención de la NLU puede verse afectado si la conversión de voz a texto no fue 100% correcta. Hemos visto informes en los que la precisión combinada de voz a texto y NLU es muy baja (hasta tan solo el 70%) en algunos casos de uso. Las gramáticas del habla, por otro lado, se utilizan como modelo lingüístico al evaluar las hipótesis del habla. Esto permite que el reconocedor siga pronunciando las intenciones correctas incluso cuando la frase hablada no coincida exactamente con la gramática; el resultado del reconocimiento será menos fiable, pero seguirá siendo utilizable.
• Las gramáticas de voz son fáciles de crear y usar. Además, no es necesario integrar el sistema NLU con el sistema de conversión de voz a texto. Todo el trabajo puede ser realizado por el motor Speech-to-Text
  

Nuestra recomendación

Voicegain es uno de los pocos motores de conversión de voz a texto o ASR que admite ambos enfoques.

Los desarrolladores pueden integrar fácilmente el amplio vocabulario de voz a texto de Voicegain (API de transcripción) con cualquier motor NLU popular. Una ventaja que tenemos aquí es la capacidad de generar múltiples hipótesis, cuando se utiliza el modo de salida de árbol de palabras. Esto permite hacer múltiples coincidencias entre las intenciones de la NLU para las diferentes hipótesis de voz con el objetivo de determinar si existe un consenso en la NLU a pesar de las diferencias en la producción de voz a texto. Este enfoque puede ofrecer una mayor precisión.

También ofrecemos nuestro Reconocer la API y API de devolución de llamadas de RTC ; ambos son compatibles con la gramática del habla. Los desarrolladores pueden codificar el flujo o diálogo de la aplicación del robot de voz en cualquier lenguaje de programación de fondo: Java, Python o Node.Js. Tenemos un amplio soporte para protocolos de telefonía como SIP/RTP y admitimos WebRTC.

La mayoría de los demás motores STT, incluidos Microsoft, Amazon y Google, no admiten gramáticas. Esto puede tener algo que ver con el hecho de que también están intentando promocionar sus motores de NLU para aplicaciones de chatbots.

Si estás creando un Voicebot y te gustaría tener una conversación sobre el enfoque que más te conviene, no dudes en obtener en contacto con nosotros. Puede enviarnos un correo electrónico a info@voicegain.ai.

‍

Muchas aplicaciones de voz a texto (STT) o reconocimiento de voz (ASR) requieren que la conversión de audio a texto se realice en tiempo real. Estas aplicaciones pueden ser los bots de voz, la subtitulación en directo de vídeos, eventos o charlas, la transcripción de reuniones, el análisis de voz en tiempo real de las llamadas de ventas o la asistencia de un agente en un centro de contacto.

Una pregunta importante para los desarrolladores que buscan integrar STT en tiempo real en sus aplicaciones es la elección del protocolo y/o mecanismo para transmitir audio en tiempo real a la plataforma STT. Si bien algunos proveedores de STT ofrecen solo un método, en Voicegain ofrecemos varias opciones entre las que los desarrolladores pueden elegir. En esta publicación, exploramos en detalle todos estos métodos para que un desarrollador pueda elegir el más adecuado para su caso de uso específico.

Algunos de los factores que pueden guiar la elección específica son:

• Su lenguaje de programación y plataforma de implementación actuales: ¿hay bibliotecas de cliente disponibles en el lenguaje de programación o plataforma de desarrollo (ya sea Java, Javascript, Python, Go, etc.) en los que se basa la aplicación?
• Cómo se pone la transmisión de audio a disposición de la aplicación: es posible que la aplicación ya esté recibiendo la transmisión de audio de una manera y un formato determinados.
• El tipo de aplicación y sus requisitos de latencia y resiliencia de la red
• En relación con lo anterior: la calidad de la red entre la aplicación y la plataforma STT.
  

En Voicegain actualmente ofrecemos siete métodos/protocolos diferentes para admitir la transmisión a nuestra plataforma STT. Los tres primeros son métodos basados en TCP y los últimos cuatro métodos están basados en UDP.

• TCP los métodos basados en general son una buena idea si la calidad de la red es muy sólida
• UDP los métodos basados podrían ser una mejor opción si la aplicación admite telefonía
  

Las opciones

1. WebSockets

El uso de WebSockets es una opción simple y popular para transmitir audio a Voicegain para el reconocimiento de voz. Los WebSockets existen desde hace tiempo y la mayoría de los lenguajes de programación web tienen bibliotecas que los admiten. Esta opción puede ser la forma más fácil de empezar. La API Voicegain usa WebSockets binarios, y tenemos algunos ejemplos sencillos para empezar.

2. HTTP 1.1 con codificación de transferencia fragmentada

Voicegain también admite la transmisión a través de HTTP 1.1 mediante codificación de transferencia fragmentada. Esto le permite enviar datos de audio sin procesar con un tamaño desconocido, como suele ser el caso de la transmisión de audio. Voicegain es compatible con ambos modos: podemos obtener el audio de la URL que tú proporciones o la aplicación puede enviar el audio a la URL que tú proporciones. Para usar este método, tu lenguaje de programación debe tener bibliotecas que admitan la codificación por transferencia fragmentada a través de HTTP; algunas de las bibliotecas HTTP más antiguas o más sencillas no la admiten.

3. gRPC

gRPC se basa en el protocolo HTTP/2, que se diseñó para admitir conexiones bidireccionales de larga duración. Además, gRPC usa búferes de protocolo, que son un formato de serialización de datos más eficiente en comparación con el JSON que se usa comúnmente en las API HTTP RESTful. Ambos aspectos de gRPC permiten que los datos de audio se envíen de manera eficiente a través de la misma conexión que también se usa para enviar comandos y recibir resultados.

Con gRPC, las bibliotecas del lado del cliente se pueden generar fácilmente para varios lenguajes, como Java, C#, C++, Go, Python, Node Js, etc. El código de cliente generado contiene stubs para que los clientes de gRPC los usen para llamar a los métodos definidos por el servicio.

Con gRPC, los clientes pueden invocar las API STT de Voicegain como un objeto local cuyos métodos exponen las API. Este método es una forma rápida, eficiente y de baja latencia de transmitir audio a Voicegain y recibir respuestas de reconocimiento. Las respuestas se envían desde el servidor al cliente a través de la misma conexión, lo que elimina la necesidad de realizar sondeos o llamadas para obtener los resultados cuando se usa HTTP.

gRPC es excelente cuando se usa desde el código de fondo o desde Android. No es una solución lista para usar cuando se usa desde navegadores web, pero requiere algunos pasos adicionales.

Métodos basados en UDP

Los tres primeros métodos descritos anteriormente son métodos basados en TCP. Funcionan muy bien para la transmisión de audio siempre que la conexión no tenga ninguna pérdida de paquetes o ésta sea mínima. La pérdida de paquetes provoca importantes retrasos y fluctuaciones en las conexiones TCP. Esto puede funcionar bien si el audio no tiene que procesarse en tiempo real y se puede almacenar en búfer.

Si el comportamiento en tiempo real es importante y se sabe que la red no es confiable, el protocolo UDP es una mejor alternativa al TCP para la transmisión de audio. Con el UDP, la pérdida de paquetes se manifiesta como interrupciones del audio, pero esto puede ser preferible a pausas y fluctuaciones excesivas en el caso del TCP.

4. Protocolo RTP con extensiones Voicegain

RTP es un protocolo estándar para la transmisión de audio a través de UDP. Sin embargo, el RTP en sí mismo no suele ser suficiente y normalmente se usa con el protocolo de control RTP (RTCP) que lo acompaña. Voicegain ha implementado su propia variante del RTCP que se puede usar para controlar las transmisiones de audio RTP enviadas al reconocedor.

Actualmente, la única forma de transmitir audio mediante RTP a la plataforma Voicegain es utilizar nuestra biblioteca Java patentada Audio Sender. También ofrecemos Audio Sender Daemon, que es capaz de leer datos directamente desde dispositivos de audio y transmitirlos a Voicegain para su transcripción en tiempo real.

5. SIP/RTP

Si quieres invocar la conversión de voz a texto en un centro de contacto, Voicegain ofrece API de bots de telefonía. Puedes leer más sobre ellos aquí. Básicamente, la plataforma Voicegain puede actuar como un punto final SIP y se puede invitar a una sesión SIP. Podemos hacer dos cosas: 1) Como parte de un IVR o un bot, reproducir las instrucciones y recopilar las entradas de la persona que llama. 2) Como parte de la asistencia de un agente en tiempo real, podemos escuchar y transcribir la interacción entre el agente y la persona que llama.

Para dar más detalles (1), con estas API puedes invitar a la plataforma Voicegain a una sesión SIPn, que proporciona acceso al audio con el motor Voicegain Speech-to-Text. Una vez que se haya establecido la transmisión de audio, puedes emitir comandos para reconocer las expresiones de las llamadas y recibir la respuesta de reconocimiento mediante nuestras llamadas web. Puede escribir la lógica de su aplicación utilizando cualquier lenguaje de programación o un motor de NLU de su elección; todo lo que necesita es poder gestionar las solicitudes HTTP y enviar respuestas.

La plataforma Voicegain en este escenario actúa esencialmente como una «boca» y un «oído» para toda la conversación que tiene lugar a través de SIP/RTP. La aplicación puede emitir comandos JSON a través de HTTP que reproducen las instrucciones y convierten la voz de la persona que llama en texto durante toda la llamada en una sola sesión. También puedes grabar toda la conversación si la llamada se transfiere a un agente en vivo y transcribirla en texto.

6. MRCP

Los proveedores de plataformas de centros de contacto, como las plataformas CCaaS basadas en Cisco, Genesys, Avaya y FreeSwitch, suelen admitir MRCP para conectarse a los motores de reconocimiento de voz. Voicegain permite el acceso mediante MRCP al reconocimiento de voz basado en vocabulario extenso y gramatical. Recomendamos el MRCP solo para despliegues en Edge, en la nube privada o locales

7. SIPREC

En los centros de contacto, para la transcripción en tiempo real de la interacción entre el agente y la persona que llama, Voicegain es compatible con SIPREC. Se proporciona más información aquí.

¡Haz una prueba de manejo con Voicegain!

1. Haga clic aquí para obtener instrucciones sobre cómo acceder a nuestro sitio de demostración en vivo.

2. Si estás creando una aplicación de voz genial y quieres probar nuestras API, haz clic aquípara crear una cuenta de desarrollador y recibir 50$ en créditos gratis

3. Si quieres usar Voicegain como tu propio asistente de transcripción con IA para las reuniones, haz clic aquí.

‍

Actualización de diciembre de 2020: hemos cambiado el nombre de las API de devolución de llamadas de RTC a API de bots de telefonía para reflejar mejor cómo los desarrolladores pueden usar estas API, es decir, crear bots de voz o IVR.

Si querías habilitar tu chatbot por voz o crear tu propio bot de voz basado en telefonía o un IVR con voz, Voicegain ha creado una API que es realmente genial - Versión 1.12.0 de Voicegain Speech-to-Text Platform ahora incluye las API de Telephony Bot (anteriormente denominadas API de devolución de llamadas de RTC).

Las API Voicegain Telephony Bot permiten cualquier Marco NLU/Bot para integrarse fácilmente con la infraestructura de telefonía y PSTN mediante (a) la plataforma SIP INVITE de Voicegain desde una plataforma de CPaaS de su elección o (b) comprando un número de teléfono directamente desde el portal Voicegain y apuntándolo a su bot. Luego puedes usar estas API de tipo callback para (i) reproducir instrucciones (ii) reconocer expresiones vocales o dígitos DTMF (iii) permitir la entrada rápida y otras funciones interesantes. Ofrecemos ejemplos de código que le ayudarán a integrar fácilmente el marco de bots de su elección en nuestras API de bots de telefonía.

Si no tienes un Bot Framework, también está bien. Puedes escribir la lógica en cualquier lenguaje de programación de backend (Python, Java o Node.JS) que pueda serializar las respuestas en formato JSON e interactuar con nuestras API de estilo Callback. Voicegain también ofrece un formato YAML declarativo para definir el flujo de llamadas. Además, puedes alojar esta lógica de archivos YAML e interactuar con estas API. Los desarrolladores también pueden codificar e implementar la lógica de la aplicación en un entorno informático sin servidor, como Amazon Lambda.

Muchas empresas (de la banca, los servicios financieros, la atención médica, las telecomunicaciones y el comercio minorista) están atrapadas en los IVR tradicionales basados en la telefonía, que se acercan a la obsolescencia.

Las API de Telephony Bot de Voicegain proporcionan una excelente ruta de actualización preparada para el futuro para este tipo de empresas. Dado que estas API se basan en devoluciones de llamadas web, pueden interactuar con cualquier lenguaje de programación de back-end. Por lo tanto, cualquier desarrollador web de backend puede diseñar, crear y mantener dichas aplicaciones.

¿Por qué deberías usar las API de Telephony Bot?

Con las API de Telephony Bot, la integración es mucho más sencilla para los desarrolladores.

1) Puede INVITAR SIP a la plataforma Voicegain Speech-to-Text/ASR a una sesión SIP/RTP durante el tiempo que sea necesario. Admitimos la integración de SIP con plataformas de CPaaS como Twilio, Signalwire y Telnyx. También admitimos plataformas de CCaaS como Genesys, Cisco y Avaya.

2) También admitimos el pedido directo de números de teléfono y enlaces troncales SIP desde la consola web Voicegain. Pronto se añadirán más integraciones.

API de bots de telefonía se basan en devoluciones de llamadas web en las que el programa/implementación real está en el lado del cliente y las API del bot de telefonía de Voicegain definen las solicitudes y las respuestas. El significado de solicitudes y respuestas es el mismo que el de una API web normal:

• Respuestas proporcione los comandos, mientras
• Solicitudes proporciona el resultado de esos comandos.

Ejemplo ilustrado de la API Telephony Bot en acción

A continuación se muestra un ejemplo de una interacción sencilla con una llamada telefónica controlada por la API Telephony Bot. El diagrama secuencial muestra cuatro llamadas recibidas durante una encuesta sobre juguetes:

• Requiso 1: Llegó la llamada telefónica
• Respuesta 1: Di: «Bienvenido»
• Requerimiento 2: Terminé de decir «Bienvenido»
• Respuesta 2: Pregunte: «¿Eres feliz?», encuadernar la respuesta a feliz var
• Repetición 3: La respuesta de la persona que llamó fue «sí», feliz=SÍ
• Respuesta 3: Desconectar
• Req. 4: Desconectado
• Respuesta 4: Hemos terminado

‍

Acciones apoyadas actualmente

La API Telephony Bot admite 4 tipos de acciones:

• salida: di algo: se admite TTS con una selección de 8 voces diferentes
• entrada: hacer una pregunta: se admiten tanto la entrada de voz como el DTMF. Para la entrada de voz, puede usar GRXML, JSGF o gramáticas integradas
• transferencia: transferir una llamada a un destino telefónico
• desconectar: finalizar la llamada
  

Espera, hay más

Cada llamada puede ser grabada (grabación de dos canales) y luego transcrito. Se puede acceder a la grabación y a la transcripción desde el portal y a través de la API.

Hoja de ruta

Próximamente habrá funciones:

• récord Acción de devolución de llamada: puede usarla para implementar el correo de voz o grabar otros tipos de mensajes
• transferir a un sorbo destino
• entrada - permitir la elección de amplio vocabulario conversión de voz a texto además de gramáticas: utilice el texto capturado en su NLU
• responder llame a un sorbo dirección: en lugar de un número de teléfono
• Soporte WebRTC
• marcación saliente

‍