Руководство по подготовке домашних заданий

Рекомендации по подготовке домашних заданий в Jupyter Notebook.
1. Общие правила

Этот раздел устанавливает фундаментальные принципы оформления домашних заданий. Соблюдение этих правил обеспечивает единообразие работ, упрощает проверку и формирует профессиональные навыки документации анализа данных.

1.1. Основные положения
  • Язык выполнения: Работы оформляются только на русском языке в соответствии с требованиями образовательной программы. Это условие обеспечивает эффективность и качество проверки.
  • Академический этикет: Ваша работа — это официальный документ. Сленг, жаргон и разговорные выражения недопустимы.
  • Списывание: Прямое копирование кода у других студентов запрещено, при обнаружении списывания все участники списывания будут сдавать устный зачет. Код из рассказанных на занятиях ноутбуков можно использовать без ограничений. Про использование ИИ
  • Публикация решений запрещена: решения, размещённые на каких-либо интернет-ресурсах, не принимаются. Кроме того, публикация решения в открытом доступе может быть приравнена к предоставлению возможности списать.
Систематические или грубые нарушения этих правил могут привести к бану.
1.2. Структура ДЗ

Домашние задания выполняются в Jupyter-notebooks. Вы можете выполнять их в Colab, Jupyter, VS Code — где удобно.

Ниже — примеры ключевых ячеек, которые обычно есть в наших ноутбуках.

Шапка

курс, номер задания, правила и разбалловка

Markdown

Bot-check

ячейка, которую читает бот для проверки корректности сдачи

Code

Использование ИИ

ячейка для ссылок на диалоги с ИИ-помощниками

Markdown

Импорты

стандартные импорты, которые можно дополнять своими. Рекомендуется держать все импорты в начале ноутбука.

Python

Условия задач

бывают теоретические (требуют ответа в markdown) и практические (с написанием кода).

Markdown
Условия менять/удалять нельзя.

Решение

место для вашего решения

Markdown
Пишите ответы на месте "..." или после плейсхолдеров Ответ, Решение, Вывод при их наличии или добавляйте свои ячейки с кодом/текстом ниже условия.
2. Оценка и проверка

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

Как проверяются работы и за что могут снижать баллы

Проверка домашних заданий проводится в два этапа и сочетает автоматическую и экспертную оценку.

  • ThetaGrader: первичную проверку выполняет автоматизированная ИИ-система ThetaGrader. Она оценивает работу по набору критериев (включая структуру и обязательные элементы: этапы решения, ответы, выводы, графики), формирует предварительный результат и комментарии. Отдельно она может фиксировать дополнительные замечания по качеству кода и оформления.
  • Проверяющий: не проверяет работу «с нуля», а работает с результатами ThetaGrader: подтверждает или отклоняет его комментарии, уточняет спорные моменты и принимает итоговое решение по оценке.
  • Критерии оценки: в большинстве заданий используются однотипные критерии —
    • выполнен ли требуемый этап решения;
    • правильно ли он выполнен;
    • корректно ли построены графики и интерпретированы результаты;
    • есть ли осмысленный ответ или вывод там, где он запрошен;
  • За что могут снижать баллы:
    • присутствуют ошибки в данных, метриках, формулах или интерпретации;
    • ход решения частично не соотстветствует указанию в условиях, код неоптимален;
    • графики не подписаны, не читаются или неинформативны;
    • выводы отсутствуют, формальны или не связаны с полученными результатами;
  • Когда решение могут не оценивать вовсе:
    • ячейки ноутбука не запущены, хотя решение есть;
    • отсутствуют ключевые этапы задания;
    • невозможно понять, что именно было сделано и зачем;
    • логику решения невозможно быстро понять по коду и markdown;
3. Как пишем код

Качество кода — показатель профессионализма аналитика. Читаемый, эффективный и хорошо структурированный код не только упрощает проверку, но и демонстрирует ваше умение превращать исследовательские наброски в воспроизводимые решения.

3.1. Codestyle
Плохо
Хорошо
  • Отступы: 4 пробела.
  • Пробелы: вокруг операторов и после запятых.
  • Структура: логические блоки разделяйте пустыми строками.
  • Имена: осмысленные названия переменных и функций.
  • Импорты: все импорты должны находиться в начале ноутбука.
  • PEP8: ориентируйтесь на общие рекомендации стиля Python.
3.2. Организация ячеек и кода
Плохо: «вермишель» + «монолит»
Pythonячейка 1
Pythonячейка 2
Pythonячейка 3
Pythonмонолит (одна ячейка на всё)
Хорошо: логические блоки + функции
Pythonподготовка данных
Pythonфункции / расчёты
Pythonвывод
  • Запрет «вермишели»: не дробите решение на десятки микро-ячеек без смысла.
  • Запрет «монолитов»: не пишите весь проект в одной ячейке — разделяйте по этапам.
  • Переиспользуемость: повторяющиеся операции оформляйте в функции.
  • Вывод данных: обычно достаточно head(),sample(),tail() (5–10 строк) и shape.
Как правильно комментировать решение
Markdown

Сделаем предобработку данных перед анализом:

Python
  • Комментирование: Общая логика — в markdown-ячейке. Краткие поясняющие комментарии по коду — внутри кода, перед крупными блоками.
  • Мера: комментарии должны помогать понимать логику решения, а не мешать чтению. Используйте их умеренно и по делу.
