Почему распознавание казахской речи ломается на смешанных фразах

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

Что такое переключение кодовF

Лингвисты называют это code-switching — переключение между языками внутри одного высказывания. В Казахстане это не исключение, а норма разговорной речи: человек начинает вопрос по-казахски, называет продукт или сумму по-русски и заканчивает мысль снова по-казахски. Переключение может происходить между предложениями, а может — внутри одной именной группы.

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

Почему на этом ломаются обычные модели

Типовая ASR-система устроена вокруг допущения, что у аудиофрагмента есть один язык. Это допущение зашито в несколько мест сразу.

Определение языка идёт до распознавания. Многие пайплайны сначала классифицируют язык куска аудио, а потом отдают его в соответствующую модель. На смешанной фразе классификатор вынужден выбрать один вариант — и вторая половина фразы попадает в модель, которая её слов не знает.

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

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

Почему это бьёт по бизнес-задачам сильнее, чем по метрикам

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

Названия продуктов, суммы, сроки, названия банков и тарифов, слова из скрипта продаж — всё это чаще всего произносится на «втором» языке фразы. То есть именно там, где модель уже переключилась не туда. Система показывает приличную общую метрику и при этом систематически теряет то, что нужно искать в разговоре.

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

Что с этим можно делать

Рабочих направлений три, и они не исключают друг друга.

Убрать раннюю классификацию языка. Модель должна работать по смешанному словарю и допускать переключение внутри фразы, а не выбирать язык заранее.

Обучать на смешанной речи. Не на сумме двух одноязычных корпусов, а на записях, где переключение действительно происходит — с ручной выверкой расшифровок.

Дообучать под домен заказчика. Названия продуктов, тарифов и внутренних процессов — это закрытый список слов, который можно передать модели явно. Больше всего качества на бизнес-задаче даёт именно этот шаг, потому что бьёт точно по тем словам, на которых считаются метрики бизнеса.

Почему это вопрос ещё и юрисдикции

Есть отдельное соображение, не техническое. Записи разговоров с клиентами — это персональные данные, а часто ещё и банковская тайна. Отправлять их в зарубежное облако ради распознавания означает выносить их за периметр организации и за пределы правового поля Казахстана.

Поэтому мы делаем движок, который разворачивается внутри контура заказчика: модель приезжает к данным, а не данные к модели. Что это означает на практике для контроля качества обслуживания, разобрано на странице AI Supervisor, а посчитать экономику внедрения на своей конфигурации можно в ROI-калькуляторе.