Hervidor de agua y asistentes de voz. El comienzo de una gran amistad.



¿Qué tenemos en un momento dado en el mundo de GA ? Hecho conocido: cada una de las grandes empresas de TI tiene su propia herramienta para trabajar con hogares inteligentes. Y cada proveedor proporciona su propia API para aquellos interesados ​​en la integración. Y en la etapa inicial, incluso paga a los desarrolladores por nuevas habilidades (acciones, habilidades, etc., de acuerdo con la terminología del proveedor).

El servicio más conveniente y práctico hasta la fecha, según nuestros expertos, es Amazon Alexa. Ella tiene más oportunidades para la formación de habilidades detalladas que el Asistente de Google, Yandex "Alice", Mail.Ru "Maroussia", Tinkoff "Oleg" y otros. Para Alexa, un dispositivo es una entidad virtual paramétrica, como resultado de lo cual las habilidades se pueden personalizar para cada dispositivo individualmente. Por ejemplo, además de la temperatura del agua, puede especificar los consumibles que el asistente ofrecerá para comprar en Amazon. Pero, desafortunadamente, Alexa actualmente no es compatible con el idioma ruso y no funciona en el territorio de la Federación Rusa, por lo que esta GA es inútil para un usuario ruso. En Google y Yandex, el asistente es más "natural": recibe y responde comandos en el lenguaje "humano", puede mantener un diálogo con el usuario, lo que hace que este GA sea más agradable de usar. El único inconveniente serio de Google fue que sus acciones no eran compatibles con el idioma ruso. Sin embargo, desde el 24 de julio de 2019, Google Actions ha estado trabajando en "teléfonos" en ruso, por lo que sus colegas han eliminado este inconveniente.

Esto esta bien. ¿Y si queremos integrar un dispositivo con varios GA?

Es posible Usando el dispositivo.

Un dispositivo es una entidad con su comportamiento en el sistema. Este es un principio común para todos los vendedores. Y aquí vale la pena detenerse, aquí comienza toda la diversión. Las diferencias están en los enfoques. Por ejemplo, Google y Yandex están tratando de estandarizar la gestión de la tecnología. Es decir, ahora es necesario escribir código no para cada dispositivo individual, pero un programa para toda la serie es suficiente. E incluso si el firmware cambia, tendrá que cambiar el código una vez, lo cual es muy conveniente. Nuestra empresa ya tiene integración con Google, Yandex, Amazon. Technique escucha a Alice , Alex y el asistente de Google. Anteriormente mostramos eso dentro de asistentes de voz .

¿De dónde vinieron los asistentes de voz?


Uno de los sistemas de reconocimiento de voz más avanzados del mundo pertenece a Google, su historia comenzó en 2002. La compañía lanzó Voice Search, sobre la base de la cual se desarrolló el Asistente de Google. En 2016, fue presentado en la presentación de Google I / O. Google Home es una de las 'superficies' para el Asistente de Google. Ahora la precisión del reconocimiento de voz de su AG se estima en un 95% y casi inferior a la de las personas.

El asistente de voz de Alexa fue presentado por Amazon en 2014. La columna inteligente Amazon Echo, que puede controlar una gran cantidad de dispositivos dentro de una casa inteligente, también se presentó allí.

Yandex SpeechKit: sistema de reconocimiento de voz Yandex. Se utiliza en más de 400 aplicaciones. La compañía también integra su GA, Alice, en navegadores y dispositivos electrónicos. La compañía rusa presentó su GA en 2017, y ya en el otoño de 2018, Yandex lanzó su columna inteligente Yandex.Station.

Nuestros expertos dicen que para el año ciento cincuenta y seis ...


Estamos bromeando, hasta ahora solo para 2020. Un poco sobre estadísticas:

  1. En 2017, se registraron aproximadamente 33 millones de dispositivos controlados por voz en todo el mundo;
  2. Los expertos occidentales llamaron a la búsqueda por voz una de las 3 principales tendencias de SEO en 2017 ;
  3. Para 2018, Google Assistant funciona en 400 millones de dispositivos en todo el mundo. Y esta cifra solo está creciendo;
  4. Según el Global Web Index , el 25% de las personas de entre 16 y 24 años usan la búsqueda por voz desde dispositivos móviles;
  5. Según las previsiones de Comscore , para 2020, el 50% de las solicitudes se realizarán por voz;
  6. Según una investigación realizada por WalkerSands en 2018 , cada quinto usuario de un altavoz inteligente de Amazon lo compró y un tercero planeaba hacerlo el próximo año;
  7. Según un estudio de PWC , el 71% de los usuarios que buscan en la web preferirían escribir voces en lugar de hacerlo manualmente.

