Как проектировать delegation с учётом человеческого фактора (усталость, занятость)?

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

Delegation в Agentic RAG — передача управления от AI-агента человеку-оператору, когда агент не может решить задачу самостоятельно. Человеческий фактор (усталость, занятость) критичен: без учёта этих состояний система будет перегружать операторов, вызывать ошибки и снижать доверие. Проектирование включает адаптивные лимиты нагрузки, мониторинг статусов, приоритезацию запросов и передачу контекста для быстрого включения. Ключевой принцип — design for failure: система должна корректно обрабатывать занятость и усталость, а не просто эскалировать.

1. Определение delegation в Agentic RAG

Delegation — это механизм, при котором AI-агент (LLM, RAG-пайплайн) передаёт выполнение задачи или запрос на решение человеку-эксперту. Обычно это происходит в рамках human-in-the-loop (HITL) — подхода, где человек остаётся конечным арбитром для сложных, неоднозначных или высокорисковых решений.

Зачем учитывать человеческий фактор

• Усталый оператор делает больше ошибок, медленнее реагирует, пропускает детали.
• Занятый оператор накапливает очередь → растёт latency ответа пользователю.
• Без учёта контекста (истории диалога, предыдущих эскалаций) оператор тратит время на разбор задачи.
• Если система эскалирует всегда и всем, операторы выгорают → увольнения, снижение качества.

2. Факторы: усталость (fatigue) vs занятость (occupancy)

Общее: оба фактора требуют динамического ограничения числа эскалаций на одного оператора. Различие: усталость — более долгосрочная характеристика (накапливается за смену), занятость — сиюминутная.

3. Проектирование системы delegation с учётом усталости

3.1 Лимиты на количество эскалаций

• N задач в час на одного оператора. Например, не более 5 сложных запросов в час или 10 простых.
• Кумулятивный лимит за смену (например, 30 запросов за 8 часов) — предотвращает выгорание.

3.2 Время суток и биологические ритмы

• Ночные часы (22:00–06:00) — выделять отдельную группу операторов (ночная смена) или повышать порог эскалации, чтобы меньше беспокоить.
• Использовать detection of fatigue по косвенным признакам: время работы без перерыва, количество ошибок подряд, скорость ответа.

Пример алгоритма (Python-псевдокод):

class FatigueManager:
    def can_delegate(self, operator, current_hour):
        # Лимит за смену
        if operator.tasks_today >= operator.max_tasks:
            return False
        # Ночной режим: эскалируем только критичные запросы
        if 22 <= current_hour or current_hour < 6:
            return operator.is_night_shift
        return True

4. Проектирование с учётом занятости

4.1 Проверка статуса оператора

• Онлайн/офлайн (по последнему пульсу, времени бездействия).
• В разговоре / на перерыве (интеграция с календарём или статусом из Slack/Teams).
• Текущая длина очереди (количество необработанных задач).

4.2 Приоритетная очередь

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

Типы очередей:

• FIFO — простейшая, но не учитывает срочность.
• PriorityQueue — с весами приоритетов.
• Round-robin с весами — для равномерной нагрузки.

Пример структуры:

from dataclasses import dataclass
from enum import Enum
import datetime

class Priority(Enum):
    LOW = 1
    NORMAL = 2
    CRITICAL = 3

@dataclass
class DelegationTask:
    task_id: str
    priority: Priority
    created_at: datetime.datetime
    context: str
    operator_id: str = None

5. Передача контекста (context handover)

Когда задача делегируется человеку, он должен быстро войти в курс дела. Контекст включает:

• История диалога пользователя с агентом.
• Результаты retrieval (найденные документы).
• Почему агент не смог решить сам (какие признаки, какой был threshold уверенности).
• Предыдущие эскалации по этому пользователю.

Формат передачи: структурированный JSON или markdown-сводка, встроенная в интерфейс оператора.

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

6. Обратная связь от операторов

Delegation не должен быть односторонним. Система должна собирать feedback от людей:

• Было ли делегирование уместным (Мог ли агент решить сам?)
• Достаточно ли данных в контексте
• Тот ли эксперт получил задачу (Нужен другой отдел?)

Фиксировать эти метрики и использовать для дообучения модели или правил делегирования.

Пример сбора:

# после завершения задачи оператором
feedback = {
    "task_id": "t123",
    "was_delegation_correct": True,
    "context_quality": 4,  # шкала 1-5
    "expert_match": True,
    "comment": "Не хватало последней версии документации"
}
# сохраняется в базу для анализа

7. Архитектурные паттерны для human-aware delegation

7.1 Центральный диспетчер (Dispatcher)

Отдельный сервис, который:

• Получает запросы от агентов.
• Проверяет статусы операторов.
• Применяет правила усталости/занятости.
• Назначает задачу конкретному оператору.

7.2 Шина событий (Event Bus)

Все эскалации публикуются в очередь (например, Redis Streams, RabbitMQ). Операторы подписываются на события в рамках своих навыков. Диспетчер может подписываться на события завершения и обновлять статусы.

7.3 Ограничение по времени

Если задача не взята оператором в течение T минут — эскалируется другому или возвращается агенту с сообщением «Оператор временно недоступен».

8. Метрики для оценки human delegation

9. Компромиссы и лучшие практики

• Автоматизация vs контроль: Чем больше правил, тем сложнее поддержка. Начинать с простых порогов и добавлять по мере накопления данных.
• Приватность: Сбор статусов (онлайн, усталость) должен быть согласован с операторами и соответствовать GDPR/локальным законам.
• Аварийный режим: Если все операторы заняты или офлайн — агент должен иметь fallback (например, отложить задачу или дать пользователю стандартный ответ с номером тикета).

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

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

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

• Python 3.10+ (FastAPI для API, asyncio для асинхронности).
• Redis (для очереди задач и хранения статусов операторов).
• SQLite (для логирования эскалаций и feedback).
• Docker Compose (для локального запуска).

Шаги:

1. Создайте модель оператора (id, имя, статус: online/offline/in_call, tasks_today, max_tasks, часовой пояс).
2. Реализуйте REST-эндпоинт /api/delegate, который принимает задачу (приоритет, контекст) и возвращает ID оператора или 503 (все заняты).
3. В логике делегирования проверьте: статус оператора → количество задач за час (хранить временные отметки в Redis sorted set) → приоритет.
4. Добавьте эмуляцию обработки: после взятия задачи оператор переходит в in_call на случайное время (5–30 сек), затем возвращает ответ.
5. Соберите метрики (среднее время ожидания, количество ошибок) и выведите их в /api/metrics.

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

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

Навигация

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