Качество 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-внедрении.