Чанкинг RAG: почему ваш размер чанков убивает качество и как его исправить

Вы настраиваете RAG и упускаете главное

Представьте: вы потратили недели на сборку RAG системы. Подключили мощные эмбеддинги, настроили ретривер, выбрали самую крутую LLM. А ответы все равно получаются неточными. Контекст не релевантный. Или слишком общий. Или фрагментированный.

Вы начинаете копать глубже. Меняете модели эмбеддингов. Добавляете гибридный поиск. Оптимизируете промпты. Но проблема остается.

А что если я скажу вам, что в 80% случаев виноват не поисковый алгоритм, не модель эмбеддингов, и даже не сама LLM? Виновник скрывается на самом первом этапе - чанкинге документа.

Почему размер имеет значение (и это не шутка про что вы подумали)

Чанкинг - это искусство баланса. Слишком мелкие чанки теряют контекст. Слишком крупные - содержат шум. И то, и другое убивает качество ретривера.

Давайте представим техническую документацию API. Один метод описан на 300 токенов. Вы делите на чанки по 100 токенов. Первый чанк - сигнатура метода. Второй - параметры. Третий - пример использования. Пользователь спрашивает: "Как передать параметр X в метод Y?"

Система ищет по эмбеддингам. Находит первый чанк (сигнатура). Отправляет в LLM. LLM не видит параметров и примеров. Галлюцинирует ответ. Пользователь злится.

Эксперимент: что происходит на разных размерах

Я взял набор из 100 технических документов (документация Python, API спецификации, научные статьи) и провел серию экспериментов. Цель - понять, как размер чанков влияет на точность извлечения.

1Настройка тестового стенда

Для чистоты эксперимента использовал:

• Эмбеддинги: text-embedding-ada-002 (OpenAI)
• Векторная БД: FAISS
• Метрики: Precision@K, Recall@K, MRR (Mean Reciprocal Rank)
• Чанкинг: простой по символам с overlap

Тестовые запросы: 50 вопросов разной сложности - от простых фактовых ("Какие параметры у функции open()?") до сложных аналитических ("Как сравнить производительность этих двух подходов?").

# Код эксперимента
import tiktoken
from langchain.text_splitter import RecursiveCharacterTextSplitter

# Разные стратегии чанкинга
def chunk_document(text, chunk_size, chunk_overlap):
    # Простой сплиттер по символам (для чистоты эксперимента)
    splitter = RecursiveCharacterTextSplitter(
        chunk_size=chunk_size,
        chunk_overlap=chunk_overlap,
        length_function=len,
        separators=["\n\n", "\n", ".", "!", "?", ",", " ", ""]
    )
    return splitter.split_text(text)

# Тестовые размеры чанков
chunk_sizes = [64, 128, 256, 512, 1024, 2048]  # токены
chunk_overlaps = [0, 32, 64, 128]  # токены

2Результаты: график качества

После недели вычислений (и сожженных долларов на OpenAI API) получил вот такие цифры:

Видите эту кривую? Она похожа на горб верблюда. Есть золотая середина - где-то между 256 и 1024 токенами. Но это усредненные цифры. Реальность сложнее.

Три типа контента - три разных размера

Вот где большинство падает в ловушку. Они берут один размер чанков для всего. Это как использовать один размер обуви для всей семьи.

Техническая документация (256-512 токенов)

API методы, функции, классы. Здесь важна точность. Чанк должен содержать полное описание одного метода или функции.

# Пример плохого чанкинга для техдока
# Размер чанка: 1000 токенов (слишком много)
# Результат: в одном чанке оказываются три разных метода
# LLM путается, какой метод нужен

# Пример хорошего чанкинга
chunk_size = 384  # токенов
chunk_overlap = 64  # токенов
# Почему 384? Средняя длина описания метода в Python ~300 токенов
# + overlap для контекста между связанными методами

Научные статьи (512-1024 токенов)

Здесь нужен контекст. Абзац без предыдущего абзаца теряет смысл. Но весь раздел статьи - это перебор.

Совет: чанкуйте по разделам (Введение, Методы, Результаты). Если раздел слишком длинный - делите на подразделы.

Диалоги, чаты (128-256 токенов)

Здесь каждая реплика - отдельная единица смысла. Но нужно сохранять контекст диалога. Решение - чанковать по сообщениям, но добавлять 2-3 предыдущих сообщения для контекста.

Overlap: секретное оружие, которое все игнорируют

Overlap (перекрытие) - это когда чанки перекрываются. Казалось бы, зачем хранить один и тот же текст дважды? А вот зачем:

1. Контекстные границы редко совпадают с границами чанков
2. Запрос может относиться к информации на стыке чанков
3. LLM лучше понимает текст, когда у нее есть "разбег"

В моих экспериментах overlap в 10-20% от размера чанка давал прирост качества на 15-25%. Это бесплатный бонус, который почти никто не использует.