Проверяющие будут снижать баллы за плохо оформленные ноутбуки. В частности, если проверяющий за разумное время не поймет логику решения из-за недостаточно хорошего оформления, он может его не оценивать совсем.
3.3. Эффективность и воспроизводимость
Плохо: циклы / apply там, где можно векторизовать
Хорошо: векторизация / встроенные операции pandas/numpy
  • Эффективность: ожидается использование эффективных подходов: векторизованные операции, встроенные функции pandas/numpy.
  • Фильтрация: Правила очистки/фильтрации данных формулируйте по обучающей выборке; сложные методы выбросов используйте только с понятным обоснованием.
  • Чистый запуск: все ячейки должны быть полностью запущены сверху вниз. Проверяющий не обудет запускать код — он проверяет outputs, код и текст. Если код студента не выполнен, не запущен, недописан и т.д., то он не оценивается.
4. Графики

Для специалиста Data Science — это не просто «красивые картинки», а инструмент анализа данных, обнаружения закономерностей, проверки гипотез и донесения инсайтов до аудитории. Грамотный график экономит часы анализа и делает выводы убедительными.

4.1. Цель графика
  • Формулировка цели: Перед построением графика необходимо чётко сформулировать, что именно вы хотите на нём показать. Цель определяет выбор типа визуализации.
    • Для связи между переменными — scatter plot или line plot.
    • Для отображения распределения — histogram или box plot.
    • Для сравнения величин — bar chart.
    Подробнее о подборе типа графика: статья на Habr.
Задайте себе вопрос: «А что именно я хочу на нём показать?»
  • Самодостаточность: если график вырезать из контекста отчёта, по нему всё равно должно быть понятно, что изображено и зачем.
После построения спросите себя: «Если показать график прохожему, поймет ли он его суть?»
4.2. Правила построения графиков

4.2.1. Осмысленность и читаемость

Плохо
Плохо: нет подписей
Хорошо
Хорошо: подписи и заголовок
  • Заголовок и оси: каждый график должен иметь заголовок и подписанные оси с единицами измерения.
Плохо
Плохо: легенда/цвета
Хорошо
Хорошо: читаемая легенда
  • Легенда и цвета: не пишите тривиальное в легенде. Используйте читаемые палитры (viridis, plasma — для непрерывных данных; Set3, tab20c — для категориальных).
Плохо
Плохо: scatter
Хорошо
Хорошо: scatter
  • Прозрачность (alpha): при большом количестве точек используйте alpha ≈ 0.3–0.6, чтобы избежать эффекта «сплошного пятна».
Плохо
Плохо: bins=5
Хорошо
Хорошо: bins=25
Плохо
Плохо: bins=100
  • Количество бинов: при построении гистограммы осмысленно выбирайте количество интервалов. Слишком малое число (bins=5) скрывает детали, а слишком большое (bins=100) создаёт шум и «гребешковый эффект».

4.2.2. Масштабирование

  • xlim / ylim: используйте для фокусировки на области, где сосредоточена основная масса данных.
  • vmin / vmax: применяйте для сравнения нескольких графиков в одной цветовой шкале или при наличии выбросов. Не используйте vmin/vmax для искусственного преувеличения незначительных различий (например, диапазон 4.7–5.0).
Проверяющие снижают баллы за плохие графики. Если по графику неясно, что изображено и какой вывод из него следует (нет подписей осей/единиц, заголовка, легенды, читаемости), график могут не учитывать при оценивании.
4.3. Интерпретация и выводы
  • Количество: обычно достаточно 2–5 ключевых графиков.
  • Интерактивные графики: если строите интерактивные графики (Plotly/Folium и т.п.), убедитесь, что они отображаются корректно в ноутбуке или присылайте их в формате HTML.
  • Выводы: каждый график должен сопровождаться текстовой интерпретацией.
Недостаточно просто вывести график. Нужно объяснить:
  • Что изображено?
  • Что это значит?
  • Какой вывод следует?
5. Выводы

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

5.1. Когда их делать
  • После завершения каждой значимой задачи или этапа анализа — особенно когда в задании прямо указано «Сделайте вывод» или «Проанализируйте результаты».
  • После создания любого визуального представления данных (графиков, диаграмм, тепловых карт) — график без интерпретации бесполезен для принятия решений.
  • После расчёта ключевых метрик (A/B-тесты, accuracy модели) — числа сами по себе ничего не значат без контекста и интерпретации.
  • При ответе на вопросы «Подумайте…» или «Как вы считаете…» в условиях задачи — даже если нет специально отведённой ячейки, важно явно сформулировать ответ.
5.2. Как делать?

Качественный вывод — это микродокумент, который должен отвечать на три ключевых вопроса:

  • Что конкретно мы узнали? (фактический результат)
  • Что это означает на практике? (интерпретация)
  • Соответствует ли это ожиданиям/целям? (оценка значимости)
Плохо
  • «я решил задачу»
  • «Практика подтвердила теорию» (без пояснения)
  • Пересказ условия задачи
  • Вывод-отписка
  • Огромное сочинение
Хорошо
  • «Эксперимент показал, что данные ведут себя так-то …»
  • «Клиенты хорошо разделяются на три кластера — …»
  • «Эксперимент подтвердил теорию тем, что …»
  • Желательно явно показывать, из какой части исследования какой вывод следует.
Проверяющие снижают баллы за формальные выводы. Если выводы не интерпретируют результаты (пересказ кода, графиков или условий без объяснения смысла), такие выводы могут быть не засчитаны.