2026-06-05 | RAG · AI · LLM · AI-инженер · практика

RAG на практике: архитектура, грабли и когда он вообще не нужен

RAG (Retrieval-Augmented Generation) — самый частый запрос к AI-инженеру: «сделай, чтобы модель отвечала по нашим документам». На бумаге всё просто: нарезал документы, сложил в векторную базу, достал релевантное, подсунул модели. На практике первая версия почти всегда отвечает мимо. Разбираем, как RAG устроен на самом деле, где он ломается и когда его вообще не нужно строить.

«Прикрутите нам чат по нашей документации» — с этой задачи начинается путь большинства AI-инженеров. И это же — самый быстрый способ узнать, что между «демо за вечер» и «системой, которой доверяют» лежит пропасть.

Что такое RAG и зачем он нужен

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

Пайплайн из трёх шагов:

Retrieval — по вопросу пользователя найти в корпусе релевантные фрагменты.
Augmentation — вставить найденное в промпт: «вот документы, отвечай по ним».
Generation — модель пишет ответ, опираясь на подложенный контекст, в идеале — со ссылками на источники.

Звучит тривиально. Вся инженерия прячется в первом шаге: если поиск принёс мусор, никакая модель не спасёт ответ.

Как устроен retrieval: от документов до векторов

Чанкинг

Документы режутся на куски (чанки) — обычно 300–1000 токенов. Это первое место, где закапываются проекты: режешь посреди абзаца — теряешь смысл, режешь слишком крупно — в кусок попадает три темы сразу и эмбеддинг становится «средней температурой по больнице».

Рабочие практики: резать по структуре документа (заголовки, секции), а не по числу символов; добавлять перекрытие между соседними чанками; приклеивать к каждому чанку контекст — заголовок документа и секции, а ещё лучше — одну строку «о чём этот кусок», сгенерированную моделью (contextual retrieval). Последний приём в среднем даёт самый большой прирост качества на единицу усилий.

Эмбеддинги и векторный поиск

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

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

Реранкинг

Первый этап поиска быстрый, но грубый: он приносит 20–50 кандидатов. Реранкер — отдельная модель, которая смотрит на пару «вопрос + кусок» целиком и переставляет кандидатов по реальной релевантности. В топ-5 после реранкинга попадает заметно больше правильных кусков, чем без него. Это второй по окупаемости апгрейд после нормального чанкинга.

Где RAG ломается: топ-5 граблей

Чанкинг по числу символов. Кусок обрывается посреди таблицы или инструкции — retrieval находит «половину ответа», модель достраивает вторую половину из головы. Получаются правдоподобные галлюцинации со ссылкой на настоящий документ — худший вид ошибки.
Вопрос и документ говорят на разных языках. Пользователи спрашивают разговорно, документы написаны канцеляритом. Лечится переформулировкой запроса моделью перед поиском (query rewriting) и гибридным поиском.
Нет фильтрации по метаданным. Вопрос про «отпуск в 2026» находит регламент 2019 года — вектора у них почти одинаковые. Дата, версия, отдел, продукт должны быть полями фильтра, а не надеждой на эмбеддинг.
Устаревший индекс. Документ обновили, а чанки в базе старые. Без пайплайна переиндексации RAG деградирует молча: система продолжает уверенно отвечать по прошлогодним правилам.
Оценка «на глазок». Потыкали пять вопросов — «вроде норм», выкатили. Через неделю прилетает скриншот с уверенным неправильным ответом. Без золотого набора вопросов и метрик каждое изменение пайплайна — лотерея.

Как оценивать качество

Минимальный рабочий контур — золотой набор из 50–200 реальных вопросов (из саппорта, логов, интервью с пользователями) с правильными ответами и документами-источниками. На нём меряются два слоя независимо:

Retrieval: попали ли нужные документы в выдачу (recall@k). Если нет — крутить чанкинг, гибрид, реранкер; модель тут ни при чём.
Generation: правильный ли ответ при правильно найденных документах. Оценивается LLM-судьёй по чеклисту: соответствие источникам, полнота, отсутствие выдумок.

Разделение слоёв — главное: оно сразу показывает, где чинить. 80% проблем живут в retrieval, но команды по привычке первым делом меняют модель генерации.

