RAG-системы: chunking, retrieval, reranking и hybrid search

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

За три года RAG превратился из академического концепта в обязательный компонент production-приложений на LLM. Разбираем устройство RAG-пайплайна изнутри: какие стратегии чанкинга существуют, как работает retrieval, зачем нужны reranking-модели, чем hybrid search отличается от чистого dense retrieval и какие production-проблемы возникают на масштабе.

Концепция RAG: что происходит под капотом

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

Этот простой пайплайн обманчиво легко собрать в прототипе, но в продакшене упирается в десятки нюансов. Размер чанка, выбор embedding-модели, метрика близости, способ ранжирования результатов, обработка multi-modal данных, стратегии обновления индекса — каждое решение влияет на качество ответов и стоимость инфраструктуры.

Chunking: стратегии разбивки документов

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

Fixed-size chunking

Самая простая стратегия — разбивка по фиксированному количеству токенов с заданным перекрытием. Типичные параметры: 256–512 токенов на чанк, 10–20% перекрытия. Перекрытие нужно, чтобы граничные предложения не теряли контекст соседних чанков. Подходит для homogeneous-данных без чёткой структуры — расшифровок звонков, чата с поддержкой.

Semantic chunking

Документ разбивается на предложения, для каждой пары соседних предложений считается косинусная близость эмбеддингов. Граница чанка проходит там, где близость падает ниже порога — то есть там, где меняется тема. Качество retrieval растёт, но стоимость индексирования увеличивается в разы из-за дополнительных эмбеддингов.

Recursive chunking

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

Document-aware chunking

Стратегия учитывает структуру конкретного типа документа. Для PDF — границы страниц и заголовков. Для Markdown — H1/H2/H3-разделы. Для кода — функции и классы. Для HTML — секции и таблицы. Качество растёт, но требует разной логики для каждого формата источника.

Embedding-модели: выбор и характеристики

Embedding-модель — мост между текстом и векторным пространством. Качество всей RAG-системы упирается в её способность размещать семантически близкие тексты рядом в этом пространстве. Параметры выбора: размерность вектора, объём обучающей выборки, поддержка многоязычности, размер контекстного окна, скорость инференса.

Размерности типичных моделей варьируются от 384 (компактные) до 3072 (крупные мультиязычные). Чем выше размерность, тем больше нюансов модель может закодировать, но тем выше стоимость хранения и поиска. Для большинства задач достаточно 768–1024 измерений.

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

• Размерность: 384, 768, 1024, 1536, 3072 — типичные значения
• Context window: от 256 до 8192 токенов, влияет на максимальный размер чанка
• Multilinguality: поддержка русского, влияет на семантическую точность
• Latency: от 5 мс (на GPU) до сотен мс (на CPU)
• Cost per million tokens: диапазон в десятки центов до нескольких долларов через API

Vector databases: что использовать для retrieval

Векторное хранилище — компонент, отвечающий за быстрый поиск ближайших векторов. На небольших объёмах (до сотен тысяч векторов) работают любые решения — даже in-memory массивы с numpy. На миллионах и миллиардах векторов выбор архитектуры становится критическим. Алгоритмы вроде HNSW (Hierarchical Navigable Small World), IVF (Inverted File Index), Product Quantization позволяют искать за миллисекунды на больших датасетах.

Выбор зависит от объёма данных, требований к латентности, бюджета и того, насколько глубоко команда хочет управлять инфраструктурой. Pinecone хорош для быстрого старта, pgvector — для команд, уже использующих PostgreSQL, Milvus и Qdrant — для self-hosted решений с большой нагрузкой.

Similarity search: cosine, dot product, Euclidean

После того как эмбеддинги получены, нужна метрика близости. Три основные: cosine similarity (косинус угла между векторами), dot product (скалярное произведение), Euclidean distance (евклидово расстояние). Для нормализованных эмбеддингов cosine и dot product эквивалентны.

Большинство embedding-моделей возвращает нормализованные векторы, поэтому де-факто стандарт — dot product как самый быстрый вариант. Euclidean распространён в специфических задачах вроде поиска по изображениям. Выбор метрики обычно диктуется не RAG-инженером, а embedding-моделью: в её документации указывается оптимальная метрика.

