RAG: что это и зачем нужно, если модель и так всё знает

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

Разберём, зачем это нужно, чем отличается от дообучения и почему у большинства оно работает хуже, чем ожидалось.

Зачем это нужно

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

Загружать всю базу в каждый запрос невозможно: она не влезет и будет дорого стоить.

RAG решает это отбором: находит три-пять релевантных фрагментов и подкладывает только их.

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

Как это устроено

Документы режутся на куски по несколько абзацев.

Каждый кусок превращается в набор чисел — вектор, который отражает его смысл.

Векторы складываются в специальную базу.

При вопросе он тоже превращается в вектор, база находит ближайшие по смыслу куски.

Найденное вместе с вопросом отправляется модели: «ответь, опираясь только на это».

Ключевое отличие от обычного поиска — совпадение по смыслу, а не по словам. Вопрос «что делать при просрочке» найдёт абзац про нарушение сроков, даже если слова «просрочка» там нет.

Чем отличается от дообучения

Дообучение меняет саму модель: она усваивает стиль и терминологию, но не хранит факты надёжно.

RAG модель не трогает — он меняет то, что ей дают на вход.

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

Обновлять RAG проще: добавили документ — он сразу учитывается. Дообучение приходится повторять.

Где чаще всего ломается

На нарезке. Куски слишком мелкие — теряется контекст, слишком крупные — в ответ попадает лишнее. Универсального размера нет, подбирается опытом.

На таблицах. Разрезанная таблица теряет смысл: строки без заголовков ничего не значат.

На похожих документах. Если у вас пять версий одного регламента, система найдёт не ту.

На вопросах, требующих обзора. «Сколько всего договоров с этим условием» — задача не для поиска по смыслу, а для базы данных.

На отсутствии дат. Без указания актуальности система с равной охотой процитирует прошлогодний прайс.

Что помогает

Чистить документы перед загрузкой: убирать колонтитулы, дубли и черновики.

Хранить метаданные: дата, версия, тип документа. И фильтровать по ним при поиске.

Заставлять систему цитировать источник в ответе — тогда сразу видно, откуда взялось.

Проверять на реальных вопросах сотрудников, а не на придуманных.

Разрешать отвечать «в документах этого нет». Без такого разрешения система начнёт достраивать из общих знаний.

Что нужно, чтобы собрать

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

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

Технический минимум для своей сборки: хранилище векторов, модель для векторизации и сама языковая модель. Всё это существует в открытом виде.

Где это оправдано

База знаний поддержки: ответы по инструкциям вместо поиска в папках.

Работа с договорами и регламентами.

Внутренняя справочная: новый сотрудник спрашивает, система отвечает по вашим документам.

Не оправдано там, где документов десяток и их проще прочитать.

С чего начать

Возьмите двадцать документов, которые чаще всего открывают в вашей компании.

Соберите по ним простой чат в готовом сервисе и дайте трём сотрудникам на неделю.

Соберите вопросы, на которые он ответил неверно, — это и есть список того, что чинить: чаще всего окажется, что дело в самих документах, а не в технологии.