Когда RAG не нужен

Самая дорогая ошибка — построить RAG там, где он не нужен:

Корпус помещается в контекст. 200K–1M токенов — это сотни страниц. Полсотни документов по продукту дешевле подать целиком, чем городить пайплайн.
Агентный поиск справляется. Если данные — это код или структурированные файлы, агент с инструментами поиска (grep, навигация по файлам — как это делает Claude Code) часто находит ответ точнее векторной базы. Подключить такие источники к ассистенту можно через MCP-серверы — без отдельной поисковой инфраструктуры.
Вопросы предсказуемы. Если 90% запросов — это 30 типовых сценариев, FAQ с классификатором проще, дешевле и не галлюцинирует.

RAG оправдан, когда документов тысячи, корпус живёт и растёт, а вопросы непредсказуемы. Тогда это полноценная поисковая система с LLM-интерфейсом — и относиться к ней нужно как к поисковой системе, а не как к промпту.

Куда расти дальше

Хороший RAG — это на 20% про AI и на 80% про инженерию: пайплайны данных, индексация, метрики, мониторинг. Именно поэтому вопросы про RAG стали стандартом на собеседованиях AI-инженеров — по ним видно, строил человек реальную систему или прошёл туториал.

Если хотите разобрать свой пайплайн с тем, кто уже наступил на эти грабли, — в базе менторов IT-ХОЗЯЕВА есть практикующие AI/ML-инженеры: ревью архитектуры, подготовка к собеседованию, помощь с первым AI-проектом. Доступ — на тарифе ХОЗЯИН, 1000 ₽/мес.

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

Что такое RAG простыми словами?

RAG (Retrieval-Augmented Generation) — это схема, при которой модель отвечает не из своей памяти, а по документам, которые ей подложили в контекст. Перед генерацией система находит куски текста, релевантные вопросу (retrieval), и добавляет их в промпт (augmentation) — модель генерирует ответ уже по ним. Так LLM отвечает по вашей вики, базе тикетов или документации, которых не было в обучающих данных.

Когда RAG не нужен?

Когда весь корпус помещается в контекст модели. Современные модели держат 200K–1M токенов — это сотни страниц. Если у вас 50 документов по продукту, дешевле и точнее подавать их целиком или агентным поиском по файлам, чем строить пайплайн с векторной базой. RAG оправдан от тысяч документов и когда корпус постоянно растёт.

Какую векторную базу выбрать?

Для старта — pgvector: если в проекте уже есть PostgreSQL, вы получаете векторный поиск без нового сервиса в инфраструктуре. Отдельные базы (Qdrant, Weaviate, Milvus) имеют смысл при десятках миллионов векторов или специфичных требованиях к фильтрации. Менять базу потом — самая дешёвая часть миграции, начинать с этого выбора не стоит.

Почему RAG отвечает неправильно, хотя документы в базе есть?

Три самые частые причины. Первая — плохой чанкинг: документ нарезан посреди мысли, и в найденном куске нет ответа целиком. Вторая — семантический разрыв: пользователь спрашивает «как вернуть деньги», а в документах написано «процедура рефанда» — эмбеддинги не всегда сближают такие формулировки. Третья — ответ размазан по нескольким документам, а система достаёт только топ-3 куска. Лечится гибридным поиском, реранкингом и переформулировкой запроса.

Как измерить качество RAG-системы?

Собрать золотой набор: 50–200 реальных вопросов с правильными ответами и ссылками на документы-источники. Дальше мерить два слоя отдельно: retrieval (нашлись ли нужные документы — recall@k) и generation (правильный ли ответ по найденному — точность, отсутствие галлюцинаций, оценивается LLM-судьёй). Без такого набора любые «стало лучше» — самообман.

Где практиковаться в построении RAG и AI-систем?

В IT-ХОЗЯЕВА есть закрытые AI-беседы и менторы по AI/ML-направлению: можно разобрать архитектуру своего проекта, подготовиться к собеседованию на AI-инженера или получить ревью пайплайна. Доступ к базе менторов — на тарифе ХОЗЯИН, 1000 ₽/мес.