El mercado empresarial actual de voz a texto se puede dividir en 3 grupos distintos de jugadores. Ten en cuenta que nos estamos centrando en las plataformas de conversión de voz a texto en lugar de en productos completos para el usuario final (por lo que no incluimos productos de consumo como Dragon NaturallySpeaking, etc.)

• Los antiguos ASR - por ejemplo, Nuance (y todas las empresas de voz que Nuance adquirió a lo largo de los años) y Lumenvox. Estos motores de conversión de voz a texto se remontan a finales de la década de 1990 y principios de la de 2000. Fueron construidos con tecnología basada en modelos gaussianos y cadenas ocultas de Markov. Requieren una instalación local.
• Servicios de conversión de voz a texto en la nube establecidos - como Google, AWS, Microsoft Azure, IBM. Algunos de ellos también comenzaron con reconocedores creados con modelos gaussianos y cadenas ocultas de Markov, pero en 2012 comenzaron la transición a reconocedores que utilizaban modelos de redes neuronales profundas para el reconocimiento de voz.
• Nuevos jugadores - se trata de empresas nuevas que se remontan aproximadamente a 2015. Fue entonces cuando Nvidia hizo posible que prácticamente cualquier persona entrenara DNN en las nuevas GPU de Nvidia. Surgieron muchas pequeñas empresas que crearon sus propios motores de conversión de voz a texto partiendo de cero o utilizando bases de código abierto. Ahora, 5 años después, muchas de ellas están ingresando al mercado de conversión de voz a texto con productos maduros y que ofrecen una alta precisión de reconocimiento.
  

¿Dónde encaja Voicegain aquí?

Nos consideramos uno de los nuevos jugadores, ya que empezamos a trabajar en nuestro propio motor de conversión de voz a texto basado en DNN a finales de 2016. Sin embargo, llevamos trabajando con sistemas ASR antiguos desde 2006, por lo que conocíamos muy bien sus limitaciones. Eso fue lo que nos motivó a desarrollar nuestros propios ASR.

También estamos muy familiarizados con el uso de ASR en aplicaciones de gran volumen del mundo real, por lo que sabemos qué funciones desean los usuarios de ASR, ya sean desarrolladores que crean las aplicaciones o personal de TI que tiene que alojarlas y mantenerlas.

Todo esto nos guió en las decisiones que tomamos al desarrollar nuestra plataforma de conversión de voz a texto.

Entonces, ¿en qué se diferencia el producto Voicegain?

A continuación, enumeramos lo que creemos que son 4 diferenciadores clave de nuestra plataforma de conversión de voz a texto en comparación con la competencia. Tenga en cuenta que el campo competitivo es bastante amplio, y consideramos que una característica en particular es un factor diferenciador si no es una característica común en el mercado.

1) Despliegue perimetral

Por implementación perimetral nos referimos a una implementación en las instalaciones del cliente (centro de datos) o en una VPC. Además, la implementación está totalmente orquestada y gestionada desde la nube (para obtener más información, consulte nuestra entrada de blog sobre Ventajas de la implementación perimetral). El aspecto de la orquestación y la administración integrada hace que sea esencialmente diferente de los antiguos ASR, que también se implementaban localmente y requerían contratos de soporte para implementarlos correctamente y mantenerlos a lo largo del tiempo.

Creemos que Edge Deployment es fundamental para una plataforma de conversión de voz a texto que sustituya a muchos de los antiguos ASR en sus aplicaciones.

2) Personalización del modelo acústico

A lo largo de los años, cuando trabajamos con ASR, nos dimos cuenta de que había casos en los que el ASR mostraba tasas de error consistentemente más altas. Por lo general, esto estaba relacionado con las llamadas IVR procedentes de clientes de regiones del país con distintos acentos.

En algunos de nuestros casos de uso hasta ahora, la capacidad de personalizar los modelos nos ha permitido reducir el WER de manera muy significativa (por ejemplo, del 8% al 3%).

