Forwarded from ML Baldini • Nikita Boyandin (Nikita Boyandin)
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Quant Valerian
Три уровня управления командами
Сегодня я вижу три разных уровня, на которых руководитель может управлять командами и людьми. Традиционно все начинают, и об этом есть много постов, с директивного управления. Свежеиспеченные тимлиды назначают задачки каждому сотруднику индивидуально, на планировании детально смотрят каждый тикет из бэклога, чтобы понять, стоит ли его брать, ежедневно справляются у сотрудников о статусах по каждой задаче — главное, всё это на ручном приводе.
В определенный момент такая схема может перестать масштабироваться. Часто это происходит при переходе на уровень управления тимлидами. В этот момент появляются регламенты и процессы. Руководители уже больше доверяются какому-нибудь управленческому фреймворку (Kanban, RUP etc.), разрабатывают схему "объективной" приоритезации (CD3, RICE etc.), обращают внимание уже только на некоторые задачи (особо важные, выпадающие по срокам etc.), вводят какие-то правила, как сотрудникам брать новые задачи, критерии приемки готовых, всякие DOR/DOD etc.
Регламенты и процессы отлично работают и, в общем и целом, нормально масштабируются. И на этом уровне любой опытный руководитель может остановиться и работать бесконечно долго. Однако высшим мастерством управления, позволяющим максимально раскрываться сотрудникам, дающим больше мотивации, смысла и вообще жизни людям на работе, кроме того, наиболее устойчивым к ошибкам, потерям и автобусным инцидентам, является управление на уровне культуры.
Это уже не просто регламенты, чек-листы и правила. Это создание среды, в которой каждый сотрудник понимает, что и зачем он делает в каждый момент времени. Это система, в которой само окружение заставляет сотрудников думать о решении проблемы, а не делании таски. То есть мы превращаем поточное ремесло в акт творения. У каждого человека есть смысл. В таком окружении каждый понимает не только свой уголок, но и чем заняты люди вокруг, как это всё соединяется, синтезируется в конечную ценность. Каждый может заметить, что вы делаете фигню. Каждый может предложить, как сделать эффективнее. Каждый понимает, не на уровне регламента, а на уровне смысла, какую задачу брать следующей. Каждый заметит, подсветит, подключится при необходимости, если какая-то задача провисла.
Встречали ли вы когда-нибудь команды, управляемые через культуру?
Сегодня я вижу три разных уровня, на которых руководитель может управлять командами и людьми. Традиционно все начинают, и об этом есть много постов, с директивного управления. Свежеиспеченные тимлиды назначают задачки каждому сотруднику индивидуально, на планировании детально смотрят каждый тикет из бэклога, чтобы понять, стоит ли его брать, ежедневно справляются у сотрудников о статусах по каждой задаче — главное, всё это на ручном приводе.
В определенный момент такая схема может перестать масштабироваться. Часто это происходит при переходе на уровень управления тимлидами. В этот момент появляются регламенты и процессы. Руководители уже больше доверяются какому-нибудь управленческому фреймворку (Kanban, RUP etc.), разрабатывают схему "объективной" приоритезации (CD3, RICE etc.), обращают внимание уже только на некоторые задачи (особо важные, выпадающие по срокам etc.), вводят какие-то правила, как сотрудникам брать новые задачи, критерии приемки готовых, всякие DOR/DOD etc.
Регламенты и процессы отлично работают и, в общем и целом, нормально масштабируются. И на этом уровне любой опытный руководитель может остановиться и работать бесконечно долго. Однако высшим мастерством управления, позволяющим максимально раскрываться сотрудникам, дающим больше мотивации, смысла и вообще жизни людям на работе, кроме того, наиболее устойчивым к ошибкам, потерям и автобусным инцидентам, является управление на уровне культуры.
Это уже не просто регламенты, чек-листы и правила. Это создание среды, в которой каждый сотрудник понимает, что и зачем он делает в каждый момент времени. Это система, в которой само окружение заставляет сотрудников думать о решении проблемы, а не делании таски. То есть мы превращаем поточное ремесло в акт творения. У каждого человека есть смысл. В таком окружении каждый понимает не только свой уголок, но и чем заняты люди вокруг, как это всё соединяется, синтезируется в конечную ценность. Каждый может заметить, что вы делаете фигню. Каждый может предложить, как сделать эффективнее. Каждый понимает, не на уровне регламента, а на уровне смысла, какую задачу брать следующей. Каждый заметит, подсветит, подключится при необходимости, если какая-то задача провисла.
Встречали ли вы когда-нибудь команды, управляемые через культуру?
Forwarded from Artem Ryblov’s Data Science Weekly
Problem Solving with Algorithms and Data Structures using Python by Brad Miller and David Ranum, Luther College
This textbook is about computer science. It is also about Python. However, there is much more.
The study of algorithms and data structures is central to understanding what computer science is all about. Learning computer science is not unlike learning any other type of difficult subject matter. The only way to be successful is through deliberate and incremental exposure to the fundamental ideas. A beginning computer scientist needs practice so that there is a thorough understanding before continuing on to the more complex parts of the curriculum. In addition, a beginner needs to be given the opportunity to be successful and gain confidence.
This textbook is designed to serve as a text for a first course on data structures and algorithms, typically taught as the second course in the computer science curriculum. Even though the second course is considered more advanced than the first course, this book assumes you are beginners at this level. You may still be struggling with some of the basic ideas and skills from a first computer science course and yet be ready to further explore the discipline and continue to practice problem solving.
Authors cover abstract data types and data structures, writing algorithms, and solving problems. They look at a number of data structures and solve classic problems that arise. The tools and techniques that you learn here will be applied over and over as you continue your study of computer science.
Links:
- Site
- Book
Navigational hashtags: #armbooks #armcourses
General hashtags: #python #algorithms #datastructures #programming #cs #computerscience
@data_science_weekly
This textbook is about computer science. It is also about Python. However, there is much more.
The study of algorithms and data structures is central to understanding what computer science is all about. Learning computer science is not unlike learning any other type of difficult subject matter. The only way to be successful is through deliberate and incremental exposure to the fundamental ideas. A beginning computer scientist needs practice so that there is a thorough understanding before continuing on to the more complex parts of the curriculum. In addition, a beginner needs to be given the opportunity to be successful and gain confidence.
This textbook is designed to serve as a text for a first course on data structures and algorithms, typically taught as the second course in the computer science curriculum. Even though the second course is considered more advanced than the first course, this book assumes you are beginners at this level. You may still be struggling with some of the basic ideas and skills from a first computer science course and yet be ready to further explore the discipline and continue to practice problem solving.
Authors cover abstract data types and data structures, writing algorithms, and solving problems. They look at a number of data structures and solve classic problems that arise. The tools and techniques that you learn here will be applied over and over as you continue your study of computer science.
Links:
- Site
- Book
Navigational hashtags: #armbooks #armcourses
General hashtags: #python #algorithms #datastructures #programming #cs #computerscience
@data_science_weekly
Forwarded from Тимлид Очевидность | Евгений Антонов
Онбординг и обучение руководителей
Я неоднократно видел один и тот же паттерн повышения или из линейного работника руками в тимлида, или из тимлида в тимлида тимлидов, в ходе которого люди оставались наедине с этим повышением.
Им говорят, что они уже взрослые и сениорные специалисты, и от них ожидается, что те сами во всем разберутся, желательно не сбавляя темпа, ведь все бегут и мы бежим.
Ну а правда, опытные же!
А вот я считаю, что не опытные. Ну вернее, опытные, но в другом.
В первом случае человек работал руками, а потом стал руководителем таких работяг. Он не делал этого раньше, не умеет это делать, и ему мало кто говорит, чего от него ждут, что подтянуть, где уже хорошо. А уж как писать код 80% времени и оставшиеся 80% времени заниматься менеджментом, точно никто не рассказывает, но порой требуют 🙂
В случае перехода из тимлидов в мидл-менеджмент ситуация ненамного лучше. Одно дело напрямую руководить линейными работниками, а другое дело руководить руководителями, и на конечные команды влиять уже через них.
Вот и выходит, что мы получаем в какой-то степени джунов тимлидов и мидл-менеджеров, которых оставляют наедине с этими заботами, даже порой не закладывая просадку по результатам на время адаптации.
А что же делать?
Очередная порция очевидных советов от Тимлида Очевидность. Очевидные вещи, но почему-то не всегда реализуемые 🙁
- Новому уровню руководства можно обучать заранее. В ряде случаев вы заранее знаете, какого человека подвинете наверх, и еще до этого самого продвижения его можно отправить на обучение. Где-то бывают курсы внутри компании, где-то покупают внешние курсы, где-то нет на это денег, но более опытные руководители собирают и готовят материалы, проводят какое-никакое обучение.
Смешная история была с одним моим знакомым, которому в компании сказали, что он будет тимлидом через N месяцев, но ему нельзя посмотреть обучение для тимлидов, потому что он еще не тимлид. И получилось, что он просто ждал, когда разгорится огонь, и вот только когда уже полыхнуло, ему дали огнетушитель.
Вот повысят, тогда и приходите.
- Если всё быстро и внезапно, то хотя бы можно заложить время на адаптацию. Я понимаю, что сроки горят, бизнес крутится, деньги мутятся. Но если со старта в жернова на полной скорости закручивать свежих руководителей, то можно получить довольно скоро уже выжатых и пожалевших о своем решении людей.
Хотя, наверное, это не остановит компании с девизом «слабаки нам не нужны», но это уже совсем другая история.
- Руководитель промоутируемого должен вкладываться в адаптацию. Вы же не запускаете джуна разработчика в проект со словами «вот рутовый пароль от базы, вот так деплоить в прод, давай, дальше сам разберешься». Это и про менторинг, и про явное проговаривание ожиданий, планов, и про погружение в контекст нового подразделения и продукта.
А если руководитель этого не понимает, то советую почитать книгу «Первые 90 дней. Стратегии успеха для новых лидеров всех уровней». Там подробно говорится о важности адаптации руководителя на новой позиции.
- Кто-то делает у себя внутри компании кадровый резерв и организует что-то типа школы тимлидов для желающих и заинтересованных, чтобы потом закрывать возникающие вакансии быстро изнутри уже готовыми к этому людьми.
Итог
Чтобы пореже жаловаться, что из хорошего инженера сделали плохого тимлида, можно и нужно заниматься обучением и адаптацией руководителей. Хотя бы на первые две ступени.
Говорят, дальше уже примерно понятно идет, без такого серьезного сдвига парадигмы.
Тимлиды и мидл-менеджеры, поделитесь своим опытом о том, как вас онбордили и обучали при повышении.
Я неоднократно видел один и тот же паттерн повышения или из линейного работника руками в тимлида, или из тимлида в тимлида тимлидов, в ходе которого люди оставались наедине с этим повышением.
Им говорят, что они уже взрослые и сениорные специалисты, и от них ожидается, что те сами во всем разберутся, желательно не сбавляя темпа, ведь все бегут и мы бежим.
Ну а правда, опытные же!
А вот я считаю, что не опытные. Ну вернее, опытные, но в другом.
В первом случае человек работал руками, а потом стал руководителем таких работяг. Он не делал этого раньше, не умеет это делать, и ему мало кто говорит, чего от него ждут, что подтянуть, где уже хорошо. А уж как писать код 80% времени и оставшиеся 80% времени заниматься менеджментом, точно никто не рассказывает, но порой требуют 🙂
В случае перехода из тимлидов в мидл-менеджмент ситуация ненамного лучше. Одно дело напрямую руководить линейными работниками, а другое дело руководить руководителями, и на конечные команды влиять уже через них.
Вот и выходит, что мы получаем в какой-то степени джунов тимлидов и мидл-менеджеров, которых оставляют наедине с этими заботами, даже порой не закладывая просадку по результатам на время адаптации.
А что же делать?
Очередная порция очевидных советов от Тимлида Очевидность. Очевидные вещи, но почему-то не всегда реализуемые 🙁
- Новому уровню руководства можно обучать заранее. В ряде случаев вы заранее знаете, какого человека подвинете наверх, и еще до этого самого продвижения его можно отправить на обучение. Где-то бывают курсы внутри компании, где-то покупают внешние курсы, где-то нет на это денег, но более опытные руководители собирают и готовят материалы, проводят какое-никакое обучение.
Смешная история была с одним моим знакомым, которому в компании сказали, что он будет тимлидом через N месяцев, но ему нельзя посмотреть обучение для тимлидов, потому что он еще не тимлид. И получилось, что он просто ждал, когда разгорится огонь, и вот только когда уже полыхнуло, ему дали огнетушитель.
Вот повысят, тогда и приходите.
- Если всё быстро и внезапно, то хотя бы можно заложить время на адаптацию. Я понимаю, что сроки горят, бизнес крутится, деньги мутятся. Но если со старта в жернова на полной скорости закручивать свежих руководителей, то можно получить довольно скоро уже выжатых и пожалевших о своем решении людей.
Хотя, наверное, это не остановит компании с девизом «слабаки нам не нужны», но это уже совсем другая история.
- Руководитель промоутируемого должен вкладываться в адаптацию. Вы же не запускаете джуна разработчика в проект со словами «вот рутовый пароль от базы, вот так деплоить в прод, давай, дальше сам разберешься». Это и про менторинг, и про явное проговаривание ожиданий, планов, и про погружение в контекст нового подразделения и продукта.
А если руководитель этого не понимает, то советую почитать книгу «Первые 90 дней. Стратегии успеха для новых лидеров всех уровней». Там подробно говорится о важности адаптации руководителя на новой позиции.
- Кто-то делает у себя внутри компании кадровый резерв и организует что-то типа школы тимлидов для желающих и заинтересованных, чтобы потом закрывать возникающие вакансии быстро изнутри уже готовыми к этому людьми.
Итог
Чтобы пореже жаловаться, что из хорошего инженера сделали плохого тимлида, можно и нужно заниматься обучением и адаптацией руководителей. Хотя бы на первые две ступени.
Говорят, дальше уже примерно понятно идет, без такого серьезного сдвига парадигмы.
Тимлиды и мидл-менеджеры, поделитесь своим опытом о том, как вас онбордили и обучали при повышении.
Forwarded from Refat Talks: Tech & AI
Context Rot (гниение контекста)
Ребята из Chroma провели масштабное исследование (пост, ролик) и выяснили неприятную правду - все современные LLM страдают от "гниения контекста". И это не баг, а системная проблема текущих архитектур.
Провели контролируемые эксперименты на 18 моделях, за основу взяли тест Needle in a Haystack, но варьировали семантическое сходство между "иглой" и вопросом и добавляли отвлекающие факторы (distractors) + использовали дополнительные тесты типа LongMemEval.
Главный вывод: производительность LLM деградирует нелинейно и непредсказуемо с увеличением длины контекста.
Не то что бы это сюрприз.
Но что еще интересного:
- Когда вопрос и ответ связаны не лексически, а семантически (требуется понимание смысла), производительность падает значительно быстрее с увеличением контекста (кстати, один из способов улучшить это - делать query expansion)
- Thinking modes немного помогают, но не решают проблему
- Парадокс структуры: Модели работают хуже (на 10-15%) на логически структурированном тексте, чем на случайно перемешанных предложениях!
Практические выводы:
1. Context Engineering критически важен - не только наличие информации в контексте, но и то, КАК она представлена, сильно влияет на результат
2. Нельзя полагаться на заявленные длины контекста - даже если модель поддерживает 1M токенов, это не значит, что она будет эффективно работать с такими объемами (кстати, классный был бенч от Nvidia RULER, не нашел ничего подобного для новых моделей).
3. Замечали как память ChatGPT иногда делает его тупее и рассеяннее? Это оно (поэтому я выключаю память по-умолчанию)
4. Популярный Needle in a Haystack - так себе бенчмарк сам по себе, тестируется слишком примитивно
5. Модели лучше помнят то, что в начале и конце контекста. Критически важную инфу размещайте там.
Про Context Engineering мы обязательно поговорим в отдельном посте, тут помимо самих техник важно понимать что есть два аспекта:
- внутренний: определение того, что должно быть в контексте прямо сейчас (в конкретном вызове LLM)
- внешний: улучшение со временем в заполнении контекста только релевантной информацией (что именно оставлять агенту во время оркестрации, как правильно хранить историю чата, что помнить о пользователе и тд).
И главный вывод простой: относитесь к контексту как к дорогому и ограниченному ресурсу. Не потому что токены стоят денег (хотя и это тоже), а потому что каждый лишний токен снижает вероятность того, что модель правильно поймет вашу задачу.
Ребята из Chroma провели масштабное исследование (пост, ролик) и выяснили неприятную правду - все современные LLM страдают от "гниения контекста". И это не баг, а системная проблема текущих архитектур.
Провели контролируемые эксперименты на 18 моделях, за основу взяли тест Needle in a Haystack, но варьировали семантическое сходство между "иглой" и вопросом и добавляли отвлекающие факторы (distractors) + использовали дополнительные тесты типа LongMemEval.
Главный вывод: производительность LLM деградирует нелинейно и непредсказуемо с увеличением длины контекста.
Не то что бы это сюрприз.
Но что еще интересного:
- Когда вопрос и ответ связаны не лексически, а семантически (требуется понимание смысла), производительность падает значительно быстрее с увеличением контекста (кстати, один из способов улучшить это - делать query expansion)
- Thinking modes немного помогают, но не решают проблему
- Парадокс структуры: Модели работают хуже (на 10-15%) на логически структурированном тексте, чем на случайно перемешанных предложениях!
Практические выводы:
1. Context Engineering критически важен - не только наличие информации в контексте, но и то, КАК она представлена, сильно влияет на результат
2. Нельзя полагаться на заявленные длины контекста - даже если модель поддерживает 1M токенов, это не значит, что она будет эффективно работать с такими объемами (кстати, классный был бенч от Nvidia RULER, не нашел ничего подобного для новых моделей).
3. Замечали как память ChatGPT иногда делает его тупее и рассеяннее? Это оно (поэтому я выключаю память по-умолчанию)
4. Популярный Needle in a Haystack - так себе бенчмарк сам по себе, тестируется слишком примитивно
5. Модели лучше помнят то, что в начале и конце контекста. Критически важную инфу размещайте там.
Про Context Engineering мы обязательно поговорим в отдельном посте, тут помимо самих техник важно понимать что есть два аспекта:
- внутренний: определение того, что должно быть в контексте прямо сейчас (в конкретном вызове LLM)
- внешний: улучшение со временем в заполнении контекста только релевантной информацией (что именно оставлять агенту во время оркестрации, как правильно хранить историю чата, что помнить о пользователе и тд).
И главный вывод простой: относитесь к контексту как к дорогому и ограниченному ресурсу. Не потому что токены стоят денег (хотя и это тоже), а потому что каждый лишний токен снижает вероятность того, что модель правильно поймет вашу задачу.
Forwarded from Daniilak — Канал
Для начинающих (и не только) будет полезно
https://dfedorov.spb.ru/pandas/
Гоняем 100гб csv-файлы на очердной мультиварке 2000-года туда-сюда
https://dfedorov.spb.ru/pandas/
Гоняем 100гб csv-файлы на очердной мультиварке 2000-года туда-сюда
dfedorov.spb.ru
Введение в Pandas, NumPy, Matplotlib, Plotly, Altair для анализа данных
Python, Pandas, NumPy, Matplotlib, Plotly, Altair, Seaborn для анализа данных
Forwarded from Data Blog
Привет, друзья! Врываюсь с полезными материалами! :)
Сделала открытую страничку, посвящённую механистической интерпретируемости.
В отличие от "обычной интерпретируемости", где мы чаще ограничиваемся атрибуцией признаков или визуализацией, механистическая ставит цель понять механизмы: какие представления формируются внутри модели, какие там есть схемы и связи и каким образом из простых блоков складывается сложное поведение.
Пока что глобально сильных результатов, вроде тех, что приближали бы к ответу на вопрос "Как спастись от AGI?" нет. Но с помощью MI можно:
— находить интерпретируемые признаки внутри моделей и отслеживать, как они взаимодействуют;
— создавать инструменты для редактирования поведения моделей (feature editing, model steering);
— теоретически понимать архитектуры вроде трансформеров, на которых сегодня держится весь прогресс :)
На страничках уже есть:
— введение в тему и зачем она нужна;
— базовые определения и ключевые термины;
— обзор гипотез, на которых строится подход;
— разбор архитектуры трансформеров.
Другие ресурсы по MI есть, конечно. Но я хочу сделать "живой справочник" и подтягиваю свежие статьи и работы, чтобы можно было сориентироваться в том, что есть сейчас.
Надеюсь больше не пропадать, хотя творческий кризис — это почти полезно, если из него выйти.
Всегда Ваш,
Дата-автор! :)
Сделала открытую страничку, посвящённую механистической интерпретируемости.
В отличие от "обычной интерпретируемости", где мы чаще ограничиваемся атрибуцией признаков или визуализацией, механистическая ставит цель понять механизмы: какие представления формируются внутри модели, какие там есть схемы и связи и каким образом из простых блоков складывается сложное поведение.
Пока что глобально сильных результатов, вроде тех, что приближали бы к ответу на вопрос "Как спастись от AGI?" нет. Но с помощью MI можно:
— находить интерпретируемые признаки внутри моделей и отслеживать, как они взаимодействуют;
— создавать инструменты для редактирования поведения моделей (feature editing, model steering);
— теоретически понимать архитектуры вроде трансформеров, на которых сегодня держится весь прогресс :)
На страничках уже есть:
— введение в тему и зачем она нужна;
— базовые определения и ключевые термины;
— обзор гипотез, на которых строится подход;
— разбор архитектуры трансформеров.
Другие ресурсы по MI есть, конечно. Но я хочу сделать "живой справочник" и подтягиваю свежие статьи и работы, чтобы можно было сориентироваться в том, что есть сейчас.
Надеюсь больше не пропадать, хотя творческий кризис — это почти полезно, если из него выйти.
Всегда Ваш,
Дата-автор! :)
sadsabrina.github.io
Awesome MI theory
Simple notes and articles on MI theory
Forwarded from Korenev AI - GPT в тапочках🩴
Как найти пушка-идею для супер-сервиса
Встретил алгоритм поиска идей, которым хочется поделиться:
1. Изучаем в первую очередь популярные приложения. Если нет популярности, значит идея не востребована.
2. Заходим в отзывы и читаем самые отрицательные и самые залайканные (именно этот пункт меня зацепил)
3. Думаем, как можем в своем проекте учесть отрицательные моменты проектов-локомотивов
Ну а дальше самое простое:
4. Быстро-быстро делаем проект - захватываем рынок - зарабатываем свой миллион долларов. Просто и точка!
Встретил алгоритм поиска идей, которым хочется поделиться:
1. Изучаем в первую очередь популярные приложения. Если нет популярности, значит идея не востребована.
2. Заходим в отзывы и читаем самые отрицательные и самые залайканные (именно этот пункт меня зацепил)
3. Думаем, как можем в своем проекте учесть отрицательные моменты проектов-локомотивов
Ну а дальше самое простое:
4. Быстро-быстро делаем проект - захватываем рынок - зарабатываем свой миллион долларов. Просто и точка!
Forwarded from Андрей Созыкин (Andrey Sozykin)
YouTube
Практика по сокетам | Компьютерные сети 2025 - 37
Практика по сокетам - интерфейсу транспортного уровня TCP/IP.
Как поддержать курс:
- Boosty - https://boosty.to/asozykin
- Cloudtips - https://pay.cloudtips.ru/p/45a4055b
Заранее спасибо за помощь!
Сайт курса - https://www.asozykin.ru/courses/networks_online…
Как поддержать курс:
- Boosty - https://boosty.to/asozykin
- Cloudtips - https://pay.cloudtips.ru/p/45a4055b
Заранее спасибо за помощь!
Сайт курса - https://www.asozykin.ru/courses/networks_online…
Практика по сокетам на Python
В видео по компьютерным сетям на этой неделе рассматриваем пример с сокетами на Python:
- Разбираемся, как запустить клиент и сервер в терминале.
- Проверяем, что сервер ожидает соединений (LISTEN) с помощью TCPView и netstat.
- Просматриваем в Wireshark, как данные между сокетами передаются по сети.
Полный код из видео находится в репозитории на GitHub.
Если плохо работает YouTube, то можно смотреть в Дзен или VK.
Поддержать создание курса можно на Boosty или CloudTips.
В видео по компьютерным сетям на этой неделе рассматриваем пример с сокетами на Python:
- Разбираемся, как запустить клиент и сервер в терминале.
- Проверяем, что сервер ожидает соединений (LISTEN) с помощью TCPView и netstat.
- Просматриваем в Wireshark, как данные между сокетами передаются по сети.
Полный код из видео находится в репозитории на GitHub.
Если плохо работает YouTube, то можно смотреть в Дзен или VK.
Поддержать создание курса можно на Boosty или CloudTips.
Forwarded from Запрети мне псевдолейблить
Пятое место #Birdclef2025
Мануальная обработка данных
Это вообще та самая 'секретная техника', которую все ленятся делать. Данные полезно ковырять/слушать смотреть руками
Использовали Silero для того, чтобы найти записи с человеческим голосом, затем слушали их уже своими ушами и вырезали все фрагменты, где слышен человек.
Вообще у Silero есть бот, так что я им пожалуй и озвучу этот раздел поста.
Для классов с низкой частотностью (меньше 30 семплов в трейне) дополнительно послушали все записи и из каждой вычистили участки, где птиц не слышно.
Для трейна брали только первые 30 сек записи, а для низкочастотных 60 сек. Там, где семплов было меньше 20 для класса- апсемплили, чтобы 'разудть' трейн.
Модели
Стакали кучу эффишентнетов. Благо они с легкостью влезали в ограничения по CPU
• 4x tf_efficientnetv2_s
• 3x tf_efficientnetv2_b3
• 4x tf_efficient_b3_ns
• 2x tf_efficient_b0_ns
Но важно что тренировали в три стейджа. В каждом FocalLoss, Adam, Cosine Annealing + warmup
Первый стейдж:
только основной набор данных, только основной таргет
Второй стейдж:
Основной таргет + псевдолейблы, только основные размеченные данные + двухэтапная самодистилляция
Третий стейдж:
Использовали все данные. Для каждого батча брали половину из размеченных данных, половину из неразмеченных. Для основного набора испольовали основные лейблы + псевдолейблы с второго этапа, для неразмеченных- только псевдолейблы
Ну и еще дважды самодистилляция.
Если вы шарите, то объясните плз в комментах почему самодистилл работает и почему его есть смысл больше двух раз делать? Там еще и перфоманс на самодистиллах растет. В комментах есть график того, какие резульатты получаются от уровня дистилла
Мануальная обработка данных
Это вообще та самая 'секретная техника', которую все ленятся делать. Данные полезно ковырять/слушать смотреть руками
Использовали Silero для того, чтобы найти записи с человеческим голосом, затем слушали их уже своими ушами и вырезали все фрагменты, где слышен человек.
Вообще у Silero есть бот, так что я им пожалуй и озвучу этот раздел поста.
Для классов с низкой частотностью (меньше 30 семплов в трейне) дополнительно послушали все записи и из каждой вычистили участки, где птиц не слышно.
Для трейна брали только первые 30 сек записи, а для низкочастотных 60 сек. Там, где семплов было меньше 20 для класса- апсемплили, чтобы 'разудть' трейн.
Модели
Стакали кучу эффишентнетов. Благо они с легкостью влезали в ограничения по CPU
• 4x tf_efficientnetv2_s
• 3x tf_efficientnetv2_b3
• 4x tf_efficient_b3_ns
• 2x tf_efficient_b0_ns
Но важно что тренировали в три стейджа. В каждом FocalLoss, Adam, Cosine Annealing + warmup
Первый стейдж:
только основной набор данных, только основной таргет
Второй стейдж:
Основной таргет + псевдолейблы, только основные размеченные данные + двухэтапная самодистилляция
Третий стейдж:
Использовали все данные. Для каждого батча брали половину из размеченных данных, половину из неразмеченных. Для основного набора испольовали основные лейблы + псевдолейблы с второго этапа, для неразмеченных- только псевдолейблы
Ну и еще дважды самодистилляция.
Если вы шарите, то объясните плз в комментах почему самодистилл работает и почему его есть смысл больше двух раз делать? Там еще и перфоманс на самодистиллах растет. В комментах есть график того, какие резульатты получаются от уровня дистилла
Forwarded from Запрети мне псевдолейблить
4 место в #BirdClef2025
Коротко, но ценно: иногда простота выигрывает.
Поскольку на BirdCLEF нас оценивают именно по AUC, логично оптимизировать его напрямую.
AUC-лосс устойчив к переобучению, но не поддерживает soft labels, как, например, кросс-энтропия.
Что еще работало и не работало:
Semi-supervised learning на неразмеченном датасете:
Сначала обучил 10 моделей EfficientNet на размеченной части.
Сгенерировал «псевдо-лейблы» для неразмеченных данных.
Обучил следующий раунд моделей уже на объединённом наборе.
Отказался от самодистилляции и сложных схем — не заводилось.
Лотерея или мастерство? Автор поднялся с 11 места на 4-е на прайвете! Возможно, дело не только в удаче.
Коротко, но ценно: иногда простота выигрывает.
Поскольку на BirdCLEF нас оценивают именно по AUC, логично оптимизировать его напрямую.
AUC-лосс устойчив к переобучению, но не поддерживает soft labels, как, например, кросс-энтропия.
class SoftAUCLoss(nn.Module):
def __init__(self, margin=1.0, pos_weight=1.0, neg_weight=1.0):
super().__init__()
self.margin = margin
self.pos_weight = pos_weight
self.neg_weight = neg_weight
def forward(self, preds, labels, sample_weights=None):
# Разделяем положительные и отрицательные предсказания
pos_mask = labels > 0.5
neg_mask = labels < 0.5
pos_preds, pos_labels = preds[pos_mask], labels[pos_mask]
neg_preds, neg_labels = preds[neg_mask], labels[neg_mask]
if pos_preds.numel() == 0 or neg_preds.numel() == 0:
return torch.tensor(0., device=preds.device)
# Веса отражают уверенность soft-label
pos_w = self.pos_weight * (pos_labels - 0.5)
neg_w = self.neg_weight * (0.5 - neg_labels)
if sample_weights is not None:
sw = sample_weights.unsqueeze(1).expand_as(labels)
pos_w *= sw[pos_mask]
neg_w *= sw[neg_mask]
# Считаем pairwise-разности и лог-лосс
diff = pos_preds.unsqueeze(1) - neg_preds.unsqueeze(0)
loss_matrix = torch.log1p(torch.exp(-self.margin * diff))
# Усредняем по всем парам с учётом весов
return (loss_matrix * pos_w.unsqueeze(1) * neg_w.unsqueeze(0)).mean()
Что еще работало и не работало:
Semi-supervised learning на неразмеченном датасете:
Сначала обучил 10 моделей EfficientNet на размеченной части.
Сгенерировал «псевдо-лейблы» для неразмеченных данных.
Обучил следующий раунд моделей уже на объединённом наборе.
Отказался от самодистилляции и сложных схем — не заводилось.
Лотерея или мастерство? Автор поднялся с 11 места на 4-е на прайвете! Возможно, дело не только в удаче.
Kaggle
4th place solution | Kaggle
Kaggle is the world’s largest data science community with powerful tools and resources to help you achieve your data science goals.