Proxy-Pointer RAG: достижение точности без векторов при масштабе и стоимости векторного RAG

Недавний запуск PageIndex является частью более широкого сдвига в архитектуре AI в сторону «Vectorless RAG» или «Reasoning-Based Retrieval». Вместо стандартного метода разделения документов на случайные фрагменты и поиска по математическому сходству, PageIndex создает «Умное оглавление» (иерархическое дерево), позволяющее LLM ориентироваться в документах так же, как эксперт. Многочисленные блоги, включая материал от Microsoft, описывают принципы работы (без векторной базы данных, без разделения на части, улучшенная объяснимость) и достигнутую точность 98,7% на финансовом бенчмарке. Однако они также осторожно отмечают, что Vectorless RAG лучше всего подходит для глубокого анализа сложных структурированных или полуструктурированных документов (таких как финансовые отчеты), чем для поиска в большом количестве независимых документов, таких как базы знаний службы поддержки, где следует продолжать использовать Vector RAG.

Почему это происходит?

Если Vectorless RAG с использованием PageIndex обеспечивает лучшие (или, по крайней мере, столь же хорошие) результаты почти по любому запросу, почему бы не использовать его для большой коллекции документов? Основная причина заключается в том, что древовидный подход PageIndex не может практически масштабироваться на сценарии с несколькими документами. Иерархический древовидный индекс, который является обязательным этапом приема, медленный и дорогой в построении с использованием LLM. Кроме того, поиск состоит из двух этапов: использование LLM для обхода дерева, определение наиболее релевантных узлов, а затем использование содержимого этих узлов в качестве контекста для этапа синтеза ответа с использованием LLM.

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

Что если вы могли бы получить отличную точность рассуждений с учетом структуры Vectorless RAG вместе с низкой задержкой и ценой Vector RAG, масштабируемым способом, который работает на всей корпоративной базе данных?

В этой статье я рассмотрю реальный прецедент на большом, сложном документе, чтобы построить Proxy-Pointer RAG — конвейер приема и поиска, который достигает этого благодаря набору инновационных инженерных шагов. Попутно мы исследуем и продемонстрируем следующее:

• Почему именно PageIndex так точен? И почему практически сложно масштабировать концепцию на многодокументные базы знаний.
• Быстрое сравнение Vectorless RAG с использованием PageIndex и Flat Vector RAG для установления базовой линии.
• Как мы можем включить принципы PageIndex в векторный индекс без каких-либо связанных с этим задержек и затрат?
• Сравнение широкого диапазона запросов с использованием PageIndex и Proxy-Pointer для проверки качества поисков.

Настройка варианта использования

Мы будем использовать доклад Всемирного банка под названием «Обновление развития Южной Азии, апрель 2024: рабочие места для устойчивости» (Лицензия: CC BY 3.0 IGO). Это доклад из 131 страницы, включающий несколько глав, сложные диаграммы, таблицы, содержание в текстовых окнах и т.д., и является хорошим кандидатом для PageIndex, чтобы доказать его возможности. Я использовал gemini-3-flash в качестве LLM для построения дерева pageindex и gemini-3.1-flash-lite для поисков. Я извлек PDF доклада в файл markdown, используя Adobe PDF Extract API, но подойдет любой другой метод, например использование VLM, который сохраняет целостность таблиц, диаграмм и т.д. Для векторной базы данных используется FAISS.

Как работает PageIndex?

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

Фаза 1: индексирование (один раз за документ)

PageIndex анализирует структуру заголовков документа (заголовки Markdown, контуры PDF и т.д.) в вложенное дерево. Каждый узел получает:

• Название (извлеченное из заголовка)
• ID узла (уникальный идентификатор, например 0012)
• Границы строк (начальная и конечная строка в исходном документе)
• Резюме (созданное LLM — это дорогостоящая и трудоемкая часть)

Результат — это JSON, который выглядит следующим образом:

{
  "node_id": "0011",
  "title": "Chapter 1. Deceptive Strength",
  "summary": "Covers South Asia's growth outlook, inflation trends, financial vulnerabilities, climate risks, and policy challenges...",
  "line_num": 621,
  "nodes": [
    {
      "node_id": "0012",
      "title": "Introduction",
      "summary": "Summarizes the chapter's key themes including regional growth driven by India...",
      "line_num": 625
    }
  ]
}

