Дорогие читатели!Продолжаю серию статей о моём дипломном проекте «Голосовое управление Умным домом». В первой части я рассказал о концепции проекта и техническоДорогие читатели!Продолжаю серию статей о моём дипломном проекте «Голосовое управление Умным домом». В первой части я рассказал о концепции проекта и техническо

От диплома до продакшена: Часть 2: Как я проектировал опыт пользователя

2026/02/26 10:01
9м. чтение

Дорогие читатели!

Продолжаю серию статей о моём дипломном проекте «Голосовое управление Умным домом». В первой части я рассказал о концепции проекта и технической реализации. Во второй части я хочу погрузиться в самую важную часть любого ИИ-продукта — проектирование пользовательского опыта.

Ведь можно создать самую совершенную нейросеть с точностью 99%, но если пользователь не понимает, как с ней взаимодействовать — проект обречён на провал.


Глава 1: Философия проектирования — продукт для людей

Почему пользовательский опыт важнее кода

Когда я начинал проектировать систему, у меня уже был опыт в стратегическом маркетинге и управлении продуктом. Это сформировало мой подход:

Эта философия стала фундаментом для всех архитектурных решений. Я понимал, что технология должна служить человеку, а не наоборот.

Ключевые принципы проектирования

При проектировании пользовательского опыта я руководствовался следующими принципами:

Принцип

Описание

Реализация

Невидимый интерфейс

Пользователь не должен думать о системе

Голосовое управление без триггерных слов

Контекстное понимание

Система понимает намерение, а не только команду

Разделение команды и обычной речи

Гибкость настроек

Пользователь может настроить систему под себя

Профили пользователей с разными правами

Безопасность по умолчанию

Защита от несанкционированного доступа

Распознавание голоса для идентификации


Глава 2: Концепция разделения прав доступа

Зачем нужно разделение прав?

В умном доме живут разные люди: взрослые, дети, пожилые люди, гости. У каждого из них должны быть разные права доступа к функциям дома.

Примеры ситуаций:

Сценарий

Проблема

Решение

Ребёнок пытается войти в помещение не для него

Безопасность

Ограничение доступа по возрасту

Подросток хочет посмотреть контент 18+

Родительский контроль

Ограничение по возрастным категориям

Гость пытается изменить настройки системы

Конфиденциальность

Гостевой режим с ограниченным доступом

Пожилой человек нуждается в помощи

Забота о здоровье

Мониторинг активности и уведомление родственников

Архитектура системы разделения прав

┌─────────────────────────────────────────────────────────────────┐ │ СИСТЕМА РАЗДЕЛЕНИЯ ПРАВ ДОСТУПА │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ 1. ИДЕНТИФИКАЦИЯ ПОЛЬЗОВАТЕЛЯ │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ │ │ Голосовая │ │ Распознавание│ │ Профиль │ │ │ │ │ │ биометрия │→ │ голоса │→ │ пользователя│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ 2. ОПРЕДЕЛЕНИЕ УРОВНЯ ДОСТУПА │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ │ │ Возраст │ │ Роль в │ │ Время │ │ │ │ │ │ пользователя│ │ семье │ │ суток │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ 3. ПРОВЕРКА ПРАВ НА КОМАНДУ │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ │ │ Тип команды │ │ Устройство │ │ Контекст │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ 4. ИСПОЛНЕНИЕ ИЛИ ОТКЛОНЕНИЕ КОМАНДЫ │ │ │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ │ │ Исполнить │ │ Отклонить │ │ │ │ │ │ команду │ │ с уведомлением│ │ │ │ │ │ │ │ │ │ │ │ │ └──────────────┘ └──────────────┘ │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘

Уровни доступа

Для обеспечения безопасности многоуровневая система доступа:

Уровень

Описание

Права доступа

Взрослые

Родители, владельцы жилья

Все команды доступны, могут открывать двери, замки, сейфы

Подростки (13-17 лет)

Ограниченный доступ

Базовые команды (свет, телевизор, музыка), ограниченный доступ к дверям

Дети (0-12 лет)

Минимальный доступ

Только базовые команды (свет, телевизор), нет доступа к дверям, замкам, окнам

Гости

Временный доступ

Только гостевые функции, нет доступа к личным данным и устройствам

Механизм «взросления»

Один из интересных моментов, которые я реализовал — это автоматический переход пользователя из статуса «ребёнок» в статус «взрослый» на основе даты рождения.

Как это работает:

  1. Владелец устройства вводит дату рождения каждого члена семьи

  2. Система хранит эту информацию в постоянной памяти

  3. При достижении определённого возраста права доступа автоматически обновляются

Примеры возрастных ограничений: (вариативно)

Возраст

Доступные функции

Ограничения

0-12 лет

Базовые команды (свет, телевизор)

Нет доступа к дверям, замкам

13-17 лет

Расширенные (музыка, интернет)

