Урок 90. Итоговый проект: оркестр моделей

Финальный проект не обязан быть самой сложной моделью курса. Он обязан провести одну проверяемую мысль через данные, baseline, модель, интерактив, ошибки и публичную защиту так, чтобы другой человек мог воспроизвести вывод.

Вопрос раньше технологии

«Сделать ИИ для экологии» не проверяется. «Можно ли по открытым почасовым данным предсказывать превышение PM2.5 на следующие шесть часов лучше сезонного baseline?» уже задаёт объект, горизонт и сравнение.

Сильный вопрос содержит:

наблюдаемую единицу;
доступные к моменту решения признаки;
target;
горизонт;
baseline;
критерий успеха;
границы применимости;
предполагаемого пользователя результата.

Перед выбором темы найдите один реальный decision. Если прогноз не меняет действие, возможно, нужна не predictive model, а исследовательская визуализация.

Воронка проектной постановки тема решение данные target metric threshold action — Рис. 90.1. От расплывчатой темы к проверяемому вопросу
Слева широкие темы `город`, `здоровье`, `язык`; каждое уточнение добавляет наблюдаемую переменную и ограничение. Справа одна карточка question contract со временем прогноза, baseline, метрикой и действием пользователя.

Паспорт задачи до первой строки кода

До кода заполните:

вопрос и гипотезу;
происхождение данных, лицензию, дату и объём;
unit of observation;
target и момент его доступности;
split;
baseline;
основную и защитные метрики;
риски утечки;
группы/режимы для анализа ошибок;
вычислительный бюджет;
формат интерактива;
условие остановки.

Это не бюрократия. Паспорт делает видимыми решения, которые иначе случайно прячутся в notebook. Принципы паспорта датасета и честного split здесь обязательны.

Контрольный вопрос для команды: какое одно изменение в данных заставит вас пересмотреть постановку, а не просто переобучить ту же модель? Такой критерий заранее отделяет исследовательский вывод от привычки защищать уже написанный код.

Ответ внесите в паспорт до первого запуска. На защите покажите, встретилось ли это условие и какое решение команда приняла после проверки.

Baseline до нейросети

Для временного ряда baseline — последнее значение или сезонный повтор. Для классификации — частый класс, logistic regression, дерево. Для retrieval — BM25. Для управления — фиксированное правило.

Baseline выполняет три функции:

обнаруживает утечку, если подозрительно силён;
показывает реальную добавочную ценность;
даёт запасной метод при отказе сложной системы.

Сравнение должно использовать один split и доступные признаки. Если neural model получает прогноз погоды, baseline тоже должен его получить либо различие надо назвать.

Оркестр ролей

Даже один человек последовательно играет роли:

предметник проверяет смысл;
data steward отвечает за происхождение и split;
modeler строит baseline и кандидаты;
skeptic ищет утечку и контрпримеры;
designer делает интерактив;
reproducibility reviewer запускает с нуля;
narrator собирает аргумент.

Роли разделяют критерии, а не создают длинную агентную церемонию. Идеи verifier из агентного урока полезны: проверка должна иметь внешнее свидетельство.

Pipeline data snapshot split baseline model error audit interactive report with reviewer gates — Рис. 90.2. Проект как цепь артефактов и проверок
У каждого этапа указан артефакт: checksum snapshot, split manifest, metrics table, error gallery, browser lab. Ромбы reviewer gate имеют бинарные критерии. Красная обратная стрелка разрешает пересборку, но запрещает подглядывать в test.

Лаборатория оркестра

Составьте pipeline и проведите карточку данных через роли. Если split следует после обучения, система укажет утечку. Если интерактив не связан с вопросом, он не проходит reviewer gate.

Попробуйте минимальный и сложный маршруты. Чем больше моделей и автоматических этапов, тем больше проверок. Лучший маршрут не самый длинный, а тот, где каждый блок меняет решение.

Один разумный маршрут

Пример проекта про качество воздуха:

скачать почасовые measurements и weather, зафиксировать snapshot;
выбрать одну станцию и период;
target: превышение порога через 1–6 часов;
split по времени с последним сезоном в test;
baseline: значение сейчас и logistic regression;
кандидат: gradient boosting или небольшой sequence model;
метрики: PR-AUC, recall при ограниченном числе тревог, calibration;
error audit по сезонам и пропускам;
интерактив threshold/base-rate;
model card с запретом медицинских рекомендаций.

Здесь временные модели применимы, но могут проиграть дереву. Результат всё равно содержателен: мы узнаём, сколько добавляет история.

Метрика должна продолжаться в интерфейс

