{"version": "https://jsonfeed.org/version/1.1", "title": "ML Baldini • Nikita Boyandin", "home_page_url": "https://t.me/ml_baldini", "feed_url": "https://tg.davvie.com/static/-1001939110700.json", "description": "ML Baldini • Nikita Boyandin", "items": [{"id": "https://t.me/c/1939110700/416", "url": "https://t.me/c/1939110700/416", "title": "📉 Что мы упускаем в пропущенных значениях? Когда в датасете появляется NaN, первая реакция обычно д", "content_html": "📉 Что мы упускаем в пропущенных значениях?
Когда в датасете появляется NaN, первая реакция обычно довольно механическая: удалить строку, заполнить средним, медианой или отдать пропуски модели, которая умеет работать с ними сама.
Но missing value - это не просто отсутствие данных. Сам факт того, что значение не было получено, тоже является результатом некоторого процесса, и этот процесс может быть связан с тем, что мы пытаемся предсказать.
Представим датчик загрязнения воздуха. Если он случайно теряет 1% измерений из-за проблем с сетью, пропуски вряд ли сильно искажают картину. Но если датчик чаще выходит из строя именно при экстремально высокой концентрации частиц, то отсутствие измерения уже говорит что-то о самой концентрации. Если просто заполнить такие NaN средним значением, мы систематически занизим самые экстремальные наблюдения.
Именно поэтому в статистике обычно различают три механизма missingness.
MCAR - Missing Completely At Random
P(R | Y_obs, Y_mis) = P(R)
Вероятность пропуска не зависит ни от наблюдаемых, ни от пропущенных значений. В этом случае удаление строк уменьшает объём выборки и повышает variance оценок, но само по себе не создаёт систематического bias.
MAR - Missing At Random
P(R | Y_obs, Y_mis) = P(R | Y_obs)
Вероятность пропуска зависит от информации, которую мы уже наблюдаем. Например, доход могут реже указывать пользователи определённой возрастной группы. Если возраст известен, механизм пропусков можно моделировать через наблюдаемые признаки.
MNAR - Missing Not At Random
Здесь вероятность пропуска зависит от самого неизвестного значения. Например, люди с очень высоким доходом могут чаще отказываться его указывать, или пользователи, которым не понравился экспериментальный интерфейс, могут уйти раньше, чем мы успеем измерить целевую метрику.
И это наиболее неприятный случай: распределение пропущенных значений нельзя восстановить только из наблюдаемой части данных без дополнительных предположений о механизме missingness.
Поэтому imputation никогда не является полностью нейтральным preprocessing step. Когда мы заменяем NaN средним, строим multiple imputation или используем inverse probability weighting, мы фактически делаем предположение о том, почему данные отсутствуют.
Но правильная стратегия зависит ещё и от того, решаем мы задачу inference или prediction.
В inference нас интересует реальная зависимость между переменными, поэтому informative missingness становится потенциальным источником bias, который нужно корректировать.
В prediction ситуация может быть обратной. Сам факт пропуска иногда является полезным feature. Если потенциальный клиент не заполнил бюджет или размер компании, это может быть связано с вероятностью покупки. Поэтому можно добавить is_missing как отдельный бинарный признак или использовать модели вроде gradient boosting, которые умеют обучать направление перехода для missing values непосредственно внутри дерева.
Но здесь возникает другое ограничение: механизм пропусков на train должен быть похож на production. Если признак отсутствовал при обучении по одной причине, а после релиза начал отсутствовать по другой, модель может использовать уже несуществующую закономерность.
Поэтому главный вопрос при работе с NaN звучит не:
«Чем заполнить пропуск?»
а:
«Почему это значение вообще отсутствует?»
Потому что иногда пропуск - это потерянная информация, иногда источник bias, а иногда полноценный признак.", "date_published": "2026-09-16T15:00:50+00:00"}, {"id": "https://t.me/c/1939110700/415", "url": "https://t.me/c/1939110700/415", "title": "🌲 Почему Random Forest вынужден быть Random? Random Forest часто объясняют как набор decision trees", "content_html": "🌲 Почему Random Forest вынужден быть Random?
Random Forest часто объясняют как набор decision trees, обученных на разных bootstrap-выборках, предсказания которых затем усредняются. Но если бы случайность ограничивалась только bootstrap sampling, мы получили бы обычный bagging деревьев. Ключевое отличие Random Forest состоит в дополнительной рандомизации: при построении каждого split алгоритм рассматривает не все признаки, а только случайное их подмножество.
Именно эта деталь во многом объясняет, почему Random Forest работает лучше простого bagging.
Decision Tree - модель с относительно низким bias, но высокой variance: небольшое изменение обучающей выборки может заметно поменять верхние split'ы, а вслед за ними и всю структуру дерева. Bagging использует эту нестабильность в свою пользу, обучая много деревьев на bootstrap-выборках и усредняя их предсказания.
Проблема в том, что деревья в таком ансамбле не независимы.
Если обозначить variance отдельного дерева через σ², а среднюю корреляцию между деревьями через ρ, variance ансамбля из N деревьев можно приближённо записать как:
Var(ensemble) = σ² [ρ + (1 - ρ) / N]{}
При увеличении N вторая часть стремится к нулю, но коррелированная компонента остаётся:
N -> ∞ => Var(ensemble) -> ρσ²{}
То есть просто добавлять деревья бесконечно бесполезно: если они ошибаются похожим образом, у ансамбля остаётся ненулевой предел variance.
Откуда вообще берётся эта корреляция?
Представим, что в датасете есть несколько очень сильных признаков. При стандартном построении дерева каждый split выбирается как лучший среди всех доступных features, например по максимальному уменьшению impurity. Поэтому самые информативные признаки будут снова и снова появляться около корня разных деревьев.
Bootstrap меняет выборку, но часто недостаточно сильно, чтобы изменить порядок лучших признаков. В результате деревья строят похожие partition пространства объектов и начинают совершать коррелированные ошибки.
Random Forest сознательно мешает каждому отдельному дереву быть оптимальным.
На каждом узле вместо всех p признаков алгоритм случайно выбирает только m, где m < p, и ищет лучший split внутри этого подмножества.
Лучший глобальный признак иногда просто недоступен, поэтому дерево вынуждено использовать второй, третий или альтернативный feature. Для конкретного дерева это может ухудшить качество split'а, зато ансамбль получает более важное свойство - decorrelation.
Деревья начинают использовать разные признаки, строить разные структуры и совершать менее похожие ошибки. Random Forest тем самым влияет не только на variance отдельных моделей, но и на covariance между ними.
Отсюда возникает основной trade-off max_features.
При большом max_features отдельные деревья сильнее, но становятся более похожими и корреляция ρ растёт. При маленьком max_features деревья сильнее различаются, но каждый learner чаще вынужден выбирать менее качественные split'ы.
Задача Random Forest - пожертвовать небольшой частью качества отдельного дерева ради достаточно сильного снижения корреляции всего ансамбля.
В этом и заключается одна из главных идей ансамблевых методов: важны не только сильные модели, но и модели, которые ошибаются по-разному.
Именно поэтому Random Forest должен быть действительно Random.", "date_published": "2026-09-09T15:00:29+00:00"}, {"id": "https://t.me/c/1939110700/414", "url": "https://t.me/c/1939110700/414", "title": "Экономика времени Давно тут не выходило постов и этому есть простое обьяснение - я ленивый, хоть и ", "content_html": "Экономика времени
Давно тут не выходило постов и этому есть простое обьяснение - я ленивый, хоть и правду старался найти силы. Кажется, просто сложно доставать времени на хобби, даже если тебе это хобби нравится.
Математика простая: у тебя есть в неделю 7 * 24 = 168 часов времени жизни. Из этого мы вычитаем время на сон(тут я считаю идеальный мир, где мы честно спим 8 часов здорового ) 8 * 7 = 56 часов (остается 112 часов), также время на еду, все дела и остается наши 100 часов.
Поехали дальше: 50 часов занимает работа(помимо 40 часов реальной работы, еще 10 часов дорога, доделки и тд), 25 часов занимает магистратура(тут тоже примерно).
И кажется все - халявные 25 часов на саморазвитие, хоть на вторую работу иди...
Но по хорошему: 7 часов на тренировки в неделю, отдых тоже хотелось бы по 10 часов в неделю включить(тут я имею ввиду правильный отдых с семьей, книжку почитать, да в игрушки позалипать)
Твои 8 часов на хобби, но как частов получается так, чтобы ты все сделал четко по таймеру, не переработал, или решил поспать, потому что идет дождь)
Очень просто во всем этом плюнуть на все и смириться, но потом страшно смотреть, что кроме работы и учебы что то своего не осталось. Так что отвечая на вопрос, а зачем канал - потому что ты не только работа или учеба)", "date_published": "2026-09-07T14:01:57+00:00"}, {"id": "https://t.me/c/1939110700/413", "url": "https://t.me/c/1939110700/413", "title": "5 сентября пройдёт онлайн-конференции Яндекса о технологических вызовах в эпоху AI. В эфире эксперт", "content_html": "5 сентября пройдёт онлайн-конференции Яндекса о технологических вызовах в эпоху AI.
В эфире эксперты Яндекса, российских и международных IT-компаний обсудят технологии, которые сегодня определяют развитие индустрии: как AI меняет инфраструктуру, архитектуру и подходы к разработке.
📌 Формат мероприятия
Программа делится на три трека — Hard (технические доклады с акцентом на сложность задач), Practice (демо и воркшопы с акцентом на конкретные прикладные навыки) и Experiment (лайтнинги и доклады с акцентом на тренды и новые форматы).
• Основной формат — онлайн-трансляция для всех зарегистрированных участников. В онлайне можно подключиться к треку Hard и Experiment, а также к Q&A-сессиям со спикерами. Регистрация открыта для всех.
• Места в офлайн ограничены. Поэтому регистрация в офлайн проходит по персональным приглашениям программного комитета конференции. Если вы хотите, можно упомянуть про офлайн и возможность оставить заявку в форме. Организаторы вернутся с ответом не позднее чем за неделю до события.
Записи выступлений всех докладов опубликуют после мероприятия.
📷 Доклады в онлайне
«За пределами LLM: что дальше после первого поколения AI-систем»
Мо Гавдат, ex-Chief Business Officer (Google X) расскажет о том, как AI изменит разработку ПО, процессы и роль разработчика. Как могут эволюционировать инженерные команды и какие вызовы их ждут.
«От классического ML к генеративным моделям: незаметная революция в RecSys»
Алексей Гусаков, CTO Бизнес‑группы Поисковых сервисов и ИИ (Яндекс) расскажет о том, как новые подходы помогают перейти от надстройки над классическими системами к одностадийным рекомендациям без ручного фичеинжиниринга.
«Physical AI без купюр»
Сергей Мельник, Руководитель сервиса Автономного транспорта и роботов (Яндекс), расскажет о том, как построить стек для продуктов Physical AI и запустить его в реальных условиях.
«От поиска к агентам: путь Алисы»
Павел Капля, Руководитель службы продуктовой разработки Алисы (Яндекс), разберет, как создаются агентские продукты в Алисе: от SDK и работы с моделями до пользовательского интерфейса. Обсудим ключевые инженерные вызовы и выясним, что нужно, чтобы превратить генеративного агента в массовый продукт.
«AI и продуктивность в Яндексе: что реально заработало»
Андрей Попов, Руководитель Управления машинного интеллекта (Яндекс), расскажет, что происходит с профессией разработчика — ускорение на 10–30% или тихая, но радикальная перестройка команд? Мы весь год измеряли эти показатели и готовы поделиться цифрами.
Полную программу и доклады можно посмотреть на сайте.
The video is too large.", "date_published": "2026-08-21T15:01:09+00:00"}, {"id": "https://t.me/c/1939110700/412", "url": "https://t.me/c/1939110700/412", "title": "Самое ценное, что можно получить от работы в большой компании - не строчка в резюме, не новый грейд ", "content_html": "Самое ценное, что можно получить от работы в большой компании - не строчка в резюме, не новый грейд и даже не опыт работы с очередным модным стеком.
Это люди, нетворк и чужие мысли.
За одну случайную беседу на кухне можно узнать больше, чем за несколько вечеров чтения статей. Кто-то расскажет, как устроена ML-система, которую ты видел только снаружи. Кто-то поделится провалом, который сэкономит тебе полгода собственных ошибок.
И мне кажется, в этом одна из главных ценностей сильного профессионального окружения: ты постоянно сталкиваешься с людьми, которые думают иначе, чем ты.
Но есть проблема - обычно такой нетворк заканчивается стенами офиса.
Поэтому мне очень нравятся папки с каналами сотрудников больших компаний. Это буквально возможность заглянуть в головы людей, с которыми иначе ты, возможно, никогда бы не пересёкся.
И сегодня как раз такая папка, которую к тому же я собирал)
Здесь люди из разработки, ML, аналитики, продукта, менеджмента и других направлений. Кто-то пишет глубоко технические разборы, кто-то - про карьеру, кто-то делится внутренней кухней профессии, а кто-то просто интересными мыслями, которые хочется унести с собой.
Получается такой маленький цифровой кофепоинт Яндекса, только без необходимости сначала пройти пять секций собеседования 🙂
Мне кажется, каждому будет интересно пробежаться по каналам, открыть несколько постов и найти 2–3 человека, за ходом мыслей которых вам действительно интересно следить.
Потому что хороший нетворк начинается не со знакомства.
Он начинается с интереса к тому, как думают другие люди.
Не промахнись!
👉 https://t.me/addlist/KaVv1NTpJKpmYmZi
👉 https://t.me/addlist/KaVv1NTpJKpmYmZi
👉 https://t.me/addlist/KaVv1NTpJKpmYmZi", "date_published": "2026-08-19T15:01:50+00:00"}, {"id": "https://t.me/c/1939110700/411", "url": "https://t.me/c/1939110700/411", "title": "Как заработать $8 млн, рискнув всего $5 тысяч Представьте самолёт на 300 мест. Авиакомпания продаёт", "content_html": "Как заработать $8 млн, рискнув всего $5 тысяч
Представьте самолёт на 300 мест. Авиакомпания продаёт на него 304 билета.
На первый взгляд кажется, что кто-то в компании не умеет считать. Но на самом деле это не ошибка, а вполне осознанное решение на основе статистики.
Разберём, как здесь работает наш любимый Data Science)
По историческим данным, вероятность того, что конкретный пассажир придёт на рейс, составляет 95%. Если продать ровно 300 билетов, самолёт почти наверняка полетит с пустыми местами, а пустое кресло после взлёта скорее всего уже невозможно продать.
Поэтому авиакомпания продаёт 304 билета и принимает небольшой риск, что придут вообще все.
Количество пришедших пассажиров можно описать биномиальным распределением:
- 304 независимых события;
- два возможных исхода: пришёл или не пришёл;
- вероятность прихода - 95%.
Нас интересует вероятность того, что на рейс придёт больше 300 человек.
То есть:
P(X > 300) = P(301) + P(302) + P(303) + P(304)
{}
После расчётов получаем вероятность примерно 0,014%. Это около одного перебронированного рейса на 7200 подобных рейсов. Кажется, что риск небольшой. Но насколько это выгодно в деньгах?
Допустим, авиакомпания выполняет 10 000 таких рейсов. На каждом она продаёт четыре дополнительных билета:
10 000 × 4 = 40 000 дополнительных билетов.
{}
При средней цене билета $200 получаем:
40 000 × $200 = $8 000 000 дополнительной выручки.
При этом математическое ожидание количества пассажиров, которым не хватит места, составляет всего около 1,66 человека на все 10 000 рейсов. Даже если каждому выплатить компенсацию, оплатить отель и пересадить на следующий рейс, расходы могут составить меньше $5000.
С точки зрения математики выбор очевиден:
рискнуть $5000 ради потенциальных $8 млн.
Именно поэтому овербукинг существует. Вот и любите этот ваш DS.", "date_published": "2026-07-31T14:02:26+00:00"}, {"id": "https://t.me/c/1939110700/410", "url": "https://t.me/c/1939110700/410", "title": "Топ 6 ошибок в резюме, из-за которых вас могут не позвать на собеседование Можно быть сильным специ", "content_html": "Топ 6 ошибок в резюме, из-за которых вас могут не позвать на собеседование
Можно быть сильным специалистом, но получать мало откликов просто потому, что из резюме это непонятно. HR не будет работать самостоятельно искать ваши сильные стороны.
Вот шесть ошибок, на которые я обращаю внимание:
1. Слишком длинное резюме
Любое резюме больше 3-4(если вы не лид) страниц вряд ли будет релевантным и будьте уверены, что HR даже половины не прочитает. Оно выглядит как то, что вы не умеете выделять главное и четко показывать, почему именно вы идеальный кандидат
2. Нерелевантный опыт
Если вы откликаетесь на AI/LLM позицию, то не нужно заполнять резюме проектами с классикой или с CV. Если вы настолько крутой специалист, что у вас есть проекты на каждую из областей, то напишите отдельные резюме на каждый домен
3. Отсутствие результата
Тут одно слово - метрики. Именно на чаще всего смотрит работодатель, потому что ничего вас не опишет лучше, чем цифры
4. Нет чёткой позиции чем вы занимались в проектах
Для каждого вашего проекта, который указан в резюме, вы четко должны рассказать ваше участие в конечном результате. Конечно, есть личные проекты, но в остальных вы обязаны четко понимать вашу роль
5. Отсутствие ссылок на портфолио или отсутствие самого портфолио
Часто встречаю, что есть определенные проекты и/или ачивки, но на них нет ссылок не на гите, ни где-либо еще. Чтобы не выглядеть воздуханом, приложите какой-нибудь ресурс, который подтвердит вашу работу
6. Отсутствие структуры и выделения
Выделяйте важные пункты в своем резюме, обязательно структурируете его, чтобы самая релевантная информация сразу попадала на глаза рекрутора
Какие пункты резюме для вас еще важны и на что вы чаще всего обращаете внимание?)", "date_published": "2026-07-29T14:04:01+00:00"}, {"id": "https://t.me/c/1939110700/409", "url": "https://t.me/c/1939110700/409", "title": "Как работает агентский RAG? Обычный RAG работает достаточно просто: вопрос -> поиск документов -", "content_html": "Как работает агентский RAG?
Обычный RAG работает достаточно просто:
вопрос -> поиск документов -> ответ LLM
Пользователь задаёт вопрос, система находит похожие фрагменты в векторной базе и передаёт их модели.
Проблема в том, что никто не проверяет: а найденные документы вообще отвечают на вопрос?
Например, пользователь спрашивает:
Может ли подрядчик работать удалённо из другой страны?
{}
Для нормального ответа могут понадобиться:
• политика удалённой работы;
• договор с подрядчиками;
• список разрешённых стран;
• налоговые ограничения.
Обычный RAG может найти только первый документ и уверенно сгенерировать неполный ответ.
Что меняет агентский RAG
Он добавляет между поиском и генерацией агента, который может принимать решения.
Теперь схема выглядит так:
вопрос -> поиск -> проверка -> решение -> повторный поиск или ответ
После retrieval агент оценивает:
• релевантны ли найденные документы;
• достаточно ли информации;
• нет ли противоречий;
• нужно ли искать в другом источнике;
• стоит ли переформулировать запрос.
Если контекста недостаточно, система не отвечает сразу, а пробует другой путь.
Три основные возможности
1. Routing
Агент сам выбирает источник:
• документы;
• SQL-база;
• интернет;
• API;
• несколько источников одновременно.
2. Query refinement
Если запрос слишком общий, агент переписывает или разбивает его на несколько подзапросов.
Например:
«Правила удалённой работы»
«Ограничения для подрядчиков»
«Работа сотрудников из других стран»
{}
3. Self-evaluation
После поиска агент проверяет качество контекста. Если документ устарел, не отвечает на вопрос или противоречит другому источнику, запускается новая итерация поиска.
По сути:
Обычный RAG: нашёл -> ответил.
Агентский RAG: нашёл -> проверил -> попробовал ещё раз -> ответил.
Но агентский RAG нужен не всегда
Каждая дополнительная итерация означает:
• ещё один вызов LLM;
• большую задержку;
• дополнительные токены;
• более сложную отладку;
• менее предсказуемое поведение.
Если у вас простые FAQ и чистая база знаний, обычный RAG будет быстрее и дешевле.
И важный момент: агент не исправит плохой retrieval. Именно поэтому в пайплайне любого RAG так важны хороший датасет и четко собранная БД
💗 - на еще один обзор
![\"media\"/](\"https://tg.davvie.com/static/-1001939110700--409-0.jpg\")
![\"media\"/](\"https://tg.davvie.com/static/-1001939110700--408-1.jpg\")
", "date_published": "2026-07-27T15:01:52+00:00", "attachments": [{"url": "https://tg.davvie.com/static/-1001939110700--409-0.jpg", "mime_type": "image/jpeg"}, {"url": "https://tg.davvie.com/static/-1001939110700--408-1.jpg", "mime_type": "image/jpeg"}]}, {"id": "https://t.me/c/1939110700/407", "url": "https://t.me/c/1939110700/407", "title": "Как меняются собеседования и процесс найма со стороны программистов За последние несколько лет рыно", "content_html": "Как меняются собеседования и процесс найма со стороны программистов
За последние несколько лет рынок IT сильно поменялся: если раньше ты мог написать open to work на линке и закинуть свое резюме в вакансии, которые нравятся именно тебе, то сейчас поиск работы сильно поменялся и начинается он задолго до того, как ты начинаешь искать вакансии(и вообще в целом начинаешь ли ты их искать?)
Шаг 0. Нетворк
Как ни странно, ничего лучше этого пока не придумали. Когда ты только начинаешь задумываться о смене работы, берем и начинаем шерстить контакты, причем не только близких знакомых, но и HR, если раньше мы могли на них забить, то сейчас нужно чуть ли не папку создавать, потому что только они знают какие вакансии реальные
Шаг 1. Реферальные программы
Собираем список компаний, куда мы хотим и ищем людей, которые работают в этих компаних, чем выше по должности, тем лучше. Рефералки один из немногих все еще работающих способов, с помощью которого можно пройти через сотни других резюме и ATS сразу к человеку
Шаг 2. Ваше резюме
К сожалению, если вы не из вышки и мфти, вы попадаете в огромную кипу резюме, таких же крутых как и вы. Нужно четко и, желательно, в одной странице показать, почему вы крутой кандидат. Так что когда вы участвуете в хакатонах, всегда сохраняйте сертефикаты об участии, даже если вы ничего не делали, всегда под соревнование можно будет собрать сильный репозиторий или поправить ошибки в уже существующем
Шаг 3. Резюме под вакансию
Если вы уже начали откликаться по вакансиям, то постарайтесь, чтобы ваше резюме максимально соответствовало позиции и уровню, на который вы идете. Понятно, что на позицию LLM инженера нерелевантно будет cv проекты, но многие люди забывают, что те проекты, которые были релевантны на junior+ и middle, будут требовать другого позиционирования на позицию Senior, так как будет важно понимание продукта и метрик, которые удалось достичь
Шаг 4. Подготовка к собеседованию
Твоя подготовка должна начинаться хотя бы за неделю, а лучше за две. Спасает то, что сейчас собесы разделены по секциям и в условном Яндексе или Авито тебя будут спрашивать либо только алгосы, либо ML
Шаг 5. Даже после получения оффера не заканчивай работать над своим личным профилем
Сейчас мы находимся в эпохе сокращений и оптимизации, поэтому тебе нужно всегда быть на готове и иметь релевантный опыт уже исходя твоей новой позиции. Лучший вариант, когда твои проекты в магистратуре попадают к тебе на kaggle или гит, чтобы не тратить время дважды
Не нужно выходить на новую работу и сразу готовиться к следующей. Но стоит сохранять результаты проектов, фиксировать достижения и понимать, как меняется ваша ценность на рынке. Тогда поиск работы начнется не с попытки вспомнить, чем вы занимались последние три года, а с уже собранного и понятного профессионального опыта.", "date_published": "2026-07-24T15:03:54+00:00"}, {"id": "https://t.me/c/1939110700/406", "url": "https://t.me/c/1939110700/406", "title": "", "content_html": "
![\"media\"/](\"https://tg.davvie.com/static/-1001939110700--406-0.jpg\")
![\"media\"/](\"https://tg.davvie.com/static/-1001939110700--405-1.jpg\")
![\"media\"/](\"https://tg.davvie.com/static/-1001939110700--404-2.jpg\")
", "date_published": "2026-07-20T08:01:22+00:00", "attachments": [{"url": "https://tg.davvie.com/static/-1001939110700--406-0.jpg", "mime_type": "image/jpeg"}, {"url": "https://tg.davvie.com/static/-1001939110700--405-1.jpg", "mime_type": "image/jpeg"}, {"url": "https://tg.davvie.com/static/-1001939110700--404-2.jpg", "mime_type": "image/jpeg"}]}], "icon": "https://tg.davvie.com/static/avatars/ml_baldini.jpg"}