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

Review Decision Codes в 2026: как кодировать решения reviewer-а так, чтобы review был полезен не только сейчас, но и для системы

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

Review decision codes в 2026 нужны потому, что human review без структурированного исхода оставляет слишком мало полезного сигнала для системы. Reviewer нажал approve, reject или request changes, но команда не понимает, это было из-за слабого evidence, policy mismatch, missing approval, stale data или слишком широкого action scope. Без decision codes review остаётся одноразовым действием вместо источника операционного знания.

Decision code — это короткая машинно-читаемая причина решения reviewer-а: например, missing_evidence, policy_conflict или scope_too_broad.
Самый вредный anti-pattern - хранить только финальный outcome без причины. Тогда review не помогает ни аналитике, ни улучшению пайплайна, ни будущему routing.

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

Хорошая система review decision codes в 2026 обычно определяет:

  1. Какие исходы вообще бывают
  2. Какие причины стоят за каждым исходом
  3. Какие коды обязательны для reviewer-а
  4. Как codes влияют на downstream routing
  5. Как по ним считать качество review и продукта

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

  • approve/reject без reason code слишком слабы для operational анализа;
  • decision code должен быть коротким, стабильным и понятным;
  • коды нужны не только для аудита, но и для policy improvement;
  • свободный текст полезен как дополнение, но не как замена.
Без техники
Кейс отклонён, но никто не знает почему.
С техникой
Кейс отклонён с кодом `missing_policy_basis`, поэтому система знает, что проблема не в reviewer mood, а в packet quality.
ПромптDecision-code intuition
Почему human review полезнее с decision codes?
Ответ модели

Потому что тогда outcome превращается в структурированный сигнал: система понимает не только что произошло, но и почему.

1. Review outcome и decision reason нужно разделять

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

  • final outcome;
  • reason code;
  • optional free-text note;
  • follow-up action.

Так one-click decision не скрывает реальную причину.

2. Codes должны быть ограниченным словарём

Обычно полезны категории:

  • evidence issues;
  • policy issues;
  • scope issues;
  • authority issues;
  • quality or formatting issues;
  • external dependency issues.

Слишком свободный набор ломает сравнимость данных.

Если две команды описывают один и тот же review-failure разными словами, decision codes почти наверняка недостаточно нормализованы.

3. Decision codes должны влиять на routing

Например:

  • missing_evidence -> enrichment;
  • policy_conflict -> policy owner;
  • scope_too_broad -> planner rewrite;
  • authority_missing -> approval path;
  • unsafe_in_degraded_mode -> manual mode.

Так review становится частью control plane, а не только ручным фильтром.

4. Codes полезны и для обучения reviewer-ов

Они помогают увидеть:

  • разные причины отклонений по reviewer-ам;
  • drift в трактовке policy;
  • частые packet defects;
  • повторяющиеся blind spots у агентов.

Это делает calibration гораздо сильнее.

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

Outcome without reason

Есть только approve/reject.

Too many codes

Словарь разрастается и теряет смысл.

Free-text only

Невозможно агрегировать причины.

Codes do not affect routing

Сигнал собирается, но ни на что не влияет.

Reviewer inconsistency

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

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

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

  • review decisions by code;
  • top rejection codes by workflow;
  • repeated codes on same case family;
  • reviewer disagreement by code;
  • improvement in packet quality after code-specific fixes;
  • share of decisions without valid code.

Плюсы

  • Decision codes превращают review в структурированный operational signal
  • Помогают улучшать routing и packet quality
  • Усиливают calibration и auditability
  • Упрощают анализ причин ручных вмешательств

Минусы

  • Нужно поддерживать словарь кодов и обучение reviewer-ов
  • Слишком широкий словарь быстро деградирует
  • Часть кейсов всё равно требует free-text контекста
  • Без downstream использования коды становятся бюрократией

Пример decision codes

decision_codes:
  - missing_evidence
  - policy_conflict
  - scope_too_broad
  - authority_missing
  - approve_with_warning

Простой routing sketch

def next_step(decision_code):
    mapping = {
        "missing_evidence": "enrichment",
        "policy_conflict": "policy_review",
        "authority_missing": "approval_path",
    }
    return mapping.get(decision_code, "manual_triage")

Практический совет: хороший review outcome отвечает не только на вопрос "что решил reviewer", но и на вопрос "какой класс проблемы система должна исправить дальше".

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

1. Зачем review decision codes нужны поверх approve/reject?

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

3. Что полезно делать с decision codes downstream?

Источники

  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
Предыдущая
Reasoning-модели в продакшене: o3 API vs deepseek-reasoner API vs self-hosted QwQ-32B
Следующая
Review Escalation Thresholds в 2026: когда кейс уже пора отправлять человеку, а не дожимать агентом