Actualmente estamos trabajando en un riguroso experimento en el que estamos personalizando nuestro modelo para que sea compatible con el inglés irlandés. Planeamos informar detalladamente sobre los resultados en abril.

3) Soporte específico para IVR

La plataforma de conversión de voz a texto Voicegain se desarrolló específicamente teniendo en cuenta los casos de uso de IVR. Actualmente, la plataforma admite los siguientes 3 casos de uso del IVR, y estamos trabajando para añadir la NLU conversacional a finales de este año.

a) ASR compatible con los estándares IVR antiguos

Para que nuestro motor de conversión de voz a texto fuera una solución atractiva para reemplazar los ASR antiguos, lo implementamos para que fuera compatible con estándares antiguos como MRCP y GRXML. Este soporte no es un simple complemento, es decir, simplemente etiquetar una API web en la parte posterior de un servidor MRCP, sino que es más integral: nuestro motor principal de conversión de voz a texto interpreta directamente un superconjunto de comandos del protocolo MCRP.

También admitimos las gramáticas GRXML y JSGF, mediante MRCP, en las devoluciones de llamada de IVR y a través de la API web.

Cuando se usa con gramáticas, la gran ventaja del reconocedor Voicegain es que, en esencia, es un gran reconocedor de vocabulario. Las gramáticas se utilizan para restringir las expresiones reconocidas y facilitar el mapeo semántico, pero el reconocedor también puede reconocer las expresiones que no son gramaticales, lo que abre nuevas posibilidades para afinar el IVR.

b) Soporte de IVR Web-hook (sin VXML)

Los sistemas IVR basados en flujos se han creado tradicionalmente utilizando dos enfoques: (i) interpretar las interacciones de los diálogos en una plataforma VXML (navegador VXML) o (ii) utilizar webhooks que invocan la lógica de la aplicación que se ejecuta en plataformas de back-end web estándar (ejemplos de esto último son las ofertas de, por ejemplo, Twilio, Plivo o Tropo).

Nuestra plataforma admite IVR de estilo webhook. Las llamadas entrantes se pueden interconectar a través de la telefonía SIP/RTP estándar, y el cuadro de diálogo del IVR se puede dirigir desde cualquier plataforma que implemente webhooks (por ejemplo, Node.js o Django)

c) Habilitar los IVR que utilizan el back-end de un chatbot

Muchas empresas han invertido un esfuerzo significativo en crear sus chatbots basados en texto en lugar de utilizar productos como Google Dialogflow. Lo que ofrece la plataforma Voicegain es una forma sencilla de implementar la lógica de chatbot existente en un canal de telefonía vocal. Esto aprovecha la compatibilidad con el IVR webhook-ivr de nuestra plataforma y puede enviar texto en tiempo real (incluidas múltiples alternativas) a una plataforma de chatbot. También proporcionamos salida de audio a través de TTS o clips pregrabados.

4) Soporte integral para conversión continua de voz a texto en tiempo real

Como el IVR siempre ha sido nuestro objetivo, creamos nuestros modelos acústicos para que admitan la conversión de voz a texto en tiempo real de baja latencia (tanto con vocabulario extenso y continuo como con gramáticas sin contexto). También nos centramos en encontrar formas prácticas de transmitir audio a nuestra plataforma de conversión de voz a texto y de consumir la transcripción generada.

Uno de nuestros productos es Transcripción en vivo que permite la transcripción en tiempo real (con solo unos segundos de retraso), que luego se transmite a través de websockets y se puede consumir en los clientes web proporcionados. Esto abre la posibilidad de realizar transcripciones de ponentes en directo, con casos de uso que pueden incluir conferencias, ponencias, etc., lo que facilita la participación de los espectadores con problemas de audición en estos eventos.

En esta publicación, mostramos en tres pasos lo que se necesita para ejecutar su primera transcripción con la API Voicegain.

Suponemos que ya se inscribió para la cuenta Voicegain y has iniciado sesión en portal.

Paso 1: Crear un nuevo contexto

