RAG

RAG (Retrieval-Augmented Generation) — техника, в которой LLM перед ответом достаёт из внешней базы релевантные документы и использует их как контекст. Это помогает работать с обновляемыми знаниями и проверяемыми источниками, но не устраняет ошибки автоматически. Система может использовать векторный, полнотекстовый, графовый или гибридный поиск, а затем добавляет найденное в контекст модели.

Коротко

RAG — способ дать языковой модели материалы, в которых можно найти ответ. Сначала система ищет нужные документы или фрагменты, затем передаёт их модели вместе с вопросом. Вместо общего совета читатель может получить ответ по своей инструкции, заметкам или базе знаний — со ссылками, которые можно открыть и проверить.

Это не гарантия достоверности. Поиск способен пропустить нужный абзац, документ — устареть, а модель — неверно понять найденное.

Зачем нужен поиск перед ответом

Допустим, команда хранит инструкции к продукту в общей папке. В них меняются названия разделов, порядок настройки и условия поддержки. Переучивать модель после каждой такой правки неудобно. Проще оставить знания в документах и находить нужное в момент вопроса.

Так устроена основная идея RAG: документы обновляются отдельно от весов модели. Но между изменением файла и новым ответом есть ещё один шаг — обновление поискового индекса. Пока система не обработала правку, она может находить старую версию.

Сокращение раскрывается как Retrieval-Augmented Generation — генерация, дополненная поиском. Термин используют и для личных помощников по заметкам, и для корпоративных баз, и для ответов с веб-источниками. Внутри конкретного сервиса могут сочетаться несколько методов, поэтому наличие ссылок само по себе не раскрывает его устройство.

В разборе «RAG и AI-поиск» подробнее показана вся цепочка. Здесь — её основные части и ограничения.

Как устроена цепочка

1. Подготовить материалы

Из документов извлекают содержимое и делят его на фрагменты. Вместе с текстом сохраняют источник, заголовок, версию, страницу и права доступа.

Размер фрагмента зависит от материала. Короткую инструкцию иногда удобно оставить целиком; большой справочник — разделить по смысловым разделам. Если разрезать таблицу или оторвать исключение от правила, даже хороший поиск получит испорченный материал.

2. Найти то, что относится к вопросу

Есть несколько способов:

• По словам: полезен для точных названий, артикулов, кодов ошибок.
• По смысловому сходству: тексты превращают в числовые представления — эмбеддинги — и ищут близкие.
• По связям: например, переходят от продукта к подходящей инструкции и её зависимостям.
• Смешанный поиск: объединяет результаты разных методов.

Векторная база — один из возможных компонентов, а не обязательное условие RAG. Если используются эмбеддинги, представления запроса и документов должны быть совместимы. Обычно их строят одной моделью с предусмотренными для поиска настройками.

3. Выбрать контекст

Из найденного отбирают материалы для ответа. При необходимости отдельная модель повторно оценивает, насколько каждый фрагмент полезен для вопроса. Это называется переранжированием.

Первые места в выдаче ещё не означают, что ответ найден. Среди результатов могут оказаться дубликаты, похожие темы или устаревшие версии. Число фрагментов выбирают по проверкам, а не по универсальному правилу «всегда пять».

4. Подготовить ответ

Вопрос и отобранный контекст передают языковой модели. В инструкции можно попросить отделять сведения из документов от предположений, указывать источники и прямо говорить о нехватке данных.

Такой промпт помогает задать поведение, но не обеспечивает его безошибочность. Модель по-прежнему использует выученные закономерности и может добавить утверждение, которого нет в документах.

5. Проверить, на что ссылается ответ

Полезная ссылка ведёт к конкретному месту: абзацу, странице или записи. При проверке важно не только то, существует ли источник, но и действительно ли он подтверждает соседнее утверждение.

Небольшой пример

Представим помощника по заметкам о съёмке. Пользователь спрашивает:

«Что помогло убрать шум ветра во время интервью у озера?»

В базе есть две записи:

[1] Интервью у озера: на открытом берегу порывы ветра
перегружали микрофон даже с ветрозащитой.

[2] Интервью у озера: переставили героев за стену павильона.
На пробной записи порывы стали заметно тише.

Ответ, который действительно следует из этих заметок:

«Помог перенос съёмки за стену павильона: на пробной записи шум порывов стал тише [2]. Одной ветрозащиты на открытом берегу оказалось недостаточно [1].»

