Why You Need to Follow Up After Your Data Science Project

eugeneyan

eugeneyan

Начните здесь Статьи Выступления Прототипирование Обо мне

Why You Need to Follow Up After Your Data Science Project

Почему нужно довести дело до конца после завершения data science проекта

[ mechanism datascience productivity ] · 12 min read

[ mechanism datascience productivity ] · чтение на 12 мин

After completing a data science project, it’s tempting to just commit the code and consider it done. After all, with git, we have the code changes—that’s enough, right? I wish.

После завершения data science проекта возникает соблазн просто закоммитить код и считать дело сделанным. В конце концов, с git у нас есть изменения кода — этого ведь достаточно, верно? Если бы.

First-iteration code is messy, especially in the early stages of data science projects such as experiments and proof of concepts (POCs). This makes it difficult to replicate the 98.67% accuracy achieved, after putting it aside for a few months. Problems include:

Код первой итерации неаккуратен, особенно на ранних стадиях data science проектов, таких как эксперименты и proof of concept (POC). Из-за этого спустя несколько месяцев становится сложно воспроизвести достигнутую точность в 98,67%. Среди проблем:

Тупиковый код: мы провели множество экспериментов и столкнулись с множеством тупиков; они всё ещё присутствуют в коде. Через несколько месяцев будет трудно отделить тупиковые ветки от рабочего подхода. Неверная последовательность запуска: data science пайплайны строго последовательны; каждый шаг зависит от предыдущего. Запустите их в другом порядке — и получите другие результаты. Плохой контроль версий для ноутбуков Jupyter: data science прототипы в основном делаются в Jupyter-ноутбуках. К сожалению, ноутбуки плохо работают с git. Повторный запуск ноутбука приводит к различиям в тысячи строк и затуманивает изменения в коде.

Jupyter notebooks are now an essential part of the data science experimentation workflow. Cell outputs (e.g., images, tables, logs, etc.) can be stored within notebooks and easily shared. Others can open the notebook and—without re-running it—view the code and results.

Ноутбуки Jupyter сегодня — неотъемлемая часть процесса экспериментов в data science. Выводы ячеек (например, изображения, таблицы, логи и т. д.) можно хранить прямо в ноутбуках и легко ими делиться. Другие могут открыть ноутбук и — не перезапуская его — увидеть код и результаты.

This is due to Jupyter notebooks being stored in json format with metadata, source code, formatted text, media, etc. Unfortunately, this doesn’t play well with git, which works best with plain text.

Это связано с тем, что Jupyter-ноутбуки хранятся в формате json с метаданными, исходным кодом, форматированным текстом, медиа и т. д. К сожалению, это плохо сочетается с git, который лучше всего работает с простым текстом.

The cell outputs, which we love, can be annoying when using version control (e.g., git). While a small change in code will also change the output, the output change is more copious and distracts from the code change (in git diff). This makes it difficult to collaborate on notebooks.

Выводы ячеек, которые мы так любим, могут раздражать при использовании контроля версий (например, git). Хотя небольшое изменение в коде меняет и вывод, изменение вывода куда объёмнее и отвлекает от изменения кода (в git diff). Из-за этого сложно совместно работать над ноутбуками.

"Oh, I'm just changing one line of code to add gridlines. No biggie."

«Да я просто меняю одну строку кода, чтобы добавить сетку. Ничего страшного.»

In the example above, we’re plotting the same sine curve, except we add gridlines on the right. It’s solely aesthetic and doesn’t affect the outcomes. However, when reviewing the pull request, we'll see the git diff below. And that’s from a single-line code change—this becomes unmanageable quickly.

В примере выше мы строим ту же синусоиду, только добавляем сетку справа. Это чисто эстетика, на результаты это не влияет. Однако при ревью pull request мы увидим приведённый ниже git diff. И это от изменения одной строки кода — такое быстро становится неуправляемым.

This is all from a single-line code change. Boggling, eh?

И всё это — от изменения одной строки кода. Ошеломляет, да?

As a result, I developed a habit of converting Jupyter notebooks to .py at each milestone, doing some refactoring along the way. There’re also other tools such as nbdime, reviewNB, and jupytext to solve this problem.

В результате у меня выработалась привычка конвертировать Jupyter-ноутбуки в .py на каждой вехе, попутно проводя рефакторинг. Существуют и другие инструменты для решения этой проблемы, такие как nbdime, reviewNB и jupytext.

