Распознавание речи on-prem для протоколов звонков: требования

Что обычно хотят от протоколов звонков и почему это сложно

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

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

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

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

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

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

Входные данные: от качества записи до метаданных звонка

Качество протоколов звонков почти всегда упирается не в модель, а во входные данные. Для on-prem это особенно заметно: вы сами отвечаете за то, что попадает в контур, и «дотянуть данные потом» обычно сложнее.

В телефонии часто встречается узкополосный звук 8 кГц, моно, нередко в сильно сжатых форматах. Такой сигнал годится для общей сути разговора, но хуже передает окончания, имена и цифры. 16 кГц (широкая полоса) обычно дает заметно более точный текст, особенно на быстрых репликах и в шуме. Отдельно проверьте, не портит ли качество двойное перекодирование: запись в одном кодеке, затем конвертация на сервере, затем еще раз при выгрузке.

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

Разделение каналов часто снимает половину споров о качестве. Стерео с разнесением «оператор-абонент» полезно для точной атрибуции реплик и для ситуаций, когда говорят одновременно. Моно достаточно, если вам нужен общий текст без строгого авторства и обычно говорят по очереди.

Метаданные нужны не «для красоты», а для оценки качества, поиска и аналитики. Минимум, без которого метрики и выборки часто начинают врать: идентификатор звонка и время начала, направление (входящий/исходящий), очередь или линия (контекст), оператор или группа, а также технические признаки записи (частота, каналы, длительность, обрывы).

Пример: если не хранить признак «8 кГц моно», падение точности легко списать на ASR, хотя причина в том, что часть звонков стала писаться в более жестком сжатии после изменения АТС.

Метрики качества: как договориться о том, что «хорошо»

Самый частый спор в ASR-проектах начинается с вопроса: «Точность будет 95%?» Без уточнений это бессмысленно. Для протоколов звонков важны разные вещи: общий смысл, точность ключевых фактов и стабильность на реальных записях именно в вашей телефонии.

WER полезен, но один он не спасает

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

Поэтому к WER почти всегда добавляют метрики по «важным словам» (entities). Это то, что вы потом ищете, сверяете и используете в протоколе: ФИО, суммы, номера договоров, адреса, названия организаций и лекарств, модели оборудования.

О чем стоит договориться до пилота: WER по всей выборке и отдельно по сложным звонкам (шум, перебивания, плохая связь), точность и полнота по важным сущностям (например, доля правильно распознанных сумм и номеров, и сколько таких сущностей вообще найдено), доля «пригодных протоколов» (сколько текстов можно отдать в работу без ручной перепечатки) и время готовности протокола после звонка, если это влияет на процессы.

Пороги качества зависят от задачи

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

Качество нужно измерять на своей выборке, а не по «средней температуре» из демо. Соберите 1-2 часа звонков разных типов, разметьте эталон и разделите данные на группы по условиям записи. И заранее договоритесь, когда пересматривать метрики: после смены кодеков или АТС, обновления микрофонов, появления новых терминов. Иначе вы будете спорить не о качестве ASR, а о том, что именно поменялось в данных.

Словари и терминология: как сделать распознавание полезным

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

Что чаще всего ломает распознавание

Проблемные зоны обычно повторяются: ФИО (особенно редкие), география (районы, аулы, улицы), бренды и модели, аббревиатуры. Например, оператор говорит: «Передайте в ЦОН, по ИИН уточните», а в тексте появляется набор похожих слов. Дальше такой протокол уже не помогает найти нужный звонок.

Стартовый словарь лучше собирать не «из головы», а из ваших источников: выгрузки из CRM и тикет-систем (ФИО, компании, продукты), внутренние справочники (филиалы, города, подразделения), частотные слова из реальных звонков, список аббревиатур с расшифровками, перечень типовых оговорок и «стоп-слов».

Дальше понадобятся правила нормализации: как писать числа (12 или «двенадцать»), даты (01.02 или «1 февраля»), валюты и проценты, сокращения и склонения. Хорошая практика - хранить «как сказано» и «как должно быть в протоколе» отдельно.

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

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

Хранение аудио и текстов: срок, доступ, безопасность

