Перейти к содержанию

Стратегии чанкинга для RAG

~8 минут чтения

URL: Firecrawl, LangCopilot, Agenta, Weaviate, Pinecone, arXiv Тип: rag / chunking / semantic-chunking / late-chunking / retrieval Дата: Февраль 2026 Сбор: Ralph Research ФАЗА 5

Предварительно: Проектирование RAG-систем

Зачем это нужно

RAG подает документы в LLM как контекст, но документ целиком не влезает -- его режут на куски (chunks). Как именно резать -- критично. Fixed-size режет механически по 512 токенов, разрывая предложения и мысли. Semantic chunking группирует по смыслу: пока эмбеддинги соседних предложений похожи -- это один чанк. Late Chunking переворачивает порядок: сначала эмбеддим документ целиком, потом нарезаем -- каждый кусок помнит глобальный контекст. Разница на практике: 60% retrieval accuracy у fixed-size vs 85%+ у semantic.

Part 1: Overview

Executive Summary

Fixed-size chunking ломает семантику

Fixed-size chunking разрывает предложения и абзацы посередине. На реальных данных это даёт 60% retrieval accuracy vs 85%+ у semantic chunking. Если accuracy критична -- никогда не используй fixed-size в production.

Key Insight:

Semantic chunking can boost RAG accuracy by up to 70% compared to fixed-size methods. Late Chunking (2024-2025 innovation) inverts traditional order--embedding entire documents first, then chunking--achieving 2-18% retrieval improvement by preserving global context.

2026 Chunking Strategy Hierarchy:

Strategy Accuracy Complexity Best For
Fixed-size Baseline Low Simple docs
Recursive +10-20% Low General use
Semantic +40-70% Medium Quality-focused
Late Chunking +50-85% High Long documents
Hybrid +60-90% High Production

Part 2: Traditional Chunking Methods

1. Fixed-Size Chunking

Concept: Split text at fixed character or token count.

Пример (fixed-size, 20 символов):

  • Chunk 1: "The quick brown fox " -- обрезано посередине мысли
  • Chunk 2: "jumps over the lazy " -- продолжение без начала
  • Chunk 3: "dog. The dog sleep" -- два предложения в одном куске, второе обрезано

Предложения разорваны, контекст потерян.

Fixed-Size Parameters:

Parameter Typical Value Impact
Chunk size 256-1024 tokens Larger = more context, less precision
Overlap 50-200 tokens More = less boundary loss

Pros & Cons:

Pro Con
Simple implementation Breaks semantic boundaries
Predictable memory Context loss at boundaries
Fast processing Variable quality

2. Recursive Character Splitting

Concept: Use prioritized list of separators (paragraphs → sentences → words).

Приоритет разделителей:

  1. Разбить по "\n\n" (абзацы)
  2. Если чанк слишком большой → разбить по "\n" (строки)
  3. Если все ещё большой → разбить по ". " (предложения)
  4. Если все ещё большой → разбить по " " (слова)
  5. В крайнем случае → разбить по символам

Recursive vs Fixed-Size:

Metric Fixed-Size Recursive
Semantic coherence Low Medium
Context preservation Low Medium
Implementation Simple Simple
Best for Simple docs General text

Part 3: Semantic Chunking

Core Concept

Semantic chunking splits text based on conceptual boundaries and meaning, not character counts.

  1. Разбить текст на предложения
  2. Получить эмбеддинг каждого предложения
  3. Вычислить similarity между соседними предложениями
  4. Создать новый чанк когда similarity падает ниже порога

Пример:

  • Sentence A: "Python is a programming language" → Sentence B: "It supports multiple paradigms" → similarity = 0.85 → один чанк
  • Sentence B → Sentence C: "The Eiffel Tower is in Paris" → similarity = 0.15 → новый чанк

Semantic Chunking Formula

\[\text{Chunk Boundary} = \arg\max_i \{i : \text{sim}(\text{embed}(s_i), \text{embed}(s_{i+1})) < \theta\}\]

Where \(\theta\) is the similarity threshold (typically 0.5-0.8).

Semantic Chunking Benefits

