Почему адреса голосовые роботы до сих пор распознают с ошибками

В сценариях доставки или вызова врача на дом ошибка в адресе стоит дорого: курьер или бригада едут не туда, время теряется, пользователь раздражается. Поэтому системе недостаточно найти в базе «похожую» строку. На выходе нужен один однозначный адрес.

Если в тексте пользователю достаточно заполнить все поля без ошибок, то в голосовом сценарии адрес часто может называться и/или распознаваться с ошибками. Как в таких условиях безошибочно устанавливать адрес, произнесенный человеком в свободной форме?

Чтобы решить эту проблему, мы разработали адаптер для работы с ГАР (Государственным адресным реестром) — официальной базой адресов России. С его помощью можно определить уникальный код (ID) адреса. ID можно получить для разных уровней адреса — от области до конечного адреса пользователя (квартиры или даже комнаты в коммуналке).

Чтобы получить лучший результат определения адреса с наименьшим количеством ошибок, мы пробовали разные варианты поиска адресов. Какие именно — рассказываем далее.

Сначала мы использовали полнотекстовый поиск

Для работы адаптера ГАР в рамках первых двух версий для поиска адреса мы использовали полнотекстовый поиск. Этот подход, грубо говоря, ищет в базе строку, которая больше всего похожа на ту, которую озвучил пользователь.

Например, абоненту не обязательно произносить абсолютно все части адреса, адаптер «поймет», если Вы скажете:

«Тула, Горького 10, квартира 13»

что это:

«Тульская область, городской округ город Тула, город Тула, улица М. Горького, дом 10, квартира 13».

Вариант оказался неидеальным. В работе адаптера мы нашли несколько недостатков:

1. Если адрес назвали не полностью (или ASR услышал не все), то мы не узнаем, чего именно не хватило для того, чтобы найти конечный адрес.

2. Некоторые опечатки или ошибки распознавания речи все еще мешают искать адрес в базе.

3. Иногда в адресе пользователи сообщают слишком много лишней информации, из-за чего максимально похожую строку становится очень сложно отыскать в базе.

4. Если мы не смогли найти адрес с первого раза, приходилось просить пользователя повторить адрес полностью — и это ухудшает пользовательский опыт.

Общая точность срабатывания адаптера первой версии составила около 85%. Примерно 15% адресов оставались неправильно распознанными.

Мы выделили 4 ключевых проблемы, из-за которых повышался процент ошибок:

1. Опечатки

2. Неверное распознавание речи

3. Адрес был назван не полностью

4. Была названа лишняя информация

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

Но что делать с неполными адресами или лишней информацией? Коллеги из R&D предложили попробовать перейти на фасетный поиск, который должен решить эти проблемы — и мы начали тесты.

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

Что же такое фасетный поиск? По своей сути это выделение слотов с элементами адреса — город, улица, дом, квартира и т.д. — и дальнейший поиск в базе распознанной комбинации. 

Например, во фразе «Тула, Горького 10, квартира 13» фасетами (слотами) будут:

Далее адаптер ищет в базе адреса, соответствующие найденной комбинации. Если найдено несколько подходящих вариантов, адаптер должен уточнить только недостающий элемент. Например, по запросу «Тула, Горького 10» потенциальных совпадений будет много, но для однозначного результата не хватает номера квартиры — именно его и следует запросить у пользователя.

На уровне концепции такой подход выглядит оптимальным, потому что адрес можно доводить до точности пошагово:

– Неполный адрес — система запрашивает только отсутствующие компоненты.

– Опечатки и ошибки ASR — для слотов можно задавать синонимы и варианты написания.

– Лишняя информация — она не мешает, если не попадает в адресные слоты.

Однако на практике результаты оказались хуже ожидаемых. На тестовом наборе качество снизилось до 69%. Разбор ошибок показал несколько типов неоднозначностей, которые сложно корректно обработать только фасетами. Пройдемся по четырем из них далее.

1. Дом с литерой: единый номер или номер + корпус?
В ГАР корпус дома вынесен в отдельный уровень. При этом дома с литерами (например, 2А) в разных регионах могут быть представлены по-разному: где-то литера входит в номер дома, а где-то учитывается как корпус.

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

Пример:

«город Тула проспект Ленина дом сто тридцать семь корпус в квартире семьдесят семь»

В таком случае «дом 137 корпус В» может означать как «дом 137В», так и «дом 137, корпус В». Если совпадение не находится, остается перебирать варианты на уровне адаптера.

2. «Микрорайон» в данных может оказаться пригородом или улицей

В адаптере предусмотрен отдельный уровень «микрорайон», но в ГАР встречаются случаи, когда одно и то же название в разных городах относится к разным уровням. Например, «микрорайон Центральный» в одном городе может быть действительно микрорайоном, а в другом — относиться к пригороду.

Проблема в том, что пользователь и сам обычно не знает, как именно этот объект классифицирован в базе. В результате корректное сопоставление слота с уровнем ГАР становится нетривиальной задачей.

3. Короткие фразы дают неоднозначный слот

При минимальном контексте, например «советский двадцать пять», сложно определить, что именно имеется в виду: поселок, улица, переулок и т.д. Без дополнительных слов модель не может уверенно выбрать слот, поэтому в таких случаях приходится запрашивать у пользователя больше информации.

4. Повтор названия увеличивает неопределенность

Иногда пользователь повторяет одно и то же слово, например: «донской донской».

Это может означать или просто «поселок Донской», или «поселок Донской, переулок Донской», или «переулок Донской». В отличие от ситуации с недостатком данных, здесь уже избыточность формулировки мешает корректно интерпретировать структуру адреса.

Обе технологии несовершенны — что же делать?

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

В результате для третьей версии адаптера мы с коллегами решили не отказываться от полнотекстового поиска, а перейти к гибридной схеме. Сначала выполняем поиск полнотекстовым методом, как и раньше. И только если адрес не находится, подключаем фасетный сценарий и уточняем у пользователя лишь недостающие или неоднозначные элементы.

О том, какие результаты в точности у нас вышли, поделимся в будущем, когда наберется статистика.