В чем разница между Workflow и Guidance в теории harness-engineering?

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

В harness-engineering (инженерия сбруи/обвязки для ИИ-агентов) Workflow (поток работ) задаёт макро-структуру — что агент должен сделать на каждом шаге (подцели, последовательность этапов). Guidance (наведение) влияет на микро-поведение — как именно агенту выбирать действия в текущем состоянии (искажение апостериорного распределения). Ключевой инсайт: избыточная детализация workflow (over-decomposition) и слишком жёсткая guidance могут снизить адаптивность агента, особенно в нестабильных средах. Правильный баланс — дать агенту свободу действий внутри чётких границ.

1. Контекст: что такое harness-engineering?

Термин harness-engineering относительно новый, популяризирован в работах Wang et al. и сообществом AI-agents. «Сбруя» (harness) — это управляющая обвязка вокруг языковой модели, которая направляет её поведение без прямого переобучения.

Основные компоненты:

• Agent: LLM, который принимает решения (какое действие совершить, какой инструмент вызвать).
• Harness: внешняя логика — workflow, guidance, инструменты, память, система промптов.
• Environment: среда, в которой агент действует (API, симулятор, база знаний).

Разница между Workflow и Guidance — один из центральных вопросов проектирования этой сбруи.

2. Определение Workflow (поток работ)

Workflow — это статическая или динамическая последовательность этапов, которые агент должен пройти. Он отвечает на вопрос «что делать?» на каждом шаге.

Характеристики:

• Структурность: этапы строго упорядочены (линейно или в виде графа переходов).
• Спецификация подцелей: на каждом этапе агент получает описание текущей цели (например, «найти релевантные чанки», «сформировать ответ», «проверить фактуальность»).
• Примеры реализации: orchestration|Directed Acyclic Graph (DAG), state machines, платформы вроде LangGraph или Temporal.

В контексте Agentic RAG workflow может выглядеть так:

@dataclass
class AgentWorkflow:
    steps: list[str]

    async def execute(self, query: str):
        step_results = {}
        for step in self.steps:
            if step == "retrieve":
                step_results["docs"] = await retrieve(query)
            elif step == "rerank":
                step_results["ranked"] = await rerank(step_results["docs"])
            elif step == "generate":
                step_results["answer"] = await generate(query, step_results["ranked"])
        return step_results["answer"]

Преимущества: предсказуемость, тестируемость, легко отлаживать. Недостатки: негибкость — если среда потребует изменить порядок действий (например, после retrieve оказалось, что нужно переформулировать запрос), workflow может сломаться.

3. Определение Guidance (наведение)

Guidance — это техника мягкого влияния на поведение агента во время генерации или выбора действия. Отвечает на вопрос «как действовать?» (локально, на уровне токенов или выбора инструмента).

Формы guidance:

• System prompt с инструкциями («ты должен сначала проверить факты, затем ответить»).
• Logit-манипуляции (увеличить/уменьшить вероятности определённых токенов — например, forcing структурированного вывода через JSON schema).
• Constraints (например, запрет на определённые действия в данный момент).
• Feedback loops: внешний модуль подсказывает агенту изменить решение на основе ошибки.

В контексте Agentic RAG guidance может быть реализован через специальный модуль, который перехватывает намерение агента и корректирует его:

def guidance_rerank(agent_intent: str, retrieved_docs: list) -> list:
    # Наведение: если агент хочет сразу ответить, но есть конфликт в документах,
    # предлагаем переформулировать запрос
    if "ответить" in agent_intent и conflict_exists(retrieved_docs):
        return suggest_reformulation()
    return retrieved_docs

Преимущества: гибкость, адаптивность — guidance не ломает общую структуру, а только корректирует курс. Недостатки: сложность настройки, риск переучить агента (over-constraining), менее предсказуем.

4. Ключевые различия (таблица)

5. Связь с Agentic RAG: как workflow и guidance сочетаются

В типичном Agentic RAG агенту даётся workflow (например, «сначала поищи, потом проверь качество, потом ответь»), а guidance вшивается в промпты или внешние модули для корректировки поведения внутри каждого шага.

Пример гибридного подхода:

class AgenticRAG:
    def __init__(self):
        self.workflow = ["retrieve", "filter", "generate"]
        self.guidance_rules = {
            "retrieve": "Если запрос короткий (<3 слов), расширь его синонимами",
            "filter": "Если много документов (>5), выбери топ-3 по релевантности",
            "generate": "Если уверенность < 0.6, верни 'Не знаю'"
        }

    async def run(self, query):
        for step in self.workflow:
            hint = self.guidance_rules.get(step)
            query = await self.execute_step(step, query, hint)

6. Опасность over-decomposition и жёсткой guidance

Over-decomposition (избыточная детализация workflow) — когда агента заставляют выполнять слишком много мелких шагов, что:

• увеличивает latency (каждый шаг — вызов LLM/инструмента);
• снижает адаптивность (агент не может пропустить ненужный шаг);
• накапливает ошибки (error accumulation).

Жёсткая guidance (over-constraining) — когда наведение настолько сильное, что агент теряет способность к творческому решению нестандартных задач. Например, forcing вывода в строгом JSON схеме может привести к потере полезной информации, которая не укладывается в схему.

Ключевой инсайт: баланс — дать агенту достаточно свободы для адаптации, но достаточно структуры для надёжности. В статье Wang et al. рекомендуется начинать с минимального workflow и добавлять guidance только там, где агент систематически ошибается.

7. Как балансировать: гибридный подход

Рекомендации:

1. Workflow — только для критических переходов (например, после retrieve обязательно выполнить валидацию).
2. Guidance — для тонкой настройки поведения (например, стиль ответа, уровень детализации).
3. Динамический workflow: граф, где агент сам решает, какой шаг выполнить следующим (как в React или LangGraph с conditional edges).
4. Feedback loop: после каждого шага измерять качество (например, через эвристики или маленькую модель) и корректировать guidance на лету.

Пример динамического workflow с guidance:

def agent_loop(query):
    memory = []
    step = "start"
    while step != "done":
        # guidance: подсказка от meta-agent
        hint = get_hint(query, memory, step)
        # выполнение текущего шага
        result, next_step = execute(step, query, memory, hint)
        memory.append(result)
        step = next_step

8. Инструменты и фреймворки

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

Задача: Разработать простую Agentic RAG-систему для ответов на вопросы по документации API, где workflow и guidance реализованы отдельно и могут настраиваться.

Инструменты:

• Python + LangGraph или bare Python (asyncio + стейт-машина)
• LLM API (OpenAI / Groq / local через Ollama)
• FAISS или ChromaDB (векторная БД)

Шаги:

1. Определить базовый workflow: retrieve → generate.
2. Добавить опциональные шаги (проверка противоречий, переформулировка запроса).
3. Реализовать guidance через промпты: при обнаружении конфликта в документах агент должен запросить уточнение у пользователя.
4. Сравнить три конфигурации:
   • только workflow (фиксированный pipeline);
   • только guidance (агент сам выбирает шаги через chain-of-thought);
   • гибрид (workflow с минимальными рамками + guidance).
5. Измерить метрики: hit rate, faithfulness, среднее число шагов.

Ожидаемый результат:

• Гибрид покажет лучший balance между точностью и эффективностью (меньше лишних шагов, выше faithfulness).
• Чистый workflow будет быстр, но упадет на сложных запросах.
• Чистая guidance даст гибкость, но может быть слишком медленной и нестабильной.

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

11. Навигация

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

Навигация

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