RAG (Retrieval-Augmented Generation, генерация с опорой на найденные документы) — это схема, в которой модель сначала ищет подходящие фрагменты в вашей базе документов, а потом отвечает по ним. Ваши файлы не хранятся в модели, поэтому без поиска она отвечает по тому, что видела при обучении, и может уверенно сказать неверное. С RAG факты попадают в запрос в момент ответа — модель опирается на конкретный документ, а не на память.
Что значит «искать документы» на деле
Аббревиатура раскладывается на два шага. Retrieval — поиск: система находит в базе куски текста, близкие по смыслу к вопросу. Generation — генерация: модель получает вопрос вместе с этими кусками и формулирует ответ. Никакого переобучения не происходит: вы просто подставляете нужный текст в запрос.
Первый шаг опирается на векторы. Каждый фрагмент документа превращают в набор чисел, отражающий смысл текста, — такой набор называют эмбеддингом. Сравнивать смысл числами удобнее, чем словами: вопрос «сколько ждать доставку» найдёт фрагмент «срок — три дня», хотя общих слов там почти нет. Числа хранят в векторной базе данных — хранилище, которое умеет быстро находить ближайшие по смыслу векторы.
Второй шаг — сборка запроса. В него кладут инструкцию («отвечай только по приведённым фрагментам»), сами найденные куски и вопрос пользователя. Модель видит факты и формулирует ответ, может сослаться на документ. Если нужного фрагмента не нашлось, хорошая схема велит модели честно сказать, что ответа в документах нет.
Почему модели без поиска не хватает
У обучения есть дата отсечки: всё, что появилось позже, модель не знает. Ваш новый прайс, свежий регламент, договор с поправками — этого в обучении нет и быть не может. Спросите модель напрямую, и она либо откажется, либо выдаст правдоподобную догадку.
Вторая проблема — галлюцинации: уверенные, но неверные ответы без источника. Модель подбирает слова по вероятностям, а не сверяется с базой фактов. Третья — прослеживаемость. Для рабочих задач мало получить ответ, нужно знать, из какого документа он взялся, чтобы проверить и сослаться. Поиск даёт эту привязку, память обучения — нет.
Есть и практический ограничитель — контекстное окно, то есть сколько текста можно передать модели за один запрос. Оно измеряется в токенах (примерно части слова). Даже большое окно не решает задачу целиком: загружать туда весь архив документов на каждый вопрос дорого и медленно, а главное — модель хуже находит нужное в длинном неразобранном тексте. Поиск отбирает десяток релевантных фрагментов вместо тысяч страниц.
Как это работает по шагам
Сначала базу готовят. Документы режут на фрагменты — обычно по разделам или абзацам, чтобы кусок оставался осмысленным. Слишком мелкий фрагмент теряет контекст, слишком крупный размывает смысл и занимает место в запросе. Каждому фрагменту строят эмбеддинг и кладут его в векторную базу вместе с метаданными: откуда взят, какая страница, кому доступен.
Дальше идёт рабочий цикл:
- Вопрос пользователя превращают в вектор тем же способом, что и документы.
- Поиск достаёт top-k ближайших фрагментов — обычно от трёх до десяти, число подбирают по качеству ответов.
- Найденные куски вместе с вопросом и инструкцией собирают в запрос к модели.
- Модель отвечает по фрагментам и указывает источники; если факта нет — отказывается.
Проверить шаг просто: задайте вопрос, ответ на который точно есть в одном документе, и посмотрите, попал ли этот фрагмент в выдачу поиска. Если нет — проблема в разбивке или в поиске, и модель тут ни при чём.
Пример: ассистент по базе строительной компании
Возьмём условный интернет-магазин стройматериалов. У него есть каталог товаров с артикулами, инструкции по монтажу и правила возврата. Клиент спрашивает: «Чем крепить утеплитель к газобетону и какой крепёж есть в наличии?»
Поиск находит два фрагмента: абзац инструкции про крепление к газобетону и карточку товара с артикулом и остатком. Модель получает вопрос и оба куска и отвечает по ним: называет тип крепежа из инструкции и артикул из карточки, отмечая, что наличие взято из каталога. Без RAG та же модель выдала бы общий совет про крепёж — без артикулов, а то и с выдуманными характеристиками.
С возвратом ещё нагляднее. Клиент спрашивает: «Можно вернуть товар через 20 дней?» Поиск находит правило «возврат — в течение 14 дней с момента получения», и модель отвечает: нельзя, срок 14 дней. Ответ опирается на конкретное правило. Если правило изменят, достаточно обновить один фрагмент — переобучать модель не нужно.
RAG, дообучение или длинный контекст
Выбор зависит от того, что именно вы хотите получить: свежесть, прозрачность источников или новый стиль ответов. Сравните варианты по различающимся условиям.
| Подход | Когда подходит | Что даёт | Чего не решает |
|---|---|---|---|
| RAG | Ответы по своим документам, которые меняются | Свежие факты, ссылки на источник, обновление за минуты | Не улучшает стиль и не учит новым навыкам |
| Дообучение | Нужен свой стиль, формат или узкая манера ответов | Меняет поведение модели на примерах | Не гарантирует актуальность и точность фактов |
| Длинный контекст | Один-два документа на запрос, разовый разбор | Просто: вставили текст и спросили | Дорого и медленно на большом архиве |
На практике схемы комбинируют: RAG для фактов, дообучение для тона и формата, кэширование частых вопросов для скорости. Если у вас всего пара страниц инструкции, длинного контекста хватит без всей инфраструктуры. Когда архив растёт до сотен документов и меняется каждую неделю, поиск окупается.
Что проверить перед внедрением
Качество ответа ограничено качеством поиска и полнотой базы, а не только моделью. Начните с честной проверки документов: актуальны ли они, нет ли противоречащих версий, в каком они формате. Сканы без распознанного текста поиск не прочитает.
- Проверьте разбивку: найдите вопросы, где ответ разорван между фрагментами, и поправьте границы.
- Ограничьте доступ: документы должны выдаваться по ролям пользователей, иначе поиск покажет лишнее.
- Защититесь от подмены инструкций: содержимое документа не должно перебивать правила ответа.
- Замерьте метрики: долю вопросов, где нужный фрагмент попал в выдачу, долю ответов с корректной ссылкой и долю честных отказов.
Если по этим замерам поиск находит нужное в большинстве ваших тестовых вопросов, схема работает. Если нет — сначала чините базу и разбивку, а модель меняйте в последнюю очередь.
Вопросы читателей
RAG — это то же самое, что поиск в интернете?
Нет. Поиск в интернете — один из возможных источников, но RAG обычно работает по вашей закрытой базе: регламентам, договорам, каталогу. Вы контролируете, что туда попадает.
Можно ли обойтись без векторной базы?
Да, для небольшого архива хватит обычного поиска по ключевым словам или длинного контекста. Векторы нужны, когда важно находить по смыслу, а не по совпадению слов.
Гарантирует ли RAG, что модель не соврёт?
Нет. Если поиск нашёл не тот кусок или нужного фрагмента нет в базе, ответ будет неверным. Поэтому инструкция «отвечай только по фрагментам» и честный отказ обязательны.
С чего начать, если документы пока в разрозненных файлах?
Соберите десять самых частых вопросов сотрудников или клиентов и проверьте, есть ли на каждый точный ответ в одном документе. Это покажет, готова ли база, раньше, чем вы потратитесь на инфраструктуру.