Устойчивая карьера в data science сейчас держится на трёх опорах: переносимых навыках работы с задачей и данными, готовности смотреть за пределы IT-сектора и осознанном использовании LLM. Такой вывод делает автор статьи на Towards Data Science с почти 20-летним опытом в индустрии, обращаясь к студентам и начинающим специалистам в data science и ML. Конкретный фреймворк или версия модели в этой логике вторичны: они меняются, а умение распознать типовую проблему, разобраться с грязными данными и подобрать адекватный метод остаётся.
Второй тезис автора касается специализации. Готовиться к обучению фронтирных LLM с нуля рискованно: эту работу ведут немногочисленные команды с большими ресурсами, а ниша для входа новичка узкая. Полезнее развивать универсальные навыки решения задач, которые переносятся между проектами и отраслями.
Третий тезис: к LLM стоит подходить осознанно, особенно когда цель — учиться, а не просто закрыть задачу. Ответственность за этичное и безопасное применение данных и моделей внутри организации тоже часть профессии. Ниже разбираем каждый пункт с практическими ориентирами. Важная оговорка: это пересказ тезисов автора статьи, независимых исследований и статистики, которые их подтверждают, в доступных материалах нет.
Что меняется в карьере data scientist в эпоху AI
Профессия не стала ненужной. Изменилось другое: ставка на конкретный инструмент перестала быть надёжной. Инструментов стало больше, обновляются они чаще, а часть рутинной работы с текстом и кодом забирают LLM.
Почему знание конкретного инструмента больше не гарантирует работу
Стек, выученный два года назад, к следующему найму может выглядеть иначе: библиотеки переименовывают функции, фреймворки меняют API, в мейнстрим выходят подходы, которых раньше не было в вакансиях. Пока вы догоняете очередную версию, список типовых задач остаётся почти неизменным.
Вот что встречается в реальных проектах чаще всего:
- пропуски, дубликаты и разные форматы в одной таблице;
- утечка целевой переменной (target leakage), из-за которой модель показывает отличное качество на валидации и проваливается в проде;
- несбалансированные классы, когда редкое событие важнее частого;
- неверная постановка задачи: заказчик просит предсказать метрику, на которую модель повлиять не может;
- сдвиг распределения (data drift) через несколько месяцев после запуска;
- валидация, собранная случайным сплитом для временных данных.
Классический пример утечки: в признаки попадает поле, которое заполняется уже после события, о котором мы предсказываем. Метрика на валидации выглядит отличной, в продакшене модель бесполезна. Умение увидеть такую проблему до выбора алгоритма ценится выше знания конкретной библиотеки.
Почему не стоит становиться узким специалистом по обучению фронтирных LLM
Обучение фронтирных моделей — узкая ниша с высоким порогом входа. Такие модели учат ограниченное число команд, у которых есть вычислительные ресурсы другого масштаба, собственные данные и инженерные наработки. Для студента или специалиста с одной рабочей станцией это не тот путь, где можно быстро набрать профессиональный вес: предобучение фронтирной модели на домашнем железе не воспроизводится.
Автор советует не превращать это в карьерную цель. Разумная альтернатива — работа с задачами вокруг моделей: подготовка данных, оценка качества, retrieval-контуры, дообучение компактных моделей под конкретную задачу, интеграция моделей в существующие процессы. Такие задачи есть в большинстве компаний, они требуют меньших ресурсов и дают опыт, который переносится в любую отрасль. Специалист, умеющий решать прикладную задачу и честно оценивать ограничения модели, нужен чаще, чем претендент на позицию в команде предобучения.
Какие навыки делают data scientist востребованным независимо от модели
Переносимый набор выглядит так: постановка задачи, работа с грязными данными, выбор метода, оценка качества решения и коммуникация результата. Эти умения не зависят от того, какая библиотека в моде, потому что описывают работу с задачей, а не синтаксис.
| Навык | Как проверить у себя | Почему переносится |
|---|---|---|
| Постановка задачи | Можете превратить запрос заказчика в вопрос с измеримым ответом и метрикой | Инструменты меняют способ решения, но не сам вопрос, на который нужен ответ |
| Работа с грязными данными | Можете объяснить, что делать с пропусками, дубликатами и противоречиями в схеме, до обучения модели | Данные приходят из одних и тех же источников: CRM, логи, выгрузки, датчики |
| Выбор метода | Можете назвать, почему взяли этот класс методов и с каким baseline его сравнили | Классы методов живут дольше конкретных реализаций |
| Оценка качества | Можете объяснить, как метрика связана с решением, которое примет заказчик | Метрика отражает задачу, а не фреймворк |
| Коммуникация | Можете описать ограничения модели человеку без технического бэкграунда | Доверие к результату не появляется само |
Работа с грязными данными как базовый навык
Грязные данные — это не аварийная ситуация, а норма. Схема собирается из нескольких систем, поле с датой встречается в трёх форматах, часть категорий записана с опечатками, а часовые пояса никто не унифицировал.
Что реально приходится делать:
- согласовывать схемы и приводить типы к одному виду;
- разбираться с пропусками: где они означают «нет данных», а где «не применимо»;
- убирать дубликаты с осторожностью: две записи об одном человеке могут содержать разные сведения, и слепое удаление стирает полезную часть;
- проверять единицы измерения и часовые пояса;
- фиксировать решения кодом, чтобы шаги воспроизводились на новых выгрузках.
Автор статьи подчёркивает: именно эта часть работы отличает практика от теоретика. Точных долей времени на подготовку данных он не приводит, и подставлять сюда красивые проценты не стоит: в каждом проекте пропорция своя.
Умение распознавать типовые проблемы и выбирать метод
Порядок действий обратный тому, как учат в туториалах: сначала разбираемся, что за задача и какие данные есть, потом выбираем метод. Примеры связок:
- нужно предсказать число: регрессия, baseline по среднему или медиане, затем более сложные модели;
- нужно разделить объекты на классы при редком положительном событии: precision и recall вместо одной accuracy, а порог срабатывания обсуждается отдельно;
- временные данные: валидация по времени, а не случайным сплитом;
- текст: эмбеддинги и поиск по ним, прежде чем браться за дообучение большой модели;
- табличные данные с нелинейными зависимостями: градиентный бустинг как рабочая отправная точка.
Новые методы появляются, логика выбора держится: сначала baseline, потом усложнение с проверкой, что усложнение себя оправдывает. Такой подход переживает и смену фреймворка, и смену поколения моделей.
Почему не только IT-сектор: здравоохранение, госсектор и некоммерческие организации
Автор советует не зацикливаться на IT-компаниях. В здравоохранении, госсекторе и некоммерческих организациях есть задачи, данные и бюджеты на аналитику, а конкуренция за вход для новичка часто ниже. Плата за это — свои ограничения, и о них лучше знать заранее.
Data science в здравоохранении: особенности и ограничения
Медицинские данные чувствительны: персональная информация, история лечения, результаты исследований. Работа с ними требует соблюдать требования к приватности и минимизировать объём данных, который покидает защищённый контур. Конкретные нормы зависят от страны и организации, поэтому их уточняют до старта проекта, а не после.
Второй момент: почти всё делается вместе с врачами и предметными экспертами. Модель, которая хорошо выглядит по метрике, но противоречит клинической логике, в работу не пойдёт. Цена ошибки здесь высокая: неверный вывод может повлиять на решение о человеке. Отсюда другой темп работы: больше проверок, больше согласований, аккуратнее с интерпретацией результатов.
Госсектор и некоммерческие организации: что там искать
Типовые задачи: аналитика и отчётность, работа с реестрами, оценка программ, автоматизация рутинных операций, поддержка социальных проектов. Данные при этом часто лежат в legacy-системах и приходят в форматах, которые в IT-компании сочли бы экзотикой.
Ограничения тоже стоит знать заранее: бюджеты ниже, решения принимаются медленнее, доступ к инструментам ограничен закупочными процедурами, а вынос данных во внешние LLM-сервисы чаще всего запрещён. Зато начинающий специалист получает реальные данные, реальных пользователей и возможность довести проект до результата, а не до ноутбука с графиком. Для первой работы такой опыт часто ценнее строчки в резюме с модной библиотекой.
Как использовать LLM в обучении, а не вместо него
Тезис автора: к LLM стоит подходить осознанно, особенно там, где цель — научиться, а не сдать задачу. Грань проходит не по инструменту, а по тому, остаётся ли у вас собственная работа с задачей.
Когда LLM помогает учиться, а когда мешает
Помогают сценарии, где модель объясняет и задаёт вопросы: разбор ошибки в трейсбеке, объяснение концепции на бытовом примере, генерация краевых случаев для тестов, проверка вашей гипотезы на контрпримерах. Мешают сценарии, где модель выдаёт готовый результат, а вы принимаете его без разбора: сгенерированный код целиком, ответ на задачу без попытки подумать, готовая структура решения, которую остаётся только переписать.
Простая проверка: если после работы с моделью вы не можете объяснить решение своими словами и воспроизвести логику, обучения не произошло. Отдельная сторона вопроса — влияние постоянного общения с ассистентами на мышление и риск зависимости; механика этого разобрана в материале про случай Hank Green и контроль над LLM.
Практические правила работы с LLM для начинающего data scientist
- Сначала своя попытка: сформулируйте план решения до запроса к модели.
- Просите объяснение, а не только ответ: почему этот метод, какие у него допущения, где он ломается.
- Проверяйте код запуском на маленьком примере, а не чтением. Модель уверенно предлагает несуществующие функции и параметры.
- Используйте LLM для генерации тестовых данных, краевых случаев и проверок, а не для подмены инженерной работы.
- Фиксируйте, что именно сгенерировала модель, если код уходит в общий репозиторий. О том, где ускорение оборачивается техническим долгом, подробнее в разборе вайб-кодинга и его последствий для качества кода.
- Помните, что ответственность за результат остаётся на вас, а не на модели.
Отдельный слой работы — контекст, который вы модели даёте: инструкции, файлы с правилами, структура задачи. Чем он чище и модульнее, тем меньше противоречий в ответах. Как это устроено на практике, разобрано в статье про то, как context engineering меняет работу data scientist.
Ответственность data scientist за этичное и безопасное применение данных
Автор статьи называет ответственность за этичное и безопасное использование данных и моделей частью профессии. Технически корректное решение может быть этически неприемлемым: качество метрик не отвечает на вопрос, стоило ли это делать вообще.
Какие решения требуют этической оценки
- сбор и хранение персональных данных: нужен ли каждый столбец и сколько данные живут;
- модели, влияющие на доступ к услугам: кредит, найм, страхование, медицина, образование;
- автоматизация решений о людях: где остаётся человек, который может оспорить результат;
- смещения в данных: если исторические данные отражают прошлую дискриминацию, модель воспроизведёт её в новых решениях;
- прозрачность: может ли человек узнать, почему получил такой результат.
Рабочий тест: если решение нужно объяснить человеку, которого оно касается, и объяснение звучит неубедительно, проблема не в формулировке, а в самом решении.
Как выстраивать безопасную работу с данными внутри команды
- минимизация данных: собирать только то, что нужно для задачи;
- разграничение доступа: сырые персональные данные не должны быть доступны всей команде по умолчанию;
- документирование: какие данные использовались, какие решения приняты, какие ограничения у модели;
- обсуждение рисков с командой и заказчиком до запуска, а не после инцидента;
- мониторинг после запуска: данные меняются, и качество модели вместе с ними;
- точка остановки: заранее договориться, при каких результатах проект не выпускают.
Безопасность — это процесс, а не разовая проверка перед релизом. Каждая новая выгрузка, новая модель и новый сценарий использования добавляют свои риски.
Как строить карьеру в data science, когда инструменты меняются каждый год
Что делать в первые годы карьеры
- брать задачи с реальными данными, даже если они выглядят скучно: выгрузки, отчёты, грязные таблицы;
- доводить решение до конца: от постановки задачи до передачи результата человеку, который им пользуется;
- просить обратную связь по решениям, а не только по коду;
- менять отрасли и типы задач, пока вы набираете опыт: это дешевле, чем менять их через десять лет;
- замечать повторяющиеся задачи и собирать собственные шаблоны решений.
Про устойчивость к отказам и роль окружения есть отдельный разбор пяти уроков после 8,5 лет в ML: терпение, дисциплина, выбор проекта и люди рядом часто решают больше, чем владение конкретным фреймворком.
Как проверять, что вы растёте, а не просто следуете за хайпом
Несколько вопросов для честной самопроверки:
- Можете ли вы объяснить, почему выбрали этот метод, а не соседний?
- Можете ли решить похожую задачу без LLM, хотя бы на уровне плана?
- Знаете ли ограничения своего решения и условия, при которых оно перестанет работать?
- Понимаете ли, как проверить качество, если завтра изменятся данные?
- Останется ли ваш вклад полезным, если завтра заменят библиотеку?
Отрицательные ответы — не повод для паники, а карта того, что стоит подтянуть в следующем проекте.
Практическое действие на ближайшую неделю: возьмите текущую или учебную задачу, сформулируйте её как вопрос с метрикой, вручную проверьте качество данных до обучения, соберите простой baseline, а LLM подключите на этапе разбора ошибок и генерации краевых случаев. Такой цикл повторяется в любой отрасли и с любой моделью, и именно он, а не знание очередного инструмента, удерживает специалиста в профессии.