Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Многошаговый RAG может тратить меньше токенов, если после каждого поиска решает, каких доказательств не хватает и стоит ли продолжать. В препринте University of Illinois Urbana-Champaign, который не прошёл рецензирование и содержит замеры самого автора, BeliefRAG использовал на 39% меньше токенов, чем поиск с фиксированным числом итераций. Для команд это аргумент в пользу отдельного контроллера поиска вместо нескольких независимых порогов в цепочке.
Состояние связывает сигналы из разных шагов
Адаптивный RAG меняет глубину поиска по ситуации: может запросить новые документы, переписать запрос, проверить найденное или сразу ответить. Обычно каждое действие запускает отдельный сигнал — низкая уверенность, слабая релевантность или противоречие. Проблема появляется, когда поиск занимает несколько шагов и локальные сигналы перестают описывать общую ситуацию.
Одинаково низкая уверенность может означать разные вещи. Иногда не найден второй факт, иногда два документа противоречат друг другу, а иногда следующий запрос почти наверняка вернёт то же самое. Простое правило «уверенность низкая — искать ещё» во всех случаях расходует бюджет одинаково, хотя системе нужны разные действия.
BeliefRAG после каждого шага обновляет состояние доказательств. Оно хранит достаточность найденного, надёжность источников, наличие конфликта, неопределённость, пробелы и уже потраченную долю бюджета. Релевантность, поддержка ответа и новизна новых документов служат входными сигналами, но не заменяют состояние целиком.
Контроллер сначала измеряет текущий набор документов, затем обновляет состояние и выбирает действие: искать, переписать запрос, проверить доказательства, ответить, остановиться или отказаться от ответа. Набор документов при этом не только растёт. Проверка может удалить слабый фрагмент, после чего система формулирует другой запрос и ищет замену.
Отдельный калиброванный показатель оценивает, сможет ли используемая модель ответить с текущим контекстом и заданной формулировкой запроса. Если ответ уже доступен, поиск заканчивается. Если данных недостаточно, контроллер продолжает только тогда, когда следующий запрос может изменить ситуацию; при низкой новизне он сначала переписывает запрос.
Сравнение проводили в общем стенде: контроллеры использовали одинаковые корпус, поиск, проверяющую модель, генератор, подсказку и бюджет. Метод проверили на шести наборах вопросов с gpt-oss-120b и Qwen3-32B, по 100 вопросов из каждого набора. В выборку вошли как многошаговые задачи, так и открытые фактологические вопросы.
Экономию даёт замена слабых доказательств
С gpt-oss-120b средний F1 по токенам составил 0,572 против 0,555 у поиска с фиксированными итерациями. Эта метрика сравнивает токены в ответе модели с токенами в эталонном ответе: результат вырос, хотя контекст стал короче.
На Qwen3-32B сохранилась та же картина: F1 достиг 0,552 против 0,523, а расход токенов снизился на 35%. Перенос на вторую модель показывает, что эффект не сводится к особенностям одного генератора, хотя настройки контроллера всё равно зависят от используемой модели и подсказки.
Разбор компонентов показал, что основную прибавку даёт не удаление плохих документов само по себе. Рабочая последовательность выглядит так: обнаружить конфликт или слабое доказательство, удалить проблемный фрагмент, переписать запрос и получить замену. После одного удаления контекст становится чище, но необходимого факта в нём всё ещё нет.
Калиброванная оценка возможности ответить помогает вовремя остановить поиск. Без неё система либо продолжает собирать уже ненужные документы, либо принимает решение по сигналу, значение которого меняется между наборами данных. Калибровка выровняла смысл порога на близких источниках, но при переходе от материалов Wikipedia к веб-фрагментам качество самого сигнала снизилось.
Что менять в архитектуре RAG
Работа меняет планы прежде всего для систем, где вопрос требует нескольких поисковых шагов, а стоимость контекста заметна в общем бюджете. Добавлять ещё один локальный порог к существующей цепочке недостаточно: контроллеру нужен объект состояния, который переживает шаги и объясняет, почему система ищет снова, меняет запрос или заканчивает.
Практическая реализация может начинаться с трёх решений. Система должна хранить текущие доказательства отдельно от полной истории, разрешать проверке удалять документы и записывать причину каждого действия. Без такого журнала нельзя понять, экономит ли контроллер токены за счёт правильной остановки или просто преждевременно сдаётся.
Переносить все измерения BeliefRAG буквально не стоит. Анализ показал, что несколько координат состояния коррелируют между собой, а наиболее полезным рабочим сигналом стала возможность ответить. Для первой версии разумнее проверить достаточность, конфликт, новизну и ожидаемую пользу нового поиска, а остальные признаки добавлять только после абляции на собственных данных.
Порог возможности ответить нельзя считать универсальной константой. Он связан с генератором, подсказкой и типом источника, поэтому его нужно подбирать на данных, похожих на рабочий поток, и заново проверять после смены корпуса. В самой работе использован лексический поиск и короткие ответы на вопросы; выводы о контроллере не переносятся автоматически на агентные процессы, длинные отчёты и корпоративные базы с другой структурой документов.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
