SHAD AB week

Помните, недавно я писал пост про материалы для ботки из ШАДа, и оказывается от них же еще недавно проходил AB week. Оригинальный пост с материалами я обновил, но чтобы вы были в курсе и сразу получили несвежую информацию из первых рук.

Там рассказали о современных методах анализа, включая бутстрап, линеаризацию и CUPED. Ну и соотвественно лекции про правильный дизайн и проведения А/В‑тестов, их анализ и формулировку бизнес‑решений.

Конкретно по лекциям:

1️⃣Статистика для A/B‑тестов: важные на практике распределения, параметры и оценки, гипотезы и статистические критерии, t‑критерий Стьюдента (YT, VK)

2️⃣Ошибки I и II рода, MDE (минимальный детектируемый эффект). Одновыборочный критерий Колмогорова — Смирнова. Тест Шапиро — Уилка. Синтетические АА‑тесты для проверки валидности статистического критерия (YT, VK)

3️⃣Сравнение распределения двух выборок: двухвыборочный критерий Колмогорова — Смирнова, тест Манна — Уитни. Метрики отношения. Мощность теста и сравнение критериев между собой (синтетические А/B‑тесты) (YT, VK)

4️⃣Доверительные интервалы для метрик отношения, процентных изменений (uplift), персентилей. Методы повышения чувствительности метрик: работа с выбросами, CUPED (YT, VK)

5️⃣Методы повышения чувствительности метрик: стратификация, постстратификация. Проблема множественного тестирования. Проблема подглядывания и групповой последовательный тест (GST). Альтернативный метод работы с данными — Байес. Флоу анализа A/B‑тестов (YT, VK)

Я вот быстренько пробежался по 4 и 5 лекции, кажется годно.

#ab #analytics #courses

Датка + жизнь = блог

В самом начале моего пути в ML не было нормальной собранной информации в виде роадмапов и вообще нормальных подборок по ботке. Из уст в уста мы передавали легенды о том, кто и как проходил разные курсы или собесы, связанные с работой и уже после пытались построить свои планы схожим образом. Я буквально сутками пропадал в чатиках и форумах, жадно поглощая каждый пост, в каждом комментарии искал крупицу дополнительной информации. Коллеги всегда находили чем удивить: прорывными решениями, эпичными фейлами, нестандартными подходами или просто безумными экспериментами. Сейчас мои источники вдохновения тоже остались в мессенджерах и телеграм-каналах. По моим постам и подборкам вы наверняка 💯 понимаете, что я постоянно мониторю огромное количество DS-каналов.

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

Огромная сила кроется в многообразии и фокусе

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

Нет одной волшебной формулы, а есть целая вселенная возможностей и траекторий к своей цели

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

Го использовать эту мощнейшую возможность. Специально для вас мы с командой сколотили убойную папку с DS-авторами: ссылка тут

Если нужны конкретные рекомендации, то по классике ловите:

▫️Наши слоны Никита с базой на LLM собесах и Дима с разваливанием собесов
▫️Даня, который сделал крутой аналитический сайт по картам Чебоксар
▫️Арина и ее путь в датасаенс с нуля
▫️И одновременно сюда же Ваня с его роадмапом с нуля до полноценного джуна
▫️Татьяна, которая идет к 300к в наносек, про ИИ и с чем его есть
▫️Легендарный Юра с применением AI в производстве
▫️В то же время Макс, который пишет о том, как навайбкодить с этим самым эйай
▫️Виталя с его историей про неудачный x3 к зп (та самая важная крупица информации)
▫️Конечно же Захар с его легендарным стартапом
▫️Андрей из Лавки пишет про то, где искать работу студенту
▫️Второй Андрей из финтеха с его тимлидскими заметками
▫️Ну и третий Андрей с его топовым роадмапом по диффузионкам
▫️Все разборы про TDA во временных рядах от Кирилла: 1, 2, 3
▫️Наш Паша, который тоже Техник, но живой про то, как устроена работа в Valve

Папка вот тут

#collaboration

Код с контекстом

Что, если весь код проекта скормить сеточке в промпт?

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

При этом, условный FastAPI занимает более 2M токенов, что естественно выше обычной длины контекстного окна для LLMок, при этом не забываем про размер эффективного контекстного окна. Запихнул туда большой проект целиком, и давай спрашивать сеточку, а что там да как там. Очень похоже на подготовку к экзаменам за пару дней, когда впихиваешь в гудящую голову все эти теоремы и доказательства, а потом на экзамене препод спрашивает базовую базу и ругается на то, что у тебя в голове опять все перемешалось.

На что учил, то и получил. Кстати, именно поэтому например сейчас в условных Курсорах и инструментах для вайбкодинга кодовая база прокидывается в виде RAGа над чанками текста

В структурном проекте обычно есть папки data, models, tests, src. Быстро пробежался по ним, и кажется вроде что-то понял. Для модели без описания структуры это может быть довольно проблематичным понять, что и с чем соотносится - особенно с файлами с одинаковым неймингом. Недостаточно просто кода, надо понимать, что один файл отвечает за конфиг для тренировки, а другой за конфиг для инференса.

К счастью, все сделано за нас. Заходим на Gitingest, вставляем ссылочку на наш гитхаб-репозиторий и получаем файлик с описанием структуры проекта и файлов в одном текстовом файлике. И дальше эту штуку можно закинуть как промпт, предварительно выкинув не нужные для нас файлы. Это конечно не RAG, но потыкаться с небольшими проектами самое то.