La razón principal para crear un nuevo contexto es establecer un nuevo dominio de autenticación. El acceso a cada contexto se puede controlar por separado, por lo que es fácil deshabilitar el acceso a un determinado contexto sin afectar a otros contextos.

Los contextos también se utilizan para especificar la configuración ASR predeterminada.

Puedes crear un nuevo contexto desde el panel de contexto

‍

Paso 2: Generar el token de autenticación

Las API de Voicegain utilizan JWT (JSON Web Tokens) para identificar y autenticar la cuenta que realiza la solicitud. Para realizar solicitudes a la API, debes generar un JWT, lo que se puede hacer fácilmente desde el portal.

‍

Paso 3: ejecuta el comando curl

A continuación se muestra la entrada y la salida completas del comando curl que envía una solicitud de API web a la API sincrónica de voz a texto de Voicegain https://api.voicegain.ai/v1/asr/transcribe

‍

‍

En este caso, el audio que se va a transcribir se recuperó de una URL. Como alternativa, el audio también se puede enviar en línea (previa solicitud).

Tenga en cuenta que la transcripción sincrónica tiene un límite de duración de audio de 60 segundos. Un audio más largo requiere el uso de la API de transcripción asincrónica.

Para solicitudes de transcripción asíncronas, es posible transmitir el audio, por ejemplo, a través de websocket. Puedes consultar parte de la documentación de la API de Voicegain en: https://www.voicegain.ai/api

‍

No se puede negar que los servicios disponibles en la nube tienen beneficios significativos y, por lo tanto, son una opción popular. Es por eso que la plataforma Voicegain Speech-to-Text está disponible tanto en la nube como en la periferia. Los principales beneficios de acceder a Voicegain como servicio en la nube son:

• Facilidad de uso - Todo lo que necesitas para empezar a acceder a Voicegain on the Cloud es crear una cuenta en la consola web de Voicegain y obtener las claves de API y los tokens de seguridad del desarrollador. Puedes empezar a acceder de inmediato a las API que están ampliamente documentadas.
• Sin mantenimiento - Voicegain garantiza la disponibilidad de la infraestructura y es responsable de las actualizaciones y parches del software, las copias de seguridad, los recursos, etc.
• Alta seguridad - Hacemos que el proveedor dedique una sola vez a proteger los servicios en la nube para todos los inquilinos. Si bien la nube está potencialmente más expuesta, el proveedor puede dedicar más recursos a abordar la seguridad de manera sistemática.
• Alta disponibilidad - La nube proporciona redundancia de la plataforma virtual y, a menudo, de la distribución geográfica. La distribución geográfica proporciona una mayor resiliencia ante las interrupciones en toda la red, etc.
• Escalabilidad - El proveedor de la nube se ocupa de la creciente demanda de recursos.
• Menores costos de administración de sistemas, DBA, etc. - Esto está relacionado en gran medida con el punto de no mantenimiento.
• ‍
  

¿Qué es Edge Deployment?

Antes de analizar los beneficios de Edge Deployment, definamos qué queremos decir con ello.

• Computación perimetral es definida en términos generales, como toda la computación fuera de la nube que se realiza en el borde de la red y, más específicamente, en aplicaciones en las que se requiere el procesamiento de datos en tiempo real. El borde de la red, a su vez, suele entenderse como aquella parte de la red que llega físicamente a las instalaciones del usuario final, en la «última milla».
• Lo que llamamos Implementación perimetral es una implementación de Edge Computing (en nuestro caso, específicamente los servicios de conversión de voz a texto) en las instalaciones del cliente (centro de datos) o en una VPC de un proveedor de nube. Los recursos informáticos son propiedad del cliente o los alquila. Sin embargo, la nube puede «organizar» la aplicación implementada y los servicios que proporciona se implementan y administran desde la nube. Estos servicios se ejecutan en un entorno virtualizado (en nuestro caso, Kubernetes).
  
  

Ventajas de la implementación perimetral

