Что такое planner/executor architecture для агентов и когда она нужна?

Краткий тезис

Planner/Executor architecture — это паттерн построения AI-агентов, в котором два компонента работают последовательно: Planner (обычно LLM) составляет многошаговый план действий на основе запроса, а Executor (LLM или rule-based система) выполняет каждый шаг, возвращая результаты. Архитектура нужна для задач с длинным горизонтом (более 5 шагов), где требуется предварительное стратегическое планирование, а не итеративное уточнение. Ключевое отличие от ReAct — план строится до выполнения, а не пошагово.

1. Основные термины

• Planner (планировщик) — компонент, который получает запрос пользователя и генерирует последовательность действий (план). Обычно это LLM с промптом, предписывающим разбить задачу на подзадачи и упорядочить их. План может быть в виде списка шагов, графа зависимостей или JSON-структуры.
• Executor (исполнитель) — компонент, который выполняет каждый шаг плана. Может быть:
  • LLM-исполнитель — вызывает ту же или другую модель для генерации ответа/действия.
  • Rule-based исполнитель — вызывает API, выполняет код, обращается к базе данных.
• Loop (цикл обратной связи]]) — после выполнения каждого шага Executor возвращает результат Planner'у, который может скорректировать оставшуюся часть плана (re-planning).
• Horizon (горизонт) — количество шагов, которое агент может выполнить до достижения цели. Длинный горизонт (>5 шагов) — ключевой индикатор для применения Planner/Executor.
• Agent (агент) — автономная система, которая воспринимает окружение, принимает решения и выполняет действия для достижения цели. Planner/Executor — один из способов реализации агента.

2. Как работает архитектура: пошагово

1. Пользовательский запрос поступает в Planner.
2. Planner анализирует запрос и генерирует план — упорядоченный список действий. Пример плана для запроса «Напиши отчёт о последних исследованиях в области RAG»:
   • Шаг 1: Поискать статьи по RAG за 2024 год.
   • Шаг 2: Извлечь ключевые идеи из каждой статьи.
   • Шаг 3: Сгруппировать идеи по темам.
   • Шаг 4: Написать введение.
   • Шаг 5: Написать основную часть.
   • Шаг 6: Написать заключение.
3. Executor последовательно выполняет шаги. На каждом шаге он может вызывать внешние инструменты (поиск, чтение файлов, вызов LLM).
4. Результат каждого шага возвращается в Planner (через loop). Planner может:
   • Продолжить выполнение по исходному плану.
   • Изменить план, если результат неожиданный (например, не найдено статей — добавить шаг поиска в другом источнике).
5. После выполнения всех шагов агент возвращает финальный ответ пользователю.

3. Когда нужна Planner/Executor архитектура?

Архитектура оправдана в следующих сценариях:

Когда НЕ нужна

• Короткие задачи (1–3 шага) — ReAct или простой LLM вызов эффективнее.
• Задачи, где план невозможно предсказать заранее (например, диалог с пользователем) — лучше подходят реактивные архитектуры (ReAct, Reflexion).

4. Сравнение Planner/Executor и ReAct

5. Пример реализации на Python (упрощённый)

from typing import List, Dict, Any
import json

