Что такое RAG
RAG, или Retrieval-Augmented Generation, — это подход, в котором модель отвечает не только на основе того, что «помнит» в своих параметрах, но и на основе внешних источников, найденных в момент запроса.
Проще говоря, сначала система находит релевантные документы, фрагменты или записи, а потом LLM использует их, чтобы собрать ответ. В этом и смысл RAG: не заставлять модель угадывать то, что уже есть в ваших данных, а подложить ей нужный контекст.
Именно поэтому RAG так часто используют в корпоративных сценариях: для внутренней базы знаний, регламентов, техдокументации, support-процессов, юрматериалов и поиска по закрытым данным.
Зачем он вообще нужен
У обычной LLM есть три естественных ограничения.
- Она знает только то, на чём обучалась.
- Она не знает ваши внутренние документы, если вы их отдельно не подключили.
- Она может звучать уверенно даже тогда, когда ошибается.
RAG решает не все проблемы, но закрывает самые практичные.
- знания можно обновлять без переобучения модели;
- можно отвечать по внутренним документам, а не только по общим знаниям;
- можно показывать источники и уменьшать споры вокруг «откуда взялся ответ»;
- можно ограничивать ответ рамками тех данных, которые вообще должны участвовать в рассуждении.
Именно в этом RAG стал стандартным инструментом для бизнеса.
Чем RAG отличается от просто большого контекста
Это самый важный вопрос, и тут легко запутаться.
Большой контекст означает, что модель умеет принять больше текста за один раз. RAG означает, что система выбирает только те фрагменты, которые действительно нужны для ответа.
Разница кажется тонкой, но на практике она огромная.
Если у вас просто большой контекст, вы всё равно должны положить в промпт весь массив документов или большую его часть. Это работает, когда данных немного, они стабильные и вопрос заранее понятен.
Если у вас RAG, система сначала ищет нужное, потом подаёт в модель уже отфильтрованный набор фрагментов. Это обычно лучше, когда:
- документов много;
- данные часто меняются;
- важна точность по конкретному источнику;
- нужна ссылка на документ, страницу или фрагмент;
- у разных пользователей разные права доступа.
Большой контекст не отменяет retrieval. Он просто расширяет окно. RAG добавляет поиск, отбор и контроль над тем, что именно попадёт в окно.
Почему большой контекст не заменяет RAG
Современные модели действительно умеют переваривать очень большие объёмы текста. Но это не означает, что они одинаково хорошо используют всё, что вы им дали.
Исследование "Lost in the Middle" показало, что даже у моделей с длинным контекстом качество ответа заметно проседает, когда важная информация оказывается в середине большого окна. Проще говоря, длинный контекст не гарантирует, что модель увидит и правильно использует нужный фрагмент.
Есть и более приземлённая проблема: чем больше вы тащите в контекст, тем больше шума, повторов и устаревших версий документов попадает в ответ. В итоге вы платите больше токенов, дольше ждёте результат и не всегда получаете лучшую точность.
Поэтому длинный контекст полезен, но он не отменяет необходимость в поиске, ранжировании и отборе источников.
Где RAG особенно полезен
RAG хорошо работает там, где знание должно приходить извне и меняться со временем.
Обычно это такие кейсы:
- поиск по внутренней базе знаний;
- ответы по регламентам, инструкциям и политиками компании;
- поддержка сотрудников и service desk;
- юридические и комплаенс-сценарии;
- техническая документация, каталоги, спецификации;
- корпоративные порталы, где нужно отвечать по закрытым данным;
- аналитические ассистенты, которым нужны свежие данные из документов и хранилищ.
Если вопрос звучит как «найди в наших материалах и объясни по-человечески», RAG почти всегда уместен.
Где RAG не нужен
RAG не стоит лепить везде подряд.
Он может быть лишним, если:
- задача простая и решается шаблоном;
- данных мало и они почти не меняются;
- ответ не требует ссылок на источники;
- вопрос не связан с внутренними документами;
- быстрее и дешевле написать обычную автоматизацию.
Хороший инженерный вывод тут простой: если поиск по базе ничего не добавляет, RAG не нужен.
Из чего состоит нормальный RAG
RAG — это не «загрузить PDF в чат».
В рабочей системе обычно есть несколько уровней.
Сначала документы нужно привести в порядок: убрать мусор, распознать PDF, извлечь структуру, сохранить метаданные и версии. Потом текст нужно разбить на осмысленные фрагменты. Затем эти фрагменты индексируются так, чтобы поиск находил не просто похожие слова, а действительно полезные куски смысла.
После этого идут ранжирование, фильтрация и только потом генерация ответа.
Если упростить, хороший RAG отвечает на четыре вопроса:
- что у нас есть;
- как это искать;
- что из найденного действительно нужно показать модели;
- как проверить, что ответ опирается именно на источники, а не на фантазию.
Почему важна не только модель, но и retrieval
У RAG часто все обсуждают генерацию, хотя настоящая сложность обычно в поиске.
Исследования по retrieval показывают, что даже мелкие решения сильно влияют на качество: что индексировать, на какой гранулярности хранить знания, как резать документ и что считать единицей поиска.
Например, работа "Dense X Retrieval" показывает, что выбор единицы извлечения заметно влияет на результат. А "RAPTOR" идёт дальше и показывает, что для длинных и сложных документов полезны иерархические суммаризации и многоуровневый поиск, а не только короткие куски текста.
Практический вывод такой: если ваша база знаний сложная, не ждите, что один и тот же чанкинг подойдёт для всего.
Когда RAG становится tool-use
В более зрелых системах RAG перестаёт быть статичным куском контекста и превращается в инструмент, которым модель пользуется по мере необходимости.
Это значит, что агент может:
- сначала вызвать поиск по базе знаний;
- проверить, хватает ли найденного для ответа;
- если не хватает, сделать ещё один запрос;
- при необходимости уточнить вопрос у пользователя;
- и только потом сформировать ответ.
Такой подход лучше, чем один большой неподвижный контекст, потому что модель не перегружается лишними фрагментами и может добирать информацию итеративно. Мы подробнее разбираем этот паттерн в статье ИИ-агенты с tool-use: как модель сама ищет данные и добирает контекст.
Что обычно ломает RAG
Большинство проблем RAG не в самой идее, а в данных и эксплуатации.
Чаще всего ломается вот что:
- в индекс попадают грязные или дублирующиеся документы;
- вместе лежат актуальные и устаревшие версии одного и того же файла;
- структура документа теряется после OCR;
- нет метаданных и прав доступа;
- retrieval тащит слишком много нерелевантного текста;
- модель получает хороший контекст, но не понимает, что это инструкция, цитата или архивная версия;
- никто не измеряет качество ответа на реальных вопросах бизнеса.
Отдельная проблема — безопасность. OWASP прямо отмечает, что RAG не решает prompt injection автоматически. Если в систему попадает внешний или пользовательский текст, он может содержать скрытые инструкции, и это нужно учитывать на уровне фильтров, политики источников и обработки входных данных.
Как понять, что RAG работает
У RAG нельзя ограничиваться ощущением «вроде отвечает лучше».
Обычно мы смотрим на несколько групп метрик.
- Насколько хороший релевантный набор документов был найден.
- Насколько ответ опирается именно на эти источники.
- Насколько мало в ответе выдуманных деталей.
- Сколько времени занимает полный цикл ответа.
- Как часто система промахивается по версии, правам или контексту.
Для бизнеса это важнее, чем абстрактная «умность» модели. Если ответ быстрый, точный, с источником и без выдумок, система работает. Если она просто красиво пишет, но ошибается в регламенте, это плохой RAG.
Когда нужен RAG, а когда просто большой контекст
Если коротко:
- большой контекст хорош, когда документов мало и вы заранее знаете, что именно нужно подать модели;
- RAG нужен, когда данных много, они меняются, есть права доступа, версии и необходимость ссылаться на источник;
- гибридный подход часто лучший: большой контекст помогает модели видеть больше, а RAG помогает дать ей именно то, что нужно.
То есть это не конкурирующие технологии. Они дополняют друг друга.
Как мы обычно проектируем такие системы
Мы начинаем не с векторной базы, а с вопроса: какие данные вообще должны отвечать на запрос.
Дальше идём по цепочке:
- определяем сценарии и типы вопросов;
- разбираем источники и права доступа;
- нормализуем документы и версии;
- выбираем способ поиска и гранулярность;
- добавляем reranking и цитирование;
- тестируем на реальных вопросах;
- подключаем мониторинг качества и журналирование.
И только после этого RAG превращается из красивой идеи в рабочий инструмент.
Итог
RAG нужен не потому, что это модное слово, а потому, что у бизнеса есть знание, которое живёт вне модели.
Если вам важны актуальность, источники, контроль доступа и работа по внутренним документам, RAG обычно нужен. Если данных мало, вопрос простой и поиск не добавляет ценности, можно обойтись без него.
Большой контекст помогает, но не заменяет retrieval. А хороший RAG делает ответ не просто длиннее, а полезнее, точнее и проверяемее.
Если хотите, мы можем помочь разобрать ваш кейс и понять, нужен ли вам RAG, большой контекст или гибридный подход."}