Поиск без векторов: дерево документа

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

Есть подход, устроенный иначе на уровне идеи. Документ здесь не режут вовсе: его разбирают в дерево разделов, что-то вроде подробного оглавления с краткими содержаниями. Вместо геометрии близости работает рассуждение: модель смотрит на оглавление и решает, в какой раздел заглянуть, как поступил бы человек, впервые открывший толстый регламент. Отсюда и названия: поиск без векторов (vectorless retrieval), поиск рассуждением (reasoning-based retrieval).

Разобраться в нём полезно, даже если вы останетесь на классическом RAG: он показывает, чего именно не хватает векторному поиску.

Похожесть ещё не релевантность

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

Спросите про регламент выплат «Маркета»: «селлер работает по УСН, покупатель вернул товар после отгрузки, удерживается ли комиссия». Ответ живёт в трёх разных разделах: общее правило комиссии, исключение для возвратов после отгрузки, оговорка про налоговый режим. Ни один из трёх по отдельности не похож на вопрос сильнее, чем десяток соседних абзацев, где слова «комиссия» и «возврат» стоят рядом чаще. Поиск вернёт самое похожее, и ответ соберётся не из тех кусков.

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

Дерево вместо нарезки

Документ разбирают по его собственной структуре: заголовки, разделы, подразделы, приложения. Получается дерево, где каждый узел несёт заголовок, границы в документе, краткое содержание и вложенные узлы. Текст остаётся на месте целыми разделами; ни эмбеддингов, ни векторного хранилища в системе не появляется.

flowchart TB
    DOC["Регламент выплат селлерам: 40 страниц"]
    subgraph T ["Дерево: заголовок, границы, краткое содержание"]
      direction TB
      R["Регламент выплат"]
      N1["1. Сроки перечисления"]
      N2["2. Комиссия"]
      N3["3. Возвраты"]
      N31["3.1 Возврат до отгрузки"]
      N32["3.2 Возврат после отгрузки"]
      R --> N1
      R --> N2
      R --> N3
      N3 --> N31
      N3 --> N32
    end
    Q["Вопрос про комиссию при возврате"]
    PICK["Модель читает оглавление и выбирает ветку"]
    READ["Раздел 3.2 читается целиком"]
    ANS["Ответ со ссылкой на раздел"]
    DOC -->|"разбор структуры, заранее"| T
    Q --> PICK
    T --> PICK
    PICK --> READ --> ANS

Разбор в дерево проходится один раз при загрузке документа, выбор ветки делается на каждый вопрос.

Как модель спускается по веткам

Модели показывают не текст документа, а его оглавление: заголовки узлов с краткими содержаниями. Она выбирает ветку, спускается на уровень ниже, снова выбирает. Если под веткой ответа не нашлось, возвращается и пробует соседнюю. Дойдя до нужного узла, читает раздел целиком и отвечает по нему.

Раздел приходит целым. Оговорка «в этом случае комиссия не удерживается» приезжает вместе с условием, к которому относится, потому что разрез по границе абзаца просто не делался. Половина проблем нарезки снимается тем, что нарезки нет.

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

Что подход выигрывает

Он рассчитан на длинные документы с внятной структурой: те, где человек тоже начал бы с оглавления.

Регламенты, договоры, своды правил. Тот самый регламент выплат, где ответ зависит от нескольких условий из разных разделов.
Спецификации и хендбуки. Руководство по эксплуатации WMS, онбординг-хендбук команды, большая спецификация API.
Вопросы про устройство документа. «В каком разделе описан порядок оспаривания», «чем возвраты в новой редакции отличаются от старой» для фрагментного поиска неудобны, а для дерева обычные.

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

Чем приходится платить

Временем и деньгами. Каждый вопрос стоит несколько обращений к модели: по одному на уровень спуска плюс чтение раздела. Порядок цифр тот же, что у агентного RAG (уровень 5 в Вариантах архитектуры): десятки секунд вместо секунды и в разы дороже.
Масштабом базы. Дерево работает внутри документа. Когда база состоит из тысяч вики-страниц по абзацу каждая, оглавление вырождается, и выбирать документ-кандидат всё равно приходится чем-то другим.
Качеством структуры. Скан без оглавления, выгрузка из чата, страница вики единым полотном без заголовков не дают ничего, что можно разобрать. Сканы дополнительно требуют распознавания текста (OCR), а оно ошибается.
Идентификаторами. Имя таблицы seller_payouts встречается в двенадцати разделах, и по кратким содержаниям это не видно. Гибридный поиск (hybrid search) здесь по-прежнему сильнее.

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

PageIndex: как это выглядит на практике

Самая заметная открытая реализация: PageIndex от VectifyAI, лицензия MIT. Из PDF он строит дерево в JSON: у каждого узла заголовок, идентификатор, диапазон страниц, краткое содержание и вложенные узлы. Дальше по этому дереву идёт поиск рассуждением. Кроме локального запуска есть облачный сервис, REST API и MCP-сервер, то есть дерево можно отдать существующему харнесу инструментом (см. MCP-серверы) и не строить свой конвейер.

Авторы приводят точность 98,7% на FinanceBench, наборе вопросов по годовым финансовым отчётам. Цифра получена вендором на бенчмарке, который идеально ложится на подход: сотни страниц, жёсткое оглавление, вопросы к конкретным разделам. Про поведение на внутренней документации команды разработки она не говорит ничего.

Что дальше

Варианты архитектуры: лестница уровней классического RAG, в стороне от которой стоит эта ветка.
Качество и оценка: как сравнить два подхода на своих вопросах.

Автор учебника: Шахматов Алексей