Если пользователь выбирает threshold, интерактив показывает confusion matrix при реальном base rate, а не абстрактную accuracy. Если исследуется clustering, пользователь меняет representation и видит устойчивость групп. Если PageRank — меняет телепортацию и наблюдает перестановки.

Интерактив обязан:

отвечать на один вопрос;
иметь начальное состояние с выводом;
подписывать единицы и данные;
показывать uncertainty;
не скрывать reset;
работать с клавиатуры;
иметь fallback-описание;
не передавать данные наружу без причины.

Это продолжение визуального аргумента, а не награда после текста.

Ошибки как основной результат

Составьте error taxonomy до просмотра test: редкие режимы, пропуски, boundary cases, domain shift, label ambiguity. Затем отберите ошибки по правилам, а не самые смешные.

Для каждой категории:

частота;
цена;
representative examples;
возможная причина;
проверяемая следующая гипотеза;
mitigation;
остаточный риск.

Уверенные ошибки важнее случайных. Calibration из урока о неопределённости помогает отделить «модель сомневалась» от «модель ошибалась уверенно».

Performance dashboard by season missingness and target prevalence with error examples — Рис. 90.3. Средняя метрика распадается на режимы
Общая PR-AUC разбита по сезонам и доле пропусков. Размер точки показывает число объектов, полосы — bootstrap intervals. Справа две уверенные ошибки связаны стрелками с соответствующими группами и проверяемыми гипотезами.

Красная команда и stop criteria

Перед защитой другой человек пытается:

нарушить формат входа;
найти near-duplicate через split;
изменить seed;
удалить сильный признак;
сдвинуть период или регион;
подобрать adversarial пример;
проверить край ползунка;
отключить сеть;
воспроизвести окружение.

Не все проблемы надо исправлять. Их можно честно зафиксировать как limitation. Stop criteria защищает от бесконечного tuning по validation и ночного добавления функций.

Мини-исследование: негативный результат тоже проект

Предположим, sequence model не превзошла seasonal baseline. Не меняйте вопрос задним числом. Проверьте, одинаковы ли признаки и tuning budget, достаточны ли интервалы и где методы расходятся. Возможно, сложная модель выигрывает только на праздниках или проигрывает везде.

Негативный вывод «в этих данных и при этом протоколе добавочная сложность не дала измеримого выигрыша» полезен. Он ограничен, воспроизводим и экономит ресурсы. Плохой вывод звучит «нейросети не работают»: он выходит далеко за эксперимент.

Опубликуйте learning curve по объёму данных. Если разрыв растёт с $D$ , следующий шаг понятен; если curves сошлись, вероятнее ограничение признаков или irreducible noise. Это связывает финальный проект со scaling analysis в малом масштабе.

Рубрика защиты

Проект оценивается по 100 баллам:

постановка и предметный смысл — 12;
данные, лицензия, provenance — 12;
split и защита от утечки — 12;
baseline и ablation — 12;
модель и объяснение — 10;
метрики и uncertainty — 12;
error analysis и ограничения — 12;
интерактив и визуальный аргумент — 10;
воспроизводимость — 8.

Сложность модели отдельно не награждается. Простая система с сильным исследованием может получить максимум.

Защита как научный разговор

Структура 12-минутной защиты:

вопрос и decision — 1 минута;
данные и split — 2;
baseline и модель — 2;
главный рисунок — 2;
интерактивный эксперимент — 2;
ошибки и ограничения — 2;
вывод — 1.

В приложении остаются полные таблицы. На вопрос «почему верить?» ответ состоит из provenance, holdout, baseline, uncertainty и reproduction, а не из уверенного тона.

История курса образует сеть: данные, оптимизация, валидация, генеративные модели и агенты становятся взаимозаменяемыми инструментами одного метода — формулировать и проверять.

Задачи

4баллов

Для проекта прогнозирования школьного энергопотребления доступны почасовые показания счётчика за 2022–2025 годы, архив погоды и календарь; в 18:00 каждого дня требуется выдать 24 почасовых прогноза для календарного дня 00:00–23:00, следующего за моментом прогноза. Составьте паспорт, явно заполнив все 12 пунктов: (1) проверяемый вопрос и решение пользователя; (2) происхождение, лицензия, дата snapshot и объём данных; (3) единица наблюдения; (4) target и момент его доступности; (5) train/validation/test split; (6) baseline; (7) основная и защитные метрики; (8) риски утечки; (9) группы и режимы для анализа ошибок; (10) вычислительный бюджет; (11) формат интерактива; (12) условие остановки эксперимента. Назовите точные календарные границы временного split. Разрешены только признаки, известные к 18:00: погодные признаки берите из прогнозов с issued_at <= forecast_origin, а фактические наблюдения погоды после 18:00 запрещены. Автопроверка должна требовать max(feature_available_at) <= forecast_origin для каждой строки. Опишите ещё минимум один конкретный механизм утечки и проверку, которая его обнаружит. Если приложенные школьные файлы не содержат происхождение, лицензию, дату snapshot или объём, запишите UNKNOWN, укажите ответственного и способ проверки; придумывать отсутствующие сведения запрещено.

