Попытки найти альтернативу векторному поиску в RAG продолжаются. После GraphRAG появился новый кандидат — PageIndex.

Идея проста. Документ разбивается на страницы. С помощью LLM и специального кода строится расширенная таблица содержания (TOC) в виде дерева узлов, для каждого из которых генерируется саммари. При поступлении запроса эта структура передаётся в промпт, и LLM определяет релевантные узлы. Каждому узлу соответствуют страницы документа, которые затем используются как контекст для финального ответа.

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

Плюсы и минусы

В README проекта приведён пример с одним документом. Но что делать, если их сотни или тысячи? Авторы предлагают три стратегии:

• Поиск по метаданным. Перспективно, но метаданные нужно получить. Эта функция обещана в ближайшей бета-версии. Однако фильтрация по метаданным уже есть в большинстве векторных хранилищ.
• Поиск по сгенерированному описанию документов. Работает, но эффективно только при небольшом количестве документов.
• Семантический поиск. Векторный поиск возвращается — без него не обойтись. Можно искать по TOC и саммари. Коэффициент сжатия контекста у PageIndex — в 4–5 раз меньше исходного текста.

Можно использовать и другие методы: TF-IDF, BM25, поиск по ключевым словам. Но индексы всё равно придётся где-то хранить. А где хранить TOC при большом числе документов? Пока PageIndex не предлагает рабочего решения для масштабных коллекций.

LLM давно используется в RAG: для транскрипции, управления коллекциями, адаптивной обработки. PageIndex добавляет ещё одну функцию — замену поиска по сходству на поиск по релевантности. Это имитирует поведение человека: сначала смотришь в оглавление, находишь нужный раздел, потом читаешь текст.

Retrieval is based on reasoning — traceable and interpretable, with page and section references. No more opaque, approximate vector search...

Заявлено 98,7% правильных ответов на FinanceBench — впечатляюще. Но цена высока: ресурсоёмкость. Допустим, векторный поиск с хорошим эмбеддингом даёт 90% точности. Дополнительные 8,7% могут стоить в десятки раз больше. Для некоторых проектов это оправдано. Для других — нет.

Судя по конфигурации, авторы экспериментировали с GPT-4o и GPT-5. Я же попробовал запустить PageIndex на локальных моделях.

Эксперименты

Текст для экспериментов

Сначала взял рассказ Уильяма Гибсона «New Rose Hotel» — PageIndex не справился. Скорее всего, из-за отсутствия структуры: это повествование без заголовков. Затем выбрал академическую статью: «A Cyberpunk 2077 perspective on the prediction and understanding of future technology» от Miguel Bordallo López и Constantino Álvarez Casado (University of Oulu).

Варианты пайплайна

PageIndex поддерживает Markdown и PDF — это два разных пайплайна.

Для Markdown текст разбивается по строкам с заголовками. Сегментация происходит от одного заголовка до следующего. Работает быстро, но это стандартный подход, аналогичный MarkdownTextSplitter из LangChain. Если заголовки не помечены — вся структура сводится к одному узлу: названию файла.

С PDF сложнее. PageIndex пытается выделить неотмеченные заголовки. Но не всегда успешно, особенно на слабых моделях.

Проблема I. Пайплайн падает из-за ошибок вывода в JSON. Пришлось обработать текст: убрать список литературы, кавычки и преобразовать нумерованные списки в маркированные.

Проблема II. Ошибка при недостаточной точности (accuracy) построения структуры. Порог — 60%. Для PDF система оценивает, сколько найденных узлов действительно находятся в указанных фрагментах. Можно снизить порог — коррекция ошибок идёт дальше. Я вынес значение в переменную окружения ACCURACY_THRESHOLD.

Проблема III. Низкая точность из-за перегрузки LLM. Связывание узлов и фрагментов выполняет LLM. Если модель слабая, она путает нумерацию. В коде предусмотрена группировка фрагментов, но параметр max_tokens по умолчанию — 20 тысяч токенов. Для текста в 17k токенов это одна группа. Я вынес MAX_TOKENS в переменную окружения.

На начальном этапе LLM ищет разделы:

