Тема: Прикладная часть 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), имеющие срок жизни и строгий контекст. Проигравшие не исчезают, а уходят в карантин с четко зафиксированной причиной (например, риск ложных эскалаций), что делает процесс решений воспроизводимым и оспариваемым.