Ограниченный контент

18+ лет

Полный доступ

Нет ограничений

Эта функция особенно важна для семей с детьми, потому что родителям не нужно вручную обновлять права доступа — система делает это автоматически.


Глава 3: Контекстное понимание команд

Проблема: команда или обычная речь?

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

Решение: метод с книгой

Для обучения нейросети различать команды и обычную речь я использовал интересный метод:

Этап 1: Чтение книги как фон

  • Я брал книгу и читал её вслух

  • В книге было повествование о том, что есть какое-то движение в помещении

  • Люди ходят, включают телевизор, смотрят передачу

  • Затем хотят просто включить чайник, чтобы заварить чай

Этап 2: Пауза перед командой

  • Я дочитывал до момента, где герой книги включает телевизор

  • Делал короткую паузу, замедление, менялась высота и тембр голоса (это паттерн)

  • Говорил команду: «Включи телевизор»

  • Продолжал чтение

Этап 3: Разметка данных

  • Эта пауза и замедление служили маркером для системы

  • Нейросеть училась распознавать этот паттерн

  • После обучения фон убирался

  • Нейросеть вырабатывала свои паттерны распознавания

┌─────────────────────────────────────────────────────────────────┐ │ МЕТОД ОБУЧЕНИЯ С КНИГОЙ │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Шаг 1: Чтение книги (фоновая речь) │ │ "Герой вошёл в комнату и включил свет..." │ │ │ │ Шаг 2: Пауза (2-3 секунды) │ │ [система фиксирует паузу как маркер] │ │ │ │ Шаг 3: Команда │ │ "Включи телевизор" │ │ │ │ Шаг 4: Продолжение чтения │ │ "После этого он сел в кресло..." │ │ │ │ Результат: │ │ • Фоновая речь = НЕ команда │ │ • Пауза + фраза = КОМАНДА │ │ • После обучения фон убирается │ │ • Нейросеть вырабатывает свои паттерны │ │ │ └─────────────────────────────────────────────────────────────────┘

Этот метод оказался очень эффективным, потому что:

  1. Естественный контекст — книга создаёт естественный речевой поток

  2. Чёткие маркеры — пауза перед командой служит чётким маркером

  3. Разнообразие — разные книги дают разную лексику и интонации

  4. Масштабируемость — метод можно применять для обучения разным командам

Паттерны, которые вырабатывала нейросеть

После обучения нейросеть научилась распознавать следующие паттерны:

Паттерн

Описание

Пример

Пауза перед командой

Короткая пауза перед командой

«...[пауза] включи свет»

Изменение интонации

Командная интонация отличается от повествовательной

«ВКЛЮЧИ свет» vs «он включил свет»

Контекстные маркеры

Определённые слова-триггеры в контексте

«хочу», «нужно», «давай»

Временные паттерны

Время суток влияет на интерпретацию

«включи свет» утром vs вечером

Всплески в аудиосигнале

Когда я глазами просматривал результаты разбора звука, я понял, что ещё происходит всплески по голосу.

Сравнение характеристик:

Параметр

Фоновая речь

Команда

Амплитуда

Стабильная, низкая

Пик, всплеск

Плотность звука

Равномерная

Увеличенная

Динамический диапазон

Узкий

Широкий

Пауза перед

Отсутствует

Короткая пауза


Глава 4: Гибкость vs. Строгие требования

Моя философия балансировки

Этот принцип стал основой для проектирования гибкой, но безопасной системы.

Примеры реализации

Жёсткие требования (неизменяемые):

  • Проверка прав доступа перед открытием двери

  • Валидация возраста для контента 18+

  • Проверка подлинности голоса владельца

Гибкие настройки (настраиваемые):

  • Громкость уведомлений

  • Время автоматического отключения света

  • Персональные сценарии «Утро», «Вечер», «Ночь»


Глава 5: Мониторинг и безопасность

Наблюдение за здоровьем

Одна из расширенных возможностей системы — мониторинг активности пользователей для заботы о здоровье и безопасности.

Сценарий для пожилых людей:

Параметр

Норма

Тревога

Действие

Активность

Движение по квартире

Отсутствие движения > 2 часов

Уведомление родственникам

Скорость движения

Нормальная

Замедление

Уведомление лечащему врачу

Голос

Нормальный

Тревожный

Экстренный вызов

Сценарий для детей:

Параметр

Разрешено

Запрещено

Действие

Доступ к огню

Нет

Да

Блокировка + уведомление родителям

Контент 18+

Нет

Да

Блокировка + запись в лог

Время у экрана

2 часа/день

> 2 часов

Предупреждение + блокировка

Логирование и уведомления

Для обеспечения безопасности все действия логируются:

Действие

Логирование

Уведомление

Ребёнок пытается открыть дверь

✅ Да

✅ Родителям

Гость пытается получить доступ к настройкам

✅ Да

✅ Владельцу