Also, my friend Yi Xiang recently wrote a cool post about writing .py files and running them as pseudo-Jupyter notebooks on Docker. This is a another great way of getting round the version control problem.

Кроме того, мой друг Yi Xiang недавно написал классный пост о том, как писать файлы .py и запускать их как псевдо-Jupyter-ноутбуки в Docker. Это ещё один отличный способ обойти проблему контроля версий.

There’s also missed opportunity from not following-up after a project is completed. Benefits of documenting and sharing your work include:

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

Экономия времени (в долгосрочной перспективе): Память быстро деградирует, и вскоре вы не будете помнить того, чего не будете помнить. Ваше будущее «я» поблагодарит вас за сэкономленные усилия при попытке разобраться в обоснованиях, методологии и результатах. Передача знаний: команда сможет продолжить работу над проектом в ваше отсутствие (и вас не дёрнут пейджером во время отпускной сиесты в Гранаде). Новые идеи и сотрудничество: возникают новые идеи и возможности для сотрудничества по применению вашей работы к другим сценариям (см. 👉 ниже). Вовлечение сообщества: сообщество учится на вашем опыте (и ошибках). Это помогает брендингу и рекрутингу вашей команды, а также вашему личному профилю.

One of my first projects was to build a product classifier for an e-commerce platform. The goal was to automatically classify the hundreds of thousands of new products that were added daily.

Одним из моих первых проектов было создание классификатора товаров для e-commerce платформы. Цель состояла в том, чтобы автоматически классифицировать сотни тысяч новых товаров, добавляемых ежедневно.

An MVP (top-3 accuracy of 95%) was developed and put into production after a couple of months. I then spent some time building a simple user interface (similar to this) and wrote about it for our internal data science newsletter.

За пару месяцев был разработан MVP (top-3 точность 95%) и выведен в продакшен. Затем я потратил некоторое время на создание простого пользовательского интерфейса (похожего на этот) и написал о нём в нашу внутреннюю data science рассылку.

No one tried the curl commands. But when we shared the UI, our demo server crashed. 🤷‍♂️

Никто не попробовал команды curl. Но когда мы поделились UI, наш демо-сервер упал. 🤷‍♂️

We did not expect such a positive response. The search team sought to collaborate on a search-intent classifier: Given a search query, what are the most relevant product categories? The product reviews team wanted help on classifying product reviews: Which reviews should be approved? Which should be denied and for what reasons (e.g., profanity, personal details, spam, etc.)?

Мы не ожидали такого положительного отклика. Команда поиска захотела вместе поработать над классификатором поискового намерения: по поисковому запросу — какие категории товаров наиболее релевантны? Команда отзывов о товарах хотела помощи в классификации отзывов: какие отзывы стоит одобрить? Какие отклонить и по каким причинам (например, нецензурная лексика, личные данные, спам и т. д.)?

This lead to a virtuous cycle where we got more opportunities and work, earned more trust, and grew our contribution to the organization—all from a week’s effort of building a simple UI and writing a newsletter.

Это привело к благоприятному циклу, в котором мы получили больше возможностей и работы, заслужили больше доверия и увеличили свой вклад в организацию — и всё это благодаря неделе усилий на создание простого UI и написание заметки в рассылку.

This is part three (after) of a three-part series on data science project practices. Also see part 1 (before) and part 2 (during).

Это третья часть (после) трёхчастной серии о практиках data science проектов. См. также часть 1 (до) и часть 2 (во время).

Do These Practices Apply to Me?

Применимы ли эти практики ко мне?

This may not apply to you if:

Это может быть к вам неприменимо, если:

Вы работаете над data science проектами однопоточно, от задачи к исследованию и решению, за пару месяцев. Вы дисциплинированно проводите рефакторинг и подчищаете свой код, поддерживая его DRY. Вы последовательно документируете свою работу (например, обоснования, методологию, результаты и т. д.) так, чтобы другие могли воспроизвести результаты.

If you do the above, bravo! Go ahead and skip to the last step. Else, read on.

Если вы делаете всё вышеперечисленное — браво! Можете сразу перейти к последнему шагу. В противном случае — читайте дальше.

(Note: The following practices also apply to personal projects. In fact, personal projects benefit more as you’re not working in a team and getting feedback. It also furthers your learning from the project.)