# Как НЕ делать overlap
chunk_size = 512
overlap = 10  # символов? токенов? неясно

# Как делать правильно
chunk_size = 512  # токенов
overlap = 64  # токенов (12.5%)
# или
overlap = 96  # токенов (18.75%)

# Почему в токенах, а не символах?
# Потому что модели эмбеддингов и LLM работают с токенами
# Символьный overlap может разрезать токен пополам
# Получится мусор в эмбеддингах

Семантический чанкинг: следующий уровень

Простого разбиения по символам или токенам уже недостаточно. Умные системы используют семантический чанкинг - разбивают документ по смыслу, а не по длине.

Представьте: у вас есть длинный технический документ. В нем есть разделы, подразделы, списки, код. Простой сплиттер разрежет код пополам. Разрежет таблицу. Разрушит структуру.

# Пример семантического чанкинга с библиотекой
from semantic_text_splitter import TextSplitter
from tokenizers import Tokenizer

# Загружаем токенаizer (тот же, что у модели эмбеддингов)
tokenizer = Tokenizer.from_pretrained("bert-base-uncased")

splitter = TextSplitter.from_huggingface_tokenizer(
    tokenizer,
    chunk_capacity=512,  # максимальный размер чанка
    chunk_overlap=64     # overlap
)

# splitter сам определит логические границы
chunks = splitter.chunks(your_text)

Практическое руководство: настраиваем чанкинг за 5 шагов

1Анализируйте ваш контент

Прежде чем что-то настраивать, посмотрите на ваши документы. Откройте несколько файлов. Посчитайте:

• Среднюю длину абзаца (в токенах)
• Среднюю длину раздела
• Есть ли код, таблицы, списки?
• Какой тип вопросов будут задавать пользователи?

2Начните с 512 токенов

512 токенов - это безопасная середина. Не идеально для всего, но работает в большинстве случаев. Используйте это как baseline.

3Добавьте overlap 10-20%

Не экономьте на overlap. 64-128 токенов перекрытия стоят дополнительного места в базе, но окупаются качеством.

4Создайте тестовый набор

Возьмите 20-30 реальных вопросов от пользователей (или придумайте сами). Для каждого вопроса определите правильный ответ в документах.

Тестируйте разные размеры чанков на этом наборе. Измеряйте:

• Находит ли система правильный чанк?
• На каком месте в результатах поиска он находится?
• Достаточно ли контекста в чанке для ответа?

5Оптимизируйте под конкретные задачи

Если ваша система специализируется на чем-то одном (например, только поиск по API документации), кастомизируйте размер чанков под этот контент. Если у вас смешанный контент - подумайте о мульти-стратегии чанкинга.

Частые ошибки (и как их избежать)

Что делать, если контекст все равно теряется?

Даже с идеальным чанкингом иногда информация "теряется" в середине длинного контекста. Это известная проблема "Lost in the Middle".

Решение: не сваливайте все релевантные чанки в один промпт. Используйте стратегию переранжирования или суммаризации чанков перед отправкой в LLM.

# Стратегия: суммаризация чанков перед LLM
def summarize_chunks_for_llm(retrieved_chunks, max_tokens=3000):
    """
    Вместо того чтобы отправлять все чанки в LLM,
    суммаризируем их в более компактную форму
    """
    if total_tokens(retrieved_chunks) <= max_tokens:
        return retrieved_chunks  # все ок, отправляем как есть
    
    # Слишком много контекста
    # Стратегия 1: суммаризация каждого чанка
    summarized = []
    for chunk in retrieved_chunks:
        # Используем быструю модель для суммаризации
        summary = fast_summarizer(chunk, max_length=100)
        summarized.append(summary)
    
    # Стратегия 2: выбираем только самые релевантные
    # на основе score от ретривера
    sorted_by_score = sorted(retrieved_chunks, key=lambda x: x.score, reverse=True)
    return sorted_by_score[:5]  # топ-5 самых релевантных

Чеклист для production системы

• [ ] Размер чанков измеряете в токенах, а не символах
• [ ] Overlap установлен на 10-20% от размера чанка
• [ ] Для разных типов контента разные стратегии чанкинга
• [ ] Тестовый набор вопросов для валидации качества
• [ ] Семантический чанкинг для структурированных документов
• [ ] Мониторинг качества retrieval (не только финального ответа)
• [ ] План A/B тестирования разных стратегий чанкинга

И последнее: размер чанков зависит от модели

Разные модели эмбеддингов имеют разные оптимальные размеры контекста. То, что работает для text-embedding-ada-002, может не работать для какой-нибудь локальной модели.

Проверяйте документацию модели эмбеддингов. Некоторые модели теряют качество на слишком длинных текстах. Другие - на слишком коротких.

И помните: идеального размера не существует. Есть оптимальный для вашей конкретной задачи, вашего контента, вашей модели. Найти его можно только экспериментально.

Но теперь вы знаете, как искать.