В on-prem проектах хранение часто решает больше, чем сама модель распознавания. Аудио, расшифровка и метаданные становятся частью внутреннего контура, и к ним обычно применяются требования службы безопасности, юристов и ИТ.

Аудио и тексты можно хранить вместе или раздельно. Совместное хранение проще для поиска и разборов: в карточке звонка сразу есть и запись, и протокол. Раздельное хранение повышает контроль: аудио кладут в более закрытое хранилище, а текст и метаданные дают шире, например аналитикам. Минус - нужно надежно связывать объекты (ID звонка, хэш, контроль целостности) и следить, чтобы связка не ломалась при переносах.

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

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

Обезличивание лучше планировать заранее. В тексте можно маскировать номера, ИИН, адреса, e-mail, суммы. С аудио сложнее: «почистить» его без потери смысла удается редко, поэтому чаще ограничивают доступ и сокращают срок хранения, оставляя только нужные фрагменты.

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

Архитектура on-prem: из каких блоков состоит решение

On-prem распознавание речи удобно тем, что весь контур остается внутри закрытой сети. Но чтобы протоколы получались стабильно, полезно заранее разложить решение на понятные блоки и точки контроля.

Типовой поток выглядит так: запись разговора попадает из АТС или платформы контакт-центра в приемник, дальше проходит через очередь заданий, затем через модуль распознавания (ASR), после этого текст улучшается постобработкой и только потом сохраняется вместе с метаданными.

Чаще всего в решении есть пять частей: сбор аудио и метаданных, очереди и диспетчеризация задач (чтобы пики не «роняли» систему), ASR сервисы с моделями под ваш язык и домен, постобработка (пунктуация, разбиение на реплики, нормализация чисел, темы), хранилище и поиск с выгрузками для контроля качества.

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

Интеграцию с АТС и контакт-центром лучше продумать заранее: какие кодеки и частоты приходят, как передается второй канал (оператор и клиент), как формируются идентификаторы звонков, что делать с переводами и конференциями. Без этого легко получить «разъехавшиеся» метаданные: текст есть, а к какому звонку он относится, непонятно.

Нагрузку стоит закладывать с запасом. Пики бывают из-за сезонности, маркетинговых кампаний или роста штата. Например, в период массовых обзвонов система начинает копить очередь, и онлайн превращается в задержки. Чтобы рост не стал сюрпризом, заранее прикиньте максимальное число одновременных звонков, план на 6-12 месяцев, время обработки 1 минуты аудио на вашем железе, схему масштабирования (добавление ASR-узлов без остановки) и отдельные ресурсы для постобработки и индексации.

В закрытой инфраструктуре такой контур часто разворачивают на выделенных серверах в ЦОДе организации. Если нужен единый стандарт оборудования и поддержки, в качестве базы под ASR-узлы используют серверные платформы уровня GSE S200 Series.

Как подготовить требования и запустить пилот

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

Полезно собрать требования в короткий документ, который одинаково понимают бизнес, ИБ и ИТ:

• Сценарии и пользователи: кто читает протоколы (контроль качества, комплаенс, продажи, сервис) и какие решения принимает по тексту.
• Тестовый набор: 50-200 типовых звонков из разных линий, смен, регионов, с разным шумом и длиной.
• Критерии «что значит хорошо»: целевые метрики и список «важных слов» (продукты, ФИО, города, номера договоров).
• Хранение в закрытой сети: где лежат аудио и расшифровки, сколько хранить, кто и как получает доступ, как ведется аудит.
• Пилот в две итерации: сначала базовая модель, затем с подключенным словарем и правилами, чтобы измерить прирост именно от терминологии.

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

Если пилот идет в закрытой инфраструктуре, заранее согласуйте, как переносить тестовые данные, кто будет размечать ошибки и как быстро вы сможете пересобирать словарь. Размещение обычно делают на серверах и инфраструктуре заказчика. Если нужен интегратор, GSE.kz (gse.kz) может закрыть часть про серверы и системную интеграцию для on-prem сценариев, но критерии пилота все равно должны оставаться вашими и измеримыми.

