English translation is not available yet. Showing Russian content.
Какие стратегии chunking'а вы знаете и когда какую применяете?
Краткий тезис
Chunking (разбиение документов на фрагменты) — один из самых важных этапов RAG. От выбора стратегии зависит, насколько хорошо retrieval найдёт нужную информацию и насколько полным будет контекст для LLM. Разные стратегии подходят для разных типов данных: от простых фиксированных кусков до семантических границ и иерархического разбиения по структуре документа.
1. Термин: Chunking (разбиение на чанки)
Что это Процесс разделения длинного документа на маленькие, логически завершённые фрагменты (чанки), которые затем индексируются в векторной БД.
Зачем нужен chunking
| Причина | Объяснение |
|---|---|
| Контекстное окно LLM | LLM имеют ограниченное окно (4k-128k токенов). Нельзя скормить весь документ целиком |
| Качество retrieval | Маленькие чанки точнее матчатся с запросом, чем огромные куски текста |
| Стоимость эмбеддингов | Embedding модели имеют ограничение на длину входа (обычно 512-8192 токенов) |
| Релевантность | Слишком большой чанк содержит много нерелевантной информации |
Термин «Токен» Базовая единица текста для LLM. 1 токен ≈ 0.75 слова на английском, ≈ 0.5 слова на русском.
2. Стратегия 1: Fixed-size chunking (фиксированный размер)
Как работает Документ режется на чанки строго по количеству символов/токенов. Самый простой и быстрый метод.
# Пример: чанки по 500 символов
text = "очень длинный текст..."
chunk_size = 500
chunks = [text[i:i+chunk_size] for i in range(0, len(text), chunk_size)]
| Плюсы | Минусы |
|---|---|
| Простота реализации | Режет предложения и абзацы посередине |
| Максимальная скорость | Теряет смысловую структуру |
| Предсказуемый размер чанков | Может разорвать важную мысль |
Когда применять Очень однородные данные, где структура не важна — логи серверов, JSON-строки, CSV-файлы, машинный код.
Термин «Однородные данные» (homogeneous data Данные, где все элементы имеют одинаковую структуру и не содержат естественных границ (абзацев, предложений, разделов).
3. Стратегия 2: RecursiveCharacterTextSplitter (рекурсивное разбиение)
Как работает LangChain-разделитель, который рекурсивно пробует разбить текст по иерархии разделителей: сначала по параграфам (\n\n), затем по предложениям (.), затем по словам ( ), затем по символам.
from langchain_text_splitters import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=1000,
chunk_overlap=200,
separators=["\n\n", "\n", ".", " ", ""]
)
chunks = splitter.split_text(document)
Термин «Рекурсивный» (Recursive Алгоритм пробует самый большой разделитель (параграф). Если полученный фрагмент всё ещё слишком длинный, применяет следующий разделитель (предложение), затем слово, затем символ. Процесс повторяется рекурсивно.
Термин «Разделитель» (Separator Символ или последовательность символов, по которой можно разделить текст (перевод строки, точка, пробел). Иерархия разделителей: от самых «крупных» к самым «мелким».
Термин «Перекрытие» (Overlap Последние N токенов чанка повторяются в начале следующего чанка. Нужно, чтобы важная информация не потерялась на границе разбиения.
Чанк 1: [токен 1 ... токен 500]
Чанк 2: [токен 401 ... токен 900] # overlap = 100 токенов
| Плюсы | Минусы |
|---|---|
| Сохраняет естественные границы текста | Медленнее Fixed-size |
| Работает для 90% текстов | Требует настройки разделителей под язык |
| Предсказуемый максимальный размер | Может создавать слишком короткие чанки |
Когда применять Дефолтный выбор для большинства текстов (статьи, новости, документация, блоги, письма). Это золотая середина между качеством и простотой.
4. Стратегия 3: Semantic chunking (семантическое разбиение)
Как работает Использует embedding-модель для определения, где заканчивается одна смысловая единица и начинается следующая.
Алгоритм
- Разбить текст на предложения
- Вычислить эмбеддинги каждого предложения
- Измерить косинусное расстояние между соседними предложениями
- Если расстояние резко увеличивается → смысловая граница → разрыв чанка
# Псевдокод
embeddings = model.encode(sentences)
for i in range(len(embeddings)-1):
similarity = cosine_similarity(embeddings[i], embeddings[i+1])
if similarity < threshold: # резкое изменение темы
split_here()
Термин «Косинусное расстояние» (Cosine Distance Мера того, насколько два вектора (эмбеддинга) далеки друг от друга. Значение от 0 (векторы одинаковые) до 2 (противоположные). 1 - cosine_similarity.
Термин «Смысловая целостность» (Semantic Coherence Свойство текста, где все предложения относятся к одной теме. Semantic chunking пытается сохранить эту целостность.
| Плюсы | Минусы |
|---|---|
| Лучшее сохранение смысла | Самый медленный метод |
| Адаптируется под контент | Требует GPU для эмбеддингов |
| Не режет по границам абзацев | Зависит от выбора threshold |
Когда применять Когда важна смысловая целостность — научные статьи (каждый абзац о разном), новости (смена темы), разговоры (смена говорящего), обсуждения на форумах.
5. Стратегия 4: Document-based chunking (по структуре документа)
Как работает Использует естественную структуру документа — заголовки (H1, H2, H3), разделы, подразделы. Каждый раздел становится отдельным чанком.
Для Markdown
# Глава 1 (чанк 1)
Текст главы 1...
## Раздел 1.1 (чанк 2)
Текст раздела 1.1...
# Глава 2 (чанк 3)
Текст главы 2...
Для HTML
<h1>Глава 1</h1>... → чанк 1
<h2>Раздел 1.1</h2>... → чанк 2
Термин «Иерархическая структура» (Hierarchical Structure Документы часто имеют вложенность: книга → главы → параграфы → подпараграфы. Document-based chunking сохраняет эту иерархию.
Термин «Заголовки H1/H2/H3» HTML-теги для заголовков разных уровней. H1 — самый главный заголовок документа, H2 — подзаголовок, H3 — подраздел.
| Плюсы | Минусы |
|---|---|
| Сохраняет логическую структуру | Требует документы с заголовками |
| Чанки имеют чёткие границы | Не работает для простого текста |
| Легко навигировать по источнику | Зависит от качества разметки |
Когда применять Юридические/технические документы с чёткой иерархией — договоры (разделы, пункты, подпункты), техническая документация (главы, разделы), книги, стандарты, законы.
6. Стратегия 5: Sliding window (скользящее окно)
Как работает Чанки перекрываются с большим overlap, создавая «скользящее окно» по документу. Каждый следующий чанк начинается не там, где кончился предыдущий, а на несколько предложений/токенов раньше.
Документ: [A][B][C][D][E][F][G][H][I][J]
Чанк 1: [A][B][C][D][E]
Чанк 2: [D][E][F][G][H]
Чанк 3: [G][H][I][J]
Формула Если chunk_size = 1000 токенов, overlap = 400 токенов, то каждый следующий чанк начинается на 600-м токене предыдущего.
| Плюсы | Минусы |
|---|---|
| Максимальное сохранение контекста | Много дублирования (больше токенов) |
| Не теряет информацию на границах | Дороже (больше эмбеддингов) |
| Идеален для последовательных данных | Может создавать много похожих чанков |
Когда применять Когда контекст на границах критичен и нельзя потерять ни одного связующего звена — чаты (реплики связаны), диалоги агентов, код (функции, которые вызывают друг друга), видео-транскрипции (соседние предложения), временные ряды (данные с датчиков).
7. Сравнение стратегий (сводная таблица)
| Стратегия | Сложность | Скорость | Сохранение смысла | Сохранение структуры | Перекрытие |
|---|---|---|---|---|---|
| Fixed-size | Низкая | Очень высокая | Низкое | Нет | Опционально |
| Recursive | Низкая | Высокая | Среднее | Частичное | Да |
| Semantic | Высокая | Низкая | Высокое | Нет | Нет |
| Document-based | Средняя | Средняя | Высокое | Полное | Нет |
| Sliding window | Средняя | Средняя | Среднее | Нет | Высокое |
8. Как выбрать стратегию (практические рекомендации)
| Тип данных | Рекомендуемая стратегия | Почему |
|---|---|---|
| Логи сервера, JSON, CSV | Fixed-size | Данные однородны, структура не важна |
| Статьи, новости, блоги, письма | RecursiveCharacterTextSplitter | Дефолтный выбор, работает везде |
| Научные статьи, новости со сменой тем | Semantic chunking | Важна смена темы, а не границы абзацев |
| Юридические договоры, тех. документация | Document-based | Есть иерархия (разделы, подразделы) |
| Чаты, диалоги агентов, код | Sliding window | Контекст на границах критичен |
| Смешанные данные | Комбинация | Пробуйте A/B тест |
Термин «A/B тест в chunking» Сравнение двух стратегий chunking на одном датасете запросов. Измеряем recall@k, MRR, faithfulness. Выбираем стратегию с лучшими метриками.
9. Пет-проект для закрепления
Задача Сравнить 4 стратегии chunking на своём датасете документов.
Инструменты Python, LangChain, Qdrant, BAAI/bge-m3
Шаги
- Взять 10 документов разного типа (статья, новость, диалог, код, договор)
- Для каждого документа применить 4 стратегии:
- Fixed-size (chunk_size=500)
- RecursiveCharacterTextSplitter (chunk_size=1000, overlap=200)
- Semantic chunking (через SemanticChunker из LangChain)
- Sliding window (overlap=50%)
- Для каждого подхода: индексировать, задать 10 вопросов
- Замерить метрики retrieval (hit rate, MRR) для каждого
- Написать вывод: какая стратегия лучше для какого типа данных
Ожидаемый результат Таблица с метриками и понимание, что semantic chunking лучше для статей, document-based — для договоров, sliding window — для диалогов, recursive — универсальный компромисс.
Связь с другими вопросами
| Вопрос | Тема |
|---|---|
| 1 | Проектирование RAG (где chunking — ключевой этап) |
| 2 | Lost in the middle (chunking влияет на позицию информации) |
| 5 | Оценка retrieval (как сравнить стратегии) |
| 14 | Обрезка контекста (большие чанки могут не влезть) |
| 19 | Хранение истории диалога (sliding window для чатов) |
| 86 | Retrieval не находит (неудачный chunking — частая причина) |
3 Какие стратегии chunking'а вы знаете и когда какую применяете|3 Какие стратегии chunking'а вы знаете и когда какую применяете|3 Какие стратегии chunking'а вы знаете и когда какую применяете|3 полностью разобран. Переходим к вопросу 4, когда будете готовы|Вопрос 3 полностью разобран. Переходим к вопросу 4, когда будете готовы]]
Навигация
- Предыдущий: 2
- Следующий: 4
- Индекс: 00. Индекс разборов