Дилемма СТО: внедрять инновационные технологии или использовать проверенный стек

Часто ИТ-команды используют проверенные технологии для новых проектов. Есть подходящая команда, опыт и не нужно тратить ресурсы и время на исследования, проверку гипотез и переобучение людей. В большинстве случаев это помогает создать надежный и качественный продукт в срок, но когда нужно создать абсолютно новое для рынка решение, этот подход не работает.

На конференции МТС Платформа 2024 Инесса Галактионова, первый вице-президент МТС по телекоммуникационному бизнесу, рассказала о подготовке компанией виртуального ассистента, который станет полноценным участником телефонных звонков. Чем он будет отличаться от существующих голосовых ассистентов и почему его невозможно было сделать по принципу «как все», расскажу вам я, CTO стрима «Виртуальный ассистент» компании МТС, Иван Мясников.

Иван Мясников

CTO стрима «Виртуальный ассистент» компании МТС

Новые подходы нужны для уникальных продуктов

Наш ассистент рассчитан не только на стандартные для ИИ задачи. Да, он подскажет прогноз погоды или прочитает сказку, но основная его фишка не в этом. Мы первые решили внедрить ИИ-ассистента прямо в звонок: он будет реагировать на голосовую команду, записывать звонок, если это нужно абоненту, выделять из него главное и отправлять в SMS. Или даже собирать информацию по теме, пока вы говорите по телефону.

ASR — преобразование речевого сигнала в текстовое представление. Интент — намерение пользователя, которое отражается в поисковом запросе. Skill Classifier — сервис, который производит предварительную классификацию навыков. TTS — синтетическая озвучка заданного текста.

Как это работает: допустим, вы с друзьями планируете совместное путешествие. Вы созвонились обсудить поездку, позвали ассистента во время звонка. Он по команде запишет нужную часть разговора, чтобы никто не забыл о планах, узнает погоду, найдет доступные рейсы и отели в пункте назначения, соберет достопримечательности, которые можно посетить, и так далее. Все за счет распознавания речи и интеграции с другими сервисами экосистемы МТС.

При этом ассистент не будет влиять на качество связи. В звонок мы встраиваем только маленькую и легкую модельку, которая определяет, вызвал ли абонент голосового ассистента. Если имя ассистента названо, запускается распознавание голоса и общение на естественном языке, но оно происходит асинхронно, поэтому не влияет на качество связи.

Чтобы сделать такой продукт, аудиопоток должен передаваться быстрее, а речь — считываться и записыватьсякачественнее, чем у конкурентов. У любого такого продукта на старте мало данных для обучения моделей, а синтетически генерировать их дорого и неэффективно. Поэтому приходится «срезать углы», выбирая нестандартные решения, чтобы выиграть время и опередить конкурентов. Поэтому мы приняли несколько нестандартных решений.

Во-первых, отошли от обычной для нас работы через веб-сокет и выбрали gRPC-протокол. Исследование, проведенное нашей командой, показало, что gRPC позволяет выиграть в скорости получения голосового запроса и скорости доставки ответа абоненту. При нагрузочном тестировании мы обнаружили, что такой подход дает нам выигрыш по скорости в два-три раза. Пользователь получает ответ быстрее, а оборудование загружается меньше. Преимущество появилось за счет того, что веб-сокет передает данные в текстовом формате, а gPRC — в бинарном. Вместе с HTTP/2 протокол gPRC позволяет включать мультиплексирование, сжимать передаваемые данные и при необходимости приоритизировать запросы.

Во-вторых, для бэкенда мы выбрали язык Kotlin вместо применяемого обычно Java. У этого решения нашлось несколько важных преимуществ. Из главных — меньший объем кода и лучшая читаемость за счет корутин и более лаконичного синтаксиса. Концепция Null Safety в Kotlin помогает избежать ошибок неопределенности — одних из самых частых и очень трудно выявляемых в Java. В результате оказалось, что применение Kotlin повышает надежность и масштабируемость системы по сравнению с Java при сравнимых трудозатратах.

Бонусом мы получили неожиданный источник кандидатов. Если у вас уже набрано ядро команды, то можно хантить джавистов и быстро их переучивать. Оказалось, что многие разработчики на Java осознают вышеперечисленные преимущества и рассматривают переход на Kotlin как ступеньку в карьере или возможность найти для себя новые вызовы и задачи.

Дело не только в стеке

Иногда новые подходы не связаны с технологическим стеком. Чтобы собрать лучших, мы нанимали ребят по всей России, они живут в разных часовых поясах. Но это не мешает нам работать по спринтам, ревьюить код, тестировать, править баги, проводить ретро и демо.

После «ковидной» удаленки мы не стали возвращать всех сотрудников в офис, а перестроили процессы и перешли на асинхронный подход: когда мы пишем запрос в чат или комментарий в задаче, то не ждем мгновенного ответа. Для этой модели важна правильная декомпозиция — в компании должно быть достаточно независимых процессов и задач. Тогда даже если вы получите ответ не сразу, а через день-два, ничего страшного не произойдет: специалист просто переключается на другую часть задачи или меняет «таску». Главное, что в результате ему не приходится ждать или торопить коллег.