• gemma3:27b — нашла оглавление, которого нет в документе. Пришлось остановить.
• gpt-oss:20b — справилась. Точность — от 57 до 63%. Seed не стабилизирует результат.
• qwen3:14b — точность 69,57%, но «вылетала» из-за JSON. Структура разделов — бедноватая.

На GPU 16 ГБ процесс занял около получаса: несколько минут на пайплайн, остальное — на коррекцию ошибок.

Как запустить

Внимание: PageIndex использует liteLLM. В requirements указана версия 1.82.0. Установите именно её — версии 1.82.7 и 1.82.8 скомпрометированы.

Не устанавливайте pageindex через pip — это версия с внешним API, не подходящая для локальной работы.

Я подготовил два ноутбука: MinimalPageindexLocalPDF.ipynb и MinimalPageindexLocalMD.ipynb — они в корне репозитория. Часть кода взята из примера с внешним API.

В utils.py добавил переменные OLLAMA_HOST и OLLAMA_TIMEOUT. В page_index.py — возможность настройки ACCURACY_THRESHOLD и MAX_TOKENS через переменные окружения. Этого достаточно для локального запуска.

Пример запроса: «What model was used in preparing this article and why?»

Ещё один запрос: «What does a dystopian future look like in this game?»

Инструкция по установке

1. Клонируйте репозиторий: git clone https://github.com/khmelkoff/PageIndex_local.git
2. Создайте и активируйте окружение: conda create --name pageindex python==3.11, затем conda activate pageindex
3. Установите зависимости: pip install -r requirements.txt
4. Проверьте версию litellm: pip show litellm — должна быть 1.82.0
5. Установите Jupyter: pip install notebook
6. Запустите Jupyter и откройте MinimalPageindexLocalPDF.ipynb
7. Загрузите модель: ollama pull gpt-oss:20b
8. Остановите ollama, установите переменные и запустите: set OLLAMA_HOST=0.0.0.0:11434, set OLLAMA_CONTEXT_LENGTH=32000, затем ollama serve
9. В ноутбуке проверьте переменные окружения и название модели. Для litellm 1.82.0 префикс openai обязателен.
10. Текст для экспериментов — в папке data: 2077.pdf, 2077.md и примеры TOC в формате pickle.

Выводы

Код пайплайна неидеален: функции похожи, слабо документированы, промпты вшиты в код. Для MVP — нормально, для продакшена — требуется доработка.

Лучший результат, вероятно, достигается в гибридном режиме: например, использовать расширенную TOC в векторном поиске или применять семантический поиск на этапе выбора документов. PageIndex — не альтернатива векторному RAG по эффективности. Ответы в реальном времени маловероятны, а обработка документов остаётся на порядок дороже.

Попытки заменить чем-то векторный поиск в RAG продолжаются. Про GraphRAG я ужевысказывался, новый претендент на замену -PageIndex.

Идея простая. Сегментируем документ на страницы, при помощи LLM и хитрого кода строим для него расширенную таблицу содержания,TOCв виде дерева узлов и саммари для каждого узла. Далее отправляем эту структуру в промпт поискового запроса и просим LLM найти релевантные узлы. За каждым найденным узлом закреплены страницы документа. Эти страницы достаём и используем в качестве контекста в финальном запросе.

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

Плюсы-минусы

Посмотрим на иллюстрацию изreadme:

Что не так, догадались? Правильно - документ всего один. Один! А что делать, если их сто, а если десятки тысяч? Авторами предлагаются следующиестратегии:

1. Поиск по метаданным. Метаданные - сильный аргумент, но их ещё нужно откуда-то получить. Такой поиск обещают в ближайшей бета версии. Заметим, что фильтрация по метаданным реализована практически в любом приличном векторном хранилище.

2. Поиск по сгенерированному описанию документов. Эта опция вроде бы уже работает. Идея хорошая, но подходит для небольшого количества документов.

3. Семантический поиск.Всё, можно выдохнуть, векторный поиск снова востребован.А у вас есть эмбеддинг с достаточно большим контекстным окном, чтобы можно было любой документ превратить в вектор? В принципе можно искать и по TOC с саммари. Я оценил коэффициент сжатия контекста, получилось, что Pageindex строит расширенную таблицу содержания, которая в четыре-пять раз меньше, чем исходный документ.

