Как устроена голосовая активация в Яндекс Дропс

Недавно Яндекс запустил свои первые ИИ-наушники — Яндекс Дропс. В числе прочего они умеют распознавать обращение «Алиса», а отвечает за эту способность компонент, который мы внутри называем «споттером» (чуть подробнее писали о споттерах тут). И если с голосовой активацией в колонках всё плюс-минус понятно, то перенести её в наушники — это челлендж.

О том, что было сложного в этом процессе и как в итоге выкрутились, рассказал на Хабре Григорий Афанасенко из команды голосовых технологий. А мы пересказываем самое интересное.

Для начала следовало выбрать чип, который позволил бы споттеру работать непрерывно и постоянно искать обращение в окружающем шуме. Большинству CPU такое не под силу — поэтому взяли чип с NPU (Neural Processing Unit). Решение казалось практически беспроигрышным — но ещё подкинуло сложностей в процессе.

Даже с NPU надо было придумать, как оптимизировать потребление энергии. Решили сделать два этапа — и тем самым уменьшили нагрузку в пять раз:

1. Лёгкая модель VAD (Voice Activity Detector) отделяет голос от фонового шума.

2. Когда VAD услышал голос, включается споттер и разбирается, «Алиса» это или нет.

Также была проблема с тем, что модели из умных колонок в наушники никак бы не влезли. Надо было ужать модель под NPU, сохранив качество распознавания. Провели ряд оптимизаций (разбили подсчёт зависимостей на два шага с помощью Depthwise‑separable convolution, добавили дистилляцию знаний и квантование в 8 бит) — и уместили модель в 200 КБ.

А теперь возвращаемся к той самой проблеме в NPU. Выяснилось, что SDK производителя чипа накладывает жёсткие ограничения на архитектуру: размер ядра свёртки — до 15 фреймов для обычных свёрток и до 11 фреймов для depthwise.

Пришлось сделать сеть глубже, чтобы набрать нужный контекст, а вместо Hardswish выбрать ReLU, которая хорошо ведёт себя после квантования. Но тут получили затухание градиента, из-за которого нижние слои почти не обучались. Помог переход на residual‑архитектуру.

А ещё, после долгих экспериментов с SDK, разобрались, как использовать для наших моделей стриминг, — и увеличили модель в два раза.

Качество споттера оценивали по числу ложных срабатываний в час и доле пропущенных верных активаций. Лучший баланс, разумеется, в тихой комнате. На улице качество чуть ухудшается, а в транспорте система почти не срабатывает ложно, но цена за это — высокий уровень пропусков. Ещё один сложный сценарий — разговор на фоне: доля пропусков небольшая, а вот число ложных активаций возрастает ощутимо.

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

Григорий Афанасенко Специально для Speech Info