Чанкование в RAG: размер чанка и перекрытие
Чанкование — нарезка документов на фрагменты перед векторизацией — определяет, найдёт ли RAG-система нужный ответ. Большие чанки размывают смысл вектора, маленькие теряют контекст. Рабочий диапазон зависит от типа текста: 500–700 символов для инструкций, 1000–1500 для лекций, от 1500 для юридических и медицинских документов, с перекрытием около 30 %.
Ниже — почему ошибки нарезки не лечатся ни моделью, ни промптом, как выбрать размер под свои документы и какие способы нарезки существуют.
Что такое чанк
Чанк — единица поиска в RAG: фрагмент текста, который целиком превращается в один вектор-эмбеддинг и хранится в векторной базе. На этапе поиска смысла в человеческом понимании нет — есть только математическое сравнение вектора вопроса с векторами чанков. Поэтому чанк прежде всего единица сравнения, и его параметры подбираются под то, как строится эмбеддинг и как выполняется выборка: сколько фрагментов берётся, есть ли фильтры и переранжирование.
Общая схема RAG, в которой этот этап стоит первым, разобрана в материале о том, как работает RAG для базы знаний компании.
Почему нарезка важнее выбора модели
На практике большинство проблем с качеством RAG — не в языковой модели и не в параметрах эмбеддингов, а в нарезке. Логика простая: если нужный фрагмент не попал в выборку, модель его не увидит. Переформулировка запроса и промпт-инжиниринг помогают найти существующее, но не создают того, что было разрезано пополам.
Для корпоративной базы знаний это особенно чувствительно. Пункт регламента, разорванный между двумя чанками, не находится ни по одному из них — и сотрудник получает ответ по соседнему, похожему, но другому пункту.
Большие и маленькие чанки: в чём конфликт
Модель эмбеддингов сжимает любой текст в вектор фиксированной длины. Отсюда конфликт.
| Размер | Что происходит с вектором | Чем плохо |
|---|---|---|
| Слишком большой | В одном векторе смешано несколько тем, он «усреднён» | Плохо совпадает с конкретным вопросом, поиск промахивается |
| Слишком маленький | Вектор точный, но узкий | Мысль разбита на части, модель получает обрывок и отвечает неполно |
| Подобранный | Один чанк ≈ одна законченная мысль | Высокая вероятность попасть в выборку целиком |
Интуитивная ошибка — делать чанки крупнее по принципу «больше информации — лучше». Для поиска это обычно хуже.
Четыре настройки нарезки
1. Размер под смысловую плотность текста. Универсального значения нет, в том числе популярных «512 токенов».
| Тип документов | Рекомендуемый размер | Почему |
|---|---|---|
| Технические инструкции, регламенты | 500–700 символов | Смысл плотный, вопросы конкретные |
| Лекции, учебные курсы | 1000–1500 символов | Мысль разворачивается на несколько предложений |
| Юридические и медицинские документы | от 1500 символов, с учётом структуры | Смысл распределён по иерархии разделов |
2. Перекрытие. В каждый следующий чанк добавляется около 30 % текста предыдущего. Это страховка: мысль, попавшая на границу разреза, целиком окажется хотя бы в одном из соседних фрагментов.
3. Резать по логическим границам. Рекурсивные сплиттеры сначала пробуют разрезать по заголовкам и абзацам, затем по переносам строк, затем по точкам. Чанк должен быть как можно ближе к законченной мысли, а не обрываться посреди предложения.
4. Семантическая нарезка для критичных задач. Вместо подсчёта символов считается косинусное расстояние между соседними предложениями. Резкий скачок означает смену темы — там и ставится разрез.
Как эти настройки выглядят на реальном корпусе — 1667 чанков по 1600 символов с перекрытием 250 — показано в разборе пайплайна RAG-сервиса из видеолекций.
Другие подходы к нарезке
Ручная разметка экспертами. Специалисты сами выделяют смысловые блоки. Точно, но долго, дорого и не масштабируется.
Нарезка через LLM. Большой фрагмент подаётся языковой модели с просьбой разбить его на смысловые части, не меняя текст. Дорого и нестабильно от запуска к запуску.
Улучшение поиска поверх простой нарезки. Переранжирование, расширение запроса, многошаговый поиск. Помогает, но не заменяет корректные границы чанков.
Чеклист нарезки базы знаний
- Разделить документы по типам: инструкции, учебные материалы, нормативка.
- Для каждого типа задать свой размер чанка, а не один на всю базу.
- Включить перекрытие около 30 % размера чанка.
- Резать по заголовкам, абзацам и концам предложений.
- Сохранять у чанка ссылку на документ и раздел — для ответа со ссылкой на источник.
- Прогнать контрольные вопросы и проверить, что правильный фрагмент попадает в выборку.
- Для самых важных документов проверить семантическую нарезку.
- После смены правил нарезки пересчитать эмбеддинги всей базы.
Частые ошибки
Один размер на всю базу. Регламенты и записи лекций требуют разной нарезки; компромисс ухудшает поиск по обоим.
Нарезка без перекрытия. Любой ответ, попавший на границу, теряется.
Резать по счётчику символов посреди предложения. Вектор обрывка плохо похож на любой вопрос.
Лечить промахи поиска промптом. Если фрагмента нет в выборке, инструкция модели ничего не изменит.
Терять источник чанка. Без ссылки на документ ответ нельзя проверить, а сотрудники перестают ему доверять.
Что делать дальше
Возьмите пять вопросов, на которые ваш ассистент отвечает неправильно, и посмотрите не на ответ, а на найденные фрагменты. Если нужного текста среди них нет — проблема в нарезке, и начинать стоит с размера и перекрытия. Если текст есть, но ответ всё равно плохой — тогда уже дело в инструкции модели. Эта проверка занимает час и экономит недели выбора «более умной» модели в рамках MLOps-процесса.