Чому соціальний робот зривається в шаблон на третій репліці
Перші дві-три репліки робот-компаньйон тримає впевнено, далі розмова осипається в завчені фрази. Користувач помічає це раніше за інженера: він уже двічі сказав, про що йдеться, а робот знову вітається і пропонує тему заново.
Причина зазвичай не в самій моделі, а в тому, як збирається діалог. Якщо в запит іде лише остання репліка, історія не зберігається — і скидання контексту відбувається після кожної фрази.
Службові вставки та підказки сценарію переповнюють вікно, ранні репліки витісняються, і робот-компаньйон відкочується до початку сценарної гілки. Простий тест: запитати через три ходи, як звати співрозмовника і про що він говорив хвилину тому.
У шумному приміщенні розпізнавання мовлення помиляється двічі: пропускає тиху репліку і приймає за неї чужу розмову. Телевізор, другий мовець за столом, дзвін посуду дають хибні спрацьовування, і робот відповідає не тому й не на те.
Лікується це відсіюванням за напрямком голосу, порогом впевненості та підтвердженням перед дією, а не підвищенням чутливості мікрофона.
Затримка відповіді ламає ритм сильніше, ніж неточність: пауза в кілька секунд читається як поломка, і людина йде.
Допомагають короткі репліки-підтвердження, поки збирається змістовна відповідь, локальні гілки на кшталт таймера чи погоди та розбиття довгої репліки на смислові частини.
Деградація до заздалегідь записаних фраз — не захист, а маскування: замість уточнювального питання робот повторює скрипт, і розмова вмирає остаточно. Правильна поведінка при невпевненості — перепитати, чесно змінити тему або визнати, що не розчув.
Розбираємо, як це закривається на рівні зберігання історії діалогу, обробки звуку та логіки поведінки робота-компаньйона.
Що дає керований діалог: ефект у вимірюваних показниках
Керований діалог оцінюють не за красою окремих відповідей, а за поведінкою на довгій серії однотипних сесій. Головний показник — частка автономних відповідей: яку частину реплік соціальний робот закриває сам, без переведення на оператора.
На запусках у гостьових сценаріїв вона виходить на плато 82–91% і далі зростає не кількістю прописаних фраз, а уточненням правил розбору незрозумілих формулювань.
Другий показник — стійкість діалогу під навантаженням. Ми тримаємо окремий контур перепитувань: якщо система не впевнена в намірі гостя, робот не відповідає навмання, а звужує питання і повертається до теми через одну-дві репліки.
Так сесія не зривається в роздратування та дострокове завершення — це видно за часткою діалогів, доведених до кінця сценарію.
Час відновлення після збою вважаємо від першої некоректної відповіді до повернення в нормальний режим.
Раніше це було ручне перезавантаження на кілька хвилин із втратою контексту, тепер — автоматичний відкат на попередню стабільну конфігурацію зі збереженням сесії: укладається в десятки секунд і помітно для гостя лише за короткою паузою.
Класи відмов ідуть у міру накопичення телеметрії: залиплі стани, повторювані відповіді, втрата пам'яті між сесіями, відповіді поза роллю персонажа.
Навантаження на оператора знижується до нагляду та розбору спірних випадків — один черговий супроводжує парк із кількох десятків роботів, а не одного.
Інженерна база тут — ROS та зовнішні сервіси розпізнавання і синтезу мовлення, пов'язані єдиним шаром інтеграції. Це дозволяє змінювати окрему модель, не переписуючи логіку поведінки робота.
Де соціальний робот працює автономно, а де потрібен оператор
Автономний режим будується на локальній обробці: розпізнавання мовлення, діалогова логіка та синтез відповіді виконуються на борту робота.
Відгук не залежить від якості мережі, а при її втраті діалог не обривається — для дитячої кімнати, приймальні чи виставкової зали це базова вимога. Обмеження режиму — заздалегідь окреслена предметна область: за її межею система розпізнає нерозуміння і не додумує відповідь.
Гібридний режим залишає типові репліки машині, а складні переводить на оператора. Передача оператору спрацьовує за зрозумілими ознаками: повторні перепитування, пряме звернення по допомогу, емоційний сплеск, тема поза сценарієм.
Людина підключається в той самий діалог і бачить контекст останніх реплік, тому розмова не починається заново і нитка не губиться.
Порівняння режимів
| Режим | Коли підходить | Обмеження режиму |
|---|---|---|
| Автономний | Типові сценарії, майданчики без стійкого зв'язку, завдання з високими вимогами до приватності | Працює тільки всередині заданої предметної області, не виходить за сценарій |
| Гібридний | Змішаний потік звернень, є чергова операторська зміна | Потрібен регламент передачі та вільний оператор у момент звернення |
| Повністю операторський | Некласифіковані ситуації, інтерв'ю, спілкування з пресою | Число одночасних діалогів обмежено числом операторів |
Вибір режиму визначається не технологією, а класом звернень: чим вища частка непередбачуваних реплік, тим раніше потрібна людина.
Регламент передачі продумуємо окремо — за якою ознакою робот кличе оператора, що відбувається, якщо той не відповів за відведений час, і як накопичуються ці випадки для донавчання автономного контуру.
Як ми впроваджуємо AI-систему: етапи робіт
У соціального робота діалог не живе окремо від поведінки: репліка запускає жест, світло та поворот голови, а якість розпізнавання мовлення залежить від шуму в приміщенні.
Тому роботи йдуть послідовно — кожна наступна сходинка спирається на перевірений результат попередньої, а не на припущення.
- Аудит сценаріїв і вузьких місць. Розбираємо реальні записи розмов і логи: де робот втрачає контекст, де пауза перед відповіддю стає некомфортною, на якій фразі гість виходить з діалогу. На виході — карта проблемних місць із частотою повторення.
- Проєктування логіки діалогу. Описуємо дерево сценаріїв і правила переходів: гілки утримання уваги, реакція на перебивання, коректний вихід із глухого кута, ескалація до оператора при невпевненому розпізнаванні.
- Налаштування інтеграцій. Пов'язуємо мовленнєві модулі, базу знань, зовнішні сервіси та сам пристрій — мотори, світло, звук. Перевіряємо, що команда синтезу коректно перетворюється на фізичну дію без розсинхронізації.
- Налаштування на доменних даних. Збираємо словник імен, термінів і типових формулювань майданчика, щоб робот впевнено розумів мовлення конкретної аудиторії, а не лише еталонні фрази.
- Приймальна перевірка. Проганяємо систему на реальних сценаріях: рахуємо частку успішно завершених діалогів, час відгуку, частоту повторних питань. Кожен провалений прогін розбираємо і правимо до стабільного результату.
- Передача в експлуатацію. Віддаємо регламенти оновлення сценаріїв, панель контролю якості діалогів і зрозумілу інструкцію для персоналу майданчика. Правки контенту вносяться без зупинки робота.
Що залишається у вас після передачі проєкту
Передаємо не архів із вихідними кодами, а працюючий контур, який ваша команда може змінювати без нас. Нижче — перелік того, що фіксується в прийманні: кожен пункт перевіряється на живому стенді, а не лише за паперами.
- Конфігурації системи — сценарії реплік, пороги спрацьовування, тайминги реакцій і правила переходу між режимами винесені в окремі файли. Поведінка робота змінюється правкою конфігурації, без перезбирання логіки.
- Схеми інтеграції — карта потоків даних між голосовим контуром, діалоговим ядром і зовнішніми сервісами, з точками відмови. Окремо описано поведінку при втраті мережі: робот переходить у базовий сценарій замість зависання.
- Політики доступу до даних — розмежування ролей: хто бачить записи діалогів, скільки вони зберігаються, як видаляються на запит. Для сценаріїв із дітьми та літніми людьми це обов'язкова частина, а не опція.
- Регламенти роботи операторів — коли діалог передається людині, як розбирати спірні відповіді, що робити при повторюваних скаргах. Без цього відлагоджена система деградує за лічені тижні.
- Документація — архітектура, схема розгортання, журнал відомих обмежень і порядок дій при типових збоях. Пишемо під інженера, який відкриє її через пів року після нас.
- Навчання команди — практичні сесії на тестовому стенді: додати сценарій, подивитися метрики якості відповідей, відкотити невдалу зміну.
- Набір еталонних реплік — фіксовані приклади діалогів для регресії. Після будь-якої зміни сценарію ви за хвилини бачите, що не зламалося.
Приймання йде за чек-лістом: ваші інженери самі вносять зміну, проганяють регресію і відкочують версію. Якщо це виходить без нашої підказки — проєкт передано.
Кейс: музейний гід — від частих збоїв до стійкого діалогу
У виставковому просторі Музей міської історії працював соціальний робот-гід: він вів відвідувача маршрутом і відповідав на питання про експонати. Логіка була побудована на жорсткому сценарії — робот впевнено відповідав лише на заздалегідь вписані формулювання.
Варто було відвідувачу перебити його або запитати «а чому ця річ стоїть окремо?», і діалог розсипався: робот повторював останню репліку або йшов у перезапуск, а розмову підхоплював доглядач.
Що змінили
Ми переписали логіку діалогу: робот став тримати контекст усієї сесії, а не однієї репліки, ставити уточнювальне питання замість вгадування і явно визнавати, коли відповіді немає.
Додали звірку фактів із базою музею, щоб гід не вигадував дати й імена, та передачу діалогу доглядачеві з коротким витягом — людина продовжує з того місця, де робот зупинився.
Окремо налаштували нічні прогони записаних розмов: правки перевіряються на реальних діалогах до виходу в залу.
| Метрика | До впровадження | Після запуску |
|---|---|---|
| Діалоги, доведені до кінця без збою | 62% | 94% |
| Питання поза сценарієм, на які є відповідь | 25% | 87% |
| Втручання доглядача на 100 діалогів | 34 | 6 |
| Середня довжина розмови, реплік | 3 | 9 |
Стійкість тримається не на одній моделі, а на контурі: якщо нове складання логіки на нічному прогоні відповідає гірше за попереднє, воно відкочується, а в залі залишається робоча версія.
Логи діалогів збираються в одному місці, тому причина збою знаходиться за конкретною реплікою, а не за скаргою відвідувача.
Чим відрізняється сценарний каркас від генеративної відповіді
Сценарний каркас — це дерево станів: робот знає, які репліки допустимі в поточному контексті, чим закінчується кожна гілка і як реагувати на мовчання. Поведінка відтворювана: та сама ситуація дає ту саму відповідь, той самий сценарій проходить перевірки детерміновано. Ціна — вузька воронка: відхід від заготовки впирається в «не зрозумів, повторіть».
Генеративна відповідь породжує репліку під конкретний контекст, тому тримає вільну бесіду, відповідає на несподіване питання і підхоплює зміну теми. Передбачуваність поведінки при цьому падає: відповідь не відтворюється від запуску до запуску, складніше втримати межі теми та тон.
Гібридна логіка розводить зони відповідальності. Каркас тримає критичні гілки — привітання, знайомство, розпізнавання наміру, ескалацію до оператора, безпечну відмову — і вирішує, коли передати хід далі.
Генеративний шар веде вільну частину в межах рамок: заданий тон, обмеження довжини репліки, заборонені теми та умови повернення до сценарію.
Чистий каркас упирається в стелю впізнаваності фраз — це наочно показала історія Jibo та інших роботів-компаньйонів. Зворотна крайність не краща: без каркаса система втрачає передбачуваність і на супроводі перетворюється на нескінченне підлаштування під кожен новий діалог.
Тому супровід системи будується навколо каркаса: сценарні гілки оновлюють правкою дерева і повторним прогоном перевірок, а генеративний шар — набором тестових діалогів і розбором відхилень.
Технічні сумніви, які варто зняти до старту
До старту замовник перевіряє три речі: де фізично лежать дані діалогів, що станеться при втраті зв'язку і наскільки дорого змінювати поведінку робота після запуску. Нижче — відповіді за цими пунктами та за стикуванням із уже вибраною платформою робота.
Аудіо та текст діалогів залишаються у нас?
Розпізнавання мовлення, синтез і модель відповідей розгортаємо на вашому контурі або в закритому хмарі під вашим контролем. Записи не покидають периметр, логи зберігаються локально з налаштовуваним терміном і доступом за ролями. Зовнішній сервіс, якщо він взагалі потрібен, вимикається одним параметром конфігурації.
Що буде при втраті зв'язку?
Базові сценарії — привітання, навігація, типові репліки — зашиті в модуль і працюють автономно. Після відновлення зв'язку накопичені сесії довантажуються в загальну аналітику. Це плавна деградація, а не відмова: робот продовжує обслуговувати людей.
Модель навчається на наших матеріалах?
Скрипти, регламенти, записи операторів і каталог послуг завантажуємо в базу знань, за якою модель будує відповіді. Робот спирається на ваші формулювання і не вигадує того, чого в матеріалах немає.
Як оновлюються сценарії та підключається обладнання?
Репліки та гілки поведінки тримаємо окремими конфігураціями: правку викочуємо на частину парку, дивимося метрики, відкочуємо без перепрошивки. Мікрофони, приводи та датчики залишаються рідними — працюємо через штатні інтерфейси виробника.
Обговоримо задачу і повернемося з оцінкою та планом
Щоб розбір задачі зайняв одну розмову, а не три, до нього достатньо підготувати кілька вступних — вони беруться з поточної роботи і не потребують окремих документів.
Чим конкретніші вихідні дані, тим точніший склад етапів та оцінка термінів: без них план виходить або завищеним, або з пропущеними роботами.
- Сценарій взаємодії. Де соціальний робот зустрічає людину — приймальня, зал, зона очікування — і що він має встигнути зробити в перші хвилини спілкування.
- Поточні можливості платформи. Які датчики та канали виводу вже доступні, чи є маневреність: від цього залежить, що налаштовується, а що розробляється з нуля.
- Зовнішні дані. Системи, до яких робот має звертатися за відповіддю: база знань, розклад, внутрішній сервіс, облікова система.
- Обмеження майданчика. Рівень шуму, освітленість, ширина проходів, стабільність мережі — вони прямо впливають на вибір моделей розпізнавання мовлення та логіки поведінки.
- Хто приймає результат. Людина з боку замовника, яка підтверджує «працює»; інакше пілотне впровадження розтягнеться на узгодження між відділами.
- Критерій успіху. Метрика, за якою судимо результат: частка діалогів, доведених до кінця, число збоїв на сотню звернень, час до осмисленої відповіді.
Після розбору ми повертаємося з планом робіт: склад етапів із порядком і залежностями, оцінка термінів на кожен, точки, де потрібен зворотний зв'язок з вашого боку.
Зазвичай перший крок — пілотне впровадження на одному роботі й одному майданчику, де перевіряються сценарії та збирається статистика відмов, і лише потім масштабування на парк пристроїв. Опишіть задачу — повернемося з оцінкою та планом.
