Ожидания vs. Реальность: чем отличается изучение Data Science и настоящая работа

Автор перевода Мария Багулина

Рассказывает Kaan Aytekin

Около года назад, после курсов по Data Science и работы над несколькими научно-исследовательскими проектами я, наконец, получил должность в компании, занимающейся электронной коммерцией. В этой статье я расскажу о рабочих нюансах, с которыми редко сталкиваются обычные энтузиасты Data Science.

Основная работа ведётся на удалённом сервере

Большинство людей начинают своё путешествие по Data Science на персональных компьютерах. Однако в реальных проектах зачастую требуется гораздо большая вычислительная мощность, которую не сможет обеспечить ни ноутбук, ни даже игровой ПК. Поэтому исследователи Data Science используют свои компьютеры для доступа к удалённому серверу по SSH (Secure Shell). SSH позволяет безопасно подключиться к вычислительной машине. После установки соединения удалённый сервер можно использовать как командную оболочку вашего компьютера. Поэтому при работе с сервером пригодится знание основных команд для Linux и опыт использования терминала.

SQL — король данных

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

SQL — стандартный язык запросов для баз данных. Он используется для быстрого объединения, агрегирования, извлечения необходимой информации и позволяет удобно работать с наборами данных. Проблема в том, что большинство энтузиастов Data Science не работают с базами данных, так как обучающие датасеты обычно уже созданы кем-то другим. В действительности же 90% времени тратится на сбор и подготовку данных. Да, звучит разочаровывающе, но без данных не было бы науки о данных.

Следует отметить, что в SQL есть много диалектов, однако они похожи друг на друга — зная один, можно легко адаптироваться к другому. Просто выберите любой диалект и начните изучать его.

Признаки важнее, чем модель

Линейные модели обычно считаются слишком простыми и не подходящими для реальных задач машинного обучения. Разве можно получить правильный результат, просто линейно увеличивая число признаков? На самом деле — можно.

Более сложные модели, такие как случайный лес, xgboost, SVM и DNN, ищут нелинейные границы в пространстве признаков. Это происходит либо разделением пространства на небольшие участки, либо сопоставлением признаков с пространством большей размерности, где границы выглядят линейно. Проще говоря, процесс построения модели можно рассматривать как подгон прямой линии под вновь сгенерированные точки данных. Поскольку модели не знают истинных значений признаков, они пытаются создать эти новые точки на основе некоторого ядра или путём оптимизации псевдо-функции правдоподобия.

Звучит довольно сложно, верно? Вот почему такие модели часто называются серыми или чёрными ящиками. С другой стороны, если вы знаете реальные значения признаков, вы можете генерировать новые конструктивные признаки с помощью данных. Процесс генерации, преобразования и предварительной обработки признаков называется конструированием признаков. К его основным подходам относятся поиск стандартного отклонения, дискретизация, агрегирование признаков и так далее.

С правильно спроектированной моделью можно добиться отличных результатов. Линейные алгоритмы обычно лучше интерпретируются — вы можете увидеть значимость сгенерированных признаков и понять по их коэффициентам, насколько достоверна модель. Если коэффициент, который по логике должен быть положительным, оказался отрицательным, — вероятно, что-то не так с моделью, данными или изначальными предположениями.

Эксперимент и запуск продукта — совершенно разные вещи

Чаще всего специалисты Data Science работают в Jupyter Notebook — это простое и удобное приложение для экспериментов и ​​визуализации. Можно быстро попробовать что-то новое, обучить модель или увидеть результат вычислений, просто открыв ячейку и запустив несколько строк кода.

Но как только модель готова к выпуску в продакшн, господство Jupyter Notebook заканчивается, и власть переходит к Python-файлам. Продакшн — это работа ваших алгоритмов в реальной жизни. Конечный пользователь всегда смотрит на качество итогового продукта, поэтому код продакшна должен быть быстрым, чистым, читабельным, отказоустойчивым и простым в отладке.

Скорость кода не так важна, если вы просто экспериментируете и запускаете программу один-два раза. Однако в продакшне ваш код, вероятно, будет выполняться несколько раз в день и влиять на другие части продукта, поэтому скорость станет важна.