Hybrid search: dense + sparse (BM25)

Чистый dense retrieval — поиск по семантическим эмбеддингам — отлично работает с переформулированными запросами и синонимами, но проседает на специфической терминологии, аббревиатурах, номерах артикулов, именах собственных. Запрос «error code 4423» в чисто dense-системе может вернуть нерелевантные результаты, потому что код «4423» не имеет осмысленного эмбеддинга.

Hybrid search решает это объединением dense retrieval с классическим BM25 — алгоритмом полнотекстового поиска. BM25 хорошо находит точные совпадения терминов и аббревиатур, dense — семантически близкие формулировки. Финальная ранжировка получается комбинированием скоров двух методов через линейную интерполяцию или Reciprocal Rank Fusion (RRF).

В production-системах hybrid search почти всегда даёт лучшее качество, чем dense-only. Стоимость инфраструктуры выше, но рост точности retrieval окупает её на любых нетривиальных корпусах.

Reranking: cross-encoders и LLM-based reranking

Первичный retrieval оптимизирован под скорость и работает на больших объёмах — извлекает 50–200 потенциально релевантных чанков. Но не все из них одинаково полезны для конкретного запроса. Reranking — второй проход, где более тяжёлая модель пересчитывает релевантность каждой пары (запрос, чанк) и оставляет топ-5 или топ-10 лучших.

Cross-encoder reranker принимает на вход пару текстов и возвращает скор релевантности. В отличие от bi-encoder (используемого на первом этапе), он не строит независимые эмбеддинги, а смотрит на оба текста совместно — это даёт более точную оценку, но требует больше вычислений. Cross-encoders запускают только на сотнях кандидатов, не на миллионах документов.

LLM-based reranking — относительно новый подход. Большая языковая модель сама оценивает релевантность чанков к запросу, возвращая структурированный ответ. Дороже cross-encoder в десятки раз, но даёт самое высокое качество на сложных запросах с многоступенчатой логикой. Применяется на критически важных запросах или для дообучения cross-encoder через distillation.

Метрики качества RAG

Оценка RAG-системы — нетривиальная задача. Качество ответов LLM зависит и от retrieval (нашлись ли нужные факты), и от генерации (правильно ли модель их использовала). Поэтому метрики делятся на две группы.

• Метрики retrieval: precision@k, recall@k, MRR (Mean Reciprocal Rank), NDCG, hit rate. Показывают, насколько хорошо система находит релевантные чанки.
• Метрики генерации: faithfulness (соответствие ответа извлечённому контексту), answer relevancy, context relevancy. Показывают, насколько финальный ответ опирается на найденные данные.
• Сквозные метрики: end-to-end accuracy, hallucination rate, response correctness. Оценивают всю систему целиком.

Для практической оценки часто используется LLM-as-judge — большая модель оценивает ответы по заданным критериям. Это дешевле ручной разметки, но требует валидации: периодической сверки оценок модели и человека.

Контекстные окна и стратегии compaction

Современные LLM имеют контекстные окна от 128K до миллионов токенов. Кажется, что можно просто запихнуть в контекст все найденные чанки и не задумываться — но это создаёт три проблемы: рост стоимости инференса (платится за токены), деградация качества (модели хуже работают на длинных контекстах — эффект lost in the middle), увеличение латентности.

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

Production-проблемы RAG

В прототипе RAG работает идеально. В продакшене возникают системные проблемы: latency (особенно при использовании reranker), стоимость API-вызовов на embedding-модель и LLM, обновление индекса при изменении документов, обработка multi-modal данных (PDF с таблицами и изображениями), управление версиями документов и удаление устаревших чанков.

Отдельная проблема — drift качества. С течением времени корпус документов меняется, embedding-модель может обновляться, поведение пользователей эволюционирует. Без регулярной оценки качества и периодической переиндексации система медленно деградирует. Хороший production-RAG включает в себя continuous evaluation pipeline.

Multi-modal RAG: текст + изображения

Корпоративные документы редко бывают чисто текстовыми — таблицы, графики, скриншоты интерфейсов, фотографии оборудования. Multi-modal RAG расширяет пайплайн до работы с изображениями: либо через мультимодальные embedding-модели, способные кодировать и текст, и изображения в одно векторное пространство, либо через предварительное преобразование картинок в текстовые описания через vision-модели.