Como puede comprender, la tendencia a usar GA está aumentando, lo que sugiere que es hora de tomar un proveedor y lanzar su propio asistente. Para nosotros, la clave es la capacidad de controlar dispositivos inteligentes, lo que distinguirá a SkyFriend de otros asistentes.

¡Y integremos!


PERO también nuestra tarea es trabajar con el enfoque de proveedor existente y adaptarlo aún más a nuestro protocolo de control de tecnología específico. Seguimos el camino de la estandarización, la aplicación práctica, percibiendo el dispositivo como un conjunto de habilidades: cada caldera sabe cómo hervir agua (habilidad), también sabe cómo calentarla a la temperatura deseada (habilidad), mantener esta temperatura durante un tiempo determinado, etc. Por ejemplo, El comando "Encendido / Apagado" es estándar para cualquier dispositivo. La tarea es transferir este comando del servicio a nuestro protocolo. ¿Cuál es la peculiaridad de nuestro protocolo? Conecta diferentes asistentes de voz (ahora tres, en el futuro, todos grandes) y les permite a todos trabajar con dispositivos, incluso al mismo tiempo. La comunicación es de uno a muchos. La única pregunta es ¿cómo exactamente adaptaremos nuestro protocolo a todos los enfoques?

A ver Los proyectos separados para cada GA son:

  • Mayor personal
  • Mucho código y legado en el futuro;
  • Incapacidad para escalar.

Cuando aparezcan nuevos asistentes en el mercado, será necesario aumentar proporcionalmente el personal y el volumen de trabajo. Es lógico que rechacemos esta opción. Sin embargo, a pesar de los diferentes enfoques para cada asistente de voz, pueden encontrar algo en común: lo que básicamente trabajan es habilidad, rasgo, habilidad. Los nombres son diferentes, pero la esencia es la misma. Entonces, la tarea es desarrollar su "habilidad", que será percibida por los asistentes. En el futuro, solo necesitará agregar nuevos proveedores, lo que resuelve el problema del escalado. También tendremos en cuenta que una cantidad significativa de nuestro equipo utiliza vehículos BLE, que dicta características arquitectónicas.

Hemos desarrollado dos microservicios que funcionan en parejas.



El primero es la capa de comando. Su tarea: llevar a cabo la conversión (mapeo) entre la API del proveedor y nuestro protocolo. Funciona así: una solicitud específica para un asistente es el mapeo de nuestra habilidad - mapeo para un protocolo de dispositivo. Con este enfoque, es fácil agregar nuevas habilidades: el mapeo se realiza para el protocolo R4S final: el código se transfiere al segundo servicio. El último elemento puede excluirse al transmitir un comando a través de Wi-Fi.

El segundo servicio o capa de transporte se utiliza para:

  1. Establecer una sesión con una puerta de enlace del cliente;
  2. Levantar y mantener una conexión Bluetooth;
  3. Recepción / transmisión de comandos desde el primer servicio.

Este servicio forma parte de una entidad de nivel superior: dispositivo BT más intermediario de puerta de enlace, que funciona según el principio: recibir comandos a través de Internet y enviarlos a través de BT. Las conexiones inalámbricas pueden no ser confiables. Por qué El canal de radio puede estar limitado por parámetros ambientales: gruesos muros de hormigón, etc. Como resultado, los dispositivos pueden "caerse" de manera elemental, por lo tanto, mantener una conexión estable se convierte en una tarea importante para la capa de transporte.



La política de conexión puede ser diferente:

1. Soporte continuo de comunicación.

Pros : retraso mínimo en la ejecución de comandos GA.
Contras : caro para el tráfico y el consumo de energía; existe un límite en la cantidad de dispositivos conectados simultáneamente (en esta generación Bluetooth 4.0 / 4.2 - seis, en Bluetooth 5.0 hasta veinte). También requerirá recursos adicionales del servidor.

2. Conexión bajo demanda.

Pros : la conexión casi no requiere tráfico y carga.
Contras : no se garantiza un alto retraso en la ejecución de los comandos más la ejecución en sí (la conexión puede "caerse" o no tener éxito). Con este enfoque, no encajamos mientras esperamos que la AG responda. La sesión terminó y el final.

