Как мы в 2,5 раза улучшили идентификацию пользователей в голосовом медпомощнике

Медицинские голосовые помощники могли бы сильно разгрузить контакт-центры, если бы не одно но: они до сих пор могут неправильно идентифицировать пользователей.

Клиента просят назвать ФИО и дату рождения. С распознаванием даты проблем обычно не бывает, а вот ФИО могут произнести неразборчиво, не в том порядке или в произвольной форме «вы говорите с Петром Викторовичем... Морозов фамилия!». Для корректного запроса поиска пациента в медицинской системе нужно именно «Морозов Петр Викторович».

ASR тоже ошибается, и ошибки могут быть разные, особенно в фамилии. Исправить фамилию очень тяжело, если нет конечного числа клиентов в базе.

В статье расскажем, как команда BSS решила эту проблему.

Ранее мы использовали механизм нечеткого поиска (fuzzy search) в Opensearch/Elasticsearch – загружали в него список фамилий, имен и отчеств, характерных для определенного региона. И это работало, но точность была недостаточна: система исправляла лишь около 11% ошибок – это приводило к потере клиентов на этапе идентификации.

Также мы тестировали парочку самым популярных платных сервисов – они неплохо расставляли порядок «фамилия – имя – отчество» и приводили к именительному падежу имя и отчество, но фамилию даже не пытались исправить.

Дополнительная сложность – отсутствие полного списка ФИО. Мы работаем лишь с некоторой выборкой имен, фамилий и отчеств, из-за чего система не может опереться на полный набор возможных совпадений.

Мы стали искать другое решение и тестировать разные технологические подходы.

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

Векторизация баз ФИО занимает слишком много времени, а векторная близость часто работает в семантическом поле, тогда как для ФИО критически важна фонетическая и символьная схожесть.

Например, векторный поиск может вернуть не только Иван Петров, но и Иванов Петр или Иванов Петрович – модель видит общую семантику имени и фамилии, а не строгое совпадение букв и звучания.

Для объективной оценки качества мы сформировали тестовый корпус на базе реальных ошибок из диалогов голосового помощника. Данные структурировали в формате «искаженное ФИО - корректное ФИО».

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

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

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

Мы взяли за основу обычный полнотекстовый поиск на базе OpenSearch. Но при заливке имеющейся базы, в индексе сделали несколько полей под фильтры постобработки: Phonetic, N-gram, Raw.

Для обработки исходной базы использовали python библиотеки fonetika и mawo-pymorphy3, они достаточно хорошо работают с русским языком.

Установили такую логику работы: не нужно валидировать ФИО каждый раз, обработке подвергаются только те клиенты, которых не смогли идентифицировать – то есть те, в чьих ФИО уже есть ошибка. Так мы не боимся сломать правильное ФИО, а только стремимся исправить заведомо ошибочное.

Так получился сервис Fio Corrector. Вот как он работает:

1. При поступлении ФИО с ошибкой запускается многоканальный поиск в Opensearch – в ответ возвращается десяток вариантов фамилий, имен, отчеств.

2. В дело вступает система постобработки:

3. Полученные варианты скорректированного ФИО, отсортированные от наиболее подходящих к наименее подходящим, возвращаются в API ответе. Далее разработчик бота может использовать их в сценарии – например, найти в медицинской системе первых трех кандидатов.

Специфика «грязной» базы и уникальность фамилий ограничили результат. И тем не менее, на тестовом корпусе удалось достичь более 25% взвешенной точности – система корректировала каждую четвертую ошибку. Это заметный рост относительно предыдущих решений.

Для сравнения:

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

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