Что хотят услышать интервьюеры:

Нужно показать, как система деградирует управляемо: при отсутствии сети и на слабом устройстве она не «падает», а переключается на локальный или упрощённый сценарий. Важны стратегия приоритизации, кэширование, локальная обработка и контроль качества ответа. Для senior-уровня ожидают понимание компромиссов между latency, качеством, батареей и размером модели.

Определение:

Fallback — это заранее предусмотренный запасной путь работы системы, который включается, когда основной сценарий недоступен или слишком дорог для устройства. В mobile/edge ML это обычно означает переход на офлайн-режим, локальную lightweight-модель, кэшированные результаты, эвристики или частичную функциональность вместо полного отказа.

При слабом устройстве fallback помогает снизить нагрузку на CPU, RAM, батарею и термопакет. При отсутствии интернета — сохранить базовую полезность продукта без обращения к серверу.

Пример использования:

Например, в мобильном ассистенте основной сценарий — запрос в облачную LLM. Если сеть недоступна, приложение переключается на локальную модель для коротких ответов, а при нехватке ресурсов — на шаблонные ответы и кэш FAQ.

def answer_query(query, network_ok, device_tier):
    if network_ok:
        return cloud_answer(query)

    if device_tier in ("high", "mid"):
        return local_model_answer(query)

    return cached_or_template_answer(query)

Пояснение кода:

Код показывает простую лестницу деградации.

Если интернет есть, используется основной облачный сценарий.
Если сети нет, но устройство достаточно сильное, включается локальная модель.
Если устройство слабое, возвращается самый дешёвый вариант: кэш или шаблонный ответ.

В реальной системе это обычно дополняют проверкой доступной памяти, времени отклика, температуры устройства и размером модели, чтобы не запускать тяжёлый fallback, который сам станет проблемой.

Ключевые моменты:

Fallback должен проектироваться заранее, а не добавляться как аварийный костыль.
Для offline-first сценариев полезны кэш, локальная база знаний и предзагруженные модели.
На слабых устройствах важны квантование, pruning, distillation и ограничение длины контекста.
Деградация должна быть управляемой: лучше меньшая точность, чем таймаут, краш или сильный drain батареи.
Полезно иметь несколько уровней fallback: облако → локальная модель → эвристика → статический ответ.
Нужно измерять не только качество, но и latency, RAM, CPU, battery impact и частоту срабатывания fallback.

Какие приёмы fallback при отсутствии интернета и слабом устройстве?