Реалізація ендпоінтінгу мовлення (End-of-Speech Detection)

Ендпоінтинг мовлення: де уривається природний діалог

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

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

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

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

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

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

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

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

Що дає кероване визначення кінця репліки

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

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

• Частка хибних обривів. Модель дивиться не лише на тишу, а й на інтонаційне завершення фрази, темп і синтаксис, тому не ріже репліку на паузі для підбору слова. Цільовий орієнтир — одиниці відсотків від усіх пауз проти десятків за фіксованого порогу тиші.
• Час відгуку асистента. Відгук скорочується в рази: відповідь стартує одразу після смислового завершення фрази, а не після витриманої паузи очікування. У потоковій передачі звуку через WebRTC це різниця, яку користувач чує без приладів.
• Стійкість до шуму. На лінії з фоновим гудінням, луною та уривками чужого мовлення детектор голосової активності не глушить початок репліки й не «дослуховує» тишу. Окрема перевірка — набір записів із реальних каналів, а не студійна тиша.
• Перебивання користувача. Якщо людина заговорила поверх відповіді, асистент замовкає в межах заданого вікна, а не домовляє до кінця. Це саме правило захищає від накладання двох потоків мовлення в записі діалогу.
• Частка покинутих діалогів. Сесії без активності закриваються після завершення заданого часу, стан скидається, а не накопичується в пам’яті. Побічний ефект — передбачуване навантаження на діалоговий сервіс у години пік.
• Регрес на розмічених наборах. Кожен реліз проганяється на корпусі з паузами, шумом і перебиваннями; порівняння з попередньою збіркою показує, чи не погіршився якийсь зі сценаріїв.

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

Режими визначення кінця фрази: порівняння підходів

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

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

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

Як ми впроваджуємо ендпоінтинг мовлення у ваш продукт

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

1. Аудит записів діалогів. Збираємо корпус реальних розмов за всіма каналами й слухаємо його: де пауза означає кінець думки, а де людина добирала слово або її перебили.
2. Розмітка меж реплік. Будуємо на цьому корпусі еталон: межі проставляються вручну, спірні випадки вирішуються правилом, а не думкою розмітника. Еталон стає міркою для всіх подальших правок.
3. Налаштування параметрів. Підбираємо поріг тиші й мінімальну тривалість паузи, час підтвердження кінця репліки, поведінку під час перебивання та шуму. Для телефонного тракту й мікрофона набори різні.
4. Перевірка на живих дзвінках. Проганяємо рішення на потоці: рахуємо обриви реплік, хибні спрацювання на вдиху й фоні, затримку відповіді бота. Правки йдуть ітераціями, доки метрики не вийдуть на узгоджений рівень.
5. Передавання в супровід. Віддаємо конфігурації за каналами, схему обробки, панель з метриками й порядок перекалібрування — у разі зміни тракту ваша команда налаштовує все сама, без нас.

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

Що передаємо на руки: конфігурації та регламенти

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

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

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

Кейс: голосовий асистент — хибні обриви та відгук

Що було

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

На записах із фоновим шумом, паузами на підбір формулювання й вдихами всередині фрази вікно зачинялося посеред речення — обрізалося 12% реплік, а довгі фрази виду «мені потрібен тариф, який… е-е… дозволяє…» асистент рвав на частини.

Обратна сторона того самого налаштування — очікування. Поки вікно не мине, система мовчала, і час до першої відповіді сягав двох секунд.

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

Що змінили

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

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

Що стало

• частка обрізаних фраз — 12% → 1,4%;
• час до першої відповіді — 1,9 → 0,5 секунди;
• діалоги з повторним перепитуванням — 24% → 6%;
• розмови, покинуті на очікуванні, — 9% → 2%;
• ескалації на живого оператора — менше приблизно вдвічі.

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

Чому поріг за гучністю рве фразу на вдиху?

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

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

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

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

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

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

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

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

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

Технічні сумніви перед стартом

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

Чи потрібне перенавчання на своїх записах?

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

Як перевірити якість?

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

Що робити за поганого зв’язку?

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

У нас свій поріг тиші — доведеться його змінювати?

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

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

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

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

Що корисно надіслати заздалегідь:

• Записи діалогів — 10–30 хвилин реальних розмов із того каналу, де буде працювати система: телефонія, мікрофон оператора, гарнітура підтримки.
• Сценарії використання — де саме потрібно ловити кінець репліки: голосовий помічник, диктування, розшифрування зустрічей, потокова аналітика дзвінків.
• Цільові метрики — допустима затримка спрацювання, частка хибних обривів, частка обрізаних фраз, поведінка на тиші та музиці в лінії.
• Обмеження за середовищем — обробка на пристрої, на вашому сервері або в зовнішньому контурі; вимоги до приватності та зберігання аудіо.
• Мови й акустика — мови та акценти, частка перебивань, якість мікрофонів, луна й мережеві втрати.
• Поточний контур розпізнавання — що вже стоїть, як передається звук, чи є жорстка вимога до роботи в реальному часі.
• Ручна розмітка, якщо є — фрагменти, де кінець репліки позначений вручну: прискорює підбір порогів і перевірку.

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