Что к этому можно добавить? Если не нравится возиться с эмбеддингом и векторным хранилищем, есть поиск по ключевым словам, по встречаемости в документах, любимыйTFIDFи прочие bm25. Однако индексы всё-таки лучше где-то хранить, а не строить на лету, особенно в варианте с нормализацией терминов и стеммингом. Поэтому совсем без хранилища здесь сложно. С другой стороны, а где хранить TOC, если документов больше одного?

Думаю, будет справедливо сказать, чтов PageIndex пока нет рабочей стратегии для обработки большой коллекции документов.

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

Retrieval is based on reasoning — traceable and interpretable, with page and section references. No more opaque, approximate vector search...

В итоге - высокая доля правильных ответов (заявлено 98,7% наFinanceBench) это и правда очень круто.Обратная сторона - ресурсоёмкость.Ризонинг вещь затратная. Допустим, что базовый векторный поиск в RAG, построенный со всеми известными эвристиками и хорошим эмбеддингом, даёт нам долю правильных ответов в районе 90%. Эти дополнительные 8,7% будут стоить в десятки раз дороже базы. Готов поверить, что для каких-то проектов это неважно. Вопрос приоритетов.

Судя по конфигу в репозитарии, авторы экспериментировали сgpt-4oиgpt-5.4Ну а я конечно же не удержался и попробовал запустить PageIndex на локальных моделях.

Эксперименты

Текст для экспериментов

По традиции я взял текст в жанре Cyberpunk. Выбрал рассказ Уильяма Гибсона"New Rose Hotel", но с ним Pageindex не справился, видимо потому что это повествование и в нём нет ни разделов, ни заголовков. Затем я решил попробовать академический текст. Это статья"A Cyberpunk 2077 perspective on the prediction and understanding of future technology"Miguel Bordallo López, Constantino Álvarez Casado, University of Oulu.

Варианты пайплайна

PageIndex понимает markdown и pdf. И это два разных паплайна. В случае с markdown текст разбивается на строки, фиксируются номера строк в которых содержится заголовок раздела. Текст сегментируется на фрагменты от строки с заголовком до следующей строки с заголовком. В принципе, всё работает и довольно быстро. Но мне кажется это не совсем честный подход. Точно также работаетMarkdownTextSplitterиз langchain. Предположу, что качество ответов будет примерно таким же как и у обычного векторного ретривера. А если заголовки в markdown не маркированы, структура текста будет состоять только из одного узла - названия файла документа.

С pdf всё сложнее, PageIndex умеет выделять заголовки, которые никак не помечены в тексте. Правда, не всегда и с кучей проблем на слабых моделях.

Проблема I.Пайплайн Pageindex падает из-за ошибок вывода в JSON, поэтому текст статьи пришлось обработать. Я отрезал список литературы, убрал все кавычки из текста и преобразовал нумерованные списки в маркированные. Ещё можно попробовать подобрать модель.

Проблема II.Пайплайн Pageindex падает с исключением при недостаточной доле правильных ответов при построении структуры текста. Это accuracy, внутренний параметр PageIndex, в коде установлено пороговое значение в 60%.

В случае с pdf PageIndex разбивает текст на постраничные фрагменты, каждый фрагмент маркируется двумя индексами - номером первой страницы фрагмента и номером какой-то следующей страницы. Ведь раздел может быть на несколько страниц. Accuracy же показывает сколько найденных узлов/заголовков действительно находятся в указанных фрагментах. Можно попробовать снизить этот параметр, там всё равно дальше по пайплайну коррекция ошибок. Сам порог задан в функции meta_processor модуля page_index.py. Я его вытащил в переменную окружения.

