Коротко
Исследование показывает: главный недостаток GraphRAG — не просто лишние ссылки, а зависимость их вреда от типа данных. Поэтому сравнивать RAG-архитектуры на одном корпусе и с одним LLM-судьёй рискованно.
У GraphRAG есть проблема, которая не исчезает при смене модели эмбеддингов или корпуса: он систематически перегружает ответы цитатами. Но последствия этого поведения зависят от данных — на одном типе документов точность ответа резко падает, на другом лишние ссылки почти не мешают.
Авторы проверили три варианта одновременно: два embedder’а — от локального e5-small до Azure text-embedding-3-small, два корпуса и двух LLM-судей — GPT-5.4 и GPT-4.1. Всего получилось 4 440 запусков в основной матрице, 600 кросс-корпусных запусков и 1 200 парных оценок соответствия ответов источникам.
Картина с цитатами оказалась стабильной: GraphRAG выдавал от 11 до 15 идентификаторов источников на ответ. При этом precision цитирования оставалась на уровне 0,12–0,23, а recall — 0,68–0,87. Иными словами, система часто находила нужный материал, но прикладывала к ответу слишком много ссылок, включая слабосвязанные.
Вот где начинается важная оговорка. В корпусе требований DO-178C, где связи между сущностями типизированы, faithfulness GraphRAG падала с 74% до 40% при переходе между hop’ами. На цепочках абзацев Wikipedia из MuSiQue произошло обратное: показатель вырос с 42% до 58%, потому что лишние абзацы всё ещё оставались тематически подходящими.
Отсюда практический вывод: у RAG нет безусловного победителя. На двухшаговых вопросах в DO-178C лучше показал себя обычный подход, а в MuSiQue — GraphRAG; выбор сохранился при использовании обоих embedder’ов. То есть устойчивость к смене embedder’а ещё не означает устойчивость метода вообще — решающим может оказаться сам корпус.
Есть и отдельная проблема с оценкой. Один и тот же LLM-судья мог менять вердикт при смене состояния retrieval: self-kappa для GPT-5.4 между embedder’ами составила всего 0,137, а решение изменилось в 41% случаев. Авторы также обучили router, который по плотным embeddings классифицировал число hop’ов с macro-F1 0,86, но это не отменяет необходимости проверять саму методику оценки.
Ограничения здесь существенные: выводы получены на двух корпусах, двух embedder’ах и паре судей, а не на всех возможных RAG-системах и данных. Поэтому работа доказывает не то, что GraphRAG плох, а то, что заявления о его превосходстве без проверок на разных корпусах и судьях слишком хрупкие.
Если вы выбираете RAG для своего продукта, готовы ли вы считать систему лучше после одного удачного теста на одном наборе документов? Источник: cs.CL updates on arXiv.org