Что такое «откат делегирования» (rollback delegation) при ошибке?

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

Откат делегирования (rollback delegation) – это механизм в архитектуре агентных систем (в том числе Agentic RAG), позволяющий при сбое текущего агента-исполнителя вернуть управление супервайзеру (или предыдущему агенту в цепочке) вместе с откатом уже выполненных изменений. Основная цель – сохранить согласованность состояния системы и избежать «подвешенных» транзакций. Реализуется через паттерн SAGA (компенсирующие транзакции), двухфазный коммит или явные компенсирующие call|вызовы API.

1. Проблема: неполное выполнение задачи в цепочке делегирования

В Agentic RAG агент (например, супервайзер) часто делегирует подзадачи другим агентам (специалистам по retrieval, генерации, веб-поиску, записи в БД и т.д.). Если один из агентов падает после частичного выполнения (изменение состояния БД, отправка запроса, модификация файла), а супервайзер не контролирует откат, система остаётся в несогласованном состоянии. Пример:

• Супервайзер попросил агента A записать результат в таблицу orders.
• Агент A вставил запись, но не смог обновить связанную таблицу inventory и упал.
• Без отката делегирования в orders остаётся «сиротская» запись, заказ считается выполненным, а товар не списан.

2. Определение rollback delegation

Rollback delegation – это согласованный протокол, при котором:

1. Вышестоящий агент (супервайзер) отслеживает состояние выполнения подзадачи.
2. При ошибке текущего исполнителя он запускает компенсирующие действия (откат изменений, отмену операций).
3. После успешного отката задача может быть перенаправлена другому агенту или возвращена пользователю с сообщением об ошибке.

Термин «агент-исполнитель» – любой модуль, выполняющий действие (LLM-вызов, запрос к API, запись в БД). «Супервайзер» – агент, управляющий цепочкой делегирования (orchestrator).

3. Ключевые термины и их связь

4. Пример сценария с rollback delegation

Исходная схема цепочки:

Пользователь → Супервайзер → Агент A (получить данные из API)
                         → Агент B (обогатить данные)
                         → Агент C (записать в БД)

Сбой на агенте B:

1. Агент A успешно получил данные (изменил временное хранилище).
2. Агент B начал обогащение, но упал (например, LLM вернул ошибку токенов).
3. Супервайзер обнаруживает ошибку (timeout/exception).
4. Rollback delegation:
   • Супервайзер вызывает компенсирующую транзакцию для агента A: удалить временные данные.
   • Уведомляет агента B об отмене (если он начал писать в БД – тоже откат).
5. Супервайзер пробует делегировать задачу агенту D (другой LLM) или возвращает ошибку пользователю.

Код псевдо-реализации (Python-like):

class Supervisor:
    def run_task(self, task):
        state = {}
        try:
            result_a = self.agent_a.execute(task, state)
            state['temp_data'] = result_a
            result_b = self.agent_b.execute(result_a, state)
            # ...
        except Exception as e:
            self.rollback(state)          # откат делегирования
            raise e

    def rollback(self, state):
        if 'temp_data' in state:
            self.agent_a.compensate(state['temp_data'])  # например, DELETE
        # аналогично для других агентов

5. Реализация через SAGA pattern

SAGA pattern – наиболее распространённый способ реализации rollback delegation в микросервисных агентных системах.

Хореографическая SAGA (choreography):

• Каждый агент после успешного выполнения публикует событие (event).
• При ошибке публикуется событие отката, и каждый агент, который участвовал, слушает своё компенсирующее событие.
• Плюс: слабая связанность. Минус: сложно отлаживать цепочку.

Оркестраторная SAGA (orchestration):

• Супервайзер (оркестратор) явно управляет шагами и компенсациями.
• Ведёт лог выполненных шагов.
• При ошибке запускает компенсации в обратном порядке.
• Пример: AWS Step Functions, Temporal, Camunda.

# Оркестраторная SAGA (упрощённо)
saga_steps = [
    ("agent_a.execute", "agent_a.compensate"),
    ("agent_b.execute", "agent_b.compensate"),
    ("agent_c.execute", "agent_c.compensate"),
]
executed = []
for step, comp in saga_steps:
    try:
        step()
        executed.append(comp)
    except Exception:
        for comp in reversed(executed):
            comp()
        raise

6. Отличие от двухфазного коммита (2PC)

В контексте Agentic RAG 2PC редко применим, т.к. агенты – это LLM-вызовы, которые не поддерживают блокировки. Поэтому rollback delegation через SAGA – де-факто стандарт.

7. Компенсирующие вызовы API для rollback delegation

Когда агент выполняет внешний запрос (например, отправляет email, создаёт тикет), откат должен быть реализован через обратное действие:

• Создание записи → удалить запись (или пометить как удалённую).
• Отправка уведомления → отправить отменяющее уведомление (если возможно) или логировать ошибку и не отправлять.
• Изменение статуса → вернуть предыдущий статус.

Важно, чтобы компенсирующие вызовы были идемпотентными: повторный вызов не должен приводить к повторному откату. Например, если DELETE уже выполнен, повторный DELETE должен быть безопасен (возвращать успех).

8. Особенности в Agentic RAG

В Agentic RAG супервайзер часто делегирует:

• Retrieval-агенту – поиск чанков (обычно read-only, откат не нужен).
• Reasoning-агенту – генерация плана (чистое вычисление, нет состояния).
• Write-агенту – запись результата в базу знаний или лог (нужен откат).
• External API-агенту – вызов стороннего сервиса (требуются компенсации).

Rollback delegation особенно важен, когда:

• Действия не являются идемпотентными (например, списание денег).
• Требуется атомарность между шагами (все или ничего).
• Используется chain-of-thought с побочными эффектами (например, заказ товара).

9. Стратегии обнаружения ошибок для rollback

• Timeouts: агент не ответил за ожидаемое время → считать ошибкой.
• Exception handling: LLM возвращает structured error (например, invalid JSON).
• Validation: результат агента не прошёл проверку супервайзера (schema mismatch).
• Health check: перед делегированием проверить статус агента (alive?).

10. Плюсы и минусы rollback delegation

Плюсы:

• Гарантирует согласованность данных в распределённой системе.
• Позволяет повторно использовать тех же агентов после отката.
• Лёгкая интеграция с существующими оркестраторами (LangGraph, CrewAI, AutoGen).

Минусы:

• Увеличивает сложность кода (нужно реализовывать компенсации для каждого действия).
• Компенсирующие транзакции могут быть дорогими (повторный вызов LLM).
• Не решает проблему «дублирования» (если агент успел что-то сделать, но не сообщил – откат может не сработать). Требуются идемпотентные ключи и retry с deduplication.

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

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

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

• Python с FastAPI (супервайзер)
• SQLite (история запросов)
• OpenAI API (генерация)
• LangChain или bare-bone LLM вызов

Шаги:

1. Создать двух агентов: retriever (возвращает чанки) и generator (генерирует ответ + записывает в историю).
2. Супервайзер делегирует retriever → получает чанки → делегирует generator.
3. Если generator падает (искусственно: raise Exception с вероятностью 30%), супервайзер откатывает изменения: удаляет запись из истории, логирует ошибку.
4. Реализовать compensate метод у generator: удалить последнюю запись из таблицы history.
5. Добавить идемпотентность: запись имеет UUID, при повторной компенсации – ничего не делать.

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

• При успешном выполнении в таблице history появляется одна запись.
• При ошибке – запись не остаётся, в логах видно откат.
• При повторе срабатывает идемпотентность (повторный вызов compensate не падает).

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

13. Навигация

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

Навигация

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