Фаза 2: поиск (по запросу)

Когда пользователь задает вопрос, PageIndex передает все дерево резюме LLM и говорит «Какие узлы содержат ответ?» Это отличается от Vector RAG, который полагается на математическое сходство между запросом и встроением фрагмента для построения соответствующего контекста.

LLM читает резюме — не полный текст — и возвращает краткий список ID узлов. Затем PageIndex использует граница строк, чтобы вырезать точный, непрерывный полный раздел из исходного файла markdown и передать его LLM синтеза.

Почему это работает так хорошо?

PageIndex превосходит благодаря трем архитектурным преимуществам:

1. Структурная навигация, а не сопоставление паттернов

Когда мы спрашиваем «Какие основные сообщения Главы 1?», PageIndex не ищет фрагменты, содержащие эти слова. Он читает резюме узла 0011 («Глава 1. Обманчивая сила»), которое говорит «Охватывает перспективы роста, тенденции инфляции, финансовые уязвимости, климатические риски и вызовы политики» — и сразу же знает, что это правильный узел. Он рассуждает о релевантности, а не семантическом и лексическом сходстве.

2. Извлечение непрерывного контекста

После определения правильных узлов PageIndex извлекает полный, неразрывный раздел, который представляет узел из исходного Markdown — заголовки, подзаголовки, маркеры, ссылки на рисунки и все остальное. LLM синтеза получает контекст, который читается как правильно написанный раздел документа, а не фрагментированный кусок с произвольными границами.

3. Нулевые артефакты границ фрагментов

Нет перекрывающихся фрагментов, нет разделенных предложений, нет контекстных окон, которые начинаются в середине абзаца. Каждый фрагмент контекста имеет естественное начало (заголовок раздела) и естественный конец (начало следующего раздела). Это резко снижает галлюцинацию из неоднозначного контекста.

Однако эта сила имеет цену — и именно здесь подход начинает разваливаться.

Почему это сложно масштабировать?

Причины — стоимость и задержка (как при приеме, так и при времени поиска). Для нашего доклада из 131 страницы мы получаем 137 структурных узлов в дереве и, следовательно, PageIndex нуждается в 137 вызовах LLM только для фазы индексирования — одно резюме на узел. Для корпуса из 50 документов это примерно 7000 вызовов LLM, прежде чем мы использовали его для ответа на единый вопрос.

Вот сравнительная стоимость PageIndex и Vector Index:

Для одного критичного документа, такого как финансовый отчет, эта стоимость легко оправдана. Для базы знаний предприятия из 500 документов по процедурам обслуживания клиентов, которая обновляется еженедельно? Это непрактично.

Вот здесь PageIndex начинает становиться непрактичным для реальных систем в масштабе.

Перед предложением альтернативы давайте установим базовую линию: насколько лучше PageIndex по сравнению со стандартным Vector RAG?

Сравнение Vectorless и Flat Vector RAG

Чтобы установить базовую линию, я сравнил результаты разнообразного диапазона запросов, используя Vectorless и плоский Vector RAG. Как и ожидалось, качество Vectorless RAG было лучше во всех случаях. Вот два примера:

Запрос о содержимом таблицы

Вот ответ от Vectorless RAG:

=== VECTORLESS RAG INTERACTION ===
Question: what does annexure table a2.1.1 say
Nodes Retrieved: 0125, 0131
Response:
Annex Table A2.1.1, titled "Studies included in the literature review," provides a comprehensive list of the academic and policy papers utilized to estimate the growth elasticity of employment (Annex Figure A2.1.1; Annex 2.1).

The table catalogs 25 specific studies, detailing the following information for each:

• Paper: The author(s) and publication source.
• Period of main sample: The timeframe covered by the study (ranging from the 1960s through 2019).
• Sample coverage: The geographical or organizational scope (e.g., Worldwide, Europe, South Asia, Africa, Asia).
• Region: The specific region analyzed.
• Economies: The specific countries included in the study sample.

According to the provided text, the articles listed in this table were selected based on specific criteria: they focus on growth elasticity of employment using country-level estimates. The selection excludes articles that present exclusively subnational, gender-specific, or industry/sector-specific estimates, as well as those focused solely on Okun's law and unemployment elasticity of growth (Annex 2.1).

