Оценка голосовых ассистентов в 2025: от WER к задаче-успеху, перехватам и галлюцинациям под шумом

Почему WER недостаточен

Word Error Rate (WER) показывает точность расшифровки, но не отражает, помогает ли ассистент пользователю выполнить задачу или вести диалог корректно. Два решения с похожим WER могут кардинально отличаться в пользовательском опыте из-за задержек, управления очередью хода, обработки прерываний, восстановления после недопонимания и устойчивости к акустическим и содержательным искажениям. Практические исследования показывают: для прогнозирования удовлетворенности нужны сигналы взаимодействия и метрики на уровне задач, а не только точность ASR.

Что измерять и как

1. Сквозной успех задачи

• Метрика: Task Success Rate (TSR) с четкими критериями успеха для каждой задачи, плюс Task Completion Time (TCT) и количество ходов до успеха.
• Почему: пользователи оценивают ассистента по результатам; TSR отражает реальную полезность.
• Протокол: описать проверяемые задания с верифицируемыми конечными состояниями (например, составить список покупок с N элементами и условиями). Использовать слепых человеческих оценщиков и автоматические логи для подсчета TSR/TCT/Turns. Для многоязычной и SLU-нагруженной области брать intents/slots из MASSIVE.

2. Перехват речи (barge-in) и управление ходом

• Метрики: задержка обнаружения barge-in (мс), доля корректных/ложных перехватов, задержка завершения (endpointing) в мс.
• Почему: гладкое прерывание и быстрое завершение речи формируют восприятие отзывчивости; ошибки приводят к потере ввода или раздражению.
• Протокол: скриптовать прерывания на контролируемых временных точках и SNR, логировать времена подавления и распознавания с точностью до кадров, включать шумные и дальние условия, измерять ложные срабатывания.

3. Галлюцинации под шумом (HUN)

• Метрика: HUN Rate — доля беглых ответов, семантически не связанных с аудио, при контролируемом шуме или не-спич вставках.
• Почему: стэки ASR+audio-LLM могут генерировать убедительный, но неверный текст при наличии не-речевых звуков; такие галлюцинации влияют на последующие действия.
• Протокол: собрать наборы аудио с наложенным окружающим шумом, не-речевыми отвлекателями и дизфлюенсиями; оценивать семантическую связность с участием людей и вычислять HUN; отслеживать влияние на downstream-действия.

4. Следование инструкциям, безопасность и робастность

• Набор метрик: точность следования инструкциям (формат и соблюдение ограничений), процент отказов по безопасности на злонамеренные устные подсказки, изменение производительности по осям — возраст/акцент/тембр, окружение (шум, реверберация).
• Почему: ассистент должен корректно выполнять инструкции и отказывать в небезопасных запросах, сохраняя работоспособность для разных говорящих и условий.
• Протокол: использовать VoiceBench для широкого покрытия инструкций и безопасности; SLUE/Phase-2 для SLU-специфики (NER, dialog acts, QA, суммаризация).

5. Перцептуальное качество речи (TTS и enhancement)

• Метрика: Mean Opinion Score по ITU-T P.808 (краудсорс ACR/DCR/CCR).
• Почему: качество воспроизведения влияет на взаимодействие; P.808 дает валидированный краудсорс-протокол и инструменты.

Обзор бенчмарков

• VoiceBench: мультиаспектная оценка голосовых ассистентов по знаниям, следованию инструкциям, безопасности и устойчивости к вариациям говорящего/окружения/контента; использует реальные и синтетические записи. Ограничение: не покрывает barge-in/endpointing или тесты реального выполнения задач на устройствах.
• SLUE / SLUE Phase-2: задачи SLU — NER, sentiment, dialog acts, QA, суммаризация; полезны для изучения чувствительности к ошибкам ASR.
• MASSIVE: >1M фраз для виртуальных ассистентов на 51–52 языках с intents/slots; хорош для многоязычных task-сьютов.
• Spoken-SQuAD / HeySQuAD: наборы для устных вопросов и ответов, проверяющие понимание и устойчивость к акцентам.
• DSTC-треки: качество диалога, устойчивость и безопасность в условиях речи с человеческими оценками.
• Alexa Prize TaskBot: реальные многозадачные сценарии с пользовательскими рейтингами и критериями завершения — полезный эталон для определения TSR.

Заполнение пробелов

• KPI для barge-in и endpointing: добавить инфраструктуру для измерений, опираться на существующие исследования по верификации перехватов и непрерывной обработке.
• Протоколы HUN: принять определения ASR-галлюцинаций и контролируемые тесты с не-речью; отмечать HUN и его влияние на downstream.
• Задержки на устройстве: измерять time-to-first-token, time-to-final и локальную нагрузку, чтобы соотнести с субъективной отзывчивостью.
• Кросс-осевые матрицы устойчивости: комбинировать оси VoiceBench с вашим task-сьютом, чтобы выявить поверхности отказов (например, barge-in при дальнем эхо; успех задачи при низком SNR).
• Перцептуальное качество воспроизведения: мерить P.808 в сквозной цепочке, а не только для изолированного TTS.

Конкретный воспроизводимый план

• Собрать набор: VoiceBench для ядра взаимодействия; SLUE/Phase-2 для SLU; MASSIVE для многоязычия; Spoken-SQuAD для устного QA.
• Добавить отсутствующие возможности: harness для barge-in/endpointing с контролируемыми офсетами и SNR, HUN-audio и аннотации, блок задач со строгими проверками успеха для TSR/TCT/Turns.
• Перцептуальное качество: запустить P.808 с использованием открытых тулкитов.
• Структура отчета: таблица с TSR/TCT/Turns, задержками и ошибками barge-in, задержкой endpointing, HUN rate, агрегатными и осевыми оценками VoiceBench, SLU-метриками и P.808 MOS; графики нагрузки — TSR и HUN vs SNR и реверберация, barge-in latency vs timing.

Практические замечания

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