Что такое RAG (Retrieval-Augmented Generation) — архитектурный подход, при котором большая языковая модель перед ответом сначала извлекает релевантные фрагменты из внешней базы знаний (документы, FAQ, регламенты, каталог), подставляет их в промпт и только затем генерирует текст. Так LLM опирается на актуальные и проверяемые источники, а не только на «память» из обучения. Термин закрепился после работы Lewis et al. (Facebook AI / Meta, NeurIPS 2020): параметрическая модель + непараметрическая память через retrieval. Ниже — как устроен пайплайн, чем RAG отличается от fine-tuning и когда одной выдачи документов недостаточно.
Кратко
- RAG = поиск по вашей базе → контекст в промпт → генерация ответа LLM с возможностью ссылок на источники.
- Главная ценность для бизнеса: обновлять знания без дорогого дообучения модели и снижать риск выдуманных фактов на корпоративных данных.
- «Наивный» RAG (PDF → векторная БД → top-k) — нормальный прототип; в проде обычно нужны чанкинг по смыслу, hybrid search и reranking.
- RAG не заменяет действия: создать сделку в CRM, вызвать API или эскалировать человеку — это уже ИИ-агент с tools.
- Качество ответа упирается в качество индекса: мусорные, устаревшие или недоступные документы дают уверенный, но неверный ответ.
Определение: retrieval + generation
По формулировке IBM Research, RAG улучшает ответы LLM, «заземляя» модель на внешних источниках знаний поверх её внутренней репрезентации. OpenAI описывает то же практично: релевантная информация извлекается из подключённых данных и добавляется в промпт во время выполнения (Help Center).
Метафора IBM: обычная LLM сдает «закрытый экзамен» по памяти; RAG — «открытый»: модель смотрит в книгу (ваш индекс) и формулирует ответ. Исходная научная постановка — статья Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al., 2020).
Как работает RAG: пайплайн
В продакшен-системах выделяют две фазы: подготовка индекса (offline) и ответ на запрос (online).
- Ingestion — документы чистят, режут на чанки (фрагменты с осмысленными границами: разделы, абзацы, таблицы), считают embeddings и кладут в векторное хранилище; часто дублируют лексический индекс (BM25).
- Query — запрос пользователя при необходимости переписывают (query rewrite), чтобы улучшить поиск.
- Retrieval — находят top-k похожих чанков; в зрелых системах — hybrid (вектор + ключевые слова) и fusion (например, Reciprocal Rank Fusion).
- Reranking — кросс-энкодер или LLM-reranker переранжирует кандидатов: убирает «похожие по смыслу, но не по факту» фрагменты.
- Augment + generate — отобранный контекст + вопрос уходят в LLM; ответ желательно со ссылками на источники для проверки человеком.
Узкое место почти всегда retrieval, а не «сила» модели: если в контекст попали три нерелевантных абзаца и пропущен нужный пункт регламента, даже сильная LLM ответит уверенно и ошибочно.
RAG vs fine-tuning vs «весь документ в промпт»
| Подход | Что меняется | Когда уместен | Ограничение |
|---|---|---|---|
| Промпт / длинный контекст | Всё нужное кладут в один запрос | Мало документов, разовый анализ | Лимит контекста, стоимость, шум |
| RAG | Внешний индекс + retrieval на каждый запрос | База знаний, политики, каталоги, поддержка | Зависит от качества поиска и чанков |
| Fine-tuning | Веса модели под стиль/задачу/формат | Тон, формат, доменная манера ответа | Дорого обновлять факты; слабее provenance |
Практическое правило студии: факты и регламенты — в индекс RAG; стиль ответа и узкие форматы — при необходимости fine-tune или сильный system prompt. Часто комбинируют оба слоя, а не выбирают «или/или».
Зачем бизнесу RAG
- Актуальность без переобучения. Обновили прайс или политику отпусков — переиндексировали документ; модель не нужно заново учить.
- Проверяемость. Можно показать сотруднику или клиенту фрагмент-источник (как в сценариях IBM для внутренних HR/support-ботов).
- Контроль периметра. Закрытый корпоративный корпус вместо «ответа из интернета модели».
- Стоимость владения. Дешевле держать актуальный индекс, чем постоянно fine-tune’ить модель под каждый релиз знаний.
Типичные сценарии: внутренний Q&A по регламентам, поддержка клиентов по базе статей, поиск по договорной/технической документации, слой знаний для ИИ-агента.
Когда RAG подходит — и когда нет
Подходит, если есть относительно стабильный корпус текстов, нужна цитируемость и ответы меняются вместе с документами. Хороший старт — один процесс (например, «ответы по базе знаний поддержки») с метриками точности и эскалацией человеку.
Не стоит ждать чуда от одной RAG-системы, если:
- нужны действия в CRM, 1С, тикетах — нужен агент с tools, а не только retrieval;
- документы противоречивы, без владельца и даты актуальности — модель усилит хаос;
- вопрос требует вычислений, бронирования или транзакций без API;
- критичны PII/доступы: без ACL на уровне retrieval сотрудник может «достать» чужой документ через чат;
- ожидают «ноль галлюцинаций» — RAG снижает риск, но не обнуляет его (модель может неверно интерпретировать даже правильный фрагмент).
Чеклист пилота RAG на 2–4 недели
- Выбрать один use case и золотой набор из 30–50 вопросов с эталонными ответами и ссылками на источники.
- Навести порядок в корпусе: версии, владельцы, запрет устаревших PDF в индексе.
- Собрать naive baseline (чанки + embeddings + top-k) и замерить hit-rate retrieval отдельно от «красоты» ответа.
- Добавить hybrid search и rerank, если baseline промахивается по точным артикулам, кодам, номерам политик.
- Включить отказ («не нашёл в базе») и эскалацию человеку; логировать запросы без ответа.
- Только после метрик — подключать tools/CRM и расширять корпус.
RAG и ИИ-агенты
RAG отвечает на вопрос «откуда взять факты». Агент решает «что сделать дальше»: вызвать API, создать сделку, уточнить статус заказа. В продуктовой разработке Compiny слой знаний (RAG) обычно идёт вместе с инструментами и правилами эскалации — иначе получается умный FAQ без операционной пользы. Подробнее о границе: ИИ-агент vs чат-бот.
FAQ
Что такое RAG простыми словами?
Это схема, где ИИ сначала ищет нужные куски в ваших документах, а потом формулирует ответ, опираясь на найденное — как сотрудник с доступом к базе знаний, а не только к памяти.
RAG полностью убирает галлюцинации?
Нет. Он снижает вероятность выдуманных фактов, если retrieval попал в цель и промпт требует опираться на контекст. При плохом поиске или противоречивых источниках модель всё ещё может ошибаться.
Чем RAG отличается от дообучения (fine-tuning)?
Fine-tuning меняет поведение модели «изнутри»; RAG подключает внешнюю память на каждый запрос. Для часто меняющихся фактов обычно выгоднее RAG; для стиля и формата ответа — fine-tune или сильный промпт.
Нужна ли векторная база данных обязательно?
Для семантического поиска — почти всегда да (или эквивалент embeddings-индекса). В проде часто добавляют классический полнотекстовый поиск и reranker; одна «векторная БД» без гибрида — частый потолок качества.
С чего начать компании без ML-команды?
С узкого пилота: один корпус, эталонные вопросы, метрики retrieval и правило «не знаю → человек». Разработку агента с RAG и интеграциями можно заказать как пилот: разработка ИИ-агентов.
Нужен пилот базы знаний или агента с RAG: ИИ-агенты, ИИ-ассистент, автоматизация с ИИ, разбор агент vs чат-бот.