Всем привет! Попалась интересная статья про рекомендашки, может быть очень даже интересно:

https://habr.com/ru/companies/yandex/articles/862148/?m-message-key-id=4311070750757191680&m-message-click-id=6783c058-61b7-40de-9d4e-a59f4c5d5d08

(саму статью еще не читал, но в ней есть ссылки на трендовые вещи в индустрии).

#rag #petproject

#ml #courses #novice

Я сейчас в Болте работаю, поэтому не могу вопросы пошарить =)

Но про заландо расскажу (я там до болта работал и сам тоже интервью проводил):
- мы пытались спрашивать то, что нужно было под позицию, если надо было человека под обучение сеток взять на последовательностях кликов, то про tfidf, word2vec, LSTM, трансформеры, как их обучать, приёмы по обучению (от простых бейзлайнов до соты)
- когда надо было заниматься бустингом во фроде, то там классика про метрики бинарной классификации, как выбирать порог отсечения в проде, про финансовый оценки FP, FN, как решать проблемы с sensored data (когда мы не знаем перформанс модели на забаненых юзерах, так как им не дали кредит и не наблюдаем их ground truth), по бустингу спрашивали про апроксимацию и препроцессинг для данных

#ml #dl #papers

Apache Airflow® Best Practices: ETL & ELT Pipelines

44 страницы исчерпывающего руководства по одному из самых распространенных сценариев использования в data engineering на ведущем open-source оркестраторе!

Что вы узнаете из руководства:

📊 Сравнение ETL vs. ELT для вашей архитектурной стратегии - какой подход выбрать и почему.

💡 Лучшие практики написания DAG в Airflow - как создавать эффективные и поддерживаемые пайплайны.

⚡️ Ключевые функции для улучшения ваших ETL & ELT пайплайнов - поднимите свои процессы обработки данных на новый уровень.

Станьте экспертом в оркестрации данных с этим подробным руководством!

Скачать можно по ссылке

@data_whisperer

#llm #metrics

📊 Как оценивать LLM: бенчмарки [Ч.2]

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

❗️Бенчмарк - это набор тестовых вопросов для оценки конкретного навыка модели.

Как правило, он работает следующим образом:
1. Берут некоторый стандартный набор запросов к LLM
2. Собирают ответы модели
3. С помощью асессоров/либо автоматической метрикой получают некоторую оценку качества модели

🗑Виды бенчмарков:

1️⃣ Открытые: создаются, как эталоны, для оценки конкретного навыка модели, что позволяет сравнить производительность любой LLM. Зачастую под данными бенчмарками понимаются: MMLU, GSM8K, HumanEval и т.д.
Проблема таких бенчмарков в том, что вся тестовая выборка хранится в открытом доступе (где-нибудь на GitHub), что зачастую приводит к утечке данных в train-датасеты.
ℹ️GSM8K - содержит математические задачи уровня начальной школы; MMLU - создан для проверки уровня фактических знаний LLM по гуманитарным наукам, социальным наукам, истории и даже право; HumanEval - содержит задачи по программированию

2️⃣ Закрытые: имеют аналогичную цель, однако, их особенность в закрытом тестовом наборе данных, которые LLM в процессе обучения не видели. Сюда могут входить: MT-Bench, SQuAD, RE-Bench и т.д.

3️⃣ Собственные (доменные): не всегда доступные бенчмарки пригодны для вашей задачи, поэтому зачастую приходится формировать свои тестовые примеры и способы оценки.

📚Дополнительная литература:
- Простая и очень полезная статья по бенчмаркам от команды Яндекса. Здесь же можно почитать про недостатки различных бенчмарков и этого подхода в целом
- Материалы из прошлой статьи
- Большой набор описаний наиболее популярных бенчмарков
- Статья про самые популярные LLM-бенчмарки
- Статья "Полный гид по бенчмаркам LLM"

Обязательно ставьте ❤️ и 🔥 под постом!
Пишите свои комментарии 🙂

Справляемся с рисками

Две совсем несложные статьи (раз, два), посвящённые риску и управлению рисками.

В первой даётся определение риска – это сочетание возможности получить выгоду и вероятности потерь. Мы принимаем риск не ради него самого, а ради целей, которые хотим достичь.

Для анализа риска автор разделяет его на два компонента:
– Вероятность: насколько возможно, что негативное событие произойдёт?
– Последствия: какие убытки или проблемы оно принесёт?

