Помимо написания кода, это решения на уровне проектирования, компромиссы и привычки, которые незаметно отличают опытных специалистов по анализу данных от всех остальных.
Делиться
Давайте будем честны. Писать код в 2025 году гораздо проще, чем десять или даже пять лет назад.
Мы перешли от Fortran к C, а затем к Python, и каждый шаг снижал трудозатраты на запуск проекта. Теперь такие инструменты, как Cursor и GitHub Copilot, позволяют писать шаблонный код, рефакторить функции и улучшать процессы кодирования всего несколькими строками естественного языка.
В то же время, все больше людей, чем когда-либо, увлекаются искусственным интеллектом , наукой о данных и машинным обучением. Менеджеры по продуктам, аналитики, биологи, экономисты — кого угодно — учатся программировать, понимать, как работают модели ИИ, и эффективно интерпретировать данные.
Всё это к тому, что:
Реальная разница между старшим и младшим специалистом по анализу данных уже не в уровне владения программированием.
Не поймите меня неправильно. Разница по-прежнему техническая . Она по-прежнему зависит от понимания данных , статистики и моделирования . Но дело уже не в том, чтобы уметь перевернуть бинарное дерево на доске или решить алгоритм за O(n).
На протяжении своей карьеры я работал с выдающимися специалистами по анализу данных из разных областей. Со временем я начал замечать закономерность в подходах ведущих специалистов по данным к решению проблем, и дело было не в конкретных используемых моделях или навыках программирования: речь шла о структурированном и организованном рабочем процессе, который они применяют для преобразования несуществующего продукта в надежное решение, основанное на данных.
В этой статье я опишу шестиэтапный рабочий процесс, который используют старшие специалисты по анализу данных при разработке продукта или функции на основе анализа данных. Старший специалист по анализу данных:
- Составьте карту экосистемы, прежде чем писать код.
- Рассматривайте продукты DS как операторов.
- Разработайте систему от начала до конца, используя «ручку и бумагу».
- Начните с простого, а затем заслужите право на усложнение.
- Анализ метрик и результатов.
- Настройте результаты работы под целевую аудиторию и выберите подходящие инструменты для демонстрации их трудов.
В этой статье я подробно рассмотрю каждый из этих пунктов. Моя цель — чтобы к концу статьи вы смогли самостоятельно применять эти шесть этапов, чтобы в своей повседневной работе мыслить как опытный специалист по анализу данных.
Давайте начнём!
Составление карты экосистемы
Я понимаю, специалисты по работе с данными, такие как мы, влюбляются в «ядро науки о данных» продукта. Нам нравится настраивать модели , пробовать разные функции потерь , экспериментировать с количеством слоев или тестировать новые приемы аугментации данных . В конце концов, именно так большинство из нас и обучалось. В университете акцент делается на технике, а не на среде, в которой эта техника будет применяться.
Однако опытные специалисты по анализу данных знают, что в реальных продуктах модель — это лишь часть более крупной системы. Вокруг неё существует целая экосистема , в которую необходимо интегрировать продукт. Если игнорировать этот контекст, можно легко создать что-то умное, что на самом деле не имеет значения.
Понимание этой экосистемы начинается с постановки таких вопросов:
- Какую именно проблему мы решаем, и как она решается сегодня?
- Кто будет использовать эту модель и как она изменит их повседневную работу?
- Как на практике выглядит « лучшее » с точки зрения бизнеса (меньше заявок, больше дохода, меньше ручной проверки)?
Проще говоря, прежде чем приступать к программированию или проектированию системы, крайне важно понять, что именно предлагает продукт.
Ваш ответ на этом этапе будет звучать примерно так:
[Мой продукт на основе данных] направлен на улучшение характеристики [A] для продукта [X] в системе [Y]. Продукт, созданный с помощью методов анализа данных, улучшит [Z]. Вы ожидаете получить [Q], улучшить [R] и уменьшить [T].
Рассматривайте продукты DS как операторов.
Итак, теперь, когда у нас есть четкое понимание экосистемы, мы можем начать думать о продукте на основе данных.
Это упражнение, в котором мы меняем местами кресла с реальным пользователем. Если бы мы были пользователем этого продукта, как бы выглядел наш опыт взаимодействия с ним?
Чтобы ответить на наш вопрос, нам нужно ответить на такие вопросы, как:
- Какой показатель удовлетворенности продуктом (т.е. успех/неудача) является хорошим вариантом? Каковы оптимальный, неоптимальный и наихудший варианты развития событий?
- Сколько времени допустимо ждать? Пару минут, десять секунд или реальное время?
- Какой бюджет необходим для приобретения этого товара? Сколько можно на него потратить?
- Что происходит, когда система дает сбой? Применяем ли мы решение на основе правил, запрашиваем ли у пользователя дополнительную информацию или просто показываем «нет результата»? Какое значение по умолчанию является наиболее безопасным?
Как вы могли заметить, мы приближаемся к этапу проектирования системы , но еще не совсем достигли его. Это скорее предварительный этап, на котором мы определяем все ограничения, пределы и функциональность системы.
Разработайте систему от начала до конца, используя «ручку и бумагу».
Итак, теперь у нас есть:
- Полное понимание экосистемы , в которой будет использоваться наш продукт.
- Полное понимание характеристик и ограничений требуемого продукта DS.
Таким образом, у нас есть все необходимое для начала этапа проектирования системы* .
Вкратце, мы используем все полученные ранее данные, чтобы определить:
- Вход и выход
- Структура машинного обучения, которую мы можем использовать
- Как будут формироваться обучающие и тестовые данные
- Метрики, которые мы будем использовать для обучения и оценки модели.
Для мозгового штурма в этой части можно использовать Figma и Excalidraw. Для справки, на этом изображении представлен фрагмент системного проектирования (часть модели/часть 2 из приведенного выше списка), выполненный с помощью Excalidraw.
Вот здесь и проявляются настоящие навыки опытного специалиста по анализу данных. Вся накопленная вами информация должна быть интегрирована в вашу систему. У вас небольшой бюджет ? Вероятно, обучение структуры глубокого обучения с 70 миллиардами параметров — не лучшая идея. Вам нужна низкая задержка ? Пакетная обработка не подходит. Вам нужно сложное приложение обработки естественного языка, где контекст имеет значение, а набор данных ограничен? Возможно, LLM-модели могут стать подходящим вариантом.
Помните, что это пока только «ручка и бумага»: код ещё не написан. Однако на данном этапе мы чётко понимаем, что нам нужно создать и как. Теперь , и только теперь , мы можем начать программировать.
*Проектирование систем — это огромная тема, и осветить её менее чем за 10 минут практически невозможно. Если вы хотите углубиться в эту тему, я настоятельно рекомендую курс от ByteByteGo.
Начните с простого, а затем заслужите право на усложнение.
Когда старший специалист по анализу данных работает над моделированием, самые сложные, мощные и изощренные модели машинного обучения обычно пробуются в последнюю очередь.
Обычно рабочий процесс состоит из следующих шагов:
- Попробуйте решить задачу вручную : что бы вы сделали, если бы эту задачу выполняли вы (а не машина)?
- Разработайте функции : исходя из того, что вы знаете из предыдущего пункта (1), какие функции вы бы рассмотрели? Можете ли вы разработать функции, которые позволят эффективно выполнить вашу задачу?
- Начните с простого : попробуйте достаточно простую* традиционную модель машинного обучения, например, случайный лес/логистическую регрессию для классификации или линейную/полиномиальную регрессию для задач регрессии. Если она окажется недостаточно точной, постепенно усложняйте модель.
Когда я говорю «прокладывайте себе путь наверх», я имею в виду именно это:
В двух словах: мы увеличиваем сложность только тогда, когда это необходимо. Помните: мы не пытаемся впечатлить кого-либо новейшими технологиями, мы стремимся создать надежный и функциональный продукт, основанный на данных.
Когда я говорю «достаточно просто», я имею в виду, что для решения некоторых сложных задач некоторые очень простые алгоритмы машинного обучения могут быть уже неприменимы. Например, если вам нужно создать сложное приложение для обработки естественного языка, вы, вероятно, никогда не будете использовать логистическую регрессию, и можно смело начинать с более сложной архитектуры из Hugging Face (например, BERT).
Анализ метрик и результатов.
Одно из ключевых отличий между опытным специалистом и рядовым профессионалом заключается в том, как они оценивают результаты моделирования.
Как правило, старшие специалисты по анализу данных тратят много времени на ручную проверку результатов. Это связано с тем, что ручная оценка — одна из первых задач, которые выполняют менеджеры по продуктам (люди, с которыми старшие специалисты по анализу данных будут делиться своей работой), чтобы оценить производительность модели. По этой причине важно, чтобы результаты работы модели выглядели «убедительно» с точки зрения ручной оценки. Более того, проанализировав сотни или тысячи случаев вручную, можно выявить ситуации, когда ваш алгоритм дает сбой. Это даст отправную точку для улучшения модели, если это необходимо.
Конечно, это только начало. Следующий важный шаг — выбор наиболее подходящих метрик для количественной оценки. Например, хотим ли мы, чтобы наша модель корректно представляла все классы/варианты выбора в наборе данных? Тогда очень важна полнота (recall ). Хотим ли мы, чтобы наша модель была чрезвычайно точной при классификации, даже ценой потери охвата данных? Тогда мы отдаем приоритет точности (precision ). Хотим ли мы и того, и другого? Показатели AUC/F1 — наш лучший выбор.
В двух словах: лучшие специалисты по анализу данных точно знают, какие метрики использовать и почему. Именно эти метрики будут сообщаться внутри компании и/или клиентам. Более того, эти метрики станут эталоном для следующей итерации: если кто-то хочет улучшить вашу модель (для той же задачи), он должен улучшить именно эту метрику.
Настройте результаты работы под целевую аудиторию и выберите подходящие инструменты для демонстрации своих проектов.
Давайте подведем итоги того, где мы находимся:
- Мы определили место нашего продукта DS в экосистеме и обозначили наши ограничения.
- Мы разработали проект системы и создали модель машинного обучения.
- Мы провели оценку , и она достаточно точна.
Наконец, настало время представить нашу работу. Это крайне важно: качество вашей работы напрямую зависит от вашей способности её донести. Первое, что мы должны понять:
Кому мы это показываем?
Если мы демонстрируем это специалисту по анализу данных для оценки модели, или инженеру-программисту для внедрения нашей модели в производство, или менеджеру по продукту , которому необходимо будет отчитаться о работе перед вышестоящими руководителями, нам потребуются разные способы предоставления результатов.
Вот общее правило:
- Менеджерам по продуктам будет предоставлен общий обзор модели и результаты анализа метрик.
- Более подробное объяснение деталей модели и метрик будет предоставлено специалистам по анализу данных.
- Практические детали, с помощью скриптов кода и блокнотов, будут переданы супергероям, которые превратят этот код в продукт: инженерам-программистам.
Выводы
В 2025 году написание кода — это не то, что отличает старшего специалиста по анализу данных от младшего. Старшие специалисты по анализу данных не «лучше» потому, что они знают документацию TensorFlow наизусть. Они лучше потому, что у них есть определенный рабочий процесс , который они используют при создании продукта, основанного на данных.
В этой статье мы описали стандартный рабочий процесс старшего специалиста по анализу данных в шестиступенчатой форме:
- Коммуникационный слой для адаптации подачи информации к аудитории (история менеджера проекта, строгий подход к анализу данных, готовые к использованию инженерами материалы).
- Способ составить карту экосистемы до начала работы над кодом (проблема, базовый уровень, пользователи, определение понятия «лучшее»).
- Структура для анализа характеристик DS, таких как операторы (задержка, бюджет, надежность, режимы отказов, наиболее безопасное значение по умолчанию).
- Простой процесс проектирования системы с использованием ручки и бумаги (входы/выходы, источники данных, цикл обучения, цикл оценки, интеграция)
- Рабочий процесс моделирования, который начинается с простых шагов и усложняется только тогда, когда это необходимо.
- Практический метод анализа результатов и метрик (сначала ручная проверка, затем выбор подходящей метрики для достижения цели продукта).
- Коммуникационный слой для адаптации подачи информации к аудитории (история менеджера проекта, строгий подход к анализу данных, готовые к использованию инженерами материалы).
Перед тем как отправиться в путь
Ещё раз большое спасибо за ваше время. Это очень много значит для меня ❤️
Меня зовут Пьеро Пайалунга, а вот этот парень:
Я родом из Италии, имею докторскую степень Университета Цинциннати и работаю специалистом по анализу данных в компании The Trade Desk в Нью-Йорке. Я пишу об искусственном интеллекте, машинном обучении и меняющейся роли специалистов по анализу данных как здесь, на TDS, так и в LinkedIn. Если вам понравилась статья и вы хотите узнать больше о машинном обучении и следить за моими исследованиями, вы можете:
А. Подписывайтесь на меня в LinkedIn , где я публикую все свои истории.
Б. Подпишитесь на меня в GitHub , где вы сможете увидеть весь мой код.
C. По всем вопросам вы можете отправить мне электронное письмо по адресу [email protected]
Источник: towardsdatascience.com