La computación perimetral para los servicios de conversión de voz a texto tiene muchas ventajas:

1. Latencias de red bajas y alta confiabilidad de red - Con Edge Computing, el procesamiento de la voz, el audio se acerca al lugar donde se origina el audio. Por ejemplo, todo el procesamiento se puede realizar en el mismo lugar donde terminan las líneas telefónicas de la compañía telefónica para una aplicación de IVR. Si el procesamiento de la voz se realizara en la nube, los datos de audio tendrían que enviarse a través de Internet, lo que introduciría latencia y fluctuación adicionales y haría que el servicio fuera susceptible a incidentes ocasionales en Internet, como troncos sobrecargados por ataques DDoS, cortes de fibra, etc. Se pueden evitar algunos de esos problemas implementando una conectividad de red más confiable a la nube, por ejemplo, Google Cloud Interconnect, pero eso tiene el costo y aún no resuelve la realidad básica de latencia adicional.
2. Menor costo de ancho de banda - Algunas aplicaciones de conversión de voz a texto generan una gran cantidad de datos, por ejemplo, la aplicación Call Analytics que procesa el 100% de las llamadas. La implementación perimetral permite colocar los recursos de procesamiento justo al lado de donde se generan los datos, por ejemplo, justo en el centro de llamadas.
3. Privacidad y control de datos - dado que todos los datos entrantes y generados se confían al entorno de Edge Computing y ninguno de ellos va a Voicegain Cloud, los clientes pueden aplicar sus propios protocolos de seguridad para proteger los datos.

¿Ofrece Edge algunos de los beneficios de la nube?

Puede que se pregunte: ¿qué pasa con los beneficios de la nube, mencionados anteriormente? ¿Puedo obtener algunos de estos con la implementación perimetral?

La respuesta es (con reservas) «sí», y específicamente:

• Facilidad de uso - Edge Deployment se gestiona completamente desde la nube. La implementación de toda la pila de aplicaciones requiere unos pocos clics del ratón.
• Sin mantenimiento - Voicegain se encarga de administrar los componentes de la aplicación: todos los componentes de la aplicación se actualizarán o parchearán automáticamente. El cliente aún debe cuidar el hardware y el clúster de Kubernetes.
• Alta seguridad - Se implementa la misma aplicación principal para todos nuestros clientes y nos hemos asegurado de que sea segura. En caso de que se descubra alguna vulnerabilidad nueva, se parcheará automáticamente. Los puntos de entrada y salida de la red desde el entorno Edge están bien definidos y los clientes pueden proporcionarles una seguridad de red adicional.
• Alta disponibilidad - Al ejecutarse en la plataforma Kubernetes, nuestra aplicación se ha diseñado teniendo en cuenta la alta disponibilidad. Hay varias instancias de cada servicio y Kubernetes se encarga de la conmutación por error en caso de que se produzca un error en un nodo de hardware. Gracias a la facilidad de implementación, nuestros clientes pueden implementar fácilmente varias instancias de Edge, por ejemplo, para lograr una distribución geográfica.
• Escalabilidad - Una vez más, gracias a la plataforma Kubernetes subyacente, se pueden añadir nuevos recursos de procesamiento añadiendo nuevos nodos de hardware al clúster de Kubernetes. La aplicación Voicegain los aprovechará automáticamente.

‍

Countryside Bible Church ha estado usando la plataforma VoiceGain para la transcripción en tiempo real desde septiembre de 2018 (cuando nuestra plataforma aún estaba en versión alfa).

Cómo empezó

En agosto de 2018, el personal de CBC se acercó a uno de nuestros empleados con una pregunta sobre un software que permitiría a una persona sorda seguir sermones en vivo mediante transcripción. Una de las miembros de CBC tiene problemas de audición y visión y no puede entender fácilmente el lenguaje de señas; sin embargo, puede leer fuentes grandes en la pantalla de un ordenador desde cerca.

