Внедрение RAG-системы для AI-бота
RAG решает конкретную проблему: модель не знает ваш продукт, вашу документацию, ваши внутренние регламенты. Дообучение дорого и медленно обновляется. RAG — дешевле, актуальнее, прозрачнее. Пользователь задаёт вопрос → система ищет релевантные фрагменты документации → передаёт их в контекст модели → модель отвечает на основе реальных данных. Наш опыт показывает, что качественно реализованный RAG повышает точность ответов до 95% и снижает нагрузку на поддержку на 40–50%.
В отличие от традиционных чат-ботов, RAG-бот использует живую базу знаний: вы добавляете или меняете документы — бот сразу отвечает по обновлённой информации. Это особенно важно для мобильных приложений с часто меняющимися тарифами, продуктами или условиями. Мы внедрили RAG-системы для 15+ проектов, включая мобильные приложения с чувствительными данными. Наша команда имеет 8+ лет опыта в мобильной разработке (iOS, Android, Flutter) и серверной архитектуре. Гарантируем прозрачность: вы видите, откуда берётся каждый ответ. Среднее время ответа RAG-бота составляет 1–3 секунды, включая поиск и генерацию, что соответствует ожиданиям пользователей.
Техника описана в работе Lewis et al.
Проблемы, которые решает RAG
Первая и главная — галлюцинации модели. Без контекста LLM может выдумать несуществующие функции или параметры. RAG фиксирует ответы на вашей документации.
Вторая — актуальность данных. Переобучать модель каждый раз при изменении документации дорого и долго. RAG подтягивает последнюю версию из базы знаний.
Третья — доверие пользователей. Мобильный чат-бот с RAG показывает источники ответа — пользователь может проверить информацию. Это снижает количество эскалаций.
Компоненты RAG-системы
Ingestion, Retrieval, Generation — как они связаны
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.
Что лучше: hybrid search или чистый векторный?
Hybrid search — комбинация векторного поиска и BM25 (keyword search) даёт лучшие результаты, чем только векторный. Pgvector + pg_trgm позволяют делать это в PostgreSQL без отдельной инфраструктуры.
Reranking — после vector search берём топ-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.
Состав работ по внедрению RAG
- Аудит корпуса документов и проектирование схемы индексации
- Выбор и развёртывание векторной БД (Pgvector, Qdrant, Pinecone — под ваш стек)
- Реализация ingestion pipeline с семантическим chunking и overlap
- Настройка hybrid search + reranking для максимальной релевантности
- Интеграция с LLM (OpenAI, GPT-4, Claude, YandexGPT или self-hosted)
- Мобильный чат-UI с стримингом, источниками и эскалацией
- Документация по эксплуатации и обучение команды
- Оценка качества метриками RAGAS
Закажите аудит вашей базы знаний — мы проанализируем документы и предложим план внедрения RAG. Свяжитесь с нами для консультации. Напишите нам, чтобы получить детальный план.
Сроки и ориентиры
| Этап | Срок |
|---|---|
| Аудит и проектирование | 1 неделя |
| Реализация пайплайна | 2–3 недели |
| Интеграция и UI | 2–4 недели |
| Тестирование и доработка | 1–2 недели |
Базовый RAG-бот с простой документацией — от 3 недель. Продакшен-система с hybrid search, reranking, мультиязычностью и оценкой качества — до 12 недель. Точные сроки зависят от объёма документов и сложности интеграции.
Типичные ошибки при внедрении RAG
- Игнорирование предобработки документов: PDF с картинками, сканы, таблицы — требуют OCR и очистки.
- Отсутствие метаданных: без фильтрации по дате или разделу качество поиска падает.
- Недостаточное тестирование: используйте метрики RAGAS — точность, релевантность, faithfulness.
- Пренебрежение безопасностью: настройте фильтрацию контекста, чтобы модель не выдавала чувствительные данные.
RAG — это не одна модель, а система из множества компонентов. Обратитесь к специалистам с опытом: мы поможем избежать типовых ошибок и внедрить решение, которое будет работать надёжно.