Тема: Приложение D. Калибровка порогов
Уровень сложности: Средний
Расчётное время изучения: 3-4 часа
Предварительные требования: Знакомство с базовыми концепциями SDD (Software-Defined Diagnostics/Delivery)
Понимание метрик MTTR, SLA, CI/CD и инцидент-менеджмента
Опыт работы с командной строкой Linux (bash) и Python
Базовое понимание мутационного тестирования и работы LLM (токены, спецификации)
Цели обучения: Понять и применять принцип парной калибровки порогов, избегая «демонтажа контура» при сдвиге только одной метрики.
Адаптировать пороги мутационного тестирования (глава 5) в зависимости от цены пропуска P0 и сложности графа маршрутов.
Настроить веса и пороги аукциона теневых спецификаций (глава 6) с учетом цены ложной эскалации и важности раннего сигнала.
Оптимизировать ярусные бюджеты токенов (глава 9) для различных профилей нагрузки и потоков инцидентов.
Распознавать и предотвращать проявления Закона Гудхарта (глава 10) при настройке guard-метрик.
Обзор: Данное учебное руководство посвящено Приложению D — калибровке порогов в процессе AgentClinic-production. Калибровка порогов — это не просто изменение чисел в конфигурационных файлах; это точная настройка баланса между рисками, стоимостью ошибок и доступными ресурсами. В материале собраны таблицы уровней (Низкий / По умолчанию / Высокий), практические упражнения по сдвигу порогов и индикаторы для их пересмотра. Ключевой акцент сделан на том, что пороги имеют смысл только в паре: изменение одного параметра должно сопровождаться пересчетом связанного, иначе система теряет устойчивость.
Ключевые концепции: Парная калибровка: Принцип, согласно которому пороги нельзя менять изолированно. Сдвиг одного значения без пересчета связанного ломает систему защиты (например, рост strict_reject_rate при падении depth_of_diagnostics — это симптом Гудхарта).
Мутационное тестирование (d.1): Оценка качества процесса диагностики на основе искусственных сбоев. Зависит от цены пропуска P0 (вероятности пропуска критического инцидента) и сложности графа маршрутов.
Отбор теневых спецификаций (d.2): Процесс аукциона, где веса (mttr_gain, early_signal, false_escalation) определяют, какие спецификации станут активными. Требует балансировки между скоростью реакции и количеством ложных срабатываний.
Ярусные бюджеты (d.3): Распределение вычислительных ресурсов (в токенах) между локальным (local) и внешним (frontier) уровнями. Изменение пропорций напрямую влияет на SLA фаз.
Защита от гудхарта (d.4): Механизм защиты метрик от манипуляций, когда оптимизация ради цифры ухудшает реальный результат. Контролируется через инварианты: silent_p0, manual_review_rate, audit_trace_coverage.
Production-готовность (d.5): Оценка готовности артефакта к релизу (по умолчанию 23/25). Включает жесткие блокирующие инварианты, такие как audit_trace_coverage = 1.0, которые невозможно обойти общей суммой баллов.
Практические упражнения: Название: Калибровка глубины диагностики (D.1)
Проблема: Вам нужно проверить, как ужесточение порога глубины диагностики (depth_of_diagnostics_min) повлияет на существующий валидатор. Требуется сравнить дефолтный запуск с запуском при завышенных требованиях (порог 5 вместо 3).
Решение: 1. Перейдите в директорию cd book2/examples/stress-mutator.
- Создайте папку out и скопируйте туда файл ожидаемых ошибок: cp expected/expected_failures.json out/expected_failures_depth5.json.
- Замените порог в файле: sed -i 's/"depth_of_diagnostics_min": 3/"depth_of_diagnostics_min": 5/' out/expected_failures_depth5.json.
- Запустите расчет с дефолтными значениями (пройдет успешно, так как средняя глубина 4 > 3).
- Запустите расчет с новыми ожиданиями (завершится с ошибкой, так как 4 < 5). Разница покажет цену ужесточения порога.
Сложность: intermediate
Название: Аукцион теневых спецификаций с консервативным профилем (D.2)
Проблема: Команда решила, что ложные эскалации обходятся слишком дорого. Необходимо запустить аукцион с новым профилем весов, где штраф за ложную эскалацию увеличен до 0.8, а вес раннего сигнала снижен до 0.2.
Решение: 1. Перейдите в cd book2/examples/shadow-auction.
- Запустите скрипт скоринга с новыми весами: python3 scripts/score.py --candidates candidates/candidates.yaml --incidents data/incidents.jsonl --weights "0.3,0.4,0.2,0.8" --out out/scorebook.json.
- Запустите принятие решений с бюджетом 2000 токенов: python3 scripts/decide.py --scorebook out/scorebook.json --budget-tokens 2000 --keep-threshold 0.70 --reject-threshold 0.40 --out-auction out/auction.json.
- Проанализируйте результат: shadow.p0.voice_handoff должен перейти в disputed, так как формула стала строже оценивать риски.
Сложность: advanced
Название: Тестирование ярусного бюджета при сбое (D.3)
Проблема: Необходимо смоделировать ситуацию с урезанным бюджетом в 5M токенов (4.5M local / 0.5M frontier) и проверить, как система переживет 45-минутный отказ локального яруса, чтобы token_health_min не упал ниже 0.5.
Решение: 1. Перейдите в cd book2/examples/budget-keeper.
- Скомпилируйте план: python3 scripts/compile.py --budget-spec specs/budget_network_5m.yaml --out out/budget_plan_5m.json.
- Запустите симуляцию сбоя: python3 scripts/simulate.py --plan out/budget_plan_5m.json --scenario scenarios/fail_local_45m.json --out out/fail_result_5m.json.
- Проверьте инварианты: python3 scripts/inspect.py --result out/fail_result_5m.json --query "failover_to_frontier==2 && degraded_queue==18 && token_health_min>=0.5".
- Убедитесь, что изменения бюджета без обновления фазовых квот вызывают ошибку (compile.py падает).
Сложность: intermediate
Название: Обход защит метрик Гудхарта (D.4)
Проблема: Проверить на практике, как ослабление даже двух независимых защит (например, manual_review_rate и silent_p0) позволяет «протолкнуть» плохой релиз, который должен был быть заблокирован.
Решение: 1. Перейдите в cd book2/examples/goodhart-validator.
- Ослабьте порог silent_p0 с 0.05 до 0.08 в локальной копии спецификации.
- Запустите валидацию (скрипт должен остаться 'красным', так как метрика 0.18 все еще выше 0.08).
- Создайте 'опасный' конфиг, ослабив сразу два порога (например, edge_drift до 0.10 и silent_p0 до 0.20).
- Запустите валидацию с плохими метриками (fixtures/new_metrics_bad.json) — система пройдет проверку, что доказывает недопустимость точечной калибровки.
Сложность: advanced
Кейсы: Название: Аномальный рост пропущенных критических инцидентов (P0)
Сценарий: В крупном финансовом проекте (высокий профиль риска) команда внедрила автоматизированный SDD-процесс. Изначально использовались дефолтные пороги AgentClinic: silent_p0 ≤ 5% и manual_review_rate ≥ 15%. Со временем разработчики начали жаловаться на замедление CI-пайплайна из-за ручных проверок.
Задача: Для ускорения процесса порог manual_review_rate был снижен до 8% (параметр 'Низкий'), при этом silent_p0 остался на уровне 5%. Это привело к тому, что система начала пропускать новые классы инцидентов, не попадавшие в историческую базу (теневые спецификации). Метрика MTTR формально снизилась, но количество катастрофических пропусков P0 выросло (симптом Закона Гудхарта).
Решение: Инженеры SRE вернулись к принципу парной калибровки. Порог manual_review_rate был возвращен к 15%. Одновременно с этим был увеличен бюджет образцов-подсказок до 12 слотов (уровень 'Высокий'), чтобы компенсировать нагрузку. Все изменения были задокументированы в validation.md.
Результат: Количество пропущенных P0 вернулось к допустимым значениям (< 1-2%). Процесс стабилизировался, система снова начала корректно классифицировать спорные кейсы за счет восстановления баланса между автоматизацией и ручным контролем.
Извлечённые уроки: Снижение доли ручных проверок без учета динамики входящего потока ведет к росту пропусков P0.
Метрики MTTR и manual_review_rate имеют отрицательную взаимозависимость; менять их нужно только парой.
Ускорение процесса не должно достигаться за счет ослабления guard-метрик.
Связанные концепции: Защита метрик от Гудхарта (D.4)
Парная калибровка порогов
Цена пропуска P0
Название: Деградация сервиса при отказе локального LLM-яруса
Сценарий: E-commerce платформа с потоком 600 инцидентов в день использовала бюджет 10M токенов с разбивкой 90% на local-coder и 10% на frontier. Это соответствовало профилю «По умолчанию», но реальный поток относился к категории «Высокий».
Задача: Во время сезонной распродажи локальный провайдер LLM начал регулярно падать (еженедельно). Резерв в 1M токенов на frontier-ярусе исчерпывался за минуты. Сработавший failover перевел систему в режим degraded_queue, что привело к задержкам восстановления критичных сервисов на часы.
Решение: Был произведен перерасчет ярусных бюджетов (Раздел D.3). Общий бюджет увеличен до 25M токенов, а пропорция изменена на 80/20. Добавлен дублированный провайдер для уровня local. Обновлены спецификации budget_plan_phases, чтобы frontier-ярус мог вмещать все «спорные» кейсы при отказе основного.
Результат: При следующем сбое локального кластера система безболезненно переключилась на frontier. token_health_min не опускался ниже 0.5, а обслуживание пользователей не прерывалось.
Извлечённые уроки: Бюджет токенов и пропорции local/frontier должны соответствовать реальному пиковому потоку инцидентов.
Разделение 9M/1M жестко связано с SLA по фазам; смена пропорций требует обновления спецификаций.
При еженедельных сбоях local-coder резерв должен составлять не менее 15-20%.
Связанные концепции: Ярусные бюджеты (D.3)
SLA-окно CI
Чувствительность к падению local-coder
Советы по изучению: Не меняйте пороги при первом чтении: Учебный минимум каждой главы рассчитан на пороги по умолчанию. Приступайте к калибровке только когда стандартные значения перестают подходить для вашего потока.
Ищите симптомы Гудхарта: Если одна метрика (например, strict_reject_rate или MTTR) стабильно улучшается, а связанная с ней (depth_of_diagnostics или manual_review_rate) падает — вы не оптимизируете процесс, вы ломаете систему защиты.
Документируйте каждое изменение: Любой сдвиг строки в таблицах должен сопровождаться записью в validation.md с четким обоснованием (изменилась цена пропуска, вырос поток и т.д.).
Визуализируйте зависимости: Используйте mermaid-схемы (как в Разделе D.4), чтобы понимать, как именно изменение узла (например, audit_trace_coverage) повлияет на весь граф метрик.
Дополнительные ресурсы: Главы 5, 6, 9, 10, 11 (базовый курс): Базовый контекст для понимания процессов, для которых в Приложении D настраиваются пороги.
Файл validation.md: Шаблон для фиксирования обоснований сдвигов порогов. Обязателен к использованию при переносе процесса в свой проект.
Репозиторий book2/examples/: Содержит исходные скрипты immunity_score.py, score.py, compile.py и конфигурационные файлы JSON/YAML для выполнения упражнений.
Резюме: Приложение D представляет собой глубокое погружение в тонкую настройку порогов AgentClinic-production. Главный вывод: пороги никогда не существуют в вакууме. Любая калибровка — это балансирование рисками. Вы не можете просто ослабить порог ручного ревью, чтобы ускорить пайплайн, не усилив одновременно защиту от пропуска P0. Вы не можете изменить бюджет токенов без пересмотра SLA фаз. Успешная эксплуатация системы требует непрерывного мониторинга индикаторов (например, доли спорных ревью или стоимости ложной эскалации) и своевременного, парного пересмотра конфигураций.