En agosto, Voicegain acaba de iniciar las pruebas alfa de la plataforma, por lo que su respuesta fue que sí conocía ese software y que era Voicegain. En aquel momento, nuestras pruebas se centraban en los casos de uso del IVR, por lo que aún necesitábamos unas semanas para perfeccionar las API de transcripción y desarrollar una aplicación web que pudiera consumir el flujo de transcripciones (a través de websocket) y presentarlo como texto desplazable en un navegador.

Para mejorar el reconocimiento, utilizamos unas 200 horas de sermones previamente transcritos de CBC para adaptar nuestro modelo acústico de DNN. Además, creamos un modelo lingüístico específico del CBC, añadiendo un corpus de texto de varias traducciones de la Biblia, varios sermones transcritos, una lista de los nombres del personal del CBC, etc.

En lo que respecta al audio de entrada, inicialmente, estábamos transmitiendo audio utilizando un protocolo RTP estándar de la herramienta ffmpeg. Tuvimos algunos problemas con la fiabilidad del RTP sin procesar, así que más tarde cambiamos a un cliente Java personalizado que envía el audio mediante un protocolo propietario. El cliente se ejecuta como un daemon en un pequeño Dispositivo Raspberry Pi.

Estado actual

El equipo audiovisual de CBC lleva realizando transcripciones en tiempo real utilizando nuestra plataforma desde septiembre de 2018, prácticamente todos los domingos. Puedes ver un ejemplo de la transcripción en acción en el siguiente vídeo

‍

‍

Planes

Los planes actuales para el servicio de transcripción son integrarlo en el sitio web de CBC y ponerlo a disposición junto con la transmisión de vídeo. Esto permitirá a las personas con problemas de audición seguir los servicios en casa por streaming. Por ahora, el texto de la transcripción se presentará como un elemento de página web incrustado debajo del vídeo incorporado.

Como el vídeo transmitido tiene un retraso de más de 30 segundos en comparación con el tiempo real, enviaremos el audio simultáneamente a dos motores ASR, uno optimizado para la respuesta en tiempo real y otro optimizado para la precisión. Esto es fácil, porque la API web de Voicegain proporciona métodos que permiten conectar dos sesiones de ASR a una sola transmisión de audio. Cada sesión, a su vez, puede alimentar su propia transmisión de websocket. Al acceder a la transmisión de websocket adecuada, la interfaz de usuario web puede mostrar la transcripción en tiempo real o retrasada.

Ejemplo de sermones transcritos

Debido a sus condiciones de uso, no podemos proporcionar resultados directos para ninguno de los principales motores de ASR, pero puede descargar el audio vinculado a continuación, así como las transcripciones exactas correspondientes y realizar pruebas de comparación en el reconocedor de su elección. Ten en cuenta que Voicegain ASR ignora la mayoría de las palabras duplicadas que aparecen en el audio, por lo que en la transcripción se eliminan esos duplicados.

El audio es propiedad de Countryside Bible Church y las transcripciones son propiedad de Voicegain.

1. El plan de Dios para la historia humana (Parte 2)

Tom Pennington | Daniel 2 | 2018-11-04 P. M.

55 minutos, 13 segundos, 7475 palabras

Audio Transcripción Salida VoiceGain

Precisión: 1,08% tasa de error de caracteres

Nota: La salida de Voicegain está formateada para que coincida con la transcripción. Normalmente, también incluye información de temporización. Esta salida específica se obtuvo el 30 de abril de 2019 con un reconocedor en tiempo real, que tiene una precisión ligeramente inferior en comparación con el reconocedor fuera de línea.

Puedes transmitir audio para la API de transcripción de Voicegain desde cualquier computadora, pero a veces es útil tener un dispositivo económico dedicado solo para esta tarea. A continuación, compartimos las experiencias de uno de nuestros clientes al usar una Raspbery Pi para transmitir audio y transcribirlo en tiempo real. Reemplazó a un Mac Mini que se usó inicialmente para ese propósito. El uso del Pi tenía dos ventajas: a) obviamente el coste, y b) es menos probable que el Mac Mini sea «secuestrado» para otros fines.