Проблема III.Почему собственно получается низкая доля правильных ответов? Здесь пришлось сильно углубиться в код. Причина оказалась в том, что связку узлов и фрагментов текста выполняет LLM. Если в слабую модель "запихнуть" весь контекст с фрагментами, она сбивается в нумерации. Для такого случая в коде заботливо предусмотрели группировку фрагментов на чуть менее крупные куски. Только вот работа этой группировки зависит от параметра max_tokens в функции page_list_to_group_text. А он по умолчанию установлен в 20 тысяч токенов и его можно поменять только в коде. Соответственно моему тексту в 17k токенов соответствовала всего одна группа текстов.

В начале пайплайна LLM пытается найти перечень разделов, выглядит это примерно так:

gemma3:27bбуквально на второй странице нашла таблицу содержания, которой в документе нет. Пришлось остановить.

gpt-oss:20bна мой взгляд с задачей справилась, accuracy варьируется от 57 до 63%. Seed не помогает стабилизировать. Все примеры для этой статьи сделаны на gpt-oss:20b.

qwen3:14bпревзошла gpt-oss:20b с accuracy в 69.57%, но пару раз "вылетала" из-за json. И структура разделов у неё получается бедноватой.

Процесс на компьютере с GPU 16GB, не самом новом, занимает около получаса, несколько минут на пайплайн, остальное на коррекцию ошибок.

Как запустить

Внимание! Pageindex использует пакет liteLLM, в requirements указана версия 1.82.0. Убедитесь, что установлена именно эта версия. Старшие версии 1.82.7 и 1.82.8 скомпрометированы,ссылка

Не устанавливайте пакет pageindex через pip. Это версия с внешним АПИ, она не нужна для локальной работы.

Я подготовил два ноутбука: MinimalPageindexLocalPDF.ipynb и MinimalPageindexLocalMD.ipynb, они в корнерепозитария. Часть кода позаимствовал из pageindex_RAG_simple.ipynb, это пример с внешним АПИ.

В модульutils.pyдобавил переменные окружения OLLAMA_HOST и OLLAMA_TIMEOUT, они теперь используются в функциях llm_completion и llm_acompletion. В модульpage_index.pyдобавил возможность менять порог для accuracy через переменную окружения ACCURACY_THRESHOLD и максимальное количество токенов для группировки фрагментов текста - MAX_TOKENS. Собственно это всё, что нужно для запуска на локальной модели.

Тестовый вопрос:"What model was used in preparing this article and why?"

Найденные узлы и рефлексия:

Сгенерированный ответ:

Ещё один вопрос:"What does a dystopian future look like in this game?"

Инструкция по установке и запуску

1. Клонируйте репозитарий с моим форкомgit clonehttps://github.com/khmelkoff/PageIndex\_local.git

2. Создайте и активируйте python окружение. Для conda:conda create --name pageindex python==3.11conda activate pageindex

3. Перейдите в папку Pageindex_local и установите необходимые пакетыpip install -r requirements.txt

4. Проверьте версию пакета litellm, должна быть 1.82.0pip show litellm

5. Установите jupyter notebookpip install notebook

6. Запустите jupyter notebook и откройте файл MinimalPageindexLocalPDF.ipynb

7. Загрузите модель в ollamaollama pull gpt-oss:20b

8. Остановите ollama. Установите переменные окружения и запустите снова - ollama serveset OLLAMA_HOST=0.0.0.0:11434set OLLAMA_CONTEXT_LENGTH=32000

9. В ноутбуке проверьте установку переменных окружения, в частности путь к ollama, и название модели в конфиге. Для litellm 1.82.0 префикс openai обязателен.

10. Текст для экспериментов находится в папке data, это 2077.pdf, там же есть вариант в маркдаун 2077.md и сохранены примеры сгенерированных TOC в формате pickle.

Вместо выводов

Код пайплайна неидеален и работает нестабильно, функций много, они похожи друг на друга и почти не документированы. Промпты прямо в коде, редактировать сложно. ДляMVPнормально, для коммерческих целей придётся серьезно дорабатывать.

Думаю, что хороший результат может быть получен в гибридном варианте. Например, расширенный TOC в векторном поиске или векторный поиск в стратегии выбора документов. При этом, подход не является альтернативой для векторного RAG, уж точно не по эффективности. Ответов в реальном времени не будет, а пайплайн обработки документов останется всегда на порядок дороже векторного.