Інтеграція NLP-движка (Dialogflow) у мобільного чат-бота
Ми часто бачимо проекти, де інтеграція Dialogflow починається без чіткого розуміння відмінностей між ES та CX. Клієнти обирають ES через простоту, а через півроку стикаються з необхідністю переписувати всю інтент-логіку — архітектура State Machine в CX несумісна з лінійним Flow з ES. Наше завдання — допомогти обрати версію та налаштувати інтеграцію так, щоб бот працював стабільно з першого релізу. Досвід — більше 5 років на ринку мобільної розробки, гарантуємо якість на кожному етапі.
Чому вибір версії Dialogflow критичний?
Dialogflow CX і Dialogflow ES — це два принципово різних продукти. ES використовує лінійний потік: інтенти обробляються послідовно, контексти живуть обмежену кількість реплік. CX побудований на State Machine: кожен крок — це сторінка (page) з явними переходами. Міграція з ES на CX вимагає повного перепроектування агента. CX краще підходить для складних багатокрокових сценаріїв (оформлення замовлення, техпідтримка), а ES — для простих відповідей на запитання. Який варіант обрати — залежить від ваших сценаріїв; ми пропонуємо аудит перед початком розробки.
Як налаштувати автентифікацію без ризику для безпеки?
Офіційна документація Google Cloud пропонує використовувати сервісний акаунт JSON безпосередньо в додатку. Це неприйнятно — приватний ключ опиниться в APK/IPA. Правильний шлях: мобільний додаток надсилає текст на ваш бекенд, бекенд спілкується з Dialogflow через бібліотеку google-cloud-dialogflow з сервісним акаунтом. Ми реалізуємо проксі-сервер на Node.js або Python, який обробляє запити та повертає відповіді. Приклад на Node.js:
const { SessionsClient } = require('@google-cloud/dialogflow-cx');
const client = new SessionsClient();
async function detectIntent(projectId, location, agentId, sessionId, text, languageCode) {
const sessionPath = client.projectLocationAgentSessionPath(
projectId, location, agentId, sessionId
);
const request = {
session: sessionPath,
queryInput: {
text: { text },
languageCode,
},
};
const [response] = await client.detectIntent(request);
return response.queryResult;
}
Як вирішити проблеми багатомовності та контексту?
Dialogflow підтримує кілька мов на одному агенті, але тренувальні фрази для кожної мови додаються окремо. Якщо передати languageCode: ru для агента без російських фраз, Dialogflow поверне фолбек-інтент з низьким confidence — користувач не зрозуміє відповідь. Ми налаштовуємо мовні набори та тестуємо їх через симулятор.
Управління контекстом — часта причина помилок. В ES контексти живуть N реплік після встановлення. Якщо не скинути контекст після завершення сценарію, користувач отримає неочікувану відповідь. В CX ця проблема вирішується явними переходами між сторінками. Наші інженери проектують потоки так, щоб кожен сценарій закінчувався скиданням контексту для всіх активних діалогів.
Реалізація на мобільній стороні
На Android використовуємо OkHttp або Retrofit для виклику проксі-сервера. Session ID генеруємо один раз при старті сесії та зберігаємо в пам'яті — не в SharedPreferences, сесії не повинні переживати перезапуск додатку.
class DialogflowRepository(private val api: ChatApiService) {
private val sessionId = UUID.randomUUID().toString()
suspend fun sendMessage(text: String, locale: String): ChatResponse {
return api.detectIntent(
DetectIntentRequest(
sessionId = sessionId,
text = text,
languageCode = locale
)
)
}
}
На iOS — аналогічно через URLSession або Alamofire. Жодного прямого звернення до Google API з клієнта. Для відображення Rich responses (картки, кнопки, каруселі) розбираємо fulfillmentMessages та рендеримо відповідні view-компоненти: TextBubbleCell, ButtonsRowCell, CardCell.
Проектування агента: практичні рекомендації
Для продакшн-бота потрібно:
- Розділити інтенти за доменами (замовлення, підтримка, FAQ) і згрупувати їх
- Налаштувати fallback-інтент з кількома варіантами відповіді (не менше 5)
- Додати Small Talk як окремий потік — інакше бот грубо ігнорує неформальні репліки
- Webhook fulfillment для динамічних відповідей (статус замовлення, залишок на складі)
- Тренувальні фрази: мінімум 10–15 варіантів на інтент, інакше confidence буде низьким на природній мові. Ми використовуємо автоматичну генерацію синонімів для збільшення покриття.
Порівняння Dialogflow ES та CX
| Критерій | Dialogflow ES | Dialogflow CX |
|---|---|---|
| Архітектура | Лінійний потік інтентів | State Machine зі сторінками та переходами |
| Складні сценарії | Важко підтримувати | Оптимізовані завдяки вбудованому State Machine |
| Контекст | Обмежений N реплік, вручну скидати | Явні переходи, контекст керується автоматично |
| A/B тестування | Немає | Вбудований A/B тест для маршрутів |
| Версіонування | Ручне (експорт/імпорт) | Вбудовані версії та середовища |
| Вартість | Безкоштовно до лімітів | Платний, але ефективніший для складних ботів |
CX краще ES для багатокрокових сценаріїв щонайменше в 2 рази за швидкістю розробки та стабільністю. Економія бюджету на переписування — до 50% при правильному виборі з самого початку.
Що входить в нашу роботу?
- Аудит поточних сценаріїв та формулювання вимог
- Вибір версії Dialogflow (ES або CX) з обґрунтуванням
- Проектування агента: інтенти, сутності, контексти, flows/pages
- Розробка проксі-сервера (Node.js/Python) з автентифікацією
- Інтеграція SDK в мобільний додаток (Android Kotlin, iOS Swift)
- Налаштування webhook fulfillment під вашу CRM/базу даних
- Тестування через Dialogflow Simulator та на реальних пристроях
- Документація з обслуговування (доступи, скрипти, конфіги)
- Навчання команди роботі з агентом
Додаткові рекомендації з тестування
Використовуйте Dialogflow Simulator для перевірки кожного інтенту з різними формулюваннями. Переконайтеся, що confidence перевищує 0.7 для всіх цільових інтентів. Перевірте обробку помилкових сценаріїв.Як ми працюємо: етапи
- Аналітика — розбираємо сценарії, збираємо приклади діалогів, визначаємо крайні випадки.
- Проектування — малюємо карту діалогів, затверджуємо з клієнтом.
- Реалізація — створюємо агента, пишемо проксі, інтегруємо в клієнт.
- Тренування та тестування — мінімум 50 тестових діалогів на мову.
- Деплой — публікація в App Store / Google Play, налаштування моніторингу.
Орієнтири за термінами
- Інтеграція з готовим агентом: від 3 до 4 днів (включаючи налаштування проксі та клієнта).
- Розробка агента з нуля для 5–10 сценаріїв + мобільний клієнт: від 1,5 до 2 тижнів.
- Підтримка після запуску: за запитом, з гарантією відлагодження знайдених помилок протягом місяця.
Зв'яжіться з нами для оцінки вашого проекту — ми підберемо оптимальне рішення під ключ.