Глава 1 — Эволюция архитектуры RAG
Первый пост поглавного разбора LLM Primer III: Enhancing Enterprise AI with RAG. О том, как два структурных предела базовой модели — замороженное знание и отсутствие провенанса — оказываются с одним архитектурным ответом, и как этот ответ за три года отрастил четыре лица.
Почему существует эта глава
У трансформера, обученного на фиксированном корпусе, есть два предела, которых не стирает никакое дополнительное обучение. Его знание заканчивается в день, когда закончился корпус. И он не может сказать, из какого документа взято предложение, потому что предложение — это статистическое среднее по многим, а не цитата из одного. Первый отказ порождает уверенно неверные ответы про всё свежее. Второй — уверенно неверные ссылки. Вместе они порождают уже знакомую корпоративную патологию: ответ, который читается как авторитетный и ссылается на пункт, которого не существует.
RAG — это архитектурный ответ сразу на оба. Вы перестаёте требовать от модели знать всё заранее и начинаете подавать ей релевантный материал во время инференса, доставая его из корпуса, которым управляете. Корпус обновляется без переобучения. Найденные пассажи становятся цитатами, потому что вы их сознательно вытащили. Задача модели сокращается с воспоминания до синтеза. Остаток главы — история о том, как этот простой ход за три года превратился в четыре всё более сильные архитектуры.
1.1 Naive RAG: эмбеддинг, поиск, склейка
Самая простая форма — это то, что до сих пор описывает любой публичный туториал. Офлайн: разрезать корпус на чанки, прогнать каждый через эмбеддер, записать векторы в индекс. Онлайн: вычислить эмбеддинг запроса, достать топ-k ближайших чанков, склеить их в промпт, отправить модели, вернуть ответ со списком чанков как цитатами. Две функции и один векторный поиск.
Демо работает. Продукт — редко. Сходство ближайших соседей — это прокси релевантности, а не её измерение, и эмбеддеры, обученные на общем веб-тексте, регулярно путают урожай яблок с квартальной выручкой Apple. У чанкера нет сигнала о том, где заканчиваются предложения и начинаются таблицы. Один поисковый проход не способен обслужить вопрос, ответ на который разбросан по трём документам. А когда поиск отказывает, модель синтезирует из того, что вернулось — цитаты настоящие, но не подкрепляют ни единого утверждения ответа.
1.2 Advanced RAG: эвристики вокруг того же пайплайна
Вторая поза сохраняет хребет эмбеддинг-поиск-генерация и добавляет обработку до и после поискового вызова. Pre-retrieval усиления направлены на запрос: переписывание, расширение, декомпозиция, HyDE (черновик гипотетического ответа, эмбеддинг которого используется вместо запроса). Post-retrieval — на кандидатов: cross-encoder reranker, который оценивает запрос и пассаж совместно, а не порознь, дедупликация, фильтрация по метаданным, сжатие контекста.
Выигрыши не малые. Cross-encoder поверх векторного ретривера обычно переводит top-5 релевантность из диапазона 50–70% в диапазон 75–90%. Переписывание запроса добавляет ещё 5–10 пунктов там, где исходная формулировка была неоднозначной. Большинство продакшен-систем, обозначаемых просто как «RAG», сегодня живут в этой архитектуре, и для широкого класса корпоративных задач — Q&A по внутренней документации, дефлекция поддержки, поиск по базе знаний — это правильный уровень инвестиций. Чего она не даёт — гибкости. Каждый запрос проходит через один и тот же конвейер.
1.3 Modular RAG: компонуемые блоки, явный роутинг
К 2024 году и исследования, и инструментарий сошлись на Modular RAG. Те же приёмы остаются, но теперь они выставлены как дискретные, заменяемые компоненты, а пайплайн собирается под запрос. Маршрутизатор решает, какие ретриверы вызывать — плотный векторный индекс, BM25, SQL, внешний API — и результаты сливаются, часто через reciprocal rank fusion. Reranker выбирается по типу запроса. Генератор — по требуемому уровню качества. Архитектура превратилась из линии стадий в граф компонентов.
Два практических следствия. Во-первых, система становится тестируемой так, как не были тестируемы предыдущие позы — каждый компонент можно оценить и заменить независимо. Во-вторых, систему можно настраивать под класс запроса: факт-вопрос идёт через быстрый ретривер и небольшой генератор, синтез по нескольким документам — через несколько ретриверов и большой генератор, оба обслуживаются одной библиотекой компонентов. Цена операционная. Когда ответ неверен, вопрос где ошиблось? теперь имеет много возможных ответов, и команде нужна телеметрия, способная локализовать отказ до одного компонента. Сначала инвестируйте в наблюдаемость, потом — в модульность.
1.4 Agentic RAG: пайплайном управляет LLM
Четвёртая поза переворачивает допущение, которое три предыдущие тихо разделяли: что LLM — последний шаг. В Agentic RAG модель сама ведёт пайплайн. Получив каталог инструментов (векторный поиск, SQL, web fetch, reranker, калькулятор), модель думает, выбирает инструмент, видит результат, думает снова, останавливается, когда есть ответ или достигнут лимит шагов. Архитектура перестала быть конвейером и стала маленькой программой, которую модель пишет заново под каждый запрос.
Это покупает многошаговое планирование, динамический выбор инструментов и паттерны мультиагентной координации вроде planner/retriever/critic/writer. Платит — латентностью, токенами и воспроизводимостью: один запрос теперь дерево решений, а не фиксированная цепочка, и патологические запросы могут перебрать множество ходов, прежде чем выдать ответ. Продакшен-агентным системам нужны бюджеты, лимиты шагов и таймауты, о которых фиксированные пайплайны могли не думать. Правильный кейс — вопросы переменной и непредсказуемой глубины: исследовательский синтез, юридический поиск по прецедентам, литературный обзор. Неправильный — статичный бот поддержки, где агентный цикл добавляет дисперсию, которую задача не требовала.
1.5 RAG против дообучения
Вопрос, который рано или поздно задаёт каждая команда. Честная рамка: эти два решения решают разные задачи. RAG отвечает на проблемы знания — модель не знает X, X меняется, пользователю нужна цитата. Дообучение отвечает на проблемы поведения — модель знает ответ, но подаёт его в неверном формате, не следует шаблону компании или растекается там, где должна быть лаконичной. RAG дёшев в настройке и дорог на запрос. Дообучение — дорого один раз и дёшево на запрос. RAG итеративен за минуты (поменяйте документ); дообучение — за дни. Полезная эвристика: если отказ — модель не знает, тяните руку к RAG. Если отказ — модель знает, но делает не так, тяните к дообучению. Зрелые системы со временем часто делают и то и другое, но начинайте с RAG — большинство корпоративных отказов — это отказы знания, а не отказы поведения.
Что подготавливает глава 1
Любая архитектура RAG — какую бы из четырёх вы ни выбрали — находится ниже по потоку от того, насколько хорошо она умеет читать свои исходные документы. Modular-пайплайн с агентным оркестратором всё равно работает с чанками, вышедшими из этапа парсинга где-то выше. Если этот этап потерял структуру таблицы, перепутал порядок чтения в двух колонках или заменил подписи к рисункам искажённой OCR — каждый следующий компонент рассуждает над искажённым входом. Архитектура задаёт потолок системы. Парсер задаёт её пол. В большинстве продакшен-систем пол важнее, потому что большинство продакшен-систем и близко не у потолка.
Дальше — Глава 2: Интеллектуальный парсинг документов. Почему наивная утилита PDF-to-text тихо разрушает качество поиска, что на самом деле сохраняет парсинг с учётом макета и мультимодальная альтернатива, ищущая по изображениям страниц напрямую.
