Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
LLM научили пересматривать план рассуждения после каждого промежуточного ответа, не дообучая модель и не готовя примеры под конкретную задачу. В препринте University of Illinois Chicago, который не рецензировался и где приведённые числа получили сами авторы, ReHoPER обошёл самосогласованность и другие базовые методы в большинстве сопоставимых настроек, особенно на сложных композиционных задачах. Для продуктовой команды это меняет не модель, а контур обработки запроса: качество можно поднять серией управляемых вызовов, заплатив дополнительными вычислениями и задержкой.
Как ReHoPER планирует только ближайший шаг
ReHoPER переносит в работу LLM планирование со скользящим горизонтом (receding-horizon planning). Вместо полного плана до финального ответа модель составляет короткий список промежуточных вопросов, выполняет только ближайший подходящий шаг и затем планирует заново.
Сначала модель отвечает на исходный вопрос напрямую. После этого запускаются независимые траектории рассуждения. В каждой траектории модель получает исходный контекст и накопленную историю, предлагает промежуточные вопросы и выбирает первый, на который ещё не отвечала.
Остальные вопросы из списка отбрасываются. Модель отвечает на выбранный вопрос, добавляет пару «вопрос — ответ» в историю и снова пробует решить исходную задачу. Затем она строит новый список уже с учётом найденной информации: прежний план может измениться, если ответ закрыл часть задачи или открыл более полезное направление.
Траектория заканчивается, когда модель перестаёт предлагать новые вопросы или достигает заданного предела шагов. В итоговое голосование попадают прямой ответ и все варианты ответа на исходный вопрос, полученные после промежуточных шагов. Побеждает самый частый вариант; ничью алгоритм разрешает по алфавиту.
От обычной цепочки рассуждений метод отличается возможностью менять маршрут. От Self-Discover — тем, что не фиксирует структуру перед решением. От самосогласованности — тем, что расходует вычисления не только на независимые финальные ответы, но и на поиск недостающих промежуточных фактов.
Где перепланирование улучшило результат
Метод проверяли на трёх семействах задач. MuSR требует собирать рассеянные по длинному тексту подсказки и ограничения, MoreHopQA — связывать несколько фрагментов доказательств, а iLLC — выполнять контролируемую последовательность операций над буквами в словах. Последний набор позволяет отдельно усложнять саму операцию и длину цепочки.
Эксперименты охватили модели семейств Llama, Gemma, Phi, Mistral, gpt-oss и Qwen3, включая режим Qwen3 с явным рассуждением. ReHoPER запускали с одинаковыми общими инструкциями и сочетали с прямым ответом, пошаговым рассуждением и предварительным планом. Специальные размеченные примеры для задач не использовали.
Основная конфигурация запускала шесть траекторий глубиной до десяти шагов при температуре 0,5. Она давала до 61 варианта ответа для голосования — столько же, сколько базовая самосогласованность. Это выравнивает число голосов, но не полную стоимость: ReHoPER отдельно вызывает модель для планирования, ответа на промежуточный вопрос и повторного решения исходной задачи.
ReHoPER оказался точнее сопоставимых методов в большинстве комбинаций моделей, задач и формата ответа. Самый заметный выигрыш пришёлся на варианты iLLC с более сложной композицией. Дополнительное простое семплирование финальных ответов редко давало тот же эффект: преимущество связано со структурой вычислений, а не только с их количеством.
Границы проверки проходят по задачам, где правильный ответ можно получить через цепочку промежуточных операций или свидетельств. Работа сравнивает методы на тестовых наборах рассуждений, а не на производственных диалогах, агентных сценариях или запросах с внешними инструментами.
Когда команде стоит менять архитектуру
Работа меняет планы команд, которые уже выбрали модель, но не получают стабильных ответов на многошаговых задачах. Перед дообучением можно проверить более дешёвую в разработке гипотезу: оставить веса модели без изменений и добавить оркестратор, который хранит историю, запускает независимые траектории и собирает голоса.
Такой пилот имеет смысл для анализа документов, сопоставления ограничений, расследования причин и других процессов, где один пропущенный шаг портит результат. На простых вопросах ожидаемая польза ниже: наибольший выигрыш в работе появился там, где требовалось выполнить больше связанных операций.
Сравнивать ReHoPER с текущим решением нужно при одинаковом бюджете задержки и токенов, а не только при одинаковом числе финальных вариантов. Метод добавляет несколько последовательных вызовов внутри каждой траектории, поэтому ограничение по времени ответа может оказаться важнее прироста точности. Параллельный запуск траекторий сокращает ожидание, но не уменьшает общий объём вычислений.
Для внедрения не требуется менять модель или собирать обучающий набор, однако появляется новый прикладной слой: нужно разбирать промежуточные вопросы, отсекать повторы, ограничивать глубину и надёжно извлекать финальные ответы. Поэтому ReHoPER стоит рассматривать как схему вычислений для задач со сложной композицией, а не как универсальную замену обычному запросу к LLM.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
