Розробка AI Speech Analytics для аналізу дзвінків: STT, NLP, комплаєнс

Розробка AI speech analytics: де ламається аналіз дзвінків

Записи в контакт-центрі накопичуються роками: архів зростає, терміни зберігання дотримуються, а розібрати цей обсяг нічим.

Контроль якості дзвінків тримається на ручному прослуховуванні — супервайзер за зміну встигає оцінити кілька десятків діалогів, а решта тисяч залишаються без оцінки й без жодного висновку.

Ціна такого підходу видна не відразу. Інциденти — грубість оператора, обіцянка нездійсненного терміну, обхід обов’язкової фрази — спливають лише після скарги, коли виправляти пізно.

Розбір діалогів перетворюється на пошук голки в сіні: потрібний фрагмент спершу шукають у вивантаженні з телефонії, потім вручну переслуховують.

Окрема проблема — розрізненість. Записи лежать в одній системі, розшифровки — в таблицях, оцінки — в особистих нотатках супервайзера, і звести це в загальну картину не виходить.

Мовленнєва аналітика в такому вигляді не відповідає ні на питання про причини звернень, ні на питання, де просідає конкретна команда.

Розробка AI speech analytics починається з того, що аналіз дзвінків перестає бути ручною операцією.

Розпізнавання мовлення в контакт-центрі працює як конвеєр: запис автоматично потрапляє в обробку, розділяється за ролями учасників, приводиться до тексту з урахуванням термінів і назв.

Далі за розшифровкою працюють правила й моделі — від обов’язкових фраз до ознак вигорання в операторів.

Нижче розбираємо, як це закривається: від доступу до записів і словників термінів до звітів, за якими керівник бачить динаміку за командами й темами звернень.

Ефект впровадження: якість розпізнавання та розбір відмов

Ефект впровадження вимірюємо замірами, а не відчуттями: до старту знімаємо базові значення за архівом, після введення в роботу повторюємо на тому самому зрізі.

Так видно, де система реально знімає навантаження зі служби контролю, а де потрібне доналаштування сценаріїв і словників.

• Повнота розбору архіву. Ручне прослуховування закривало одиниці відсотків записів — решта залишалася поза перевіркою. Після впровадження розпізнавання та автоматичний розбір за сценаріями проходять по всьому трафіку, включаючи нічні зміни й лінії підрядників.
• Точність розпізнавання мовлення. Рахуємо на розміченій вибірці — відкритий корпус Common Voice плюс зліпок записів замовника. Метрику розносимо за типами ліній: на шумному каналі та на зв’язку з надмірним стисненням якість помітно нижча, ніж на еталонному студійному записі.
• Швидкість пошуку розмови. Пошук за архівом дзвінків іде за фразою, номером, оператором і періодом — потрібний епізод знаходиться за секунди замість годин ручного прослуховування.
• Частка автоматично знайдених порушень. Відсутність обов’язкового застереження про запис розмови, перебивання клієнта, конфліктні формулювання підсвічуються системою. Фахівець приходить до готового інциденту, а не шукає його вручну.

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

Режими обробки дзвінків: потік, пакет, гібрид

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

Пакетна обробка записів працює з готовими файлами: аудіо спочатку потрапляє в сховище, потім проходить нормалізацію, сегментацію за каналами й розпізнавання цілком.

Точність вища — менше заважають артефакти стиснення і є контекст усієї розмови, — але затримка розбору вимірюється годинами, і під час дзвінка такий результат марний.

Гібридна схема знімає цю суперечність: легкий потоковий прохід дає оперативну картину й метадані, а пакетний прохід на відкритій моделі Whisper уточнює розшифровку та розмітку для звітності. Розходження між проходами — ще й індикатор проблем зі звуком на боці телефонії.

Вибір режиму — це вибір між затримкою розбору та якістю розшифровки; гібрид купує обидва, але потребує зрілої експлуатації.

Етапи розробки: від аудиту записів до передачі системи

Порядок робіт вибудуваний так, щоб слабкі місця в словниках і правилах спливали на етапі налаштування, а не в проді, коли звітами вже користуються керівники. Кожен наступний етап спирається на артефакт попереднього, тому перестановка кроків зазвичай означає переробку розмітки.