Benefit Description
Conceptual coherence Each chunk = one idea
Better retrieval Query matches complete concepts
Context preservation Related info stays together
Adaptive sizing Chunks sized by meaning

Semantic Chunking Impact

Metric Fixed Recursive Semantic
Retrieval accuracy 60% 70% 85%+
Semantic coherence Low Medium High
Processing time Fast Fast Medium

Part 4: Late Chunking (2024-2025 Innovation)

Core Concept

Late Chunking inverts traditional order: embed entire document first, then chunk.

Traditional RAG: Document → Chunk → Embed each chunk → Vector Store. Контекст теряется при нарезке.

Late Chunking переворачивает порядок:

  1. Токенизировать весь документ
  2. Пропустить все токены через long-context модель эмбеддингов
  3. Применить mean pooling к диапазонам токенов → эмбеддинги чанков
  4. Каждый эмбеддинг чанка сохраняет глобальный контекст документа

Late Chunking Performance

Benchmark Traditional Late Chunking Improvement
Retrieval quality Baseline +2-18% Significant
Context preservation Lost Preserved Critical
Long document handling Poor Good Major

When to Use Late Chunking

Use Case Recommended Reason
Long documents ✅ Yes Context preserved
Technical docs ✅ Yes Cross-references kept
Legal contracts ✅ Yes Clause context
Short articles ⚠️ Maybe Overkill
Simple FAQ ❌ No Not worth complexity

Part 5: Advanced Strategies

1. Hierarchical Chunking

Concept: Multiple chunk levels (small for retrieval, large for context).

Уровень Размер Назначение
Level 1 (мелкие) 256 токенов Векторный поиск, точное совпадение
Level 2 (средние) 512 токенов Вписывание в context window
Level 3 (крупные) 1024+ токенов Полный контекст, суммаризация

Retrieval: поиск по Level 1 → возврат контекста из Level ⅔.

Chunk size побольше != контекст получше

Соблазнительно поставить chunk size 2048 токенов "чтобы точно хватило контекста". Но при retrieval большой чанк содержит много нерелевантного текста -- similarity score падает, нужный чанк проигрывает в ранжировании. Оптимум: мелкие чанки для поиска (256-512), крупные для контекста (1024+). Ищем точно, отдаём широко.

2. Parent Chunk Strategy

Aspect Details
Small chunks For precise retrieval
Parent chunks Returned for LLM context
Mapping Child → Parent relationship

3. Contextual Retrieval

Concept: Prepend document context to each chunk.

Без контекста: "The model achieved 95% accuracy on the test set" -- какая модель? Какой test set?

С контекстом: "Document: BERT Paper, Section: Experiments. The model achieved 95% accuracy on the test set" -- теперь ясно: это BERT, секция экспериментов.

4. Max-Min Semantic Chunking (Dec 2025)

Aspect Details
Developer Milvus
Innovation Embedding-first approach
Benefit Smarter chunk boundaries
Improvement Better context + RAG accuracy

5. Agentic Chunking (2025)

Concept: Agent dynamically selects chunking strategy per document.

Агент анализирует документ и динамически выбирает стратегию:

  1. Анализ структуры -- секции, заголовки, вложенность
  2. Плотность контента -- технический vs нарративный
  3. Длина документа и целевой use case
  4. Решение: "Это техническое руководство → semantic + hierarchical chunking с сохранением code blocks"

Part 6: Language-Specific Chunking

Code Chunking

Strategy Description
Function-level Split at function/class boundaries
AST-based Parse syntax tree, split on nodes
Doc-level Entire files as chunks

Markdown Chunking

Element Handling
Headers New chunk boundary
Code blocks Keep together
Tables Keep together
Lists Keep related items

Part 7: Selection Guide

Decision Tree

graph TD
    START{"Document type?"} -->|"Simple, short"| REC["Recursive chunking"]
    START -->|"Long, context-heavy"| LATE["Late Chunking"]
    START -->|"Quality-critical"| SEM["Semantic chunking"]
    START -->|"Mixed types"| AGENT["Agentic chunking"]
    START -->|"Retrieval + context"| HIER["Hierarchical / Parent chunk"]
    START -->|"Production at scale"| HYB["Hybrid (semantic + hierarchical)"]

    style REC fill:#e8f5e9,stroke:#4caf50
    style LATE fill:#e8eaf6,stroke:#3f51b5
    style SEM fill:#fff3e0,stroke:#ff9800
    style AGENT fill:#fce4ec,stroke:#e91e63
    style HIER fill:#e0f7fa,stroke:#00bcd4
    style HYB fill:#f3e5f5,stroke:#9c27b0

