PageIndex da VectifyAI oferece busca sem embeddings para documentos longos

PageIndex — один из самых заметных новых претендентов на роль «RAG без векторной базы». Вместо привычной схемы с эмбеддингами и чанками система строит для документа иерархическое оглавление с краткими описаниями разделов, а затем просит LLM логически выбрать релевантные узлы и связанные с ними страницы. Подход выглядит свежо и для длинных, хорошо структурированных PDF действительно может работать ближе к тому, как документ читает человек.

Механика у PageIndex сравнительно простая. Документ сначала делят по страницам, после чего модель и вспомогательный код собирают расширенный TOC — дерево разделов с заголовками, диапазонами страниц и саммари для каждого узла. Когда приходит вопрос, в промпт отправляется не весь документ и не набор случайных кусков текста, а именно эта структура.

LLM выбирает релевантные ветки дерева, после чего в финальный запрос подставляются только привязанные к ним страницы. В результате система обходится без эмбеддингов, без векторного хранилища и без искусственного чанкинга, который часто ломает смысл на границах фрагментов. Именно поэтому вокруг PageIndex столько интереса.

На длинных финансовых отчетах, юридических документах, технических руководствах и учебных материалах такой подход выглядит естественно: человек тоже обычно начинает с оглавления, а не перебирает текст кусками. В репозитории проекта разработчики VectifyAI прямо позиционируют систему как reasoning-based retrieval и утверждают, что на FinanceBench она помогла добиться точности 98,7%. Для команд, которые работают с одним большим документом или небольшой коллекцией сложных PDF, это звучит как сильная альтернатива привычному RAG-пайплайну, особенно если хочется более интерпретируемого поиска с понятными ссылками на разделы и страницы.

Но главный вопрос не в том, можно ли заменить векторный поиск на PageIndex, а в том, где у этого подхода предел. Критика здесь довольно приземленная. Во-первых, TOC тоже нужно где-то хранить, особенно если документов больше одного, так что разговор о «полностью без индекса» немного лукавит.

Во-вторых, для больших коллекций пока не видно убедительной стратегии отбора документов: метаданные, keyword search, TF-IDF и BM25 никуда не исчезают и часто остаются дешевым первым фильтром. В-третьих, reasoning retrieval почти неизбежно дороже по токенам и медленнее по времени ответа. Если хороший векторный RAG уже дает около 90% качества, дополнительные проценты точности могут обойтись в разы дороже — и не для каждого продукта это разумный обмен.

Практика тоже показывает ограничения. В разборе отмечается, что PageIndex плохо справился с художественным текстом без явной структуры: если в документе нет разделов и заголовков, строить «умное оглавление» просто не на что. С академическим текстом результаты оказались лучше, потому что там есть нормальная иерархия секций.

Запустить систему локально можно через открытый репозиторий: установить зависимости, задать API-ключ для совместимого LLM через LiteLLM и прогнать PDF или markdown через run_pageindex.py. Но и тут есть нюансы: автор отдельно предупреждает о версии LiteLLM, не советует ставить облачный пакет pageindex из pip для локальной работы и описывает, что на слабых локальных моделях качество дерева заметно проседает, а сам процесс может занимать десятки минут даже на относительно небольшом документе.

Что это значит на практике? PageIndex не выглядит убийцей векторного поиска, но выглядит полезным новым слоем в RAG-архитектуре. Логичнее всего воспринимать его не как прямую замену, а как специализированный инструмент для длинных, структурированных документов, где важны объяснимость, точность навигации и работа по страницам.

Самый реалистичный сценарий — гибридный: сначала дешевый поиск по метаданным или векторам, затем PageIndex для точного выбора разделов. Такой компромисс лучше отражает реальность: универсальной замены векторному RAG пока не появилось, но у document-first подходов вроде PageIndex уже есть своя понятная ниша.