Реализация Fallback-логики при недоступности AI-сервиса в мобильном приложении

TRUETECH занимается разработкой, поддержкой и обслуживанием мобильных приложений iOS, Android, PWA. Имеем большой опыт и экспертизу для публикации мобильных приложений в популярные маркеты Google Play, App Store, Amazon, AppGallery и другие.

Разработка и поддержка любых видов мобильных приложений:

Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

Это лишь некоторые из типы мобильных приложений, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента.

Услуги, которые мы предлагаем
Показано 1 из 1Все 1735 услуг
Реализация Fallback-логики при недоступности AI-сервиса в мобильном приложении
Средний
от 1 дня до 3 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    792
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    671
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1097
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    969
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    914
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    495

Реализация Fallback-логики при недоступности AI-сервиса в мобильном приложении

OpenAI возвращает 503 примерно раз в несколько недель — в часы пиковой нагрузки или при инцидентах. Для мобильного приложения, где AI-ассистент — часть core user flow, это означает белый экран или крэш, если fallback не предусмотрен заранее.

Уровни деградации

Правильный fallback — это не одна заглушка, а каскад уровней деградации:

Уровень 1: Retry с backoff. Транзиентные ошибки (429 Rate Limit, 503, timeout) — ретраим с exponential backoff. Три попытки: через 1с, 3с, 9с. Если все три провалились — переходим к уровню 2.

Уровень 2: Смена провайдера. Если основной провайдер — OpenAI, fallback — Anthropic Claude API или Google Gemini. Ответы разных провайдеров различаются по стилю, но для большинства задач качество сопоставимо. Ключи к резервным провайдерам хранятся в конфиге сервера.

Уровень 3: Локальная модель. Для критичных флоу — небольшая локальная модель (Phi-3.5-mini через llama.cpp, ~2.2 ГБ). Качество ниже GPT-4o, но работает без сети. На iOS запускается через MLModel или llama.swift.

Уровень 4: Статические ответы. FAQ и часто задаваемые вопросы — из кэша или базы данных. Пользователь получает полезный ответ, не зная, что AI недоступен.

Реализация circuit breaker

Паттерн Circuit Breaker предотвращает лавинообразную нагрузку на деградирующий сервис:

// Android — Kotlin
class AIServiceCircuitBreaker {
    private var failureCount = 0
    private var lastFailureTime = 0L
    private val failureThreshold = 5
    private val resetTimeout = 60_000L // 1 минута

    enum class State { CLOSED, OPEN, HALF_OPEN }
    var state = State.CLOSED

    fun canCall(): Boolean = when (state) {
        State.CLOSED -> true
        State.OPEN -> {
            if (System.currentTimeMillis() - lastFailureTime > resetTimeout) {
                state = State.HALF_OPEN
                true
            } else false
        }
        State.HALF_OPEN -> true
    }

    fun recordSuccess() {
        failureCount = 0
        state = State.CLOSED
    }

    fun recordFailure() {
        failureCount++
        lastFailureTime = System.currentTimeMillis()
        if (failureCount >= failureThreshold) state = State.OPEN
    }
}

UX при деградации

Пользователь не должен видеть технические ошибки. При fallback на статические ответы — показываем обычный UI без маркировки. При полной недоступности — «Ассистент временно недоступен, попробуйте через несколько минут» вместо сырого Error 503.

Индикатор деградации полезен во внутренней аналитике: логируем каждый fallback с уровнем и причиной.

Ориентиры по срокам

Базовый retry с backoff — 1 день. Полный каскад с circuit breaker и двумя провайдерами — 2–3 дня.