Sber / GigaChat: Финальное собеседование

Сначала формулируем сценарий и действие продукта: что ассистент делает после события, кому это полезно, как измерить пользу и какой вред от false positive.

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

Дальше оцениваем частоту события, аудиторию, стоимость ошибки и user journey. Лай собаки может быть полезен не всем; разбитое стекло или сработавшая сигнализация могут быть high-value, но требуют низкого false positive и понятной реакции.

Проверить гипотезу можно без полной ML-системы: fake door test, ручная разметка аудио, прототип с готовой моделью, интервью пользователей, A/B уведомлений на synthetic/curated events. Метрики: activation, response rate, disable rate, complaints, false alarm rate, retention.

Baseline: нарезать аудио окнами, считать log-mel spectrogram, обучить CNN/CRNN или взять pretrained audio model, затем подобрать threshold под цену false positive.

Технический baseline: поток аудио режется на короткие окна, например 1-5 секунд. Для каждого окна считаем log-mel spectrogram или MFCC. Дальше обучаем классификатор: CNN по спектрограмме, CRNN/Transformer для учета времени или fine-tune pretrained audio model.

Данные должны покрывать шумы, комнаты, микрофоны, расстояния, перекрывающиеся события и hard negatives. Важны negative examples: телевизор, музыка, разговор, бытовые шумы, чтобы модель не тревожила пользователя.

Оценка: precision/recall по классам, false alarms per hour/day, latency, устойчивость к шуму, calibration. Для ассистента часто нужен threshold per class: для тревожных событий precision важнее, для мягких подсказок можно позволить больше recall.

Нужен легкий on-device detector: quantization, distillation, streaming windows, early exit, локальная обработка приватного аудио и cloud fallback только при явном разрешении/событии.

Для устройства важно не только качество, но и ограничения: CPU, память, задержка, энергопотребление, приватность. Поэтому используем маленькую модель, quantization, distillation, pruning или mobile-friendly архитектуру.

Serving может быть двухступенчатым: дешевый wake-up/event detector постоянно слушает короткие окна, а более дорогая модель запускается только на подозрительных событиях. Для приватности лучше обрабатывать аудио локально и не отправлять сырой звук в облако без необходимости и согласия.

Мониторинг сложнее, чем на сервере: нужны anonymized counters, opt-in telemetry, shadow evaluation на разрешенных данных, версии моделей, rollback. Метрики: latency, CPU/memory, false alarms per day, battery impact, crash rate, disable rate.

Данных нужно достаточно по каждому классу, устройству и шумовому контексту; high-resolution включаем по calibrated confidence, expected value события и бюджету latency/энергии.

На вопрос "сколько данных" нельзя честно ответить одним числом. Нужна оценка по классам событий, редкости, разнообразию устройств, помещений, микрофонов, шумов и языков/регионов. Для старта можно собрать пилотный датасет, обучить baseline и построить learning curve: качество от размера данных.

Для редких событий важны synthetic/augmented data, public datasets, targeted collection, active learning и hard negative mining. Но production threshold все равно надо подбирать на реальных данных.

Переключение на high-resolution режим - это decisioning задача. У модели есть score/confidence, цена пропуска события и цена ложного срабатывания, плюс стоимость CPU/батареи/трафика. Можно включать дорогой режим только при score выше порога, при повторном подтверждении на нескольких окнах или для high-value классов.