5баллов

Используйте UCI Bike Sharing Dataset, DOI 10.24432/C5W894, файл hour.csv из архива Bike-Sharing-Dataset.zip, содержащий 17 379 почасовых строк, и среду scikit-learn==1.7.2. Target — столбец cnt; удалите instant, casual и registered, поскольку два последних в сумме дают target. Поле dteday применяйте только для сортировки и split, а затем удалите. Категориальные признаки season, yr, mnth, hr, holiday, weekday, workingday, weathersit кодируйте через OneHotEncoder(handle_unknown="ignore", sparse_output=False); числовые temp, atemp, hum, windspeed передавайте без преобразования. ColumnTransformer и encoder обучайте только на train.

Train содержит даты до 30 июня 2012 года включительно, validation — с 1 июля по 30 сентября 2012 года, test — с 1 октября по 31 декабря 2012 года; test нельзя просматривать до фиксации протокола. Сравните dummy-прогноз медианой train target и HistGradientBoostingRegressor(random_state=2026, max_iter=300, early_stopping=False). Переберите только по validation все комбинации learning_rate из $\{0{,}03;0{,}08\}$ , max_leaf_nodes из $\{15;31\}$ , min_samples_leaf из $\{20;50\}$ и l2_regularization из $\{0;1\}$ ; при равном validation MAE выберите лексикографически первый набор в порядке перечисления параметров. Основная метрика — MAE; дополнительно сообщите RMSE, $R^2$ , время обучения, выбранный max_leaf_nodes и фактический n_iter_.

Для paired bootstrap ресэмплируйте с возвращением столько целых тестовых календарных дней, сколько их есть в test, и в каждой реплике используйте один набор дней для обеих моделей. Вычисляйте $\Delta=\operatorname{MAE}_{HGB}-\operatorname{MAE}_{dummy}$ ; 95% interval образуют эмпирические квантили 0,025 и 0,975 среди 2 000 значений $\Delta$ , полученных генератором PCG64 с seed 9003. Постройте error slices для рабочих/выходных дней, четырёх сезонов и часов 0–5, 6–11, 12–17, 18–23; опубликуйте checksum архива, точное preprocessing и итоговую таблицу.

6баллов

Спроектируйте browser-интерактив для учебного макета почасового проката велосипедов. Это не оценённая по данным неопределённость: явно подпишите модель как демонстрационную. При температуре $T$ , влажности $H$ и зафиксированном во всех состояниях индикаторе слабого дождя $R=1$ вычисляйте прогноз

\widehat y=\operatorname{clip}_{[0,400]}\left(120+4(T-12)-0{,}7(H-70)-25R\right),

полуширину $d=30+0{,}2|T-12|+0{,}1|H-70|$ и показывайте условный интервал $[\max(0,\widehat y-d),\widehat y+d]$ . Начальное состояние — будний день 15 октября, 08:00, температура $12^\circ$ C, влажность 70%, слабый дождь; пользователь меняет двумя sliders с шагом 1 температуру от $-10$ до $35^\circ$ C и влажность от 20% до 100%, а output обновляет прогноз, интервал и разность с исходным сценарием. Если вход отсутствует или вычисление даёт не конечное число, вместо чисел показывайте «Не удалось вычислить» и не сохраняйте прежний результат. Опишите поведение на краю шкалы и при недоступном JavaScript, а также управление Tab, стрелками, Home/End и экранным диктором. Создайте storyboard из шести состояний: загрузка, исходный прогноз, изменение температуры, изменение влажности, край шкалы, fallback. Проведите тест минимум с пятью людьми и задайте каждому одинаковые вопросы: «каков прогноз и интервал?», «при каком сценарии спрос выше — при исходном или при текущем?», «что означает ширина интервала?», «как вернуть исходные значения?», «что произойдёт на краю шкалы?». Запишите время, правильность пяти ответов, три места замешательства и изменения интерфейса после теста.

7баллов

