Проще говоря, fallback rate отвечает на вопрос: “как часто наш AI не справляется штатно?”. Если показатель растет, это может означать проблемы с основной моделью, промптом, RAG, tool calling, rate limits, качеством данных, guardrails или интеграциями.
Fallback rate полезен для LLMOps и поддержки AI-агентов. Он помогает увидеть, где автоматизация действительно работает, а где только красиво передает задачи дальше. Например, если 40% запросов уходят оператору, агент может быть полезен, но не решает основную задачу самостоятельно.
Высокий fallback rate не всегда плох. В рискованных сценариях лучше передать человеку, чем выполнить опасное действие. Но важно понимать причины fallback: timeout, невалидный JSON, низкая уверенность, отсутствие данных, отказ guardrail, ошибка API, неподходящий intent или запрос вне зоны ответственности.
Примеры
- После смены модели fallback rate вырос, потому что ответы чаще не проходят JSON Schema.
- AI-агент поддержки передает 25% диалогов оператору из-за низкой confidence score.
- При rate limit основного провайдера система чаще переключается на fallback model.
- Рост fallback rate в RAG-сценарии показал, что база знаний устарела и агент не находит источники.
- В финансовых сценариях высокий fallback rate допустим, если спорные операции уходят на human approval.
Где используется
- Мониторинг надежности AI-агента и LLM-приложения
- Контроль fallback-моделей, retry и handoff to human
- Поиск проблем в RAG, tool calling и structured output
- Оценка качества guardrails и policy gates
- Сравнение версий модели, промпта и retrieval pipeline
- Анализ нагрузки на операторов и approval queue
- Go/no-go решение перед production-запуском AI-системы
Связанные термины
Частые вопросы
Что считать fallback?
Любой уход с основного сценария: резервная модель, retry после ошибки, handoff человеку, safe refusal, шаблонный ответ, read-only режим или задача в очередь вместо автоматического действия.
Высокий fallback rate — это всегда плохо?
Не всегда. В опасных сценариях fallback защищает систему. Но высокий показатель нужно объяснить: он может указывать на плохой retrieval, слабый промпт, ошибки API, слишком строгие guardrails или нехватку данных.
Как снизить fallback rate?
Разобрать причины fallback, улучшить промпт, добавить данные в базу знаний, настроить tool schema, исправить интеграции, выбрать подходящую модель, улучшить evals и уточнить пороги confidence.
Какие разрезы полезно смотреть?
Причина fallback, тип запроса, модель, инструмент, источник данных, клиентский сегмент, версия промпта, latency, стоимость, оператор после handoff и итоговый resolution rate.