В результате повышается концентрация всех членов команды: не нужно постоянно мониторить чаты, задачи и почту, можно выделить на это, например, час после ежедневной планерки, а все остальное время кодить, тестировать, писать документацию. Сокращение количества созвонов (мы оставили только самые необходимые мероприятия — демо, ретро и т.п.) особенно важно для команды, которая работает в разных часовых поясах: от Москвы до Братска.

А как же встречи у кулера и командные обеды, без которых, кажется, невозможно выстроить взаимоотношения в команде? Мы нашли, чем их заменить. Иногда собираем всех в одном городе (чаще всего в Москве), работаем в офисе, а после идем толпой в бар или еще куда-нибудь. За счет этого ребята узнают друг друга лично и налаживают связи. Они сами организуются в клубы по интересам: в одном городе собираются поиграть в настолки, в другом — в футбол.

Мы начали работать по асинхронной схеме не сразу. Сперва договаривались с разработчиками, что нужно ответить в течение часа, потом – в течение двух; ребятам, которые всегда отвечали в течение двух минут, рассказывали, что отвлекаться от текущих задач не обязательно, ничего не сгорит. Параллельно работали с продактами, рассказывали, что нужен запас времени на выполнение задачи, чтобы мы могли работать эффективно, качественно, в срок, но не в спешке из-за того, что кто-то уже пообещал показать новую версию.

Свой подход к работе мы перенесли в наём: сразу рассказывали о процессах, о специфике нашей работы, искали подходящих ребят через вопросы и разбор кейсов на собеседовании. Например: «К вам в 9 утра прибежал коллега с задачей, которую обязательно надо сдать сегодня. Что вы будете делать?»

Наконец, в роли СТО я старался работать с коллегами, которые приходят с горящими задачами, например: «Через неделю демо продуктов, нам надо обязательно участвовать, и мы хотим показать фичи 1, 2 и 3, хотя мы понимаем, что фича 2 не будет готова вовремя, надо повышать приоритет, чтобы успеть». В таких случаях мы выясняем, откуда срочность — действительно ли надо реализовать функцию к ближайшей встрече или имеет смысл сделать ее несколько позже, зато более качественно.

Разбор с коллегами, когда задача действительно нужна срочно, а в каких случаях требует более глубокой проработки — это специфика продукта на старте, сейчас такая дилема возникает редко. Но в любом случае опыт инцидент-менеджмента, когда приходится выбирать между интересами разных команд и отделов, позволяет улучшить процесс и организацию действий. Получив достаточный опыт работы с новым продуктом, мы научились декомпозировать возникающие задачи так, чтобы выполнять их качественно и в срок.

Конечно, бывают случаи, когда надо сделать что-то максимально быстро. Тогда мы переходим в режим «синхронной коммуникации», но после решения всех проблем возвращаемся к более эффективному для нас «асинхронному» состоянию.

Что дают инновации разработчику?

Я и вне работы стараюсь следить за развитием технологий, чтобы не терять интерес к программированию. Иногда делаю пет-проекты.

Забавный пример: когда команда только-только формировалась, многие ребята делились друг с другом мемами в корпоративном чате, и это не нравилось части коллег. Чтобы их примирить, я сделал бота, который собирал мемы. А потом он отправлял их в отдельный канал, куда заходили только желающие.

Из недавнего и интересного: делаю сервис Personaj, в котором можно общаться с виртуальными личностями — от Эйнштейна до Пикачу. Сейчас аватаров уже больше 100, и база растет (к тому же можно добавить своего). Суть такая: каждый человек после регистрации может предоставить фото, текстовое описание и имя персонажа — допустим, Пушкин. Моделька на основе этих UGC-данных создаст аватара, который будет отвечать, как этот самый Пушкин (с учетом предоставленных данных, конечно). Другой вариант — поговорить с уже готовым Пушкиным, данные о котором мы подгрузили из открытых источников.

Бэкенд у нас на Python, фронт пока на low-code, но скоро переедем на React, который мне всегда нравился. Смотрел и другие варианты, например, порог входа в Angular по необходимым знаниям мне показался выше, и он скорее подходит для больших команд. Так что важно учитывать разные аспекты при выборе стека и подбирать его не только под задачу, но и под имеющуюся команду. Вот примеры работы проекта:

Всегда ли нужны новые технологии?

В заключение отмечу, что не обязательно в каждый проект внедрять новый фреймворк или модный язык программирования. Все зависит от конкретной задачи. Если вам нужно сделать что-то инновационное или догнать конкурентов, разумеется, лучше пробовать новое. Но если делаете стандартный продукт, который хорошо работает на старом стеке, не стоит изобретать велосипед.

В случае с ассистентом новый стек был необходим, но для системы авторизации МТС ID, которую мы делали для экосистемы, подобного не требовалось. Так что мы взяли многим известный Keycloack, интегрировали и получили качественный продукт (который к тому же оставляет возможности для кастомизации и написания собственных, нестандартных интеграций).

Чтобы понять, что нужно внедрять инновации, пробовать новые технологии в проекте, я советую отталкиваться от следующих критериев:

1. Есть ли у кого-то в команде опыт работы в этом направлении или все будут учиться вместе «с нуля».
2. Есть ли время и ресурсы на исследования и готовы ли вы к тому, что часть идей и гипотез не выстрелит.

Часто привычных для вас подходов хватает, чтобы сделать надежный, качественный продукт. Но не стоит забывать, что разработка — это постоянное обучение и рост над собой.