Разработка AI-системы транскрибации с API под ключ

Почему API транскрибации сбоит на реальных записях

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

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

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

Всё это не экзотика, а штатное поведение сервиса, собранного без подготовки входного звука, без контроля очереди и без проверки результата на согласованность. Разбираем, как это закрывается на уровне архитектуры решения.

Что меняется после внедрения: скорость, качество, отказоустойчивость

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

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

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

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

Наружу это видно как стабильный API: приходит ссылка на запись, возвращается текст, таймкоды и статус обработки.

Режимы API транскрибации: пакетный, потоковый и гибридный

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

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

Гибридный режим оправдан, когда требования к данным различаются по каналам. Тогда словари и разметка ведутся одинаково, а маршрут записи задаётся политикой, а не правкой кода в момент запуска.

Как мы внедряем систему: этапы инженерной работы

Работа идёт итерациями: сначала разбираемся с реальными записями, потом собираем интеграцию, и только после этого настраиваем поведение системы под нагрузкой. Ниже — последовательность, по которой мы ведём проекты транскрибации с API.

1. Аудит аудиоданных. Берём выборку из архива заказчика и слушаем её: сколько каналов, уровень фонового шума, доля перекрывающейся речи, какие языки и профессиональный жаргон встречаются. На выходе — требования к качеству распознавания, профиль нагрузки и перечень записей, на которых система будет проверяться.
2. Схема интеграции. Определяем, как записи попадают в систему: событие от телефонии, выгрузка из хранилища или загрузка через интерфейс. Фиксируем формат ответа API — посегментные метки времени, разметка спикеров, оценка уверенности по каждому фрагменту.
3. Настройка очередей. Записи приходят неравномерно, поэтому разводим их по приоритетам: короткие обращения обрабатываются сразу, длинные совещания уходят в отдельную очередь. Здесь же задаём повторные попытки и предел параллельных задач, чтобы пиковая нагрузка не роняла обработку.
4. Адаптация под домен. Движок Whisper даёт хорошую базовую точность, но названия продуктов, фамилии и внутренние сокращения он слышит неверно. Добавляем словари терминов и правила постобработки, проверяем эффект на контрольной выборке.
5. Приёмочные проверки. Считаем долю слов с ошибкой и ошибку по ключевым сущностям, сверяем таймкоды и разделение спикеров с эталонной расшифровкой. Фиксируем пороги, ниже которых результат не принимается, и только после их прохождения идём дальше.
6. Передача в эксплуатацию. Отдаём документацию по API и схему интеграции, настраиваем мониторинг очередей и ошибок распознавания, проводим обучение команды заказчика и договариваемся о регламенте дообучения словарей.

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

Артефакты внедрения: схемы, конфигурации, регламенты

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

• Документация по интеграции — сценарии «загрузил запись → получил текст», обработка длинных файлов, поведение при обрыве соединения и повторной отправке.
• Описание методов API транскрибации: параметры запроса, структура ответа, коды ошибок и что делать клиенту при каждом из них.
• Схема развёртывания — где живут сервис распознавания, очередь и хранилище записей, как контур масштабируется при пиковой загрузке и что происходит при отказе узла.
• Конфигурации обработки: выбор языка и диаризации, пунктуация, пороги уверенности, размер батча и правила повторных попыток.
• Политики доступа — роли и ключи с ограниченным сроком жизни, привязка к источнику запроса, журнал обращений к расшифровкам.
• Регламент эксплуатации: какие метрики смотреть ежедневно, какая доля отказов считается нормой, когда перезапускать обработку вручную, а когда ждать автовосстановления.
• Инструкции для службы поддержки — разбор типовых обращений по расшифровке, что закрывается на первой линии и что эскалируется инженерам.
• Порядок обновления моделей: прогон новой версии на отложенной выборке записей заказчика, критерии приёмки и точка возврата к предыдущей.

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

Кейс: контакт-центр сократил ручную правку расшифровок в шесть раз

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

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

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

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

Чем отличается потоковая расшифровка от пакетной?

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

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

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

Выбор режима — про сценарий, а не про «мощность». Живые субтитры, контроль качества разговора, подсказки оператору — поток. Разбор звонков, интервью и архива — пакет. Оба режима держим за одним API: общий контракт на файл и на поток, единая авторизация и уведомления о готовности результата.

Сомнения по нагрузке, приватности и качеству данных

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

Где хранятся записи и кто к ним имеет доступ?

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

Как распознаются отраслевые термины — артикулы, названия препаратов, юридические формулировки?

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

Как результат попадает в наши учётные системы?

Транскрипт забирается через API транскрибации: система сообщает о готовности записи событием, ваша сторона получает текст, структурные поля и метрики. Схему соответствия сущностям учётной системы согласуем до старта, поэтому ручная выгрузка не нужна.

Обсудим задачу: что стоит подготовить к первому разговору

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

• Образцы записей: 5–10 файлов из реальных каналов, включая худшие — с шумом, несколькими говорящими, обрывками связи. По ним видно, нужна ли подготовка звука и какая точность достижима.
• Сценарий использования: дословный текст, протокол встречи с разделением по спикерам или выжимка с ключевыми решениями и задачами.
• Требования к интеграции: куда уходит результат — в вашу систему или хранилище, нужен ли ответ в реальном времени или подойдёт отложенная обработка.
• Объём и пики: сколько часов записи приходит в сутки и как распределена нагрузка — от этого зависит масштабирование и схема очереди.
• Правила работы с данными: можно ли выносить записи во внешнюю среду, сколько хранить исходники, у кого доступ к расшифровкам.
• Критерии приёмки: что считаем результатом — доля верно распознанных слов, точность разделения спикеров, время обработки часовой записи.
• Ваша инфраструктура: есть ли сервис, с которым нужно стыковаться, кто на вашей стороне принимает результат и проверяет качество.

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