ReWOO — это подход к рассуждению в больших языковых моделях, при котором модель сначала строит план решения, а уже потом обращается к инструментам и данным. Название расшифровывается как reasoning without observation, то есть «рассуждение без наблюдения» на каждом промежуточном шаге.
Такой подход применяют в задачах, где модели нужно не просто ответить на вопрос, а пройти несколько этапов: собрать факты, использовать внешние инструменты, затем собрать всё в итоговый ответ. Главная идея ReWOO проста: не заставлять модель заново “думать вслух” после каждого действия, если план можно составить заранее.
Содержание статьи
Как работает ReWOO
ReWOO разделяет задачу на три части: планирование, выполнение и финальную сборку ответа. За счёт этого модель тратит меньше токенов и не повторяет один и тот же контекст на каждом шаге.
В типичном сценарии участвуют три модуля. Сначала Planner получает запрос пользователя и строит план: какие данные нужны, в каком порядке их лучше получить и какие инструменты для этого подойдут. Затем Worker выполняет этот план: обращается к API, поиску, базе знаний или другому внешнему инструменту. После этого Solver берёт план и собранные данные, чтобы составить итоговый ответ.
Ключевое отличие здесь в том, что этап рассуждения не перемешан с каждым отдельным действием. Модель не обязана после каждого вызова инструмента снова разворачивать весь предыдущий ход мысли. Это сокращает лишний обмен контекстом и делает процесс более собранным.
Чем ReWOO отличается от ReAct
ReAct работает по схеме «мысль → действие → наблюдение», а ReWOO сначала строит план целиком и только потом исполняет его. Разница кажется небольшой, но на практике она заметно влияет на расход токенов и поведение системы.
В ReAct модель после каждого шага получает результат, переосмысливает его и только затем решает, что делать дальше. Такой цикл удобен в задачах, где ход решения постоянно меняется. Но есть цена: каждый следующий вызов часто требует повторной передачи накопленного контекста, а это увеличивает расход токенов.
ReWOO устроен иначе. Он заранее определяет, какие данные нужно собрать, и передаёт эту работу модулю выполнения. План отделён от наблюдений, поэтому системе не нужно заново прогонять длинную цепочку рассуждений после каждого промежуточного результата.
Пример работы ReWOO на простой задаче
Если пользователю нужен ответ, который зависит от нескольких внешних источников, ReWOO сначала перечисляет нужные данные, а затем запрашивает их серией операций. После этого система формирует общий вывод.
Представим задачу: нужно помочь собраться в поездку с перелётом и последующей дорогой на машине, опираясь на прогноз погоды в нескольких городах и в разные даты. Подход ReAct в такой ситуации обычно разбивает работу на последовательные циклы: сначала запрос по одному городу, потом анализ результата, затем следующий город и снова анализ.
ReWOO действует ровнее. Сначала система определяет, что ей нужны прогнозы для всех точек маршрута и для нужных дней. Потом модуль выполнения обращается к погодным сервисам по этому списку. Иногда такие запросы можно сделать подряд, а в некоторых системах и параллельно. Лишь после этого формируется ответ с рекомендацией по одежде и вещам.
За счёт такого порядка меньше промежуточных «раздумий» и повторов контекста.
Почему ReWOO экономит токены
ReWOO снижает расход токенов, потому что не заставляет модель повторно проговаривать цепочку рассуждений перед каждым обращением к инструменту. Это особенно заметно в многошаговых задачах.
Токен — это единица текста, с которой работает модель. Чем больше токенов передаётся в запросах и ответах, тем выше вычислительные затраты. В схемах, где модель после каждого действия снова получает длинную историю и продолжает рассуждать, расход быстро растёт.
У ReWOO этого узкого места меньше. План составляется заранее, а этап выполнения не требует постоянных дорогих вызовов модели ради промежуточного «мышления». Поэтому подход часто оказывается выгоднее в задачах с понятной структурой: собрать данные, сопоставить их, выдать вывод.
Какие преимущества даёт ReWOO
Главные плюсы ReWOO — экономия токенов, устойчивость к сбоям инструментов и более предсказуемый ход выполнения. Подход полезен там, где заранее понятно, какие сведения нужны для ответа.
- Меньше лишних вызовов модели. План создаётся один раз, а не пересобирается после каждого действия.
- Лучше контроль над процессом. Видно, какие данные система собирается получить и зачем.
- Более стабильная работа при сбоях. Если один инструмент не ответил, общий план не исчезает.
- Удобство для повторяемых сценариев. Особенно там, где задачи похожи по структуре.
Есть ещё один важный момент. Если внешний инструмент дал сбой, система на базе ReAct может зациклиться на одной и той же операции. У ReWOO модуль выполнения может продолжить работу по остальным пунктам плана, а модуль сборки ответа — выдать частичный, но полезный результат.
Какие ограничения есть у ReWOO
ReWOO подходит не для всех задач. Он слабее там, где решение нельзя разумно спланировать заранее и где ход работы должен меняться после каждого нового факта.
Если задача исследовательская, с большим числом неожиданных поворотов, жёсткий предварительный план может быстро устареть. Это бывает при отладке кода, анализе нестандартных ошибок, поиске причин непредсказуемого поведения системы. В таких случаях ценнее схема, которая умеет гибко реагировать на каждое новое наблюдение.
Именно поэтому ReWOO обычно рассматривают не как замену всем остальным подходам, а как подходящий инструмент для определённого класса задач. Когда заранее известен тип нужных данных и шаги решения, он показывает себя лучше. Когда задача требует постоянной импровизации, его преимущества уменьшаются.
Где ReWOO уместен, а где нет
ReWOO хорошо работает в регулярных многошаговых сценариях, а хуже — в открытых и плохо предсказуемых задачах. Ориентир простой: если путь к ответу можно набросать заранее, подход обычно уместен.
| Сценарий | Подходит ли ReWOO | Почему |
| Сбор данных из нескольких источников | Да | Можно заранее определить список запросов и порядок действий |
| Ответы на вопросы с понятной структурой | Да | Есть предсказуемый набор шагов и источников данных |
| Маршруты, расписания, погодные сводки | Да | Нужно собрать несколько фактов и объединить их в вывод |
| Отладка Python-кода | Нет | Каждое исправление может породить новую ошибку и поменять ход решения |
| Исследовательский анализ с неожиданными находками | Скорее нет | План быстро теряет актуальность из-за новых вводных |
Как внедряют ReWOO в ИИ-системы
ReWOO можно реализовать как отдельный шаблон работы модели, где этапы планирования, выполнения и синтеза ответа разделены логически или архитектурно. Для этого не всегда нужна сложная инфраструктура, но в прикладных системах её обычно используют.
Официальная реализация подхода была описана исследователями в 2023 году и опубликована на GitHub. Для построения подобных процессов также применяют фреймворки вроде LangGraph и LangChain. В них удобно разделять систему на узлы или этапы, где один компонент строит план, другой вызывает инструменты, а третий формирует ответ.
Подобную логику можно воспроизвести и на уровне промпта. Модели задают инструкцию сначала составить пошаговый план, указать нужные внешние инструменты и только затем переходить к получению данных. Это уже приближает поведение системы к ReWOO, даже если под капотом нет отдельного оркестратора модулей.
Как выглядит базовый процесс ReWOO
В основе ReWOO лежит последовательность из трёх шагов: составить план, собрать доказательства, собрать финальный ответ. Эта схема повторяется от задачи к задаче.
- Понять запрос пользователя. Система выделяет цель, ограничения и нужные типы данных.
- Построить план. Определяются шаги решения и инструменты для каждого шага.
- Выполнить план. Сервис обращается к API, поиску, базе знаний или другим источникам.
- Собрать результаты. Найденные данные связываются с исходным планом.
- Сформировать ответ. Итог выдаётся на основе плана и полученных фактов.
Если часть данных не получена, процесс не обязательно останавливается полностью. Система может перейти к финальному шагу и явно опереться на то, что удалось собрать.
Что значит reasoning without observation
Фраза reasoning without observation означает, что основная цепочка рассуждения строится до промежуточных наблюдений от инструментов, а не после каждого из них. В этом и состоит центральная идея ReWOO.
Здесь важно не буквальное отсутствие наблюдений. Инструменты и внешние данные всё равно используются. Смысл в другом: наблюдения не управляют каждым следующим шагом мышления в реальном времени, как это происходит в циклических схемах наподобие ReAct.
Иначе говоря, модель сначала определяет маршрут, а потом идёт по нему. Это снижает число повторных пересчётов и делает поведение системы более ровным в задачах с понятной структурой.
Когда стоит выбирать ReWOO
ReWOO выбирают тогда, когда задача многошаговая, но предсказуемая по структуре, а стоимость токенов и стабильность работы имеют значение. Если же решение нужно постоянно перестраивать по ходу дела, лучше подходят более гибкие схемы.
Удобный ориентир такой: если можно заранее ответить на вопрос «какие данные мне понадобятся для результата», ReWOO — хороший кандидат. Если заранее это неясно и каждый новый факт меняет стратегию, жёсткое планирование будет мешать.
Поэтому ReWOO чаще рассматривают как архитектурный выбор под конкретный тип нагрузки, а не как универсальный стандарт для всех ИИ-агентов и всех цепочек рассуждения.
