Качество AI-продуктов Спроектировать внедрение

UX и fallback-сценарии для AI-продукта

AI-продукты неизбежно сталкиваются с неопределённостью. Внедрение без fallback-сценариев — это риск потери доверия. Здесь — архитектурный подход к управлению неудачами: от интерфейса до логирования.

Что такое fallback-сценарий в AI-продукте?

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

В отличие от традиционных систем, где fallback — это 500-я ошибка, в AI-продуктах он должен сохранять пользовательский контекст и предоставлять путь к разрешению ситуации.

Архитектурный уровень fallback: 4 слоя

flowchart TD
    A[Пользовательский запрос] --> B{AI-агент}
    B -->|Успех| C[Ответ]
    B -->|Неуверенность| D[Fallback-уровень 1: уточнение]
    D -->|Не помогло| E[Fallback-уровень 2: человек-in-the-loop]
    E -->|Необходимо| F[Fallback-уровень 3: откат/ручной режим]
    F -->|Критично| G[Fallback-уровень 4: лог + уведомление]

Каждый уровень — это не «запасной вариант», а часть UX-потока. Чем выше уровень, тем больше вовлечения человека и больше контроля.

Примеры fallback-сценариев

  • Неуверенность модели: «Я не уверен, что понял ваш запрос. Могли бы уточнить: вы хотите создать отчёт по продажам за апрель или за квартал?»
  • Отсутствие данных: «У меня пока нет доступа к данным по отделу «Инновации». Пока — отчёт по остальным отделам. Могу ли запросить доступ?»
  • Ограничение прав: «Я не могу изменить статус сделки — у меня нет прав. Отправить на подтверждение менеджеру?»
  • Технический сбой: «Сервис временно недоступен. Сохраняю запрос в очередь — обработаю, как только восстановится.»

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

// Уровень 1: проверка уверенности
if agent.confidence < 0.85:
    return fallback_request_clarification()

// Уровень 2: проверка доступа к данным
if not data_source.has_permission(request.context):
    return fallback_human_review(
        action="grant_access",
        reason="missing_data_permission"
    )

// Уровень 3: критическая ошибка
if system_error.is_critical():
    log_critical_error()
    notify_admin(channel="slack", priority="high")
    return fallback_manual_mode(
        message="Система перешла в ручной режим. Обратитесь к оператору."
    )

Ключевые параметры: confidence, permission_check, error_severity. Все fallback-сценарии должны возвращать структурированный объект с action, message, next_step.

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

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

Что проверить перед запуском

КритерийПроверка
Все API-вызовы имеют fallback-обработку?✅ / ❌
UX-тексты fallback-сценариев проверены на эмпатичность?✅ / ❌
Логирование fallback-событий включено и структурировано?✅ / ❌
Механизм «человек-in-the-loop» настроен и протестирован?✅ / ❌
Есть метрика: % fallback-сценариев по типам?✅ / ❌

Рекомендуемый KPI: не более 15% fallback-сценариев на 1000 запросов. Выше — сигнал к улучшению качества данных или модели.

Следующий шаг: интеграция с системой контроля качества

Fallback-сценарии — это не только UX, но и источник данных для улучшения продукта. Каждый fallback должен:

  • Записываться в лог с контекстом: запрос, модель, confidence, действие, пользователь.
  • Попадать в дашборд «Качество AI» (в CodeVibers — Telegram-канал есть примеры).
  • Триггерить автоматический ревью: если fallback по одному типу растёт — запускается аудит данных или переобучение.

Следующая тема: Роли и ответственность в AI-внедрении.