Зачем разбираться в теме

Chunking для RAG: как выбрать размер чанка, overlap и границы — это не отдельный трюк, а часть production-архитектуры LLM-приложения. Ниже — практический способ внедрить подход так, чтобы качество можно было измерить, а изменения безопасно откатить.

Почему chunking решает половину качества RAG

Retriever ищет не документ целиком, а фрагменты. Если chunk слишком большой, вектор смешивает несколько тем; если слишком маленький, нужный факт теряет контекст. Поэтому размер чанка — это параметр retrieval, а не косметическая настройка ingestion.

Начинайте со структуры документа

Заголовки, абзацы, списки, таблицы и блоки кода дают естественные границы. Сначала режьте по структуре, затем применяйте ограничение по токенам; слепое деление каждые N символов чаще создаёт обрезанные мысли.

Overlap нужен не везде

Overlap полезен, когда важная мысль пересекает границу, но большой overlap раздувает индекс и создаёт дубликаты результатов. Проверяйте, даёт ли он прирост Recall@K, а не просто больше похожих chunks.

Размер должен зависеть от контента

FAQ, юридический документ, API reference и длинная статья требуют разных профилей. Для кода и таблиц полезно сохранять логические блоки, а для prose — смысловые абзацы и секции.

Измеряйте retrieval, а не интуицию

Соберите набор реальных вопросов и supporting chunks. Сравнивайте Recall@K, MRR, число дубликатов, размер финального context и downstream answer correctness для нескольких стратегий chunking.

Версионируйте ingestion

Храните chunker version, document version и source offsets. Тогда можно переиндексировать корпус, сравнить две стратегии и откатить неудачную схему без потери происхождения данных.

Production checklist

  • Зафиксируйте исходный baseline и dataset.

  • Версионируйте конфигурацию и данные.

  • Логируйте ключевые входы, решения и ошибки.

  • Измеряйте качество вместе с latency и cost.

  • Не передавайте модели права, которые можно проверить детерминированно.

  • Запускайте изменения через feature flag или контролируемый cutover.

  • Держите rollback path до завершения наблюдаемого периода.

Вывод

Хорошая реализация отличается не количеством компонентов, а управляемостью: понятный контракт, измеримые метрики, безопасные границы и возможность воспроизвести результат. Начинайте с простого baseline и усложняйте систему только там, где evals показывают реальный выигрыш.