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

Review Escalation Thresholds в 2026: когда кейс уже пора отправлять человеку, а не дожимать агентом

Review escalation thresholds в 2026: как задавать пороги для human review, чтобы агент не эскалировал всё подряд, но и не тянул risky кейсы слишком долго внутри automation.

Review escalation thresholds в 2026 нужны потому, что human review ломается в обе стороны. Если порог слишком низкий, очередь забивается слабыми кейсами, которые агент ещё мог бы дообогатить или безопасно закрыть сам. Если порог слишком высокий, risky cases слишком долго живут внутри automation и доходят до человека уже поздно или в испорченном виде. Поэтому review threshold должен быть не интуицией команды, а явной operational границей.

Escalation threshold — это условие, при котором кейс перестаёт обрабатываться автоматически и переходит в human review или другой контролируемый path.
Самый вредный anti-pattern - строить escalation только по одному confidence score. Для реального review threshold обычно важнее risk, evidence quality, authority и degraded state.

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

Хороший review-escalation threshold в 2026 обычно учитывает:

  1. Класс риска
  2. Качество evidence
  3. Полномочность агента
  4. Состояние support-path
  5. Стоимость ошибки и стоимость review

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

  • threshold должен быть разным для разных action classes;
  • low confidence не всегда требует review, а high confidence не всегда позволяет auto-action;
  • escalation полезно отделять от enrichment;
  • thresholds должны быть измеримы и калибруемы.
Без техники
Любой сомнительный кейс сразу уходит человеку или, наоборот, тянется до последнего внутри automation.
С техникой
Threshold учитывает risk class, sufficiency of support и authority boundary, поэтому review включается в нужный момент.
ПромптEscalation-threshold intuition
Почему одного confidence score мало для решения об escalation?
Ответ модели

Потому что уверенность модели не заменяет evidence quality, authority limits и стоимость ошибки в конкретном действии.

1. Threshold должен смотреть на тип решения

Например:

  • low-risk informational answer;
  • customer-visible message;
  • refund or money movement;
  • policy exception;
  • cross-tenant action.

У этих классов разная tolerance к автоматизации.

2. Evidence threshold и review threshold не одно и то же

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

  • нужно ли ещё дообогащать packet;
  • уже пора передавать человеку;
  • кейс надо вообще блокировать.

Это лучше, чем один грубый switch между auto и review.

Если команда не может отдельно ответить на вопросы "кейс недостаточно готов" и "кейс слишком рискованный для авто-решения", thresholds почти наверняка смешаны.

3. Threshold должен учитывать degraded mode

Даже обычно безопасный flow может требовать review, если:

  • tool confirmation unavailable;
  • retrieval degraded;
  • citations слабые;
  • approval path частично недоступен;
  • routing ушёл в fallback model tier.

Threshold без учёта degraded state быстро становится слепым.

4. Threshold должен быть калибруемым

Полезно анализировать:

  • under-escalation incidents;
  • over-escalation backlog;
  • decision reversals;
  • manual completion rate after review;
  • false-positive review triggers.

Так threshold можно настраивать по реальным потерям, а не по вкусу команды.

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

One threshold for everything

Все workflows получают одинаковый порог.

Confidence-only escalation

Игнорируются authority и evidence sufficiency.

Review used instead of enrichment

Человеку отправляют сырые кейсы.

Threshold hidden in prompt folklore

Нет явной policy и runtime check.

No recalibration

Порог зафиксирован навсегда, хотя продукт меняется.

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

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

  • escalation rate by action class;
  • over-escalation rate;
  • under-escalation incidents;
  • reversal rate after auto-action;
  • review queue load by trigger type;
  • percent of escalated cases missing evidence minimum.

Плюсы

  • Thresholds делают review более предсказуемым
  • Помогают балансировать cost of review и cost of error
  • Снижают шум в очереди
  • Улучшают связку между risk policy и routing

Минусы

  • Нужно калибровать thresholds по реальным данным
  • Часть кейсов всё равно остаётся на границе
  • Слишком жёсткий порог может переэскалировать
  • Слишком мягкий порог приводит к under-review

Пример threshold policy

review_thresholds:
  low_risk_info:
    require_review: false
  refund_action:
    require_review_if:
      - evidence_level != full
      - approval_missing
      - degraded_mode

Простой gate

def should_escalate(case):
    return case["risk_class"] != "low_risk_info" and (
        case["evidence_level"] != "full" or case["authority_ok"] is False
    )

Практический совет: хороший escalation threshold отвечает не на вопрос "агент уверен?", а на вопрос "достаточно ли у системы оснований и полномочий, чтобы не включать человека сейчас?".

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

1. Почему одного confidence score мало для review threshold?

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

3. Что полезно измерять для калибровки threshold?

Источники

  1. OpenAI Agents SDK - Human in the loop
  2. LangGraph Docs - Human in the loop
  3. OpenAI API Docs - Evaluation best practices
  4. OpenAI API Docs - Trace grading
Предыдущая
Review Decision Codes в 2026: как кодировать решения reviewer-а так, чтобы review был полезен не только сейчас, но и для системы
Следующая
Review Evidence Minimums в 2026: какой минимум доказательств нужен человеку перед risky decision