Взрослый изменяет настройки

✅ Да

❌ Нет

Попытка несанкционированного доступа

✅ Да

✅ Владельцу + полиция


Глава 6: Практическая реализация

Пример сценария: ребёнок пытается открыть дверь (например может быт таким)

┌─────────────────────────────────────────────────────────────────┐ │ СЦЕНАРИЙ: РЕБЁНОК ПЫТАЕТСЯ ОТКРЫТЬ ДВЕРЬ │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 1. Ребёнок говорит: "Открой дверь" │ │ │ │ 2. Система распознаёт голос → Профиль: Ребёнок (8 лет) │ │ │ │ 3. Проверка прав доступа: │ │ • Команда: "Открой дверь" │ │ • Устройство: Входная дверь │ │ • Права ребёнка: НЕТ доступа к входной двери │ │ │ │ 4. Решение системы: │ │ • Команда ОТКЛОНЕНА │ │ • Действие: Дверь не открывается │ │ • Логирование: Запись в журнал событий │ │ • Уведомление: Отправка уведомления родителям │ │ │ │ 5. Обратная связь ребёнку: │ │ • Голосовое сообщение: "Извини, ты не можешь открыть │ │ входную дверь. Это могут сделать только взрослые." │ │ │ └─────────────────────────────────────────────────────────────────┘

Пример сценария: автоматическое обновление прав

┌─────────────────────────────────────────────────────────────────┐ │ СЦЕНАРИЙ: ДЕНЬ РОЖДЕНИЯ ПОДРОСТКА │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 1. Система проверяет даты рождения пользователей │ │ │ │ 2. Обнаружено: Пользователь "Сын" достигает 18 лет │ │ │ │ 3. Автоматическое обновление прав: │ │ • Предыдущий статус: Подросток (13-17 лет) │ │ • Новый статус: Взрослый (18+ лет) │ │ • Обновлённые права: Полный доступ ко всем функциям │ │ │ │ 4. Уведомление: │ │ • Пользователю: "Поздравляем! Теперь у вас полный доступ │ │ ко всем функциям умного дома." │ │ • Родителям: "Ваш сын достиг 18 лет. Права доступа │ │ автоматически обновлены." │ │ │ └─────────────────────────────────────────────────────────────────┘


Глава 7: Уроки и выводы

Что сработало хорошо

  1. Метод с книгой — оказался очень эффективным для обучения контекстному пониманию

  2. Автоматическое обновление прав — избавило от ручной настройки

  3. Голосовая биометрия — обеспечила надёжную идентификацию пользователей

  4. Гибкие настройки — позволили адаптировать систему под разные семьи

Что можно улучшить

  1. Распознавание эмоций — можно добавить распознавание эмоционального состояния для более точного понимания контекста

  2. Мультимодальность — добавить распознавание жестов и взгляда для более естественного взаимодействия

  3. Адаптивное обучение — система должна учиться на ошибках и адаптироваться под пользователя

  4. Интеграция с внешними сервисами — интеграция с системами безопасности, экстренными службами

Советы для разработчиков

  1. Начинайте с пользовательских сценариев — не с архитектуры, а с того, как пользователь будет использовать систему

  2. Тестируйте на реальных людях — не только на тестовых данных

  3. Думайте о крайних случаях — дети, пожилые, люди с особенностями

  4. Соблюдайте баланс между интеллектом и контролем — система должна быть умной, но не слишком


Что будет в следующей части?

Часть 3: Архитектура нейросети

В третьей части я расскажу о технической реализации нейросети:

  • Почему была выбрана архитектура Multi-input CNN

  • Как обрабатываются три группы признаков (SSR, CHZ, MFC)

  • Детали реализации свёрточных слоёв

  • Оптимизация для работы в реальном времени


📚 Источники и ресурсы

Исходные материалы проекта

Файл

Описание

Ссылка

Презентация

Презентация дипломного проекта

[Скачать PDF](! Презентация дипломного проекта.pdf)

Jupyter Notebook

Код модели и обучение

[SmartHome v4.6.ipynb](SmartHome v4.6.ipynb)

GitHub

Репозиторий проекта

github.com/AlekseyVB/SmartHome

Будет продолжение

Источник

Отказ от ответственности: Статьи, размещенные на этом веб-сайте, взяты из общедоступных источников и предоставляются исключительно в информационных целях. Они не обязательно отражают точку зрения MEXC. Все права принадлежат первоисточникам. Если вы считаете, что какой-либо контент нарушает права третьих лиц, пожалуйста, обратитесь по адресу [email protected] для его удаления. MEXC не дает никаких гарантий в отношении точности, полноты или своевременности контента и не несет ответственности за любые действия, предпринятые на основе предоставленной информации. Контент не является финансовой, юридической или иной профессиональной консультацией и не должен рассматриваться как рекомендация или одобрение со стороны MEXC.