Что такое RAG простыми словами
RAG (retrieval-augmented generation, генерация с извлечением) — это связка поиска и языковой модели. Прежде чем ответить, система находит в вашей базе фрагменты, относящиеся к вопросу, и кладёт их модели в контекст. Модель отвечает, опираясь на найденное, а не на общие представления о мире.
Бытовая аналогия: сотруднику задали вопрос по внутреннему регламенту. Он не пытается вспомнить, а открывает нужные страницы и отвечает по ним — со ссылкой на пункт. RAG устроен так же, и именно поэтому его ответы можно проверять.
Когда RAG нужен, а когда нет
RAG оправдан, когда знание живёт в документах и меняется: регламенты, договоры, техническая документация, база поддержки, история проектов. Обновили документ — система отвечает по-новому уже сегодня, без переобучения.
RAG не нужен и только добавит сложности, если:
- ответ вычисляется из структурированных данных — тут нужен запрос к базе, а не поиск по смыслу;
- документов мало и они помещаются в контекст модели целиком;
- задача требует не знаний, а действий в системах — это работа агента, RAG будет лишь его инструментом;
- нужен строго детерминированный ответ по формуле или регламенту — надёжнее правило в коде.
Как устроена RAG-система
Минимальный работающий контур состоит из шести частей, и каждая из них — источник отказа.
- Сбор документов: выгрузка из хранилищ, почты, вики, файловых шар. Здесь же решается, что делать со сканами и таблицами.
- Нарезка на фрагменты: документ режется на куски, которые модель получит целиком. Слишком мелкие теряют смысл, слишком крупные размывают поиск.
- Векторизация: каждый фрагмент превращается в набор чисел, отражающий смысл, и попадает в векторную базу.
- Поиск: вопрос превращается в такой же вектор, база возвращает ближайшие фрагменты. Хорошие системы дополняют это обычным полнотекстовым поиском по терминам.
- Сборка контекста: отобранные фрагменты фильтруются, переупорядочиваются и складываются в промпт вместе с инструкцией.
- Генерация с цитированием: модель отвечает и указывает, на каких фрагментах основан ответ.
Где RAG ломается на реальных документах
Нарезка
Самая частая причина плохих ответов. Регламент, разрезанный посреди пункта, даёт фрагмент без условия применения — модель отвечает уверенно и неверно. Нарезка должна следовать структуре документа: разделы, пункты, таблицы, а не фиксированное число символов.
Таблицы, сканы и приложения
Таблица, превращённая в плоский текст, теряет связь заголовка со значением. Скан без распознавания не попадает в поиск вообще. В корпоративных архивах такого материала обычно больше, чем ожидают на старте, — это отдельная статья работ, а не деталь.
Версии и дубликаты
В базе одновременно живут договор, его редакция и черновик. Поиск по смыслу с одинаковой охотой найдёт любой из них. Без даты, статуса и приоритета версии система будет отвечать по отменённому документу — и формально «правильно».
Смысл против терминов
Векторный поиск хорошо понимает переформулировки и плохо — точные обозначения: артикулы, номера ГОСТов, названия версий. Лечится гибридным поиском: векторный плюс полнотекстовый, с объединением результатов.
Права доступа
Если фильтрация по правам не встроена в сам поиск, система рано или поздно процитирует сотруднику документ, которого он видеть не должен. Права — часть индекса, а не постобработка ответа.
Как понять, что система работает
Ощущение «отвечает неплохо» не является приёмкой. Нужен набор вопросов с заранее известными правильными ответами и ссылками на источник — его собирают вместе с экспертами предметной области до запуска. По этому набору измеряются вещи, которые действительно решают:
- нашлись ли нужные фрагменты вообще — качество поиска отдельно от качества ответа;
- опирается ли ответ на найденное или модель добавила от себя;
- есть ли в ответе ссылка на источник и ведёт ли она в правильное место;
- умеет ли система отказываться, когда ответа в документах нет, — это отдельный навык и его надо проверять специально.
Разделение поиска и генерации в измерениях принципиально: если ошибка в поиске, менять промпт бессмысленно, и наоборот. Без такого разделения улучшение системы превращается в гадание.
RAG, дообучение или граф знаний
Три подхода решают разные задачи, и их регулярно путают.
- RAG — когда знание меняется и его надо цитировать. Обновление данных стоит копейки.
- Дообучение — когда нужно поменять поведение и стиль модели или научить её узкому формату. Знания фактов оно даёт плохо и устаревает вместе с данными.
- Граф знаний — когда важны связи между сущностями и ответ требует нескольких шагов рассуждения: кто с кем связан, что от чего зависит, какая деталь в каком узле.
На практике сильные системы комбинируют: граф отвечает за структуру и связи, векторный поиск — за формулировки, дообучение — за стиль и формат. Подробнее о выборе между графом и векторным поиском — в отдельном разборе.
С чего начать
- Возьмите один процесс с повторяющимися вопросами и измеримой ценой ответа — поддержку, подбор по документации, проверку договоров.
- Соберите 30–50 реальных вопросов с эталонными ответами. Это самая ценная работа этапа, и её нельзя делегировать подрядчику целиком.
- Соберите прототип на ограниченном наборе документов и измерьте на своих вопросах.
- Только после этого расширяйте корпус. Плохая система на большом корпусе отлаживается в разы дороже.