Стратегии чанкинга для RAG: 7 методов с бенчмарками (2026)

Коротко: что выбрать

Chroma Research провела бенчмарк всех популярных стратегий чанкинга. Вердикт однозначный: стандартные настройки OpenAI Assistants (800 токенов, 400 overlap) дают 1.4% precision — худший результат среди всех протестированных конфигураций. А простой рекурсивный сплит 200 токенов без overlap показывает в 3.7 раза выше.

Чанкинг — это решение, на которое команды тратят меньше всего времени. И при этом оно сильнее всего влияет на качество RAG. В этом обзоре — 7 методов, их реальные цифры на бенчмарках и конкретные рекомендации под разные типы документов.

• Хотите быстро и предсказуемо — рекурсивный 512/1024 токенов, 10% overlap. Работает везде.
• Точность критична — Sentence Window или Parent-Child. Чуть сложнее, но радикально лучше.
• Длинные связные документы — Late Chunking с ColBERT. +6.5 пункта nDCG@10 на BEIR.
• Нет времени на подбор — Contextual Embeddings. Anthropic показала снижение ошибок на 35%.

Рекурсивный (Recursive Character)

Самый популярный метод — и по делу. Алгоритм пытается разбить текст по естественным разделителям (\n\n, \n, ., ?) в порядке приоритета. Если первый чанк превышает лимит — идёт по следующему разделителю. LangChain использует этот сплиттер по умолчанию.

По данным Vecta Benchmark (февраль 2026), рекурсивный сплит на 512 токенах набрал 69% accuracy. Семантический чанкинг, который все рекомендуют, — 54%. Разрыв не близкий, и дешёвый метод победил.

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

Семантический (Semantic)

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

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

Средний размер семантического чанка — 43 токена (данные Vecta Benchmark). Это слишком мало для quality-of-retrieval: модель получает слишком узкий контекст. На практике семантический чанкинг лучше комбинировать с parent-child подходом, где семантические границы определяют чанки нижнего уровня.

Sentence Window Retrieval

Элегантный гибрид: эмбеддинги считаются на небольших предложениях (для точного поиска), но на ответ LLM отправляется окно из ±K соседних предложений. По Pinecone, это часто даёт лучший результат, чем большой чанк, потому что в эмбеддинг не попадает шум из соседних абзацев.

Реализация: LangChain SentenceWindowRetrieval или самописный вариант с эмбеддингом на отдельных предложениях. Размер окна — обычно 3–5 предложений. Метод особенно хорош для Q&A-систем, где точное попадание в предложение важнее контекста.

Минус: если релевантное предложение короткое и не содержит ключевых слов запроса, поиск может его пропустить. Решение — BM25 как дополнительный retrieval (гибрид).

Parent-Child (Small-to-Big)

Хранит две гранулярности: маленькие «дочерние» чанки (одно-два предложения) для эмбеддинга и индексации, и большие «родительские» (абзац или секция) для подачи в LLM. При поиске находит дочерние чанки, но возвращает родительский контекст.

В середине 2025 года Reddit RAG community активно тестировала этот подход. Основной вывод: Parent-Child эффективнее Graph RAG для большинства сценариев — Graph RAG слишком медленный и дорогой для типовых вопросов. Parent-Child даёт 80% того же результата за 10% стоимости.

Хороший выбор для: FAQ по документации, поиск по инструкциям, медицинские/юридические тексты. Не подходит для: чата по код-базе (строки не имеют parent-child иерархии).

Contextual Embeddings (Anthropic)

Проблема классического чанкинга: чанки «анонимны». Чанк «Выручка выросла на 3%» — какой компании? Какой период? Из какого документа? Эмбеддинг этого предложения не содержит ответов.

Решение Anthropic: перед эмбеддингом добавить в каждый чанк контекст — название документа, заголовок секции, окружающие абзацы. Anthropic опубликовала бенчмарки (failure rate на top-20 чанков):

Внедряется просто: при генерации чанков добавить в начало префикс с контекстом. Увеличивает размер хранения на ~20–30%, но даёт одно из самых больших улучшений retrieval среди всех методов. Особенно эффективно на длинных документах (отчёты, исследования, книги), где без контекста чанки неразличимы.