Посмотрим правде в глаза, наверняка в большинстве ваших .ipynb-файлов много неупорядоченных строк, неиспользованных import и ненужных ячеек. И это нормально, когда вы просто экспериментируете. Но перед выпуском в продакшн код нужно «очистить». Считайте, что ваш код достаточно чист, если кто-то в вашей команде может просмотреть его и с лёгкостью понять назначение каждой строки. Вот почему вы должны давать правильные имена своим переменным и функциям.

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

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

Но даже в отказоустойчивом коде могут быть ошибки, приводящие к непредвиденным результатам. В этом случае программу нужно отлаживать. Чтобы процесс отладки был понятным и простым, всегда следите за чистотой и качеством кода: используйте функции вместо повторяющихся конструкций, помните про правило «одна функция = одна решаемая задача» и избегайте «грязных» функций. Такая практика позволит легко найти источник ошибки в коде.

Для написания продакшн-кода вместо Jupyter Notebook лучше использовать текстовый редактор или IDE, например VS Code или PyCharm. Эти инструменты сделают разработку проще и быстрее. Если вы всё же хотите работать с Jupyter, можете попробовать использовать расширение nbconvert, которое конвертирует скрипты .ipynb в .py-файлы.

MVP лучше, чем долгосрочное исследование

Мир технологий конкурентоспособен и изменчив. В большинстве случаев у компаний нет времени ждать идеального решения, которое достигло бы наилучшего уровня производительности. Вместо этого они начинают проект с минимально жизнеспособного продукта (minimum viable product, MVP) и развивают его. MVP должен удовлетворять самым основным потребностям проекта — ни больше, ни меньше.

Перфекционистам и людям, внимательным к деталям (то есть большинству Data Science-энтузиастов), зачастую сложно работать над MVP. Обычно исследователи стремятся тщательно проанализировать данные, опробовать множество различных моделей и найти наилучшее решение. Наука о данных по сути ориентирована именно на такой подход, однако мы не зря говорим о прикладной области Data Science.

Нужно понимать, что в разработке самый важный актив — время. Никто не может предсказать путь, по которому пойдёт продукт. Возможно, со временем проект приостановят или полностью закроют. MVP создаётся, чтобы свести риски к минимуму. Даже если продукт гарантированно будет развиваться, поначалу ему может не хватать необходимых ресурсов. Построение простой модели и её постепенное развитие с появляющимися новыми данными и технологиями даёт более надёжные результаты.

Data Science привязан к Agile

Ещё одна концепция в мире технологий — использование гибких методологий для построения рабочих процессов. Agile — философия разработки, при которой проекты делятся на небольшие задачи.

На самом деле про гибкие методологии гораздо легче рассказать, чем реализовать их. Agile больше подходит командам разработчиков с чётко определёнными тактиками решения задач. Data Science-проекты же создаются путём проб и ошибок, а время выполнения конкретных задач сложно оценить из-за высокой изменчивости. Ирония в том, что Data Science-специалист даёт точные прогнозы для других бизнес-процессов, но не может сделать то же самое для своих задач.

A/B-тесты важнее обучения модели

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

Важным процессом в Agile и Data Science являются A/B-тесты. Ваша модель может превзойти предыдущее решение во время обучения, но может не работать в реальной жизни. Обучающие данные — это лишь подмножество реальных данных. Они могут быть устаревшими и содержать ошибки. Поэтому модель выпускается в продакшн только в том случае, если она показывает лучшие результаты во время A/B-тестирования.

Нужно общаться с людьми из разных сфер

Круг общения эксперта по Data Science может быть гораздо шире, чем у обычного разработчика ПО или учёного. Исследователи Data Science тесно сотрудничают как с техническими специалистами, так и с бизнес-представителями, поэтому им необходимо знать как деловую, так и техническую сторону проектов.

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

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

Исследователи Data Science должны понимать потребности бизнеса и ресурсы разработчиков, чтобы знать возможности и ограничения с обеих сторон.

Вывод

Настоящая работа Data Science-специалиста совершенно не похожа на создание любительских моделей машинного обучения для Kaggle. Я попытался перечислить ключевые различия, которые могут быть неочевидны и неизвестны заранее, и надеюсь, что вы найдёте их полезными.