Что такое RAG

Модель не читала ваш Confluence, не видела архитектурных решений команды и не разбирала ваши инциденты. Сама она об этом и не узнает: таких текстов не было в обучающих данных, а часть из них появилась уже после отсечки знаний.

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

RAG (retrieval-augmented generation) даёт модели доступ к этим текстам: найти нужные фрагменты и положить их в контекст перед тем, как модель начнёт отвечать.

Определение: найти → подложить → ответить

Название разбирается с конца. Generation: модель генерирует ответ. Augmented: этот ответ дополнен, усилен чем-то извне. Retrieval: тем, что было найдено поиском. Отсюда весь механизм в трёх шагах:

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

Важно понять сразу: RAG ничего не меняет в самой модели. Веса остаются прежними, вашу документацию она не «выучивает». Меняется только то, что лежит в её контексте на момент ответа. По сути, RAG автоматизирует то, что человек делает вручную, когда копирует в чат кусок регламента и пишет «ответь по этому тексту».

Три способа дать модели знания компании

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

	Вручную в промпт	Дообучение (fine-tuning)	RAG
Стоимость запуска	нулевая	высокая: данные, обучение, эксперименты	средняя: индексация и поиск
Обновить один факт	переписать промпт	переобучить модель	переиндексировать документ
Свежесть данных	ручная	на момент обучения	близка к реальному времени
Ссылки на источник	вы их знаете сами	нет, знание «растворено» в весах	есть, это часть ответа
Разграничение прав	вы решаете, что вставить	невозможно: модель одна на всех	фильтр при поиске
Когда оправдан	разовые вопросы	нужен стиль, формат, узкий язык домена	нужны факты компании

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

Почему не «просто большое окно»

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

Лимит всё равно жёсткий. Вики компании средних размеров занимает десятки миллионов токенов. В миллионное окно она не поместится ни при каком раскладе.
Качество падает раньше лимита. Даже то, что влезло, обрабатывается неравномерно: информация из середины длинного контекста теряется чаще («потеря в середине»). Пять точных фрагментов работают лучше пятисот приблизительных.
Вы платите за входные токены. Каждый вопрос с полной вики в контексте стоит как небольшой рабочий день. Умножьте на число сотрудников и вопросов в день.

Из правила «больше контекста не значит лучше» и вырос RAG. Задача формулируется так: дать модели нужное, а не всё, что есть.

RAG не агент, но они дружат

Разница часто ускользает, хотя она существенная.

Классический RAG делает один проход: получил вопрос, один раз сходил в поиск, отдал найденное модели, получил ответ. Что искать, решает система, а не модель.

Агент решает сам: он видит инструменты (поиск по коду, чтение файла, запрос в базу) и по ходу задачи сам определяет, что открыть, а прочитав, понимает, что нужно посмотреть ещё. Это цикл, а не один проход. Так устроена работа с кодом в терминальных харнесах: агенту не нужен предварительно построенный индекс, он ориентируется в репозитории поиском на месте (см. Инструменты и их вызов).

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

Пример: вопрос, на который никто не отвечает за пять минут

Дальше в разделе используется один сквозной пример: вымышленный маркетплейс «Маркет». Компания большая: около тридцати команд разработки, сгруппированных в шесть доменов.

Домен	За что отвечает
Селлеры	личный кабинет продавца, онбординг, рейтинг
Склады	WMS, остатки, приёмка товара
Логистика	доставка, ПВЗ, маршруты, сроки
Реклама	ставки, показы, биллинг кампаний
Платежи	выплаты селлерам, возвраты, комиссии
Поиск	каталог, ранжирование, фасеты

Теперь вопрос. Аналитик команды Рекламы считает эффективность кампаний и видит, что с января цифры возвратов ведут себя иначе. Он не знает, почему: возвраты живут в домене Платежей.

Как это решается сегодня: он пишет в общий чат «а кто знает, что поменялось в возвратах?», ждёт полдня, получает ссылку на человека, тот отвечает через день, что было архитектурное решение о смене момента фиксации возврата. Итого полтора дня и время двух других сотрудников на вопрос, ответ на который уже полгода как написан в ADR команды Платежей.

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

Где RAG не нужен

Чтобы не строить систему там, где хватает более простого:

Вопрос по конкретному известному файлу. Открыть его дешевле, чем искать.
Задача внутри одного репозитория. Агент с поиском по файлам справится лучше и без индекса, который надо поддерживать.
Знание, нужное постоянно и всем. Соглашения проекта, команды сборки и стиль кода образуют память проекта, она должна лежать в контексте всегда, а не искаться каждый раз.
Процедура, а не факт. За «как мы выкатываем релиз» отвечает скил: пошаговая инструкция, которую агент подгружает целиком.
Редкий разовый вопрос. Одноразовое любопытство не окупает индексацию.

RAG начинает выигрывать там, где документов много, они меняются, разбросаны по системам и нужны фрагментами.

Что дальше

Как устроен RAG внутри: два цикла системы, индексация и ответ, по шагам.
Токены и контекстное окно: почему контекст ограничен и почему «дать всё» не работает.

Автор учебника: Шахматов Алексей