LLM знают много, но не знают ваших данных: внутреннюю документацию, базу знаний, историю переписок с клиентами. RAG (Retrieval-Augmented Generation) решает эту проблему: модель находит релевантные фрагменты из ваших документов и использует их для генерации ответа. Разберём архитектуру, инструменты и подводные камни.
Как работает RAG
Классическая RAG-система состоит из четырёх этапов:
- Индексация — документы разбиваются на чанки (фрагменты по 200–500 токенов), каждый чанк преобразуется в вектор (embedding) и сохраняется в векторную базу данных
- Запрос — пользователь задаёт вопрос, вопрос тоже преобразуется в вектор
- Поиск — система находит топ-N чанков, наиболее семантически близких к вопросу
- Генерация — найденные чанки подставляются в контекст LLM, модель генерирует ответ на их основе
Компоненты RAG-пайплайна
| Компонент | Популярные инструменты | На что влияет |
|---|---|---|
| Embedding-модель | OpenAI text-embedding-3, Cohere Embed, E5, BGE | Качество семантического поиска |
| Векторная база | Pinecone, Weaviate, Qdrant, Chroma, pgvector | Скорость поиска, масштабируемость |
| Chunking-стратегия | Fixed-size, recursive, semantic splitting | Релевантность найденных фрагментов |
| LLM | GPT-4, Claude, Llama, Mistral | Качество генерации ответа |
| Оркестратор | LangChain, LlamaIndex, Haystack | Гибкость и простота интеграции |
Chunking: как правильно разбивать документы
Качество RAG на 60% зависит от качества чанкинга. Слишком маленькие чанки теряют контекст. Слишком большие — включают нерелевантную информацию и тратят контекстное окно модели.
Стратегии чанкинга:
- Fixed-size с перекрытием — 400 токенов с overlap 50 токенов. Простейший подход, работает для однородных текстов
- Recursive splitting — разбивает по заголовкам, абзацам, предложениям. Учитывает структуру документа. Реализован в LangChain из коробки
- Semantic chunking — использует embedding для определения границ тем. Точнее, но дороже в вычислениях
- Parent-child — маленькие чанки для точного поиска, большие — для контекста. При нахождении маленького чанка в контекст LLM подставляется его «родительский» документ
Улучшение качества ответов
Базовый RAG часто недостаточно точен. Продвинутые техники:
- Hybrid search — комбинация векторного поиска (семантика) и BM25 (ключевые слова). Покрывает случаи, когда семантическое сходство не совпадает с лексическим
- Reranking — после первичного поиска переранжируйте результаты с помощью cross-encoder модели (Cohere Rerank, BGE-reranker). Значительно повышает точность
- Query transformation — перефразируйте запрос пользователя для улучшения поиска. Генерируйте несколько вариантов запроса и объединяйте результаты
- Metadata filtering — добавляйте метаданные к чанкам (дата, автор, категория) и фильтруйте перед поиском. «Найди в документации за 2026 год» — сужает поиск до релевантных документов
Типичные ошибки
- Нет оценки качества — без метрик (precision, recall, faithfulness) невозможно понять, работает ли RAG корректно. Используйте RAGAS или DeepEval для автоматической оценки
- Одна стратегия чанкинга для всех документов — PDF-таблицы, код и длинные тексты требуют разного подхода к разбиению
- Игнорирование hallucinations — даже с RAG модель может додумывать факты. Добавьте в системный промпт: «Отвечай только на основе предоставленного контекста. Если информации недостаточно — скажи об этом»
- Слишком много чанков в контексте — 20 чанков по 500 токенов = 10 000 токенов контекста. Модель теряется в избытке информации. Оптимум — 3–7 наиболее релевантных чанков
Когда RAG не нужен
RAG — не универсальное решение. Если данных мало (до 50 страниц) — проще передать весь текст в контекстное окно модели. Если данные структурированные (таблицы, SQL) — лучше использовать Text-to-SQL подход. Если нужна точная, детерминированная логика — RAG не гарантирует точности, традиционный поиск надёжнее.
RAG — мощный инструмент для работы с неструктурированными корпоративными данными. Но как любой инструмент, он требует настройки, тестирования и мониторинга. Начните с простого пайплайна, замерьте качество — и улучшайте итеративно.