Проще говоря, fallback model нужна, чтобы пользователь не видел “все сломалось” при первой проблеме с основной моделью. Если дорогая или мощная модель недоступна, система может временно переключиться на более дешевую, быструю, локальную или модель другого провайдера.
Fallback не должен быть случайной заменой. У резервной модели могут быть другие возможности: меньше контекстное окно, хуже reasoning, другой формат structured output, другая политика безопасности и другая стоимость. Поэтому для важных сценариев нужно заранее проверить, какие задачи fallback-модель действительно тянет.
В production fallback model обычно используют вместе с model routing, retry, rate limit handling, observability и evals. Важно логировать каждое переключение: какая модель была основной, почему сработал fallback, какая модель ответила, сколько это стоило и не ухудшилось ли качество.
Примеры
- Основная модель вернула timeout, и система повторила запрос через более быструю fallback-модель.
- При rate limit у одного провайдера AI-агент временно переключается на модель другого провайдера.
- Если structured output не прошел валидацию, backend делает повтор на модели, которая стабильнее возвращает JSON.
- Для простого summary fallback-модель подходит, но для юридического анализа система оставляет no-go вместо снижения качества.
- Локальная LLM используется как fallback, если облачный API временно недоступен.
Где используется
- Повышение надежности LLM-приложения при сбоях API
- Обработка timeout, rate limit и временной недоступности модели
- Снижение стоимости через резервную более дешевую модель
- Переключение между провайдерами в AI-агенте
- Fallback для structured output и tool calling
- Локальная модель как резерв для self-hosted сценариев
- Мониторинг качества, latency и стоимости после переключения
Связанные термины
Частые вопросы
Чем fallback model отличается от model routing?
Model routing заранее выбирает подходящую модель по задаче, стоимости или сложности. Fallback model включается как резерв, когда основной путь не сработал или стал недоступен.
Всегда ли стоит использовать fallback-модель?
Нет. Для низкорисковых задач fallback полезен. Для юридических, финансовых, медицинских или критичных действий лучше иногда остановить процесс и отправить на human review, чем тихо ухудшить качество.
Что проверять у fallback-модели?
Качество на evals, контекстное окно, поддержку JSON и tool calling, latency, стоимость, политику безопасности, доступность региона и совместимость с промптами.
Как понять, что fallback работает плохо?
Смотрите рост ошибок, жалоб, повторных запросов, невалидного JSON, handoff to human, latency и падение качества на evals после переключений.
