Чому транскрибування дзвінків ламається на реальних записах
Відкриті моделі на кшталт Whisper на чистому студійному записі видають майже дослівний текст і створюють хибне відчуття, що завдання вирішено. На потоці з телефоції те саме розшифрування розмов перетворюється на кашу: уривки фраз, чужі імена, репліки, приписані не тому учаснику.
Перша причина — якість запису. Вузькосмуговий телефонний канал, відлуння, втрати пакетів і повторне стиснення зрізають верхні частоти, за якими якраз і розрізняються приголосні. Шумопридушення на боці АТС добиває тиху мову — і модель добудовує слово за змістом, а не за звуком.
Друга — накладення голосів і зміна мовця. Клієнт і оператор перебивають одне одного, розділення реплік за мовцями не встигає перемкнутися і склеює дві фрази в одну. На коротких «угу», «так-так», цифрах і адресах помилки розпізнавання накопичуються найшвидше.
Третя — галузевий сленг. Назви тарифів, артикули, абревіатури й номери договорів модель пише за фонетикою, а не за довідником. Без словника предметної області та постобробки такий текст не можна вантажити в облікову систему — його доведеться вичитувати вручну.
Четверта — сам архів. Якщо запис зведено в моно або зроблено диктофоном біля телефону, втрачене не відновить жодна модель. Тому ми починаємо з аудиту записів: чи писалися канали за сторонами розмови, що відбувається при стисненні, у яких місцях мова зникає зовсім. Далі — як це закривається на кожному рівні.
Що змінюється після впровадження: ефекти в робочих метриках
Перша метрика, яка зсувається, — частка розмов, які оператор більше не слухає вручну. Мова перетворюється на текст на льоту, і типовий запит закривається за розшифруванням: оператор читає потрібний фрагмент, а не прокручує запис повністю. Записи, до яких раніше не доходили руки, перестають бути мертвим вантажем.
Розбір накопиченого архіву перестає бути окремим проєктом. Пошук іде за репліками — за номером замовлення, назвою послуги, формулюванням скарги, — і вибірка за потрібний період збирається за хвилини замість днів прослуховування.
Індекс будується за всіма лініями одразу, тому інцидент розбирається за фактичними словами клієнта, а не за переказом.
Повнота картки звернення зростає завдяки вилученню сутностей з розшифрування: адреса, ідентифікатор замовлення, обіцяний строк, причина відмови. Поля заповнюються автоматично й залишаються перевірюваними — кожне значення прив’язане до фрагмента розмови.
Частка звернень з порожніми обов’язковими полями падає в рази, а спірний випадок розбирається за цитатою, а не з пам’яті.
Контроль якості змінює форму: перевіряльник працює не з тим, що встиг прослухати, а зі зрізом за всіма лініями. Знаходяться системні речі — скрипти, які оператори обходять, і теми, за якими клієнти повертаються повторно.
Покриття перевірками вимірюється часткою розмов, а не кількістю прослуханих годин, тому вибірковість перестає приховувати проблеми.
Транскрибування дзвінків: пакетний, потоковий, гібридний режим
Режим обробки вибирають не за обсягом архіву, а за тим, що потрібно в момент розмови: віддавати текст оператору одразу або розбирати запис після.
Пакетна обробка вивантажує записи з телефоції за розкладом і розшифровує пакетом, потокова передає звук на розпізнавання під час розмови, гібридний режим включає обидві гілки на різних лініях.
Різниця видна в затримці видачі. Потокове розшифрування віддає репліки через лічені секунди після їх завершення — це потрібно там, де підказка оператору або контроль скрипту працюють у реальному часі.
Пакетний режим відповідає за запис повністю: він переживає нічні піки, обриви зв’язку й повторно обробляє збійні файли, але результат приходить із затримкою в хвилини та години.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Пакетна обробка | Архів, звітність, розбір якості за зміну | Текст недоступний під час дзвінка, затримка видачі — від хвилин |
| Потокове розшифрування | Підказки оператору, контроль скрипту, тривожні сценарії | Потрібен стабільний канал і резерв: під час обриву ділянка розмови губиться |
| Гібридний режим | Контакт-центр, де частина ліній працює в реальному часі | Складніший у супроводі: дві гілки обробки й наскрізна звірка результатів |
Вибір упирається у дві величини: скільки розмов іде одночасно і через скільки після дзвінка текст має опинитися в CRM.
Результати обох гілок зводимо в одне сховище з розміткою каналів, мовців і часу реплік — на відкритих моделях розпізнавання на кшталт Whisper аудіо й текст залишаються на вашій стороні.
Якщо частина ліній потребує реального часу, а частина — лише звітності, гібридний режим знімає необхідність тримати дві системи.
Як ми впроваджуємо: аудит, схема, налаштування, перевірка, передача
Транскрибування починається не з вибору моделі, а з розбору того, що вже записано. На реальному масиві дзвінків видно частку перекриттів мови, шум контакт-центра, діалекти, сленг і якість каналу — ці дані й задають схему обробки. Нижче — послідовність кроків від першого прослуховування до передачі в експлуатацію.
- Аудит записів. Беремо вибірку за різними лініями, операторами й типами звернень, рахуємо частку мови, перекриття й нерозбірливі фрагменти. Результат — звіт з оцінкою досяжної точності та списком проблемних груп.
- Схема обробки. Вирішуємо, де стоїть розпізнавання: потоком під час розмови або після його завершення. Фіксуємо розділення мовців, формат видачі з відмітками часу, строки зберігання й зв’язок тексту із записом в обліковій системі.
- Налаштування словників. Доповнюємо базовий лексикон назвами продуктів, посад, скороченнями й типовими помилками з аудиту. Для двомовних ліній налаштовуємо перемикання мови всередині фрази, версії словників зберігаємо для відкату.
- Підключення до джерела. Забираємо записи із системи, налаштовуємо чергу й повтори при збоях, розмежовуємо доступ: текст дзвінка доступний лише тому, хто має право на сам запис.
- Приймання якості. Прогоняємо вибірку, яка не брала участі в налаштуванні, і звіряємо з ручним розшифруванням за часткою правильних слів і ключових сутностей — номерів, адрес, числових значень. Поріг погоджуємо заздалегідь і фіксуємо в протоколі.
- Передача в експлуатацію. Віддаємо регламенти, схему, словники, інструкції для підтримки й панель із якістю за днями; перший тиждень супроводжуємо й розбираємо відхилення.
Комплект постачання: конфігурації, схеми й регламенти
Комплект постачання — це не папка з файлами, а робоча система, яку ваша команда веде самостійно після здачі. Конфігурації правляться без нас, схеми пояснюють, де що тече, регламенти визначають поведінку при збої.
Кожен артефакт віддаємо у форматі, який ви підтримуєте власними силами, — без закритих редакторів і нотаток «зрозуміло лише автору».
- Конфігурація системи — параметри підключення до телефоції, черга обробки, пороги впевненості розпізнавання, строки зберігання записів і розшифровок. Значення винесені окремо від коду: змінити правило можна без перезбирання й релізу.
- Схема потоків даних — шлях дзвінка від запису до готового розшифрування: де лежить аудіо, на якому кроці вмикається розпізнавання, які перевірки проходить текст, куди йде результат.
- Словник термінів — назви продуктів, відділів, посад, абревіатури й імена, які без словника чуються неправильно. Поповнюється на ходу, без перенавчання.
- Документація на систему — склад сервісів, точки інтеграції із системою обліку клієнтів і сховищем, формати вивантаження, змінні середовища, порядок оновлення.
- Регламент експлуатації — що робити при недоступності телефоції або сервісу розпізнавання, як перезапускати чергу, як перевіряти затримку обробки й повноту вивантаження, кому повідомляти про збій.
- Методика контролю якості — еталонна вибірка дзвінків, порядок заміру частки помилок, правила перегляду словників і критерії, за яких розпізнавання вважається деградованим.
Комплект приймаємо разом: ваші інженери піднімають систему на тестовому контурі за нашою документацією. Якщо крок не описаний або описаний так, що потребує дзвінка автору, — це наш недолік, і ми його закриваємо.
Кейс контакт-центра: точність розшифрування до і після
Контакт-центр вхідної підтримки — близько чотирьох тисяч дзвінків на добу, шістдесят операторів на лінії.
Розшифрування йшло нічною пакетною обробкою на загальній моделі: частка помилок у словах трималася на 28–34%, тому запис годився лише на те, щоб «зрозуміти, про що взагалі була розмова».
Окремий біль — числові й термінологічні сутності. Номери договорів, коди помилок, назви тарифів модель видавала випадковим набором символів, і все, де потрібна точність, оператор вбивав в облікову систему руками. Контроль якості був вибірковим: 10–12 записів на прослуховування на день, менше ніж 0,3% розмов.
Що зробили
Зібрали окремий контур розпізнавання: потокове розшифрування на Whisper з донавчанням на архіві записів самого контакт-центра, словник сутностей під продукт — тарифи, коди, імена — і нормалізація номерів і дат до подачі в модель. Додали розділення за мовцями: репліки прив’язані до конкретного учасника, а не злиті в один потік.
Що змінилося в цифрах
Частка помилок у словах — 6–9% на чистому каналі та 12–14% на шумних записах із мобільних. Ручна вичитка скоротилася з кожної розмови до вибіркової, приблизно кожна двадцята.
Пішов цілий клас помилок: цифри, коди й назви сервісів більше не губляться, спірні нарахування розбираються за цитатою з дзвінка, а не з пам’яті оператора. Суцільний контроль якості зріс з 0,3% до 100% розмов — без розширення штату відділу.
Що робити, якщо архів записів зберігається у старому форматі
Успадкований архів телефонних записів майже ніколи не однорідний. Частина файлів стиснута вузькосмуговими телефонними кодеками (G.729, GSM, адаптивна багатошвидкісна), частина — уже перекодовані копії, частина — потоки без коректного заголовка з розширенням .wav.
Розширенню й метаданим вірити не можна: формат визначається за сигнатурою й результатом пробного декодування.
Ключове правило при перекодуванні — допустити рівно одну втрату за всю історію запису. Стиснений потік декодується один раз у майстер-копію без втрат, і вся повторна обробка йде вже від майстер-копії.
Якщо запускати транскрибування дзвінків від джерела й зберігати проміжні результати у стиснений формат, артефакти накопичуються: шум передбачення, «дзвін», з’їдені приголосні — модель починає плутати близькі за звучанням слова.
Підвищення частоти дискретизації не повертає інформацію, якої у вузькосмуговому записі немає. Корисніше подати її в модель, навчену на телефонному каналі, ніж роздувати до широкосмугової: точність та сама, обсяг і час обробки вищі.
Окремо лікуються дефекти тракту — перевантаження за рівнем, робота автоматичного регулювання підсилення, обриви, — інакше вони дають хибні спрацювання на репліках.
Міграція архіву будується як ідемпотентний процес. Спочатку паспортизація: за кожним файлом фіксуються кодек, тривалість, число каналів, цілісність. Потім контрольні точки за записами — перерваний на середині прохід не змушує починати заново й не створює дублів.
Оригінали зберігаються до звірки з журналом комутатора й системами обліку: так виявляються розмови, помилково прив’язані до іншого абонента.
Технічні сумніви, які знімаємо до старту робіт
Перед стартом технічна сторона замовника зазвичай перевіряє не саму ідею розшифрування, а її стик з інфраструктурою: де фізично лежать записи, що йде за периметр, як система поводиться на їхній лексиці й що буде, якщо якість виявиться нижчою за очікувану. Нижче — відповіді на те, що найчастіше спливає на етапі погодження.
Де розміщується система і чи залишають записи наш контур?
Розгортаємо в контурі замовника на його потужностях або у виділеному контурі в обраному регіоні — аудіо не надсилається в зовнішні сервіси розпізнавання.
Доступ до записів і текстів розмежовано за ролями, звернення до сховища потрапляють у журнал, а фрагменти на кшталт номерів карток і паспортних даних вирізаються до збереження розшифрування.
Як система дає раду нашій лексиці — назвам продуктів, артикулам, іменам?
Базове розпізнавання працює з першого дня, але доменну лексику підтягуємо окремо: збираємо словник термінів і абревіатур, додаємо його в модель і перевіряємо на розміченій вибірці реальних дзвінків. Зазвичай достатньо двох-трьох ітерацій, щоб артикули й назви перестали розпізнаватися за складами.
Що вважається успіхом пілота і як ви це вимірюєте?
Рахуємо частку помилок у словах і в ключових сутностях — номерах замовлень, числових значеннях, датах — на відкладеній вибірці, яку не використовували при налаштуванні.
Плюс окремо дивимося, скільки дзвінків потрібно дорозмічувати вручну: якщо їхня частка падає в рази відносно ручного розшифрування, завдання вирішено.
Що буде, якщо якість не влаштує?
Запускаємо в тіньовому режимі: система розшифровує потік паралельно з поточним процесом, результати звіряються, але нічого не замінюють. Перемикання робимо частками трафіку — від одного каналу до решти, з можливістю повернути ручну обробку в будь-який момент.
Що потрібно від нас, щоб стартувати, і скільки це займе?
Потрібні доступ до записів дзвінків за минулий період, розуміння, як вони зберігаються, і один контакт із боку телефоції. На цих даних налаштовуємо словник і метрики, далі — тіньовий прогін і поступове включення. Обговоримо ваше завдання — повернемося з оцінкою й планом за етапами.
Обговоримо завдання і повернемося з оцінкою та планом
Щоб повернутися з оцінкою проєкту й планом впровадження, не потрібен об’ємний бриф — достатньо одного розбору з вашим інженером або керівником напряму.
Нас цікавить, де зараз лежать записи дзвінків, як влаштована телефоція і куди має потрапляти готовий текст: в облікову систему, сховище або окремий інтерфейс для контролю якості. Цього достатньо, щоб побачити вузькі місця до початку робіт.
У відповідь ви отримуєте документ, за яким можна ухвалювати рішення без додаткових уточнень:
- схему потоку: від запису в телефоції до тексту у вашій системі, з місцями зберігання аудіо й розшифровок;
- вимоги до якості: цільова частка правильно розпізнаних слів, точність розділення за мовцями, словник термінів, назв і імен;
- план впровадження за етапами: пілот на одному відділі, замір якості на реальних дзвінках, розширення на решту ліній;
- перелік даних і доступів із вашого боку та відповідального, хто приймає результат етапу;
- політику роботи з персональними даними: де зберігається аудіо й текст, строки зберігання, видалення на запит;
- оцінку проєкту: трудозатрати за етапами та склад підтримки після запуску;
- критерії приймання — що саме вважаємо працюючим рішенням.
Наступний крок — опишіть завдання: скільки ліній і дзвінків на місяць, яка телефоція, що робите з розшифровками зараз. Повернемося з оцінкою та планом впровадження.
