Always Alert: обнаружение бедствия по звуку смартфона

Эта статья выглядит старомоднее большинства свежих работ с большими моделями, но полезна инженерной постановкой: круглосуточное обнаружение крика или плача со смартфона упирается не только в recall, а в цену ложных тревог. Авторы строят Always Alert как каскад фильтров и отдельно считают, сколько уведомлений получат люди "в контуре проверки". Для практических аудио-систем это хороший пример, где метрика продукта важнее красивой точности на чистом тесте.

Метод. Система использует MFCC-признаки и SVM-классификаторы. Первый фильтр отделяет обычную речь от сигналов бедствия, но дает около 10% ложных тревог. Второй, контекстный, фильтр проверяет похожие на крик срабатывания на фоне других звуков и снижает FAR примерно до 1%. Затем temporal analysis подавляет серии подряд идущих ложных срабатываний, а спорные фрагменты предлагается отправлять доверенным людям для подтверждения.

Результаты. В выбранных рабочих точках на валидации P1 для чистых distress-сэмплов дает DR 96.33% при FAR 1.29%, P3 при 40 dB - DR 95.03% и FAR 1.02%, P4 при 20 dB - DR 79.30% и FAR 1.35%. На 10 dB компромисс становится тяжелым: P5 дает DR 79.62%, но FAR 5.71%, а P6 снижает FAR до 1.29%, но DR падает до 50.81%. На добровольческих фоновых записях авторы сообщают средний FAR 0.8978% и медианный 0.45% для P1; один пользователь с музыкой и телевизором дал особенно много ложных срабатываний.

Ограничения. В тестовых данных добровольцев нет реальных криков, поэтому оценка ложных тревог и оценка обнаружения фактически разделены. Метод основан на ручных признаках и SVM, без современной проверки на разнообразных телефонах, языках и акустических условиях. Есть и продуктовый риск: даже одно сообщение каждые несколько часов может стать неприемлемым, если почти все они ложные.

Фишка из статьи. Самая ценная часть - учет серийности ложных тревог: модель может срабатывать часто, но если ошибки идут пачками, их можно сжать во времени.

Как это читать: с точки зрения продукта важен не только FAR в процентах, а частота реальных уведомлений. Уменьшение 1197 срабатываний до 11 показывает, что постобработка может быть столь же важна, как сам аудио-классификатор.