first commit

project.md

@@ -0,0 +1,155 @@
+# Командный проект
+
+Проект посвящён воспроизведению и экспериментальной проверке результата научной статьи. Полное воспроизведение статьи не требуется: команда должна разобраться в работе, восстановить существенную часть её методики и независимо проверить значимый результат.
+
+Обычная команда состоит из трёх человек. Пары формируются только для выравнивания числа студентов; для них преподаватель сокращает объем обязательной работы. Команды из четырёх человек не создаются.
+
+В проектном задании перечислены три содержательных направления. Они служат ориентирами для планирования и не задают готовых ролей по числу участников. Команда распределяет работу самостоятельно; каждый студент отвечает за законченный проверяемый результат.
+
+## Календарь проекта
+
+### Начало проекта
+
+- **14.09.2026, 23:59** — заполнить профиль.
+- **18.09.2026** — получить окончательный состав команды и ознакомиться с окончательным банком заданий.
+- **21.09.2026, 23:59** — указать три предпочтительных задания от команды.
+- **23.09.2026** — получить назначенное проектное задание.
+
+### Сроки контрольных точек
+
+Для каждой точки команда заранее сдаёт материалы. На общем занятии ведущий даёт обратную связь и разбирает несколько показательных проектов, после чего команда получает письменный статус и обязательные исправления.
+
+| Контрольная точка | Материалы | Занятие | Статус | Опрос |
+|---|---|---|---|---|
+| [Проверка и детализация проектного задания, план эксперимента](project-checkpoints/01-project-plan.md) | 03.11.2026, 23:59 | 09.11.2026 | до 13.11.2026 | — |
+| [Первый работающий результат](project-checkpoints/02-working-result.md) | 02.12.2026, 23:59 | 07.12.2026 | до 11.12.2026 | до 18.12.2026, 23:59 |
+| [Промежуточные результаты воспроизведения и уточнение плана](project-checkpoints/03-intermediate-results.md) | 27.01.2027, 23:59 | 01.02.2027 | до 05.02.2027 | до 12.02.2027, 23:59 |
+
+### Завершение проекта
+
+- **26.02.2027, 23:59** — сдать короткую сверку состояния проекта через ветку `nis/status` и PR/MR. Опросы и сверка отдельно не оцениваются.
+- **01.03.2027** — при отсутствии оцениваемого участия получить предупреждение о риске `ИР=0` и требуемом результате к итоговой сдаче.
+- **05.03.2027** — получить адресную обратную связь, если у команды выявлены риски или блокировки.
+- **19.03.2027, 23:59** — сдать технический отчёт, репозиторий и лист итоговой сдачи через PR/MR; указать полный хеш оцениваемого коммита.
+
+После срока 19 марта разрешены только редакторские изменения презентации и согласованные технические исправления. Даты защит приведены в [расписании](schedule.md).
+
+## Формирование команды и выбор проектного задания
+
+До **14 сентября, 23:59** каждый студент заполняет короткий профиль. Названия групп приведены в [тематическом указателе банка](project-tasks/README.md#тематические-группы). Профили видит преподаватель; общая таблица имён и интересов не публикуется. Если профиль не заполнен, команда и проектное задание могут быть назначены без учёта предпочтений.
+
+```text
+Имя:
+Команда: готовая тройка / пара / команды нет
+Участники готовой команды:
+Интересующие проектные задания:
+2–3 тематические группы из банка:
+Своя статья, если есть: название и ссылка
+Чем статья связана с курсом:
+Какой результат интересно проверить:
+Код и данные, если есть:
+```
+
+К 18 сентября публикуются окончательные составы команд и окончательный [банк готовых проектных заданий](project-tasks/README.md). До 21 сентября, 23:59, команда совместно ранжирует три задания. 23 сентября проектные задания распределяются между командами. После этого команда создаёт репозиторий по [общим правилам](project-repository.md), передаёт его адрес преподавателю и фиксирует начальные содержательные ответственности. Отдельная проектная заявка не нужна.
+
+## Что требуется от проекта
+
+Обязательный объём задаёт назначенное проектное задание. Существовавшие до начала курса код, данные и результаты считаются исходной точкой; оценивается новая работа команды.
+
+Простого запуска готового кода недостаточно. Нужны:
+
+- проверяемый технический результат;
+- корректный эксперимент с сопоставимыми вариантами, метриками и повторами;
+- проверка корректности и доказательный анализ результатов;
+- воспроизводимый репозиторий и полный протокол основных серий;
+- технический отчёт и презентация.
+
+Сравниваемые варианты запускаются на одинаковых входах или на одинаково сформированных выборках. Для недетерминированных измерений выполняется не менее трёх повторов, если проектное задание явно не требует большего числа.
+
+Корректный отрицательный результат или расхождение со статьёй могут быть полноценным итогом, если эксперимент корректен, данные пригодны для анализа, а причины разобраны по свидетельствам. Техническая блокировка без корректного эксперимента итоговым результатом не считается.
+
+## Технический путь проекта
+
+Проверяется утверждение или метод статьи, поэтому опубликованный программный артефакт не обязан быть основой реализации. Проектное задание может предусматривать один или несколько равноправных путей:
+
+- восстановить, адаптировать или модифицировать авторский артефакт;
+- самостоятельно реализовать центральный механизм в объёме, достаточном для проверки;
+- построить собственный симулятор или модель существенного механизма;
+- сочетать реальный прототип с имитацией для более широких экспериментальных серий.
+
+Допустимые пути указаны в конкретном проектном задании. Если их несколько, команда выбирает путь самостоятельно и фиксирует выбор к первой контрольной точке. Переход к пути, которого нет в задании, оформляется как его уточнение: команда показывает технические основания, после чего преподаватель выпускает новую версию задания.
+
+Самостоятельная реализация должна явно отделять сохранённые свойства метода от упрощений и иметь автоматическую проверку корректности. Для симулятора нужно описать допущения, проверить его на аналитических примерах, опубликованных данных или доступной реализации и ограничить выводы областью применимости модели. При любом пути сохраняются заданные проверяемый вопрос, baseline, основные показатели и требования к анализу.
+
+## Ресурсы, данные и лицензии
+
+Каждое выданное задание имеет содержательный обязательный путь на CPU, обычном личном компьютере или бесплатно доступной инфраструктуре. Личные расходы не требуются. По согласованию команда с подтверждённым доступом к GPU может включить GPU-реализацию и эксперименты в обязательный план. Доступ должен сохраняться до окончания проверки, а преподавателю должна быть обеспечена возможность выборочно повторить запуски на сопоставимом ресурсе. Оценка зависит от полученного результата; сам доступ к оборудованию преимуществ не даёт. При утрате доступа команда возвращается к исходному CPU-пути. По согласованию могут быть выделены ресурсы Яндекс Облака, но их наличие, объём и срок не гарантируются.
+
+Если у артефакта нет явной лицензии, команда не копирует его код: нужно получить разрешение правообладателя или реализовать механизм независимо по описанию статьи. Закрытые данные, код и сервисы можно использовать только при законном доступе и возможности проверки преподавателем.
+
+## Воспроизводимость
+
+Состав и оформление репозитория определены в [отдельной памятке](project-repository.md). Итоговый репозиторий должен содержать:
+
+- зафиксированные версии кода, данных, зависимостей и параметров;
+- автоматизированную настройку или точную инструкцию;
+- сокращённый сквозной запуск на обычной машине;
+- полный протокол основных серий, сырые и обработанные данные;
+- сценарий, который перестраивает итоговые таблицы и графики.
+
+Если в обязательный план входят GPU-эксперименты, преподавателю достаточно обеспечить выборочный повторный запуск; полное повторение всех дорогих серий не требуется.
+
+Контейнеризация не обязательна. Секреты, токены и закрытые данные в репозиторий не помещаются.
+
+## Контрольные точки
+
+Каждая точка сдаётся через отдельную ветку и PR/MR. Полный хеш в описании PR/MR фиксирует версию, сданную к сроку. Материалы содержат краткий результат, ссылки на проверяемые свидетельства и карточки ответственности участников. На занятии разбираются общие ошибки и несколько показательных проектов. Статусы, порядок обратной связи, исправлений и документирования блокировок приведены в [общих правилах контрольных точек](project-checkpoints/README.md).
+
+1. [Проверка и детализация проектного задания, план эксперимента](project-checkpoints/01-project-plan.md) — команда уточняет обязательный результат, проверяет технические предпосылки выбранного пути и готовит план эксперимента. Полный сквозной эксперимент пока не требуется.
+2. [Первый работающий результат](project-checkpoints/02-working-result.md) — команда показывает один содержательный сквозной сценарий, исходные измерения, обработанный результат и свидетельства проверки корректности. Baseline и полная серия пока не требуются.
+3. [Промежуточные результаты и уточнение плана](project-checkpoints/03-intermediate-results.md) — команда сравнивает основной метод с baseline, представляет промежуточные данные и уточняет обязательный план завершения проекта. Возможное самостоятельное продолжение описывается отдельно.
+
+## Конфиденциальные опросы и риск-сигналы
+
+Каждый студент заполняет опрос о себе и каждом участнике команды до **18 декабря, 23:59**, и до **12 февраля, 23:59**. По шкале «да», «частично», «нет», «недостаточно данных» оцениваются выполнение согласованных задач, проверяемость результата, своевременность сообщения о блокировках, участие в проверке и интеграции и необходимость вмешательства преподавателя. При ответе «частично» или «нет» нужен конкретный пример.
+
+Опросы не образуют автоматического коэффициента и не изменяют командный балл напрямую. Они помогают рано обнаружить проблемы и служат одним из свидетельств индивидуальной работы.
+
+Между точками можно подать риск-сигнал, если блокировка угрожает обязательному результату, нужно пересогласовать объём или возникла документированная командная проблема:
+
+```text
+Команда и тема:
+Ссылка на проверяемые материалы:
+Конкретная блокировка:
+Что уже сделано:
+Влияние на обязательный результат:
+Какое решение требуется от преподавателя:
+```
+
+Риск-сигналы, поданные до среды 23:59, разбираются до пятницы 23:59. Обычная отладка, предварительное рецензирование черновиков и управление внутренними задачами команды в этот порядок не входят.
+
+## Итоговые материалы и защита
+
+Итоговый комплект включает репозиторий с сокращённым сквозным запуском, данные и конфигурации полного протокола, технический отчёт, презентацию и лист итоговой сдачи `nis/final.md`. До **19 марта 2027 года, 23:59** команда открывает итоговый PR/MR и указывает в его описании полный хеш оцениваемого коммита. Материалы оцениваются в конце курса как компонент `ПР` проектного экзамена; второй компонент `ЗП` определяется на защите. Порядок подготовки и оформления комплекта приведён на странице [«Финальная версия проекта»](project-final.md).
+
+Защиты ориентировочно проходят 25, 29 и 31 марта; точные даты будут уточнены ближе к концу курса. На команду отводится 20 минут: до 7 минут на доклад, 12 минут на индивидуальные вопросы и 1 минута на смену команды. Каждый участник отвечает на вопросы о своей работе, общей методике, проверке результатов и ограничениях.
+
+Ведущий обеспечивает каждому участнику сопоставимое время для индивидуальных ответов. Превышение времени доклада не сокращает время вопросов. Посещение защит других команд добровольное, без контроля посещаемости и влияния на оценку.
+
+Проект может быть связан с ВКР, но должен иметь самостоятельный законченный результат к марту. Подробная шкала проекта приведена в [памятке по оцениванию](grading.md).
+
+## Дополнительное достижение по проекту
+
+Дополнительное достижение описывается в техническом отчёте и `nis/final.md`, подтверждается материалами проекта и ответами на защите. Отдельная форма или предварительное согласование не требуются. Четыре признака достижения и примеры приведены в [порядке итоговой сдачи](project-final.md#дополнительное-достижение), условия высокой оценки — в [правилах оценивания](grading.md#итоговая-оценка).
+
+## Риски и порядок действий
+
+Риски фиксируются в материалах контрольной точки или через риск-сигнал. Своевременное сообщение позволяет скорректировать дальнейшую работу; обещание будущего результата и затраченное время сами по себе не учитываются.
+
+| Риск | Порядок действий | Как учитывается |
+|---|---|---|
+| Ошибочная предпосылка проектного задания | Команда прикладывает воспроизводимую диагностику. Преподаватель уточняет задание или назначает другое свободное задание и корректирует сроки и объём. | Документированная ошибка задания не снижает статус контрольной точки. |
+| Утрата внешнего ресурса | Команда возвращается к обязательному CPU-пути и при необходимости подаёт риск-сигнал. | Доступ к GPU, облаку или закрытому сервису преимуществ в оценке не даёт. |
+| Техническая блокировка или отрицательный результат | Команда сохраняет материалы, анализирует причины и обновляет план. | Документированная блокировка может быть зачтена как контрольная точка, но сама по себе не заменяет итоговый результат. Корректный отрицательный результат оценивается на общих основаниях. |
+| Проблема внутри команды | Участники фиксируют ответственность и результаты в материалах точек, конфиденциальных опросах и при необходимости в риск-сигнале. | `ИР` оценивается индивидуально. Если своевременно документированная проблема не зависит от студента и делает продолжение исходного проекта объективно невозможным, ему может быть назначено одно из заранее подготовленных резервных заданий. |
+| К сверке нет оцениваемого участия студента | До 1 марта студент получает в PR/MR адресное предупреждение о риске `ИР=0`, требуемом результате и сроке. Конфиденциальные ответы и личные обстоятельства публично не раскрываются. | Студент продолжает работу в исходном проекте. Отдельный индивидуальный проект из-за отсутствия вклада не назначается; при итоговом `ИР=0` применяются общие правила оценивания и пересдачи. |