Что такое delegation by exception (делегирование только по исключению)?

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

Delegation by exception (DBE) — парадигма проектирования AI-агентов, при которой агент сначала пытается выполнить задачу полностью автономно, а передаёт управление (делегирует) другому агенту или человеку только в случае, когда возникает исключительная ситуация (exception). Это позволяет обрабатывать рутинные запросы максимально эффективно, без участия человека, и одновременно гарантировать, что проблемные или нестандартные случаи не будут проигнорированы. Подход критически важен для production-систем, где требуется баланс между автоматизацией и надёжностью.

1. Определение и ключевая идея

Delegation by exception (делегирование только по исключению) — стратегия управления потоком выполнения в multi-agent системах, когда агент берёт на себя основную работу и передаёт задачу другому исполнителю лишь при наступлении заранее определённых условий: ошибка, превышение уровня уверенности, требование человеческого суждения и т.п.

Идея заимствована из классического программирования (блоки try-except):

• try — агент выполняет стандартную операцию;
• except — если операция не удалась, вызывается обработчик (fallback — другой агент или оператор).

В контексте Agentic RAG это означает, что RAG-агент сначала пытается найти ответ в документах и сгенерировать его самостоятельно, а при нехватке данных, двусмысленности или запросе, выходящем за рамки его компетенции, эскалирует задачу.

2. Контекст: agentic RAG и multi-agent системы

Agentic RAG — RAG-система, в которой не просто извлекаются документы и передаются LLM, а используется один или несколько автономных агентов, способных планировать, использовать инструменты, взаимодействовать друг с другом и принимать решения.

DBE — один из базовых паттернов оркестровки в multi-agent средах. Он противопоставляется:

• Полному делегированию (full delegation) — агент сразу передаёт задачу специализированному агенту.
• Конкурентному делегированию (delegation|parallel delegation) — задачу одновременно выполняют несколько агентов, а затем результат консолидируется.
• Иерархическому делегированию — задача дробно спускается по уровням подчинённых агентов.

DBE является частным случаем supervised autonomy — агент работает автономно, но под надзором (supervisor), который вмешивается только в исключительных ситуациях.

3. Принцип работы: try-catch для агентов

Жизненный цикл запроса в архитектуре DBE:

1. Поступление запроса → агенту-исполнителю (worker agent).
2. Worker agent выполняет стандартный пайплайн (retrieval + generation) и оценивает результат по трём критериям:
   • Уверенность (confidence) — LLM даёт score достоверности ответа.
   • Полнота — найден ли хотя бы один релевантный документ.
   • Валидность — соответствует ли ответ бизнес-правилам (например, сумма возврата не превышает лимит).
3. Если все проверки пройдены → ответ возвращается пользователю.
4. Если хотя бы одна проверка не пройдена → worker agent делает raise exception, и exception handler (роутер или supervisor) решает, кому передать задачу: другому агенту (специалисту по исключениям) или человеку-оператору.
5. Эскалированный запрос обрабатывается, решение возвращается в систему (часто с обратной связью для улучшения worker agent).

4. Триггеры исключений

Агент должен уметь распознавать ситуации, когда его компетенции недостаточно. Основные триггеры:

Реализация триггеров обычно включает:

• LLM-as-a-judge: LLM получает запрос, контекст и ответ, затем оценивает качество.
• Метрики faithfulness (по RAGAS) и answer relevance.
• Программные проверки (rule-based) — сравнение числовых полей, проверка формата.

5. Сравнение с другими паттернами делегирования

DBE компромисс: жертвуем небольшим процентом ошибок (которые отлавливаются) ради значительного повышения скорости и снижения затрат на ручную обработку.

6. Когда применять: примеры из реальной жизни

• Customer support (возвраты товаров)
  95% типовых возвратов (срок < 30 дней, товар без дефектов) агент обрабатывает сам.
  5% (просроченные возвраты, брак, крупные суммы) эскалируются оператору.

• Модерация контента
  Агент проверяет текст на явные нарушения (мат, реклама), неясные кейсы отправляет модератору.

• Medical RAG
  Агент отвечает на общие вопросы (график работы, симптомы простуды), но при подозрении на серьёзное заболевание или необходимости рецепта передаёт врачу.

• Финансовые консультации
  Агент рассчитывает ежемесячный платёж по кредиту, но при нестандартных ставках или досрочном погашении эскалирует аналитику.

7. Архитектурная реализация (код на Python)

Пример простого агента с DBE на базе LangChain и Fake LLM (для демонстрации):

import asyncio
from enum import Enum
from typing import Optional

class ExceptionType(Enum):
    LOW_CONFIDENCE = 1
    NO_DOCUMENTS = 2
    POLICY_VIOLATION = 3

class WorkerAgent:
    def __init__(self, llm, retriever, confidence_threshold=0.7):
        self.llm = llm
        self.retriever = retriever
        self.confidence_threshold = confidence_threshold

    async def process_query(self, query: str) -> tuple[str, Optional[ExceptionType]]:
        # 1. Retrieval
        docs = await self.retriever.get_relevant_documents(query)
        if not docs:
            return "No documents found", ExceptionType.NO_DOCUMENTS

        # 2. Generate answer
        answer = await self.llm.generate_with_context(query, docs)

        # 3. Evaluate confidence (simplified)
        confidence = self._estimate_confidence(answer)
        if confidence < self.confidence_threshold:
            return answer, ExceptionType.LOW_CONFIDENCE

        # 4. Check business policy (example: amount > 1000)
        if self._has_policy_violation(answer):
            return answer, ExceptionType.POLICY_VIOLATION

        return answer, None  # OK

    def _estimate_confidence(self, answer: str) -> float:
        # Mock: LLM returns confidence as part of answer
        return 0.85 if "maybe" not in answer.lower() else 0.4

    def _has_policy_violation(self, answer: str) -> bool:
        return "$2000" in answer