Это учебный пример, не результат проведённого теста. Он показывает, что ценность RAG — в связи ответа с конкретным опытом. Из этих фрагментов нельзя узнать модель микрофона, точные настройки обработки или доказать, что весь шум исчез. Хороший ответ не должен их дописывать.

Для русскоязычной базы поисковую модель тоже проверяют на русском: известность модели или её небольшой размер не гарантируют подходящего поиска.

Где чаще всего теряется качество

• До поиска: из PDF неверно извлечена таблица или распознавание перепутало символы.
• Во время поиска: найден близкий по теме текст, но не ответ на вопрос.
• При отборе: нужный фрагмент вытеснен дубликатами или обрезан вместе с важной оговоркой.
• При генерации: модель смешала несколько версий инструкции или добавила неподтверждённую деталь.
• После ответа: ссылка существует, но ведёт не к тому месту.

Этапы удобно проверять отдельно. Сначала — нашёлся ли материал, достаточный для ответа. Затем — верно ли модель его использовала. Замена генератора на более крупный не исправит абзац, который вообще не попал в контекст.

Права доступа и безопасность

Если сотрудник не может читать документ напрямую, он не должен получать его через помощника. Проверка доступа нужна до передачи текста модели или внешнему сервису переранжирования. Просьба в промпте «не показывай секретное» не заменяет этой проверки.

Документы также могут содержать команды, адресованные модели. Это риск prompt injection: внешний текст пытается изменить поведение помощника. Разделение инструкций и данных, проверки подозрительного содержимого и системный промпт полезны, но сами по себе не закрывают риск.

Если помощник умеет отправлять письма, открывать ссылки или менять файлы, эти действия отдельно ограничивает приложение. Права на чтение справки не должны автоматически давать право переслать её наружу.

Локальная модель эмбеддингов тоже не делает всю систему локальной. Найденный текст может уходить облачному генератору, а запросы — сохраняться в журналах. Конфиденциальность зависит от всей цепочки.

Чем RAG отличается от соседних подходов

Дообучение меняет параметры модели. RAG при использовании может добавлять внешний контекст без изменения весов. Подходы совместимы: поисковую или генерирующую модель можно отдельно дообучить для своей задачи.

Семантический поиск возвращает найденное. RAG добавляет к поиску формирование ответа. При этом сам поиск не обязательно семантический.

Большое контекстное окно позволяет передать больше текста за один раз. RAG помогает выбрать, что туда положить. Даже большое окно не решает автоматически вопросы прав доступа, версий и качества источников.

Память помощника может использовать поиск по сохранённым сведениям, но бывает устроена и иначе: например, через краткую сводку или явно выбранные записи.

Частые вопросы

Нужно ли превращать все документы в векторы?

Нет. Это зависит от выбранного поиска. Для кодов ошибок иногда полезнее точное совпадение, а для вопросов с перефразированием — смысловой поиск. Эти способы можно сочетать.

Что происходит после изменения документа?

Система должна обработать новую версию и обновить связанные записи индекса. Важно также удалить устаревшие фрагменты и учесть изменившиеся права. Возможность базы обновлять записи ещё не означает, что приложение настроило синхронизацию правильно.

RAG делает запросы дороже?

Добавленный контекст увеличивает объём входных данных для генератора. Есть и отдельные расходы на обработку документов, поиск и переранжирование. Итог зависит от нагрузки, кэширования и способа размещения; сравнивать его с дообучением без этих условий бессмысленно.

Сколько документов выдержит система?

Одно число мало что скажет. Важны объём текста, число фрагментов, размер векторов, фильтры, оборудование и одновременные запросы. Подходящую конфигурацию проверяют на похожей нагрузке, а не обещанием «миллион документов без задержки».

Можно ли искать по изображениям?

Да, если система умеет извлекать и сопоставлять нужную информацию. Это могут быть распознанный текст, описания изображений или мультимодальные представления. Само расширение файла не гарантирует, что схема, график или таблица будут поняты верно.

Главное

RAG полезен там, где ответ нужно связать с конкретными материалами. Его надёжность складывается из нескольких вещей: подходящий поиск, актуальный индекс, корректные права доступа и ответ, который действительно опирается на найденное. Ссылка помогает проверить результат, но не делает его истинным автоматически.

Источники

• Исходная работа о Retrieval-Augmented Generation
• Qdrant: фильтрация при поиске
• OWASP: prompt injection в приложениях с языковыми моделями