Интеграция NLP-движка (Dialogflow) в мобильного чат-бота
Dialogflow CX и Dialogflow ES — разные продукты с разными SDK. Если начать с ES, а потом попытаться мигрировать на CX, придётся переписывать интент-логику с нуля: архитектура 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 вернёт фоллбэк-интент с 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-интент с разными вариантами ответа на непонятные запросы
- Добавить Small Talk как отдельный поток — иначе бот грубо игнорирует неформальные реплики
- Webhook fulfillment для динамических ответов (статус заказа, остаток на складе)
Тренировочные фразы: минимум 10–15 вариантов на интент, иначе confidence будет низким на естественной речи.
Процесс работы
Аудит сценариев: какие задачи решает бот, какие крайние случаи нужно обработать.
Проектирование агента в Dialogflow Console: интенты, сущности, контексты / flows и pages для CX.
Разработка прокси-сервера и мобильного UI.
Тренировка и тестирование через Dialogflow Simulator перед выходом в прод.
Ориентиры по срокам
Интеграция с готовым агентом — 3–4 дня. Разработка агента с нуля для 5–10 сценариев + мобильный клиент — 1,5–2 недели.