La pregunta también permanece: el comando se recibió y resolvió, PERO qué hacer con la conexión: desconectarse o continuar. Tenga en cuenta que exactamente de la misma manera que Apple HomeKit funciona cuando se trabaja con dispositivos terminales BLE (a través de Apple TV o iPad como puerta de enlace). Se ve así: la primera vez que intenta enviar un comando, el proceso lleva bastante tiempo (o mejor, notable para el usuario), pero los comandos posteriores se ejecutan casi instantáneamente. Una vez completado el trabajo del usuario con el dispositivo, el sistema operativo "configura" la sesión después de un tiempo razonable y luego el proceso se repite como nuevo.

Sin embargo, eso no es todo.


Dificultad 1 . Enrutamiento de puerta de enlace.



Si hay varias puertas de enlace en la sala, surge la pregunta: a cuál conectarse y a qué puerta de enlace está conectado el dispositivo. Ahora todo funciona según el principio: el que tenga éxito está conectado. La implementación no siempre es exitosa, ya que la puerta de enlace más cercana (y por lo tanto capaz de conectarse de manera más confiable) puede estar ocupada en el intervalo de tiempo utilizado. Entonces el que es libre y capaz está conectado. Esto sucede sin tener en cuenta la calidad de la comunicación. Por lo tanto, es importante construir una jerarquía y un esquema de trabajo para que el usuario se sienta lo más cómodo posible.

Dificultad 2 . Muchos usuarios

Esta es una situación en la que varios usuarios pueden usar una puerta de enlace o dispositivo al mismo tiempo. Por supuesto con un alto nivel de seguridad. Por ejemplo, de diferentes GA o de GA y teléfonos de usuario. Un enjambre de preguntas: qué dispositivo encender primero, si los comandos de GA se contradicen entre sí, qué comando es una prioridad y debe ejecutarse antes, etc. El servicio de Redis resuelve parcialmente nuestro problema, una base de datos en la que se almacenan las sesiones de usuario, los estados del dispositivo y el transceptor comandos y servicio de bus de datos entre el primer y el segundo servicio. Pero aquí es donde se detiene la solución al problema.

Que hemos hecho Hicimos SkyFriend. Este es nuestro propio desarrollo, un asistente de voz para la gestión de la tecnología, que también admitirá el idioma ruso. Una característica clave de nuestra GA es que está afilada para una interacción directa con la tecnología Smart Ready for Sky sin instrumentos adicionales. El dispositivo es dos en uno: el asistente se combina con la puerta de enlace, que recibirá información a través de los comandos que el usuario envía desde su teléfono inteligente o directamente por voz. Además, SkyFriend tiene características adicionales que le permitirán competir con las que ya existen. Puede activar recordatorios a pedido, puede determinar la geolocalización del usuario, buscar información en Wikipedia, recomendar películas, hacer brindis, leer noticias, responder preguntas, decir la hora y el clima en cualquier ciudad del mundo, jugar Misterios y ciudades con el usuario haciendo bromas Comprar boletos y pedir un taxi aún se encuentra en la etapa de prueba alfa. Y esto es solo una parte de la funcionalidad.

Más recientemente, Google anunció el trabajo de su columna en una arquitectura similar: el script de ejecución se carga directamente en la columna Google Home. Ganar del lado del usuario es reducir el tiempo que lleva ejecutar comandos. No necesita enviarlo al servidor del fabricante del equipo; vuela directamente a la columna desde el servidor de Google a través del mismo canal de comunicación y se ejecuta allí.

Sin embargo, Google todavía no admite otros transportes: Bluetooth, ZigBe, Z-Wave, RF, etc. directamente en la columna, y SkyFriend es compatible con Bluetooth 5.0.

¿Qué más nos queda? Trabaje con recursos del sistema: agregue memoria, potencia del procesador, etc. Y estamos listos para ofrecer a los usuarios una nueva calidad de GA.

¿Qué podemos decir en conclusión?


GA es una tendencia, es conveniente, es práctica. El tema es nuevo, exhaustivo, tiene muchas preguntas que aún son difíciles de resolver. Especialmente solo. Por lo tanto, te invitamos a una discusión.

¿Qué pasará después? Y luego estará nuestro nuevo artículo sobre la arquitectura SkyFriend. Le diremos y mostraremos todo. Pero entonces

PD Sugerencias y comentarios se pueden dejar en los comentarios.

Source: https://habr.com/ru/post/461363/


All Articles