Иерархический RAG провалился: почему RAPTOR набрал всего 0.094 nDCG и что делать вместо него

Идея, которая казалась гениальной

Представьте документ на 100 страниц. Обычный RAG разбивает его на 200 чанков, индексирует, при запросе находит 5-10 самых релевантных. Но что если ответ размазан по всему документу? Иерархический RAG предлагает решение: строим дерево суммаризаций. Листья — исходные чанки. Над ними — суммаризации групп чанков. Над ними — суммаризации суммаризаций. Получаем пирамиду. При запросе идем сверху вниз: сначала читаем корневую суммаризацию, выбираем подходящую ветку, спускаемся, находим точные фрагменты. Логично? Теоретически — да. Практически — полный провал.

Цифры, которые заставят вас выбросить RAPTOR

В 2025 году вышла работа по RAPTOR (Recursive Abstractive Processing for Tree-Organized Retrieval). Авторы сравнивали его с baseline на датасете QASPER. Метрика — nDCG@10 (нормализованный дисконтированный кумулятивный выигрыш). Чем ближе к 1, тем лучше. Результаты:

Почему дерево суммаризаций убивает точность

Проблема не в идее, а в ее реализации через современные LLM. Вот что ломается на каждом уровне:

1. Кумулятивные ошибки маршрутизации

Каждый уровень дерева — это решение LLM: "В какую ветку спускаться?". Предположим, точность выбора на одном уровне — 85%. Кажется, неплохо? Посчитаем для дерева глубиной 4:

# Кумулятивная ошибка маршрутизации
error_per_level = 0.15  # 15% ошибок на каждом уровне
total_accuracy = (1 - error_per_level) ** 4
print(f"Общая точность после 4 уровней: {total_accuracy:.2%}")
# Вывод: Общая точность после 4 уровней: 52.20%

Половина запросов уходит не туда с самого начала. И это в лучшем случае — с моделью, которая правильно понимает контекст. В реальности ошибок больше.

2. Потеря специфичности в суммаризациях

LLM при суммаризации теряет детали. Особенно цифры, имена, технические термины. Что получается? Верхние уровни дерева содержат общие фразы вроде "документ описывает методы оптимизации". А где именно упоминается алгоритм Хищника-Жертвы? Неизвестно. При запросе про конкретный алгоритм система не может найти нужную ветку — в суммаризациях этого нет.

3. Нелинейная стоимость ошибок

В плоском RAG ошибка ретривева — вы получили не самый релевантный чанк, но LLM еще может что-то из него выжать. В иерархическом RAG ошибка на верхнем уровне означает: вы спустились не в ту ветку. Все чанки в этой ветке нерелевантны. Система не вернется и не проверит другие ветки (если не реализован backtracking, что удваивает latency).

Что мы пробовали и что не сработало

Мы потратили три месяца на эксперименты с RAPTOR-подобными системами. Вот список решений, которые должны были помочь, но не помогли:

• Гибридный поиск на каждом уровне — комбинируем семантический и ключевой поиск при выборе ветки. Результат: +0.03 к nDCG, но latency x3.
• Мультимодальные эмбеддинги — используем текстовые и табличные эмбеддинги для научных статей. Не помогает, потому что проблема в структуре дерева, а не в качестве эмбеддингов.
• Динамическая глубина обхода — решаем, насколько глубоко спускаться для каждого запроса. На практике LLM плохо определяет "достаточную глубину".
• Ансамбли деревьев — строим несколько деревьев с разными стратегиями кластеризации. Точность растет до 0.21 nDCG, но стоимость вычислений становится астрономической.
• Fine-tuning моделей для суммаризации — обучаем специализированную модель на сохранении ключевых терминов. Помогает, но требует огромного датасета и все равно не решает проблему маршрутизации.

Что работает в 2026 году вместо иерархического RAG

Забудьте про RAPTOR. Вот что действительно дает результат:

1. Графовые RAG с обратным обходом

Вместо дерева — граф связей между чанками. Каждый чанк связан с другими по тематике, ссылкам, цитатам. При запросе идем не сверху вниз, а от наиболее релевантного чанка расширяемся по графу. Это спасает от катастрофического забывания контекста. Подробнее в статье про Dreaming Engine и обратный обход графа.

2. Агентный RAG с многоэтапным reasoning

Не пытайтесь засунуть всю логику в одну архитектуру. Разделите: один агент ищет, другой анализирует, третий проверяет консистентность. Каждый агент использует подходящий ему инструмент. В 2025 году такой подход показал рост точности на 40% по сравнению с монолитными системами. Полное руководство по локальной сборке есть в статье про Agentic RAG.

3. Гибридный поиск с адаптивным взвешиванием

Простое, но эффективное: векторный поиск + полнотекстовый + метаданные. Ключ — динамическое взвешивание. Для технических запросов увеличиваем вес ключевых слов, для концептуальных — семантики. Современные библиотеки вроде Weaviate или Qdrant делают это из коробки.

4. Рерайтинг запросов и чанков

Вместо сложной архитектуры — улучшаем то, что есть. Переписываем запрос пользователя в 3-5 вариантах, ищем по всем, объединяем результаты. Переписываем чанки перед индексацией, добавляя контекст. Дешево и сердито. Подход подробно разобран в roadmap по RAG на 2026 год.

Когда иерархический подход МОЖЕТ работать

Есть два узких сценария, где дерево не полностью бесполезно:

1. Очень большие документы с четкой структурой — например, многостраничные юридические контракты с разделами и подразделами. Но даже здесь граф работает лучше.
2. Интерактивное исследование документов — когда пользователь хочет "побродить" по документу, а не найти конкретный ответ. Дерево дает хороший overview.

Но для production RAG, где нужны точные ответы на конкретные вопросы — забудьте. Не тратьте время.

Практический чеклист: что делать, если вас тянет на RAPTOR

Чувствуете соблазн попробовать иерархический подход? Пройдите этот чеклист:

Что будет дальше с иерархическими подходами

Идея не умерла полностью. В исследованиях на 2026 год появляются гибриды: графы с иерархическими метаузлами, деревья с перекрестными связями, динамические иерархии, которые строятся под запрос. Но это уже не классический RAPTOR.

Главный урок: не усложняйте архитектуру ради красоты концепции. Начинайте с простого гибридного поиска, добавляйте агентов только когда уперлись в потолок, используйте графы вместо деревьев. И помните цифру: 0.094 nDCG. Столько стоит красивая теория без практической проверки.

P.S. Если все же решитесь на RAPTOR — сразу закладывайте в бюджет на 30% больше времени на отладку маршрутизации. И держите под рукой fallback в виде обычного векторного поиска. Проверено.