Особенно остро multi-modal стоит для PDF с диаграммами и техническими чертежами. Простое извлечение текста через OCR теряет смысловую часть изображений, а ответ на вопрос «как выглядит схема подключения?» без работы с картинкой невозможен.

Agentic RAG: когда retrieval вызывается итеративно

Классический RAG — одношаговый: один retrieval, один LLM-вызов. Agentic RAG превращает retrieval в инструмент, который агент может вызывать многократно. Сначала модель формулирует подзапросы по сложному вопросу, для каждого делает retrieval, потом синтезирует общий ответ. Качество растёт на многосоставных запросах вроде «сравни политику возврата у поставщиков A, B и C».

Минус — стоимость и латентность. Каждый дополнительный retrieval-цикл добавляет секунды и токены. Agentic RAG имеет смысл там, где запросы реально многосоставные и где цена ошибки выше цены вычислений.

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

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

Часто задаваемые вопросы

Какой размер чанка выбрать на старте?

Для текстовых документов общего назначения — 256–512 токенов с 10–20% перекрытия. Для технической документации с кодом — больше, 512–1024. Для коротких справок и FAQ — меньше, 128–256. Лучше начать с дефолтных значений фреймворка и оптимизировать по результатам evaluation.

Что выбрать — Pinecone, Weaviate или pgvector?

Pinecone — самый быстрый старт, но vendor lock-in и подписка по объёму. Weaviate — баланс managed и self-hosted, есть gibrid search из коробки. pgvector — лучший выбор, если PostgreSQL уже в стеке и объёмы до десятков миллионов векторов. Qdrant и Milvus — для больших объёмов и self-hosted.

Нужен ли reranker, если у меня уже работает hybrid search?

Hybrid search улучшает retrieval, но не финальное ранжирование извлечённых кандидатов. Reranker применяется к топ-кандидатам из hybrid search и поднимает качество финальной выборки. Если латентность позволяет, reranker обычно даёт +10–25% к точности.

Можно ли обойтись без vector database на маленьком проекте?

Для корпуса до 10 тысяч документов работает простой подход: эмбеддинги хранятся в numpy-массиве в памяти, поиск через brute-force cosine similarity. Это не масштабируется, но для прототипа и небольших внутренних инструментов — оптимальный выбор без накладных расходов на инфраструктуру.

Как бороться с галлюцинациями в RAG-ответах?

Стандартный набор: faithfulness-метрика на этапе оценки, инструкция в промте «отвечай только на основе предоставленного контекста, если ответа нет — сообщи об этом», добавление цитат с источниками для верификации, fallback-логика на «не знаю» при низком confidence retrieval.

Стоит ли использовать LLM для генерации синтетических вопросов к чанкам?

Подход называется HyDE (Hypothetical Document Embeddings) и его варианты. Для каждого чанка LLM генерирует вопросы, на которые этот чанк отвечает. Эмбеддинги вопросов используются вместо или дополнительно к эмбеддингам исходных чанков. Качество retrieval растёт, но индексирование становится дороже и медленнее.

Заключение

RAG в 2026 году — это не одна архитектура, а конструктор из десятка компонентов: чанкер, embedding-модель, векторное хранилище, retrieval-стратегия, reranker, compactor, LLM-генератор. Качество системы определяется выбором каждого компонента и их слаженной работой, а не самим фактом наличия RAG.

Главное правило production-RAG — измерять. Без evaluation-пайплайна с метриками retrieval и генерации система деградирует незаметно, ответы пользователям ухудшаются, доверие падает. Развитие RAG идёт в сторону агентных архитектур, мультимодальности, более качественных reranker’ов и интеграции с инструментами помимо vector search — full-text, графовыми базами, API-вызовами.

Для команд, начинающих внедрять RAG, разумный путь — собрать минимальный пайплайн на recursive chunking + open-source embedding + pgvector или Qdrant, прогнать на небольшом наборе тестовых запросов, измерить базовое качество, и итеративно усложнять: добавить hybrid search, потом reranker, потом continuous evaluation. Такой подход даёт работающий результат за недели вместо месяцев и закладывает основу для дальнейшего развития.