А вот то же самое с использованием Vector RAG, что полностью пропускает содержимое:

=== VECTOR RAG INTERACTION ===
Question: what does annexure table a2.1.1 say
Retrieved 5 chunks.
Response:
Based on the provided context, there is no information available describing the contents of a table labeled "A2.1.1."

The documents list "A2.1.1" in the table of contents as «Studies included in the literature review» (page 93). However, the detailed content provided in your search results pertains to other tables, specifically:

• Annex 2.1: Describes a summary of the literature on the growth elasticity of employment, noting that "an extensive literature search was performed of studies on the elasticity of employment with respect to output growth."
• Annex Figure A2.1.1 (referenced as A2..1.11.1 in the text): Titled "Estimates of output elasticity of employment," which states, "The literature provides a wide range of estimates on the growth elasticity of total employment."
• Annex Table A2.3.3: Provides specific regression data regarding the robustness tests for the female employment ratio.

There is no specific data or content provided for Annex Table A2.1.1 beyond its title in the table of contents.

Запрос, требующий структурного знания документа

Запрос: what are the questions answered by chapter 2? Вот ответ от Vectorless RAG. Он точно определил Главу 2 и раздел «Вопросов» внутри и опубликовал его дословно вместе с информацией о основе для объяснимости.

=== VECTORLESS RAG INTERACTION ===
Question: what are the questions answered by chapter 2
Nodes Retrieved: 0098
Response:
Based on the provided excerpts, Chapter 2 addresses the following questions:

• How does South Asia's employment compare with that of other emerging market and developing economies (EMDEs)?
• What are the correlates of long-run employment ratios among EMDEs?
• How can South Asia create the jobs needed to absorb its growing working-age population, while also boosting productivity?

These questions are explicitly listed in the section titled «Questions.»

Фрагменты в Vector RAG не сохраняют иерархическую структуру и целостность раздела, поэтому, хотя он находит раздел «Вопросы», он не может найти конкретные вопросы в нем.

=== VECTOR RAG INTERACTION ===
Question: what are the questions answered by chapter 2
Retrieved 5 chunks.
Response:
Based on the provided document, Chapter 2—titled "Jobless Development"—is structured to address specific inquiries regarding labor markets and economic growth.

The chapter explicitly identifies a "Questions" section (page 65) to frame its analysis. While the document does not list the specific text of these questions, it indicates that the chapter covers the following thematic areas and analytical components:

• Trends and Productivity: The chapter examines "Trends in employment and labor productivity" (page 67) and addresses "Labor productivity growth" (page 73).
• Employment Ratios: A significant portion of the chapter is dedicated to "Long-run employment ratios" (page 75) and their various "Correlates," including:
  • Policy and Structural Factors: Tax regimes, policy uncertainty (page 77), and trade openness (page 79).
  • Market and Financial Factors: Access to finance (page 81), as well as product, labor, and land markets (page 82).
  • Human Capital and Firm Characteristics: Education (page 83) and establishment size (page 78).
• Growth Dynamics: The chapter explores the "Engines of output growth in EMDEs" (page 73) and the "Sectoral employment composition" (page 72).
• Policy Implications: The research concludes by addressing "Policy options to boost employment" (page 85).

Итак, вопрос становится: можем ли мы сохранить эти преимущества без затрат?

Инженерная разработка лучшего средства поиска — Proxy-Pointer RAG

Давайте создадим Proxy-Pointer RAG для ответа на этот вопрос. Основная идея интуитивна и заключается в следующем:

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

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

Затем вместо того, чтобы просить LLM ориентироваться в дереве, мы позволяем FAISS выполнить поиск — но мы проектируем фрагменты так, чтобы FAISS «понимал», где каждый фрагмент находится в иерархии документа.

Вот вид конвейера приема:

Конвейер приема

Построение скелетного дерева

