RAPTOR
RAPTOR меняет саму структуру retrieval-корпуса. Вместо набора независимых chunks система строит дерево: нижний уровень хранит исходные фрагменты, а верхние уровни содержат их рекурсивные summaries. Благодаря этому retrieval может срабатывать не только по локальным кускам текста, но и по более общим представлениям длинного документа.
В 2026 это особенно полезно для длинных документов, policy packs, технических wiki и больших отчётов. Обычный chunk-based RAG там часто промахивается: локальный фрагмент найден, а общий смысл раздела нет.
Чем RAPTOR отличается от обычного chunking
В plain RAG документ обычно режется на одинаковые chunks, и retrieval ищет только среди них. Это работает для локальных фактов, но плохо отвечает на глобальные вопросы.
RAPTOR строит более богатый индекс:
- leaf nodes с исходными chunks;
- intermediate summaries;
- верхнеуровневые summaries для групп разделов.
Поэтому система может сначала найти правильную область смысла, а потом уточнить детали ниже по дереву.
Когда техника особенно полезна
RAPTOR хорошо подходит для:
- длинных PDF и technical reports;
- regulatory и compliance документации;
- due diligence corpora;
- больших knowledge bases;
- question answering, где нужны и overview, и evidence.
Если corpus состоит из коротких независимых заметок, выгода будет меньше.
Ограничения
RAPTOR требует preprocessing и более дорогого индекса:
- нужно строить summaries;
- нужно обновлять дерево при изменении корпуса;
- есть риск summary drift, если абстракции неточно отражают низовые chunks.
То есть техника особенно оправдана на тяжёлых knowledge corpora, а не в маленьких FAQ.
Почему техника актуальна в 2026
Контекстные окна растут, но проблема не исчезает: найти правильный кусок длинного документа всё ещё трудно. RAPTOR важен тем, что делает retrieval структурным, а не просто более длинным.
Это полезно там, где пользователи задают и локальные, и глобальные вопросы к одному и тому же корпусу.