class EscalationManager:
    async def handle_exception(self, query: str, exception_type: ExceptionType, answer: str):
        if exception_type == ExceptionType.NO_DOCUMENTS:
            print(f"[ESCALATION] Routing {query} to search team.")
        elif exception_type == ExceptionType.LOW_CONFIDENCE:
            print(f"[ESCALATION] Routing {query} to human operator.")
        elif exception_type == ExceptionType.POLICY_VIOLATION:
            print(f"[ESCALATION] Routing {query} to compliance team.")

async def main():
    agent = WorkerAgent(llm=None, retriever=None)
    escalation = EscalationManager()

    test_queries = [
        "How do I return a $20 item?",
        "How do I return a broken TV ($2000)?",
        "What is the meaning of life?"
    ]

    for query in test_queries:
        answer, exception = await agent.process_query(query)
        if exception:
            await escalation.handle_exception(query, exception, answer)
        else:
            print(f"[OK] {query} → {answer}")

asyncio.run(main())

Ожидаемый вывод

[OK] How do I return a $20 item? → ...
[ESCALATION] Routing How do I return a broken TV ($2000)? to compliance team.
[ESCALATION] Routing What is the meaning of life? to search team.

Ключевой момент: агент сначала пробует сам, и только при обнаружении исключения вызывает escalation manager. В реальных системах вместо mock используются LLM с output parsers, confidence scoring (например, через логиты) и интеграция с внешними системами (ticketing, Slack).

8. Преимущества и недостатки

Преимущества

• Высокая скорость обработки 95%+ запросов обрабатываются без участия человека (latency = время агента).
• Снижение operational cost ручной труд используется только там, где он действительно нужен.
• Масштабируемость легко добавлять новых агентов без перегрузки операторов.
• Постепенное обучение исключения можно анализировать и добавлять новые правила для автоматизации (расширение «try»-части).
• Безопасность экстремальные случаи не «проглатываются» системой.

Недостатки

• Сложность определения границ слишком низкий порог исключений → много ложных эскалаций; слишком высокий → опасные ситуации пропускаются.
• Риск пропуска неявных исключений агент может быть уверен в своём неверном ответе; такие случаи не вызовут exception.
• Дополнительная инфраструктура нужен механизм оценки уверенности и мониторинг исключений.
• UX для операторов людям, которые получают эскалированные запросы, нужно видеть контекст (историю, попытку агента, почему он не справился).

9. Метрики и оценка эффективности DBE

Для измерения качества DBE системы используются три группы метрик:

Важно также запускать A/B-тесты: сравнивать систему с DBE и систему с полным делегированием (baseline) по NPS и cost per ticket.

10. Связь с другими паттернами (supervision, routing, hierarchical agents)

DBE часто комбинируется с другими подходами:

• DBE + Supervision supervisor-агент не просто наблюдает, а вмешивается, когда worker agent выдаёт исключение. Supervision может быть жёстким (supervisor перехватывает запрос) или мягким (рекомендация, но решение за worker-ом).
• DBE + Routing роутер на входе распределяет запросы между разными worker-агентами, и каждый из них работает по DBE. При исключении роутер перенаправляет запрос другому агенту или человеку.
• DBE + Reflection после обработки worker agent проводит самопроверку (reflection) и может сам сгенерировать exception, если находит ошибку.

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

Задача Разработать агента для автоматической обработки заявок на возврат товаров в интернет-магазине. Система должна сама обрабатывать 90% возвратов (по стандартному сценарию), а сложные (брак, просрочка, крупная сумма) передавать оператору.

Инструменты

• Python + LangChain / AutoGen
• Retriever: FAISS + эмбеддинги (sentence-transformers)
• LLM: OpenAI / локальная модель через Ollama
• Система эскалации: простая очередь на основе SQLite или mock Slack API

Шаги:

1. Создать датасет — 100 типовых и 20 сложных кейсов (эталонные решения).
2. Реализовать WorkerAgent с retrieval по документам политики возврата.
3. Добавить триггеры исключений
   • сумма > $500 → эскалация;
   • товар не найден в БД заказов → эскалация;
   • в запросе есть слово «брак» → эскалация.
4. Реализовать EscalationManager — записывает эскалированный запрос в файл/таблицу, затем «оператор» (скрипт-имитатор) выдаёт ответ.
5. Оценить auto-success rate на датасете.
6. Провести ручной анализ логов все ли исключения действительно требовали человека? не пропущены ли опасные случаи?

Ожидаемый результат
Агент обрабатывает около 85–95% запросов, эскалирует только те, где действительно нужен человек. Метрики precision и recall исключений >0.9.

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

Дополнительно: DBE пересекается с концепцией fallback strategies (вопрос 757) и эскалацией confidence (вопрос 758).

Навигация

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