Вы залили в RAG 500-страничный отчет. А он молчит
Вы сделали все по учебнику: разбили PDF на чанки, запустили эмбеддинг-модель, загрузили в векторную базу. Задаете вопрос про "пункт 7.2.3 изменения в налоговом вычете". В ответ - тишина. Или, что хуже, красивая, но абсолютно неверная цитата из преамбулы. Знакомо? Это не баг, это фича классического RAG.
Пока мир гонялся за размерностью векторов и новыми embedding-моделями, одна вещь оставалась слепым пятном: структура. Финансовые отчеты, юридические договоры, технические спецификации - это не мешок слов. Это строгая иерархия: разделы, подразделы, пункты, таблицы, сноски. Векторный поиск эту иерархию стирает. Он превращает документ в "суп из смыслов", где пункт 7.2.3 по смыслу может оказаться ближе к приложению Б, чем к своему собственному разделу 7.
Итог 2025 года: на бенчмарке FinanceBench, который состоит из реальных финансовых документов (отчеты 10-K, проспекты, договоры), лучшие векторные RAG-системы показывали точность не выше 72%. Они справлялись с общими вопросами ("о чем этот отчет?"), но терялись в конкретике ("какая ставка применяется к транзакциям в евро согласно разделу 4.1 договора?").
Три фундаментальные трещины в векторах
Почему же embedding-модели, даже самые мощные на 2026 год (вроде OpenAI text-embedding-3-large или Cohere Embed V3), спотыкаются о сложные документы?
1. Проклятие семантической близости
Эмбеддинги отлично улавливают смысловую близость. "Собака" и "щенок" будут рядом. Но в юридическом документе "Сторона А обязуется" и "Сторона Б обязуется" - это семантически идентичные фразы. Для модели они будут почти одним вектором. Как тогда найти обязательства конкретно Стороны А? Придется встраивать в запрос контекст, а это уже костыль.
2. Игнорирование иерархии
Разбивая документ на чанки фиксированного размера (например, по 512 токенов), вы рубите логические блоки. Определение термина может оказаться в одном чанке, а его применение в другом. При поиске система найдет определение, но пропустит критически важный контекст использования. Это все равно что искать инструкцию к сборке шкафа, просматривая случайные страницы из середины.
3. Слепота к перекрестным ссылкам
"См. пункт 4.5", "как указано в Приложении 2", "в соответствии со ст. 181 ГК РФ". Для человека это навигационные маяки. Для векторного поиска - просто слова. Модель не понимает, что это указатель на другой фрагмент документа, который может содержать ключевую информацию. Она ищет "похожие" слова, а не следует за ссылкой.
PageIndex: если документ - это карта, а не суп
Новый подход, который взорвал FinanceBench в начале 2026 года, называется PageIndex. Его философия проста: не превращай документ в векторы. Работай с его родной структурой. Если документ имеет оглавление - используй его как индекс. Если нет - восстанови иерархию с помощью современной LLM (например, GPT-4o или Claude 3.7 Sonnet).
PageIndex не генерирует эмбеддинги для чанков. Вместо этого он строит многоуровневое дерево документа: Глава -> Раздел -> Подраздел -> Абзац. Каждому узлу присваивается не вектор, а набор ключевых терминов и метаданных (уровень в иерархии, тип контента: текст, таблица, список).
1 Как работает поиск в PageIndex
Когда приходит запрос "ставка НДС для медицинских услуг", система:
- Анализирует запрос: Извлекает ключевые сущности ("НДС", "медицинские услуги") и определяет вероятный тип документа (Налоговый кодекс, пояснительная записка).
- Спускается по дереву: Не ищет по всему документу сразу. Сначала проверяет верхнеуровневые разделы ("Раздел VIII. Федеральные налоги"), затем уточняет ("Глава 21. Налог на добавленную стоимость").
- Применяет точное соответствие: На нижних уровнях использует быстрый лексический поиск (по ключевым терминам) или ультрасовременные sparse-эмбеддинги (как в SPLADE v3), которые лучше ловят точные совпадения терминов, а не смыслы.
- Возвращает контекстный блок: Выдает не случайный чанк, а логически завершенный узел дерева (весь пункт закона со всеми подпунктами).
2 Почему это дает 98.7% на FinanceBench
FinanceBench - это не вопросы в духе "как дела?". Это вопросы, требующие точного извлечения данных: "Какова долгосрочная задолженность компании на 31 декабря согласно таблице 6.2?".
Векторный RAG ищет "похожие" на вопрос тексты. Он может найти абзац, где говорится о долгосрочной задолженности вообще, но пропустить конкретную таблицу. PageIndex же сначала находит раздел "Финансовые обязательства", затем подраздел "Долгосрочная задолженность", а внутри - точную ссылку на "Таблицу 6.2". Это навигация, а не гадание.
| Подход | Точность на FinanceBench | Ключевой принцип |
|---|---|---|
| Классический векторный RAG (с чанками) | 71.5% - 73.2% | Семантическая близость векторов |
| Гибридный поиск (векторы + ключевые слова) | 82.1% - 85.7% | Компенсация слабостей одного метода другим |
| PageIndex (иерархический, без эмбеддингов чанков) | 98.7% | Следование нативной структуре документа |
Где и как применять PageIndex уже сейчас
Не нужно выбрасывать свою векторную базу. PageIndex - это не замена, а специализированный инструмент для специфических задач. Вот где он незаменим:
- Юридический Due Diligence: Анализ сотен договоров при сделке M&A. Вопросы типа "найдите во всех документах пункты о change of control" требуют точности, а не "похожести". Для таких задач идеально подходит браузерный RAG для юристов, где PageIndex обеспечивает точность, а локальность - безопасность.
- Финансовая аналитика: Ежеквартальные отчеты компаний (10-Q, 10-K). Все таблицы имеют жесткую структуру. PageIndex может извлекать данные из конкретной строки и графы.
- Техническая документация: Руководства по API, стандарты (например, ГОСТ). Когда нужно найти описание конкретного параметра или метода.
Для интеграции PageIndex в production-пайплайн, ознакомьтесь с нашей дорожной картой RAG 2026. Там есть этапы внедрения и метрики для A/B1тестирования против вашего текущего решения.
Подводные камни: когда PageIndex не сработает
Как и любой инструмент, PageIndex не серебряная пуля. Его слабые места:
- Хаотичные документы: Если ваш документ - это сплошная простыня текста без заголовков, списков, выделений (например, некоторые старые сканы), восстановить иерархию будет сложно. LLM может ошибиться. Здесь может помочь предварительная обработка моделями компьютерного зрения, которые детектируют структурные элементы на странице.
- Очень общие вопросы: "Перескажите суть этого отчета". Для такого запроса иерархический поиск избыточен. Здесь все еще выигрывает семантический поиск по векторам, который найдет самые "репрезентативные" фрагменты. Лучше использовать гибридную систему, которая выбирает стратегию в зависимости от запроса.
- Стоимость и время индексации: Построение точного иерархического дерева для большого документа (1000+ страниц) с помощью LLM (например, через GPT-4 Turbo) занимает время и стоит денег. Векторная индексация, по сравнению с этим, дешевле и быстрее.
Вопросы, которые вы хотели задать
PageIndex полностью отказывается от эмбеддингов?
Не совсем. На этапе классификации запроса и выбора раздела для поиска могут использоваться легкие эмбеддинги для заголовков или sparse-эмбеддинги. Ключевое отличие: PageIndex не создает эмбеддинги для контентных блоков (чанков). Он использует их только для навигации по верхним уровням структуры. Основная работа идет через лексический поиск и анализ дерева.
Что делать, если в документе нет явной структуры?
Здесь на помощь приходит LLM. Можно дать ей prompt: "Проанализируй следующий текст и разметь его иерархическую структуру: выдели основные темы, подтемы, ключевые определения и примеры". Современные модели, такие как Claude 3.7 Sonnet, справляются с этим удивительно хорошо. Но это добавляет шаг и стоимость к пайплайну.
Можно ли комбинировать PageIndex с векторным поиском?
Абсолютно. Это мощная комбинация. PageIndex обрабатывает точные, фактологические запросы. Векторный поиск берет на себя общие, интерпретационные вопросы. Система-оркестратор (например, на основе архитектуры локального RAG-пайплайна) решает, какой метод использовать первым или как объединить результаты. Такой гибрид закрывает 99% use cases.
Гонка за размерностью векторов в 1536 или даже 8192 измерения подходит к концу. Следующий рубеж - не более "умные" эмбеддинги, а более "зрячие" системы, которые умеют читать документ так, как это делает человек: видя не только слова, но и карту. PageIndex - первый крупный шаг в эту сторону. И если ваш RAG до сих пор путается в трех пунктах договора, возможно, ему просто не дали карту.
Прогноз на 2026-2027: Ожидайте появления open-source библиотек, реализующих принципы PageIndex (иерархический индекс + sparse-эмбеддинги для заголовков) в одном фреймворке. Первые ласточки уже есть в нишевых решениях для финансового сектора. Внедряйте поэтапно, начиная с самых болезненных документов, и меряйте точность, а не только скорость ответа.
