RAG для бизнеса: зачем он нужен и чем отличается от большого контекста
Retrieval-Augmented Generation - это не «загрузить PDF в чат». Это инженерная система: чанкинг, гибридный поиск, reranking, метрики качества. Разбираем архитектуру, точки отказа и почему большой контекст не заменяет retrieval - а дополняет его.
Что такое RAG и зачем он бизнесу
RAG (Retrieval-Augmented Generation) - подход, при котором LLM отвечает не только на основе своих параметров, но и на основе внешних источников, найденных в момент запроса. Сначала система находит релевантные документы или фрагменты, а потом модель использует их для ответа.
У обычной LLM три ограничения: знает только то, на чём обучалась; не знает ваши внутренние документы; может звучать уверенно, даже когда ошибается. RAG закрывает эти проблемы: знания обновляются без переобучения, ответ опирается на конкретные источники, а не на память модели.
По данным на 2026 год, 71% организаций регулярно используют генеративный ИИ в как минимум одной бизнес-функции. RAG - стандартный инструмент для тех, кому нужны ответы по внутренним документам: регламентам, техдокументации, договорам, базам знаний и support-процессам.
Из чего состоит нормальный RAG
Ingestion: документы в порядок
Убрать мусор, распознать PDF, извлечь структуру, сохранить метаданные и версии. 80% отказов RAG - на этапе ingestion, а не в модели.
Чанкинг: нарезать осмысленно
Рекомендуемый размер: 300 - 500 токенов с 10 - 20% перекрытием. Неправильный чанкинг даёт до 9% разницы в recall между лучшим и худшим методом.
Индексация: embedding + поиск
Эмбеддинги через bge-large, text-embedding-3 или multilingual. Хранение в Qdrant, Milvus, Pinecone, Weaviate. Гибридный поиск: BM25 + dense.
Reranking: отсеять шум
Cross-encoder (bge-reranker, Cohere) переранжирует top-N результатов. Reranking - «секретный соус» production RAG, поднимает precision на 10 - 20%.
Guardrails: защита от инъекций
OWASP: RAG не решает prompt injection автоматически. Фильтры на входе, политика источников, валидация retrieved-чанков до подачи модели.
Метрики: не «вроде лучше»
RAGAS: faithfulness, context precision, context recall, answer relevance. Без метрик вы не знаете, работает ли RAG или просто красиво пишет.
Почему большой контекст не заменяет RAG
Lost in the Middle
Исследование «Lost in the Middle» показало: даже у моделей с длинным контекстом качество ответа падает, когда важная информация оказывается в середине окна. Модель видит текст, но не фокусируется на нём.
Шум и стоимость
Чем больше текста в контексте, тем больше шума, повторов и устаревших версий. Вы платите за лишние токены, дольше ждёте ответ - и не всегда получаете лучшую точность. На 1M контексте DeepSeek V4-Flash стоит $0.14/M input - кажется дёшево, пока вы не загружаете туда весь архив ежедневно.
RAG + длинный контекст = лучший результат
Аналитика 2026 года (Toolhalla, Open-Techstack) показывает: комбинация RAG и длинного контекста превосходит каждый подход по отдельности в 7 из 8 enterprise-сценариев. RAG выбирает релевантное, а длинный контекст даёт модели больше рабочей памяти для сложных цепочек рассуждений.
Практическое правило
Если документов мало и вы точно знаете, что подавать модели - длинный контекст. Если данных много, они меняются, есть права доступа и важно цитирование - RAG. В большинстве реальных проектов - гибрид.
RAG vs длинный контекст: когда что использовать
| Критерий | RAG | Длинный контекст | Гибрид |
|---|---|---|---|
| Объём данных | Тысячи документов | Десятки документов | Большая база + контекст для сложных цепочек |
| Обновление данных | Без переиндексации модели | Каждый раз грузить заново | RAG для свежего, контекст для стабильного |
| Точность поиска | Высокая (reranking) | Зависит от позиции в окне | RAG для поиска, контекст для удержания |
| Стоимость | Ниже на больших объёмах | Растёт линейно с объёмом | Баланс: платить за нужное |
| Цитирование | Конкретный источник | Весь документ в окне | Источник из RAG, контекст из окна |
| Права доступа | На уровне чанков | На уровне документа | Комбинированное управление |
Главная ошибка: забыть про ingestion
80% отказов RAG - не в модели и не в retrieval, а на этапе ingestion. Грязные документы, дубликаты, устаревшие версии, потеря структуры после OCR, отсутствие метаданных. Если в индексе мусор - никакой reranker не спасёт. Чистые данные и правильный чанкинг важнее выбора векторной базы.
Что ломает RAG и как это чинить
Грязный индекс
Дубликаты, старые версии, OCR-артефакты. Решение: пайплайн очистки, dedup, версионирование, metadata-фильтры.
Слабый retrieval
Только dense - теряет ключевые слова. Решение: гибридный поиск BM25 + dense, reciprocal rank fusion, cross-encoder reranker.
Плохой чанкинг
Фиксированный размер режет по середине мысли. Решение: семантический или структурный чанкинг, 300 - 500 токенов, 10 - 20% overlap.
Нет tool-use
Один retrieval-проход на сложный вопрос. Решение: agentic RAG - итеративный поиск, уточнение запроса, добор контекста.
Prompt injection
Внешний текст содержит скрытые инструкции. Решение: фильтры на входе, валидация чанков, ограничение источников.
Нет метрик
«Вроде работает» - не метрика. Решение: RAGAS (faithfulness, context precision), регулярный eval на реальных вопросах.
Метрики, agentic RAG и как мы строим
RAGAS: четыре вопроса к системе
RAGAS - стандарт оценки RAG в 2026 году. Четыре ключевых метрики:
- Faithfulness: опирается ли ответ на найденный контекст, а не на галлюцинации.
- Context Precision: насколько найденные чанки релевантны запросу (а не просто похожи).
- Context Recall: все ли нужные фрагменты попали в контекст.
- Answer Relevance: насколько ответ полезен для пользователя.
Важный нюанс: система может показать faithfulness 0.95 и всё равно отвечать неправильно, если индекс содержит устаревшие данные. Метрики retrieval и генерации нужно смотреть вместе.
Agentic RAG: когда модель сама решает
В классическом RAG система делает один retrieval-проход и подаёт результаты модели. Agentic RAG идёт дальше: модель сама решает, что искать, в каком порядке, и достаточно ли найденного. Это не статичный кусок контекста, а итеративный цикл: поиск → оценка → уточнение запроса → повторный поиск → ответ.
Такой подход лучше для сложных вопросов, где ответ собирается из нескольких источников. Подробнее - в статье ИИ-агенты с tool-use.
Как мы проектируем RAG
Мы начинаем не с векторной базы, а с вопроса: какие данные вообще должны отвечать на запрос. Дальше по цепочке:
1. Определяем сценарии и типы вопросов.
2. Разбираем источники, версии и права доступа.
3. Нормализуем документы: очистка, структура, метаданные.
4. Выбираем чанкинг и гранулярность под тип документов.
5. Строим retrieval: гибридный поиск, reranker, фильтры.
6. Добавляем guardrails и цитирование.
7. Тестируем на реальных вопросах бизнеса.
8. Подключаем RAGAS-мониторинг и журналирование.
И только после этого RAG превращается из красивой идеи в рабочий инструмент. Для частных LLM это особенно важно: данные не покидают периметр, retrieval работает в том же контуре, что и модель.
Спроектируем RAG под ваши данные
Мы строим RAG-системы в закрытом контуре: от аудита документов до промышленного retrieval с гибридным поиском, reranking, метриками и интеграцией с 1С, CRM, ERP. Опишите задачу - покажем архитектуру и план пилота.