Use Case Matrix

Use Case Primary Secondary Chunk Size
FAQ/Support Recursive - 256-512
Technical docs Semantic Hierarchical 512-1024
Legal contracts Late Chunking Contextual 1024+
Research papers Semantic Parent chunk 512-1024
Code documentation AST-based Hierarchical Function-level
News articles Recursive - 256-512

Part 8: Interview-Relevant Numbers

Accuracy Comparison

Strategy Retrieval Accuracy Improvement
Fixed-size 60% Baseline
Recursive 70% +10%
Semantic 85% +25%
Late Chunking 87% +27%
Hybrid 90%+ +30%+

Processing Overhead

Strategy Time Impact Memory Impact
Fixed-size 1x 1x
Recursive 1x 1x
Semantic 1.5-2x 1.5x
Late Chunking 2-3x 2x
Agentic 3-5x 2x

Chunk Size Guidelines

Model Optimal Chunk Max Chunk
GPT-3.5/4 512-1024 8192
Claude 3 1024-2048 100K+
Local 7B 256-512 4096

Late Chunking Benchmarks

Benchmark Improvement
Single-hop retrieval +2-5%
Multi-hop retrieval +10-18%
Long document QA +15-20%

Interview Questions

1. Как выбрать стратегию чанкинга для production RAG?

❌ Red flag: "Semantic chunking всегда лучше"

✅ Strong answer: "Зависит от данных и требований. FAQ/короткие тексты: recursive chunking (просто, быстро, достаточно). Технические документы: semantic chunking (сохраняет концептуальную целостность). Юридические контракты: late chunking (важен глобальный контекст). Production на масштабе: hierarchical -- мелкие чанки для поиска (256-512 токенов), крупные для контекста (1024+). Ищем точно, возвращаем широко."

2. Late chunking vs semantic chunking: в чём принципиальная разница?

❌ Red flag: "Late chunking -- просто улучшенная версия semantic chunking"

✅ Strong answer: "Порядок операций разный. Semantic: split → embed каждый чанк → store. Late: embed весь документ → split эмбеддинги → store. В semantic chunking каждый чанк эмбеддится изолированно -- если чанк содержит 'The model achieved 95%', непонятно о какой модели речь. В late chunking весь документ проходит через long-context модель, и mean pooling по диапазонам токенов сохраняет глобальный контекст в каждом chunk embedding. Gain: +2-5% single-hop, +10-18% multi-hop retrieval."

3. Fixed-size chunking дает 60% accuracy -- почему его вообще используют?

❌ Red flag: "Его не нужно использовать, это устаревший подход"

✅ Strong answer: "Три причины: (1) Простота -- одна строка кода, нет зависимости от embedding модели. (2) Предсказуемость -- фиксированный размер чанков = предсказуемая стоимость и latency. (3) Скорость -- нет overhead на вычисление эмбеддингов при индексации. Для простых FAQ, support tickets, structured данных -- fixed-size с overlap 10-20% дает приемлемые результаты. Semantic chunking оправдан когда данные неструктурированные и quality критичен."

See Also

Sources

  1. Firecrawl -- "Best Chunking Strategies for RAG in 2025"
  2. LangCopilot — "Document Chunking for RAG: 9 Strategies Tested (70% Accuracy Boost)"
  3. Agenta — "The Ultimate Guide to RAG Chunking Strategies"
  4. Weaviate — "Chunking Strategies to Improve Your RAG Performance"
  5. Pinecone — "Chunking Strategies for LLM Applications"
  6. arXiv — "Where Do LLMs Still Struggle? Code Generation Analysis" (2511.04355)
  7. Medium — "Max-Min Semantic Chunking for RAG"
  8. ResearchGate — "Data Chunking Strategies for RAG in 2025"