Предложен DeFT-RAG: многошаговые вопросы через подвопросы и кэш ответов

Retrieval-augmented generation (RAG, генерация с поиском по документам) позволяет языковой модели отвечать на вопросы, подтягивая нужные фрагменты из большого корпуса. Слабое место подхода, многошаговые вопросы: чтобы ответить, надо связать факты из нескольких документов через промежуточные сущности, которых в самом вопросе нет. Авторы препринта считают, что графовые RAG-методы делают один поиск по сущностям, названным в вопросе, и потому редко восстанавливают всю цепочку доказательств. Итеративные методы восстанавливают её шаг за шагом, но их точность ограничена тем, сколько разных задач они взваливают на модель: планировать подвопросы, определять их зависимости, переписывать их по мере поступления ответов и помнить, что уже известно.
Для этого предложен DeFT-RAG, фреймворк из трёх компонентов. Первый: на каждом шаге генерируется один самодостаточный подвопрос, по исходному вопросу и уже отвеченным подвопросам вместе с ответами (парами «вопрос, ответ»). Каждый подвопрос прямо называет все сущности, о которых спрашивает, поэтому не нужно ни планировать, ни отслеживать зависимости, ни переписывать вопросы, а модель решает одну мелкую задачу за раз. Второй: оставшуюся работу выносят за пределы языковой модели, таблицу пар «вопрос, ответ», где хранится известное, обновляют по правилам, а решения вида «да/нет» принимает дообученная лёгкая модель-решатель. Третий: пары «вопрос, ответ» кэшируются, и ответ используется повторно, если в другом вопросе встретился подвопрос с тем же смыслом.
Проверка шла на MuSiQue, 2WikiMultiHopQA и HotpotQA с двумя базовыми моделями, gpt-4o-mini и Qwen3.6. По утверждению авторов, DeFT-RAG показал лучшую точность среди тринадцати базовых методов и при этом передаёт модели меньше входных токенов, чем любой другой итеративный метод. В эксперименте с общим кэшем на 1000 вопросов MuSiQue 23,1% подвопросов были закрыты из кэша, что сократило число обращений к языковой модели на 12,9% без потери точности.
Ключевые факты
- DeFT-RAG генерирует по одному самодостаточному подвопросу за шаг: в нём названы все сущности, поэтому не нужны планирование, отслеживание зависимостей и переписывание.
- Учёт известного ведётся вне языковой модели: таблица пар «вопрос, ответ» обновляется по правилам, а решения «да/нет» принимает дообученная лёгкая модель.
- Заявлена лучшая точность среди тринадцати базовых методов на MuSiQue, 2WikiMultiHopQA и HotpotQA с gpt-4o-mini и Qwen3.6 в роли базовой модели.
- Входных токенов для модели уходит меньше, чем у любого другого итеративного метода.
- Общий кэш на 1000 вопросов MuSiQue закрыл 23,1% подвопросов и сократил число обращений к модели на 12,9% без снижения точности.
Почему это важно
Многошаговые вопросы остаются слабым местом RAG: цепочку фактов из разных документов одним поиском не собрать, а итеративные методы перегружают модель вспомогательными задачами. DeFT-RAG предлагает упростить работу модели до одной узкой задачи за шаг и вынести учёт знаний наружу. Отдельный сюжет, повторное использование ответов: если вопросы похожи по подвопросам, часть обращений к модели можно сэкономить.
Кому это важно
Тем, кто строит системы вопросов и ответов по большим корпусам документов и сталкивается со сложными вопросами, требующими нескольких «прыжков» между источниками. Также исследователям итеративного и графового RAG, для которых тринадцать базовых методов на трёх известных бенчмарках, ориентир для сравнения.
Как это применить
Из описания можно взять три идеи: формулировать каждый подвопрос так, чтобы в нём были названы все сущности; держать состояние («что уже известно») в таблице с правилами обновления, а не в рассуждениях модели; кэшировать пары «вопрос, ответ» с проверкой на совпадение смысла подвопросов. Готовой реализации по тексту не видно, поэтому для практического использования придётся реализовывать подход самостоятельно.
Можно ли доверять
Это препринт, а в источнике, только аннотация, поэтому все результаты, заявления авторов. Конкретных значений точности ни для DeFT-RAG, ни для базовых методов в тексте нет, размер отрыва от них не назван, а тринадцать базовых методов не перечислены. Выигрыш по входным токенам тоже не измерен числом.
Риски и подводные камни
Цифры 23,1% и 12,9% относятся только к настройке с 1000 вопросов MuSiQue; для 2WikiMultiHopQA и HotpotQA они не приведены. База, от которой отсчитано сокращение обращений на 12,9%, не названа. Что за лёгкая модель-решатель и каков её размер, в тексте не сказано. Оценка проведена с двумя базовыми моделями, так что перенос на другие модели остаётся непроверенным.