Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Yucan Guo и соавторы представили R2Adapter для гибридных RAG-систем — работа опубликована как препринт, не проходивший рецензирования. По замерам авторов, адаптер сокращает использование графового RAG вплоть до 59% при сопоставимой точности ответов. Результат важен командам, которые уже используют графовый поиск или оценивают его издержки для продукта с неоднородными запросами.
Что сделали
Обычный RAG ищет подходящие фрагменты текста и передаёт их языковой модели. Такой конвейер сравнительно прост, но хуже справляется с вопросами, где нужно связать несколько сущностей или последовательно собрать факты из разных документов. Графовый RAG сначала представляет знания как сущности и связи, а затем выполняет поиск по этой структуре; это помогает многошаговым запросам, но увеличивает вычислительные расходы.
R2Adapter ставится перед двумя готовыми конвейерами и состоит из маршрутизатора и переписчика запросов. Маршрутизатор на основе DeBERTa-v3-base оценивает, какой способ поиска подходит конкретному вопросу. Если преимущество графа недостаточно выражено, запрос уходит в обычный RAG; авторы намеренно считают такую ветку предпочтительной при равных оценках.
Для обучения маршрутизатора авторы автоматически разметили вопросы из сложной части HotpotQA. Обычный RAG с NV-Embed-v2 и графовый HippoRAG 2 извлекали документы, после чего подходящим признавался вариант с более высокой позицией релевантных материалов. В обучающем наборе было 14 969 запросов, причём графовый вариант получил предпочтение для 12,2% из них.
Вторая часть адаптера работает только после выбора графового RAG и только при низкой уверенности маршрутизатора. Языковая модель переписывает вопрос как цепочку отношений между сущностями, обозначая неизвестные промежуточные сущности заполнителями. Исходный и структурированный запросы объединяются и передаются графовому поиску. Поэтому R2Adapter не устраняет обращения к LLM полностью: он исключает их из маршрутизации, но использует для выборочного переписывания.
Что показали
Авторы проверили подход на HotpotQA, 2WikiMultihopQA и MuSiQue — наборах вопросов, требующих объединять несколько фактов. R2Adapter подключали к GraphRAG и HippoRAG 2, а в качестве обычного поиска использовали NV-Embed-v2.
В связке с HippoRAG 2 адаптер получил средний F1 66,9 против 65,8 у постоянно включённого HippoRAG 2. F1 здесь показывает совпадение ответа с эталоном с учётом точности и полноты по токенам. Разница невелика: результат работы следует читать как сохранение качества при снижении числа дорогих обращений к графу, а не как заметное улучшение ответов.
При подключении к GraphRAG в обычный RAG в среднем направлялось около 45% запросов, при этом качество ответов по замерам авторов не ухудшилось. Их маршрутизатор также показывал более стабильные результаты, чем правила по числу именованных сущностей и классификация запросов отдельной LLM.
Переписывание повышало точность на подмножестве запросов, уже направленных к графу, однако выигрыш переставал расти при обработке всех таких вопросов. Это поддерживает выбранную схему: переписывание полезно как дополнительная операция для неуверенных решений, а не как обязательный этап.
Ограничения
Маршрутизатор обучали на одном источнике вопросов и автоматических метках, полученных при сравнении конкретного текстового поиска с HippoRAG 2. Авторы предупреждают, что после замены плотного поисковика маршрутизатор может потребовать переобучения. Проверка охватывает три академических набора многошаговых вопросов и два графовых конвейера; экспериментов на производственных запросах, диалогах, закрытых базах знаний и смешанных языках в работе нет.
Сравнение показывает долю обращений к графу и качество ответов, но из представленных результатов нельзя получить универсальную стоимость запроса: она зависит от графового конвейера, генератора, оборудования и инфраструктуры. Выборочное переписывание требует отдельного вызова LLM, а его затраты не сведены с экономией от пропущенного графового поиска в единую денежную метрику. Кроме того, адаптер не отменяет построение и обновление графового индекса — он сокращает его использование во время обработки запросов.
Что это значит
Для команды с уже работающими обычным и графовым RAG эта работа меняет план реализации: вместо постоянного запуска графа имеет смысл поставить перед конвейерами небольшой обучаемый классификатор. Метки для него можно получать из фактического качества поиска двух веток, а порог выбирать с учётом более дорогой ошибки — отправки действительно сложного вопроса в обычный поиск.
Переписывание стоит отделять от маршрутизации. Первый этап может выполняться небольшой моделью-классификатором, а вызов LLM нужен лишь для неуверенных запросов, уже назначенных графовой ветке. В продукте придётся отдельно измерять долю таких вызовов, задержку и итоговую точность: работа подтверждает полезность схемы на тестах, но не даёт готового порога для другой предметной области.
Если графового RAG в системе ещё нет, результаты сами по себе не обосновывают его внедрение. R2Adapter снижает эксплуатационную нагрузку существующего гибридного конвейера, но не устраняет стоимость построения графа и подготовки обучающих меток. Поэтому практический вывод ограничен: архитектура выглядит подходящей для оптимизации уже выбранного графового решения, а не как самостоятельный аргумент в пользу перехода на него.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
