Уроки и советы, полученные в ходе получения медали конкурса Kaggle
Делиться
Скажи мне, и я забуду. Научи меня, и я запомню. Вовлеки меня, и я научусь.
Старая поговорка всё ещё актуальна: обучение на практике — один из самых поучительных способов приобретения нового навыка. В области науки о данных и машинного обучения участие в соревнованиях — один из самых эффективных способов получить практический опыт и улучшить свои навыки и умения.
Kaggle — крупнейшее в мире сообщество специалистов по анализу данных, и его соревнования пользуются большим уважением в отрасли. Многие ведущие мировые конференции по машинному обучению (например, NeurIPS), организации (например, Google) и университеты (например, Стэнфордский университет) проводят соревнования на Kaggle.
В рамках представленных соревнований Kaggle лучшим участникам закрытой таблицы лидеров присуждаются медали. Недавно я участвовал в своём первом соревновании Kaggle с медалью и мне посчастливилось получить серебряную медаль . Это был NeurIPS – Ariel Data Challenge 2025. Я не собираюсь делиться здесь своим решением. Если вам интересно, можете посмотреть его здесь.
Чего я не осознавал до участия, так это то, что Kaggle проверяет не только навыки машинного обучения.
Kaggle проверяет навыки программирования и разработки программного обеспечения. Подчеркивается умение правильно организовать кодовую базу для быстрого итерирования и тестирования новых идей. Также проверяется способность наглядно отслеживать эксперименты и результаты.
Участие в научно-исследовательской конференции NeurIPS 2025 Competition Track также проверяло способность быстро и эффективно исследовать и изучать новую область.
В целом, этот конкурс меня очень пристыдил и научил многому, помимо МО.
Цель этой статьи — поделиться с вами некоторыми из этих уроков, не связанных с машинным обучением. Все они вращаются вокруг одного принципа: организация , организация , организация .
Сначала я покажу вам, почему чёткая структуризация кода и организация процессов — это не пустая трата времени и не просто приятное дополнение, а, напротив, важнейшее условие для участия в соревнованиях Kaggle и любого успешного проекта в области науки о данных в целом. Затем я поделюсь с вами некоторыми использованными мной приёмами и уроками, полученными в ходе структурирования кода и экспериментов.
Хочу начать со скромности. Я ни в коем случае не эксперт в этой области. Я всё ещё в начале своего пути. Надеюсь только, что некоторые читатели найдут эти уроки полезными и извлекут уроки из моих ошибок. Если у вас есть другие советы или предложения, прошу вас поделиться ими, чтобы мы все могли учиться вместе.
1 Золотой совет по науке: Организуйте
Не секрет, что учёные-естественники любят вести подробные записи о своей работе и процессе исследований. Неясные шаги могут (и приведут) к неверным выводам и пониманию. Невоспроизводимые результаты — бич науки. Почему для нас, специалистов по данным, должно быть иначе?
1.1 Но скорость важна!
Распространенный контраргумент заключается в том, что природа науки о данных динамична и итеративна. Как правило, эксперименты обходятся недорого и быстро; кроме того, кто в мире предпочтет написание документации программированию и построению моделей?
Хотя я и разделяю эту точку зрения и люблю быстрые результаты, боюсь, что такой подход недальновиден. Помните, что конечная цель любого проекта в области науки о данных — либо предоставить точные, подтверждённые данными и воспроизводимые выводы, либо создать надёжные и воспроизводимые модели. Если быстрая работа идёт вразрез с конечной целью, то она ничего не стоит.
Моё решение этой дилеммы — сделать рутинные этапы организации максимально простыми, быстрыми и безболезненными. Мы не должны стремиться к полному отказу от организационных процессов, а скорее к исправлению их недостатков, чтобы сделать их максимально эффективными и продуктивными.
1.2 Издержки отсутствия организации
Представьте себе такую ситуацию. Для каждого эксперимента у вас есть один блокнот на Kaggle, который выполняет всё: от загрузки и предварительной обработки данных до обучения модели, её оценки и, наконец, отправки. К настоящему моменту вы провели десятки экспериментов. Вы обнаруживаете небольшую ошибку в функции загрузки данных, которую использовали во всех своих экспериментах. Исправление её станет настоящим кошмаром, потому что вам придётся просмотреть каждый блокнот, исправить ошибку, убедиться в отсутствии новых ошибок, а затем заново запустить все эксперименты для получения обновлённых результатов. Всего этого можно было бы избежать, если бы у вас была чёткая структура кода, который можно было бы использовать повторно и который был модульным.
В работе Drivendata (2022) приводится яркий пример затрат на неорганизованный проект в области науки о данных. В ней упоминается история провала проекта, реализация которого заняла месяцы и стоила миллионы долларов. Причиной провала стал неверный вывод, обнаруженный на ранней стадии проекта. Ошибка кода при очистке данных привела к искажению данных и получению неверных результатов. Если бы команда лучше отслеживала источники данных и преобразования, она бы обнаружила ошибку раньше и сэкономила бы деньги.
Если из этого раздела и можно извлечь хоть один урок, так это то, что организация — это не просто приятное дополнение, а неотъемлемая часть любого проекта по науке о данных . Без чёткой структуры кода и организации процессов мы неизбежно будем совершать ошибки, тратить время и создавать невоспроизводимую работу.
1.3 Что отслеживать и организовывать?
Я считаю, что стоит обратить внимание на три основных аспекта:
- Кодовая база
- Результаты экспериментов и конфигурации
- Исследования и обучение
2 Кодовая база
В конце концов, код — это основа любого проекта в области науки о данных. Так что здесь есть чему поучиться у инженеров-программистов.
2.1 Структура репо
Если вы уделяете должное внимание структуре своей кодовой базы, у вас все будет хорошо.
Единой, общепринятой структуры не существует (и никогда не будет). Поэтому этот раздел крайне субъективен и основан на личных мнениях. Я расскажу об общей структуре, которая мне нравится и которую я использую.
Я предпочитаю начинать работу с помощью популярного шаблона Cookiecutter Data Science (CCDS). При инициализации проекта с помощью CCDS создается папка со следующей структурой: 1
├── ЛИЦЕНЗИЯ <- Лицензия с открытым исходным кодом, если она выбрана ├── Makefile <- Makefile с удобными командами, такими как `make data` или `make train` ├── README.md <- Файл README верхнего уровня для разработчиков, использующих этот проект. ├── data │ ├── external <- Данные из сторонних источников. │ ├── interim <- Промежуточные данные, которые были преобразованы. │ ├── processing <- Окончательные канонические наборы данных для моделирования. │ └── raw <- Исходный неизменяемый дамп данных. │ ├── docs <- Проект mkdocs по умолчанию; Подробнее см. на сайте www.mkdocs.org │ ├── модели <- Обученные и сериализованные модели, прогнозы моделей или сводки моделей │ ├── блокноты <- блокноты Jupyter. Именование состоит из номера (для упорядочивания), │ инициалов создателя и краткого описания, разделённого символом `-`, например, │ `1.0-jqp-initial-data-exploration`. │ ├── pyproject.toml <- Файл конфигурации проекта с метаданными пакета для │ {{ cookiecutter.module_name }} и конфигурацией для таких инструментов, как black │ ├── справочники <- Словари данных, руководства и все другие пояснительные материалы. │ ├── отчеты <- Сгенерированный анализ в формате HTML, PDF, LaTeX и т. д. │ └── рисунки <- Сгенерированная графика и рисунки для использования в отчетах │ ├── требования.txt <- Файл требований для воспроизведения среды анализа, например │ сгенерированный с помощью `pip freeze > requirements.txt` │ ├── setup.cfg <- Файл конфигурации для flake8 │ └── {{ cookiecutter.module_name }} <- Исходный код для использования в этом проекте. │ ├── __init__.py <- Делает {{ cookiecutter.module_name }} модулем Python │ ├── config.py <- Хранит полезные переменные и конфигурацию │ ├── dataset.py <- Скрипты для загрузки или генерации данных │ ├── features.py <- Код для создания признаков для моделирования │ ├── моделирования │ ├── __init__.py │ ├── predict.py <- Код для запуска вывода модели с обученными моделями │ └── train.py <- Код для обучения моделей │ └── plots.py <- Код для создания визуализаций
2.1.1 Управление окружающей средой
При использовании ccds вам будет предложено выбрать менеджер окружения. Лично я предпочитаю uv от Astral. Он записывает все используемые пакеты в файл pyproject.toml и позволяет воссоздать то же окружение, просто используя uv-синхронизацию.
Под капотом uv использует venv. Я считаю, что использовать uv гораздо проще, чем напрямую управлять виртуальными средами, поскольку управлять и читать pyproject.toml гораздо проще, чем requirements.txt.
Более того, я считаю, что uv намного проще, чем conda. uv создан специально для Python, тогда как conda гораздо более универсален.
2.1.2 Сгенерированный модуль
Значительную часть этого шаблона занимает каталог { cookiecutter.module_name }. В этом каталоге вы определили пакет Python, который будет содержать все важные части вашего кода (например, функции предварительной обработки, определение моделей, функцию вывода и т. д.).
Я считаю использование этого пакета весьма полезным, и в разделе 2.3 я расскажу, что размещать здесь, а что — в блокнотах Jupyter.
2.1.3 Сохранение гибкости
Не считайте эту структуру идеальной или полной. Вам не обязательно использовать всё, что предлагает CCDS, и вы можете (и должны) изменить её, если того требует проект. CCDS предоставляет отличную отправную точку для настройки под конкретные нужды и требования вашего проекта.
2.2 Контроль версий
Git стал абсолютной необходимостью для любого проекта, связанного с кодом. Он позволяет отслеживать изменения, возвращаться к предыдущим версиям и, благодаря GitHub, сотрудничать с членами команды.
Используя Git, вы, по сути, получаете доступ к машине времени, которая может исправить любые ошибки, внесённые вами в код. Сегодня использование Git не подлежит обсуждению.
2.3 Три типа кода
Выбор между скриптами Python и Jupyter Notebooks — давно обсуждаемая тема в сообществе специалистов по анализу данных. Здесь я изложу свою позицию по этому вопросу.
Мне нравится разделять весь свой код в одном из трех каталогов:
- Модуль
- Скрипты
- Блокноты
2.3.1 Модуль
Модуль должен содержать все важные функции и классы, которые вы создаете.
Его использование помогает нам минимизировать избыточность и создать единый источник достоверной информации для всех важных операций, выполняемых с данными.
В проектах по науке о данных некоторые операции, такие как чтение данных из файлов, преобразование данных и определение моделей, будут повторяться во всех рабочих процессах обучения и вывода. Повторять все эти функции во всех блокнотах или скриптах сложно и крайне утомительно. Использование модуля позволяет написать код один раз и импортировать его везде.
Более того, это помогает сократить количество ошибок. Если в модуле обнаружена ошибка, вы исправляете её один раз в модуле, и она автоматически исправляется во всех скриптах и блокнотах, импортирующих её.
2.3.2 Скрипты
Каталог scripts содержит файлы .py. Эти файлы — единственный источник выходных данных проекта. Они служат интерфейсом для взаимодействия с нашим модулем и кодом.
Эти файлы в основном используются для обучения и вывода данных. Все используемые модели должны быть созданы с помощью одного из скриптов, и все публикации на Kaggle должны быть сделаны с помощью таких файлов.
Использование этих скриптов помогает сделать наши результаты воспроизводимыми. Чтобы воспроизвести старый результат (например, обучить ту же модель), достаточно клонировать ту же версию репозитория и запустить скрипт, использованный для получения старых результатов.
Поскольку скрипты запускаются из CLI, использование библиотеки для управления аргументами CLI упрощает код. Мне нравится использовать typer для простых скриптов с небольшим количеством параметров конфигурации, а Hydra — для сложных (подробнее о Hydra я расскажу позже).
2.3.3 Ноутбуки
Блокноты Jupyter прекрасно подходят для исследований и создания прототипов благодаря короткому циклу обратной связи, который они обеспечивают.
Часто я начинаю писать код в блокноте, чтобы быстро его протестировать и выявить все ошибки. Только после этого я переношу его в модуль.
Однако блокноты не следует использовать для создания окончательных результатов. Их сложно воспроизводить и отслеживать изменения. Поэтому всегда используйте скрипты для создания окончательных результатов.
3. Запуск кодовой базы на Kaggle
Используя структуру, обсуждавшуюся в предыдущем разделе, нам необходимо выполнить следующие шаги для запуска нашего кода на Kaggle:
- Клонировать репозиторий
- Установить необходимые пакеты
- Запустить один из скриптов
Поскольку Kaggle предоставляет нам интерфейс Jupyter Notebook для запуска нашего кода, а большинство соревнований Kaggle имеют ограничения по доступу в Интернет, подача заявок не так проста, как запуск скрипта на локальном компьютере. Далее я расскажу, как выполнить каждый из вышеперечисленных шагов на Kaggle.
3.1 Клонирование репозитория
Во-первых, мы не можем напрямую клонировать наш репозиторий из GitHub в блокнот для отправки из-за ограничений интернета. Однако Kaggle позволяет импортировать результаты других блокнотов Kaggle в наш текущий блокнот. Поэтому решение заключается в создании отдельного блокнота Kaggle, который клонирует наш репозиторий и устанавливает необходимые пакеты. Результаты этого блокнота затем импортируются в блокнот для отправки.
Скорее всего, вы будете использовать приватный репозиторий. Самый простой способ клонировать приватный репозиторий на Kaggle — использовать персональный токен доступа (PAT). Вы можете создать PAT на GitHub, следуя этому руководству. Хорошей практикой будет создать PAT специально для Kaggle с минимальными необходимыми правами.
В блокноте клонирования вы можете использовать следующий код для клонирования своего репозитория:
из kaggle_secrets import UserSecretsClient user_secrets = UserSecretsClient() github_token = user_secrets.get_secret(«GITHUB_TOKEN») user = «YOUR_GITHUB_USERNAME» CLONE_URL = f»https://oauth2:{github_token}@github.com/{user}/YOUR_REPO_NAME.git» get_ipython().system(f»git clone {CLONE_URL}»)
Этот код загружает ваш репозиторий в рабочий каталог текущего блокнота. Предполагается, что вы сохранили свой PAT в секрете Kaggle с именем GITHUB_TOKEN. Перед запуском убедитесь, что вы активировали секрет в настройках блокнота.
3.2 Установка необходимых пакетов
В блокноте клонирования вы также можете установить необходимые пакеты. Если вы используете UV, вы можете собрать свой собственный модуль, установить его и его зависимости, выполнив следующие команды: 3.
cd ariel-2025 && uv build
Это создаст файл wheel в каталоге dist/ для вашего модуля. Затем вы можете установить его и все его зависимости в другой каталог, выполнив команду: 4.
pip install /path/to/wheel/file —target /path/to/custom/dir
Обязательно замените /path/to/wheel/file и /path/to/custom/dir на фактические пути. /path/to/wheel/file — это путь к файлу .whl в каталоге REPO_NAME/dist/. Вместо /path/to/custom/dir можно указать любой каталог. Запомните путь к пользовательскому каталогу, так как последующие блокноты будут использовать его для импорта вашего модуля и зависимостей проекта.
Мне нравится загружать репозиторий и устанавливать пакеты в одном блокноте. Я называю этот блокнот тем же именем, что и репозиторий, чтобы упростить его последующий импорт.
3.3 Запуск одного из скриптов
Первое, что необходимо сделать в каждом последующем блокноте, — импортировать блокнот, содержащий клонированный репозиторий и установленные пакеты. При этом Kaggle сохранит содержимое /kaggle/working/ из импортированного блокнота в каталоге /kaggle/input/REPO_NAME/, где REPO_NAME — имя репозитория 5.
Часто ваши скрипты создают выходные данные (например, файлы отправки) относительно своего расположения. По умолчанию ваш код будет находиться в каталоге /kaggle/input/REPO_NAME/, доступном только для чтения. Поэтому вам необходимо скопировать содержимое репозитория в /kaggle/working/, который является текущим рабочим каталогом и доступен для чтения и записи. Хотя это может быть излишним, это хорошая практика, которая не наносит вреда и предотвращает нелепые проблемы.
cp -r /kaggle/input/ИМЯ_РЕПО/ИМЯ_РЕПО/ /kaggle/working/
Если вы запускаете скрипты напрямую из /kaggle/working/scripts/, возникнут ошибки импорта, поскольку Python не может найти установленные пакеты и ваш модуль. Эту проблему легко решить, обновив переменную окружения PYTHONPATH. Я использую следующую команду для её обновления, а затем запускаю свои скрипты:
! export PYTHONPATH=/kaggle/input/ИМЯ_РЕПО/custom_dir:$PYTHONPATH && cd /kaggle/working/ИМЯ_РЕПО/scripts && python your_script.py —arg1 значение1 —arg2 значение2
Обычно я называю любой блокнот, запускающий скрипт, именем самого скрипта для простоты. Более того, когда я перезапускаю блокнот на Kaggle, я называю версию хешем текущего коммита Git, чтобы отслеживать, какая версия кода использовалась для получения результатов. 6.
3.4 Собираем все вместе
В конце необходимы две тетради:
- Блокнот клонирования: клонирует репозиторий и устанавливает необходимые пакеты.
- Блокнот сценариев: запускает один из сценариев.
Вам может понадобиться больше блокнотов сценариев в процессе разработки. Например, один блокнот может быть для обучения, а другой — для вывода. Каждый из этих блокнотов будет иметь ту же структуру, что и блокнот сценариев, описанный выше.
Выделение каждого этапа конвейера (например, предобработки данных, обучения, вывода) в отдельный блокнот полезно, когда один этап выполняется долго и редко меняется. Например, в Ariel Data Challenge мой этап предобработки занял более семи часов. Если бы всё хранилось в одном блокноте, мне пришлось бы ждать по семь часов каждый раз, когда я пробовал новую идею. Более того, временные ограничения ядер Kaggle сделали бы невозможным запуск всего конвейера в одном блокноте.
Каждый блокнот затем импортирует выходные данные предыдущего блокнота, выполняет свой собственный шаг и строит скрипт на его основе. Рекомендуется указывать пути к файлам данных или моделям в качестве аргументов скриптов, чтобы их можно было легко изменить при запуске в Kaggle или любой другой среде.
После обновления кода перезапустите блокнот клонирования, чтобы обновить код на Kaggle. Затем перезапустите только необходимые блокноты скриптов для получения новых результатов.
3.5 Стоят ли все эти усилия того?
Конечно да!
Я знаю, что указанный конвейер добавит некоторые накладные расходы на старте вашего проекта. Однако в долгосрочной перспективе он сэкономит вам гораздо больше времени и усилий. Вы сможете писать весь код локально и запускать его на Kaggle.
При создании новой модели вам достаточно скопировать один из блокнотов скрипта и изменить его. Конфликтов между вашим локальным кодом и кодом Kaggle не возникнет. Вы сможете отслеживать все изменения с помощью Git. Вы сможете воспроизвести любые старые результаты, просто выполнив проверку соответствующего коммита Git и перезапустив необходимые блокноты в Kaggle.
Более того, вы сможете разрабатывать на любой машине, которая вам нравится. Всё централизовано на GitHub. Вы можете работать локально. Если вам нужна большая мощность, вы можете использовать облачную виртуальную машину. Если хотите обучаться на Kaggle, это тоже возможно. Весь ваш код и окружение везде одинаковы.
Это такая небольшая цена за такое удобство. Как только процесс будет налажен, вы можете забыть о нём и сосредоточиться на самом важном: исследованиях и построении моделей!
4. Запись знаний и исследований
Погружаясь в новую область, вы будете тратить значительную часть времени на исследования, изучение и чтение статей. Легко потеряться в обилии прочитанного и забыть, где встречалась та или иная идея или концепция. Поэтому важно управлять и организовывать своё обучение.
4.1 Отслеживание показаний
Раджпуркар (2023) рекомендует вести список всех прочитанных вами работ и статей. Это позволит вам быстро просматривать прочитанное и возвращаться к нему при необходимости.
Профессор Раджпуркар также предлагает аннотировать каждую статью одной, двумя или тремя звёздочками. Статьи с одной звездой не относятся к теме статьи, но вы не знали об этом до их прочтения. Статьи с двумя звездами относятся к теме статьи. Статьи с тремя звездами — к теме статьи. Это позволяет вам быстро фильтровать материалы для дальнейшего чтения.
Также следует делать заметки по каждой прочитанной статье. Эти заметки должны отражать связь статьи с вашим проектом. Они должны быть краткими для лёгкого чтения, но при этом достаточно подробными для понимания основных идей. В списке статей следует добавить ссылки на заметки для удобства чтения к каждой статье.
Мне также нравится делать заметки на самих работах, например, выделять выделенный текст. Если вы используете программу для чтения PDF-файлов или устройство с электронными чернилами, сохраните аннотированную версию работы для дальнейшего использования и добавьте ссылку на неё в свои заметки. Если вы предпочитаете читать на бумаге, можно отсканировать аннотированную версию и сохранить её в цифровом формате.
4.2 Инструменты
Для большинства документов я предпочитаю Google Docs, потому что он позволяет мне получать доступ к своим заметкам откуда угодно. Более того, в Google Docs можно писать в Markdown — моём любимом формате письма (я использую его для этой статьи).
Zotero — отличный инструмент для управления исследовательскими работами. Он отлично подходит для хранения и организации статей. Вы можете создать коллекцию для каждого проекта и хранить там все соответствующие статьи. Импорт статей очень прост с помощью расширения для браузера, а экспорт ссылок в формате BibTeX — очень прост.
5. Отслеживание эксперимента
В проектах по науке о данных вам часто придётся проводить множество экспериментов и пробовать множество идей. И снова, во всём этом хаосе легко запутаться.
Мы уже добились значительного прогресса, правильно структурировав нашу кодовую базу и используя скрипты для проведения экспериментов. Тем не менее, я хочу рассказать о двух программных инструментах, которые позволяют нам добиться ещё лучших результатов.
5.1 Палочка
Weights and Biases (wandb), произносится как «w-and-b» (веса и смещения), «wand-b» (волшебный, как палочка) или «wan-db» (база данных), — отличный инструмент для отслеживания экспериментов. Он позволяет проводить несколько экспериментов и сохранять все их конфигурации и результаты в одном месте.
Wandb предоставляет нам панель инструментов для сравнения результатов различных экспериментов, используемых гиперпараметров и кривых обучения. Он также отслеживает системные метрики, такие как загрузка графического процессора и центрального процессора.
Wandb также интегрируется с библиотеками Hugging Face, что упрощает отслеживание экспериментов при использовании трансформаторов.
Как только вы начнете использовать множественные эксперименты, wandb станет незаменимым инструментом.
5.2 Гидра
Hydra — это инструмент Meta, упрощающий управление конфигурацией. Он позволяет определять все конфигурации в YAML-файлах и легко переопределять их через интерфейс командной строки.
Это очень гибкий инструмент, подходящий для самых разных случаев использования. В этом руководстве рассматривается использование Hydra для настройки экспериментов.
6. Сквозной процесс
На рисунке 2 представлен процесс, описанный в этой статье. Сначала мы исследуем идеи и записываем полученные знания. Затем мы экспериментируем с этими идеями на наших локальных компьютерах в Jupyter Notebooks. Как только у нас появляется рабочая идея, мы рефакторим код в наш модуль и создаём скрипты для проведения экспериментов. Мы запускаем новый(е) эксперимент(ы) на Kaggle. Наконец, мы отслеживаем результаты новых экспериментов.
Поскольку все тщательно отслеживается, мы можем предсказать наши недостатки и быстро вернуться к этапам исследования или разработки, чтобы исправить их.
7 Заключение
Хаос — источник всех зол в проектах по науке о данных. Если мы хотим добиться надёжных и воспроизводимых результатов, мы должны стремиться к организации и ясности процессов. Соревнования Kaggle — не исключение.
В этой статье мы обсудили метод организации нашей кодовой базы, советы по отслеживанию исследований и знаний, а также инструменты для отслеживания экспериментов. Предлагаемый метод представлен на рисунке 2.
Надеюсь, эта статья была вам полезна. Если у вас есть другие советы или предложения, пожалуйста, поделитесь ими в комментариях ниже.
Желаем удачи в следующих соревнованиях!
7.1 Ссылки
Drivendata. (2022). 10 правил надежной науки о данных.
Раджпуркар, П. (2023). Гарвард CS197: Опыт исследований искусственного интеллекта. https://www.cs197.seas.harvard.edu
Сноски
- Структура папок была скопирована с сайта ccds на момент публикации статьи.
- Предполагается, что во всех генераторах случайных чисел используется начальное число.
- При запуске любой команды bash в ячейке кода в Jupyter Notebook необходимо добавить к команде префикс !.
- При выполнении любой команды bash в ячейке кода Kaggle предполагается, что текущий рабочий каталог — /kaggle/working/. Все предыдущие команды cd игнорируются. Необходимо указывать путь к /kaggle/working/ во всех командах или начинать команды с cd PATH &&, чтобы сменить каталог перед выполнением оставшейся части команды.
- Если вы забыли путь, вы можете скопировать его из вкладки блокнота на правой боковой панели блокнота.
- Обратите внимание, что вам потребуется перезапустить блокнот клонирования, чтобы обновить код на Kaggle, прежде чем перезапускать блокнот скрипта. Не забудьте нажать «Проверить наличие обновлений» в блокноте клонирования перед перезапуском блокнота скрипта.
Источник: towardsdatascience.com
