Как работает RAG: три шага
Шаг 1 — индексация. Документы (PDF, Word, страницы CMS) разбиваются на фрагменты по 200–500 токенов, каждый фрагмент преобразуется в числовой вектор через модель эмбеддингов и сохраняется в векторной базе данных (Qdrant, Weaviate, pgvector).
Шаг 2 — retrieval. Запрос пользователя также преобразуется в вектор. Векторная база находит 3–10 наиболее похожих фрагментов за 20–50 мс.
Шаг 3 — generation. Найденные фрагменты вставляются в промпт вместе с вопросом пользователя. LLM формирует ответ, опираясь только на этот контекст.
В проекте для медицинской базы знаний RAG-бот отвечает на 94% вопросов без эскалации на оператора. База: 2 300 документов, время ответа — 3–4 секунды. Подробнее о PapAI MedScale.
RAG или Fine-tuning: что выбрать
RAG дешевле и гибче: обновить базу знаний можно за минуты без переобучения модели. Fine-tuning меняет поведение самой модели — стиль, формат, специфическую терминологию — но требует минимум 500–1000 примеров и недель работы. Для большинства корпоративных ботов, которым нужно отвечать по документам компании, RAG — правильный выбор.
Качество RAG: что влияет на точность
Размер чанка (фрагмента): слишком маленький — теряется контекст, слишком большой — заполняет контекстное окно нерелевантным текстом. Качество эмбеддинг-модели: для русского языка лучше работают модели, обученные на русскоязычном корпусе (например, rubert-tiny2 или E5-multilingual). Гибридный поиск (вектор + BM25 keyword) повышает recall на 15–20% по сравнению с чисто векторным.
Как устроена RAG-система на практике
В типовой RAG-архитектуре для корпоративного чат-бота: (1) документы компании разбиваются на чанки по 512–1024 токена, (2) каждый чанк переводится в векторное представление через модель эмбеддингов, (3) векторы хранятся в специализированной БД (Qdrant, Weaviate, pgvector), (4) при вопросе пользователя — вопрос тоже переводится в вектор, ищутся ближайшие чанки, (5) найденные фрагменты передаются LLM как контекст. Ответ модели опирается только на найденные данные, а не на "знания" модели из обучения.
Когда RAG не помогает
- Плохая база знаний. Если документы противоречат друг другу или устарели — бот будет путаться. Качество ответов = качество базы.
- Слишком большие чанки. Чанки по 5–10 страниц дают плохой поиск. Оптимум — 400–800 слов с перекрытием.
- Только семантический поиск. Точные номера, артикулы, даты лучше ищутся через полнотекстовый индекс. Нужен гибридный подход.
Сергей Полухин
Co-Founder & CTO PapAI Soft · профиль
Частые вопросы
Как часто нужно обновлять базу знаний в RAG?
Зависит от частоты изменений в источнике. Прайс-листы и акции — ежедневно через API. Регламенты и инструкции — при каждом обновлении документа, через автоматический триггер из системы документооборота. Статичные FAQ — по мере накопления новых вопросов от пользователей.
Какой размер чанка выбрать для векторной базы?
Оптимум — 400–800 слов с перекрытием 10–20% между соседними чанками. Слишком маленькие чанки (менее 100 слов) теряют контекст, слишком большие (более 2000 слов) снижают точность поиска. Для структурированных данных (таблицы, прайсы) лучше хранить полные строки, а не части.
Связанные термины
- LLM — языковая модель, которая генерирует ответ в RAG
- Fine-tuning — альтернатива RAG для изменения поведения модели
- Контекстное окно — ограничение, которое определяет, сколько документов войдёт в промпт
- Промпт-инжиниринг — как правильно вставить найденные документы в промпт
Где применяется
Хотите подключить RAG к корпоративной базе знаний? Обсудим задачу.
Связаться с нами