1. Аудит архіву та каналів. Розбираємо записи з усіх джерел: телефонія, контакт-центр, диктофони, записи зустрічей. Дивимося розподіл за каналами, частку шуму, обриви, кодеки, довжину діалогів. На виході — карта джерел із часткою записів, придатних для автоматичного розбору, і списком того, що доведеться чистити на вході.
2. Схема потоку та правила обробки. Фіксуємо, де проходять вивантаження, зберігання, розбір і вітрина звітів. Окремо узгоджуємо знеособлення, терміни зберігання й доступ за ролями — це вимога, яку дешевше закласти одразу, ніж перебудовувати сховище заднім числом.
3. Налаштування словників. Терміни, назви продуктів, абревіатури, сленг операторів, фонетичні варіанти вимови. Словники закривають те, що загальна модель чує неправильно: без них назви тарифів і послуг розпізнаються як випадковий набір слів.
4. Розмітка вибірки. Вручну розмічаємо кілька сотень діалогів і отримуємо еталон: ролі, теми, ключові події, порушення. Вибірку стратифікуємо за каналами, темами та якістю зв’язку, інакше оцінка якості виявиться завищеною.
5. Впровадження мовленнєвої аналітики. Налаштовуємо розподіл за ролями, детектори й теги, правила перевірки скриптів і заборонених формулювань. Пороги спрацювання підбираємо так, щоб звіти не тонули в хибних спрацюваннях.
6. Перевірка якості розбору. Проганяємо систему на відкладеній вибірці й дивимося точність розпізнавання, коректність визначення ролей, повноту й точність тегів. Кожну помилку відносимо до джерела: модель, словник, розмітка або правило.
7. Навчання та передача. Віддаємо документацію, регламент оновлення словників, інструкції для аналітиків і схему моніторингу якості. Команда замовника далі править словники й пороги самостійно — без нас.

Що передаємо на виході: словники, розмітка, політики доступу

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

Тому разом із системою передаємо комплект, за яким її можна експлуатувати, перевіряти й розвивати власними силами.

• Словники термінів і правила розмітки — галузева лексика, синоніми, скорочення, список винятків; поповнюються з корпусу ваших записів, а не переписуються з нуля при кожній зміні мовлення.
• Схеми потоків даних — де запис з’являється, де зберігається, де видаляється, які копії залишаються; за цією схемою далі спокійно проходить служба безпеки.
• Матриця ролей і політики доступу — хто чує аудіо, хто бачить лише текст, хто працює зі звітами; доступ до запису не видається «на всякий випадок».
• Знеособлення записів — персональні дані вирізаються або маскуються до моменту зберігання, аналітикам іде вже очищений текст, а оригінал живе під окремим обмеженим правом.
• Регламенти контролю якості — як часто вимірюється точність розпізнавання, за якою вибіркою і хто переперевіряє вручну; зафіксовано, яке просідання вважаємо деградацією.
• Документація на систему — архітектура, параметри конфігурації, інструкції для операторів і адміністраторів, порядок оновлення моделей і словників.
• Журнал змін і порядок відкату — версія словника прив’язана до результату розбору, тому можна повернутися до попередньої й порівняти висновок на тому самому записі.

Далі система живе без нас: словники доповнює ваш аналітик, доступи видає ваша служба безпеки, а ми залишаємося на підтримці змін — за заздалегідь описаними точками розширення, а не з листування в месенджері.

Кейс: як розбір дзвінків скоротив час контролю якості

Кейс мовленнєвої аналітики почався із заміру: замовник — сервісна компанія з контакт-центром на кілька десятків операторів і потоком 2–3 тисячі дзвінків на добу. Відділ контролю якості з трьох осіб прослуховував 40–50 діалогів на тиждень — близько 2% трафіку.

На одну перевірку йшло 20–25 хвилин: прослухати розмову цілком, звірити зі скриптом, зафіксувати порушення, оформити висновок. Решту записів не розбирав ніхто, тому про конфлікти дізнавалися зі скарг, а не за власною вибіркою дзвінків.

Приклад впровадження будувався навколо суцільної транскрибації: аудіо йшло в розпізнавання мовлення на власному контурі замовника — рушій Whisper розгортався всередині його інфраструктури, щоб записи не залишали периметр.

Далі текст розбирався на ролі, репліки та смислові блоки, поверх чого працювали правила: слова-тригери, тривалі паузи, перебивання, пропуск обов’язкових фраз скрипта, згадування конкурентів.

Що змінилося

Результати впровадження рахували за тими самими метриками до й після. Розбір зріс із 2% до 100% дзвінків: кожен діалог отримує оцінку й мітки «спір», «відмова від оплати», «порушення регламенту».

Оператор відкриває не випадковий запис, а відфільтровану вибірку — скорочення часу перевірки до 4–6 хвилин замість 20–25, бо розшифровка, таймкоди й підсвічування порушень уже готові.