(Примечание: следующие практики также применимы к личным проектам. На самом деле личные проекты выигрывают больше, так как вы не работаете в команде и не получаете обратной связи. Это также углубляет ваше обучение на проекте.)

Make Your Work Reproducible Each Run, Every Run

Сделайте свою работу воспроизводимой при каждом запуске, всегда

Remember the time when you revisited a project (from a few months back), ran the code, and got the same results again? Me neither.

Помните, как вы возвращались к проекту (несколько месяцев спустя), запускали код и получали те же результаты снова? Вот и я нет.

Once, I had to pick up a project done by someone else (who had left the organization before I joined). Results from the project (i.e., machine learning metrics) had been presented and committed to the client—but I couldn’t #$^!@% replicate it. What ensued was days and weeks of figuring which permutation of notebooks to run in which magical order—no one should have to go through that.

Однажды мне пришлось подхватить проект, сделанный кем-то другим (кто покинул организацию ещё до моего прихода). Результаты проекта (то есть метрики машинного обучения) уже были представлены и зафиксированы для клиента — но я не мог их #$^!@% воспроизвести. Последовали дни и недели выяснения того, какую перестановку ноутбуков запускать в каком магическом порядке — никому не должно приходиться через это проходить.

It's too easy to create Jupyter notebook copies, leading to notebook hell.

Слишком легко наплодить копий Jupyter-ноутбуков, что приводит к ноутбучному аду.

Thus, I made it a habit to package my projects, especially those in an unfinished state (i.e., not in production), so someone else can easily replicate the work. This doesn’t have to be complicated or take a lot of time.

Поэтому я взял за привычку упаковывать свои проекты, особенно те, что находятся в незавершённом состоянии (то есть не в продакшене), чтобы кто-то другой мог легко воспроизвести работу. Это не обязательно должно быть сложно или отнимать много времени.

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live” – John Woods

«Всегда пишите код так, как будто сопровождать его в итоге будет склонный к насилию психопат, который знает, где вы живёте» — John Woods

It starts with a script to replicate your code environment. I use a Makefile; running make setup will create the python virtual environment and install the required dependencies.

Всё начинается со скрипта для воспроизведения вашего окружения кода. Я использую Makefile; запуск make setup создаст виртуальное окружение python и установит необходимые зависимости.

setup: python -m venv .venv && . .venv/bin/activate pip install --upgrade pip pip install -r requirements.dev pip install -r requirements.prod

setup: python -m venv .venv && . .venv/bin/activate pip install --upgrade pip pip install -r requirements.dev pip install -r requirements.prod

Then, I have a script to run the code or notebooks end-to-end, in the right sequence (see 👉 below). One of the steps should include a train-validation split. A final step should evaluate and compare model metrics on the validation set—evaluation metrics should be identical every run.

Затем у меня есть скрипт, чтобы запустить код или ноутбуки сквозным образом, в правильной последовательности (см. 👉 ниже). Один из шагов должен включать разбиение на train-validation. Финальный шаг должен оценивать и сравнивать метрики модели на валидационном наборе — метрики оценки должны быть идентичными при каждом запуске.

(Note: While machine learning has a degree of stochasticity, fixing the seed should lead to reproducible results. Set the seed in processes involving shuffle (e.g., splitting data, cross-validation, iterative data loaders) and model training.)

(Примечание: хотя машинному обучению свойственна доля стохастичности, фиксация seed должна приводить к воспроизводимым результатам. Устанавливайте seed в процессах, где задействован shuffle (например, разбиение данных, кросс-валидация, итеративные загрузчики данных), и при обучении модели.)

If your pipeline can run on a single machine, create a docker image for it—this lets you spin up a fresh, clean environment with each run. (If not, run the pipeline on a spot instance cluster.) The docker container will set up the environment and run the scripts, throwing an error if the results are different.

Если ваш пайплайн может работать на одной машине, создайте для него docker-образ — это позволит поднимать свежее, чистое окружение при каждом запуске. (Если нет, запускайте пайплайн на кластере spot instance.) Docker-контейнер настроит окружение и запустит скрипты, выбросив ошибку, если результаты будут отличаться.

Don’t forget to provide a README on how to run your pipeline and check the results. Have a team member or two verify reproducibility.

Не забудьте предоставить README о том, как запускать ваш пайплайн и проверять результаты. Попросите одного-двух коллег по команде проверить воспроизводимость.

