Наверняка у каждого на работе бывают моменты, когда нужно просто сесть и подождать чего-либо ☕️. Это может быть долгий запуск программы, долгий расчёт чего-либо, или просто неоптимальная работа не на вашей стороне, а на стороне коллеги, который сделал какой-то кривой процесс, который долго работает⌛️ .

Вот и у меня был один такой кейс, который удалось успешно решить. Он был связан с расчётом популярной метрики в машинном обучении в задаче классификации: ROC AUC. Ниже гайд, как можно оптимизировать и ваши расчеты тоже.

Прочитал очень интересные мысли автора из этой публикации. Очень верно подмечено, я и сам замечаю то же самое. Поэтому далее мои мысли по состоянию IT-рынка в целом и про ML в частности.

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

От себя хочу добавить следующее:
За тот же ценник от вас будут ждать не только роста качества ваших навыков, но и роста их количества.

Почему? Вот три примера.

Пример 1️⃣: сложное становится простым.

Ещё два-три года назад уметь обучать модели машинного обучения, ставить их в продакшен, подключать к ним разные источники данных и записывать предсказания — это было чем-то вроде магии. Я помню времена, когда наличие знаний о DS / ML / MLOps / DE / DA у одного человека вызывало восхищение у коллег. Но сейчас? Это просто базовые навыки. Даже я лично спрашиваю их на собеседованиях на junior-позиции.

В чём причина? Знания стали доступнее. Материалов о том, как всё это сделать, сейчас море. Но не только знания — современные инструменты делают процесс проще и эффективнее. И поэтому компании уже не хотят платить за одного специалиста, который умеет делать что-то одно. Они хотят, чтобы вы были «универсалом»: обучили модель, наладили поставку данных, поставили её в продакшен, настроили мониторинг, запланировали и запустили АБ-тест, и всё это объяснили бизнесу.

Пример 2️⃣: удивлять всё сложнее.

Помните времена, когда Data Scientist просто занимался обучением моделей? А теперь? Нам приходится не только создавать модели, но и разрабатывать корпоративные приложения с бэкендом, добавлять фронтенд — словом, быть полноценным разработчиком. Всё это, чтобы оставаться в парадигме outperforming в рамках корпоративного роста и развития. И знаете что? Год назад мы в команде вызывали у коллег удивление: «Ого, вы этим занимаетесь?» А сейчас я вижу, что такое восхищение пропало. Почему?

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

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

Пример 3️⃣: а что остается делать менеджеру?

Смогли представить себе команду специалистов из пункта 1 и 2? А теперь представьте, что вся вышеописанная команда уходит одним днем в другую компанию. Сколько ценных навыков будет потеряно? Что будет делать менеджер? Если раньше в его команде было 3 человека и 12 уникальных скилов (backend, frontend, DS, MLOps, LLMOPs и так далее), то теперь ни одного.

➖Вариант первый: менеджер просто набирает новых специалистов — по одному на каждый навык. Но это дорого, никто не будет так раздувать штат специалистов.
➖Вариант второй: гораздо дешевле, но дольше, найти одного человека, который охватывает сразу несколько навыков. Лучше найти одного универсала, чем целую команду узких специалистов. Это не только проще, но и дешевле.

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

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

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

Сегодня будет первая публикация из цикла, а найти все можно будет по этим тегам:

➡️ #llm_для_работы - кейсы из моей рабочей практики, как LLM были полезны в команде ML-разработчиков и на продуктах финтеха
➡️ #llm_для_жизни - кейсы из жизни, когда использование помогало решать личные вопросы

Следующий кейс будет полезен всем, кто связан с разработкой. Речь пойдет о написании юнит-тестов на Python ⚙️.

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

Я решил доверить эту задачу нейросети — Claude 3.5 Sonnet. После нескольких итераций и уточнений получил рабочую регулярку, которая делала именно то, что нужно. Но на этом история не закончилась.

# что я хотел найти:
# из строки: "последовательность запуска алгоритмов: [(1, 2) >> 3]"
# выделить: [(1, 2) >> 3]

