#code

Создал небольшой репозиторий с решениями SQL задачек с sqlpad. Может кому-то пригодятся, если вдруг решите потренировать SQL задачки (а они там достаточно неплохие) и застрянете на какой-то из них

​​Готовлю обзорный доклад по мета-анализу.

Интересная мысль из сферы медицины - использовать некое соотношение между типами доказательств. Например, личному мнению специалиста мы верим куда меньше, чем A/B тесту (что логично).

И вот, казалось бы, идея классная. Но в суровую реальность живого применения она идет с трудом. Потому что совсем не ясно, насколько важнее один тип доказательств, чем другой? А рост траты ресурсов на доказательства выше по позиции в этой пирамиде достаточно нелинейный. Что влечет за собой еще больше проблем.

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

И я верю, что скоро в больших (а потом и в меньших) компаниях придут к такого рода "табелям о рангах". Пускай и в упрощенном эмпирическом виде.

P.S. Из идей реализации таких историй можно попробовать проделать все операции снизу-вверх (для нескольких разных исследуемых ситуаций), а потом посмотреть, сколь часто наши доказательства будут рассогласованы и сколько времени будем занимать каждый этап. А оттуда уже получать среднее по больнице (эмпирические правила, когда и сколько доказательств получать - некий скоринг уверенности в выводах).

Лютейшая годнота по теме Causal Inference.
Называется "Causal Inference for The Brave and True".

Очень много полезной информации + тонна мемов, разбавляющих заумное повествование (спойлер: там все еще много математики, так что будьте аккуратны, чтобы случайно не сломать мозг).

В общем, 10 регрессий из 10.

#AB

Почему при оценке бутстрепом нельзя взять на каждой итерации больше элементов, чем у нас в выборке?

Вопрос хороший.
Казалось бы, идея простая: больше объектов - уже доверительные интервалы, точнее оценки.

Ан нет, тут тоже у нас no free lunch.
Если кратко - то это сужение доверительного интервала есть лишь искажение, искусственно заниженный результат (мы изменяем распределение, так что полагаться на такие оценки нельзя). Подробные объяснения можно посмотреть по ссылкам (раз, два)

Дополнительно к этому сделал крайне простую симуляцию. Генерация выборок размера 2N на каждом шаге увеличивает ошибку первого рода (причем достаточно сильно, на 5-10%).

​​♟ Нейронка, которая комментирует ваши ходы в шахматах

ChessCoach играет лучше людей (3450 Elo), но может проиграть более сильной нейронке. Тренировалась играя сама против себя. По ссылке есть детальное описание от автора, будет полезно многим, кто хочет вкатиться в разработку нейронок.

Поиграть против нейронки и почитать её комментарии можно вот тут.

#libraries

PythonMeta - библиотека для мета-анализа в Pyhton. Внутри все основные инструменты для проведения мета-анализа (строит funnel, forest plot, позволяет оценить гетерогенность, производит оценку общего эффекта).

К сожалению, все на китайском, но есть небольшой материал по использованию библиотеки (в нем есть ссылки на еще пару библиотек для проведения мета-анализа).

Вы, наверное, слышали фразу "wild import - зло". В коде это выглядит так:

from my_module import *

Ответ почему это "зло" очень простой - вы импортируете всё - то что надо и то что не надо.

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

Он есть - это переменная __all__ .__all__ в Python - это список публичных объектов данного модуля.

Например, есть некий my_module.py, в нём очень много объектов, и не требуется давать пользоваться ими всеми. В my_module.py вы списком определяете названия объектов, которые можно импортировать:

__all__ = ["MyClass", "MyClass2"]

И тогда конструкция

from my_module import *

Импортирует только те объекты, которые вы описали в __all__.

#books

"Мультипотенциалы. Руководство для тех, кто уже вырос, но так и не решил, кем хочет стать"

В книге рассказывается про особый тип людей, которым многое интересно, у них широкая (но не всегда глубокая) сфера интересов. В книге их называют мультипотенциалы, я слышал еще вариант - сканеры.

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

Краткие форматы карьеры из книги:
1. Групповое объятие. Такой вариант, при котором в одной должности совмещаются несколько разных направлений. Работа DS вполне может подходить под такое описание, т.к. в рамках одной должности частенько приходится заниматься весьма разными задачами;
2. Подход Эйнштейна. Здесь совмещается не очень напрягающая работа, которая приносит основной доход и множество увлечений "для души". Мне такой подход показался наиболее классическим.
3. Слэш-карьера. Здесь человек совмещает несколько part-time карьер. Например, преподает и является маркетологом на фрилансе.
4. Феникс-карьера. В данном варианте каждые n лет одна карьера завершается, после чего происходит переход к новой интересной теме.

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

#management

Правило 5 почему?

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

Пример: в master постоянно попадает код с ошибками.