We’ll need a few extra scripts to set up the Docker container to run our notebooks. First, a simple shell script that runs the notebooks in order. This should execute and update the notebooks with the output, letting us review the results at our convenience.

Нам понадобится несколько дополнительных скриптов, чтобы настроить Docker-контейнер для запуска наших ноутбуков. Сначала — простой shell-скрипт, который запускает ноутбуки по порядку. Он должен выполнять и обновлять ноутбуки с выводом, позволяя нам просматривать результаты в удобное время.

jupyter nbconvert --ExecutePreprocessor.timeout=-1 --execute --inplace --to notebook notebooks/1-data-prep.ipynb jupyter nbconvert --ExecutePreprocessor.timeout=-1 --execute --inplace --to notebook notebooks/2-feature-engineering.ipynb jupyter nbconvert --ExecutePreprocessor.timeout=-1 --execute --inplace --to notebook notebooks/2b-data-visualizations.ipynb jupyter nbconvert --ExecutePreprocessor.timeout=-1 --execute --inplace --to notebook notebooks/3-train-val-split.ipynb jupyter nbconvert --ExecutePreprocessor.timeout=-1 --execute --inplace --to notebook notebooks/4-train-model.ipynb

jupyter nbconvert --ExecutePreprocessor.timeout=-1 --execute --inplace --to notebook notebooks/1-data-prep.ipynb jupyter nbconvert --ExecutePreprocessor.timeout=-1 --execute --inplace --to notebook notebooks/2-feature-engineering.ipynb jupyter nbconvert --ExecutePreprocessor.timeout=-1 --execute --inplace --to notebook notebooks/2b-data-visualizations.ipynb jupyter nbconvert --ExecutePreprocessor.timeout=-1 --execute --inplace --to notebook notebooks/3-train-val-split.ipynb jupyter nbconvert --ExecutePreprocessor.timeout=-1 --execute --inplace --to notebook notebooks/4-train-model.ipynb

Then, a Dockerfile that builds our image with the required python dependencies. I use a simple requirements.txt here.

Затем — Dockerfile, который собирает наш образ с необходимыми зависимостями python. Здесь я использую простой requirements.txt.

FROM python:3.8 LABEL maintainer='eugeneyan <[email protected]>' WORKDIR /poc-docker-template COPY ./requirements.txt /poc-docker-template/ # Install python requirements RUN pip install -r requirements.txt

FROM python:3.8 LABEL maintainer='eugeneyan <[email protected]>' WORKDIR /poc-docker-template COPY ./requirements.txt /poc-docker-template/ # Install python requirements RUN pip install -r requirements.txt

With these, building the Docker image and running the Jupyter notebooks end-to-end is simply:

С этим сборка Docker-образа и сквозной запуск Jupyter-ноутбуков сводятся просто к:

# Build the container and tag it as 'poc-docker-template' docker build --tag poc-docker-template . # Run the container and the script 'run.sh' docker run --rm -v $(PWD):/poc-docker-template --name tmp -t poc-docker-template /bin/bash run.sh

# Build the container and tag it as 'poc-docker-template' docker build --tag poc-docker-template . # Run the container and the script 'run.sh' docker run --rm -v $(PWD):/poc-docker-template --name tmp -t poc-docker-template /bin/bash run.sh

This mounts our local project directory on the container via -v $(PWD):/poc-docker-template. Thus, while our notebooks (in the project directory) are run in the container, updates will be reflected locally. Think of it as a (disposable) virtual environment that includes the operating system.

Это монтирует нашу локальную директорию проекта в контейнер через -v $(PWD):/poc-docker-template. Таким образом, хотя наши ноутбуки (в директории проекта) запускаются в контейнере, обновления отразятся локально. Думайте об этом как об (одноразовом) виртуальном окружении, включающем операционную систему.

For more details, check out this GitHub repository. Try it for yourself.

Подробнее смотрите в этом GitHub-репозитории. Попробуйте сами.

Recall the scenario this section began with. Now, instead of spending days (and weeks) to replicate the previous results, we can do it in minutes and hours. Instead of starting with confusion, debugging, and unnecessary effort, we start with working code, reproducible outcomes, confidence, and ease of mind.

Вспомните сценарий, с которого начался этот раздел. Теперь, вместо того чтобы тратить дни (и недели) на воспроизведение предыдущих результатов, мы можем сделать это за минуты и часы. Вместо того чтобы начинать с путаницы, отладки и лишних усилий, мы начинаем с рабочего кода, воспроизводимых результатов, уверенности и спокойствия.

