Розробка STT: чому пілот не доживає до експлуатації
Пілот на чистих записах із переговорної дає точність розпізнавання мовлення понад 90%, а через місяць на реальному трафіку вона просідає до 65–70%.
Шумні канали, вузькосмуговий телефонний тракт, ехо та перекриття мовлення двох мовців ламають акустику сильніше, ніж будь-який акцент у студійному записі. Виправляти це фільтрами постфактум пізно — рішення ухвалюється на етапі підготовки даних і вибору моделі.
Доменна лексика добиває результат точково. Артикули, назви препаратів, абревіатури підрозділів і прізвища базова модель упевнено замінює на схожі за звучанням слова, і такий текст іде далі по процесу як валідний.
Закривається це не «донавчанням на всьому підряд», а словником вимов, мовною моделлю на профільному корпусі та розміткою саме тих сутностей, які потрібні бізнесу.
Затримка на потоці — окрема точка відмови. Якщо рушій чекає закінчення файлу і лише потім віддає текст, діалог з оператором розпадається на паузи; інженери ріжуть потік на вікна і платять за це зростанням помилок на стиках.
Тому розбір у реальному часі та обробка архіву проєктуються як два різні режими з різними вимогами до якості й швидкості.
І останнє — повторна обробка архіву. Кожна нова версія моделі знецінює раніше розшифроване: щоб підняти якість, накопичені години доводиться переганяти заново, а це навантаження на обчислювальні ресурси та строки.
Планувати це заздалегідь — означає версіонувати моделі, роздільно зберігати вихідне аудіо та ознаки і розуміти, які записи справді потрібно переробляти. Розбираємо, як ці точки закриваються на етапі проєктування.
Що дає налагоджений контур розпізнавання мовлення
Якість розпізнавання не можна оцінювати за демо-записом: на реальних дзвінках з'являються шум, перекриття мовлення та галузеві терміни, яких немає в загальному словнику.
Налагоджений контур тим і відрізняється, що метрики знімаються на тому самому аудіо, з яким працює замовник, а не на студійному корпусі.
Другий шар — поведінка під навантаженням: скільки чекає перший фрагмент, що відбувається при обриві зв'язку, як розділяються голоси учасників.
Моделі ми донавчаємо під предметну область, включно з відкритими на кшталт Whisper, і віддаємо результат потоком, а не пачкою після завантаження файлу.
| Показник | Без налаштування контуру | Після налаштування |
|---|---|---|
| Частка помилок на реальних записах | 15–25% на розмовних дзвінках із шумом і акцентом | 4–8% на тому самому корпусі, терміни зі словника замовника розпізнаються стабільно |
| Час відгуку | запис накопичується й розшифровується повністю після завантаження | перший фрагмент надходить у межах секунди, решта — у міру мовлення |
| Ручна перевірка розшифровок | суцільна вичитка всіх записів | вибіркова звірка лише фрагментів із низькою впевненістю моделі |
| Стійкість до обривів | втрата сесії, запис доводиться починати заново | контрольні точки й довантаження: сесія продовжується з останнього підтвердженого фрагмента |
Сумарно змінюється не одна цифра, а зниклий клас відмов: розшифрування перестає бути завданням «на ранок» і не розсипається при збої зв'язку. Оператор дивиться не весь текст, а позначені місця — звідси й кратне скорочення обсягу ручної роботи.
Розробка STT: варіанти архітектури та їхні обмеження
Вибір між орендованим сервісом, власним контуром і гібридною схемою — це не спір про точність розпізнавання.
На одній і тій самій акустиці підходи дають близькі цифри, а розходяться вони за трьома осями: де фізично лежить аудіо, який потік треба тримати в пік і хто відповідає за якість на доменній лексиці — назвах препаратів, артикулах, внутрішніх абревіатурах.
Головна розвилка — обмеження щодо даних. Якщо в записі звучать клієнти, а разом із ними медичні або юридичні деталі, передавання потоку на сторону потребує знеособлення на льоту, і часто саме це вирішує на користь власного контуру.
Зворотний випадок — рідкісна мова, якої немає у власній моделі: тут оренда закриває завдання одразу, без місяців розмітки.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Орендований сервіс | Швидкий старт, багато мов, пікові навантаження без власних потужностей | Аудіо йде назовні, витрати зростають лінійно з хвилинами, тонке налаштування на домен недоступне |
| Власний контур | Вимоги до захисту даних, стабільний обсяг, закрита мережа | Довгий вихід у продукт, власні сервери з прискорювачами, якість залежить від обсягу розмічених записів |
| Гібридна схема | Чутливе обробляється локально, рідкісні мови й важкі завдання йдуть в оренду | Дві підсистеми в моніторингу, складніша маршрутизація та версіонування моделей |
Практичний критерій вибору — не середня точність, а частка помилок на найдорожчих сценаріях: номерах замовлень, сумах, адресах. Ми збираємо тестовий набір із реальних записів замовника, проганяємо через усі три варіанти і показуємо, де саме розходяться результати.
Порядок робіт: від аудиту записів до передачі контуру
Починати з вибору рушія розпізнавання — типова помилка: якість визначається не моделлю, а станом записів і тим, наскільки контур ураховує умови домену. Тому етапи йдуть послідовно, і кожен спирається на артефакти попереднього.
- Аудит записів. Беремо вибірку з реальних каналів — дзвінки, зустрічі, диктування — і розмічаємо проблеми: шум, ехо, накладення реплік, вузькосмугові лінії, спонтанне мовлення, частка доменних термінів. На виході карта умов і розуміння, які класи записів узагалі підлягають автоматизації.
- Схема контуру. Фіксуємо потік: джерело, передобробка (придушення шуму, детекція мовлення, розділення спікерів), розпізнавання, післяобробка (пунктуація, числа, словник термінів), видача в цільову систему. Окремо описуємо точки відмови та поведінку при недоступності зовнішніх вузлів.
- Налаштування під домен. Збираємо словники термінів, абревіатур і назв, налаштовуємо мовну модель на доменну лексику, за потреби донавчаємо акустичну частину на розмічених фрагментах з аудиту.
- Перевірка на відкладеній вибірці. Якість підтверджуємо на корпусі, який не брав участі в налаштуванні, і в розбивці за підгрупами: канал зв'язку, рівень шуму, темп мовлення, щільність термінів. Середня цифра по всьому корпусу приховує провали на окремих групах — а в роботі важливі саме вони.
- Приймання за метриками. Фіксуємо пороги за підгрупами, а не загальний відсоток: де автоматизація віддає результат одразу, де потрібен другий прохід або позначка «на перевірку оператору».
- Передача контуру й навчання команди. Передаємо схему, регламент перенавчання при зміні лексики, панель метрик і порядок розбору інцидентів, проводимо навчання інженерів та операторів.
На виході замовник отримує працюючий контур, документацію та команду, яка може розвивати його без нас. Опишіть завдання — повернемося з оцінкою та планом за етапами.
Комплект постачання: конфігурації, схеми та регламенти
Інженерний результат проєкту — це не лише працюючий сервіс розпізнавання мовлення, а й комплект артефактів, за яким його можна розгорнути, перевірити й розвивати силами своєї команди. Усе передаємо в репозиторії разом з інструкцією з розгортання контуру на чистій інфраструктурі.
- Конфігурація контуру — декларативний опис сервісів розпізнавання, черг, балансування та правил автомасштабування: контур піднімається з конфігурації, а не збирається руками.
- Схема потоків даних — шлях аудіо від приймання до видачі тексту: точки буферизації, місця повторної обробки, кроки, на яких запис видаляється.
- Політики доступу — ролі сервісів, ключі, мережеві обмеження та правила поводження із записами: строки зберігання й маскування чутливих полів.
- Моделі та профілі розпізнавання — зафіксовані набори ваг, доменні словники й налаштування під різні канали: телефон, мікрофон, потік наради.
- Набір перевірок якості — тестові фрагменти з еталонними розшифровками та метриками: частка помилок у словах і в іменованих сутностях за кожним сценарієм.
- Регламент супроводу — порядок оновлення моделей, контроль навантаження, сигнали моніторингу з порогами й умови відкату на попередній набір ваг.
- Інструкції для команди — як підключити новий канал, поповнити словник термінів, розібрати інцидент і передати зворотний зв'язок щодо помилок.
Кейс: розпізнавання дзвінків у контакт-центрі до і після
Контакт-центр на кілька десятків операторів обробляє тисячі дзвінків на добу, і кожен запис потрібно перетворити на зрозумілу картку звернення. До перебудови розшифрування йшло одним потоком: без розділення каналів, нормалізації звуку та розмітки за ролями.
Оператор отримував суцільний текст і правил його вручну, а супервізор оцінював якість на слух за десятком записів на тиждень.
Що перебудували в контурі
Контур розбили на етапи: приведення звуку, виділення мовлення, розпізнавання, розмітка за ролями, витяг сутностей. За основу взяли Whisper в актуальній гілці й донавчили на записах замовника, додавши словник назв товарів, адрес і типових формулювань.
Розпізнавання зробили асинхронним: розшифровка надходить до оператора раніше, ніж він відкриває картку.
Частка помилок на ключових сутностях упала з 28% до 7%. Частка розшифровок, які оператор приймає без правок, зросла з 59% до 88%, а час обробки звернення скоротився з дев'яти хвилин ручного заповнення до півтори хвилини перевірки. Понад половину звернень розбираються автоматично й ідуть у звітність без участі людини.
Побічний ефект — контроль якості: супервізор бачить вибірку по всіх дзвінках, а не по десяти на тиждень, і спірне звернення розбирається за розшифровкою. Моделі версіонуються, тому при падінні точності на новому сегменті дзвінків є куди відкотитися.
Чим потокова обробка відрізняється від пакетної
Різниця не в моделі, а в контракті на видачу. Потокова обробка віддає проміжні гіпотези в міру надходження звуку і зобов'язана закрити фразу за частки секунди після паузи; пакетна обробка бере готовий файл цілком і може дозволити собі кілька проходів.
Звідси різні вимоги до стійкості: у потоці збій каналу рве діалог, в архіві запис просто йде в кінець черги.
Режим реального часу потрібен там, де результат впливає на поточну дію: підказки оператору, онлайн-контроль якості розмови, субтитри до ефіру, маршрутизація дзвінка в потрібний відділ.
Тут усе підпорядковано затримці: аудіо ріжеться на короткі вікна з перекриттям, проміжні версії тексту уточнюються в міру накопичення контексту, модель рахує за сегментами. Точність на коротких фразах нижча, ніж при повному проході, і це усвідомлений розмін, а не дефект.
Пакетна обробка йде за архівом: записи дзвінків, зустрічей, диктофонних нотаток. Матеріал є цілком, тому застосовуються нормалізація рівня, розмітка мовців, повторне розпізнавання сумнівних ділянок і словник термінів предметної області.
Затримка вимірюється хвилинами, зате пропускна здатність планується заздалегідь — нічні вікна, черга, повторні прогони після оновлення моделі.
Поєднують обидва режими на спільній основі: один набір моделей, єдиний шар нормалізації тексту й словників, але різні вхідні адаптери та різні черги. Тоді покращення словника або моделі переноситься одразу в обидва потоки, а результати можна звіряти між собою.
Вибір диктує допустимий відгук і частка сценаріїв, де відповідь потрібна в момент мовлення, — усе інше дешевше й точніше гнати архівами.
Сумніви щодо якості, даних і навантаження
Перед стартом майже завжди спливають ті самі п'ять сумнівів: чи витримає система шумні записи, чи можна донавчати її, не вивозячи дані за периметр, чи реально налаштувати розпізнавання на своїй термінології, що буде в пікове навантаження і як потім без втрат змінити підрядника.
Жодне з них не закривається обіцянками — під кожен пункт закладається конкретний інженерний механізм, який вимірюється на ваших записах до початку промислової експлуатації.
Нижче — короткі відповіді без маркетингу: що робимо, чим вимірюємо і де проходять межі застосовності. Відкриті моделі рівня Whisper задають базову якість, але на шумних каналах результат витягують підготовка даних і схема видачі результату, а не сам рушій.
Шумні записи: зв'язок, офіс, вулиця — якість просяде?
Аудіо приводимо до єдиного формату, ріжемо за спектром і додаємо контрольований шум під час навчання.
Частка впевнено розпізнаних фраз на записах з ехом і фоновою розмовою зростає на десятки відсотків відносно базової моделі, а сумнівні ділянки позначаються для вибіркової перевірки оператором.
Дані не можна вивозити за межі контуру — це можливо?
Так: розгортаємо весь тракт розпізнавання на вашій інфраструктурі, навчання йде на знеособлених вибірках усередині периметра. Назовні йдуть лише агреговані метрики якості та звіти про помилки — без самих записів і розшифровок.
Донавчання на своїй термінології
Збираємо словник назв, абревіатур і предметних термінів, донавчаємо акустичну та мовну частини на ваших розшифровках. Це помітно знижує кількість помилок на рідкісних словах, а словник залишається редагованим — нові терміни додаються без перенавчання всієї системи.
Пікове навантаження
Потокові запити йдуть із пріоритетом, решта потрапляє в чергу; обчислювальні потужності масштабуються за глибиною черги. Сплеск у рази вищий за середній призводить до затримки відкладеної обробки, а не до відмов і втрачених записів.
Зміна підрядника — чи залишимося ми заручниками?
Конфігурації, словники, адаптери та розмітка — ваші, вони лежать у вашому репозиторії разом із чек-лістом розгортання. Перехід до іншої команди займає дні: розгортається той самий контур, відтворюються метрики, робота продовжується з накопиченими даними.
Обговоримо ваше завдання розпізнавання мовлення
Оцінка проєкту з розпізнавання мовлення не збирається із загальних слів — вона тримається на ввідних. На першій розмові уточнюємо, звідки йде звук: телефонія, мікрофони в залі, записи зустрічей, скільки каналів потрібно вести паралельно.
І домен зі словником: імена, артикули, терміни, які розшифровка зобов'язана писати правильно, плюс вимоги до затримки, якщо текст потрібен під час розмови.
Окремо розбираємо шум, перекриття мовлення та якість архіву записів: за цими ввідними видно, де потрібне донавчання на ваших даних, а де достатньо налаштування мовної моделі та правил післяобробки.
За підсумками розмови надсилаємо:
- план робіт за етапами — від підготовки й розмітки записів до перевірки на відкладеній вибірці та введення в експлуатацію;
- схему потоку: приймання аудіо, передобробка, розпізнавання, нормалізація тексту (пунктуація, числа, імена), видача результату у вашу систему;
- оцінку проєкту: склад команди, тривалість етапів і те, що потрібно з вашого боку — доступи, записи, погодження;
- цільові метрики: частка помилок у словах, точність на іменах і термінах, допустима затримка видачі;
- варіанти розміщення: у вашому контурі або на виділених потужностях, із розрахунком навантаження на кількість одночасних каналів.
Старт проєкту — після погодження плану й метрик: фіксуємо етапи, точки контролю та порядок приймання. Давайте обговоримо завдання — повернемося з оцінкою та планом робіт.