# Регулярка по мнению Claude 3.5 sonnet
pattern = r'\[(?:\s*\((?:\d+(?:\s*,\s*\(\s*\d+(?:\s*,\s*\d+)*\s*\))*(?:\s*,\s*\d+)*)\)|\s*\d+)(?:\s*>>\s*(?:\((?:\d+(?:\s*,\s*\(\s*\d+(?:\s*,\s*\d+)*\s*\))*(?:\s*,\s*\d+)*)\)|\d+))*\s*\]'

Даже если регулярка работает на первых тестовых данных, это не гарантирует, что она справится со всеми возможными сценариями. Здесь на помощь приходят юнит-тесты. Они помогают проверить, что ваш код (или регулярка) работает корректно в разных ситуациях, включая краевые случаи (edge cases).

Однако придумывать такие тесты вручную — это долго и не всегда эффективно. Можно что-то упустить, особенно если проект большой и сложный. И тут я подумал: а почему бы не поручить это нейросети?

Я начал с того, что написал три базовых теста (используя few-shot технику), чтобы задать контекст. Затем попросил Claude сгенерировать дополнительные тесты. Результат меня впечатлил: нейросеть не только предложила еще десяток тестов, но и добавила краевые случаи, которые я сам мог бы и не учесть.

# мои few-shot примеры 
test_cases_user = [
    ["алгоритмов: [1 >> 2 >> 3]  этом", "1 >> 2 >> 3"],
    ["алгоритмов: [(1, 2) >> 3]  этом", "(1, 2) >> 3"],
    ["алгоритмов: [(1, 2) >> (3, 4)]  этом", "(1, 2) >> (3, 4)"],
    ["алгоритмов: [(1, 2, 3) >> (5, 6) >> 7]  этом", "(1, 2, 3) >> (5, 6) >> 7"],
]
# ответ Claude 3.5 sonnet
test_cases_gpt = [
    ["[(1) >> (2)]", "(1) >> (2)"],
    ["[(1, 2)]", "(1, 2)"],
    ["[1 >> 2]", "1 >> 2"],
    ["[(1,2,3)>>4>> (5,6)]", "(1,2,3)>>4>> (5,6)"],
    ["[1 >> (2, 3) >> (4, 5, 6)]", "1 >> (2, 3) >> (4, 5, 6)"],
    ["алгоритмов: [(100, 200, 300) >> 400 >> (500, 600)]  этом", "(100, 200, 300) >> 400 >> (500, 600)"],
    ["алгоритмов: [1000 >> (2000, 3000) >> 4000 >> (5000, 6000, 7000)]  этом", "1000 >> (2000, 3000) >> 4000 >> (5000, 6000, 7000)"],
    ["алгоритмов: [(1) >> (2) >> (3) >> (4)]  этом", "(1) >> (2) >> (3) >> (4)"],
    ["алгоритмов: [1 >> 2]  этом", "1 >> 2"],
    ["алгоритмов: [(1, 2)]  этом", "(1, 2)"],
    ["алгоритмов: [1]  этом", "1"],
    ["алгоритмов: [(1,2,3,4,5,6,7,8,9,10) >> 11]  этом", "(1,2,3,4,5,6,7,8,9,10) >> 11"],
    ["алгоритмов: [(1, 2) >> (3, (3, 3))] этом", "(1, 2) >> (3, (3, 3))"],
]

Вот несколько ключевых выводов, которые я для себя сделал:

1. Экономия времени: нейросети позволяют быстро генерировать большое количество тестов, что особенно полезно при работе с большими проектами.
2. Улучшение качества тестов: нейросети предлагают краевые случаи, которые разработчик может упустить.
3. Дополнительная проверка: даже если тесты от нейросети не всегда идеальны, они служат хорошей отправной точкой для дальнейшей доработки.

✏️ Этот опыт очень интересен, особенно на фоне новостей о появлении различных коробочных решений, которые работают схожим образом, но с большей автономностью. (тык 1, тык 2)

Визуализация данных — это навык, на который часто забивают, а зря.

В своей серии публикаций я показываю, почему его стоит прокачивать и как это сделать.

📊 И да, сегодня — первая в этом году #пятничная_визуализация

p.s. Код на питоне есть по ссылке из поста