Hardware

Voicegain Audio Streaming Daemon requiere muy pocos recursos informáticos, por lo que incluso en una Raspberry Pi Zero es suficiente; sin embargo, recomendamos usar Raspberry Pi 3 B+ principalmente porque tiene un puerto Ethernet cableado de 1 Gbps incorporado. Es más probable que las conexiones WiFi tengan problemas con la transmisión mediante el protocolo UDP.

Esta es una lista de todo el hardware utilizado en el proyecto (con los precios de Amazon (a partir de julio de 2019)):

• Placa base Element14 Raspberry Pi 3 B+ - 37,78$
• Pantalla Miuzei Raspberry Pi 3 b+, 3.5 pulgadas - 23,99 dólares
• Funda de pantalla Miuzei de 3.5 pulgadas para LCD de 3.5 pulgadas - $9.99
• Mini teclado portátil inalámbrico iPazzPort - 13,99$
• Adaptador de audio USB UGREEN - 8,99 dólares
• Tarjeta microSDHC UHS-I SanDisk Ultra de 32 GB - 7,23$
• además, se utilizó alguna fuente de alimentación USB de 5 V existente.

Todos los componentes sumaron un total de 101,97 dólares. La razón por la que se incluyeron un minimonitor y un miniteclado es porque facilitan el control del dispositivo mientras está en el soporte de audio. Por ejemplo, el mezclador de audio Alsa se puede ajustar fácilmente de esta manera y, al mismo tiempo, monitorear el nivel del audio con auriculares.

Raspberry PI con AudioDaemon

Software

El dispositivo funciona con Raspbian estándar, que se puede instalar fácilmente desde una imagen utilizando, por ejemplo, BalenaEtcher. Tras la instalación básica, se necesitó lo siguiente para que todo funcionara:

• habilitar el acceso ssh
• cambiar el dispositivo de audio predeterminado a una tarjeta de sonido USB (Raspbian viene por defecto con alsa y controladores de sonido USB básicos)
• instalar el controlador para la pantalla (de lo contrario, la fuente de salida es demasiado pequeña y no se puede leer)
• instalar OpenJDK 9
• utilice el enlace generado desde el portal Voicegain para descargar el archivo jar de Voicegain AudioDaemon y corregir la configuración de JSON
• establecer el número de fuente de audio correcto, el script de inicio de AudioDaemon y lanzar el daemon

Observaciones

Estas son algunas de las lecciones aprendidas al usar esta configuración durante los últimos 6 meses:

• Durante la transmisión, el uso de la CPU se mantiene por debajo del 10%
• El montón de Java está establecido en 128 millones, lo que parece ser más que suficiente porque los GC logran reducirlo a unos 54 millones
• La Raspberry Pi resultó ser muy fiable: no hemos tenido un solo problema con el hardware ni con el sistema operativo Raspbian
• La tarjeta de audio USB barata ofrece una calidad de sonido muy buena (al menos para el reconocimiento de voz)
• Deben evitarse las fuentes de alimentación USB muy baratas, ya que a veces provocan un zumbido en el audio (pero eso también depende del dispositivo de audio que se esté conectando).

‍

El equipo detrás de VoiceGain tiene más de 12 años de experiencia en el uso del reconocimiento automático de voz en el mundo real, desarrollando y alojando sistemas IVR completos para grandes empresas.

Empezamos como Resolvity, Inc., en 2005. Creamos nuestra propia plataforma IVR Dialog, utilizando inteligencia artificial para guiar el diálogo y mejorar los resultados de reconocimiento de los motores ASR comerciales.

Plataforma Resolvity Dialog

La plataforma Resolvity Dialog tenía algunos módulos avanzados de IA. Por ejemplo:

