Прокси-указатель RAG: достижение безвекторной точности в масштабе и по стоимости векторного RAG

Новый способ построения векторного RAG — учитывающий структуру и способный к логическому осмыслению.

Делиться

Недавний запуск PageIndex является частью более широкого сдвига в архитектуре ИИ в сторону «Vectorless RAG» или «Reasoning-Based Retrieval» (поиска на основе логических рассуждений). Вместо стандартного метода разделения документов на случайные фрагменты и поиска по математическому сходству, PageIndex создает «умное оглавление» (иерархическое дерево), которое позволяет пользователям с ограниченными знаниями ориентироваться в документах так же, как это делал бы эксперт-человек. Многочисленные блоги (включая этот от 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 с помощью API Adobe PDF Extract, но любой другой метод, например, использование VLM, который сохраняет целостность таблиц, диаграмм и т. д., будет работать так же хорошо. В качестве векторной базы данных используется FAISS.

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

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

Этап 1: Индексирование (один раз для каждого документа)

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

• Заголовок (извлеченный из заголовка)
• Идентификатор узла (уникальный идентификатор, например, 0012)
• Границы строк (начальная и конечная строки в исходном документе)
• Краткое изложение (составленное магистратом права — это самая дорогостоящая и трудоемкая часть).

В результате получается JSON-файл следующего вида:

{ «node_id»: «0011», «title»: «Глава 1. Обманчивая сила», «summary»: «Рассматриваются перспективы роста Южной Азии, тенденции инфляции, финансовая уязвимость, климатические риски и политические проблемы…», «line_num»: 621, «nodes»: [ { «node_id»: «0012», «title»: «Введение», «summary»: «Кратко излагаются ключевые темы главы, включая региональный рост, обусловленный Индией…», «line_num»: 625 }, … ] }

Этап 2: Извлечение данных (по каждому запросу)

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

LLM считывает аннотации, а не полный текст, и возвращает короткий список идентификаторов узлов. Затем 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?

Сравнение векторного и плоского векторного RAG

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

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

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

=== ВЕКТОРНОЕ ВЗАИМОДЕЙСТВИЕ ТРУСОВЫХ МАТЕРИАЛОВ === Вопрос: что говорится в таблице A2.1.1 приложения? Получено узлов: 0125, 0131. Ответ: Таблица A2.1.1 приложения, озаглавленная «Исследования, включенные в обзор литературы», содержит исчерпывающий список академических и политических работ, использованных для оценки эластичности роста занятости (Рисунок A2.1.1 приложения; Приложение 2.1). В таблице перечислены 25 конкретных исследований, для каждого из которых указана следующая информация: * **Работа:** Автор(ы) и источник публикации. * **Период основной выборки:** Временные рамки, охватываемые исследованием (с 1960-х по 2019 год). * **Охват выборки:** Географический или организационный охват (например, весь мир, Европа, Южная Азия, Африка, Азия). * **Регион:** Конкретный анализируемый регион. * **Экономики:** Конкретные страны, включенные в выборку исследования. Согласно представленному тексту, статьи, перечисленные в этой таблице, были отобраны на основе определенных критериев: они посвящены эластичности роста занятости с использованием оценок на уровне стран. Из отбора не включены статьи, представляющие исключительно оценки на субнациональном уровне, с учетом гендерных различий или специфики отраслей/секторов, а также статьи, посвященные исключительно закону Окуна и эластичности роста безработицы (Приложение 2.1).

То же самое происходит при использовании Vector RAG, который полностью игнорирует содержимое.

=== ВЗАИМОДЕЙСТВИЕ ВЕКТОРОВ И ТРУСОВ === Вопрос: что говорится в таблице A2.1.1 приложения? Получено 5 фрагментов. Ответ: Исходя из предоставленного контекста, отсутствует информация, описывающая содержание таблицы с пометкой «A2.1.1». В документах «A2.1.1» указан как **«Исследования, включенные в обзор литературы»** (страница 93). Однако подробное содержание, представленное в результатах вашего поиска, относится к другим таблицам, а именно: * **Приложение 2.1:** Содержит краткое изложение литературы по эластичности роста занятости, отмечая, что «был проведен обширный поиск литературы по исследованиям эластичности занятости по отношению к росту производства». * **Рисунок A2.1.1 (в тексте указан как A2.1.11.1):** Заголовок «Оценки эластичности производства по отношению к занятости», в котором говорится: «В литературе представлен широкий диапазон оценок эластичности роста общей занятости». * **Приложение A2.3.3:** Содержит конкретные данные регрессионного анализа, касающиеся тестов на устойчивость показателя занятости женщин. В Приложении A2.1.1, помимо его названия в содержании, нет других конкретных данных или информации.

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

Вопрос в том, на какие вопросы отвечает глава 2? Вот ответ от Vectorless RAG. Они точно определили местоположение главы 2 и раздела «Вопросы» в ней и опубликовали его дословно, вместе с основной информацией для пояснения.

=== ВЕКТОРНОЕ БЕЗВЕКТОРНОЕ ВЗАИМОДЕЙСТВИЕ С ТРЯПКАМИ === Вопрос: На какие вопросы отвечает глава 2? Получено узлов: 0098 Ответ: На основе предоставленных выдержек глава 2 рассматривает следующие вопросы: * **Как уровень занятости в Южной Азии соотносится с уровнем занятости в других странах с развивающейся экономикой (СЭР)?** * **Каковы корреляты долгосрочных показателей занятости в странах с развивающейся экономикой?** * **Как Южная Азия может создать рабочие места, необходимые для трудоустройства растущего населения трудоспособного возраста, одновременно повышая производительность труда?** Эти вопросы явно перечислены в разделе «Вопросы».**

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

=== ВЗАИМОДЕЙСТВИЕ ВЕКТОРОВ И ТРЯПОК === Вопрос: На какие вопросы отвечает глава 2? Получено 5 фрагментов. Ответ: На основании предоставленного документа, глава 2, озаглавленная «Безработное развитие», структурирована таким образом, чтобы ответить на конкретные вопросы, касающиеся рынков труда и экономического роста. В главе явно выделен раздел «Вопросы» (страница 65), который служит основой для анализа. Хотя в документе не указан конкретный текст этих вопросов, он указывает, что глава охватывает следующие тематические области и аналитические компоненты: * **Тенденции и производительность:** В главе рассматриваются «Тенденции в занятости и производительности труда» (страница 67) и «Рост производительности труда» (страница 73). * **Показатели занятости:** Значительная часть главы посвящена «Долгосрочным показателям занятости» (стр. 75) и их различным «коррелятам», включая: * **Политические и структурные факторы:** Налоговые режимы, неопределенность политики (стр. 77) и открытость торговли (стр. 79). * **Рыночные и финансовые факторы:** Доступ к финансированию (стр. 81), а также рынки товаров, труда и земли (стр. 82). * **Человеческий капитал и характеристики фирм:** Образование (стр. 83) и размер предприятия (стр. 78). * **Динамика роста:** В главе рассматриваются «Двигатели роста производства в странах с развивающейся экономикой» (стр. 73) и «Секторальная структура занятости» (стр. 72). * **Последствия для политики:** Исследование завершается рассмотрением «Вариантов политики для стимулирования занятости» (стр. 85).

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

Разработка более совершенной собаки-поисковика — Proxy-Pointer RAG

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

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

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

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

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

Постройте скелетное дерево

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

Мы называем версию без LLM « скелетным деревом» : та же структура, те же идентификаторы узлов, те же границы строк — но без сводных данных.

# Создание каркаса дерева — без LLM, выполняется за миллисекунды pageindex = PageIndex(doc_path, enable_ai=False) tree = pageindex.build_structure() # Чистый парсинг регулярных выражений

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

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

Структурные метаданные-указатели (ключевое отличие)

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

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

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

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

metadata = { «doc_id»: «SADU», # Какой документ «node_id»: «0012», # Какой структурный узел «title»: «Введение», # Заголовок раздела «start_line»: 624, # Где начинается раздел в исходном файле «end_line»: 672 # Где заканчивается раздел }

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

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

Вот схема процесса извлечения данных:

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

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

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

Введение хлебных крошек (структурный контекст)

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

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

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

Внедрение «хлебных крошек» добавляет полный путь происхождения от «скелетного дерева» к каждому фрагменту перед его встраиванием:

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

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

# Создание навигационной цепочки на основе исходных данных current_crumb = f»{parent_breadcrumb} > {node_title}» # Добавление текста фрагмента перед встраиванием enriched_text = f»[{current_crumb}]n{section_text}» chunks = text_splitter.split_text(enriched_text)

Это кодирование древовидной структуры в векторное пространство с нулевыми затратами. Мы используем тот же API для встраивания, тот же индекс FAISS, тот же код поиска. Единственное отличие заключается в том, что мы передаем в встраиватель.

Стоимость: 0 долларов США дополнительно. Влияние: Улучшает качество поиска для структурных запросов.

Структурно-ориентированное сегментирование (без слепых раздвижных окон)

Стандартный векторный алгоритм RAG применяет скользящее окно по всему документу — окно размером 2000 символов, которое перемещается вперед с некоторым перекрытием, совершенно не обращая внимания на структуру документа. Фрагмент может начинаться с середины абзаца во введении и заканчиваться на середине предложения в подписи к рисунку. Границы произвольны, и каждый фрагмент представляет собой отдельный остров, не знающий своего положения в общей структуре документа.

Proxy-Pointer делает нечто принципиально иное: мы проходим по дереву, а не по тексту.

Для каждого узла в скелетном дереве мы извлекаем только текст его собственного раздела — от start_line до end_line — а затем применяем разделитель текста к этому изолированному разделу. Если раздел достаточно короткий, он становится одним целым блоком. Если он длиннее, разделитель делит его — но строго в пределах границ этого раздела.

Стандартный RAG: Слепое скользящее окно по всему документу [====chunk1====][====chunk2====][====chunk3====]… ↑ может начинаться во Введении, заканчиваться в подписи к рисунку. Прокси-указатель: Фрагмент в пределах границ каждого узла. Введение (строки 624-672) → [фрагмент A] [фрагмент B] Экономическая активность (строки 672-676) → [фрагмент C] BOX 1.1 (строки 746-749) → пропущено (< 100 символов) Инфляция (строки 938-941) → [фрагмент D]

Это гарантирует три вещи:

1. Фрагменты никогда не выходят за рамки разделов — фрагмент из раздела «Введение» никогда не будет пересекаться с разделом «Экономическая деятельность».
2. Каждый фрагмент принадлежит ровно одному узлу — поэтому метаданные node_id всегда точны.
3. Количество панировочных сухарей указано точно для каждого куска — оно отражает реальную структуру контейнера, а не является предположением.

Важно отметить, что если узел пропускается (потому что его текст слишком короткий — например, заголовок «BOX 1.1» без основного содержимого), обход дерева все равно рекурсивно проходит по его дочерним узлам. Фактическое содержимое находится в дочерних узлах, таких как «Введение», «Особенности» и «Рисунки» — все они встраиваются вместе с заголовком родительского узла в свою навигационную цепочку (например: BOX 1.1 Ускорение частных инвестиций > Введение, BOX 1.1 > Особенности…). Содержимое никогда не теряется; исключаются только пустые структурные заголовки.

Стоимость: 0 долларов. Влияние: Каждый фрагмент структурно отслеживается, что позволяет получать точные указатели на метаданные.

Фильтрация шума (удаление отвлекающих факторов)

Некоторые разделы в любом документе не имеют отношения к поиску и загрязняют контекст: они содержат ключевые слова, которые соответствуют почти каждому запросу, но не предоставляют полезной информации.

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

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

При индексировании мы применяем простой фильтр по заголовку:

NOISE_TITLES = { «contents», «summary of contents», «table of contents», «abbreviations», «acknowledgments», «foreword», «executive summary», «references» } if title.strip().lower() in NOISE_TITLES: continue # Пропустить этот узел полностью

Этот фильтр удалил 7 узлов из нашего тестового документа. Результат был незамедлительным: для запроса «Каковы основные тезисы главы 1?» система перестала получать краткое содержание и оглавление и начала получать собственно раздел «Введение».

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

Вот и всё. Proxy-Pointer RAG готов к тестированию.

Тестовый конвейер прокси-указатель

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

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

=== ВЗАИМОДЕЙСТВИЕ ПРОКСИ-УКАЗАТЕЛЬ RAG === Вопрос: что говорится в таблице приложения A2.1.1? Извлеченные уникальные контекстные узлы: — [SADU] Узел 0131: 'ТАБЛИЦА ПРИЛОЖЕНИЯ A2.1.1 Исследования, включенные в обзор литературы' | Строки: 3952-4157 — [SADU] Узел 0092: 'ТАБЛИЦА ПРИЛОЖЕНИЯ SL.B1.1.1 Предельная вероятность исследования, документирующего эффект выше среднего для домохозяйств с низким и средним уровнем дохода' | Строки: 2537-2745 — [SADU] Узел 0052: 'ТАБЛИЦА B1.1.1 Корреляты вероятности начала ускорения частных инвестиций' | Строки: 1663-1899 Ответ: На основании предоставленных документов, **Приложение A2.1.1** озаглавлено **«Исследования, включенные в обзор литературы».** Эта таблица содержит краткое описание различных исследовательских работ, с указанием следующей информации для каждой из них: * **Статья:** Автор(ы) и год исследования (например, Kapsos (2005), Saget (2000), Papola and Sahu (2012) и др.). * **Период основной выборки:** Временные рамки, охватываемые исследованием (с 1960-х по 2019 год). * **Охват выборки:** Масштаб или количество анализируемых объектов (например, «160 стран», «90 развивающихся стран», «47 африканских стран»). * **Регион:** Географический охват исследования (например, весь мир, Южная Азия, Африка, Европа, Ближний Восток, Азия). * **Экономики:** Конкретные страны или экономические группы, включенные в исследование (например, «Индия», «Болгария, Чехия, Эстония…», «Страны G20»). В таблице представлены данные по различным исследованиям, охватывающим период с 1960 по 2019 год, включая регионы и экономики по всему миру, а также данные по странам с переходной экономикой, различным странам ОЭСР и таким регионам, как Южная Азия и Африка.

Запрос, требующий структурных знаний.

=== ВЗАИМОДЕЙСТВИЕ ПРОКСИ-УКАЗАТЕЛЬ RAG === Вопрос: на какие вопросы отвечает глава 2? Извлечены уникальные контекстные узлы: — [SADU] Узел 0099: 'РИСУНОК 2.3 Модели роста' | Строки: 3127-3155 — [SADU] Узел 0098: 'Вопросы' | Строки: 3115-3127 — [SADU] Узел 0124: 'ПРИЛОЖЕНИЕ 2.1 Краткий обзор литературы по эластичности роста занятости' | Строки: 3807-3812 Ответ: На основе предоставленного текста в Главе 2 рассматриваются следующие вопросы, касающиеся экономического роста и рынка труда Южной Азии: * **Как уровень занятости в Южной Азии соотносится с уровнем занятости в других странах с развивающейся экономикой (СЭР)?** (Источник: *Глава 2, Раздел вопросов*) * **Каковы корреляты долгосрочных показателей занятости в странах с развивающейся экономикой?** (Источник: *Глава 2, Раздел вопросов*) * **Как Южная Азия может создать рабочие места, необходимые для трудоустройства растущего населения трудоспособного возраста, одновременно повышая производительность труда?** (Источник: *Глава 2, Раздел вопросов*) Кроме того, в главе рассматриваются эти вопросы с целью понимания того, как регион может использовать свое население трудоспособного возраста для ускорения сближения с уровнем доходов развитых экономик.

Хотя мы уже продемонстрировали ценовое преимущество, удается ли данной архитектуре преодолеть проблему масштабируемости PageIndex?

Масштабируем ли Proxy-Pointer?

Вот почему эта архитектура масштабируема в рамках корпоративной базы знаний. PageIndex имеет недостатки в масштабируемости с обеих сторон: около 137 вызовов LLM на документ во время индексирования и дополнительный шаг логического вывода LLM на каждый запрос для навигации по дереву. Proxy-Pointer устраняет оба этих недостатка.

• При индексировании LLM не используется. Дерево-скелет строится с помощью регулярных выражений за миллисекунды. Единственные вызовы API — к модели встраивания, идентичной стандартной векторной RAG.
• При извлечении данных отсутствует древовидная навигация. Запросы направляются непосредственно к векторному индексу. Отсутствуют сводки чтения LLM и обход документов по отдельности.

Proxy-Pointer — это стандартный векторный RAG с встроенными интеллектуальными метаданными. Структурная информация хранится внутри эмбеддингов (через «хлебные крошки») и метаданных фрагментов (через указатели узлов), а не в цикле логического вывода LLM. Он наследует все возможности масштабируемости векторного RAG: унифицированные многодокументные индексы, сублинейный поиск, инкрементальные обновления и нулевые накладные расходы LLM на каждый запрос после окончательного синтеза.

Защита от сбоев для неструктурированных документов: если документ не содержит заголовков — или дерево-скелет содержит только один корневой узел — система обнаруживает это во время разбиения на фрагменты и переключается на стандартное скользящее окно. Фрагменты помечаются пустыми значениями node_id и границами строк. Во время извлечения помеченные фрагменты используются непосредственно в качестве контекста LLM, а не по указателям обратно к источнику. Система плавно переходит к стандартному векторному RAG — без ошибок и специальной обработки.

Давайте сравним Vectorless RAG и Proxy-Pointer напрямую.

Vectorless vs Proxy-Pointer RAG

Я выполнил множество запросов — общие структурные, перекрестные ссылки, конкретные фактические, касающиеся конкретных рисунков и т. д. И позволил Клоду оценить ответы для всестороннего сравнения. Подробные ответы от Vectorless и Proxy-Pointer, а также полный отчет о сравнении качества, вы можете найти здесь .

В следующей таблице представлен итоговый результат. Итоговый счет: PageIndex 2 — Proxy 4 — Ничья 4. Другими словами, Proxy-Pointer соответствует или превосходит PageIndex в 8 из 10 запросов . И все это при масштабируемости и цене Flat Vector RAG.

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

А вот сравнение цен:

Основные выводы

1. В RAG не хватает именно структуры. Разница в качестве между наивным векторным RAG и PageIndex заключается не в улучшении эмбеддингов, а в сохранении иерархии.
2. Для кодирования структуры не требуется LLM. Внедрение «хлебных крошек» и структурные метаданные обеспечивают векторному индексу структурную информацию без каких-либо затрат.
3. Фильтрация шума превосходит более качественные эмбеддинги. Удаление 7 узлов с низкими значениями из индекса оказало большее влияние на качество поиска, чем любая замена модели.
4. Указатели превосходят блоки. Блоки выступают в качестве заменителей полного раздела, который и видит синтезатор LLM.

Заключение

Proxy-Pointer RAG доказывает простой тезис: для того, чтобы система поиска информации понимала структуру данных, не требуется дорогостоящая LLM-система — достаточно просто грамотно подойти к ее внедрению.

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

В следующий раз, когда будете создавать RAG для своего хранилища структурированных (или неструктурированных) документов, не пытайтесь использовать более крупную модель. Используйте индекс на основе прокси-указатели .

Свяжитесь со мной и поделитесь своими комментариями на сайте www.linkedin.com/in/partha-sarkar-lets-talk-AI

Ссылка

Всемирный банк. 2024. Обзор развития Южной Азии, апрель 2024 г.: Рабочие места для повышения устойчивости — Лицензия: CC BY 3.0 IGO.

Изображения, использованные в этой статье, сгенерированы с помощью Google Gemini. Код создан мной.

Источник: towardsdatascience.com