РУКОВОДСТВО · ОБНОВЛЕНО 2026-09-15
Fallback AI-моделей: отказоустойчивая схема без скрытых ошибок
Резервная модель поддерживает доступность только тогда, когда её контракт, качество, политика данных и цена заранее проверены.
Создайте список совместимых маршрутов для каждого сценария, классифицируйте временные ошибки и ограничьте retry. Перед переключением проверьте input, tools, schema, контекст и политику данных; после него запишите фактическую модель. Значимые записи выполняйте идемпотентно, чтобы неизвестный результат timeout не создал дубль.
1. Определите причины переключения
Подходящие сигналы — timeout, временная недоступность, rate limit или открытый circuit breaker. Неверный ключ, плохой prompt и unsupported parameter требуют исправления, а не обхода через цепочку провайдеров. Классификатор ошибок основывается на кодах и контракте API. Число попыток и общий deadline ограничены.
2. Составьте матрицу совместимости
Для резервной модели проверьте текст, изображения, максимальный контекст, tools, structured output, streaming и лимит ответа. Совпадающий endpoint не гарантирует свойства. Отдельно сравните правила хранения и разрешённый регион. Если безопасного эквивалента нет, верните понятную ошибку вместо скрытого перехода.
3. Защитите операции с эффектом
Timeout после tool call не сообщает, завершилось ли внешнее действие. Используйте idempotency key, журнал состояния и проверку результата перед повтором. Модельный ответ не должен сам инициировать второй платёж или публикацию. Чтение можно повторять свободнее, но оно тоже подчиняется deadline и rate limit.
4. Проверьте качество деградации
Запустите основной и резервный маршрут на одном eval set. Установите минимальный task success и список запрещённых критических ошибок. Если fallback умеет только текст, интерфейс не обещает анализ изображения. Для некритичного сценария допустим упрощённый ответ, но пользователь и мониторинг видят режим деградации.
5. Наблюдайте и восстанавливайте основной путь
Логируйте причину, попытку, latency, usage и фактический model id. Метрики показывают fallback rate, полные отказы и дополнительную стоимость. Circuit breaker временно прекращает запросы к больному маршруту и делает ограниченную проверку восстановления. Постоянный высокий fallback рассматривается как инцидент, а не нормальный балансировщик.
Частые вопросы
На какие ошибки переключать модель?
На заранее классифицированные временные сбои и rate limits.
Можно сделать цепочку из десяти моделей?
Это увеличит задержку, цену и непредсказуемость; используйте минимум проверенных.
Нужна ли идемпотентность?
Да, особенно если запрос мог вызвать запись до timeout.
Сообщать ли пользователю о fallback?
Показывайте деградацию, если она влияет на возможности или качество.
Как вернуть основной маршрут?
Через circuit breaker и ограниченную health-проверку после паузы.