Реализация 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 недель.