ReAct (reasoning + acting)

ReAct — это паттерн работы языковой модели, при котором она не пытается ответить за один проход, а чередует короткие шаги рассуждения и действия: ищет данные, вызывает инструменты, получает наблюдения и только потом формирует вывод. Такой подход полезен там, где ответ зависит от внешнего мира: документации, базы знаний, API, поискового индекса, статуса сервиса. Он плохо подходит для простых статических задач вроде перефразирования или классификации, для сценариев с жестким лимитом по задержке, а также для контуров, где инструменты ненадежны или их ответы нельзя безопасно использовать без дополнительной проверки.

Простыми словами

Если обычный prompt просит модель сразу выдать ответ, то ReAct заставляет ее работать по шагам. Сначала модель намечает, чего ей не хватает для ответа. Затем делает действие: например, ищет страницу в базе знаний, вызывает калькулятор, читает статус инцидентов или запрашивает данные из CRM. После этого она учитывает результат и решает, нужен ли следующий шаг.

Практически это выглядит как связка reasoning + acting: модель рассуждает не в отрыве от мира, а рядом с инструментами. Поэтому ReAct часто используют как базовый паттерн для AI-агентов.

• Reasoning — промежуточное планирование: что проверить, что уточнить, какой инструмент выбрать.
• Acting — реальное действие: вызов функции, поиск, чтение документа, запрос к API.
• Observation — результат действия, на основе которого модель корректирует следующий шаг.

Важно: ReAct — не отдельная модель и не стандарт API, а способ организовать поведение модели. Его можно реализовать через prompt, через агентный runtime или через системную оркестрацию вокруг LLM.

Как это работает

Классический цикл ReAct состоит из повторяющихся шагов. В исходной работе он записывался текстовыми блоками вроде Thought, Action, Observation. В production-системах видимая часть обычно компактнее: мыслительный шаг может оставаться внутренним, а наружу логируются только вызовы инструментов и результаты.

1. Получение задачи. Пользователь задает вопрос или просит выполнить действие.
2. Локальное рассуждение. Модель определяет, хватает ли ей контекста. Если нет, она выбирает следующий шаг.
3. Вызов инструмента. Система передает аргументы в функцию, поисковый индекс, БД или внешний API.
4. Наблюдение. Результат возвращается модели в виде структурированных данных или текста.
5. Переоценка. Модель решает: ответ уже можно дать или нужен еще один шаг.
6. Финальный ответ. Система возвращает пользователю итог, иногда со ссылкой на найденные факты.

Элемент	Что делает модель	Что должна сделать система	Типичный риск
Рассуждение	Выбирает следующий шаг	Ограничить доступные действия и формат вывода	Лишние шаги, уход в сторону
Действие	Формирует вызов инструмента	Провалидировать аргументы и права доступа	Ошибочный или опасный вызов
Наблюдение	Интерпретирует результат	Вернуть чистые и структурированные данные	Неверное чтение ответа инструмента
Финализация	Собирает ответ пользователю	Применить шаблоны, политики и проверки	Уверенный, но неверный вывод

Для устойчивой реализации нужны как минимум четыре вещи: ограниченный каталог инструментов, четкие схемы аргументов, лимиты на число шагов и проверка результатов перед критическими действиями. Без этого ReAct быстро превращается в дорогой и нестабильный цикл проб и ошибок.

Зачем нужно

Главная причина использовать ReAct — отделить знания модели от фактов текущего мира. У LLM может быть сильный языковой и логический слой, но слабая связь с актуальными данными. ReAct закрывает этот разрыв.

• Доступ к свежим данным. Модель может искать актуальную информацию вместо ответа по памяти.
• Многошаговые задачи. Вопросы вида «сначала найди, потом сравни, потом объясни» проще решать через цикл действий.
• Снижение галлюцинаций. Если система заставляет модель опираться на наблюдения, а не на догадки, качество обычно выше.
• Лучший выбор инструмента. Модель может решить, нужен поиск, калькулятор, SQL-запрос или чтение документа.
• Трассируемость. По логу действий проще понять, откуда взялся ответ и на каком шаге произошла ошибка.

На практике ReAct особенно полезен в поддержке, аналитике, внутренних copilot-системах, интерфейсах к документации, автоматизации исследований и обслуживании бизнес-процессов с несколькими источниками данных.

Но он не обязателен везде. Если задача полностью решается на одном контексте — например, извлечь поля из уже переданного документа, суммаризировать текст или классифицировать обращение, — дополнительный агентный цикл часто только увеличит задержку и стоимость.

Пример

Практический сценарий: внутренний помощник поддержки отвечает на вопрос инженера: «Почему вчера около 14:20 клиенты получали 502 от нашего API?» У помощника есть три инструмента: поиск по базе знаний, чтение страницы инцидентов и запрос к журналу ошибок.

