Чанкинг и контекстуализация

Зачем это отдельный шаг

Чанкинг — разбиение документов на фрагменты, которые индексируются и попадают в контекст модели. Это первый шаг RAG и самый дешёвый способ испортить всё остальное: если фрагмент потерял смысл при нарезке, никакой reranker и никакая модель его не восстановят.

Фрагмент должен быть понятен сам по себе. Классический провал: нарезка по 500 символов, при которой в выдачу попадает абзац «…это делается через хук, описанный выше» — без заголовка, раздела и предмета речи. Формально это релевантный текст; фактически он бесполезен.

Стратегии

Стратегия	Как работает	Сильная сторона	Слабое место
Фиксированный размер	Режет по числу токенов или символов с перекрытием	Предсказуемая стоимость, простота	Рвёт смысл на границах
Рекурсивная	Пробует разделители по приоритету: разделы → абзацы → предложения	Держит логические блоки, если разметка есть	Зависит от качества структуры документа
По структуре	Режет по заголовкам Markdown/HTML, пунктам списков, таблицам	Фрагмент совпадает с разделом	Слишком крупные разделы приходится дробить дальше
Семантическая	Ищет границы по смене темы (сходство соседних предложений)	Лучше на «плоских» текстах без разметки	Дороже и медленнее индексации, результат нестабилен
Late chunking	Сначала считает эмбеддинг всего документа, затем режет по токенам	Фрагмент сохраняет контекст документа	Требует модели с большим окном и поддержки на стороне хранилища

Практический порядок выбора: структура → рекурсивная → фиксированная. Семантический чанкинг и late chunking — улучшения, к которым стоит переходить, когда есть набор вопросов и метрики, иначе не понять, помогло ли.

Размер и перекрытие

Единого правильного размера нет, но есть закономерности:

• Слишком мелко — фрагмент теряет предмет речи, растёт число кандидатов, падает точность.
• Слишком крупно — в контекст попадает лишнее, модель отвлекается, стоимость растёт, а нужный абзац «размывается» среди соседних.
• Перекрытие (10–20% длины) спасает предложение, разрезанное на границе, но увеличивает индекс и число дублей в выдаче.

Рабочий подход: сделать чанк равным смысловому блоку (раздел, подраздел, пункт регламента) и добавить по 1–2 предложения перекрытия. Если документ — таблица или список параметров, резать по строкам почти всегда хуже, чем хранить таблицу целиком.

Контекстуализация: главный дешёвый выигрыш

Даже хороший чанк теряет часть смысла в отрыве от документа. Anthropic предложил contextual retrieval: перед индексацией к каждому фрагменту добавляется короткое пояснение, где он находится и о чём документ в целом.

Например, к абзацу из инструкции добавляется: «Фрагмент из раздела о настройке кэширования в документации WordPress; речь о хуках плагина». Такое пояснение учитывается и при построении эмбеддинга, и при поиске по ключевым словам.

По замерам Anthropic в их оценке:

• контекстуализация сама по себе снизила число неудачных поисков примерно на 49%;
• вместе с reranking и гибридным поиском — примерно на 67%.

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

Цена — дополнительные вызовы модели на этапе индексации. Она окупается на корпусах, которые меняются редко и читаются часто; для потока логов или тикетов контекстуализация обычно слишком дорога.

Где ломается

• Нарезка по символам в коде и таблицах. Ломает синтаксис и выравнивание; для таких источников нужны структурные парсеры.
• Заголовки вне чанка. Раздел «Ограничения» без указания, чего именно ограничения, бесполезен.
• Дублирование. Перекрытие и копии документов дают в выдаче пять почти одинаковых фрагментов, из которых модель делает вид, что нашла подтверждение.
• Смешанные языки и форматы. PDF с колонками, сканы без OCR, docx с трекингом правок — парсинг важнее стратегии нарезки.
• Отсутствие привязки к источнику. Без пути, заголовка и даты у фрагмента нельзя ни сослаться, ни проверить актуальность.

Что проверять

• Читается ли чанк без соседей. Откройте случайные 20 фрагментов из индекса и прочитайте. Это быстрее любой метрики.
• Есть ли в чанке заголовок и источник. Минимум: документ, раздел, дата.
• Одинаково ли режется весь корпус. Разные стратегии для разных типов документов — норма, случайные — нет.
• Измеряется ли эффект. Набор из 30–50 реальных вопросов с известными ответами позволяет сравнить стратегии за час. См. Оценка качества.

Связанные материалы

• Поиск и reranking — что происходит с чанками после нарезки.
• Эмбеддинги и Vector DB — где они хранятся.
• Курируемая база знаний — альтернатива, в которой синтез делается при записи, а не при поиске.

Материалы и источники

• Anthropic: Introducing Contextual Retrieval — методика и замеры снижения неудачных поисков
• Jina AI: Late Chunking — эмбеддинг до нарезки
• LlamaIndex: стратегии чанкинга — обзор подходов и параметров
• Pinecone: Chunking strategies for LLM applications — практические рекомендации по размеру и перекрытию