🏢 Диспетчер Діалогів Державного Чат-бота
Спостерігайте, як загоряється машина станів діалогу чат-бота громадських послуг протягом розмови — класифікація намірів, заповнення слотів і переходи станів крок за кроком.
Про Диспетчер Діалогів Державного Чат-бота
Більшість державних чат-ботів, що спілкуються з громадянами, працюють не на єдиній чорноскринькій моделі, яка вгадує наступну репліку — під дружнім вікном чату лежить машина станів діалогу: граф іменованих станів («очікує ідентифікатор нерухомості», «підтверджує тип дозволу», «передано людині»), з'єднаних переходами, які спрацьовують лише тоді, коли розуміння системою поточного повідомлення відповідає тому, що очікує цей стан. Це робить розмову передбачуваною та перевірюваною, що важливо, коли бот називає розмір плати, підтверджує термін подання документів або реєструє скаргу, яку має опрацювати муніципалітет.
Ця симуляція безпосередньо візуалізує цей граф: початковий стан розгалужується на три сервісні наміри — Податок на нерухомість, Заявка на дозвіл і Повідомити про проблему — плюс прямий вихід «Поговорити з людиною», і кожна гілка проходить через власні стани заповнення слотів, перш ніж злитися назад у «Щось іще?». Клацайте на вбудовані приклади повідомлень (або введіть власні), і невеликий шар NLU на основі правил вирішує, з поточного стану та надісланого вами тексту, до якого стану перейти далі — включно з поверненням по колу, якщо потрібний слот не знайдено, точно так, як це робив би виробничий диспетчер діалогу.
Часті питання
Що таке машина станів діалогу і чим вона відрізняється від простого класифікатора намірів?
Простий класифікатор намірів розглядає одне повідомлення окремо і видає мітку — «податок на нерухомість», «дозвіл», «скарга» — не пам'ятаючи, що було раніше. Машина станів діалогу натомість відстежує поточний стан (наприклад, «очікує ідентифікатор нерухомості») і приймає лише ті переходи, які мають сенс із цього стану, використовуючи вхідне повідомлення, щоб вирішити, яке ребро графа обрати. Це дозволяє одному й тому ж слову означати різні речі в різних станах — «вулиця Дубова, 123» є адресою, коли бот її запитує, і безглуздим шумом у будь-якому іншому випадку — і дозволяє системі пам'ятати, що вже було запитано й отримано у відповідь протягом багатьох реплік, а не лише останнього повідомлення.
Що означає «заповнення слотів» у системі розмовного ШІ?
Коли намір відомий (скажімо, «Заявка на дозвіл»), системі зазвичай усе ще потрібно кілька фрагментів структурованої інформації — так званих слотів — перш ніж вона зможе діяти: адреса, тип дозволу, можливо дата. Заповнення слотів — це процес видобування кожного з цих значень із вільного тексту відповідей користувача та запису їх у невеликий структурований запис. Заявка на дозвіл не може бути опрацьована, доки кожен обов'язковий слот (address, permit_type) не отримає значення; завдання диспетчера діалогу — продовжувати запитувати те, що ще порожнє.
Чому бот повертається по колу, коли слот відсутній, замість того щоб запитати лише раз?
Реальні користувачі часто відповідають не на те запитання, яке було поставлено, відхиляються від теми або дають відповідь, яку екстрактор не може розібрати («той великий, що біля школи» — не адреса, яку можна розпарсити). Якби машина станів просто рухалася далі попри це, вона б спробувала знайти дозвіл із відсутньою адресою і мовчки провалилася б або впала нижче за потоком. Натомість стан «запит» має самоцикл: якщо очікуваний шаблон слота не виявлено у відповіді, машина залишається в тому самому стані й перепитує. Саме цей цикл ця симуляція враховує як «цикл заповнення слота» — реальний, вимірюваний сигнал того, скільки тертя спричинила репліка.
Коли і чому реальні державні чат-боти передають розмову людині?
Передача спрацьовує або явно — коли громадянин каже «з'єднайте з людиною» — або неявно, коли той самий цикл заповнення слота спрацьовує більше кількох разів, коли впевненість класифікатора намірів залишається низькою протягом кількох реплік, або коли запит стосується чогось, що бот не уповноважений вирішувати (апеляція, юридичний спір, питання безпеки). Раннє скерування до людини, перш ніж громадянин розчарується, у добре спроєктованих системах вважається показником успіху, а не провалу — ефективна передача набагато краща за довгий цикл у глухий кут.
Чим це відрізняється від сучасного розмовного агента на основі LLM?
Велика мовна модель може обробляти відкриті формулювання, змішані наміри в одному реченні та уточнювальні запитання без вручну написаного графа, тому що вона генерує наступну відповідь із вивченого розподілу над мовою, а не через збіг ключових слів. Ця гнучкість має ціну передбачуваності: LLM може відхилитися від сценарію, вигадати політику або прийняти адресу, яку насправді ніколи не перевіряла. Машина станів на основі правил, як ця, значно менш гнучка щодо формулювань, але кожен шлях через неї можна перелічити, протестувати й перевірити — саме тому багато державних і регульованих систем досі поєднують фронтенд на основі LLM із детермінованою машиною станів або шаром перевірки слотів під ним для всього, що має юридичні чи фінансові наслідки.
У чому різниця між визначенням наміру та вилученням сутностей чи слотів?
Визначення наміру відповідає на питання «що користувач хоче зробити» — оплатити рахунок, подати заявку на дозвіл, повідомити про яму на дорозі — і зазвичай вирішується один раз на початку розмови. Вилучення сутностей чи слотів відповідає на питання «які конкретні значення він мені дав» — адреса, тип дозволу, дата — і може відбуватися майже на кожній репліці, поки розмова заповнює деталі, потрібні для дії за наміром. Повідомлення може нести обидва одразу: «на Головній вулиці є яма» задає намір (report_issue) і заповнює слот (location) в одному висловлюванні, що NLU цієї симуляції обробляє, перевіряючи обидва шаблони для кожного вхідного повідомлення.
Чому державні чат-боти часто використовують машини станів замість чистих вільних LLM?
Державні служби пов'язані правилами, які мають застосовуватися послідовно й обґрунтовано — неправильно названа плата за дозвіл або неправильно повідомлений термін сплати податку має реальні наслідки і може стати предметом запиту на публічну інформацію чи аудиту. Скінченний автомат гарантує, що певні кроки (перевірка особи, підтвердження значення слота, пропозиція передачі людині) завжди відбуваються в тому самому порядку і ніколи не можуть бути пропущені, а кожен можливий шлях через розмову можна заздалегідь перелічити й протестувати. Ця можливість перевірки та передбачуваність зазвичай коштують державному органу більше, ніж природніша розмова, яку могла б запропонувати чиста LLM.
Граф діалогу з ~13 станів керує невеликим NLU на основі правил: кожне прикладне повідомлення звіряється з очікуваним словником поточного стану, щоб визначити намір і заповнити слоти, повертаючись по колу при відсутніх слотах і зливаючись назад у спільний стан «щось іще?», перш ніж завершити розмову або передати її людині.
3D · рушій Three.js / WebGL · ціль 60 FPS · працює повністю на стороні клієнта, без встановлення