Підключення NLP до мобільного чат-бота: практика Microsoft Bot Framework
Припустимо, у вас є мобільний додаток, який має спілкуватися з користувачами природною мовою — розуміти команди, відповідати в різних каналах. Якщо ви вирішите писати NLP з нуля, це займе півроку і бюджет, порівнянний із командою з трьох розробників. Microsoft Bot Framework v4 і Azure Bot Service дають готову інфраструктуру: діалоговий рушій, інтеграцію з десятками каналів (Teams, Telegram, веб) і вбудований NLP-компонент CLU. Однак інтеграція в мобільний додаток вимагає розуміння архітектурних нюансів. Розберемо ключові точки: Direct Line, токени, стан діалогу та відмова від Adaptive Cards. Це економить до 40% бюджету порівняно з кастомною розробкою.
Як безпечно підключити мобільний додаток до Azure Bot Service?
Direct Line — єдиний канал для кастомних мобільних клієнтів (див. Direct Line Protocol). Помилка, яку ми бачили в десятках проєктів: розробники зашивають DirectLineSecret у код додатку. Після реверс-інжинірингу APK або IPA секрет потрапляє у відкритий доступ. Це дозволяє зловмисникам надсилати запити від імені бота. Рішення — токенізація: сервер генерує тимчасовий token через /v3/directline/tokens/generate і передає його клієнту. Токен живе 30 хвилин, його можна оновити через /v3/directline/tokens/refresh. Приклад на Swift:
// iOS: отримання токена з сервера та ініціалізація сесії Direct Line
func startBotSession() async throws -> String {
let tokenResponse = try await authService.getDirectLineToken()
UserDefaults.standard.set(tokenResponse.conversationId, forKey: "botConversationId")
return tokenResponse.token
}У документації Microsoft підтверджується: The Direct Line token is valid for 30 minutes. You can obtain a new token from the /v3/directline/tokens/refresh endpoint.
Архітектурна схема інтеграції
Для розгортання використовуйте Azure Web App з інтеграцією Direct Line, CLU та CosmosDB. Типова архітектура: мобільний додаток → Direct Line → Bot Framework SDK → CLU для NLP → CosmosDB для збереження стану.LUIS чи CLU: що обрати для нового проєкту?
Bot Framework традиційно використовував LUIS для розпізнавання намірів. Але Microsoft мігрувала на CLU (Conversational Language Understanding) у складі Azure AI Language. CLU працює вдвічі швидше за LUIS, підтримує 50+ мов і краще розпізнає складні діалоги з контекстом. Якщо ви починаєте новий проєкт — обирайте CLU. Для існуючих проєктів на LUIS готуйте міграцію: формати експорту та SDK відрізняються (Azure.AI.Language.Conversations замість Microsoft.Azure.CognitiveServices.Language.LUIS). Ми допомогли клієнтам мігрувати п'ять проєктів за останні роки.
| Характеристика | LUIS | CLU |
|---|---|---|
| Швидкість розпізнавання | 200–400 мс | 80–200 мс (до 2× швидше) |
| Підтримувані мови | ~10 | 50+ |
| Інтеграція з Bot Framework | Пряма через Recognizer | Через CustomQuestionAnsweringRecognizer |
| Навчання моделі | Потрібен експорт з LUIS | Вбудований імпорт з .LU файлів |
Економія при переході на CLU становить 30–40% вартості транзакцій і 40% часу розробки. Отримайте консультацію нашого інженера, щоб оцінити вигоду для вашого проєкту.
Зберігання стану діалогу в продакшні
За замовчуванням Bot Framework зберігає UserState і ConversationState у пам'яті. Після перезапуску сервера контекст втрачається. Для продакшну використовуємо CosmosDbPartitionedStorage або BlobStorage. Приклад налаштування на C#:
var storage = new CosmosDbPartitionedStorage(new CosmosDbPartitionedStorageOptions
{
CosmosDbEndpoint = configuration["CosmosDb:Endpoint"],
AuthKey = configuration["CosmosDb:AuthKey"],
DatabaseId = "BotStorage",
ContainerId = "DialogState"
});
var userState = new UserState(storage);
var conversationState = new ConversationState(storage);Це гарантує збереження контексту навіть при масштабуванні до 1000+ одночасних діалогів. Якщо у вас виникли питання щодо налаштування CosmosDB, зв'яжіться з нами — ми допоможемо.
Вибір протоколу: WebSocket чи Polling
Direct Line підтримує два режими отримання повідомлень: long polling (REST) і WebSocket. Порівняємо їх за ключовими метриками.
| Характеристика | Long Polling (REST) | WebSocket (streamUrl) |
|---|---|---|
| Затримка доставки | 500 мс – 2 с | 50–150 мс |
| Навантаження на сервер | Високе (часті запити) | Низьке (одне з'єднання) |
| Споживання батареї на мобільному | Вище (часті wake-up) | Нижче (постійний TCP) |
| Складність реалізації | Проста (HTTP) | Середня (керування з'єднанням) |
WebSocket кращий для активного чату. На Android використовуємо OkHttp WebSocket, на iOS — URLSessionWebSocketTask. Важливий нюанс: streamUrl живе близько 60 секунд без активності, після чого з'єднання закривається. Потрібно обробляти onClosed і перепідключатися з оновленим токеном.
Обмеження Adaptive Cards для мобільного UI
Adaptive Cards — це JSON-схема для UI-карток, яку Bot Framework використовує для мультиканального рендерингу. Для iOS і Android є офіційні SDK (AdaptiveCards-iOS, adaptivecards-android), але кастомізація стилів обмежена: не можна перевизначити шрифти, відступи та анімації. У 80% наших проєктів ми відмовляємося від Adaptive Cards на користь кастомних event-активностей, які рендерять UI нативно. Це дає повний контроль над дизайном і поведінкою — наприклад, можна вбудувати інтерактивні форми або графіку.
Що входить у роботу при замовленні інтеграції під ключ
- Архітектурна документація (схема Direct Line, діаграма діалогів)
- Репозиторій з кодом бота та SDK для iOS/Android
- Доступ до Azure ресурсів (Bot Service, CLU, CosmosDB)
- Інструкція з деплою через CI/CD та моніторингу (Application Insights)
- Навчання команди (2 години онлайн з розбором типових помилок)
- Гарантія сумісності з iOS 15+ та Android 12+
Ми працюємо з Bot Framework v4 з його першого релізу. Оцінимо ваш проєкт за 1 день — просто напишіть у чат на сайті.
Процес роботи
- Аналітика: аудит поточних чат-сценаріїв, збір вимог.
- Проєктування: вибір стеку (CLU/LUIS), проєктування діалогів, архітектура Direct Line.
- Розробка: реалізація бота на C# (.NET) або TypeScript, створення мобільного клієнта з підтримкою WebSocket.
- Тестування: Bot Framework Emulator для юніт-тестів, навантажувальне тестування на 500+ RPS.
- Деплой: Azure Web App з автоскейлінгом, налаштування моніторингу та алертів.
Орієнтири за термінами
Інтеграція з готовим Azure Bot — 3–5 днів. Розробка з нуля (включаючи CLU-модель, діалогову логіку, Azure-інфраструктуру та мобільний клієнт) — 2–4 тижні.
Замовте консультацію — ми покажемо, як заощадити до 40% бюджету на розробці чат-бота.
