AI-порталAI-портал

Degraded Mode Risk Budgets в 2026: сколько ослабления системы ещё допустимо, прежде чем нужно ужесточать режим

Degraded mode risk budgets в 2026: как задавать допустимый объём degraded behavior, чтобы продукт не жил слишком долго в ослабленном состоянии и не накапливал скрытый риск.

Degraded mode risk budgets в 2026 нужны потому, что degraded mode часто воспринимают слишком бинарно: либо "мы уже в нём", либо "всё нормально". На практике degraded behavior может накапливаться постепенно: больше fallback-ответов, меньше tool confirmation, больше manual overrides, выше доля low-trust outputs, длиннее review queue. Если у системы нет risk budget, она может формально ещё не считаться broken, но уже долго жить в режиме, где качество и безопасность заметно ниже нормы.

Risk budget — это допустимый объём degraded behavior за период или для конкретного flow. Когда бюджет исчерпан, система должна ужесточать routing, расширять review или сужать autonomy.
Самый вредный anti-pattern - считать degraded mode терпимым сколько угодно долго, пока нет явной катастрофы. Это постепенно нормализует слабые решения как новую обычную работу системы.

Короткая версия

Хороший degraded-mode risk budget в 2026 обычно задаёт:

  1. Какие degraded signals считаются расходом бюджета
  2. Какой объём допустим
  3. На каком уровне бюджет считается исчерпанным
  4. Какие guardrails включаются после исчерпания
  5. Как budget различается по risk class

Что особенно важно

  • бюджет нужен не только для uptime, но и для quality erosion;
  • low-risk и high-risk flows должны иметь разные budgets;
  • exceeded budget должен менять поведение системы;
  • budget полезен как early-warning до большого incident.
Без техники
Система неделями живёт с повышенным fallback rate, но никто не считает это отдельной проблемой.
С техникой
Рост degraded behavior расходует risk budget, после чего routing становится строже и risky paths сужаются.
ПромптRisk-budget intuition
Почему degraded mode полезно измерять через budget?
Ответ модели

Потому что это позволяет видеть накопление риска заранее и не считать длительное ослабление системы нормой.

1. Budget должен отражать именно расход risk capacity

Полезные расходы бюджета:

  • fallback auto-show;
  • missing citations in sensitive flows;
  • tool confirmation misses;
  • manual override spikes;
  • low-trust output consumption.

Так degraded state измеряется не только через availability, но и через качество решений.

2. Budget должен быть разным по flows

Например:

  • low-risk FAQ может терпеть больше degraded responses;
  • customer-visible actions — меньше;
  • money or compliance flows — почти ноль;
  • internal draft workflows — умеренно больше.

Один общий бюджет скрывает реальную опасность.

Если продукт умеет терпеть degraded behavior только в одних сценариях, а budget считается агрегированно по всем сценариям, система почти наверняка недооценивает реальные риски.

3. Budget должен иметь consequence

После исчерпания бюджета полезно:

  • widen review coverage;
  • disable auto-actions;
  • tighten authority boundaries;
  • suppress weak fallback paths;
  • trigger incident or change freeze.

Без consequence budget превращается в красивый график.

4. Budget помогает выходить из "почти нормального" режима

Он показывает:

  • продукт ещё technically жив;
  • но degraded behavior уже слишком дорог;
  • нормализация слабых решений недопустима;
  • требуется либо remediation, либо stricter mode.

Это особенно полезно до полной деградации.

5. Что особенно часто ломают команды

No budget, only incidents

Замечают только крупные поломки.

One budget for all flows

Risky и low-risk use cases смешаны.

Budget without action

Нарушение ничего не меняет.

Budget tracks uptime only

Не учитывается erosion of decision quality.

Chronic over-budget treated as normal

Ослабленный режим становится новым baseline.

6. Какие метрики полезны

Полезно считать:

  • degraded budget burn rate;
  • percent of time over budget;
  • budget breaches by flow class;
  • actions disabled after budget breach;
  • review expansion caused by budget exhaustion;
  • recurrence of over-budget periods.

Плюсы

  • Risk budgets делают degraded mode измеримым и управляемым
  • Ловят накопление слабых решений до большого incident
  • Помогают различать acceptable degradation и dangerous normalization
  • Связывают quality erosion с routing actions

Минусы

  • Нужно определить, что именно считается расходом бюджета
  • Разные flows требуют разной tolerances
  • Слишком чувствительный budget может часто триггерить guardrails
  • Без хорошей observability расчёт будет неточным

Пример risk budget

degraded_budgets:
  low_risk_info:
    max_fallback_rate: 0.15
  sensitive_actions:
    max_fallback_rate: 0.01
    max_missing_confirmation: 0

Простой breach check

def budget_exceeded(flow):
    return flow["fallback_rate"] > flow["max_fallback_rate"]

Практический совет: degraded mode risk budget полезен тогда, когда он позволяет системе раньше ужесточить поведение, а не ждать, пока слабый режим окончательно станет аварией.

Проверьте себя

1. Зачем degraded mode risk budget нужен поверх incident monitoring?

2. Какой anti-pattern особенно вреден?

3. Что полезно делать после исчерпания бюджета?

Источники

  1. OpenAI API Docs - Evaluation best practices
  2. OpenAI Agents SDK - Run state
  3. OpenAI Agents SDK - Human in the loop
  4. OpenTelemetry GenAI Semantic Conventions
Предыдущая
Degraded Mode Exit Criteria в 2026: когда систему можно считать вышедшей из ослабленного режима
Следующая
Degraded Mode Rollback Triggers в 2026: когда нужно быстро вернуть систему обратно в более строгий режим