Document Everything, Especially What’s Not in Code

Документируйте всё, особенно то, чего нет в коде

Working code and reproducible results are a must-have. However, this only captures part of the work—it doesn’t explain the business context, motivation, methodology, and (negative) experiment results.

Рабочий код и воспроизводимые результаты — обязательны. Однако это охватывает лишь часть работы — это не объясняет бизнес-контекст, мотивацию, методологию и (отрицательные) результаты экспериментов.

Thus, documentation is important. I tend to write it like an industry conference / applied research paper. It should cover:

Поэтому документация важна. Я склонен писать её как статью для отраслевой конференции / прикладную научную работу. Она должна охватывать:

Мотивация: почему эта проблема или возможность важна? Какова оценочная выгода (например, улучшение клиентского опыта, рост выручки, экономия затрат)? Обзор литературы: как другие пытались решить эту проблему? Что сработало (и не сработало)? Как эти подходы определили нашу дорожную карту? Данные: каков наш источник данных? Какая у них схема? Каковы их особенности и недостатки? Какой временной период мы использовали? Методология: как мы очищали данные и создавали признаки? Какие техники машинного обучения мы пробовали? О чём говорит анализ (например, кривые обучения, компромиссы)? Как мы оценивали подходы (например, ML-метрики, задержка инференса, ограничения по ресурсам)? Результаты: каковы были результаты офлайн-валидации? Если проводились A/B-тесты, каковы их итоги? Каковы наш анализ и интерпретация? Следующие шаги: как можно улучшить существующую реализацию? Какие идеи кажутся наиболее перспективными при наименьших усилиях?

“Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing.” – Dick Brandon

«Документация как секс: когда она хороша — она очень, очень хороша; а когда плоха — всё равно лучше, чем ничего.» — Dick Brandon

When writing documentation, I often find my understanding of the work lacking, especially on the methodology and results. When we conduct hundreds of experiments, it’s easy to forget or confuse certain details.

Когда я пишу документацию, я часто обнаруживаю, что моё понимание работы неполно, особенно по методологии и результатам. Когда мы проводим сотни экспериментов, легко забыть или перепутать некоторые детали.

Thus, I have to revisit my work, dig into the details, and write it down. The sooner I do this, the better my memory, and the lesser effort needed. Imagine not having documentation and revisiting the work after a few months—many details would be lost forever.

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

The documentation (likely a word doc or wiki) can then be shared with the team for knowledge transfer and feedback. Together with the working code, someone else can pick up where you left off, increasing the bus factor of the project.

Документацию (вероятно, это word-документ или wiki) затем можно поделиться с командой для передачи знаний и обратной связи. Вместе с рабочим кодом кто-то другой сможет подхватить с того места, где вы остановились, повышая bus factor проекта.

Don't be the person who wrote a ton of code and left.️

Не будьте тем человеком, который написал кучу кода и ушёл.️

Don’t Keep Your Awesome Work to Yourself—Share It

Не держите свою отличную работу при себе — делитесь ею

It’s a pity to keep the work to yourself or your team. There are many venues you can share it, such as (internal) demos, conferences, meet-ups, and tech blogs (both work-related and personal).

Жаль держать работу при себе или в пределах своей команды. Есть множество площадок, где можно ею поделиться: (внутренние) демо, конференции, митапы и техноблоги (как рабочие, так и личные).

It doesn’t take much more effort—just pick out the relevant sections from your documentation and tweak it to suit different audiences, such as:

Это не требует больших дополнительных усилий — просто выберите релевантные разделы из вашей документации и подстройте их под разные аудитории, такие как:

Внутренние стейкхолдеры: у них есть бизнес-контекст и мотивация, и они хотят сосредоточиться больше на результатах (читай: 💰💰💰). Не нагружайте техническими деталями. Они будут спрашивать: «Чем это поможет мне?» Практики: у них есть технические знания, и им интересны ваше исследование, методология, реализация и (неудачные) результаты экспериментов. Смело углубляйтесь в детали. Они будут спрашивать: «Как мне это воспроизвести?» Продуктовые и бизнес-лидеры: им больше интересен общий обзор, и они сосредоточены на сценариях использования и результатах. Они будут спрашивать: «Как мне применить это к моему продукту/организации?»

