Что такое Chunking (разбиение на чанки)
Подробнее
Когда у вас 10,000-страничный документ, его нельзя загрузить в LLM целиком (даже 1M-контекст не вместит). Поэтому документ разбивается на куски (чанки) по 200-1200 токенов и индексируется в векторной БД. При запросе ищутся релевантные чанки и подаются модели в контекст.
Стратегии: 1) Fixed-size — фиксированный размер (простая, грубая); 2) Sentence-based — по предложениям; 3) Semantic — по смысловым границам (через embeddings); 4) Recursive — иерархическая разбивка по размеру; 5) Hybrid — комбинация. Для русского языка лучше semantic + recursive из-за длинных предложений.
Параметры: размер чанка (200-1200 токенов), overlap (10-20% для контекста), метаданные (тег документа, страница, заголовок). Слишком маленькие чанки — теряется контекст. Слишком большие — низкая релевантность retrieval.
Примеры
- 200 токенов с overlap 50 — для FAQ
- 500 токенов с overlap 100 — для документации
- 1000 токенов — для длинных книг
- Recursive chunking по разделам — для отчётов
Частые вопросы
Какой размер чанка оптимален?
Для FAQ — 200-300 токенов. Для документации — 500-700. Для книг и отчётов — 800-1200. Главный принцип: один чанк = одна мысль.
Зачем overlap между чанками?
Чтобы не разрывать контекст по границе чанка. Если ответ на вопрос разделён между двумя чанками, overlap помогает найти оба.
Как chunking влияет на стоимость?
Меньше чанков → дешевле индексация и retrieval. Но плохой chunking требует подавать больше чанков на запрос (top-k=10 вместо 3) — дороже.
Какие библиотеки для chunking?
LangChain (RecursiveCharacterTextSplitter), LlamaIndex (NodeParsers), Haystack. Для семантического — sentence-transformers + custom logic.