Какой размер чанка оптимален для RAG?

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

Насколько большим должно быть перекрытие чанков?

От десяти до двадцати процентов размера чанка — примерно 50–100 токенов для чанка в 500 токенов. Перекрытие не даёт смыслу обрываться на границе; слишком малое фрагментирует контекст на разрыве, слишком большое раздувает индекс и вызывает почти дублирующие результаты. NVIDIA установила, что около 15 % оптимально для финансовых документов.

Семантический чанкинг лучше фиксированного?

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

Что такое позднее разбиение и когда его применять?

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

Действительно ли контекстный поиск повышает точность?

Да, измеримо. Anthropic сообщила, что добавление к каждому чанку сгенерированной LLM контекстной заметки сократило ошибки поиска в top-20 на 35 % при контекстных эмбеддингах, на 49 % в сочетании с контекстным BM25 и на 67 % при добавлении реранкинга — и всё это примерно за $1,02 на миллион токенов документа при кэшировании промптов. Это наиболее оправдано для ценных корпусов, где пропущенный фрагмент обходится дорого.

С какой стратегии чанкинга стоит начать?

С рекурсивного чанкинга примерно с 500 токенами и 15 % перекрытием. Он уважает естественные границы, дёшев и служит сильной базовой линией для большинства контента. Добавьте структурно-ориентированное разбиение для PDF и руководств, поиск по родительскому документу, когда ответам нужно больше контекста, и контекстный поиск только там, где ставки оправдывают дополнительные расходы.

← Resources

By Priya Shah — Senior Engineer, RAG + Knowledge · 2026-05-22 · TUTORIAL

Стратегии чанкинга для RAG: размеры, перекрытие и что работает

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

Почему чанкинг определяет качество RAG

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

Шесть стратегий, доминирующих на практике

Современная практика сводится к шести подходам:

Фиксированный размер: равные отрезки токенов или символов с перекрытием. Самый старый, дешёвый и воспроизводимый — и на удивление сильная базовая линия.
Рекурсивный: разбиение по иерархии разделителей (абзац → строка → предложение), чтобы уложиться в лимит размера, не нарушая естественных границ. Рекомендуемый вариант по умолчанию.
Семантический: группирует предложения по близости эмбеддингов, чтобы каждый чанк охватывал одну тему. Выигрыш по сравнению с рекурсивным непостоянен и требует дополнительных вычислений на эмбеддинги.
Структурно-ориентированный: разбиение по структуре документа (заголовки, разделы, страницы, markdown). Лучший выбор для PDF, руководств и финансовых документов.
Позднее разбиение: сначала весь документ кодируется в эмбеддинги моделью с длинным контекстом, затем эмбеддинги токенов объединяются в чанки — так каждый чанк несёт глобальный контекст.
Контекстный поиск: перед индексацией к каждому чанку добавляется сгенерированная LLM контекстная заметка.

Начните с рекурсивного; переходите к остальным, когда этого требуют документы или типы запросов.

Размер чанка и перекрытие: конкретные числа

Универсального оптимального размера не существует, но есть хорошие отправные точки. Начните примерно с 400–512 токенов и перекрытия 10–20 % (около 50–100 токенов для чанка в 500 токенов). Затем подбирайте размер под тип запроса: маленькие чанки (128–256 токенов) хороши для точного поиска фактов и ключевых слов, а большие (512–1024 токена) — для аналитических запросов и суммаризации, где важна связность изложения.

Перекрытие не даёт смыслу обрываться на границе: слишком малое фрагментирует контекст, слишком большое раздувает индекс и дублирует результаты поиска. Бенчмарк NVIDIA показал, что около 15 % перекрытия оптимально для финансовых документов, а постраничное разбиение обеспечивает самую высокую и стабильную точность на смешанных корпусах — фактологические запросы достигают пика при 256–512 токенах, аналитические — при 1024+.

Продвинутый уровень: контекстный поиск и позднее разбиение

Две более новые техники решают одну и ту же проблему — чанк со словами «выручка выросла на 15 %» бесполезен, если непонятно, о какой компании или квартале идёт речь.

Контекстный поиск от Anthropic добавляет к каждому чанку — перед эмбеддингом и индексацией BM25 — контекстную заметку объёмом 50–100 токенов, сгенерированную LLM. По сравнению с базовым уровнем ошибок 5,7 % для top-20 контекстные эмбеддинги сокращают ошибки на 35 %, добавление контекстного BM25 — на 49 %, а добавление реранкинга — на 67 %, и всё это примерно за $1,02 на миллион токенов документа при кэшировании промптов.