Древесный парсер PageIndex на самом деле не нуждается в LLM для построения структурной иерархии. Обнаружение заголовков основано на регулярных выражениях — оно находит заголовки Markdown (#, ##, ###) и строит вложение от уровней отступа. LLM используется только для суммирования каждого узла.

Мы называем версию без LLM скелетным деревом: то же структура, те же ID узлов, те же граница строк — но без полей резюме.

# Build skeleton tree — no LLM, runs in milliseconds
pageindex = PageIndex(doc_path, enable_ai=False)
tree = pageindex.build_structure()  # Pure regex parsing

Скелетное дерево и суммированное дерево, созданное для более ранних Vectorless RAG, производят идентичные структуры — те же 137 узлов, те же глубины вложения, те же номера строк, те же названия. Единственное различие — отсутствующее поле резюме.

Стоимость: $0. Время: < 1 секунда.

Указатели структурных метаданных (основной отличающийся элемент)

Это суть того, почему PageIndex работает так хорошо — и трюк, который мы примем.

В стандартном векторном RAG, полученный фрагмент является контекстом. Какие бы 500 слов ни вернул FAISS, это то, что видит LLM. Если фрагмент начинается в середине предложения или заканчивается до ключевой точки данных, ответ полностью упустит намерение запроса (как показано в предыдущем разделе о сравнении Vectorless и Vector RAG).

PageIndex делает что-то принципиально другое: фрагмент никогда не является контекстом. Каждый узел в дереве знает его точную позицию в исходном документе — его название, его ID узла и, критически, начальный и конечный номера строк всего раздела, который он представляет. Когда поиск выбирает узел, PageIndex возвращается к исходному файлу Markdown и вырезает полный, непрерывный раздел между этими границами строк.

Мы воспроизводим это точно. Каждый фрагмент, который мы встраиваем в векторный индекс, содержит богатые структурные метаданные из узла дерева:

metadata = {
    "doc_id": "SADU",           # Which document
    "node_id": "0012",          # Which structural node
    "title": "Introduction",    # Section heading
    "start_line": 624,          # Where the section starts in the original file
    "end_line": 672             # Where the section ends
}

Во время поиска мы не передаем совпадающие фрагменты LLM. Вместо этого мы:

1. Используем фрагменты в качестве прокси — они здесь только для определения какие узлы релевантны. Удалить дублирование (doc_id, node_id) комбинаций, чтобы получить уникальные топ-k.
2. Следуйте указателям метаданных — откройте исходный Markdown, разрежьте строки узлов, например 624 на 672
3. Предоставьте полные разделы — LLM синтеза получает полный, неправленный, структурно целый текст

Вот вид конвейера поиска:

Конвейер поиска

Это означает, что даже если фрагмент совпадает только с одним предложением глубоко внутри раздела, LLM синтеза получает весь раздел — с его заголовком, его контекстом, его рисунками, его выводами. Фрагмент был одноразовым; указатель — это то, что имеет значение.

Вот почему я называю это Proxy-Pointer RAG: векторы являются прокси для местоположения, метаданные — указатели на реальное содержимое.

Стоимость: $0. Влияние: преобразует качество контекста из фрагментированных фрагментов в полные разделы документа.

Инъекция хлебных крошек (структурный контекст)

Это ключ для ответа на запросы, связанные с конкретным разделом документа (например, Глава 2). Стандартный векторный RAG встраивает raw текст:

«Хотя рост частных инвестиций замедлился как в Южной Азии, так и в других EMDЕ…»

FAISS понятия не имеет, что этот фрагмент происходит из Главы 1, под Экономической деятельностью, внутри Ящика 1.1. Поэтому, когда пользователь спрашивает «основные сообщения Главы 1», этот фрагмент не будет иметь высокий рейтинг — он не содержит слова «Глава 1» или «основные сообщения».

Инъекция хлебных крошек добавляет путь полного происхождения из скелетного дерева к каждому фрагменту перед встраиванием:

«[Глава 1. Обманчивая сила > Экономическая деятельность > Региональное развитие > ЯЩИК 1.1 Ускорение частных инвестиций]
Хотя рост частных инвестиций замедлился как в Южной Азии, так и в других EMDЕ…»

Теперь вектор встраивания кодирует и содержимое и его структурное расположение. Когда кто-то спрашивает о «Главе 1», FAISS знает, какие фрагменты принадлежат Главе 1 — потому что слова «Глава 1. Обманчивая сила» присутствуют в встраивании.

# Build breadcrumb from ancestry
current_cr