Настроенная система синтеза речи требует управления мощностями, на которых она расположена. Этим занимаются системные администраторы (DevOps), которые разворачивают виртуальное окружение и занимаются поддержкой его работоспособности.
У нас в Initlab большой опыт работы с облаками, есть опыт внедрения ИИ сервисов от Яндекса и мы постоянно учимся чему-то новому. Недавно наши DevOps прошли обучение в Яндексе по развертыванию их технологии для синтеза и распознавания речи (SpeechKit) в облаке Яндекс. В ходе обучения мы познакомились с возможностями SpeechKit и подготовили обзорную статью. Здесь мы сравним преимущества и недостатки развертывания этого и подобных сервисов в облаке и на своём железе.
Технологии синтеза и распознавания речи от Яндекса помогают бизнесу заменить колл-центр. Можно настроить и обучить речевую модель, по которой робот будет звонить людям по самым разным поводам: напоминать о записи на услугу, оповещать об акциях, проводить опросы о качестве сервиса и многое другое.
Эта статья будет полезна тем, кто планирует работать со SpeechKit. Мы кратко расскажем, как она может помочь бизнесу и как обеспечить её бесперебойную работу.
Яндекс.SpeechKit: что за технология и кому нужна
Яндекс.SpeechKit предназначена для распознавания и синтеза речи. Речевые технологии на базе машинного обучения помогают создавать голосовых помощников, автоматизировать колл-центры, контролировать качество сервиса и так далее. Если ваш бизнес хоть где-то завязан на звонках, вы сами можете представить возможность их автоматизации и применения конкретно под ваши задачи:
- обрабатывайте входящие звонки;
- актуализируйте клиентскую базу
- контролируйте качество услуг;
- снижайте затраты;
- оповещайте, приглашайте на мероприятия;
- проводите рекламные кампании и т.д.
Голосовой робот может послужить любому бизнесу, если есть запрос:
- сфера услуг, медицина и красота;
- колл-центры, банки, консультационные и информационные центры;
- магазины, e-commerce сервисы доставки;
- государственный сектор, образование и многие другие.
Голосового робота можно настроить по-разному: исходящие звонки с целью информирования, общение по скрипту, ответы на вопросы, запись разговора для дальнейшего анализа и многое другое.
Если вы решили использовать технологию Яндекс.SpeechKit для бизнеса, вам предстоит работать с инструментом Яндекс.SpeechKit Hybrid. Он позволяет технологии работать на собственной инфраструктуре либо на своём железе, либо на виртуальных машинах Яндекса в облаке.
Пример работы и разделение задач
Давайте представим, что вы локальный интернет-провайдер. У вас подключена IP-телефония и есть 10 сотрудников, которые обрабатывают типовые вопросы/запросы и заводят все данные в CRM-систему.
И вроде бы жить можно, но вот что можно оптимизировать с помощью SpeechKit:
- переводить в текст запись звонков для более быстрого анализа и оценки;
- создать сценарий для однотипных вопросов, сэкономив время сотрудников;
- настроить автоматические прозвоны с напоминанием о ежемесячном платеже или дате подключения к связи и т.д.
И это только первые мысли для не самого масштабного бизнеса, а представьте, сколько всего можно настроить для огромных компаний.
Чтобы всё это заработало, нужно настроить коммутацию между сервисами. Порядок подключения следующий:
- «поднимаем» окружение бота, который будет принимать звонки, в облаке;
- настраиваем связь с открытым программным сервером телефонии Asterisk, чтобы первым на звонок отвечал бот;
- обучаем этого бота.
Обучение бота и речевые настройки — это прерогатива разработчиков и специалистов по бизнесу. Условный аналитик представляет возникающие ситуации и пишет сценарии, которые разработчики переносят в бота через специальный интерфейс.
Задача инженера — сделать так, чтоб технология «поднялась», отвечала, корректно работала. Он настраивает сетевое взаимодействие между сервисами, распределение нагрузки, динамический автоскейлинг — повышение и понижение ресурса в зависимости от скачка нагрузок. То есть отвечает за окружение, а не работу сервиса как такового.
Отметим также, что сам Яндекс разрабатывает, обновляет, тренирует и обслуживает систему. В его ведении искусственный интеллект для веб-проектов и машинное обучение.
Админская часть работы делится на обязательную и зависящую от масштабов проекта и запроса клиента.
В обязательную входит базовое обслуживание проекта:
- обновлять и расширять;
- вносить изменения в инфраструктуру;
- подключать новые сервисы;
- обслуживать сопутствующую инфраструктуру.
Рецепт подготовки окружения, универсален и разворачиваемый шаблон уже работоспособен. Что касается второй части работы — какими техническими характеристиками обрастёт проект зависит от его характеристик. Насколько большой поток информации и обработки данных: 100 телефонистов — одни настройки, 1000 — совершенно другие. В любом случае, мы можем динамически корректировать эти параметры.
Динамическая инфраструктура и управление ресурсом
Выстраивание динамической инфраструктуры может не пригодиться малым компаниям, но для больших — must have. С помощью инструмента Terraform мы разворачиваем инфраструктуру как код в облаке: описываем в нём специальные манифесты, за счёт которых в одну команду разворачиваем полностью готовое окружение и уже можем управлять ресурсом — то есть получаем динамическую инфраструктуру.
Например: многим компаниям люди звонят неравномерно в течение дня. Условно
- с 14:00 до 17:00 — пик звонков. Под него нам нужно 100 ядер процессорного времени и 200 Гб оперативной памяти;
- с 18:00 до полуночи — минимум звонков. Выделяем в два раза меньше ресурсов.
Динамическое управление позволит нам платить меньше за счёт снижения ночного трафика.
Надежность системы позволяют поддерживать тесты на Python:
- функциональные тесты — цифры по нагрузкам, при помощи которых мы сможем управлять ресурсом;
- прикладные тесты — информация для «речевой инженерии»: как синтезируется речь из текста, всё ли хорошо с ударениями и дикцией, как речь распознаётся и переводится в текст и т.д.
Благодаря функциональным тестам мы ищем и устраняем узкие места, перенаправляем либо отсекаем потоки. То есть администратор примерно понимает, сколько обращений клиентов конкретный колл-центр может переварить, считает его усреднённый ежемесячный трафик и узнаёт, на какие мощности тот претендует. И если нам поступает больше звонков, чем мы можем обработать на входе, значит мы их отсекаем и начинаем продумывать решение на будущее.
Ресурс, которым управляют администраторы — процессорное время, оперативная память, вычислительная мощность, GPU-ускорители. Последние стоят дорого и чтобы зря не расходовать их мощность, есть такие понятия, как минимально необходимый уровень и максимально допустимый уровень. Оптимальное расходование вычислительных ресурсов также входит в задачи администраторов.
Каковы риски, если не заниматься такими настройками и не управлять ресурсом? Представьте, что мы дали рекламу и нам резко начали звонить большие потоки людей. Здесь есть проблемы технические и финансовые. Либо всё упадёт и до нас просто не будут доходить вызовы, либо начнётся перерасход бюджета в облаке.
Итог — люди не дозвонились, мы разорились.
В облаке можно поставить верхнюю границу доступного бюджета и выравниваться на длинной дистанции, даже с учётом скачков нагрузки. Теперь давайте поговорим о железе и облаках.
Деньги, гибкость и эффективность
SpeechKit Hybrid — это технологии Яндекс SpeechKit, работающие внутри вашей инфраструктуры. В основе SpeechKit Hybrid лежат контейнеры Docker, которые отлично подходят для обеспечения требований к безопасности и управлению данными. SpeechKit Hybrid основан на тех же моделях синтеза и распознавания речи, что и SpeechKit.
Эту технологию можно развернуть в разных окружениях: на своём железе или в Яндекс.Облаке. Администраторы Инитлаб настраивают инфраструктуру для развертывания решения, исходя из технических требований к отказоустойчивости и масштабируемости системы. Предпочтительным является построение системы в Kubernetes c управлением конфигурацией инфраструктуры, для этого мы используем Terraform. Таким образом, у нас появляется возможность динамического управления ресурсами и повышения отказоустойчивости системы. Развёртывание системы в Docker-контейнерах возможно, если использование Kubernetes избыточно.
Если у вас крупный бизнес и вы решили, что технология вам нужна, давайте рассмотрим выгоду от разворачивания на собственном железе и в облаке. Делать это мы будем через призму денег, гибкости и эффективности.
Деньги
Без лишних интриг скажем: мы топим за облако. Яндекс нам не доплачивал, просто это объективно более простое и выгодное решение. Дальше мы распишем, почему так считаем.
Мы не пишем конкретных цен в этом блоке по двум весомым причинам:
- Цифры быстро устаревают. Даже с учётом этого факта, нет никаких предпосылок к тому, чтобы оборудование, его комплектующие или аренда места в дата-центре подешевели. При этом зарплата одного DevOps-инженера вряд ли улетит в космос даже по прошествию времени.
- Мы не знаем, какие мощности вам нужны. Стоимость покупки своего оборудования зависит от конфигурации сервера и его мощности, из-за чего цены могут прилично варьироваться.
Давайте сравним:
| Своё железо | Облако |
| Найти, выбрать и приобрести оборудование с заделом на постоянный апгрейд | Оборудование уже есть, самое лучшее из возможного |
| Установка в дата-центре или на своей территории: ремонтировать, заменять комплектующие, диски, видеокарты и т.д. | Уже установлено и работает на оптимальных комплектующих |
| Обслуживать: обеспечить сетевой доступ, помещение, нужный климат — охлаждение, кондиционирование | Стоимость обслуживания входит в пакет и происходит в идеальных условиях |
| Системные администраторы с высокой ЗП и желательно поддержкой 24/7. Минимум 2, а то и 3, потому что рабочих часов 8 — сутками никто не трудится | Один DevOps-инженер |
| Резервный источник с репликацией системы на случай сбоя (а это ещё один физический сервер) или система хранения данных (СХД) | Уже входит в пакет |
Если сесть и подбить цифры, на входе может показаться, что 4-5 месяцев аренды перекроют покупку оборудования, и оно же своё. Но нужно помнить, что через это время оно начнёт деградировать, его нужно будет чинить или обновлять.
При работе с облаком расходы идут на его аренду и на всего одного DevOps-инженера. Да, он получает большую зарплату, но явно меньшую, чем три сисадмина.
Если говорить о последнем пункте, в нём вскрываются ещё одни убытки. При резервировании системы мы должны понимать, сколько сервер будет простаивать в случае выхода из строя железа, в процессе установки нового и копирования этого бэкапа обратно. Это могут быть условно сутки простоя, которые измеряются в деньгах отдельно взятого бизнеса или проекта.
Как видите, выгоды определённо очевидны. Ежемесячные сопутствующие расходы по железу могут превысить стоимость оборудования. Помимо всего прочего, должны иметься резервные источники питания, человек, который будет их обслуживать, у него, в свою очередь, должны быть основной и резервный каналы интернет-доступа, чтобы не терять ваши деньги, если что-то отключится.
Гибкость и эффективность
Эти параметры также косвенно про деньги, но уже про сэкономленные в процессе взаимодействия с системой.
| Своё железо | Облако |
| Низкая скорость внедрения. Собрать, установить, настроить, протестировать — и это только в начале | Быстрый старт. Оплатил, запустил, настроил — работаешь |
| Эксплуатационные издержки. Затраты на содержание оборудования и необходимость штатных специалистов эксплуатации для поддержания работы 24/7 | Простое взаимодействие. Готовое решение, которое не нужно изобретать |
| Низкий уровень масштабируемости: наращивать нагрузку можно только в рамках характеристик оборудования | Высокая и простая масштабируемость: достаточно настроить характеристики под себя и оплатить более высокий тариф |
| Низкая надёжность. Своё железо сложнее обезопасить | Надёжно защищено. Соответствует всем законодательным нормам и обеспечивает максимальный уровень безопасности |
| Нестабильные скорость и качество работы. Зависит от множества факторов и включает в себя всё вышеперечисленное. Проблема на любом уровне может повлечь сбой или замедление работы | Стабильные скорость и качество работы. Конечно, и здесь не без сбоев. Но количество причин заметно сокращается и на их поиск уйдёт намного меньше времени |
Представьте, что уверенно средний бизнес заморочился и приобрёл своё оборудование, начал активно расти и теперь ему нужно больше, мощнее и стабильнее. Своё оборудование никогда не дотянется до такой махины, как уже устроил Яндекс, сколько не улучшай. Прокачивать Жигули в надежде, что они будут лучше BMW затея так себе. По всем параметрам — безопасности, масштабируемости, скорости и прочим облако держит уверенную победу.
Резюмируем
Если вы решите работать с технологией Яндекс.SpeechKit, вам понадобится:
- выбрать тариф в облаке (преимущества очевидны);
- нанять или обучить уже имеющихся разработчиков работать с панелью Яндекс.SpeechKit для речевой инженерии;
- нанять DevOps-инженера, который развернёт технологию в нужном окружении и будет управлять её нагрузкой;
- развивать свой бизнес, применяя достижения современности на благо своего дела.
В последнем крайне важно помнить о развитии динамической инфраструктуры, важность которой мы постарались донести в этой статье. Если ещё раз и просто: под скачки нагрузки нужен специалист, который проанализирует и установит нужные настройки. Так ваш колл-центр не упадёт и будет максимально стабильным, насколько это возможно.
Такой специалист закрывает две задачи: разёртывание и эксплуатацию. Развёртывание включает в себя «архитектурные работы»: выстроить, настроить, наладить, запустить. Эксплуатация включает решение текущих вопросов, устранение аварий, рассмотрение инцидентов. Этап внедрения может оказаться дороже, чем дальнейшая поддержка: после развёртывания и настройки системы, инженер работает на почасовке, но только в случае необходимости. На решение текущих задач может уходить всего 2-3 часа, при этом сам специалист на дежурстве полный день. То есть в случае поломки он начнёт всё исправлять.
У Initlab есть все необходимые компетенции и сертификаты для работы с данным окружением. За развертыванием и поддержкой такой инфраструктуры можно обратиться к нам.
Добавить комментарий