OpenAI повертає 503 приблизно раз на кілька тижнів — у години пікового навантаження або при інцидентах. Для мобільного додатку, де AI-асистент — частина core user flow, це означає білий екран або крэш, якщо fallback не передбачено заздалегідь. У таких сценаріях накопичується черга запитів, зростає latency, і користувачі йдуть. Щоб цього уникнути, ми проєктуємо каскад деградації: retry з exponential backoff, а потім перемикання на резервний AI-сервіс, наприклад Anthropic Claude або Google Gemini. Наші рішення перевірені на проєктах з мільйонною аудиторією. Якщо ваш AI-асистент — ключовий функціонал, без fallback-логіки не обійтися. Середній час простою знижується з 3 годин до 5 хвилин, що економить бізнесу до $5 000 щомісяця. Скорочення витрат на підтримку досягає 30% за рахунок автоматичного відновлення.
Проблема: AI-сервіс недоступний
Збої бувають різними: перевантаження провайдера, мережеві проблеми, ліміти. Без fallback користувач бачить помилку або нескінченне завантаження. Результат — падіння утримання та негативні відгуки. Патерни retry та circuit breaker — база, але для критичних сценаріїв потрібен каскад.
Як працює каскад деградації?
Правильний 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 недоступний.
Таблиця порівняння рівнів деградації
| Рівень | Затримка | Якість | Вартість виконання |
|---|---|---|---|
| Retry | ~13 с | Повна | Безкоштовно |
| Зміна провайдера | ~1 с | 90-95% | Запити до API |
| Локальна модель | ~2 с | 70-80% | Енергія пристрою |
| Статичні відповіді | <100 мс | Точні лише для FAQ | Нульова |
Чому circuit breaker — обов'язковий патерн?
Патерн Circuit Breaker запобігає лавиноподібному навантаженню на сервіс, що деградує. Він швидший, ніж простий retry, і економить ресурси клієнта та сервера.
// 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
}
}
Приклад реалізації circuit breaker на iOS (Swift)
enum CircuitBreakerState {
case closed, open, halfOpen
}
class CircuitBreaker {
private var state: CircuitBreakerState = .closed
private var failureCount = 0
private let threshold = 5
private let timeout: TimeInterval = 60
private var lastFailure: Date?
func canCall() -> Bool {
switch state {
case .closed: return true
case .open:
if let lastFailure = lastFailure, Date().timeIntervalSince(lastFailure) > timeout {
state = .halfOpen
return true
}
return false
case .halfOpen: return true
}
}
func recordSuccess() {
failureCount = 0
state = .closed
}
func recordFailure() {
failureCount += 1
lastFailure = Date()
if failureCount >= threshold { state = .open }
}
}
Порівняння retry-стратегій
| Стратегія | Час між спробами | Кількість спроб | Застосовність |
|---|---|---|---|
| Fixed | 5 с | 3 | Низьке навантаження |
| Exponential | 1 с, 3 с, 9 с | 3-5 | Транзисторні помилки |
| Jitter | 1-5 с (випадково) | 3-5 | Rate Limit |
Як працюють статичні відповіді?
Статичні відповіді — це заздалегідь підготовлені повідомлення для часто задаваних питань. Вони зберігаються у вигляді пар ключ-значення в локальній базі або кеші. При недоступності всіх вищестоящих рівнів система повертає найбільш релевантну відповідь на основі аналізу запиту (наприклад, через TF-IDF). Такий підхід гарантує миттєву відповідь без мережі.
Як тестувати fallback-логіку?
Використовуємо інтеграційні тести, що симулюють 503 помилку від основного провайдера. Перевіряємо перемикання на резервного, коректне логування рівнів деградації та UX без технічних повідомлень. Для автоматизації запускаємо тести на CI при кожному коміті.
Покроковий план впровадження fallback
- Аналіз поточного стеку та інтеграція з AI-провайдерами — виявлення точок відмови.
- Проєктування каскаду деградації (retry, circuit breaker, зміна провайдера, локальна модель).
- Реалізація retry з exponential backoff та jitter на клієнті.
- Впровадження circuit breaker з порогами спрацьовування.
- Підключення резервного провайдера та локальної моделі.
- Розробка статичних відповідей для частих запитів.
- Написання тестів (unit, integration) для кожного рівня.
- Документація з логіки fallback та моніторингу.
- Інструкція з додавання нових провайдерів.
- Підтримка після впровадження (1 місяць).
UX при деградації
Користувач не повинен бачити технічні помилки. При fallback на статичні відповіді — показуємо звичайний UI без маркування. При повній недоступності — «Асистент тимчасово недоступний, спробуйте через кілька хвилин» замість сирого Error 503.
Індикатор деградації корисний у внутрішній аналітиці: логуємо кожен fallback з рівнем та причиною. Це дозволяє виявити проблемні провайдери та покращити стабільність.
Що входить в роботу
- Аналіз поточного стеку та інтеграція з AI-провайдерами
- Проєктування та реалізація каскаду деградації (retry, circuit breaker, зміна провайдера, локальна модель)
- Налаштування статичних відповідей та кешу
- Написання тестів (unit, integration)
- Документація з логіки fallback та моніторингу
- Інструкція з додавання нових провайдерів
- Підтримка після впровадження (1 місяць)
Орієнтири за термінами
Базовий retry з backoff — 1 день. Повний каскад з circuit breaker та двома провайдерами — 2–3 дні. Оцінимо точніше на безкоштовній консультації.
Наші метрики
5+ років на ринку мобільної розробки, 50+ проєктів з AI-інтеграцією, сертифіковані інженери (iOS, Android, Flutter). Гарантія на реалізований функціонал. Замовте обстеження вашого поточного AI-стека — ми знайдемо слабкі місця. Отримайте безкоштовну консультацію з проєктування відмовостійкості. Зв'яжіться з нами для оцінки проєкту.