Чанкинг, переранжирование и гибридный поиск: как заставить RAG реально работать

Большинство RAG-реализаций работают плохо. С моделью всё в порядке — Claude или GPT-5 спокойно отвечают по извлечённым документам. Ломается извлечение. Вы задаёте вопрос, система возвращает не те чанки, и модель уверенно генерирует ответ по неправильной информации.

Эта статья — практический гид по трём вещам, которые чинят плохое извлечение: стратегия чанкинга, переранжирование и гибридный поиск. Сделайте их правильно — и большинство жалоб «RAG не работает на нашем кейсе» испарятся.

Сложную техническую математику опустим, сосредоточимся на том, что реально делать.

Почему извлечение ломается

Дефолтный RAG-пайплайн:

1. Разбить документы на чанки.
2. Сделать эмбеддинги каждого чанка.
3. На входящий вопрос — эмбеддинг и поиск самых похожих чанков (cosine similarity).
4. Передать их в LLM.

У каждого шага свои режимы провала:

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

Наивная similarity находит чанки, лексически близкие к запросу, но не реально релевантные. Запрос «как мне отменить подписку» вытащит любой чанк, где упоминается «подписка», включая никак не связанные с этим рекламные тексты.

Отсутствие переранжирования означает, что LLM видит то, что вернул similarity. Самый похожий чанк — не всегда самый релевантный.

Чисто семантический поиск пропускает важные exact-match-совпадения. Запрос «error code 503» может промахнуться мимо чанка с дословным текстом «error code 503», потому что семантический вектор запроса не совпадает с общей тематикой чанка.

Три исправления — лучший чанкинг, переранжирование, гибридный поиск — закрывают каждую из этих проблем.

Фикс 1: лучший чанкинг

Чанкинг — самое влиятельное единичное решение в RAG-пайплайне и то, о чём большинство не задумывается, пока результаты не станут плохими.

Наивный дефолт в большинстве no-code-инструментов — чанкинг по фиксированному количеству токенов (например, 500 токенов с перекрытием 50). Это работает «нормально», но часто ломается.

Стратегии получше:

Семантический чанкинг

Разбивайте документы по семантическим границам — там, где меняется тема, — а не по произвольному количеству токенов. У большинства современных фреймворков (LangChain, LlamaIndex) есть семантические чанкеры, которые ловят смены темы и режут именно там.

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

Структурно-зависимый чанкинг

Если у ваших документов есть естественная структура (Markdown-заголовки, секции HTML, главы PDF, границы функций в коде) — используйте её. Чанкуйте по секциям, а не по токенам.

Для Markdown:

• Каждая H2-секция — отдельный чанк (с H1-контекстом в начале).
• Длинные H2-секции разбиваются на подчанки, с повторённым H2-заголовком в качестве контекста.

Для кода:

• Каждая функция или класс — отдельный чанк.
• В чанк включается путь к файлу и относящиеся импорты.

Это драматически лучше слепого фиксированного чанкинга для любого структурированного контента.

Иерархический чанкинг

Паттерн из недавних RAG-исследований. Создавайте чанки на нескольких уровнях:

• Маленькие чанки (200–500 токенов) — для точного извлечения.
• Средние чанки (1000–2000 токенов) — для контекста.
• Резюме документа (50–100 токенов) — для матчинга высокого уровня.

При извлечении совпадаете по маленьким чанкам, но возвращаете окружающий средний чанк. LLM получает точную релевантность плюс достаточно контекста, чтобы её осмыслить.

Как выбрать размер чанка

Грубая эвристика по типу контента:

| Тип контента | Размер чанка | Логика | | --- | --- | --- | | Техдокументация / мануалы | 500–1000 токенов | Понятия самодостаточные, средняя плотность | | Код | Одна функция/класс на чанк | Логические единицы, а не произвольные срезы | | Длинные статьи / книги | 1000–2000 токенов | Мысли развиваются на несколько абзацев | | Тикеты поддержки | Один тикет = один чанк | Не дробите внутри тикета | | Юридические тексты / контракты | По секциям, часто 500–1500 токенов | Логические единицы; сохраняйте границы статей | | Табличные данные | Строка + заголовки | Каждая строка — чанк, с заголовками колонок |

Если вы пользуетесь no-code-инструментом, который прячет чанкинг, прогоните тест: задайте 10 вопросов, чьи ответы вы знаете и которые лежат в корпусе. Если извлечение регулярно промахивается мимо нужного чанка — проблема в чанкинге.

Хороший рабочий паттерн: «страница-или-секция, потом question-grounded»

Для большинства сценариев личного RAG рабочий паттерн такой:

1. Чанкуйте по секциям документа (Markdown H2, главам PDF и т. д.).
2. Чанки больше ~2000 токенов подчанкуйте по абзацам.
3. К каждому чанку в начале добавляйте контекст: название документа и заголовок секции.
4. В конце прикрепляйте короткое описание того, на какие вопросы этот чанк отвечает (автогенерируется быстрой LLM на этапе индексации).

