StructRAG (ICLR 2025): Изборът на правилната структура на документа побеждава GraphRAG с 28 точки

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

Докладът

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

Авторите извършват оценка предимно чрез бенчмарка Loong (EMNLP 2024 Oral) – бенчмарк за QA върху множество документи, обхващащ финансови отчети, правни казуси и академични статии, с входящи данни от 10 хиляди до 250 хиляди токена, покриващ четири типа задачи: Локализиране на акценти (Spotlight Locating), Сравнение, Клъстеризация и Верига от разсъждения.

Ключови идеи

• Обученият с DPO маршрутизатор достига 94,38% точност при избора на тип структура срещу 50,04% при zero-shot с Qwen2-72B-Instruct — решението за маршрутизация е единственият най-критичен компонент. Премахването на маршрутизатора сваля общия резултат на 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“ става „1308463“ в клетка от таблица), създавайки систематичен проблем с несъответствие на токените, който наказва автоматизираната оценка.

Какво издържа проверката — и какво не

Основният резултат е реален и историята с аблацията е ясна: маршрутизацията е най-важна, следвана от структурирането, следвано от оползотворяването. Подобрението при големи дължини на документите е най-силното откритие — 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 в една стъпка.