1 Почему: потому что в master мерджат без ревью кода
2 Почему: потому что ревью ждать долго, а спринт горит
3 Почему: потому что помимо своих задач из спринта коллегам нужно выделять время на ревью
4 Почему: потому что в спринте нет отдельных задач на ревью кода
5 Почему: потому что не умеем оценивать задачи по ревью кода

Итого:
1. Нужно откалибровать наши оценки таким образом, чтобы появилось понимание, сколько займет ревью той или иной задачи;
2. Нужно помимо основной задачи вносить в спринт задачу по ревью кода основной задачи. И впоследствии учитывать, что наша capacity меньше, чем мы думали ранее (за счет дополнительных трат на ревью).

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

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

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

🖥 Код

#training #inference #theory

#AB

Не бывает бесплатных А/Б тестов.

Да, именно так. Практически каждый А/Б тест чего-то, да стоит.

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

Нам нужно потратить силы на новую фичу или ее прототип, сделать инфраструктуру для проведения теста, провести дизайн эксперимента, а потом еще и проанализировать результаты. Все это выливается в человеко-часы.

Поэтому, стоит хотя бы примерно оценивать, стоит ли какой-либо эксперимент денег, потраченных на его проведение.
Например, ваше изменение предположительно будет приносить дополнительный 1 рубль с пользователя. У вас 10000 пользователей. Проведение эксперимента со всеми изменениями, подготовкой и анализом будет стоить 100000 рублей. Кажется, что инвестиция крайне невыгодная, верно?

Понятное дело, что реальный эффект не всегда совпадает с расчетным. Да и результаты иногда получаются весьма контринтуитивными. Но все же можно хотя бы примерно оценить "окупаемость" нашего А/Б теста, чтобы не стрелять из пушки по воробьям. А на сэкономленные ресурсы лучше провести более полезный тест (ну или работяг в бар сводить - авось продуктивность подрастет ;)).

#AB

Что такое негативный АБ тест?

Негативный (или ухудшающий) АБ тест предполагает под собой обратное классическому АБ тест действие - ухудшение сервиса для пользователя.

Например: что будет, если наш сайт будет отвечать на 100мс дольше? Или другой пример - что будет, если мы выключим персональные рекомендации для части наших пользователей?

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

Основные проблемы, которые могут быть при проведении такого эксперимента:
1. Сопротивление менеджмента, продакта и прочих коллег, которые не очень понимают, что бесплатно узнать нам такую информацию вряд ли удастся (только если не возникнет "естественного АБ теста", где у части пользователей что-то сломается само, а мы это проанализируем);
2. Сопротивление пользователей. К примеру, если мы отключим части пользователей рекомендации, которые стали удобным для них инструментом, то поддержке стоит ждать множества обращений, а-ля "Дуров - верни стену". С этим что-то придется делать (вплоть до остановки эксперимента, если все совсем плохо).

В итоге получаем достаточно полезный, но неоднозначный инструмент.

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

Попробовал этот ваш ruDALL-E

#video

Интересное видео про использование бутстрапа для вычисления p-values. Рекомендую к просмотру, всего 8 минут, так что заскучать не успеете. Правда, подача несколько специфическая, но тут ничего не поделаешь.

#мысли

Проводить собеседования очень непросто.

Личная эвристика - если в день больше двух собеседований, или в неделю больше трех-четырех, то это лично меня вгоняет в дикую усталость. Потому что остальную работу никто не отменял, ясное дело. Приходится потом несколько дней, а то и неделю отходить на неполной мощности работы.

Как с этим бороться?
1. Выделять кого-то только на собеседования (дежурный по собеседованиям);
2. Ходить по несколько человек. Тогда один может вести одну часть, пока другой слушает вполуха. Потом вы меняетесь. Нагрузка ложится на вас более равномерно;
3. Давать какие-то предварительные задачки на отсев. Я такой подход не люблю, но выкинуть из списка рука не поднялась;
4. Устраивать "сезон собеседований". Похоже на 1й метод, но тут вы уже выходите группой. Концентрированно проводите много собеседований. Подводите итог и успокаиваетесь до нового "сезона". Правда, в таком случае у нас должна быть общая шакала оценки, чтобы разные группы оценивали примерно похоже, а кандидаты были хоть как-то сравнимы между собой.

#management

Услышал интересный метод учета времени на коммуникацию и какие-то собственные задачи, связанные с управлением.

Суть в том, чтобы повторить типичный процесс оценки "а-ля Agile". Берем задачи, выбираем самую маленькую и назначаем 1 или XS (ну или что еще вы используете для оценки задач). Оцениваем свои задачки в бэклоге, считаем capacity. Вуаля - вы великолепны, т.к. знаете, сколько персональных задач вмещает ваше расписание. Ну и можете планировать ваш личный бэклог с учетом его вместимости.

Реально очень удобно представлять, насколько "вместим" ваш день. Иначе есть шанс переутомиться и выгореть дотла.