StructRAG (ICLR 2025): выбор правильной структуры документа превосходит GraphRAG на 28 пунктов

Основная претензия к RAG в продакшене заключается в том, что поиск — это слишком грубый инструмент, когда релевантные факты разбросаны по десяткам документов в несовместимых форматах. StructRAG (Li et al., ICLR 2025) решает эту проблему напрямую, преобразуя извлеченный текст в подходящую для задачи структуру — таблицу, граф, каталог, алгоритм или обычный фрагмент (chunk) — перед этапом рассуждения. Метод мотивирован теорией когнитивистики: люди естественным образом перерабатывают сырую информацию в структурированные представления при решении сложных логических задач. Независимо от того, является ли эта формулировка метафорой или реальным механизмом, эмпирические данные заслуживают тщательного изучения.

Статья

StructRAG предлагает конвейер, работающий во время инференса и состоящий из трех модулей. Во-первых, гибридный маршрутизатор структур (Qwen2-7B-Instruct, дообученный с помощью DPO на 900 синтетических парах предпочтений) предсказывает, какой из пяти типов структур лучше всего подходит для входящего вопроса и его документов. Во-вторых, структуризатор разрозненных знаний (Qwen2-72B-Instruct) переписывает извлеченные фрагменты в выбранный формат. В-третьих, утилизатор структурированных знаний разбивает вопрос на подвопросы, извлекает соответствующие структурированные фрагменты и генерирует окончательный ответ. Пять типов структур: таблица (статистические сравнения), граф (многоходовые цепочки, закодированные в виде триплетов субъект–отношение–объект), алгоритм (задачи планирования, записанные в виде псевдокода), каталог (саммаризация, иерархическая нумерация) и фрагмент (простой одноходовый поиск, стандартный запасной вариант RAG).

Авторы проводят оценку в основном на бенчмарке Loong (EMNLP 2024 Oral), предназначенном для многодокументного QA и охватывающем финансовые отчеты, юридические дела и научные статьи с объемом входных данных от 10 тыс. до 250 тыс. токенов по четырем типам задач: Spotlight Locating, Comparison, Clustering и Chain of Reasoning.

Ключевые идеи

• Маршрутизатор, обученный с помощью DPO, достигает точности 94,38% при выборе типа структуры по сравнению с 50,04% в режиме zero-shot с Qwen2-72B-Instruct — решение о маршрутизации является наиболее критичным компонентом. Удаление маршрутизатора снижает общую оценку LLM с 60,38 до 45,33.
• На самом сложном уровне длины документов (200–250 тыс. токенов) StructRAG набирает 51,42 балла против 28,92 у Long-Context и 29,29 у RAG — разрыв в ~22 пункта увеличивается по мере роста контекста. Стандартный подход «просто засунуть всё внутрь» резко деградирует, в то время как показатели StructRAG снижаются более плавно.
• GraphRAG, несмотря на навязывание структуры, набирает в среднем 40,82 балла по оценке LLM на Loong против 69,43 у StructRAG, и при этом тратит 217,1 минуты на запрос против 9,7 минут у StructRAG. Предварительное построение глобального графа знаний медленнее и менее точно, чем выбор правильного формата по запросу.
• На Podcast Transcripts (открытая саммаризация) StructRAG достигает 95,75% доли побед в парных сравнениях над Long-Context, что позволяет предположить, что структурированный синтез превосходит подходы с полным контекстом даже на менее структурированном исходном материале.
• Оценки точного совпадения (exact-match, EM) последовательно отстают от оценок судей-LLM, потому что структуризация меняет поверхностные формулировки (например, "$1,308,463" становится "138463" в ячейке таблицы), создавая систематическую проблему несовпадения токенов, которая занижает результаты автоматической оценки.

Что подтверждается, а что — нет

Основной результат реален, а история с анализом влияния компонентов (ablation study) прозрачна: маршрутизация важнее всего, за ней следует структуризация, а затем — использование. Улучшение на длинных документах — самый сильный вывод: 22 пункта на 200 тыс. токенов — это не шум.