• Tenía una ontología que podía usarse para modelar Dialog Domain. Esta ontología podría usarse entonces para impulsar automáticamente el diálogo. Generaría automáticamente preguntas de seguimiento basadas en la información ya adquirida. Lo usábamos con frecuencia en aplicaciones de IVR que requerían el reconocimiento de los nombres de los productos.
• Tenía un motor de resolución de problemas de razonamiento incremental basado en casos (CBR) que, junto con Ontology, podía usarse para diagnosticar problemas técnicos en función de los síntomas presentados.
• Tenía un módulo para corregir los errores sistemáticos del motor ASR para mejorar la precisión (recibimos un Patente estadounidense para esto)
• Tenía un módulo NLCR que podía gestionar automáticamente «¿En qué puedo ayudarlo?» tipo de interacciones. Utilizó una combinación de clasificadores ontológicos, bayesianos y de redes neuronales.

IVR hospedado

A partir de 2007, desarrollamos aplicaciones IVR completas para el servicio de atención al cliente y las alojamos en nuestros servidores de centros de datos. Creamos un equipo de soluciones al cliente que interactuaba con nuestros clientes para garantizar que las aplicaciones de IVR estuvieran siempre actualizadas, y un equipo de operaciones que se aseguraba de ejecutar los IVR las 24 horas del día, los 7 días de la semana, con SLA muy altos.

Resolvity Dialog Platform tenía un conjunto de herramientas disponibles que nos permitían analizar la precisión del reconocimiento de voz con gran detalle y también nos permitían ajustar varios parámetros de ASR (umbrales, gramáticas).

Además, dado que esa plataforma era independiente de los motores ASR, pudimos ver cómo funcionaban varios motores ASR de varias marcas en la vida real.

PBX en la nube VoiceGain 1.0

En 2012-2013, Resolvity creó una plataforma completa de PBX en la nube de bajo costo sobre la base de proyectos de código abierto. La lanzamos para el mercado de la India con la marca VoiceGain. La plataforma proporcionaba una funcionalidad completa de PBX+IVR de extremo a extremo.

La versión que utilizamos en prod solo admitía DTMF, pero también teníamos una versión ASR funcional. Sin embargo, en ese momento se creó con tecnologías ASR convencionales (GMM+HMM) y descubrimos que entrenarla para que utilizara nuevos idiomas presentaba algunos desafíos.

VoiceGain crecía muy rápido. Teníamos presencia en centros de datos en Bangalore y Bombay. Pudimos proporcionar números fijos y móviles a nuestros clientes de PBX+IVR. Con el tiempo, aunque nuestra tecnología estaba funcionando bastante bien, nos resultó caro gestionar un negocio muy práctico en la India desde los EE. UU. y vendimos nuestras operaciones en la India.

Reconocimiento aumentado

Cuando la combinación de desarrollos de hardware e inteligencia artificial hizo posible las redes neuronales profundas, decidimos empezar a trabajar en nuestro propio reconocedor de voz DNN, inicialmente con el objetivo de aumentar los resultados de los motores ASR que utilizábamos en nuestros IVR. Rápidamente nos dimos cuenta de que con nuestro nuevo ASR personalizado, que utilizábamos para las tareas de IVR, podíamos obtener mejores resultados que con los ASR comerciales. Pudimos confirmarlo realizando pruebas comparativas entre conjuntos de datos que contenían miles de ejemplos. La clave para lograr una mayor precisión era la capacidad de personalizar los modelos acústicos del ASR según el dominio de IVR y la población de usuarios específicos.

Plataforma ASR propia

Los excelentes resultados con el reconocimiento aumentado nos llevaron a emprender un esfuerzo a gran escala para crear una plataforma ASR completa, nuevamente bajo la marca Voicegain (.ai), que permitiera una fácil personalización del modelo y fuera fácil de usar en aplicaciones de IVR.

Gracias a nuestra experiencia con el IVR, sabíamos que los usuarios de IVR de las grandes empresas (a) son muy sensibles al precio y (b) requieren un estricto cumplimiento de las normas de seguridad, por lo que desde el primer día también trabajamos para que la plataforma Voicegain se pueda implementar en Edge.