Выполните мини-проект в среде scikit-learn==1.7.2 на UCI Beijing Multi-Site Air-Quality Data, DOI 10.24432/C5RK5G, snapshot архива, скачанный 1 июля 2026 года, лицензия CC BY 4.0. Используйте строки станции Dongsi с 1 января 2014 по 31 декабря 2016 года. Соберите timestamp, отсортируйте строки и проверьте отсутствие дублей. Target в момент $t$ равен 1, если максимум PM2.5 ровно в моменты $t+1,\ldots,t+6$ превышает 75 мкг/м³. Строка допустима, только если существуют все шесть последовательных почасовых timestamps и не пропущены семь значений PM2.5 от $t$ до $t+6$ ; удалять строки с пропусками до построения сдвигов запрещено. Признаки — текущие PM2.5, TEMP, PRES, DEWP, RAIN, WSPM, направление ветра wd, месяц, день недели и час; будущие значения запрещены.

Train содержит 2014–2015 годы, validation — январь–июнь 2016 года, test — июль–декабрь 2016 года. Удалите origins, чьё target-окно пересекает границу частей: последние допустимые origins — 31 декабря 2015 года 17:00, 30 июня 2016 года 17:00 и 31 декабря 2016 года 17:00. Пропуски числовых признаков заполняйте медианами train. Для wd используйте SimpleImputer(strategy="constant", fill_value="MISSING") и OneHotEncoder(handle_unknown="ignore", sparse_output=False). Постройте циклические признаки: для месяца $\sin(2\pi(m-1)/12)$ и $\cos(2\pi(m-1)/12)$ ; для дня недели с Monday = 0 — $\sin(2\pi d/7)$ и $\cos(2\pi d/7)$ ; для часа — $\sin(2\pi h/24)$ и $\cos(2\pi h/24)$ . Все преобразования обучайте только на train.

Сравните baseline с постоянной вероятностью, равной доле положительного класса в train, LogisticRegression(solver="lbfgs", max_iter=2000, random_state=2026) с $C\in\{0{,}1;1;10\}$ и HistGradientBoostingClassifier(loss="log_loss", max_iter=300, early_stopping=False, random_state=2026) с max_leaf_nodes из $\{15;31\}$ , learning_rate из $\{0{,}05;0{,}1\}$ и l2_regularization из $\{0;1\}$ . Для logistic regression масштабируйте числовые и циклические признаки через StandardScaler, а one-hot столбцы не масштабируйте; для бустинга scaling не применяйте. Для каждой из двух моделей выберите конфигурацию с максимальным validation average_precision_score (AP); при равенстве берите лексикографически первый tuple параметров. Champion — модель с большей validation AP, а при равенстве logistic regression.

Только для champion переберите неповторяющиеся значения validation probability и выберите порог, дающий максимальный recall при precision не ниже 0,70 и хотя бы одном положительном предсказании; при равном recall берите больший порог. Если допустимого порога нет, зафиксируйте статус INFEASIBLE, threshold $=+\infty$ , recall $=0$ , precision NA и не объявляйте систему пригодной. Полностью переобучите и настройте ablation без текущего PM2.5 только по train и validation. После фиксации champion, preprocessing, threshold и ablation выполните один общий test run. Сообщите test AP, ROC-AUC, Brier score, а также precision и recall при замороженном пороге.

Для champion и baseline сделайте paired block bootstrap по целым тестовым календарным дням: 2 000 ресэмплов генератором PCG64 с seed 9005. Получите 2 000 реплик, в каждой из которых присутствуют оба класса, и постройте 95% percentile interval для $\Delta AP=AP_{champion}-AP_{baseline}$ ; если threshold допустим, постройте такой же interval для recall champion. Проведите error audit по сезонам DJF, MAM, JJA, SON и категориям wd. В browser-интерактиве зафиксируйте остальные признаки по выбранной validation-строке, а sliders для TEMP и WSPM ограничьте train min/max и отметьте центральный диапазон от 1-го до 99-го train percentile. Показывайте probability champion, замороженный threshold, решение и предупреждение вне центрального диапазона.

Приложите reproduction guide, split manifest и checksum; независимый одноклассник должен запустить проект с нуля. На защите покажите главный вывод, один опровергнутый исходный тезис и одно сознательно оставленное ограничение. Оцените артефакты по рубрике ровно на 100 баллов и приложите evidence к каждой категории: постановка и предметный смысл — 12; данные, лицензия и provenance — 12; split и защита от утечки — 12; baseline и ablation — 12; модель и объяснение — 10; метрики и uncertainty — 12; error analysis и ограничения — 12; интерактив и визуальный аргумент — 10; воспроизводимость — 8.