1. Шаг 1: уточнение источника истины. Модель понимает, что ответ нельзя давать по памяти: нужен статус инцидентов и реальные логи.
2. Шаг 2: действие. Вызов get_incidents(start=14:00,end=14:40).
3. Наблюдение. Сервисный инцидент в 14:12–14:31: деградация upstream gateway.
4. Шаг 3: действие. Вызов search_logs(code=502,time_window=14:00-14:40).
5. Наблюдение. Пик ошибок совпадает по времени; большая часть записей содержит таймаут обращения к upstream.
6. Шаг 4: действие. Вызов kb_search(query="502 upstream timeout mitigation").
7. Наблюдение. В базе знаний есть статья с типовым объяснением и советом проверить повторы запросов после восстановления.
8. Финальный ответ. Модель сообщает, что 502 были связаны с подтвержденным инцидентом upstream gateway, приводит временной диапазон, советует повторить неуспешные запросы и, если нужно, перечисляет затронутые методы API.

Здесь ценность ReAct не в самом факте вызова функций, а в последовательности. Модель сначала собирает подтверждение из разных источников, затем синтезирует вывод. Если бы инцидентов не оказалось, она могла бы сменить стратегию и искать ошибки аутентификации, превышение лимита или региональную деградацию.

Практическое правило: если вопрос требует проверить более одного внешнего источника и между проверками нужно принимать решение о следующем шаге, ReAct обычно уместнее, чем одиночный prompt.

Заблуждения и ограничения

• ReAct не гарантирует истинность. Он лишь дает модели способ добывать факты. Если инструмент возвращает мусор, ответ тоже будет плохим.
• Это не то же самое, что chain-of-thought. В ReAct важен цикл с действиями. Рассуждение без инструментов — только часть подхода.
• Больше шагов — больше задержка и стоимость. Каждый вызов инструмента и каждый дополнительный проход через модель увеличивают время ответа.
• Нужны guardrails. Нельзя давать модели прямой доступ к чувствительным операциям без валидации, прав доступа и подтверждения пользователя.
• Не все задачи требуют агентности. Для извлечения, классификации, форматирования и коротких ответов по предоставленному контексту ReAct часто избыточен.
• Инструменты могут заражать контекст. Поисковая выдача, веб-страницы или пользовательские документы могут содержать инструкции, которые пытаются перехватить поведение агента.

Отдельное заблуждение — считать, что хороший ReAct строится только prompt-инженерией. На практике качество сильнее зависит от оркестрации: формата наблюдений, политики выбора инструментов, лимита шагов, ретраев, кэширования и постпроверок.

Подход особенно нежелателен там, где требуется строго детерминированное поведение без права на лишние запросы: например, в критических транзакциях, системах с дорогими внешними API или интерфейсах с очень маленьким SLA по времени ответа.

Частые вопросы

ReAct и agent — это одно и то же?

Нет. ReAct — это паттерн поведения агента: цикл «подумать, сделать, посмотреть результат». Агент — более широкое понятие; он может использовать ReAct, планировщики, графы состояний или жестко заданные workflow.

Чем ReAct отличается от простого tool calling?

Tool calling — это механизм вызова функции. ReAct — стратегия, по которой модель решает, когда и зачем вызвать инструмент, как интерпретировать результат и нужен ли следующий шаг.

Нужно ли показывать пользователю все промежуточные рассуждения?

Нет. Для эксплуатации обычно достаточно логировать действия, аргументы, результаты и финальный ответ. Подробные внутренние рассуждения не обязательны и не всегда желательны с точки зрения безопасности и UX.

Снижает ли ReAct галлюцинации?

Часто да, если модель обязана опираться на наблюдения из надежных источников. Но если источник плохой, схема вызова неверная или шагов слишком много, галлюцинации никуда не исчезают.

Когда лучше выбрать RAG без ReAct?

Когда задача сводится к одному хорошему поиску по корпусу и последующему ответу по найденным фрагментам. Если не нужно принимать решения между несколькими инструментами и менять план по ходу, обычный RAG проще и дешевле.

Связанные понятия

• Agent — система, в которой модель не только отвечает, но и управляет шагами выполнения задачи.
• Tool calling — механизм структурированного вызова функций и API из LLM.
• RAG — retrieval-augmented generation, когда модель сначала получает релевантные документы, а затем отвечает по ним.
• Chain-of-thought — промежуточное рассуждение модели; в ReAct оно сочетается с действиями, но не исчерпывает весь подход.
• Planning — более явное предварительное планирование задачи на несколько шагов; может использоваться вместе с ReAct, если нужна длинная стратегия.
• Guardrails — ограничения и проверки вокруг агента: схемы, политики, подтверждения, фильтры и валидация результатов.

Если нужен короткий ориентир для практики: используйте ReAct там, где модель должна принимать решения между несколькими инструментами на основе промежуточных результатов. Не используйте его по умолчанию для каждой задачи. Сначала проверьте, нельзя ли решить проблему одним поиском, одним вызовом функции или обычным workflow без агентной петли.