Для оценки риска предлагается использовать матрицы риска, которые делят вероятность и последствия на категории: низкие, средние, высокие. Таким образом можно наглядно увидеть, какие стечения обстоятельств действительно рисковые.

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

Вторая статья посвящена управлению рисками – действиям, направленным на снижение риска.

По сути мы возвращаемся к составляющим риска:
– Снижение вероятности. Мы пытаемся сделать так, чтобы рискованное событие с меньшей вероятностью происходило.
– Снижение последствий. Мы уменьшаем ущерб, если событие всё же произойдёт.

Автор приводит не айтишный пример, но, в целом, неплохо демонстрирующий суть.
Нужно переправиться через реку:

Для снижения вероятности падения в воду мы можем:
– Использовать командные техники переправы
– Искать более мелкий участок реки для перехода

Для снижения последствий попадания в воду мы можем:
– Запаковать вещи в водонепроницаемые мешки, чтобы предотвратить их повреждение
– Разместить спасателей ниже по течению, чтобы минимизировать риск травм или утопления

#teamwork

Пятый месяц. Развитие ключевых людей

Прошел пятый месяц курса Стратоплана «Руководитель отдела». Перевалил за серединку уже 🙂

Контент первого, второго, третьего и четвертого месяцев я описывал ранее.

В отличие от прошлого месяца в этот раз удалось присоединиться к групповым практикам, и я в очередной раз убедился, что это ОГРОМНАЯ разница, конечно.

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

Старенькое
- Ситуационное руководство. Как с кем работать при разных уровнях мотивации и компетентности. Это классика, и это надо уметь, если хочешь взращивать самостоятельные и профессиональные команды.
- Как с человеком поговорить о его желании и потенциальных направлениях к дальнейшему развитию. Тут, как всегда, я сторонник того, что не надо на каждого наседать, что развиваться – это ОБЯЗАТЕЛЬНО. Тем не менее это важная часть нашей работы. Где-то сами люди хотят профессионально и карьерно расти, но не знают как, и им надо помочь. А где-то некоторым людям надо расти, чтобы продолжать быть на хорошем уровне в команде, перед которой встают новые вызовы, и надо правильно это донести.
- HiPo и HiPro анализ своей команды (именно такое упражнение я как-то и делал на работе). С одной стороны, мне кажется, у опытного руководителя, погруженного в команду, это должно уже быть где-то в подсознании всегда сгенерено, а с другой стороны, для менее опытных ребят это хороший подход к рефлексии на тему своих соколиков.
- SWOT-анализ и модель GROW. Коротко говоря, это фреймворки на подумать о себе, о своих целях и о том, как и за счет чего ты их будешь достигать.

Новенькое
Тут растекусь мыслью только про одну тему. Но это мне прям ярко впечаталось, и хочется с вами поделиться.
У нас была тема про менторинг vs коучинг. Где менторинг — это про то, что очень опытный и компетентный в конкретном вопросе человек учит другого (ну, например, кузнец учит подмастерье ковать какие-нибудь загогулины), а коучинг — грубо говоря, не обязательно столько компетентный в этом деле человек задает тебе вопросы, и ты сам во всём разбираешься.

Вот мне всегда менторинг был ближе и понятнее. Как будто это профессионально, а коучинг — странное инфоцыганство из серии: «Так, ты пришел ко мне с проблемой. А сам что думаешь? А как будешь решать? Разобрался? С вас пятьтыщ».
Послушал я теоретическую часть и немного скептически двинулся к групповой практике, где мы реальные рабочие вопросы разбирали, чередуя то менторинговый подход, то коучинговый.

И оказалось, что коучинговый подход в некоторых вопросах отработал внезапно очень круто. Человек, ранее зафреймировавший себя на определенные мысли и поведение, столкнулся с проясняющими вопросами и, пока на них отвечал, сам всё понял и пришел к решению, которое ему подходит и нравится.

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

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

Хотите описать сильные и слабые стороны продукта, берите SWOT (слайд 2).

Есть потребность оценки рисков и проектных зависимостей, рассмотрите RAID Log (слайд 20).

Хотите зафиксировать список стейкхолдеров проекта и понять кому и по каким вопросам обращаться, с кем согласовывать, а кому просто прийти с готовым результатом - посмотрите на Stakeholder Analysis (слайд 17)

Только запускаете проект и думаете какую информацию для старта важно собрать - воспользуйтесь Project Charter (слайд 26)

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

#interview

Собесы на SE 2 в мелкомягких