PageIndex — это инструмент, который читает длинные PDF как человек: сначала строит умное оглавление, потом рассуждает, куда смотреть, вместо того чтобы слепо сравнивать слова через векторы. GitHub: https://github.com/VectifyAI/PageIndex

Если просто

Представьте, что вы ищете конкретную цифру в годовом отчёте на 200 страниц. Обычные поисковики по документам (RAG) режут текст на куски, превращают в векторы и ищут “похожее”. Но “похоже” ≠ “нужно”. PageIndex делает по-другому: он строит дерево разделов документа и заставляет LLM “думать”, в какую ветку заглянуть, как вы сами просматриваете оглавление.

Я проверила — это не просто ещё одна база данных. Это попытка отказаться от векторных поисков, которые часто теряют контекст в профессиональных документах (финансовые отчёты, юридические акты, учебники).

Что это решает

Боль в том, что векторный поиск плохо справляется с длинными документами, где нужно рассуждать. Например, вопрос “Как изменилась политика дивидендов в 2023 году?” требует понимания структуры отчёта, а не просто поиска слова “дивиденды”.

PageIndex создаёт иерархическое дерево — буквально JSON с заголовками, диапазонами страниц и краткими описаниями разделов. Потом LLM проходит по этому дереву, выбирая нужные ветви. Это называют “reasoning-based retrieval” — поиск через рассуждение, а не через математическое сходство векторов.

Как попробовать

Самый простой путь — Colab-блокноты, которые лежат в репозитории. Нужен Python, ключ API от OpenAI или другого LLM (поддерживается LiteLLM для разных провайдеров), и PDF-файл.

Установка локальная:

pip install -r requirements.txt

Создаёте .env с API-ключом, запускаете скрипт — получаете JSON-дерево документа. Для продакшена есть облачный API с улучшенным OCR (распознаванием текста), потому что стандартный парсинг PDF иногда капризничает со сложными макетами.

Есть ещё интеграция через MCP (Model Context Protocol) — это протокол, который позволяет Claude или другим агентам напрямую “разговаривать” с PageIndex.

3 сценария с примерами

1. Анализ финансовых отчётов Задача: Найти, какие риски упоминались в разделе ликвидности во втором квартале. Как применить: Загружаете 10-Q отчёт в PageIndex, он строит дерево. Затем запрашиваете через API: “Найди риски в подразделе Liquidity Analysis”. LLM пройдёт по веткам дерева, найдёт нужные страницы без перебора всего документа. Что получится: Точные цитаты с номерами страниц, без ложных срабатываний на слове “риск” в других контекстах.

2. Юридический due diligence Задача: Проверить все упоминания конкретной клаузы договора в папке сделок. Как применить: Используете PageIndex File System (новая фича) для работы с корпусом документов. Строите индексы для каждого договора, потом агент ищет по всему “лесу” деревьев сразу. Что получится: Список релевантных абзацев с пониманием структуры каждого документа, а не просто совпадения слов.

3. Образовательный контент (учебники) Задача: Найти объяснение конкретной формулы с примерами из разных глав. Как применить: Загружаете учебник по эконометрике, строите дерево. Запрос: “Где объясняется регрессия с примерами из финансов?”. Что получится: LLM найдёт не только главу про регрессию, но и конкретные примеры в кейс-стади, потому что дерево сохраняет иерархию “теория → применение”.

Где можно застрять

Во-первых, локальная версия использует стандартный парсинг PDF. Если у вас сканы с таблицами или колонками, он может споткнуться. Облако решает это через OCR, но это уже платно.

Во-вторых, quality дерева сильно зависит от качества LLM. Если модель слабая (дёшево), дерево построится криво — и поиск будет блуждать.

В-третьих, это не для потоковой обработки миллионов мелких файлов. PageIndex заточен под длинные профессиональные документы (10+ страниц), где структура важна. Для базы знаний из коротких заметок это overkill.

Кому это нужно

  • Финансовым аналитикам, копающимся в 10-K и 10-Q
  • Юристам, работающим с длинными контрактами и регуляциями
  • Исследователям, обрабатывающим научные статьи и книги
  • Разработчикам агентов, которым нужно “честное” понимание структуры документа, а не векторная лотерея

Кому это не нужно

  • Если вы просто ищете по базе знаний типа “как установить плагин” — проще обычный векторный RAG
  • Если бюджет на API ограничен: построение дерева требует много вызовов LLM (дороже, чем один эмбеддинг)
  • Если документы короткие (1-2 страницы) — затраты на индексацию не окупятся

Вердикт Веры

Мне нравится смелость: отказаться от векторов — это как отказаться от колёс и изобрести шагающий механизм. Иногда это бессмысленно, но для профессиональных документов — может быть прорывом.

Честно скажу: я не уверена, что “vectorless” заменит векторы везде. Но как дополнительный слой — когда нужна точность и объяснимость, почему модель выбрала именно этот абзац — это золото. Особенно если вы строите агентов, которым нельзя галлюцинировать по поводу цифр в отчётах.

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

Материалы

Похожие материалы