Інтеграція NLP-движка (Rasa) в мобільного чат-бота
Rasa — це self-hosted NLP-стек: ви контролюєте модель, дані та інфраструктуру. Саме тому його вибирають для проектів з чутливими даними або нестандартною предметною областю. Але «self-hosted» означає й те, що налаштування pipeline доведеться робити самостійно — стандартний конфіг дає посередню точність на російській мові.
Rasa NLU pipeline для російської
Стандартний конфіг з WhitespaceTokenizer на російській працює погано: російська морфологія складніша за англійську, форми одного слова сприймаються як різні токени. Робочий конфіг для російськомовного бота:
language: ru
pipeline:
- name: SpacyNLP
model: ru_core_news_md
- name: SpacyTokenizer
- name: SpacyFeaturizer
- name: RegexFeaturizer
- name: LexicalSyntacticFeaturizer
- name: CountVectorsFeaturizer
- name: CountVectorsFeaturizer
analyzer: char_wb
min_ngram: 1
max_ngram: 4
- name: DIETClassifier
epochs: 150
- name: EntitySynonymMapper
- name: ResponseSelector
epochs: 100
- name: FallbackClassifier
threshold: 0.7
ambiguity_threshold: 0.1
spacy з моделлю ru_core_news_md + char n-gram фічі від CountVectorsFeaturizer — це базова комбінація, яка дає розумну точність на коротких фразах з продакшену. DIETClassifier з 150 епохами зазвичай достатньо для 20–50 інтентів.
Rasa Core: управління діалогом
Rasa розділяє NLU (розуміння намірів) та Core (управління діалогом). Core працює на основі правил (rules.yml) та історій (stories.yml). Найчастіша помилка — спробувати описати всі сценарії через rules і отримати крихку систему, яка ломається на нестандартному порядку реплік.
Правило: жорсткі команди (скасування, допомога, почати заново) — в rules. Багатокрокові сценарії з варіативністю — в stories. Rasa Core навчається на історіях та узагальнює сценарії, які явно не бачила — це його головна перевага перед деревами рішень.
Custom Actions. Динамічні відповіді (статус замовлення, доступні слоти) реалізуються через action_server — окремий Python-сервіс, який Rasa викликає через HTTP. Мобільний додаток з цим не взаємодіє напряму:
class ActionCheckOrderStatus(Action):
def name(self) -> str:
return "action_check_order_status"
async def run(self, dispatcher, tracker, domain) -> list:
order_id = tracker.get_slot("order_id")
status = await order_service.get_status(order_id)
dispatcher.utter_message(text=f"Ваше замовлення #{order_id}: {status}")
return [SlotSet("order_status", status)]
Інтеграція з мобільним додатком
Rasa Server надає REST-канал на /webhooks/rest/webhook. Мобільний додаток відправляє POST-запит:
{
"sender": "user_device_id_or_session_uuid",
"message": "текст повідомлення"
}
Відповідь — масив повідомлень, кожне з яких може бути текстом, зображенням, кнопками або кастомним payload.
На Android це стандартний Retrofit-виклик. Важливий момент: sender повинен бути стабільним ідентифікатором сесії — Rasa зберігає слоти (slots) між запитами в межах одного sender. Якщо генерувати новий ID кожен раз, контекст діалогу втратиться.
Для продакшену Rasa не варто відкривати напряму в інтернет — перед ним ставимо nginx з rate limiting та автентифікацією по токену.
Розгортання
Rasa Server + Action Server зручно запускати в Docker Compose. Модель тренується командою rasa train та монтується в контейнер. На скромному VPS тренування 50 інтентів займає 5–10 хвилин — цілком прийнятно для CI/CD.
Rasa Enterprise (комерційна версія) додає аналітику та A/B тестування діалогів, але для більшості завдань достатньо open-source версії.
Процес розробки
Аудит предметної області, збір прикладів реплік для NLU-датасету.
Налаштування pipeline, тренування базової моделі, оцінка точності через rasa test.
Розробка діалогових сценаріїв (rules + stories), custom actions.
Інтеграція REST-каналу з мобільним клієнтом, налаштування інфраструктури.
Орієнтири за часом
Інтеграція з готовим Rasa-сервером — 3–4 дні. Повний цикл включно з тренуванням моделі з нуля, написанням сценаріїв та розгортанням — 2–4 тижні залежно від кількості інтентів.