Глава 3 — Retrieval-Augmented Generation

Третий пост поглавного разбора LLM Primer V: Building Real-World LLM Applications. Глава, проходящая RAG-конвейер от начала до конца и отделяющая демо, работающее на ваших десяти любимых документах, от системы, переживающей контакт с реальным корпусом.

Почему существует эта глава

Foundation-модель знает то, что показал ей обучающий корпус, и ничего больше. Продукт, который вы строите, почти наверняка требует, чтобы модель рассуждала о вещах вне этого корпуса — о внутренних документах, тикетах за прошлую неделю, истории заказов клиента, политике, вышедшей сегодня утром. Retrieval-Augmented Generation — инженерная дисциплина, закрывающая этот разрыв: на этапе запроса вытянуть релевантный материал из системы записи, отформатировать его в промпт и позволить модели генерировать против него. Наивная версия — один эмбеддинг-вызов и top-k lookup. Продакшен-версия — конвейер с стратегией chunking, трансформацией запроса, гибридным скорингом, reranker-ом и оценочной петлёй. Глава 3 проходит конвейер от начала до конца, а затем техники, превращающие демо-конвейер в развёртывание.

3.1 Пятиэтапный конвейер и гибридный retrieval

У минимального RAG-конвейера пять этапов, и каждый взаимодействует с остальными способами, очевидными задним числом. Загрузчики сохраняют структуру — заголовки, пути секций, временные метки, исходные URL, метки доступа, — потому что всё дальше по цепочке зависит от того, что сохранил загрузчик. Chunker-ы режут вдоль естественного шва документа, а не по произвольному счётчику токенов. Эмбеддеры проецируют чанки в векторное пространство, геометрия которого целиком определена обучающим распределением эмбеддинг-модели. Retriever-ы ищут ближайших соседей. Генераторы получают промпт с найденным контекстом, и обрамление важно: «отвечай, используя только контекст ниже, иначе скажи „у меня нет этой информации“» — это единственный самый эффективный анти-галлюцинационный паттерн в продакшен-RAG. Чистый плотный retrieval понимает парафраз, но промахивается по точным идентификаторам; лексический retrieval ловит идентификаторы, но промахивается по семантике; гибридный retrieval, склеенный через Reciprocal Rank Fusion, получает оба эффекта, а cross-encoder reranker поверх слитого top-50 покупает ещё десять-двадцать процентов точности.

3.2 Chunking — то, где качество живёт или умирает

Дефолт «резать каждые 500 токенов с 50 токенами перекрытия» работает на удивительно большом числе универсальных корпусов и отказывает почти на любом специализированном. Структурный chunker обходит HTML или Markdown по уровням заголовков и выдаёт по одному чанку на листовую секцию, с префиксом из хлебных крошек предков-заголовков. Parent-child chunker эмбеддит маленькие детские чанки ради точности retrieval, но расширяет каждое попадание до родительского абзаца перед передачей его генератору, разводя единицу поиска и единицу контекста. Семантический chunker обходит последовательность эмбеддингов предложений и режет там, где тема сдвигается. В композиции — структурный сначала и семантический внутри длинных секций — два паттерна покрывают почти все типы источников, встречающиеся в реальном корпусе. И каждый чанк несёт обогащающие метаданные — источник, URL, временную метку, путь заголовков, язык, область видимости, — потому что именно эти поля делают найденные чанки атрибутируемыми, фильтруемыми и читаемыми для остальной системы.

3.3 Трансформация запроса, мультимодальность и text-to-SQL

Пользовательский запрос редко является идеальным запросом для retrieval. Multi-query expansion просит модель дать несколько переформулировок, ищет по каждой и сливает. HyDE — Hypothetical Document Embeddings — просит модель выдумать правдоподобный ответ и эмбеддит его вместо вопроса, исходя из того, что ответы живут в другой области эмбеддинг-пространства, чем вопросы. Step-back prompting производит более общую версию вопроса, ищет и по ней, и по исходной и даёт модели использовать рамку для ответа на конкретный случай. Декомпозиция режет составной вопрос на подвопросы, с которыми retriever справится по одному. Итеративный retrieval даёт модели решать, что подтягивать дальше, — мост между RAG и агентами. RAG также выходит за пределы текста: CLIP-подобные совместные пространства image-text поддерживают мультимодальный retrieval, а text-to-SQL относится к схемам базы данных как к retrieval-корпусу и генерирует запросы против read-replica с таймаутом. Роутер выбирает подходящую трансформацию на запрос, а не запускает все сразу.

Что подготавливает глава 3

RAG — одна из способностей, а не единственная. Продакшен-ассистент редко живёт только на retrieval: ему нужно достать недавние заказы клиента, проверить остатки в другой системе, резюмировать результаты, задать уточняющий вопрос и сам решать, когда что делать. Естественная рамка для такого поведения — агентная: модель выбирает из набора инструментов, система запускает выбранный инструмент, результат возвращается модели, и цикл продолжается, пока задача не решена. Retrieval в этой рамке — один из инструментов, которого агент может дотянуться. Глава 4 превращает обёртку в агента: цикл ReAct, схемы инструментов как контракты и три слоя памяти, позволяющие агенту держать состояние между ходами.

Дальше — Глава 4: ИИ-агенты и вызов инструментов. Цикл, превращающий stateless-модель в актора, преследующего цель, — с инструментами, памятью и жёсткими границами на runaway-поведение.