Проектирование голосового ассистента МТС Секретарь

Проект системы: МТС Секретарь (highloud)

1. Функциональные требования (ФТ)

Голосовой ассистент предназначен для помощи абонентам МТС в мобильном приложении.

Основные функции:

1. Голосовая активация: Возможность запуска ассистента голосом (например, «Привет, Секретарь») или через кнопку в интерфейсе приложения.
2. Распознавание речи (STT): Преобразование голоса пользователя в текст.
3. Понимание намерений (NLU): Анализ текста, выделение интентов (намерений) и сущностей (параметров).
   Пример: «Пополни счет на 500 рублей» -> Интент: pay_mobile, Сущность: amount=500.
4. Управление диалогом (DM): Поддержка контекста диалога (не путать с историей сессии).
5. Генерация ответа (NLG): Формирование текстового ответа.
6. Синтез речи (TTS): Озвучивание ответа пользователю голосом ассистента.
7. Исполнение сценариев (Backend):
   Проверка баланса и детализация расходов.
   Оплата услуг, подключение/отключение подписок.
   Поиск контактов и совершение вызова/отправка SMS.
   Помощь в настройках телефона (через интеграцию с ОС).
   Поиск офисов и ближайших банкоматов (геосервисы).
8. Аутентификация: Верификация личности через данные аккаунта в приложении (безопасные операции должны требовать подтверждения).

2. Нефункциональные требования (НФТ)

Требования к качеству (highloud):

1. Производительность и Latency:
   Общее время ответа (сквозная задержка) не должно превышать 1.2 секунды для 95% запросов (иначе диалог ощущается "неживым").
   Время первого байта аудио (TTS) должно быть < 300 мс.
2. Доступность и Отказоустойчивость:
   Целевой уровень доступности сервиса: 99.95% (исключая сбой мобильного интернета клиента).
   Отсутствие единой точки отказа (High Availability).
3. Масштабируемость:
   Горизонтальное масштабирование под нагрузку (пиковые часы — вечер, праздники).
   Поддержка миллионов пользователей.
4. Безопасность:
   Шифрование трафика (mTLS между сервисами, TLS/HTTPS на границе).
   Обезличивание (анонимизация) персональных данных в логах диалогов.
   Защита от фрода (ботов).
5. Надежность ASR/TTS:
   Качество распознавания речи (WER — Word Error Rate) не хуже 5% для чистого канала.
   Естественность синтеза речи (MOS — Mean Opinion Score) не ниже 4.5.

3. Архитектура системы (C4 нотация)

Уровень 1: Контекст системы (System Context)

На этом уровне показано, как «МТС Секретарь» взаимодействует с внешними системами и пользователями.

Уровень 2: Контейнеры (Containers)

Декомпозиция «МТС Секретаря» на основные высокоуровневые приложения и хранилища.

Уровень 3: Компоненты (Components) на примере Dialogue Manager

Детализация одного из ключевых контейнеров (например, Dialogue Manager), чтобы показать его внутреннее устройство.

4. Описание ключевых компонентов

1. API Gateway (Edge):
   Принимает WebSocket/gRPC-стрим от мобильного приложения.
   Аутентифицирует устройство (проверка JWT-токена).
   Маршрутизирует трафик в зависимости от типа данных (аудио или текст).
2. Voice Processing Layer (ASR/TTS):
   Используют GPU-инстансы в облаке highloud для низкой задержки.
   ASR: Работает с аудиопотоком в реальном времени (streaming режим).
   TTS: Использует нейросети для генерации "живого" голоса.
3. Dialogue Layer (NLU + DM):
   NLU: Микросервис на Python (PyTorch/TensorFlow), инференс ML-моделей.
   DM: Статус-машина. Хранит состояние диалога в Redis (например, пользователь сейчас на шаге подтверждения платежа).
4. Business Assistant (BA):
   Оркестратор. Получив интент (например, pay_phone), вызывает биллинг, ждет ответ и возвращает статус.
   Работает синхронно, но таймауты строго контролируются.
5. Data Layer:
   Redis: In-memory хранилище для сессий (время жизни сессии ~30 мин неактивности).
   Cassandra: Распределенное хранилище для логов диалогов (аналитика, улучшение моделей, омниканальность). Выбрана за способность принимать высокую нагрузку на запись.

5. Ключевые сценарии работы (Sequence)

Сценарий: "Проверка баланса"

1. Пользователь: "Сколько денег на счете?"
2. МП приложение стримит аудио -> ASR.
3. ASR -> (текст) -> NLU.
4. NLU -> (intent: get_balance, entities: {}) -> DM.
5. DM проверяет состояние (State Tracker), видит, что это начало диалога -> вызывает BA.
6. BA дергает BSS (биллинг) -> получает баланс (150 руб).
7. BA -> DM (ответ: text="Ваш баланс 150 рублей").
8. DM -> TTS (текст).
9. TTS -> генерирует аудио -> стримит в МП.
10. МП проигрывает: "Ваш баланс 150 рублей".

Данная архитектура обеспечивает модульность (можно заменить ASR провайдера), горизонтальное масштабирование и соответствует требованиям high-нагруженного облачного сервиса (highloud).

Страховка на собеседовании

Знание есть, но стресс мешает?
Бесплатное сообщество для прокачки карьеры в IT

Подпишись на https://t.me/IT_Interview_Partner_Bot
Подпишись на https://t.me/LyakhovEugene