I’m always surprised by the benefits from sharing about the effort, both work-related and personal. Firstly, there’s immense satisfaction from sharing with the community, and they’re often appreciative. This helps the industry and community to learn from your experience and failures and level up.

Меня всегда удивляют выгоды от того, что делишься своими усилиями, как рабочими, так и личными. Во-первых, есть огромное удовлетворение от обмена с сообществом, и оно часто благодарно. Это помогает индустрии и сообществу учиться на вашем опыте и неудачах и расти.

Knowledge Shared = Knowledge Squared

Знание, которым поделились = Знание в квадрате

Second, we get valuable feedback and suggestions for improvement. Furthermore, sharing our team’s awesome work helps with team branding and recruitment efforts. Many quality candidates reach out because they attended a meet-up, or heard good things about a meet-up. It also starts relationships with other organizations for knowledge sharing.

Во-вторых, мы получаем ценную обратную связь и предложения по улучшению. Кроме того, обмен отличной работой нашей команды помогает брендингу команды и рекрутингу. Многие качественные кандидаты выходят на связь, потому что побывали на митапе или слышали хорошее о митапе. Это также завязывает отношения с другими организациями для обмена знаниями.

Last, it’s also a great way to build your presence and relationships with likeminded practitioners. I’ve made many friends through sharing my work online and at meet-ups. (If you’re thinking of giving a data science talk, here are seven tips to make it kick-ass).

Наконец, это ещё и отличный способ выстроить своё присутствие и отношения с единомышленниками-практиками. Я завёл много друзей, делясь своей работой онлайн и на митапах. (Если вы подумываете выступить с докладом по data science, вот семь советов, как сделать его крутым).

These Practices Pay For Themselves Many Times Over

Эти практики окупаются многократно

“Wow, that seems like a lot of effort”, you’re wondering.

«Ого, это похоже на кучу усилий», — думаете вы.

Yes, these follow-up practices do take time (about a week or two, depending on the scale of the project). However, the long-term benefits far outweigh the effort—trust me on this and just try it once, please.

Да, эти follow-up практики действительно занимают время (примерно неделю или две, в зависимости от масштаба проекта). Однако долгосрочные выгоды намного перевешивают усилия — поверьте мне на слово и просто попробуйте хотя бы раз, пожалуйста.

Upon the completion of your current project, arrange for time to follow-up. If you need to get buy-in, highlight the benefits: reproducibility, knowledge transfer, community engagement, team branding and recruitment.

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

Remember the time when you revisited a project (from a few months back), ran the code, and got the same results again?

Me neither.

First-iteration code degrades too fast. Also, there's a lot to gain from sharing your work. Here's what worked for me👇 https://t.co/r8WpA7KXP1

Помните, как вы возвращались к проекту (несколько месяцев спустя), запускали код и получали те же результаты снова? Вот и я нет. Код первой итерации деградирует слишком быстро. Кроме того, есть много выгоды от обмена своей работой. Вот что сработало для меня👇 https://t.co/r8WpA7KXP1— Eugene Yan (@eugeneyan) 22 июля 2020

Thanks to Yang Xinyi and Tyler Wince for reading drafts of this.

Спасибо Yang Xinyi и Tyler Wince за чтение черновиков.

If you found this useful, please cite this write-up as:

Если вы нашли это полезным, пожалуйста, цитируйте эту заметку так:

Yan, Ziyou. (Jul 2020). Why You Need to Follow Up After Your Data Science Project. eugeneyan.com. https://eugeneyan.com/writing/why-you-need-to-follow-up-after-your-data-science-project/.

Yan, Ziyou. (Jul 2020). Why You Need to Follow Up After Your Data Science Project. eugeneyan.com. https://eugeneyan.com/writing/why-you-need-to-follow-up-after-your-data-science-project/.

or

или

@article{yan2020follow, title = {Why You Need to Follow Up After Your Data Science Project}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2020}, month = {Jul}, url = {https://eugeneyan.com/writing/why-you-need-to-follow-up-after-your-data-science-project/} }

@article{yan2020follow, title = {Why You Need to Follow Up After Your Data Science Project}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2020}, month = {Jul}, url = {https://eugeneyan.com/writing/why-you-need-to-follow-up-after-your-data-science-project/} }

Join 11,800+ readers getting updates on machine learning, RecSys, LLMs, and engineering.

Присоединяйтесь к 11 800+ читателям, получающим обновления о машинном обучении, RecSys, LLM и инженерии.