Інтеграція NLP-движка (Dialogflow) в мобільного чат-бота
Dialogflow CX та Dialogflow ES — різні продукти з різними SDK. Якщо почати з ES, а потім спробувати мігрувати на CX, доведеться переписувати intent-логіку з нуля: архітектура State Machine в CX несумісна з лінійним Flow з ES. Вибір версії на початку проекту критичний.
Де ломається інтеграція
Автентифікація в мобільному клієнті. Офіційна документація Google пропонує використовувати сервісний аккаунт JSON безпосередньо в додатку. Це неприйнятно — приватний ключ опиниться в APK/IPA. Правильний шлях: мобільний додаток відправляє текст на ваш бекенд, бекенд спілкується з Dialogflow через бібліотеку google-cloud-dialogflow з сервісним аккаунтом.
Для мінімального прокси на 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 повертає fallback-intent з confidence: 0.5 — користувач не зрозуміє, чому бот відповідає невпопад.
Управління контекстом. У Dialogflow ES контексти живуть N реплік після установки. Найчастіша помилка — не скидати контекст після завершення сценарію. Користувач закінчив оформлення замовлення, потім запитав про акції — а бот продовжує чекати адресу доставки, тому що контекст order-address все ще активний.
У CX ця проблема розв'язується явними переходами між сторінками (pages) та потоками (flows), але вимагає більш уважного проектування сценаріїв.
Реалізація на мобільній стороні
На 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. Dialogflow вміє повертати карточки, кнопки швидких відповідей, carousel. На мобільному клієнті це розбирається з fulfillmentMessages / responseMessages у відповіді. Кожен тип повідомлення рендерується окремим view-компонентом: TextBubbleCell, ButtonsRowCell, CardCell.
Проектування агента
Dialogflow-агент — це не просто дерево інтентів. Для продакшн-бота потрібно:
- Розділити інтенти за доменами (замовлення, підтримка, FAQ) та згрупувати їх
- Налаштувати fallback-intent з різними варіантами відповіді на незрозумілі запити
- Додати Small Talk як окремий потік — інакше бот грубо ігнорує неформальні репліки
- Webhook fulfillment для динамічних відповідей (статус замовлення, залишок на складі)
Тренувальні фрази: мінімум 10–15 варіантів на інтент, інакше confidence буде низьким на природній мові.
Процес розробки
Аудит сценаріїв: які завдання вирішує бот, які крайні випадки потрібно обробити.
Проектування агента в Dialogflow Console: інтенти, сутності, контексти / flows та pages для CX.
Розробка прокси-сервера та мобільного UI.
Тренування та тестування через Dialogflow Simulator перед виходом у прод.
Орієнтири за часом
Інтеграція з готовим агентом — 3–4 дні. Розробка агента з нуля для 5–10 сценаріїв + мобільний клієнт — 1,5–2 тижні.