Готовим c serverless. Голосовой сервис записи к врачу и регистрации в поликлинике
Какой serverless-стек нужен, из чего состоит сценарий и как может быть устроена система CRM на стороне Yandex.Cloud. Коммуникационная платформа Voximplant и Yandex.Cloud подготовили рецепт голосового сервиса регистрации и записи на прием к врачу в поликлинику. Впрочем, им можно воспользоваться и для других похожих serverless-задач.
Как устроен визуальный конструктор Voximplant Kit
Интеграция с коммуникационной платформой — один из основных сценариев использования serverless наряду c сервисами геолокации, бэкендами для IoT-приложений, микросервиами и чат-ботами. Что включает в себя платформа, на базе которой можно создать голосовой serverless-сервис?
Конструктор. На платформе Voximplant разработан Voximplant Kit — простой визуальный конструктор, который позволяет запрограммировать входящие и исходящие сценарии. Это омниканальный колл-центр в браузере, где процессы приема и отправки звонков управляются drag & drop.
В Voximplant Kit интегрирован Yandex SpeechKit, поэтому в любом месте можно вызывать ASR и TTS Яндекса, как, впрочем, и других поставщиков синтеза и распознавания речи. В одном сценарии можно использовать несколько разных.
Среди плюсов использования технологий Яндекса для синтеза — наличие нейронных, но очень натуралистичных голосов Алены и Филиппа.
VKit поддерживает нативную разметку Яндекса и его XML-теги. Это значит, что можно написать текст на Yandex SpeechKit, послушать, как он звучит, скопировать его вместе со знаками препинания в Voximplant Kit — и он будет звучать точно так же. Плюс такого drag & drop-решения очевиден: вы просто открываете нужный блок и вставляете текст в нужное место. Вам не надо писать код, который вызовет его проигрывание.
Сервис автоматизации звонков работает через API Serverless. В ходе разговора голосовой (или кнопочный) ответ человека превращается в данные, понятные БД. Далее принимается ответ из базы, и чтобы его озвучить, сырые данные превращаются в текст, который воспроизводится синтезом речи.
Получаем и валидируем ответ голосом и (или) кнопками → Заполняем значение переменной в зависимости от ответа → Отправляем по API значение в формате базы данных.
Разбираем сценарий входящего звонка
Желтые блоки — взаимодействие с API Serverless Человек звонит, чтобы записаться на прием к одному или нескольким специалистам. Списки врачей, специализаций и даты приема получаются при помощи API-запросов к API Gateway.
Сначала определенные блоки используются для получения данных из базы, а в конце — чтобы положить в базу запись человека на прием.
Какие блоки используются в сценарии и за что они отвечают.
Блоки звонка. Поступивший звонок проходит через блок записи звонка. При этом формируется аудиозапись в MP3. Она будет храниться в облаке от трех месяцев до двух лет.
Блоки интерактивного меню. В этих блоках указывается текст, который будет синтезирован и озвучен человеку, вендор или язык синтеза и голос, которым робот будет говорить с человеком. При этом в тексте можно использовать переменные, благодаря которым робот может обратиться к человеку по имени.
Ответ человека собирается голосом и кнопками. В настройках при этом указывается язык распознавания и те слова или словосочетания, которые система будет искать в ответе пользователя.
Блок HTTP-запроса. После получения ответа от человека запрос отправляется по API в Yandex Database Serverless (YDBS). Для этого используется блок HTTP-запроса, где указываются все данные запроса. При этом можно сразу соотнести данные из ответа с переменными из сценария. И даже добавить аудиофайл. Если выполнение запроса занимает время, пользователь может слушать не тишину, а, например, звук набора текста на клавиатуре.
Блоки текста в голос. В некоторых местах для синтеза речи используется блоки конвертации текста в голос. Они нужны там, где не предполагаются какие-то ответы от человека.
Блоки изменения данных. Для перевода человеческого ответа на язык HTTP-запроса и подстановки нужного значения в параметры или URL используются блоки изменения данных. В них подставляются значения в переменную, которая позже используется в блоке HTTP-запроса.
На стороне YDBS слоты врачей хранятся в виде временных отпечатков — таймстампов.
Это удобный формат для хранения данных, но синтезу речи сложно читать его правильно. Чтобы избежать ошибок, используется вспомогательный преобразователь DateConvert, который разделяет таймстамп на время и дату. Так синтез точно считывает их корректно.
Как устроена CRM-система на стороне Yandex за API, с которым взаимодействует конструктор
Заглянем под капот — рассмотрим ключевые моменты и возможности настройки системы обработки входящих вызовов и регистрации пользователей. Как управлять данными в YDBS, зачем создавать сервисный аккаунт и облачную функцию и для чего скрывать детали имплементации при помощи API-шлюза.
Yandex Database Serverless
Создаем облако и каталог, в котором будут размещаться все ресурсы для приложения.
Создаем облако и каталог, в котором будут размещаться все ресурсы для приложения.
Создаем YDBS и выбираем режим serverless — в этом режиме база данных автоматически расширяет ресурсы, необходимые для вашей нагрузки.
Заходим в навигацию БД. Наполняем базу данными.
В нашем случае это справочники врачей, поликлиник, специализаций докторов и их расписания.
Некоторые подробности работы с данными на конкретных примерах
Doctors.sql. В облаке базу можно наполнить, скопировав исходный код из вашего репозитория во встроенный в консоль облачный редактор, и выполнить запрос из файла. В этом случае — doctors.sql
YDBS поддерживает конструкции DDL и DML. После выполнения запроса создается таблица докторов в корневой директории.
Schedules.sql. Все таблицы YDBS содержат первичный ключ, и данные в таблице отсортированы по первичному ключу. В табличке расписания используется и вторичный ключ. Вторичные индексы в YDBS можно использовать для существующих таблиц, и это построение не приводит к деградации нагрузки на таблицу с данными.
Тут же используются именованные переменные — специальные конструкции, похожие на макросы, для упрощения используемого синтаксиса. Сахар делает итоговые конструкции лаконичнее.
Authorized_users.sql. Чтобы Voximplant Kit мог обращаться к API Gateway и это обращение было авторизованным, можно воспользоваться Яндекс ID или настроить авторизацию другими средствами.
В корневой директории YBDS доступна метаинформация о таблицах: дата создания изменения, информация о собираемой по таблице статистике — количество строк, размеры и все настройки, выставленные для таблицы. В разделе «Схема» можно увидеть, какие столбцы являются частью первичного ключа, а в разделе «Индексы» — созданные индексы для этой таблицы.
В консоль также выведена возможность изменять структуры таблиц: добавлять или удалять неключевые колонки, изменять настройки таблицы. Например, автоматически партицировать шарды при росте размера и (или) нагрузки и сливать их при уменьшении размера или падении нагрузки.
Еще один из бонусов интерфейса — возможность добавлять вторичные индексы. И эта нагрузка никак не аффектит вашу онлайн-нагрузку. При добавлении индекса важно учитывать порядок столбцов.
Это далеко не все возможности консоли YDBS. Читайте подробную документацию.
Сервисный аккаунт и облачная функция
Сервисный аккаунт нужен, чтобы от его имени компоненты могли производить авторизованные действия с объектами. Такому аккаунту назначаются роли — примитивные (например, editor, который позволяет работать с объектами за исключением выделения им грантов) или сервисные (например, server function envoker и ydb.admin, которые позволяют СА вызывать функции в cloud functions и производить различные операции с базой данных).
После создания аккаунта можно переходить к созданию функции, которая будет осуществлять всю работу: принимать вызовы от Voximplant Kit и работать с данными в YDBS.
Важно учитывать, что создание функции — это только создание обертки, которая хранит информацию о метаданных и получает ссылку для вызова. Чтобы функция начала содержать исходный код, нужно загрузить версию функции. Это можно делать через консоль или CLI. Процесс загрузки версии функции подробно описан тут.
На этом почти весь процесс завершен — функция загружена, и теперь можно производить вызовы из Voximplant Kit в функцию. Но часто хочется скрыть детали имплементации от внешнего сервиса.
API Gateway: скрываем детали имплементации
Со временем могут меняться требования к коду или детали бизнес-логики. При этом контакт с внешней системой нарушать не хочется. Для этого создается API-шлюз, который за собой скроет все детали имплементации. Это тоже можно сделать через CLI или облачную консоль.
Для создания API Gateway понадобится создать спецификацию в формате Open API 3.0. Пример спецификации можно посмотреть тут.
В ней, в свою очередь, описываются все спецификации, которые конфигурируются в визуальном конструкторе Voximplant Kit и вызывают метод обработчика облачной функции.
Важно указать в спецификации идентификатор сервисного аккаунта, для которого уже выдано разрешение на вызов cloud function. Таким образом, от имени этого сервисного аккаунта API-шлюз будет с ней взаимодействовать.
Расширение API Gateway позволяет работать не только с вызовами cloud functions, но и с различными бэкендами: Object Storage и статическими вызовами.
Сводная по приготовлению в качестве заключения
Все готово! Использование serverless, готового голосового робота и визуального конструктора экономит кучу времени и ресурсов, и это просто удобно. Чтобы закрепить полученные знания, запишем рецепт нашего голосового сервиса.
Для реализации системы нужны следующие ингредиенты:
А для приготовления мы использовали:
P.S.
Попробуйте сделать свое serverless-приложение, протестировать работу с YDB и другие инструменты стека serverless в Yandex.Cloudе если у вас возникнут вопросы задавайте их у нас в Telegram: Yandex Serverless Ecosystem
