StructRAG (ICLR 2025): Вибір правильної структури документа перевершує GraphRAG на 28 пунктів

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

Стаття

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

Автори оцінюють систему насамперед за допомогою бенчмарку Loong (EMNLP 2024 Oral) — бенчмарку для QA по кількох документах, що охоплює фінансові звіти, юридичні справи та академічні статті, з вхідними даними від 10K до 250K токенів, що охоплюють чотири типи завдань: Пошук ключових моментів (Spotlight Locating), Порівняння, Кластеризація та Ланцюжок міркувань.

Ключові ідеї

• Маршрутизатор, навчений за допомогою DPO, досягає точності 94,38% у виборі типу структури порівняно з 50,04% при використанні Qwen2-72B-Instruct у режимі zero-shot — рішення про маршрутизацію є критично важливим компонентом. Видалення маршрутизатора знижує загальний бал LLM з 60,38 до 45,33.
• На найскладнішому рівні довжини документів (200K–250K токенів) 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, що свідчить про те, що структурований синтез перевершує підходи з повним контекстом навіть на менш структурованих вихідних матеріалах.
• Показники точного збігу (EM) стабільно відстають від оцінок LLM-судді, оскільки структуризація змінює поверхневе формулювання (наприклад, "$1,308,463" стає "138463" у клітинці таблиці), створюючи систематичну проблему невідповідності токенів, яка карає автоматизоване оцінювання.

Що працює, а що — ні

Основний результат є реальним, а історія з абляцією виглядає переконливо: маршрутизація має найбільше значення, потім структуризація, а потім — використання. Покращення при великій довжині документів є найсильнішим висновком — 22 пункти при 200K токенах — це не похибка.

Тим не менш, у мене є три зауваження. По-перше, охоплення бенчмарками є недостатнім. 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 допомагають якості прийняття рішень, окрім простої точності однокрокових відповідей.