---
title: Чанкинг и контекстуализация
description: "Как нарезать документы для поиска: стратегии чанкинга, размер и перекрытие, контекстуализация фрагментов и почему ошибка нарезки не лечится сменой модели."
---

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

Чанкинг — разбиение документов на фрагменты, которые индексируются и попадают в контекст модели. Это первый шаг 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 реальных вопросов с известными ответами позволяет сравнить стратегии за час. См. [Оценка качества](https://wpcraft.ru/kb/ai/agents/evaluation.md).

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

- [Поиск и reranking](https://wpcraft.ru/kb/ai/rag/retrieval.md) — что происходит с чанками после нарезки.
- [Эмбеддинги и Vector DB](https://wpcraft.ru/kb/ai/rag/embeddings-and-vector-db.md) — где они хранятся.
- [Курируемая база знаний](https://wpcraft.ru/kb/ai/rag/knowledge-bases.md) — альтернатива, в которой синтез делается при записи, а не при поиске.

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

- [Anthropic: Introducing Contextual Retrieval](https://www.anthropic.com/research/contextual-retrieval) — методика и замеры снижения неудачных поисков
- [Jina AI: Late Chunking](https://jina.ai/news/late-chunking-in-long-context-embedding-models/) — эмбеддинг до нарезки
- [LlamaIndex: стратегии чанкинга](https://docs.llamaindex.ai/en/stable/module_guides/loading/node_parsers/) — обзор подходов и параметров
- [Pinecone: Chunking strategies for LLM applications](https://www.pinecone.io/learn/chunking-strategies/) — практические рекомендации по размеру и перекрытию