PageIndex: глибокий аналіз: RAG без векторів, що базується на міркуваннях, дозволяє AI читати документи як експерт
PageIndex — це RAG-фреймворк без векторів, що базується на міркуваннях, з відкритим кодом від команди Vectify AI (GitHub 14.8k+ зірок). Він перетворює довгі документи на ієрархічні деревоподібні індекси, використовує LLM для пошуку на основі міркувань на дереві та досягає 98,7% точності на фінансовому бенчмарку FinanceBench для запитань і відповідей щодо фінансових документів.

1. Передумови: П'ять проблем традиційного RAG
RAG став фактичним стандартом для застосування великих мовних моделей. Основні рішення на етапі попередньої обробки поділяють документи на чанки фіксованої довжини, перетворюють їх на вектори за допомогою моделі embedding і зберігають у векторній базі даних; під час запиту роблять те саме embedding для запитання користувача, а потім викликають Top-K результати за допомогою пошуку векторної подібності, об'єднуючи їх у вхідний контекст LLM.
Цей процес ефективний для коротких текстів і загальних сценаріїв, але в сценаріях професійних довгих документів (фінансові звіти, закони та нормативні акти, технічні посібники тощо) виявляє п'ять фундаментальних проблем:
1) Подібність ≠ релевантність. Векторний пошук передбачає, що «семантично найбільш подібний текстовий блок = найбільш релевантне джерело відповіді», але в професійних документах велика кількість абзаців має приблизну семантику, але значно відрізняється в ключових деталях.
2) Жорстке розділення на блоки руйнує цілісність контексту. Розділення документів на фіксовані вікна розміром 512 або 1024 токени призводить до обрізання речень, абзаців і навіть цілих логічних розділів, що призводить до втрати ключового контексту.
3) Розбіжність між наміром запиту та простором знань. Запит користувача виражає «намір», а не «зміст», тому query embedding і document embedding знаходяться в різних семантичних просторах.
4) Неможливість обробки посилань у документі. У професійних документах часто зустрічаються посилання на кшталт «див. додаток G», «порівняйте таблицю 5.3» тощо. Між цими посиланнями та змістом, на який вони посилаються, немає семантичної подібності, тому векторний пошук не може їх зіставити.
5) Незалежні запити, неможливість використання історії діалогу. Кожен пошук розглядає запит як незалежний, тому неможливо поєднати контекст попереднього діалогу для поступового пошуку.
2. Загальна архітектура PageIndex
PageIndex — це RAG-фреймворк без векторів (Vectorless), що базується на міркуваннях (Reasoning-based). Його основна ідея полягає в тому, щоб замість того, щоб модель робила приблизні зіставлення у векторному просторі, дозволити моделі міркувати над структурованим представленням документа — вирішувати, «куди дивитися», а не просто «що виглядає схожим».
PageIndex імітує спосіб, яким експерти читають довгі документи: спочатку переглядають зміст, визначають відповідні розділи на основі запитання, а потім заглиблюються, поки не знайдуть цільовий вміст. Цей процес реалізується у два етапи:
- Побудова деревоподібного індексу: перетворення PDF/Markdown документів на ієрархічне JSON-дерево, подібне до «змісту, оптимізованого для LLM»
- Пошук на основі міркувань у дереві: LLM використовує міркування для навігації по дереву на основі запитання, визначає відповідні вузли, витягує вміст і генерує відповіді

3. Розбір основних модулів
3.1 Конвеєр обробки PDF
Конвеєр обробки PDF PageIndex організований функцією tree_parser(), а основний процес включає: виявлення змісту (три гілки режиму), додавання передмови, перетворення плоского списку на ієрархічне дерево, рекурсивне подрібнення великих вузлів, збагачення вузлів, виведення структури JSON-дерева.
Три режими обробки:
- process_toc_with_page_numbers (є зміст + є номери сторінок): LLM використовує оригінальний зміст для перетворення на структурований JSON, зіставляючи логічні номери сторінок з фізичними номерами сторінок
- process_no_toc (немає змісту): LLM безпосередньо виводить ієрархічну структуру з основного тексту
- process_toc_no_page_numbers (є зміст, але немає номерів сторінок): витягує структуру, а потім виводить і доповнює фізичні номери сторінок
3.2 Модель даних деревоподібної структури
Кожен вузол у дереві містить такі поля: title, node_id, start_index, end_index, summary, prefix_summary, text, nodes (масив дочірніх вузлів) тощо.
3.3 Механізм пошуку на основі міркувань
Етап пошуку не залежить від жодних векторних обчислень. LLM отримує запитання користувача та структуру дерева документа, міркує на основі заголовків і анотацій вузлів і виводить свій «процес мислення» та список відповідних node_id. Потім система витягує повний текст відповідних вузлів з node_map на основі node_id, об'єднує їх у контекст і передає LLM для створення остаточної відповіді.

4. Основні переваги дизайну
- Архітектура без векторів: не потребує моделі embedding і векторної бази даних, що знижує вартість інфраструктури та спрощує розгортання
- Збереження природної структури документа: організація вмісту за розділами/підрозділами/підрозділами, властивими документу, щоб уникнути втрати контексту між чанками
- Пояснюваність пошуку: кожен пошук повертає повний ланцюжок міркувань, що має очевидні переваги в сценаріях з високими вимогами до відповідності
5. Результати оцінювання
Mafin 2.5 — це система запитань і відповідей щодо фінансових документів на основі PageIndex. На FinanceBench (еталонний тест QA для фінансових документів) він досяг 98,7% точності, що значно перевищує Perplexity (45%) і GPT-4o (31%).

6. Сценарії застосування
Підходить для: довгих документів з чіткою ієрархічною структурою (фінансові звіти, закони та нормативні акти, навчальні матеріали, посібники), обсягом від десятків до сотень сторінок
Не підходить для: документів без структурованого вмісту, сканованих копій без OCR, документів, що складаються переважно з таблиць/діаграм, сценаріїв, що потребують миттєвої відповіді за мілісекунди
7. Висновок
Основний внесок PageIndex полягає в пропонуванні практичної парадигми RAG без векторів: використання природної структури документа для побудови деревоподібного індексу, заміна пошуку векторної подібності міркуваннями LLM. Це рішення чудово працює в сценаріях професійних довгих документів з чіткою ієрархічною структурою, а його пояснюваність і можливість аудиту значно перевершують традиційні рішення.