Позднее разбиение от Jina переворачивает конвейер: сначала весь документ кодируется в эмбеддинги моделью с длинным контекстом (до ~8192 токенов), затем контекстуализированные эмбеддинги токенов объединяются в чанки — так каждый эмбеддинг чанка уже несёт межчанковый контекст. Применяйте этот подход для длинных документов с дальними зависимостями.

Поиск по родительскому документу и метаданные

Два усовершенствования окупаются почти везде. Поиск по родительскому документу («от малого к большому») разделяет гранулярность поиска и генерации: индексируйте маленькие дочерние чанки (≈100–500 токенов) для точного сопоставления, но возвращайте модели более крупный родительский раздел (≈500–2000 токенов), чтобы у неё был окружающий контекст. А обогащение метаданными — добавление к каждому чанку источника, заголовка раздела, номера страницы и меток времени — улучшает фильтрацию, обеспечивает цитирование и повышает точность поиска независимо от размера чанка.

Выбор и настройка в osFoundry

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

osFoundry рассматривает всё это как конфигурацию, а не код. Автоматический чанкинг поставляется с разумным рекурсивным значением по умолчанию, а настраиваемый RAG-конвейер позволяет задавать размер, перекрытие и стратегию для каждой базы знаний — с реранкингом и поиском по родительскому документу в виде переключателей этапов конвейера. Поскольку этапы настраиваемы, вы можете проводить A/B-тестирование настроек чанкинга на собственном распределении запросов — фактологических против аналитических — оставляя остальной стек неизменным. Именно такой рабочий процесс с настраиваемыми параметрами и рекомендуют исследования.

Frequently asked questions

Какой размер чанка оптимален для RAG?: Универсального ответа нет, но хорошая отправная точка — 400–512 токенов с перекрытием 10–20 %. Затем настройте под тип запроса: 128–256 токенов для точного поиска фактов и 512–1024 токена для аналитических запросов или суммаризации. Лучше протестировать несколько размеров на собственных вопросах, чем полагаться на единственное значение по умолчанию.
Насколько большим должно быть перекрытие чанков?: От десяти до двадцати процентов размера чанка — примерно 50–100 токенов для чанка в 500 токенов. Перекрытие не даёт смыслу обрываться на границе; слишком малое фрагментирует контекст на разрыве, слишком большое раздувает индекс и вызывает почти дублирующие результаты. NVIDIA установила, что около 15 % оптимально для финансовых документов.
Семантический чанкинг лучше фиксированного?: Не стабильно. Семантический чанкинг группирует предложения по теме, что звучит привлекательнее, но бенчмарки показывают: его выигрыш по сравнению с рекурсивным или фиксированным чанкингом непостоянен и часто не оправдывает дополнительных вычислений на эмбеддинги. Фиксированный и рекурсивный чанкинг остаются сильными и дешёвыми базовыми линиями — начните с них и переходите к семантическому только если оценка покажет реальный прирост.
Что такое позднее разбиение и когда его применять?: Позднее разбиение сначала кодирует весь документ в эмбеддинги моделью эмбеддингов длинного контекста, а затем объединяет эмбеддинги токенов в чанки — так вектор каждого чанка несёт контекст всего документа, а не только собственного текста. Применяйте его для длинных документов с дальними зависимостями, где фрагмент имеет смысл только с учётом предшествующего контекста.
Действительно ли контекстный поиск повышает точность?: Да, измеримо. Anthropic сообщила, что добавление к каждому чанку сгенерированной LLM контекстной заметки сократило ошибки поиска в top-20 на 35 % при контекстных эмбеддингах, на 49 % в сочетании с контекстным BM25 и на 67 % при добавлении реранкинга — и всё это примерно за $1,02 на миллион токенов документа при кэшировании промптов. Это наиболее оправдано для ценных корпусов, где пропущенный фрагмент обходится дорого.
Что такое поиск по родительскому документу («от малого к большому»)?: Он разделяет то, как вы сопоставляете, и то, что возвращаете. Вы индексируете маленькие дочерние чанки для точного сопоставления, но когда один из них совпадает, передаёте модели более крупный родительский раздел с окружающим контекстом. Так вы получаете полноту маленьких чанков и связность больших, не жертвуя ни тем, ни другим.
С какой стратегии чанкинга стоит начать?: С рекурсивного чанкинга примерно с 500 токенами и 15 % перекрытием. Он уважает естественные границы, дёшев и служит сильной базовой линией для большинства контента. Добавьте структурно-ориентированное разбиение для PDF и руководств, поиск по родительскому документу, когда ответам нужно больше контекста, и контекстный поиск только там, где ставки оправдывают дополнительные расходы.