Late Chunking (ColBERT)

Самый технически сложный из популярных методов. Вместо того чтобы разбивать текст на чанки ДО эмбеддинга, late chunking сначала пропускает весь документ через энкодер один раз, а потом разбивает его на уровне токенов для поиска. Используется с ColBERT-style моделями, где каждый токен имеет свой эмбеддинг.

Результаты на BEIR benchmark (NFCorpus, длинные документы): late chunking поднимает nDCG@10 с 23.46% до 29.98% — прибавка +6.5 пункта. На коротких документах прироста нет: метод эффективен именно там, где контекст длинный и связный.

Технические требования: модель с токен-уровневыми эмбеддингами (ColBERT-v2, ColPali). Такие модели тяжелее (1–5 ГБ) и медленнее обычных энкодеров. Плюс — сборка индекса сложнее, не все векторные БД поддерживают late interaction.

Где применять: поиск по монографиям, научным статьям, юридическим кейсам, многостраничным отчётам. Не имеет смысла для: FAQ, коротких документов (<1 страницы), чата по код-базе.

Agentic Chunking (LLM-based)

Даёт LLM агенту полномочия решать, как разбивать каждый документ. Модель сначала анализирует структуру документа (тип, разделы, логические блоки), а потом выбирает стратегию чанкинга адаптивно. IBM описывает это как «LLM сам решает, где проходят границы смысловых блоков».

Подход даёт лучшую семантическую когерентность, потому что LLM понимает контекст и не обрывает абзац посередине. Минусы очевидны: дорого (каждый документ проходит через LLM), медленно (дополнительный вызов модели на каждый файл), непредсказуемо (разные модели chunk'ят по-разному).

Community benchmarks (Reddit r/Rag) показывают: context-enriched chunking и agentic — лидеры по качеству, но agentic проигрывает по сложности. Для продакшена советуют использовать agentic только для «проблемных» документов (сложная вёрстка, PDF с колонками, таблицы), а для обычных текстов оставлять рекурсивный или semantic.

Сравнительная таблица

Все методы сведены в одну таблицу для быстрого сравнения:

Какой метод выбрать под свой стек

Универсального ответа нет, но Chroma Research и практика сообщества дают несколько твёрдых правил:

Overlap не нужен больше 10%. 50% overlap (OpenAI Assistants default) — худшая конфигурация по данным Chroma (1.4% precision). С 0% overlap на 200-токеновых чанках precision выше в разы, а recall почти не страдает.

Размер чанка = f(типа документа). Для коротких текстов (emails, чаты, новости) — 200–256 токенов. Для документации, инструкций — 512 токенов. Для аналитических отчётов — 1024 токена. Для книг и монографий — 1024+ с late chunking.

Эмбеддинг-модель — ограничитель. Современные LLM легко обрабатывают 128K+ контекста (GPT-5.2, Claude 4.5, Mistral Large). Ограничение не в модели генерации, а в эмбеддинг-модели — она работает с фиксированным окном (обычно 512 токенов). Чанк больше окна эмбеддера просто обрезается.

Parent-Child + Contextual Embeddings = мейнстрим 2026. Гибрид двух методов закрывает 80% сценариев: Parent-Child даёт две гранулярности, Contextual — решает проблему анонимных чанков. Реализация через LangChain ParentDocumentRetriever + кастомный префикс контекста.

Не забывайте про BM25. Гибридный поиск (векторный + keyword) даёт +10% recall по сравнению с чистым вектором. BM25 ловит точные совпадения, которые эмбеддинги могут пропустить из-за семантического сдвига. В Pinecone называют это «правилом буравчика для RAG»: если ваш поиск работает на одном методе — вы теряете 10–15% релевантных результатов по определению.

Что ещё важно знать

Материал основан на данных Chroma Research, NVIDIA, Pinecone, Anthropic, NAACL 2025 и практических кейсах сообщества RAG. Ссылки на источники — внутри текста.