Тем не менее, у меня есть три замечания. Во-первых, охват бенчмарков невелик. StructRAG сообщает только о Loong и Podcast Transcripts. Стандартные многоходовые бенчмарки (HotpotQA, 2WikiMultiHopQA, MuSiQue, NQ) отсутствуют, что делает невозможным оценку того, как StructRAG соотносится с большим объемом предыдущих исследований по извлечению данных на этих установленных наборах. Рецензенты ICLR, вероятно, поднимали этот вопрос; в опубликованной версии статьи прямого ответа нет.

Во-вторых, оценочной моделью является GPT-4. Оценка по принципу «LLM-как-судья» подвержена предвзятости к длине и стилистическим предпочтениям, которые могут благоприятствовать результатам того же процесса структуризации, особенно если судья обучался на похожих структурированных текстах. Метрика EM служит корректировкой, но авторы представляют ее как ограничение метрики, а не как доказательство проблемы метода.

В-третьих, StructRAG тестируется с мощной базовой моделью (Qwen2-72B-Instruct для структуризатора и утилизатора). Неясно, какая часть выигрыша обеспечивается маршрутизацией, а какая — просто вызовом мощной модели для переписывания и обобщения. Исследование абляции против базовой линии с прямым ответом модели того же размера могло бы прояснить ситуацию, но оно не представлено.

Почему это важно для финансового ИИ

Учетные книги Beancount являются каноническим примером проблемы «разрозненной информации». Один вопрос по сверке — «почему мои чистые активы упали в третьем квартале?» — может потребовать чтения транзакций по трем счетам, перекрестной сверки с отчетом о балансе и отслеживания многоэтапной цепочки корректировок. Это почти один в один соответствует типам структур StructRAG: таблицы для сравнения балансов, графы для цепочек транзакций, каталоги для сводок за период.

Идея маршрутизации особенно применима. Агент Beancount, ориентированный на запросы, не должен всегда просто сбрасывать фрагменты текста в контекст; он должен сначала спросить, какой формы требует ответ. Вопрос о тренде баланса требует таблицы. Вопрос «объясните эту цепочку возмещений» требует графа. Вопрос «подведите итоги расходов за этот год» требует каталога. Явное встраивание этого решения о маршрутизации — даже с помощью небольшой модели — может значительно сократить галлюцинации и путаницу в цифрах, которые преследуют нынешние попытки создания QA для учетных книг.

История с задержкой в 217 против 9,7 минут также важна на практике. Для интерактивного агента Beancount затраты на предварительную индексацию GraphRAG непомерно велики для часто обновляемых книг; подход StructRAG на этапе вывода лучше подходит для сценария с частой записью и редкими запросами.

Предостережение: структуризатор StructRAG требует вызова большой LLM при каждом запросе. Для длинных историй транзакций стоимость такого инференса может стать значительной. Эффективная по токенам структуризация — возможно, с использованием меньшей дообученной модели — остается открытым инженерным вопросом.

Что почитать дальше

• From Local to Global: A Graph RAG Approach to Query-Focused Summarization (Edge et al., 2024, arXiv:2404.16130) — Microsoft GraphRAG использует сводки сообществ для глобальных запросов; понимание того, где структуризация во время вывода StructRAG превосходит предварительную индексацию GraphRAG, является ключевым архитектурным компромиссом.
• FinAuditing: A Financial Taxonomy-Structured Multi-Document Benchmark (arXiv:2510.08886) — тестирует 13 LLM на отчетности XBRL с иерархическими таблицами; прямая проверка того, переносятся ли табличные и каталожные структуры StructRAG на формат структурированной отчетности, на который похожи книги Beancount.
• InvestorBench: A Benchmark for Financial Decision-Making Tasks with LLM-based Agent (arXiv:2412.18174, ACL 2025) — оценивает агентов в реальных задачах принятия финансовых решений, что позволило бы измерить, действительно ли структурированные рассуждения StructRAG помогают качеству последующих решений за рамками точности одноходового QA.