По сути мы закидываем не только код, но и автоматизируем подачу контекста. Ну кайф же чисто закинуть в условный google colab или aistudio потыкать код и попросить AI-стажера отрефакторить весь код проекта 😂

P.S. Кстати, у челов уже 12к звезд на гитхабе.

#llm #code

С понедельником, коллеги!

Нужны двое сильных ребят перенести ящики с реактивами в соседнюю лабораторию

Узнали?

Ну а если серьезно, всех с Днем Знаний!

Побольше сил, тем кто в школе, в университете и с усердием прокачивается в своих навыках💪🏿 ну и конечно же еще больше сил родителям😹

Что хочу напомнить вам и прежде всего себе:

▫️Учитесь для достижения конкретных целей
▫️Сразу применяйте знания на практике
▫️И создавайте комфортную для вас среду обучения!

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

Коллеги предложили разыграть одно место на тариф BASE среди вас. Что думаете? Делаем?

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

Погнали💪🏿

Техдолг платежом красен

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

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

Не пишите хреновый код, и не будет вам техдолга

Казалось бы, что мы часто слышим про техдолг в виде того, что надо пофиксить какие-то баги или поменять способ работы определенных модулей. В реале же масштаб зависит далеко не от качества или чистоты кода. Техдолг может возникнуть в любом моменте жизненного цикла ПО, буквально от требований до инфры, где все будет работать. При этом даже есть некоторая классификация, введенная Мартином Фаулером (там это даже раскладывается в квадрант).

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

При этом естественно техдолг не возникает на ровном месте:
▫️Могут быть жесткие дедлайны или сроки, либо сильная динамика требований (тяжело влиять на это - вдруг у вас сильнорастущий бизнес), вплоть до смены стратегии
▫️Классика в неоптимальных процессах: допустим, отсутствие автоматизации тестирования, ну или плохое проектирование (влиять чуть легче)
▫️Может быть и недостаток компетенций (влиять легче всего)

Самое главное, это обнаружить скрытые угрозы и затем контролируемо над ними работать. По сути это и есть управление техдолгом, когда мы находим, оцениваем, планируем и устраняем его. Но при этом еще очень важно и предотвратить накопления нового долга!

Что делать?

Если вы внимательно читали предшествующие абзацы, я думаю вы уверенно ответите, что сначала техдолг надо обнаружить, или сделать видимым. Идем в обратном порядке от последствий к причинам: симптомы → последствия → технический долг → причины. Например, замедление разработки (симптом) может указывать на сложный для понимания код (технический долг), возникший из-за спешки при реализации (причина). Ну и анализируем все артефакты разработки: часто меняющиеся требования, монолитность, проблемы с масштабируемостью, отсутствие тестов, уязвимости, ручное развертывание, долгие и непрозрачные CI/CD-пайплайны.

Далее классифицируем по сложности устранения и срочности, и обязательно проводим экономическую оценку (не только стоимость исправления, но и стоимость отказа от исправления!).

Далее процессная база к устранению техдолга:

1️⃣Техдолг превращается в задачу
2️⃣Задачи приоритизируются
3️⃣Выделяем X% от спринта на техдолг

ну и еще 😎 про предотвращение непреднамеренного долга:

▫️Глубокий анализ требований, с документированием и вовлечением команды в обсуждение (вспоминаем дизайн-док)
▫️Применение архитектурных принципов, документирование решений, архревью (снова вспоминаем дизайн-док)
▫️Единые стандарты разработки, тестирование и статический анализ
▫️Ну и естественно мониторинги

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

Кстати, на Хабре есть очень хорошая статья по этой теме.

#softskills #career

✍️ Михаил Шуфутинский

Вайбы работы в офисе в Москве-Сити примерно такие:

©️Еду в автобусе на работу
©️В это время нас обгоняет Lamborghini, что аж стекла дребезжат
©️Я такой: Ух бля как круто

P.S. На автобусе передвигаться люблю

#life

Интересное что-то от ребят, кого я читаю v0.31

Предыдущий пост тут
Интересное что-то тут

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

Давайте в этот раз снова заполним эту рубрику постами по вашим рекомендациям. Так что первые 5-6 постов, которые вы скинете, я закину сюда в подборочку. Ну и если есть что-то реально крутое, просто закинем в комментарии, чтобы коллегам было полезно и интересно почитать.

Погнали 💪

1. Анна поделилась любимым постом в любимом канале, где рассказывается про необычный термин, который, внимание!, хер прочитаешь, не сломав язык.

2. Другая Анна рассказала о том, что важно узнать на финальном собеседовании, чтобы не пожалеть о принятом офере. Сюда же рекомендую еще ознакомиться с комментариями, потому что там есть еще дополнительные крупицы информации

3. Третья Анна нашла необходимое и достаточное коичество бесплатных SQL-тренажеров, кстати среди которых есть и довольно популярные типа sql-ex. Когда я тоже собирал похожую подборку, возможно вам будет полезно

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

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

6. Паша вкинул сразу пару постов: первый пост про GRM от дип сик (где дипсики продолжают идею думания мат.задачами и рассказывают как можно обучить general reward model), ну и второй пост про разбор GSPO от квена и сравнение с GRPO от дипсика

7. Ну и конечно же коллеги с DevFM и пост про работу с ai-агентами. Это как процесссы с разными заходами, приемами и приседаниями с MCP-серверами и Rules. По классике не забываем про тесты и просто не сдаемся!

#interesting