Час реакції на інцидент скоротився з кількох днів до пари годин: критичні слова піднімають дзвінок у черзі того самого дня, поки клієнт ще в діалозі з компанією.

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

Як розбір мовлення вбудовується в наявну телефонію

Підключаємося до того місця, де запис уже з’являється, — наявну телефонію не чіпаємо. Способів два: забирати готові файли зі сховища за розкладом або за фактом закриття дзвінка, чи приймати аудіо потоком через проміжний сервіс-приймач, якщо потрібен розбір у реальному часі. Часто беруть змішаний варіант: термінові лінії — потоком, решта пакетно.

Запис розмови залишається у вашій телефонії, ми її не дублюємо. Передача записів іде разом із метаданими: ідентифікатор виклику, напрямок, номер, оператор, час. Без прив’язки розбір втрачає сенс — розшифровка є, а до якого дзвінка належить, незрозуміло. Метадані забираємо з журналу викликів тим самим розкладом і зв’язуємо за ідентифікатором.

Якщо телефонія не вміє віддавати записи назовні, ставимо сервіс-приймач: вона надсилає файл після завершення виклику, сервіс кладе його в чергу й передає далі. Повторне надсилання не створює дубль — приймання ідемпотентне за ідентифікатором дзвінка.

Різні джерела дзвінків — кілька АТС, провайдерів, майданчиків контакт-центру — зводимо до єдиного виду: контейнери й кодеки, число каналів і частоту дискретизації нормалізуємо, биті та порожні ділянки відкидаємо.

Далі один індекс поверх усіх сховищ аудіо, і пошук іде відразу за всіма джерелами, а не за кожним окремо.

Сирі записи залишаються у вас: сюди йде лише потрібне для розбору, із заданою політикою зберігання та видалення, а доступ видається сервісним обліковим записом із мінімальними правами.

Технічні питання: точність, мови, зберігання записів

Інженери й керівники напряму запитують одне й те саме: що буде з точністю на поганому зв’язку, скільки мов реально підтримати, як довго тримати архів і хто отримає доступ до записів.

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

Скільки мов підтримати і що зі змішаним мовленням?

Російську та англійську беремо відразу, перемикання мов усередині однієї фрази — теж. Галузеву лексику, назви й прізвища закриваємо словниками та підказками: це знімає більшу частину помилок без повного донавчання на розміченому корпусі.

Наскільки глибокий архів потрібен і як зберігати записи?

Аудіо та розшифровки живуть роздільно: текст із метриками зберігається дешевше й шукається швидше, аудіо — за політикою (термін, холодний клас, автовидалення). Часто достатньо тримати цілком лише фрагменти зі спрацьованими правилами контролю, решта — обмежений термін.

Хто і як отримує доступ до записів?

Персональні та платіжні дані маскуються на етапі розшифровки, доступ видається за ролями й пишеться в журнал. Контур можна розгорнути на боці замовника — записи не залишають периметр, приватність даних залишається під вашим контролем.

Обговоримо задачу: що потрібно для оцінки розбору дзвінків

Оцінка впровадження мовленнєвої аналітики тримається не на обсязі записів, а на тому, наскільки рівно описані джерела, критерії пошуку й точки, куди мають потрапляти результати. Нижче — вихідні дані, які ми запитуємо до розрахунку. Частина закривається на дзвінку, частина приходить вивантаженням.

• Канали та обсяг. Звідки йдуть записи — телефонія, месенджери, очні зустрічі — скільки годин розмов на місяць і як зростає потік. За цим рахуємо навантаження й обираємо схему обробки.
• Формат архівів. Один канал чи стерео, чи чути обох учасників, чи є сторонній шум і як зберігається історія. Звідси — обсяг попередньої обробки й очікувана точність розпізнавання.
• Що шукаємо в розмовах. Скрипти й критерії оцінки оператора, стоп-слова, назви продуктів, конкурентів, спірні формулювання. Список перетворюється на правила й словники.
• Регуляторні рамки. Вимоги до зберігання персональних даних, термінів і доступів, чи потрібно обмежити обробку вашим контуром.
• Системи-отримувачі. Куди віддавати результати — у CRM, сховище звітів чи внутрішню панель, які ролі й права потрібні керівникам і службі контролю якості.
• Критерій успіху. Як ви зрозумієте, що впровадження спрацювало: частка перевірених дзвінків, швидкість реакції на інцидент, повнота вибірки для розбору.

Зібравши відповіді, ми повертаємося з оцінкою та планом робіт: етапи, склад, що закривається на вашому боці й що на нашому. Готове ТЗ не потрібне — опишіть задачу своїми словами, решту розберемо разом.