Глава 3 — Продвинутые фреймворки чанкинга
Третий пост поглавного разбора LLM Primer III: Enhancing Enterprise AI with RAG. Там, где наивные решения тише всего деградируют всё, что следует — и где два недавних приёма изменили возможное на фронтире.
Почему существует эта глава
Как только документы распарсены, следующее решение оказывается и самым важным: как разбить их на куски, достаточно маленькие для эмбеддинга и достаточно большие, чтобы по-прежнему что-то значить сами по себе. Это чанкинг. Чанк, отделивший определение от его уточнения, будет уверенно найден и окажется неверным. Чанк, склеивший пять не связанных тем, размывает каждый эмбеддинг, к которому прикасается. Любая поисковая система над этим способна вернуть только то, что сохранил этап чанкинга, а режимы отказа здесь тихие — ретривер всё ещё возвращает кандидатов, модель всё ещё выдаёт беглые ответы, и только пользователь замечает, что ответы тонко неверны.
3.1 Спектр чанкинга
Полезно упорядочить стратегии по тому, сколько они знают о документе. На одном краю фиксированный по размеру чанкинг не знает ничего — посчитал токены, разрезал. Быстро, детерминированно и приемлемо для стилистически однородного короткого текста (чат-логи, FAQ-записи, отзывы клиентов). На структурированных технических документах это тихая катастрофа. Рекурсивный чанкинг применяет приоритетный список разделителей — абзацы, потом переводы строк, потом предложения, потом слова — разрезая по самой высокоприоритетной границе, помещающейся под целевой размер. Почти так же дёшев, как фиксированный, и существенно лучше. Это правильный дефолт для большинства команд.
Семантический чанкинг переносит решение из синтаксиса в смысл: эмбеддит каждое предложение, идёт по последовательности, помечает границу темы там, где сходство соседних предложений падает ниже порога. Хорош на длинной прозе со слабыми структурными подсказками (аналитические отчёты, расшифровки интервью) и плох на структурированных технических документах, где плотные перекрёстные ссылки и повторяющаяся шаблонщина путают эмбеддинги предложений. Чанкинг с учётом структуры рассматривает распарсенный документ как дерево и режет вдоль него — по секциям, по уровню заголовков, по функциям кода. Сделанный хорошо, это самая верная форма чанкинга; сделанный без парсера с учётом макета выше по потоку, он не отличается от рекурсивного, потому что структура никогда не была извлечена. Эти четыре — альтернативы, а не стек для совместного развёртывания.
3.2 Миф об overlap и обрыв контекста
Почти каждый туториал рекомендует overlap чанков 15–20%. Интуиция верна в пределах — overlap снижает потери на границах — но кривая быстро уплощается. Первые 10% дают большую часть выгоды. После примерно 25% точность фактически плоская, а стоимость растёт по трём осям: счёт за эмбеддинги линейно растёт с числом чанков, размер индекса и латентность запроса увеличиваются, а топ результатов ретривера начинает быть почти-дубликатами друг друга. Запрос матчится с пассажем в чанках A, B и C; окно контекста съедено без поступления новой информации; reranker тратит бюджет на переупорядочивание вариантов одного и того же. Команда, тянущаяся к overlap 30–40%, должна воспринять это как сигнал о неверном чанкере, а не как сигнал о недостаточном overlap.
Связанный, но иной — обрыв контекста: резкое падение качества поиска, когда чанк теряет якорные термины, делавшие его находимым. Абзац открывается «Поправка 2023 года к Политике 47-Б требовала от всех филиалов…» и далее описывает требование в следующих предложениях. Разрежьте после открытия — и описывающий требование чанк больше не упоминает ни политику, ни поправку, ни год. Он уверенно найдётся под не относящиеся запросы и пропустит канонические. Поиск — это top-k: либо чанк всплывает, либо нет, без плавной деградации. Обрыв — доминирующий режим отказа в технических корпусах, где местоимения и сокращения протаскивают антецедент через секцию.
3.3 Соответствие размера чанка типу запроса
Размер чанка часто обсуждают так, будто у него один правильный ответ. Его нет, потому что правильный ответ зависит от того, какие запросы получит система. Факт-вопрос — «какая была франшиза по полису 47-Б в 2024 году?» — хочет 150–300 токенов, достаточно узких для точности и достаточно широких для дизамбигуации. Рассуждательный запрос — «суммируйте изменения между версиями 2023 и 2024 и объясните их влияние на продление» — хочет 800–1200 токенов, чтобы сохранить соединительную ткань внутри секции. Оптимальный размер отличается в 4–8 раз, а трафик в продакшене обычно смешан.
Два продуктивных ответа. Мульти-гранулярная индексация хранит один корпус в нескольких размерах чанков и маршрутизирует запросы по классификации намерения. Иерархический поиск индексирует мелкие чанки ради точности, но возвращает их родительские секции ради контекста — один индекс, обусловленный во время запроса, чаще встречается в продакшене, потому что плавно деградирует, когда классификация намерения ошибается. Паттерн «родительский документ» — один из самых ценных приёмов в продакшен-литературе поиска.
3.4 Contextual retrieval и late chunking
Фронтир — это признание, что чанк и эмбеддинг — отделимые сущности. Два недавних приёма эксплуатируют это разделение с противоположных сторон. Contextual retrieval, популяризованный Anthropic в 2024 году, отправляет каждый чанк вместе с полным документом дешёвой LLM и просит дать одно-два предложения, где этот чанк находится — «этот чанк обсуждает изменение расчёта франшизы, введённое поправкой 2024 года к Политике 47-Б» — и затем подставляет это перед текстом чанка перед эмбеддингом. Чанк становится находимым по запросам, которых исходный текст не называл. Заявленные выигрыши — около 49% снижения неудач поиска на оценке Anthropic, больше с гибридным поиском и rerank поверх. Трюк, делающий это экономичным, — кеш промптов: отправьте документ один раз, обрабатывайте каждый чанк против кешированной версии.
Late chunking, представленный Jina AI в 2024 году, атакует ту же проблему с другой стороны. Полный документ пропускается через long-context эмбеддер за один проход, давая токенные эмбеддинги, уже контекстуализированные по всему документу. Только потом документ режется на чанки, и эмбеддинг каждого чанка собирается пулингом из его уже контекстуализированных токенов. Никаких дополнительных вызовов LLM; эмбеддинги наследуют контекст уровня документа неявно. Ограничение — эмбеддер должен это нативно поддерживать (jina-embeddings-v3/v4 и некоторые исследовательские модели — да), и документ должен помещаться в окно модели. Для документов, которые помещаются, late chunking сравним по качеству с contextual retrieval за долю стоимости индексации. Для тех, что не помещаются, contextual retrieval универсальнее. Эти два не взаимоисключающи, и серьёзные продакшен-системы часто гоняют оба с дедупликацией поверх.
Что подготавливает глава 3
Чанкинг превращает распарсенный документ в популяцию находимых единиц. Каждой единице нужно где-то жить — храниться, индексироваться, опрашиваться с низкой латентностью, обновляться по мере изменения корпуса. Это «где-то» — векторная база данных, и выбор векторной базы — это решение иного рода, чем выбор чанкинга. Чанкинг — программная задача с программными затратами. Выбор базы — программная задача с инфраструктурными, операционными и регуляторными последствиями, и неверный выбор может потребовать полгода на отмену.
Дальше — Глава 4: Выбор подходящей векторной базы данных. Специализированные системы против расширений, лидеры managed-сегмента, open-source поле и три оси — резидентность, операционные расходы, общая стоимость — на которых обычно решается реальный выбор.
