主题: Прикладная часть 6. Отбор теневых спецификаций
难度等级: 中等
预计学习时间: 4-6 часов (включая работу с учебными скриптами и калибровку)
前置要求: Понимание принципов управления инцидентами (triage, post-mortem, MTTR)
Базовые навыки работы с командной строкой (CLI) и Python
Общее понимание концепции LLM-агентов и промпт-инжиниринга (few-shot примеры)
Знакомство с форматами данных YAML и JSON
学习目标: Переводить неформальные наблюдения и операционный фольклор в структурированный формат 'контекст → признак → наблюдаемый эффект'.
Рассчитывать предсказательную ценность (score) эвристик на основе исторических инцидентов с использованием заданной формулы.
Проводить автоматизированный 'аукцион' для отбора победителей под ограниченный бюджет токенов (few-shot слоты).
Формировать версионированные блоки для QWEN.md и карантинные записи с причинами отклонения.
Анализировать влияние весовых коэффициентов (в частности, штрафа за ложную эскалацию) на результаты аукциона.
概述: Данный раздел посвящен управлению неформальными наблюдениями, возникающими при поддержке программных систем. Часто инженеры используют полезные эвристики (например, 'отвечать короче ночью' или 'при повторном симптоме запрашивать историю'), которые сложно формализовать как строгие системные требования. Здесь вводится понятие теневых спецификаций (shadow specs) — проверяемых эвристик, помогающих на фазе triage. Вы узнаете, как превратить эти наблюдения в измеримые слоты, провести их оценку на исторических данных (аукцион) и принять обоснованное решение: добавить ли эвристику как версионированный образец-подсказку (few-shot) в QWEN.md или отправить в карантин из-за высокого риска ложных срабатываний.
关键概念: Теневая спецификация (shadow spec): Проверяемая эвристика из операционной практики. Она не является обязательным системным требованием, но помогает агенту или инженеру быстрее принимать решения на фазе triage.
Образец-подсказка (few-shot): Короткий пример в промпте, который показывает желаемый формат ответа или логику поведения. В контексте теневых спецификаций это полезная эвристика, оформленная для внедрения в QWEN.md.
Журнал оценок (scorebook): Журнал экономики теневых спецификаций. Хранит исходные данные, формулу оценки, пороги, бюджет, версии кандидатов и протокол принятия решения. Защищает от 'споров авторитетов' и ловушки Гудхарта.
Аукцион (auction): Процесс ранжированного отбора эвристик под строго ограниченный контекстный бюджет (в токенах или слотах).
Карантин (quarantine): Статус, который получает эвристика, не прошедшая порог качества. Кандидат не удаляется бесследно, а сохраняется с причиной отклонения (например, high_false_escalation) и датой пересмотра.
Формула оценки: Математическое выражение для расчета ценности эвристики. Базовый учебный вариант: score = 0.5mttr_gain + 0.3early_signal + 0.2coverage - 0.4false_escalation.
Дрейф данных (drift): Рассинхронизация временных шкал и идентификаторов в источниках инцидентов. Требует дедупликации и нормализации перед оценкой, чтобы избежать ложных ранних сигналов.
练习题: 名称: Запуск оценки теневых кандидатов
问题: Вам необходимо рассчитать оценку (score) для списка теневых спецификаций на основе симулированных исторических инцидентов. Используйте базовые веса формулы. Цель — получить корректный журнал оценок (scorebook.json) для последующего принятия решений.
解决方案: 1. Откройте терминал и перейдите в каталог примера: cd book2/examples/shadow-auction. 2. Запустите скрипт оценки: python3 scripts/score.py --candidates candidates/candidates.yaml --incidents data/incidents.jsonl --weights 0.5,0.3,0.2,0.4 --out out/scorebook.json. 3. Сравните полученный результат с эталоном: diff -u outputs/scorebook.example.json out/scorebook.json.
难度: beginner
名称: Аукцион: отбор победителей и отбраковка шума
问题: На основе рассчитанного scorebook.json проведите аукцион. Установите бюджет в 2000 токенов, порог принятия 0.70 и порог отказа 0.40. Необходимо разделить кандидатов на победителей (keep) и отправленных в карантин (quarantine).
解决方案: 1. Находясь в каталоге shadow-auction, выполните: python3 scripts/decide.py --scorebook out/scorebook.json --budget-tokens 2000 --keep-threshold 0.70 --reject-threshold 0.40 --out-auction out/auction.json --out-quarantine out/quarantine.json. 2. Проверьте содержимое out/quarantine.json: убедитесь, что там присутствует хотя бы одна запись (например, shadow.alert.red_color_urgency) с явной причиной отказа.
难度: intermediate
名称: Калибровка штрафа за ложную эскалацию
问题: В вашей команде цена ложной эскалации P1 оказалась значительно выше, чем в базовой конфигурации. Удвойте вес штрафа (false_escalation) и посмотрите, как изменится состав победителей.
解决方案: 1. Запустите score.py с измененными весами: python3 scripts/score.py --candidates candidates/candidates.yaml --incidents data/incidents.jsonl --weights 0.5,0.3,0.2,0.8 --out out/scorebook_strict.json. 2. Запустите decide.py с новым scorebook. 3. Зафиксируйте наблюдение: 'При удвоенном штрафе кандидат X упал в карантин из-за высокой доли ложных эскалаций'.
难度: advanced
案例研究: 名称: Борьба с ложной срочностью: красный цвет дашборда
场景: В проекте автоматического triage для сервиса appointments-api команда инженеров предложила эвристику: если на дашборде индикатор горит красным цветом, агент должен автоматически повышать severity инцидента до P1, так как это 'визуально привлекает внимание'.
挑战: Интуитивно правило казалось полезным для быстрого реагирования. Однако при проверке выяснилось, что красный цвет часто использовался для визуального акцента в некритичных ситуациях и не соответствовал реальному радиусу последствий.
解决方案: Эвристика была оформлена как теневая спецификация shadow.alert.red_color_urgency и прогнана через аукцион. Формула оценки показала слабый рост mttr_gain и высокую долю false_escalation. Итоговый score ушел в минус (-0.3081). Кандидат был отправлен в карантин с причиной high_false_escalation.
结果: Система избежала токсичного шума. Спецификация не попала в QWEN.md, что предотвратило перегрузку дежурных инженеров ложными P1 эскалациями и сохранило доверие к автоматическим рекомендациям агента.
经验教训: Интуитивно убедительные эвристики ('операционный фольклор') могут нанести серьезный вред процессу triage.
Важно оценивать не только ускорение решения (MTTR), но и цену ошибки (штраф за ложную эскалацию).
Карантин должен содержать причину отклонения и условия возврата (например, после изменения политик UI).
相关概念: Журнал оценок (scorebook)
Ложные эскалации
Карантин (quarantine)
名称: Голосовой обход при каскадных сбоях
场景: Анализируя постмортемы, команда заметила паттерн: при подтвержденных P0-инцидентах в критических сервисах дежурные инженеры иногда пропускали стандартный текстовый шаблон и сразу инициировали голосовой созвон (voice handoff) для передачи проблемы второй линии.
挑战: Это неформальное наблюдение требовало формализации для LLM-агента, но его нельзя было делать универсальным правилом (P2 инциденты по-прежнему требовали асинхронного текстового следа). Нужно было доказать его ценность при ограниченном бюджете few-shot слотов.
解决方案: Наблюдение было преобразовано в формат 'контекст → признак → эффект' под названием shadow.p0.voice_handoff. На выборке из 20 инцидентов оно показало score 0.727 (высокий ранний сигнал, ноль ложных эскалаций, хотя и узкое покрытие).
结果: Спецификация победила в аукционе и была внедрена в QWEN.md как версионированный образец-подсказка с жестким контекстом (только для P0). Агент начал рекомендовать голосовой канал только там, где задержка передачи дороже потери письменного контекста.
经验教训: Редкие, но точные сигналы имеют высокую ценность, если их контекст строго ограничен.
Победитель аукциона не должен подменять формальную спецификацию — он внедряется как few-shot с ограниченным TTL (сроком жизни).
Формат контекст→признак→эффект делает из 'магического знания' воспроизводимый слот.
相关概念: Образец-подсказка (few-shot)
Аукцион
Нормализация наблюдений
学习建议: Не пропускайте практическую часть: теория аукциона лучше всего усваивается при запуске скриптов score.py и decide.py в каталоге examples/shadow-auction/.
Обратите внимание на формулу score = 0.5mttr_gain + 0.3early_signal + 0.2coverage - 0.4false_escalation. Попробуйте мысленно изменить приоритеты — какой коэффициент вы бы увеличили в медицинском проекте? В e-commerce?
Главный дисциплинарный принцип раздела — не доверять ярким историям без журнала оценок (scorebook). Всегда требуйте воспроизводимости расчетов.
Запомните отличие: формальное требование (requirements.md) расширяет контракт системы, а теневая спецификация (shadow spec в QWEN.md) — это лишь временное расширение памяти агента с указанным сроком пересмотра (ttl).
附加资源: Учебные скрипты и данные: book2/examples/shadow-auction/ (содержит candidates.yaml, incidents.jsonl и скрипты для расчета)
Предыдущие темы курса: Часть 6 первого тома (отделение пожеланий от требований) и Часть 19 первого тома (агентная память)
Приложение d (калибровка): appendix-d-threshold-calibration.md — раздел D.2 для детальной настройки весов на production-треке
Github spec kit: https://github.com/github/spec-kit — использование .specify/memory/constitution.md как защитного слоя от дрейфа
摘要: Аукцион теневых спецификаций — это механизм превращения операционного фольклора и неформальных наблюдений инженеров в управляемый и измеримый слой эвристик. Вы переводите наблюдение в формат 'контекст → признак → эффект', оцениваете его на истории инцидентов с помощью прозрачной формулы и конкурируете за ограниченный контекстный бюджет. Победившие спецификации попадают в QWEN.md как версионированные образцы-подсказки (few-shot), имеющие срок жизни и строгий контекст. Проигравшие не исчезают, а уходят в карантин с четко зафиксированной причиной (например, риск ложных эскалаций), что делает процесс решений воспроизводимым и оспариваемым.