Реалізація RAG (Retrieval-Augmented Generation) для AI-бота у мобільному додатку
RAG вирішує конкретну проблему: модель не знає вашого продукту, вашу документацію, ваші внутрішні регламенти. Дообучення—дорого та повільно оновляється. RAG—дешевше, актуальніше, прозоріше. Користувач задає запитання → система шукає релевантні фрагменти документації → передає їх у контекст моделі → модель відповідає на основі реальних даних.
Компоненти RAG-системи та де вони живуть
RAG—це не одна функція, а пайплайн з кількох етапів:
Ingestion (завантаження та індексація):
- Розбивка документів на чанки (chunking)
- Створення еквалайзирів для кожного чанку
- Збереження у векторну БД
Retrieval (пошук):
- Еквалайзир користувацького запиту
- Векторний пошук (cosine similarity / ANN)
- Reranking результатів (опціонально)
Generation (генерація):
- Формування промпту з контекстом
- Виклик LLM
- Постобробка ответу
На мобільному весь Ingestion та більшість Retrieval—серверна задача. Клієнт робить запит до API, отримує ответ з джерелами.
Chunking: найнедооцінений етап
Якість RAG визначається якістю чанків. Погане chunking убиває точність незалежно від моделі.
Фіксований chunking (по 500 символів)—не робіть так. Розривує речення, теряє контекст абзаців.
Семантичний chunking—розбивка по смисловим границям (заголовки, абзаци, речення). Для Markdown та HTML працює за замовчуванням. Бібліотека LangChain4j на Java/Kotlin надає RecursiveCharacterTextSplitter з розділювачами ["\n\n", "\n", ". "]—це правильний підхід.
Overlap—перекриття 10–20% між чанками: останні 50–100 токенів попереднього чанку включаються в початок наступного. Це зберігає контекст на границях.
Оптимальний розмір чанку залежить від типу документа: для технічної документації—300–500 токенів, для юридичних текстів—500–800 токенів, для FAQ—чанк = одне запитання+ответ.
Еквалайзири: вибір моделі
| Модель | Розмірність | Контекст | Вартість | Підходить для |
|---|---|---|---|---|
| text-embedding-3-small | 1536 | 8192 | Дешево | Загальний контент |
| text-embedding-3-large | 3072 | 8192 | Середньо | Технічна документація |
| nomic-embed-text | 768 | 8192 | Безплатно (self-host) | Приватні дані |
| multilingual-e5-large | 1024 | 512 | Безплатно (self-host) | Мультиязичний контент |
Для мобільного додатку з чутливими даними—self-hosted модель. OpenAI Embeddings відправляють документи на сервера OpenAI.
Retrieval: що реально впливає на якість
Hybrid search—комбінація векторного пошуку та BM25 (keyword search) дає кращі результати, ніж тільки векторний. Pgvector + pg_trgm дозволяють робити це у PostgreSQL без окремої інфраструктури.
Reranking—після vectorsearch беремо топ-20 результатів, прогоняємо через cross-encoder модель (cross-encoder/ms-marco-MiniLM-L-6-v2), повертаємо топ-5. Це суттєво покращує релевантність. Cohere Rerank API—якщо не хочете self-hosted модель.
Metadata filtering—якщо у документів є метадані (дата, раздел, мова, тип документа), фільтруйте за ними до векторного пошуку. Пошук по векторам серед 10 тисяч релевантних чанків замість мільйона—швидше та точніше.
Формування промпту з контекстом
System: Ти асистент продукту. Відповідай ТІЛЬКИ на основі наданого контексту.
Якщо ответу нема у контексті—скажи про це прямо.
Контекст:
[Чанк 1]: <текст>
[Чанк 2]: <текст>
[Чанк 3]: <текст>
User: Як налаштувати двофакторну аутентифікацію?
Указувати джерела—хороша практика. На мобілі показувати список чанків/документів під ответом: користувач може перевірити, звідки інформація. Це знижує hallucination risk та підвищує довіру.
Мобільний UI для RAG-бота
Особливості рендеринга ответу:
- Потік через SSE—ответ з'являється поступово
- Джерела під ответом (коллапс-список)
- Індикатор «шукаю у базі знань» під час Retrieval (100–300 мс)
- Кнопка «Не знайшов ответу» для ескалації до оператора
На Flutter: flutter_markdown для рендеринга ответу, кастомний віджет для джерел. На iOS: UILabel з NSAttributedString або UITextView + WKWebView для Markdown. На Android: Markwon—найкращий Markdown-рендерер для RecyclerView.
Етапи та сроки
Аудит корпусу документів → проектування схеми індексації → вибір векторної БД → реалізація ingestion pipeline → настройка hybrid search + reranking → інтеграція з LLM → мобільний чат-UI з джерелами → оцінка якості (RAGAS або ручна) → ітерація по промптам та chunking.
Базовий RAG-бот з простою документацією—3–5 тижнів. Продакшен-система з hybrid search, reranking, мультиязичністю та оцінкою якості—8–12 тижнів.