Этот трюк с автогенерированным «на какие вопросы отвечает этот чанк» удивительно мало используется и удивительно мощный. Он работает, потому что пользовательские запросы часто формулируются как вопросы, и матчинг их к метаданным в форме вопроса точнее, чем матчинг к сырому тексту документа.

Фикс 2: переранжирование

После первичного извлечения (обычно возвращающего 20–50 чанков по векторной similarity) используйте reranker, чтобы переупорядочить их по реальной релевантности запросу.

Reranker — это отдельная модель (обычно маленькая, специализированная), которая принимает пары (запрос, чанк) и выдаёт оценку релевантности. Применяете её к топ-20–50 результатам, сортируете по новой оценке и передаёте топ-3–5 в LLM.

Выигрыш: драматически лучшая точность. Векторная similarity быстрая, но не сверхточная; rerankers медленнее, но намного точнее. Сочетание даёт быстрое извлечение с точным упорядочиванием.

Варианты reranker в 2026:

• Cohere Rerank — устоявшийся API-reranker. Около $1 за 1000 запросов.
• Voyage AI rerank-2 — сильный коммерческий вариант, часто лучше Cohere на нишевых доменах.
• bge-reranker-v2-m3 — open-source, поднимается локально или на дешёвом хостинге.
• Jina Reranker — ещё один сильный open-source-вариант.

В типичном пайплайне:

1. Векторный поиск возвращает топ-50 чанков (дёшево, быстро).
2. Reranker оценивает все 50 относительно запроса (дороже, медленнее).
3. Топ-5 по rerank-score уходят в LLM.

Добавленная задержка: около 200–500 мс. Прирост качества: часто 20–40% по бенчмаркам точности извлечения.

Для no-code-инструментов, в которых нет встроенного переранжирования (NotebookLM, большинство базовых конфигураций n8n), это самый высокоотдачный апгрейд, который можно сделать. У n8n есть нода Cohere Rerank; LangChain и LlamaIndex включают интеграции с rerankers нативно.

Фикс 3: гибридный поиск

Векторная similarity ловит семантические совпадения. Ключевой поиск (BM25 и аналогичные) ловит точные совпадения. Каждый пропускает то, что ловит другой.

Запрос «how to fix HTTP 503 errors on our gateway»:

• Векторный поиск найдёт чанки про HTTP-ошибки, проблемы шлюзов, диагностику.
• Ключевой поиск найдёт чанки, где конкретно упоминается «503» — а это может быть именно тот ответ.

Гибридный поиск прогоняет оба и комбинирует результаты. Комбинация делается методом, который называется Reciprocal Rank Fusion (RRF): по ранжированиям из каждого метода RRF строит сводное ранжирование, учитывающее оба сигнала.

Реализация в большинстве инструментов простая:

• Запускаете векторный поиск → получаете ранжированный список A.
• Запускаете BM25 / ключевой поиск → получаете ранжированный список B.
• Для каждого чанка считаете его RRF-score = 1/(k + rank_in_A) + 1/(k + rank_in_B) (где k обычно 60).
• Сортируете по сводной оценке, возвращаете топ.

В 2026 году гибридный поиск нативно поддерживают:

• Weaviate (векторное хранилище) — гибридный поиск из коробки.
• Qdrant — гибридный поиск через фильтрацию.
• Pinecone — гибридный поиск через sparse vectors.
• Elastic / OpenSearch — комбинированный keyword + vector.
• Большинство RAG-шаблонов в n8n — в современных шаблонах гибрид по умолчанию.

Выигрыш: драматически лучший recall на запросах, содержащих конкретные идентификаторы, коды, имена или жаргон. Для технического контента (код, коды ошибок, названия продуктов, ссылки на регуляции) гибридный поиск, по сути, обязателен.

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

Складываем всё вместе

State-of-the-art RAG-пайплайн в 2026 году:

Query
  ↓
Query rewriter (optional — clean up the query, expand abbreviations)
  ↓
Hybrid retrieval: vector + keyword search
  ↓
Top 30-50 results
  ↓
Reranker
  ↓
Top 5 by reranker score
  ↓
LLM with retrieved chunks + query
  ↓
Cited answer

Каждый шаг сам по себе дешёвый. Вместе они дают качество извлечения, качественно иное по сравнению с «vector similarity → top 5 → LLM».

Несколько менее распространённых, но мощных добавок:

Расширение запроса. Перепишите пользовательский запрос в несколько вариантов и ищите по каждому. Ловит разные формулировки.

Многошаговое извлечение. Для сложных вопросов делайте несколько извлечений. Первое определяет подвопросы; второе — достаёт ответы под каждый подвопрос.

Conversational retrieval. В многоходовом диалоге используйте историю разговора при извлечении («они спрашивали про X ранее, значит сейчас приоритезируем контент, связанный с X»).

Фильтрация по источникам. Используйте фильтры по метаданным, чтобы сузить извлечение. «Искать только в документах с тегом “EU regulations” и датой после 2023».

Они всё чаще доступны в no-code RAG-инструментах, но всегда проверяйте, что у вас есть базовые три (хороший чанкинг, reranker, гибридный поиск), прежде чем тянуться за продвинутыми.

Как измерять качество RAG

