Голосовий помічник у мобільному застосунку: де він ламається
Голосовий помічник у мобільному застосунку ламається не на записі демо, а в живому сценарії: в машині, на вулиці, у торговому центрі.
Там, де мовний інтерфейс має працювати, розпізнавання мовлення в застосунку отримує не чистий сигнал, а суміш голосу, музики й чужих розмов — і впевненість моделі падає саме на значущих словах: адресі, сумі, назві позиції.
Збої голосового введення рідко бувають поодинокими.
Фоновий шум маскує ключове слово, користувач повторює гучніше — асистент чує вже інше; зв'язок зникає в ліфті або на перегоні, і запит іде в нікуди без виразної відповіді; довга пауза на роздуми закриває сесію, і людина повертається до першого екрана, не розуміючи, чи її почули.
Окрема категорія — помилки розпізнавання на неоднозначних формулюваннях. «Два» і «двадцять», «на два дні» і «на двоє», вулиця, продиктована по літерах, — помічник або вгадує, або перепитує по колу, і довіра до голосового введення падає швидше, ніж до ручного.
Найдорожче — втрата контексту між кроками: продиктували адресу, розмір, час, а стан сесії не зберігся. Тоді кожна пауза стирає попередні відповіді, і замовлення доводиться починати заново. Розбираємо, як це закривається.
Що змінюється після впровадження: мовлення як основний інтерфейс
Введення перестає бути формою. Голосовий шар розбирає фразу на намір і параметри та передає їх у ті самі операції, що викликають кнопки, — це надбудова над наявною логікою застосунку, а не другий продукт із власною бізнес-логікою.
Перший вимірюваний ефект — частка сценаріїв, закритих без оператора. У телеметрії вона рахується напряму: сесія завершилася дією, а не переведенням на людину.
На повторюваних операціях — перевірити статус, повторити замовлення, записатися — показник виходить на 60–80% за акуратно зібраних підказок.
Другий — швидкість повторюваних дій. Екран із чотирма-п'ятьма кроками згортається в одну фразу, і оформлення замовлення скорочується з двох-трьох хвилин до десятків секунд.
Економія накопичується саме в частотних сценаріях: людина повертається до них багаторазово, а не один раз під час першого знайомства із застосунком.
Третій — цілий клас відмов на введенні: друкарські помилки, неправильний формат номера й дати, пропущене обов'язкове поле.
Голосове введення віддає вже розібрані значення, а перед незворотним кроком на кшталт списання чи скасування застосунок промовляє параметри й просить підтвердження.
Четвертий — розвантаження першої лінії: типові питання переходять у самообслуговування, операторам залишаються нестандартні випадки.
Розпізнавання працює в потоковому режимі — Yandex SpeechKit віддає проміжні гіпотези до кінця фрази, тому відповідь починається раніше, а перебивання обробляється коректно.
Усі чотири метрики знімаються в робочому контурі, і за ними видно, де шар працює, а де потребує доопрацювання.
Сценарії розпізнавання мовлення: порівняння режимів роботи
Режим розпізнавання обирають не за смаком, а за сценарієм: коротка команда «увімкни таймер» і десятихвилинна диктовка нотатки висувають до обробки мовлення різні вимоги.
Тому в одному застосунку зазвичай співіснують кілька режимів роботи помічника, і перемикаються вони непомітно для користувача.
Локальне розпізнавання мовлення тримає аудіо на пристрої: працює в метро й літаку, не потребує каналу і не надсилає голос назовні. Обмеження — невеликий словник, слабша якість на шумному й змішаному мовленні, модель займає місце у складі застосунку.
Хмарні мовні сервіси дають точність на складних записах, широкий словник і оновлення моделей без релізу, але залежать від каналу і передбачають передавання голосу на сервер.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| На пристрої | Короткі команди, офлайн-сценарії, чутливі до приватності дані | Вузький словник, слабше на шумі, зростає розмір збірки |
| У хмарі | Диктовка, довгі фрази, кілька мов | Потрібен стабільний канал, голос іде на сервер, відгук залежить від мережі |
| Гібрид | Змішані сценарії, нестабільна мережа | Складніша логіка перемикання й тестування обох шляхів |
Гібридна обробка найчастіше і є відповіддю на вибір схеми розпізнавання: команди йдуть у локальну модель, диктовка — у хмару, а за втрати каналу помічник доопрацьовує на пристрої та ставить надсилання в чергу.
Межу між режимами задають за типом сценарію, довжиною фрази й станом мережі — на етапі проєктування, а не після релізу.
Як відбувається впровадження: від аудиту сценаріїв до передачі
Порядок робіт вибудуваний так, щоб помічник навчався на реальних зверненнях, а не на вигаданих фразах. Спершу дивимося, що люди вже пишуть і кажуть у підтримку, і лише потім проєктуємо діалоги — інакше перші ж нестандартні формулювання ламають сценарій і розмова йде до оператора.
- Аудит діалогових сценаріїв. Вивантажуємо історію звернень, класифікуємо за темами й рахуємо, яку частку закриває помічник, а яку доведеться віддавати людині. На виході — список сценаріїв із пріоритетом за частотою.
- Розмітка реальних діалогів. Збираємо еталонну вибірку живих реплік: як запитують, як перепитують, де кидають. За нею налаштовуємо розпізнавання й розбір сенсу, фіксуємо спірні випадки в окремий набір для перевірок.
- Проєктування діалогів. Прописуємо гілки, уточнювальні питання, запасні сценарії та правила ескалації на оператора. Критичні дії — оплата, зміна даних — лише з явним підтвердженням.
- Налаштування помічника. Підключаємо розпізнавання мовлення і синтез відповіді, голосові профілі, пороги впевненості, інтеграцію з обліковою системою та базою знань.
- Перевірка на користувачах. Запускаємо на обмеженій частці трафіку: дивимося частку завершених розмов без оператора, кількість перепитувань, причини відмов. Правки вносимо за фактичними логами, а не за відчуттями.
- Закриття помилок. Розбираємо кожну невдалу гілку, доучуємо на нових формулюваннях і проганяємо регрес за еталонною вибіркою, щоб не зламати те, що вже працює.
- Передача команді. Віддаємо конфігурації, схему діалогів, регламент правки фраз і моніторинг за ключовими метриками — далі замовник веде помічника сам.
Що залишається в замовника після запуску помічника
Помічник — це не кнопка мікрофона, а набір інженерних рішень: як розпізнається мовлення, як із фрази виділяється намір, що робить застосунок за обриву мережі. Якщо ці рішення залишаються в листуванні, будь-яка правка сценарію перетворюється на археологію.
Ми передаємо проєкт так, щоб команда замовника розвивала помічника сама. Комплект артефактів на руках:
- Схема діалогів — дерево сценаріїв із точками розгалуження: що вважається командою, де помічник уточнює, де передає запит оператору.
- Правила обробки помилок і повторів — скільки разів перепитати за непевного розпізнавання, коли запропонувати введення текстом, коли повернути на крок назад.
- Політики доступу до голосових даних — де зберігаються записи, скільки живуть, хто має до них доступ і як вони видаляються на запит.
- Документація з помічника — перелік намірів, підтримувані формулювання, інструкція з додавання команди без правки ядра.
- Регламент підтримки — які події вважаються збоєм, куди приходять оповіщення, за який час розбирається інцидент і як відкочується реліз.
- Репозиторій і порядок передачі проєкту — код, конфігурації, доступи, опис тестового й продуктивного стендів.
- Порядок розвитку — як додати сценарій або мову, не переписуючи ядро.
Передача йде не архівом: проходимо за кожним пунктом із командою замовника, поки не залишиться сірих зон. Далі наша допомога потрібна лише на нових сценаріях.
Кейс: як помічник у застосунку доставки зняв навантаження з підтримки
Мережа доставки їжі із застосунком на iOS і Android: пік навантаження — вечір п'ятниці, і підтримка захлинається однотипними питаннями «де замовлення», «повторіть попереднє», «змініть адресу». До впровадження помічника без оператора закривалося 12% звернень, решта йшла в чат і на лінію.
Сценарії зібрали не «на все», а на три часті наміри: статус замовлення, повтор попереднього кошика, зміна адреси. Помічник відкривається прямо з картки замовлення й отримує контекст сесії — номер, адресу, історію, — тому не перепитує те, що застосунок уже знає.
Розпізнавання побудоване на хмарному сервісі рівня Yandex SpeechKit з проміжними результатами: людина бачить текст у міру мовлення, а не після паузи.
Метрики до і після
| Метрика | До | Після |
|---|---|---|
| Звернення, закриті голосом без оператора | 12% | 41% |
| Оформлення повторного замовлення | близько 3 хвилин | 50 секунд |
| Зриви діалогу | кожен п'ятий | один із двадцяти |
| Відмови на розпізнаванні | 18% | 6% |
Зриви діалогу знизили не моделлю, а правилом ескалації: після двох невдалих перепитувань розмова безшовно переходить оператору разом із розшифруванням. Відмови на розпізнаванні впали завдяки коротким підказкам, що саме можна сказати, і повтору фрази в уповільненому темпі.
Кількість звернень до операторів скоротилася на третину, а в пікові години лінія розвантажилася настільки, що черга очікування перестала зростати до кінця вечора.
Чим відрізняється обробка мовлення на пристрої від хмарної?
Коротка відповідь: вибір зводиться до того, де розміщені акустична й мовна моделі — на пристрої чи на сервері. За локальної обробки мовлення розпізнається прямо в застосунку: відкриті моделі на кшталт Whisper працюють поруч із мікрофоном, без надсилання звуку назовні.
Хмарна надсилає потік на сервери, де якість розпізнавання вища, а сценарії майже не обмежені словником.
Приватність голосових даних різниться принципово: локально сирий звук не залишає пристрій, назовні йде лише розпізнаний текст. У хмарі аудіо передається каналом і якийсь час зберігається, тому потрібні шифрування, регламент терміну зберігання й явна згода користувача. Офлайн локальна модель відповідає в авіарежимі, хмарна за тих самих умов не працює.
На практиці вибір архітектури помічника рідко буває бінарним. Ми визначаємо, які команди зобов'язані працювати без мережі й який звук не можна виносити за межі пристрою, — вони йдуть у локальний контур, а вільні формулювання та складні діалоги залишаються в хмарі.
Гібридна схема дає швидкий відгук на частих запитах і прибирає відмови, пов'язані зі зникненням зв'язку.
Часті технічні сумніви перед стартом проєкту
Питання про точність, мови й вимоги до самого застосунку вирішуються на етапі проєктування, а не після запуску. Нижче — те, що найчастіше перевіряють перед стартом: розпізнавання, доменна логіка й сценарії діалогу тестуються разом, на реальних записах, а не окремо.
Наскільки точно помічник розпізнає мовлення в шумі?
Точність сильніше залежить від умов запису, ніж від обраної моделі: вулиця, луна приміщення, тихий голос біля мікрофона. Ми вмикаємо шумопридушення і задаємо поріг впевненості — за низької впевненості помічник перепитує або пропонує варіанти, а не вгадує. Налаштування йде на записах із реальних сценаріїв, а не на студійних прикладах.
Що з акцентами та змішаним мовленням?
Збираємо словник предметної області: терміни, назви, абревіатури — з варіантами вимови. Змішані фрази розбираємо на рівні мовної моделі, де частина слів розпізнається однією мовою, частина іншою. Спірні розпізнавання інженер перевіряє на розміченій вибірці й уточнює словник.
Що робить помічник, якщо не зрозумів?
Сценарій на нерозуміння проєктуємо явно: уточнювальне питання, звуження варіантів, перехід на ручне введення. Мовчання або випадкова здогадка дратують сильніше за прохання повторити. Кожен такий випадок потрапляє в журнал — це готовий список правок сценаріїв і словника.
Як додаються нові мови?
Архітектуру робимо без жорсткої прив'язки до мови: розпізнавання, доменна логіка й відповіді розділені. Нова мова — це підключення мовної моделі та переклад сценаріїв, а не переписування застосунку. Стартуємо з однієї-двох, решту додаємо в міру попиту.
Які вимоги до застосунку?
Потрібні дозволи на мікрофон, робота у фоні та зрозуміла поведінка за слабкої мережі.
Фіксуємо мінімальну підтримувану версію операційної системи, щоб розпізнавання не губилося на старих пристроях, і передбачаємо м'яке зниження якості: фраза зберігається й іде на обробку за появи каналу.
Обговоримо задачу: розберемо сценарії та повернемося з планом
Оцінка проєкту починається не з цифр, а з ввідних: за якими сценаріями користувач говорить із застосунком і які обмеження є у вашої інфраструктури. Частину даних ми піднімемо самі з коду й макетів, але кілька речей знаєте тільки ви — їх варто принести на обговорення задачі.
- голосові сценарії: що закривається мовленням, а що залишається в інтерфейсі;
- платформи й мінімальні підтримувані версії системи;
- чи є вже розпізнавання й синтез мовлення, чи підбираємо рушій з нуля;
- чи потрібна робота без мережі й який запас команд тримати офлайн;
- доступи: мікрофон, акаунти платформ, правила обробки персональних даних;
- мови, галузева лексика й вимоги до точності розпізнавання;
- терміни й точка, до якої потрібен робочий сценарій цілком.
Розберемо ці ввідні на дзвінку й повернемося з оцінкою обсягу, планом впровадження за етапами та складом робіт — із явним розподілом, що робимо ми, а що потрібно від вашого боку.
Опишіть задачу у зручній формі: текстом, голосовим повідомленням або посиланням на поточний застосунок, — і ми запропонуємо час для розмови по суті.
