Архитектура RAG-системы: источники, индексация, переранжирование

Коротко для руководителя. Когда RAG-систему рисуют на одном слайде, её изображают как одну стрелку: «база знаний → модель → ответ». Эта картинка и есть источник большинства проблем в проде. Реальная архитектура RAG — это конвейер из нескольких слоёв, и стоимость и надёжность системы определяются именно ими, а не размером модели. Понимание того, как она устроена, нужно не для того, чтобы программировать, а чтобы задавать правильные вопросы подрядчику и понимать, за что вы платите.

RAG (retrieval augmented generation) — это подход, при котором модель отвечает не «по памяти», а по фрагментам ваших документов, найденным под конкретный вопрос. Идея простая, и из-за этой простоты её схему обычно рисуют одной стрелкой. На этой стрелке ничего не ломается на демо и почти всё ломается в проде. Разберём, что между «базой» и «ответом» на самом деле происходит — по слоям.

Гипотеза: RAG — это инфраструктура контекста, а не «поиск плюс LLM»

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

Проблема: схему упрощают до одной стрелки

Упрощённая схема «документы → вектор → модель» опускает ровно те слои, которые отвечают за надёжность: приведение источников к единому виду, обновление индекса при изменении документов, отбор из похожих именно отвечающего фрагмента, ограничение объёма контекста. Каждый из этих пропусков по отдельности кажется деталью; вместе они и есть разница между демонстрацией и системой.

Почему обычные подходы не работают

Наивная архитектура держится на трёх неявных допущениях, каждое из которых неверно в проде.

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

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

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

Инженерная модель: слои архитектуры

Опишем конвейер так, как он выглядит на самом деле.

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

Слой индексации по событиям. Изменение источника порождает событие переиндексации именно этого документа. Индекс отстаёт от реальности на секунды, а не на сутки.

Слой поиска: гибридный. Параллельно работают семантический поиск (по смыслу) и лексический (по точным терминам, номерам, артикулам). Их результаты объединяются — это закрывает и «спросили своими словами», и «нужен конкретный пункт 4.2».

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

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

Слой генерации и оценки. Модель формирует ответ по поданному контексту; параллельно для части трафика оценивается обоснованность — опирается ли ответ на фрагменты. Модель здесь выбирается под задачу и заменяема: контракт слоя не меняется при смене модели.

Практический вывод для бизнеса

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

Стоимость и качество живут в одних и тех же слоях. Длина контекста — это одновременно про деньги и про смешивание источников; индексация по событиям — одновременно про свежесть и про доверие. Поэтому «сделать дешевле» и «сделать точнее» здесь часто один и тот же инженерный шаг, а не компромисс.

Замена модели не должна быть проектом. В правильной архитектуре модель — сменный слой за стабильным контрактом; если смена модели требует переписывания системы, архитектура неверна, и это будущая стоимость.

Приложить это к вашим процессам — обсудить с инженером → .

Открытые вопросы

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

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