CVCodeVibers Telegram

AI-агенты и автоматизация Спроектировать внедрение

Fallback и проверка человеком в агентных системах

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

Обсудить внедрение Все темы Академии

Что такое Fallback в агентных системах

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

Отличие от чат-ботов: агенты принимают решения и выполняют действия. Поэтому fallback — это не только обработка ошибок, но и контроль за последствиями.

Архитектурный паттерн fallback

flowchart TD
    A[Запрос] --> B{Агент: цель + контекст + инструменты}
    B -->|Уверенность > порог| C[Выполнить действие]
    B -->|Уверенность < порог| D[Fallback-модуль]
    D --> E{Тип fallback}
    E -->|Критично| F[Human-in-the-loop: подтверждение]
    E -->|Не критично| G[Упрощённая логика / rule-based]
    E -->|Нужен контекст| H[Запрос уточнения у пользователя]
    C --> I[Логирование и аудит]
    F --> I
    G --> I
    H --> B

Пример: агент обработки заявок

Агент получает заявку на кредит. Он проверяет: возраст, доход, кредитную историю, внутренние правила.

  • Уверенность 92% → автоматически одобряет.
  • Уверенность 68% → перенаправляет в human-in-the-loop (менеджер получает уведомление в Telegram).
  • Нет данных по кредитной истории → запрашивает у пользователя подтверждение («Вы подтверждаете, что у вас нет долгов?»).
  • Сумма > 500 000 ₽ → всегда fallback на человека, независимо от уверенности.

Псевдокод fallback-логики

// Уровень уверенности от 0.0 до 1.0
confidence = agent.decide(request)
action = agent.propose_action(request)

// Пороги настраиваются в конфиге
if confidence < 0.75:
    fallback_type = determine_fallback_type(action, request)
    if fallback_type == 'human_approval':
        notify_human({
            action: action,
            confidence: confidence,
            context: request,
            deadline: '5m'
        })
        return { status: 'awaiting_review' }
    elif fallback_type == 'clarify':
        return { status: 'clarify', question: generate_question(action) }
    else:
        return execute_simplified_rule(action)
else:
    return execute(action)

Типичные ошибки

  • «Скрытый fallback»: агент возвращает «не могу», но не логирует причину и не передаёт контекст человеку.
  • Избыточный fallback: каждый второй запрос уходит на человека → теряется ценность автоматизации.
  • Отсутствие обратной связи: человек одобряет, но агент не учитывает результат в будущем (нет обучения).
  • Нет аудита: действия агента и fallback-решения не сохраняются → невозможно отследить ошибки.

Что проверить перед внедрением

КатегорияПроверка
АрхитектураЕсть ли отдельный fallback-модуль? Не смешан ли с основной логикой?
КонфигурацияНастроены ли пороги уверенности и критичности под каждый тип действия?
APIВозвращает ли агент структуру с `fallback_reason`, `confidence`, `next_step`?
РолиКто принимает решения в fallback? Менеджер, модератор, супер-пользователь?
ЛогированиеЗаписываются ли все fallback-события с контекстом и решением?
Обратная связьИспользуется ли результат human-проверки для дообучения агента?

Следующий шаг

Не начинайте с «полного fallback» — начните с контролируемого эксперимента: выберите 1–2 критичных действия (например, удаление данных или перевод средств), включите fallback и измерьте:

  • Долю fallback-запросов
  • Время ответа человека
  • Согласованность решений между людьми

После 2–3 итераций вы получите данные для оптимизации порогов и архитектуры. Подробнее о ролях и ответственности — в статье «Роли и ответственность в AI-внедрении».

Связанные темы