Чанкинг для RAG: размер чанка и overlap

Чанкинг — разбиение документа на фрагменты перед вычислением эмбеддингов. От границ чанка зависит, сможет ли поиск вернуть точный ответ вместе с необходимым контекстом.

Почему нельзя индексировать документ целиком

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

Базовые параметры:

• chunk size — максимальный размер фрагмента в токенах или символах;
• overlap — часть текста, повторяющаяся между соседними чанками;
• separator — предпочтительные границы: раздел, абзац, предложение, пробел.

Универсального числа нет. Для FAQ подойдут короткие фрагменты, для юридических условий и технических инструкций часто нужен больший контекст.

Стратегии разбиения

Фиксированный размер прост и быстр, но может разрезать мысль посередине. Recursive splitting сначала пытается делить по заголовкам и абзацам, затем по предложениям и только потом по символам. Это хороший baseline для обычного текста.

Структурный чанкинг учитывает Markdown-заголовки, HTML, страницы PDF, функции в коде или строки таблицы. Семантический чанкинг ищет изменение темы по эмбеддингам предложений, но требует больше вычислений и сложнее отлаживается.

В parent-child схеме поиск идёт по маленьким дочерним фрагментам, а в контекст возвращается более крупный родительский блок. Так точность retrieval сочетается с целостным контекстом.

Overlap страхует границы, но его избыток создаёт дубликаты в top-k, увеличивает индекс и стоимость. Начинать разумно с небольшого overlap, а не с половины чанка.

Как подобрать размер экспериментально

Соберите 30–100 реальных вопросов и отметьте фрагменты, в которых лежит ответ. Затем сравните несколько конфигураций на одинаковой embedding-модели: например, короткие, средние и крупные чанки с разным overlap.

Смотрите не только Recall@k. Проверяйте дубли, среднее число токенов в контексте и качество финального ответа. Если нужный чанк находится, но модель не понимает его без соседнего раздела, увеличьте контекст или примените parent-child. Если top-k заполнен похожими копиями, уменьшите overlap либо добавьте дедупликацию.

Сохраняйте в metadata заголовок раздела, путь документа, страницу и идентификатор родителя. Эти поля пригодятся для фильтрации, цитирования и восстановления расширенного контекста.

Хороший чанкинг — не тот, где выбран популярный размер, а тот, который стабильно возвращает доказательство на вашем тестовом наборе.