5 лет сообщества Data Science — ВАШ опыт общения с заинтересованными сторонами, задавания хороших вопросов и плохого общения.
В моем недавнем посте 5 Years of Data Science — мысли о трудных стартах, переоцененных комментариях и мусорных данных мы говорили о 5 вещах, которые я усвоил за первые 5 лет работы с data science.
Однако мне было любопытно узнать, что вы узнали. Поэтому я обратился к reddit / r / datascience, чтобы спросить других об их 5 основных уроках за первые 5 лет работы с наукой о данных.
Тема была достаточно популярной, набрав более 50 000 просмотров. Я отфильтровал множество списков, опубликованных в комментариях, и выделил 5 лучших из ваших знаний.
Небольшое примечание: я попытался связаться с пользователем, упомянутым в этом посте, чтобы иметь возможность правильно указать их имя, например, со ссылкой на их Twitter или GitHub. Если вы знаете или являетесь одним из этих пользователей и хотите, чтобы вас отметили, напишите: [email protected].
1. Когда увольнять заинтересованного лица
Если ваша заинтересованная сторона заботится о проекте меньше, чем вы, прекратите работу над этим проектом.
В корпоративных условиях вы часто работаете в отделе обработки данных, который выполняет проекты для конкретных заинтересованных сторон в компании. То же самое верно и для многих других сценариев, например, в академических кругах или в качестве независимого консультанта.
Вы должны работать над проектом только в том случае, если ваша заинтересованная сторона заботится о нем по крайней мере так же сильно, как и вы. Мы могли бы сократить это утверждение до: «Ваша заинтересованная сторона должна иметь свою шкуру в игре».
Если это не так, могут случиться плохие вещи. Они могут не предоставить вам адекватные метаданные, дать вам неточное описание своих потребностей или просто потратить ресурсы на плохо построенную проблему.
Не каждый проект спасет положение. На самом деле это делают лишь некоторые из них.
Но работать над чем-то, что, по мнению даже владельца проекта, не стоит их внимания, пустая трата времени. времени каждого.
В своем подкасте Люди, которыми я (в основном) восхищаюсь Стив Левитт часто подробно рассказывает о навыке выхода из проекта: когда его заинтересованному лицу все равно» на ваш репертуар.
Бонус: не стройте мосты из титана.
Интересно, что пользователь, называющий себя «заинтересованным лицом», добавляет:
Не стройте мосты из титана. Или другими словами: не переусердствуйте.
Большие проблемы требуют больших решений, а маленькие проблемы требуют только маленьких.
Не стройте нейронную сеть, если достаточно подсчета.
2. Аристотель был специалистом по данным
Отправка записной книжки владельцу продукта/менеджеру — неправильный способ поделиться своими мыслями.
Аристотель никогда бы не подарил Jupyter Notebook аудитории PowerPoint.
По словам греческого философа, вы убеждаете людей с помощью Логоса, Этоса и Пафоса: Содержание, Достоверность и (Знание вашего) Клиента (плохая аллитерация моя).
Неважно, насколько проницательны ваши результаты (Логос) и сколько наград вы получили (Этос), когда вы передаете Jupyter Notebook тому, кто никогда раньше не писал код, вы проявляете неуважение Пафос.
Будьте более убедительны, встречаясь с людьми там, где они есть.
Хорошая новость заключается в том, что с помощью такого инструмента, как Quarto, вы можете превратить свою любимую Jupyter Notebook в слайды PowerPoint для отдела маркетинга, интерактивный веб-сайт для клиента или в распечатке для вашего босса.
Великие специалисты по данным используют свой набор навыков, чтобы чтить Pathos и встречаться с людьми там, где они есть.
3. По-настоящему понять ваши данные сложно
Обучающие модели даются многим легко, а очистка и понимание данных — нет, и я видел, как многие «опытные» специалисты по данным сбивались с этого.
Это относится к пункту из моей оригинальной статьи: Впечатляющие данные делают интересным проект. Получение данных, которые трудно получить, и очистка данных, которые не только грязные, но и грязные, отличают вас от других.
Однако действительное понимание имеющихся данных добавляет новое измерение.
Табличные данные, изображения, видео, аудио, сетевые, геномные или текстовые данные выглядят совершенно по-разному, и потребуется время, чтобы просто понять, что на самом деле представляют строки и столбцы ваших данных.
Чтобы сделать еще один шаг вперед и по-настоящему понять, как собирались данные, что измерялось и какую информацию можно извлечь, требуется время, но это бесценно.
4. Как лучше задавать вопросы?
Получение посредственного ответа на правильный вопрос ››››› получение отличного ответа на неправильный вопрос.
Мы пытаемся ответить на вопрос с помощью анализа данных. Если предположить, что мы задаем идеальный вопрос, все, что остается сделать, это дать наиболее точный ответ.
Однако что, если наш вопрос на самом деле неправильный?
Как лучше задавать вопросы? По этому поводу я нашел несколько статей, например, эту от Адмонда Ли на среде. Тем не менее, мне кажется, что это все еще продолжается дискуссия.
Одной из отправных точек может быть запись фактов вашей задачи и действительно подумайте о вашей проблеме:
- Какие данные у меня есть?
- Могу ли я получить больше данных?
- Сколько времени у меня есть?
- Какова поставленная цель проекта?
- Какова настоящая цель проекта?
Со временем наши ответы будут становиться все лучше и лучше, поскольку вычислительные ресурсы улучшаются, а область машинного обучения изобретает еще более «точные» методы.
Узким местом является сама проблема: если мы задаем неправильный вопрос, мы получаем точный, но неправильный ответ.
Вы бы предпочли стрелять неточно в правильную цель или точно не в ту цель?
Последнее выглядит более причудливо, но первое — честный выбор.
Я настоятельно рекомендую этот пост от Роджера Пенга: Тьюки, дизайн-мышление и лучшие вопросы, если вы хотите узнать больше о мыслительном процессе, стоящем за постановкой лучших вопросов. Особенно его диаграмма Сила доказательств против качества вопроса очень проницательна.
5. Юнит-тесты делают профессионалы
Напишите как можно больше тестов. Не принимайте вещи как должное, даже если это выглядит просто.
В исходном посте я говорил о том, как кодирование делает вас более профессиональным: модульные тесты делают вас профессионалом в написании кода.
Что такое модульный тест?
Часто упускаемые из виду в науке о данных модульные тесты становятся критически важными при перемещении модели на этап производства и могут сохранить анализ данных в контексте исследования.
По моему опыту, отделы обработки данных перекладывают эту ответственность на «настоящих программистов», которые реализуют ваш прототип как производственную версию. Однако причин для этого нет. Модульные тесты не сложны, и лучше всего их реализует тот, кто в первую очередь пишет код.
assert a == b, "A is not equal to B: There is a problem!"Итак, модульный тест.
Конечно, они могут стать более сложными, и для их реализации даже есть специальные пакеты, например, unittest или pytest. Но в конечном итоге все сводится к утверждению, подобному приведенному выше: проверьте, что условие равно true, в противном случае уведомите меня.
В идеале вы должны написать модульный тест даже до реализации соответствующего кода:
- Какой результат я хочу?
- Напишите модульный тест, который проверяет этот результат
- Напишите код, который проходит этот модульный тест
Таким образом, у вас уже есть модульный тест, который выявляет множество ошибок в вашем коде. Пока тест «хороший», ваш код будет делать то, что вы хотите.
Большое спасибо за эти материалы! Они заставили меня о многом задуматься, и я надеюсь, что они также натолкнут других на новые идеи.