Нельзя улучшить то, что не измеряешь. Несколько практичных стратегий оценки:

Тест «золотых вопросов». Возьмите 20 вопросов, у которых вы знаете правильные ответы. Прогоните их через ваш RAG. Оценивайте: достали ли правильные чанки? Получился ли правильный ответ? Делайте это ежемесячно.

Recall извлечения at K. Для каждого золотого вопроса определите, какие чанки содержат ответ. Затем проверьте: вернула ли система извлечения хоть один из них в топ-K (5, 10, 20)? Считайте долю.

LLM-as-judge-оценка. Более продвинутая версия: пусть сильная модель (Claude Opus, GPT-5) оценивает, корректен ли ответ, точны ли цитирования, полон ли он и хорошо ли заземлён. Запускайте на пакете репрезентативных вопросов. У нас про evals есть отдельная статья.

Качество, воспринимаемое пользователем. Для командного или production RAG добавьте thumbs-up / thumbs-down к каждому ответу. Смотрите на паттерны thumbs-down. Они кучкуются вокруг конкретных типов вопросов — их и чините.

Самая большая ошибка — вообще пропустить измерение. «Кажется, нормально» — это не измерение. Без него вы не узнаете, работают ли ваши улучшения.

Разобранный пример: чиним проседающий RAG

Допустим, вы собрали личный RAG по внутренней документации компании. Качество посредственное — примерно 60% вопросов получают полезный ответ. Улучшения, которые стоит применить, в порядке:

Сначала аудит извлечения. Для десяти плохих ответов посмотрите, какие чанки были извлечены. Достался ли правильный чанк? Если да — проблема в модели или промпте. Если нет — проблема в извлечении.

Если проблема в извлечении:

1. Проверьте чанкинг. Чанки связные? Чанкер не режет посередине важных мыслей? Переключитесь на семантический или структурно-зависимый чанкинг.

1. Добавьте reranker. Если используется базовый векторный поиск и top-5, добавьте между извлечением и LLM Cohere Rerank или bge-reranker-v2-m3. Часто это 20–30% прироста качества.

1. Добавьте гибридный поиск. Особенно если запросы содержат специфичные термины (названия продуктов, коды ошибок, жаргон).

1. Осмотрите индексацию. Чанки тегированы метаданными (тип документа, секция, дата)? Используйте фильтры по метаданным в извлечении.

Если проблема в модели (правильные чанки достались, ответ неправильный):

1. Затяните промпт. Прямо скажите модели: «отвечай только по предоставленному контексту. Если контекст не покрывает вопрос — так и скажи».

1. Добавьте цитирования. Требуйте, чтобы модель цитировала конкретный использованный чанк. Это и помогает дебажить, и снижает галлюцинации.

1. Используйте более сильную модель. Если работаете на маленькой быстрой модели — попробуйте Claude Sonnet 4.5 или GPT-5.

После двух-трёх раундов такого расследования и фикса большинство RAG-реализаций выходят на 85–90% полезных ответов, а это тот порог, на котором пользователи начинают реально пользоваться системой и ей доверять.

Типичные ошибки

Несколько конкретных вещей, на которые систематически попадаются:

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

Забывают обновлять индекс при изменении документов. RAG с устаревшим контентом уверенно даёт неправильные ответы. Либо переиндексируйте регулярно, либо используйте систему с автосинком.

Игнорирование оценки. Большинство RAG разворачивают без измерения и потом никогда не улучшают. Фаза «вроде нормально» длится бесконечно. Закладывайте оценку с первого дня.

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

Излишнее усложнение на старте. Не нужно начинать со state-of-the-art-пайплайна. Начните с NotebookLM или базового векторного поиска. Добавляйте сложность только тогда, когда обнаружили конкретное узкое место.

Когда это особенно важно

Три фикса — лучший чанкинг, переранжирование, гибридный поиск — особенно важны, когда:

• Корпус технический, со специфичной терминологией.
• Запросы требуют точных совпадений (коды, имена, ID).
• Пользователям важна точность (юридическая сфера, комплаенс, поддержка).
• Система работает в масштабе (небольшой прирост качества сильно ощущается при 10 000 обращений в день).

И менее важны, когда:

• Корпус маленький (меньше 100 документов) и хорошо организован.
• Запросы открытые («какова наша позиция по X»).
• Пользователи готовы итерировать в поисках ответа.
• Сценарий исследовательский, а не точный.

Для большинства личных и небольших командных RAG переход от голой векторной similarity к «vector + reranker» — самый высокорычажный апгрейд. Гибридный поиск — следующий. Чанкинг важен на любом масштабе.

Что в итоге

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

Чтобы это применять, поисковым инженером быть не нужно. Инструменты — Weaviate, Pinecone, Qdrant, шаблоны n8n, интеграции LangChain — сделали техники доступными. Узкое место теперь — в основном знать, что они существуют, и применять их сознательно.

Если ваш RAG не работает — не вините модель. Посмотрите, какие чанки возвращаются, почините извлечение и переоцените. Большинство жалоб «RAG не работает» превращаются в «RAG теперь работает» в течение недели серьёзной работы над этим.