Разбираем статью об улучшении диалоговых агентов с помощью «проактивности». Речь о способности системы в нужный момент задать уточняющий вопрос, если она понимает, что пользователь, скорее всего, останется недоволен ответом.
Применяют обычный для голосового ассистента каскадный пайплайн: отдельный ASR, переформулировка запроса при необходимости, определение интента (намерения пользователя) и домена, формирование ответа-кандидата, TTS. Поверх этого работает диалог-менеджер, который решает, отдавать ответ сразу или сначала уточнить запрос. Для этого он пытается предсказать, будет ли пользователь недоволен на текущем шаге.
Модель диалог-менеджера состоит из трёх веток, чьи представления конкатенируются и подаются в MLP-голову предсказания недовольства.
Query-side. На вход: ASR-вывод, n-best гипотез и rewritten query. Для n-best гипотез считается attention pooling, чтобы собрать их в одно агрегированное представление. Эта ветка должна уловить расхождения между вариантами одного и того же запроса и тем самым помочь выявить возможные ASR-ошибки.
Response-side. На вход: финальный запрос, ответ-кандидат и связанные с ним признаки. Эта ветка моделирует, насколько согласованы между собой пользовательский запрос и тот результат, который система собирается вернуть.
Session-side. На вход: история взаимодействия и время отклика. Эта ветка извлекает признаки на уровне сессии — то есть паттерны, связанные с пользовательской неудовлетворенностью в ходе диалога.
Проблема в том, что такой диалог-менеджер часто ошибается в обе стороны. Если он не задаёт уточняющий вопрос, где это нужно, пользователь получает плохой ответ. Если задаёт лишний — начинает раздражать. Когда модель выкатили в прод и посмотрели на реальные сессии, оказалось, что она хуже всего работает именно там, где обучающий сигнал слабее всего:
1) На ошибках ASR — распознавание часто даёт странные или редкие формулировки, которых мало в обучении, и диалог-менеджер плохо на них обобщается;
2) Редкие домены — на частых сценариях система работает лучше, а в QA и других long-tail-случаях заметно проседает. Авторы связывают это с тем, что здесь используются слабые метки, извлечённые из последующего поведения пользователя, а редких кейсов мало, чтобы основной сигнал сам научил модель устойчивым представлениям.
Архитектуру авторы не меняют. Вместо этого усиливают обучение с помощью двух дополнительных задач.
Первая — contrastive self-supervised learning. Схема, близка к SimCSE: один и тот же запрос дважды пропускается через энкодер с разным dropout, после чего полученные представления сближаются как positive pair, а остальные примеры в батче используются как negatives. За счёт этого модель становится устойчивее к ASR-шуму, редким вариантам запроса и вообще лучше переносит «кривые» формулировки.
Вторая — классификация домена и интента. Для этого авторы берут сессионное представление, построенное по истории диалога, и учат отдельную голову предсказывать, к какому домену относится текущий запрос и какой у него интент. Эта задача нужна не сама по себе, а как дополнительный обучающий сигнал, заставляя модель лучше структурировать редкие сценарии и тем самым повышая качество в long-tail-доменах.
В итоге всё обучается совместно: основной лосс на предсказание недовольства и два вспомогательных лосса с весами. Отдельный претрейн не требуется.
Основной прирост возникает там, где у базовой модели были проблемы: в редких доменах и шумных запросах. В офлайне это особенно заметно в домене universal QA, где CLA растёт с 0,045 до 0,058. Онлайн-замер это подтверждает: в разборе тысячи сессий новая модель лучше выявляет ошибки ASR (38/119 против 30/119) и NLU (10/61 против 5/61).
По сути, статья показывает практичный ход: если основной обучающий сигнал шумный и плохо покрывает редкие случаи, можно не усложнять архитектуру, а добавить вспомогательные задачи, которые делают представления устойчивее к ASR-ошибкам и полезнее для long-tail-доменов.
Никита Боровко