class PlannerExecutorAgent:
    def __init__(self, planner_llm, executor_llm, tools: Dict[str, callable]):
        self.planner_llm = planner_llm
        self.executor_llm = executor_llm
        self.tools = tools  # {"search": search_func, "read_file": read_func, ...}

    def plan(self, user_query: str) -> List[Dict[str, Any]]:
        prompt = f"""Ты — планировщик. Разбей задачу на шаги.
Запрос: {user_query}
Формат ответа: JSON-список шагов, каждый шаг: {{"step_id": int, "action": str, "tool": str, "input": str}}.
Пример: [{{"step_id": 1, "action": "search", "tool": "search", "input": "RAG 2024 papers"}}]"""
        response = self.planner_llm.generate(prompt)
        return json.loads(response)

    def execute_step(self, step: Dict[str, Any], context: Dict) -> str:
        tool_name = step["tool"]
        tool_input = step["input"]
        if tool_name in self.tools:
            return self.tools[tool_name](tool_input, context)
        else:
            # Если нет инструмента — используем executor_llm для генерации
            return self.executor_llm.generate(f"Выполни действие: {step['action']} с входом: {tool_input}")

    def run(self, user_query: str) -> str:
        plan = self.plan(user_query)
        context = {"query": user_query, "results": {}}
        for step in plan:
            result = self.execute_step(step, context)
            context["results"][step["step_id"]] = result
            # Опционально: re-planning
            # plan = self.replan_if_needed(plan, context)
        # Финальная генерация ответа
        final_prompt = f"Запрос: {user_query}\nРезультаты шагов: {context['results']}\nСформируй финальный ответ."
        return self.executor_llm.generate(final_prompt)

Пояснение

• planner_llm — LLM, которая генерирует план.
• executor_llm — LLM для выполнения шагов (может быть той же моделью).
• tools — словарь функций (поиск, чтение файлов, вызов API).
• context — накапливает результаты для последующих шагов.
• Re-planning (закомментирован) — может быть реализован как вызов Planner после каждого шага с обновлённым контекстом.

6. Плюсы и минусы

Плюсы

• Структурированность — план даёт ясную дорожную карту.
• Экономия ресурсов — меньше вызовов LLM на рассуждения.
• Лучшая производительность на длинных задачах.
• Возможность предварительной валидации плана пользователем.

Минусы

• План может оказаться неоптимальным, если запрос неоднозначен.
• Re-planning добавляет сложность и latency.
• Не подходит для задач, где план невозможно составить заранее (динамические окружения).
• Требует тюнинга промптов для Planner.

7. Интеграция с RAG (Agentic RAG)

В контексте Agentic RAG Planner/Executor используется для многошагового поиска и синтеза информации:

• Planner разбивает сложный запрос на подзапросы (например, «Найди данные по продажам за Q1, затем сравни с Q2»).
• Executor выполняет retrieval для каждого подзапроса, используя разные коллекции или фильтры.
• Loop позволяет уточнять поиск на основе промежуточных результатов (например, если первый поиск не дал релевантных документов, Planner добавляет шаг с другими ключевыми словами).

Пример: агент для юридического анализа — сначала ищет законы, затем судебную практику, затем составляет меморандум.

8. Пет-проект для закрепления

Задача Создать агента для автоматического исследования темы (multi-step research agent). Пользователь вводит тему, агент должен:

1. Спланировать шаги (поиск статей, извлечение ключевых пунктов, сравнение источников, написание summary).
2. Выполнить шаги с использованием реального поискового API (например, SerpAPI или Wikipedia API).
3. Вернуть структурированный отчёт.

Инструменты

• Python, библиотеки: requests, json, openai (или transformers для локальной LLM).
• LLM: GPT-4 или Llama 3 (через API).
• Поисковый инструмент: Wikipedia API или DuckDuckGo API.

Шаги:

1. Реализовать класс ResearchAgent с методами plan, execute_step, run.
2. Planner: промпт, который просит LLM разбить тему на 3–5 шагов (например, «найти обзор», «найти последние новости», «сравнить»).
3. Executor: для каждого шага вызывает поисковый инструмент и сохраняет результаты.
4. Loop: после каждого шага проверять, достаточно ли информации; если нет — добавить шаг.
5. Финальный шаг: LLM пишет отчёт на основе собранных данных.

Ожидаемый результат Работающий агент, который по запросу «последние достижения в области квантовых вычислений» выдаёт отчёт с разделами: введение, основные направления, ключевые компании, перспективы.

9. Связь с другими вопросами

10. Навигация

• Предыдущий: 566
• Следующий: 568
• Индекс: 00. Индекс разборов

Навигация

• Предыдущий: 566
• Следующий: 568
• Индекс: 00. Индекс разборов