Разбиение на фрагменты преобразует нормализованное исходное содержимое страниц в единицы поиска. Неудачный выбор раздувает стоимость (слишком много фрагментов), ухудшает recall (слишком крупные блоки) или размывает точность (разрывы на границах). Универсально лучшего метода не существует; стратегия согласуется со структурой корпуса, его изменчивостью и шаблонами запросов. Это руководство охватывает пространство проектирования, компромиссы, рабочий процесс оценки и рычаги оптимизации для продакшн-конвейеров RAG.
Почему разбиение важно
Цели:
- Максимизировать вероятность того, что релевантные факты попадут в top‑k результаты поиска.
- Сохранять семантическую связность, чтобы сгенерированные ответы были обоснованы.
- Оптимизировать использование токенов (избегать повторного встраивания шаблонного текста).
- Обеспечить детерминированные инкрементальные обновления (стабильные ID фрагментов).
Несогласованное разбиение проявляется как: высокая избыточность, низкий Recall@k, галлюцинированные граничные факты, раздутые расходы на embedding.
Разбиение с фиксированным окном
Простые окна из N токенов (например, 500 токенов). Плюсы: детерминированность, простота реализации, стабильное поведение при обновлении. Минусы: границы рассекают понятия; для уменьшения усечения требуется избыточное перекрытие → рост стоимости. Использовать умеренно: хороший базовый уровень для разнородного или плохо структурированного контента, где семантические сигналы ненадёжны.
Перекрывающиеся скользящие окна
Размер окна W с перекрытием O (например, 500 / 50 токенов) уменьшает усечение фактов на границах. Перекрытие свыше ~15 % даёт убывающий прирост recall, при этом наращивая размер индекса. Отслеживайте duplication_ratio = distinct_token_count / total_token_count, чтобы снижать O.
Обнаружение семантических границ
Сегментируйте по структурным сигналам: заголовки H2/H3, группировки списков, блоки кода, границы таблиц. Применяйте минимальные/максимальные пределы токенов (объединяйте слишком мелких соседей, разбивайте слишком крупные разделы). Преимущества: выше связность, меньше перекрытий. Риски: некорректная разметка, несогласованная иерархия заголовков. Снижайте их восстановлением иерархии + переходом на разбиение по абзацам при отсутствии заголовков.
Иерархическое разбиение
Двухуровневый индекс: грубые embedding разделов (например, целый раздел руководства) + детализированные подфрагменты. Поток поиска: грубый ANN → отбор top‑N разделов → точный поиск внутри них. Преимущества: уменьшает глобальное пространство поиска для больших корпусов, улучшает задержку. Сложность: больше движущихся частей, нужна логика каскадного скоринга.
Адаптивное / динамическое разбиение
Подстраивайте размеры фрагментов под локальную семантическую плотность и структурные подсказки. Пример логики: начните с раздела-заголовка, если >800 токенов → разбейте по кластерам абзацев, оценённым по семантическому сходству; если <120 токенов → объедините со следующим соседом, если расхождение тем не превышает порог. Требуется предварительный проход по embedding или сходству; заплатите цену один раз при загрузке ради лучшей долгосрочной эффективности поиска.
Соображения по embedding
Сохраняйте метаданные: token_count, model_version, content_hash. Избегайте усечения — предварительно вычисляйте токены и разбивайте до вызова модели. Плотные модели деградируют при избытке шаблонного текста; удаляйте навигационные артефакты перед разбиением. Отслеживайте vector_density (уникальные термины / токены), чтобы выявлять малоинформативные фрагменты (кандидаты на повторное объединение).
Методы оценки
Бенчмарки по каждой стратегии:
| Метрика | Назначение |
|---|---|
| Recall@k | Сохранение фактов |
| Precision@k | Шум контекста |
| Количество фрагментов | Индикатор стоимости |
| Коэффициент дублирования | Настройка перекрытия |
| Среднее число токенов на фрагмент | Использование окна |
| Задержка (поиск) | Эффективность индекса |
Запускайте на эталонном наборе запросов; принимайте стратегию только если прирост recall превышает дельты стоимости и задержки.
Практическое руководство по внедрению
- Базовый уровень: фиксированные 500 + 10 % перекрытия; соберите бенчмарки.
- Введите семантические границы: замените окна там, где заголовки надёжны; повторно измерьте.
- Добавьте иерархический слой, если корпус >250k фрагментов или задержка превышает цель.
- Разверните адаптивную логику для разделов с высокой дисперсией размеров.
- Ежеквартальная переоценка: сравните стоимость на единицу прироста качества с возможностями новых моделей.
Сохраняйте diff манифеста фрагментов на каждой итерации для отката.
Ключевые выводы
- Семантические границы обычно превосходят чисто фиксированные окна по точности/стоимости.
- Перекрытие — это регулятор: измеряйте дублирование, не гадайте.
- Иерархический поиск помогает масштабироваться без линейного роста задержки.
- Стабильные ID фрагментов обеспечивают безопасное инкрементальное обновление embedding.
- Оценивайте изменения стратегии как деплои кода: бенчмарк, сравнение, журналирование.