Частые ошибки при внедрении в закрытой инфраструктуре

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

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

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

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

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

Пять вещей, которые стоит отловить заранее:

• успех меряют только WER и игнорируют полезность текста
• не следят за качеством записи и микрофонов
• обновляют словари без версий, тестов и отката
• хранят аудио без прав доступа и журналирования
• не закладывают ручную проверку для спорных звонков

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

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

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

1) Зачем вам протоколы звонков

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

2) Как вы меряете качество

Договоритесь о метриках и о тестовой выборке, на которой будете принимать решение. Выборка должна быть похожа на «боевую»: разные операторы, часы пик, плохая связь, несколько типов клиентов. Сразу решите, что важнее: общий процент ошибок или качество по ключевым сущностям (ФИО, суммы, даты, номера договоров).

3) Что считается «правильным» аудио

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

4) Словари и процесс обновлений

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

5) Хранение и доступ в закрытой сети

Заранее опишите сроки хранения аудио и текстов, роли доступа (операторы, контроль качества, безопасность), журналирование, резервное копирование и требования к шифрованию. Если у вас on-prem, уточните, где физически лежат данные и кто администрирует узлы.

Короткая проверка перед стартом:

• цели и сценарии использования сформулированы и приоритизированы
• метрики и тестовый набор согласованы, критерии приемки записаны
• форматы аудио и требования к записи закреплены в одном документе
• есть владелец словаря и понятный цикл обновлений
• прописаны хранение, доступ, бэкапы и правила безопасности

Пример сценария: как требования меняют итоговый результат

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

Первый запуск on-prem распознавания сделали «как есть»: взяли текущие записи, прогнали модель и получили тексты. В среднем читалось терпимо, но самое важное оказалось самым слабым. Фамилии путались («Кожахметов» превращался в «Кожа Ахметов»), суммы терялись («сто двадцать пять» распознавалось как «сто двадцать»), а внутренние кодовые слова продуктов превращались в обычные.

После этого требования переписали так, чтобы защищать именно «важные слова». Зафиксировали список терминов (продукты, города, типовые сокращения, кодовые слова), правила для чисел (суммы, проценты, номера договоров и заявок), формат имен (ФИО, инициалы, варианты произношения, частые ошибки) и приоритет качества по ключевым сущностям: ФИО, суммы, продукт, город.

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

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

Что сделать на этой неделе

Чтобы быстро продвинуться, не пытайтесь сразу «сделать идеальную систему». За неделю реально собрать требования и подготовить пилот так, чтобы потом не спорить о результатах.

Пять практичных шагов:

• Выберите 3-5 приоритетных сценариев (продажи, взыскание, техподдержка, внутренние согласования) и для каждого запишите, что именно должно появиться в протоколе: резюме, задачи, риск-фразы, причины отказа.
• Составьте список «важных слов»: продукты, услуги, города, фамилии, аббревиатуры, сленг. Хватит 50-200 терминов, но с примерами произношения.
• Проверьте качество записи на 20-30 реальных звонках: один канал или два, 8/16 кГц, есть ли шум, не обрезается ли начало. Сразу решите, в каком виде храните исходный аудиоархив.
• Прикиньте ресурсы для on-prem: сколько часов аудио в день, нужна ли обработка «почти в реальном времени», сколько параллельных потоков. Это быстро превращается в понятные требования к CPU/GPU, памяти и дискам.
• Запланируйте пилот на 2-3 недели: метрики, критерии приемки, расписание обновления словарей (например, раз в неделю).

Для пилота заранее соберите минимум данных: 1-2 часа звонков на каждый сценарий, согласованный способ обезличивания и простую разметку (где встречаются ключевые слова и как должна выглядеть итоговая заметка).

Если пилот требует серверов и интеграции в закрытом контуре, обсудите это заранее, чтобы не упереться в ограничения по размещению и поддержке. В таких проектах удобно, когда инфраструктура и интеграция собираются в один понятный контур: например, на серверной базе и с сопровождением от GSE.kz (gse.kz), особенно если параллельно нужны задачи системной интеграции, ЦОД или ИИ-инфраструктура.

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