Бот-асистент для технічної підтримки в мобільному додатку
Бот технічної підтримки — один з небагатьох випадків, коли LLM виправдовує себе економічно без складного налаштування. При структурованій базі знань RAG (retrieval-augmented generation) дає точні відповіді з мінімальною галюцинацією. Якщо ні — LLM буде вигадувати неіснуючі рішення з впевненим тоном.
RAG як основа бота підтримки
Класична схема: документація, статті бази знань, розв'язані тикети → векторна база → при запиті користувача шукаємо релевантні фрагменти → передаємо в LLM як контекст → модель формулює відповідь на основі реальних даних.
Стек, який добре працює для підтримки:
База знань (Confluence, Notion, MDX файли)
↓ Chunking + Embedding (text-embedding-3-small / BGE-m3)
Qdrant / pgvector
↓ Semantic search (top-5 чанків)
GPT-4o mini / Claude 3.5 Haiku
↓ Answer generation with context
Мобільний клієнт
Критично: чанки повинні бути смисловими, а не механічно розрізаними по 500 символів. Якщо розрізати статтю посередині абзацу, релевантний контекст втратиться. Використовуйте RecursiveCharacterTextSplitter з розділювачами за заголовками та абзацами.
Еска лація до живого оператора
Бот не повинен удавати всезнайство. Якщо confidence нижче порога (або модель явно говорить «не знаю») — еска лація до оператора. Перемикання прозоре: користувач бачить сповіщення «Підключаю спеціаліста», історія діалогу передається оператору.
Інтеграції для передачі в живий чат: Zendesk Chat API, Intercom, AmoCRM, власна система тикетів. Технічно — вебхук з історією діалогу та контактними даними.
Важливий паттерн: бот продовжує працювати у фоні при чеканні оператора. Якщо черга довга, бот спробує знайти відповідь ще раз, пропонує корисні статті поки користувач чекає.
Класифікація та приоритизація тикетів
Якщо бот не розв'язав проблему самостійно, він класифікує звернення перед передачею:
CATEGORY_PROMPT = """
Класифікуй звернення користувача за категорією:
- billing (питання оплати, рахунок, повернення)
- technical (помилки, не працює функція)
- account (аккаунт, пароль, доступ)
- other
Верни тільки назву категорії, без пояснень.
"""
async def classify_ticket(user_message: str) -> str:
response = await openai_client.chat.completions.create(
model="gpt-4o-mini",
messages=[
{"role": "system", "content": CATEGORY_PROMPT},
{"role": "user", "content": user_message}
],
temperature=0
)
return response.choices[0].message.content.strip()
Категорія визначає чергу та пріоритет тикета. temperature=0 — не випадковість: для класифікації потрібна детермінованість, не творчий підхід.
UI особливості для підтримки
Вкладення. Користувачі хочуть прикріплювати скриншоти та відео. На iOS — PHPickerViewController з обмеженням типів медіа, на Android — ActivityResultContracts.GetContent(). Файли загружаються на S3 / Cloudinary, в повідомлення вставляється превью.
Статус тикета. Якщо тикет створено, користувач бачить його номер і може відстежувати через того ж бота: «Статус мого звернення #12345».
Рейтинг відповіді. Після кожної бот-відповіді — thumbs up/down. Дані йдуть в аналітику та допомагають поліпшити базу знань.
Процес розробки
Аудит бази знань: обсяг, формат, актуальність.
Налаштування пайплайну: парсинг документів, chunking, embedding, векторна база.
Розробка системного промпту з інструкцією не виходити за рамки бази знань.
Логіка еска лації та інтеграція з тикет-системою.
Мобільний клієнт з підтримкою вкладень та статусу тикета.
Орієнтири за часом
Бот з RAG на готовій базі знань без інтеграції з тикет-системою — 1 тиждень. Повний бот з RAG, класифікацією, еска лацією до оператора, аналітикою — 3–4 тижні.