Forwarded from Тимлид Очевидность | Евгений Антонов
Внедрение изменений по Бекхарду
Есть много разных фреймворков про внедрение изменений, но вы знаете, что я люблю, чтобы было просто и достаточно работоспособно. Вот один из таких вариантов — формула Бекхарда.
Сама формула:
D × V × F > R
D — неудовлетворенность текущей ситуацией (dissatisfaction);
V — видение будущего (vision);
F — первые конкретные шаги, которые могут быть предприняты для реализации видения (first steps);
R — сопротивление изменениям (resistance).
Всего лишь 3 самых важных компонента, которые надо учесть и правильным образом подогреть.
Неудовлетворенность текущей ситуацией
Как следует из названия — кто-то должен быть неудовлетворен ситуацией. Нередко изменения внедряются, потому что кто-то сверху неудовлетворен, снизу всем всё и так хорошо, но оно через силу пихается. А потом руководство расстраивается, что люди на местах — несговорчивые саботажники, а работники — что руководство самодурствует.
Да, может быть так, что вы, как руководитель, неудовлетворены, но вы должны подать информацию таким образом, чтобы и люди понимали, что им тоже не очень хорошо от текущей ситуации. Может быть, сейчас не очень хорошо, но они просто привыкли. А может, в будущем будет плохо, если всё так продолжится, как сейчас.
Видение будущего
Возможно, кого-то вдохновляют рассказы про космические корабли, бороздящие Большой театр. Я же хотел бы слышать несколько более конкретные вещи. Не то что я начинаю сразу «а на какую именно метрику это повлияет и на сколько?», просто хотелось бы понимать, что именно изменится, а не абстрактную воду про «станет эффективнее и прозрачнее». Здесь хорошо бы сделать отсылку к предыдущему пункту и к Саше Брызгаловой, которая любит повторять: «Если это решение, то в чем проблема?».
Первые шаги
Практически всех пугает большое и долгое изменение привычного образа жизни и работы. Но если вы сможете его раздробить на простые шаги и показать, что для начала достаточно всего лишь не сильно-то поменять один привычный паттерн, чтобы уже стало лучше, то это укрепит ваше предложение в глазах тех, кого вы хотите «напрячь». Если при этом окажется удачной связка: первые легкие шаги – первые собранные низковисящие фрукты, то доверие к вашим предложениям сильно укрепится и саботаж вряд ли произойдет.
Итог
Самый простой и, казалось бы, очевидный (но не всегда), способ что-то поменять у людей — показать, почему это вам и им нужно, что именно изменится и как легко начать эти изменения получать. Дальше уже у вас будет кредит доверия, смотрите не продолбайте его, если вдруг вы решили, что надо ограничиться только обещаниями 🙂 Обещания должны или совпасть с результатами, или вы должны объяснить, почему они не совпали и что теперь делать с этим.
Есть много разных фреймворков про внедрение изменений, но вы знаете, что я люблю, чтобы было просто и достаточно работоспособно. Вот один из таких вариантов — формула Бекхарда.
Сама формула:
D × V × F > R
D — неудовлетворенность текущей ситуацией (dissatisfaction);
V — видение будущего (vision);
F — первые конкретные шаги, которые могут быть предприняты для реализации видения (first steps);
R — сопротивление изменениям (resistance).
Всего лишь 3 самых важных компонента, которые надо учесть и правильным образом подогреть.
Неудовлетворенность текущей ситуацией
Как следует из названия — кто-то должен быть неудовлетворен ситуацией. Нередко изменения внедряются, потому что кто-то сверху неудовлетворен, снизу всем всё и так хорошо, но оно через силу пихается. А потом руководство расстраивается, что люди на местах — несговорчивые саботажники, а работники — что руководство самодурствует.
Да, может быть так, что вы, как руководитель, неудовлетворены, но вы должны подать информацию таким образом, чтобы и люди понимали, что им тоже не очень хорошо от текущей ситуации. Может быть, сейчас не очень хорошо, но они просто привыкли. А может, в будущем будет плохо, если всё так продолжится, как сейчас.
Видение будущего
Возможно, кого-то вдохновляют рассказы про космические корабли, бороздящие Большой театр. Я же хотел бы слышать несколько более конкретные вещи. Не то что я начинаю сразу «а на какую именно метрику это повлияет и на сколько?», просто хотелось бы понимать, что именно изменится, а не абстрактную воду про «станет эффективнее и прозрачнее». Здесь хорошо бы сделать отсылку к предыдущему пункту и к Саше Брызгаловой, которая любит повторять: «Если это решение, то в чем проблема?».
Первые шаги
Практически всех пугает большое и долгое изменение привычного образа жизни и работы. Но если вы сможете его раздробить на простые шаги и показать, что для начала достаточно всего лишь не сильно-то поменять один привычный паттерн, чтобы уже стало лучше, то это укрепит ваше предложение в глазах тех, кого вы хотите «напрячь». Если при этом окажется удачной связка: первые легкие шаги – первые собранные низковисящие фрукты, то доверие к вашим предложениям сильно укрепится и саботаж вряд ли произойдет.
Итог
Самый простой и, казалось бы, очевидный (но не всегда), способ что-то поменять у людей — показать, почему это вам и им нужно, что именно изменится и как легко начать эти изменения получать. Дальше уже у вас будет кредит доверия, смотрите не продолбайте его, если вдруг вы решили, что надо ограничиться только обещаниями 🙂 Обещания должны или совпасть с результатами, или вы должны объяснить, почему они не совпали и что теперь делать с этим.
Forwarded from Статистика и R в науке и аналитике
p-value, альфа и ошибка первого рода: как не перепутать
Это будет простой теоретический разбор ключевых понятий в статистике.
Для разогрева я спрятала под спойлер определения, попробуйте их распределить самостоятельно и ответить, как они связаны между собой.
alpha – верхняя граница вероятности ошибки первого рода.
p-value – вероятность найти такие же или еще более экстремальные значения тестовой статистики при условии верности нулевой гипотезы.
ошибка первого рода – отвергли нулевую гипотезу, когда она была верна (например, нашли отличия, там где их на самом деле нет).
А как они связаны между собой?
1. Мы сравниваем p-value с альфой, чтобы отвергнуть или не отвергнуть нулевую гипотезу.
2. При проведении множества независимых тестов с верностью нулевой гипотезы ожидаемая доля ошибок первого рода не превышает заданную альфу. Например, если мы проводим 100 A/A-тестов с α = 0.05, то в среднем примерно в 5 тестах мы отвергнем H₀ (то есть сделаем ошибку первого рода).
Важно: в конкретном тесте мы никогда не знаем, совершили ли ошибку первого рода (это уже случилось или нет). Но когда мы фиксируем альфу заранее, мы контролируем долгосрочную частоту таких ошибок — при большом числе повторений она будет близка к α (но есть нюансы, подробнее ниже).
3. Следствие: чем меньше альфа, тем реже будет ошибка первого рода. Однако при этом увеличится ошибка второго рода, всегда приходится балансировать между двумя типами ошибок.
Нюанс: в реальной жизни альфа не всегда совпадает с фактической вероятностью ошибки первого рода (ошибка бывает больше). Когда это происходит и как этого избежать?
🟡 Множественные сравнения
При тестировании множества гипотез (несколько групп, метрик) возрастает вероятность совершить хотя бы одну ошибку первого рода. Если не делать поправку, то мы уже не контролируем альфа на заданном уровне.
Решение: использовать поправки на множественные сравнения (Бонферрони, Холм, FDR) в зависимости от задачи. Более подробно можно почитать здесь.
🟡 Подглядывание в A/B тесты
Если мы многократно проверяем результаты A/B теста и останавливаем эксперимент при первом p-value < 0.05, это эквивалентно множественным проверкам гипотез и приводит к завышению ошибки первого рода.
Решение: использовать методы sequential testing.
🟡 Не выполнены предпосылки теста
Например, используем t-тест Стьюдента (не Велча) для выборок с разной дисперсией и разного объема, в результате мы можем сильно завысить уровень ошибки первого рода, подробнее здесь.
Решение: использовать тест Велча.
Другие примеры, когда ошибка первого рода возрастает в случае несоблюдения предпосылок теста, предлагаю накидать в комментарии.
Подсказка: это может быть связано с одной из любимых тем на этом канале)
Пишите в комментариях, не путаете ли вы термины, и сталкивались ли с ситуациями, когда ошибка первого рода превышала альфу.
#stats #stat_hard #analytics
Это будет простой теоретический разбор ключевых понятий в статистике.
Для разогрева я спрятала под спойлер определения, попробуйте их распределить самостоятельно и ответить, как они связаны между собой.
А как они связаны между собой?
1. Мы сравниваем p-value с альфой, чтобы отвергнуть или не отвергнуть нулевую гипотезу.
2. При проведении множества независимых тестов с верностью нулевой гипотезы ожидаемая доля ошибок первого рода не превышает заданную альфу. Например, если мы проводим 100 A/A-тестов с α = 0.05, то в среднем примерно в 5 тестах мы отвергнем H₀ (то есть сделаем ошибку первого рода).
Важно: в конкретном тесте мы никогда не знаем, совершили ли ошибку первого рода (это уже случилось или нет). Но когда мы фиксируем альфу заранее, мы контролируем долгосрочную частоту таких ошибок — при большом числе повторений она будет близка к α (но есть нюансы, подробнее ниже).
3. Следствие: чем меньше альфа, тем реже будет ошибка первого рода. Однако при этом увеличится ошибка второго рода, всегда приходится балансировать между двумя типами ошибок.
Нюанс: в реальной жизни альфа не всегда совпадает с фактической вероятностью ошибки первого рода (ошибка бывает больше). Когда это происходит и как этого избежать?
При тестировании множества гипотез (несколько групп, метрик) возрастает вероятность совершить хотя бы одну ошибку первого рода. Если не делать поправку, то мы уже не контролируем альфа на заданном уровне.
Решение: использовать поправки на множественные сравнения (Бонферрони, Холм, FDR) в зависимости от задачи. Более подробно можно почитать здесь.
Если мы многократно проверяем результаты A/B теста и останавливаем эксперимент при первом p-value < 0.05, это эквивалентно множественным проверкам гипотез и приводит к завышению ошибки первого рода.
Решение: использовать методы sequential testing.
Например, используем t-тест Стьюдента (не Велча) для выборок с разной дисперсией и разного объема, в результате мы можем сильно завысить уровень ошибки первого рода, подробнее здесь.
Решение: использовать тест Велча.
Другие примеры, когда ошибка первого рода возрастает в случае несоблюдения предпосылок теста, предлагаю накидать в комментарии.
Подсказка: это может быть связано с одной из любимых тем на этом канале)
Пишите в комментариях, не путаете ли вы термины, и сталкивались ли с ситуациями, когда ошибка первого рода превышала альфу.
#stats #stat_hard #analytics
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Заскуль питона (Аналитика данных)
Проблемы с фокусом во время работы — это не лень
Вы погружены в задачу, хочется ее решить.
Голова работает.
Но...
1️⃣ Вас выдергивают на важные встречи.
2️⃣ Вам спамят личку и спрашивают, какой статус по задаче
3️⃣ Вы думаете, что задачу нужно отдать идеально
4️⃣ Вы переключились на другую вкладку и в итоге забыли, зачем открывали
5️⃣ Параллельно вы начали делать другую задачу
И под конец рабочего дня задача не сделана, вы устали, чувствуете вину
Фокус ломается не из-за лени, а из-за среды и когнитивной перегрузки. Это проблема неправильной организации внимания.
🟢 Должен быть четкий объект фокуса. Нужно себе ответить на вопрос, над чем сейчас работаешь, чтобы явно себе понять, на чем нужно сфокусироваться.
🟢 Отключить ненужные уведомления. Нам кажется, что мы постоянно должны впитывать любую информацию. Но любая информация — это потеря фокуса на основных задачах 🔕
🟢 Выбрать оптимальную технику для фокуса. Это может быть Pomodoro, Deep Work, Pomodoro 2.0 даже. Техники бывают разные, в Яндексе я старался работать по Deep Work и это было эффективно. Сейчас выбираю для себя Pomodoro 🍅
🟢 Убрать мелкие выборы. Иногда себя ловлю на мысли о том, а какую вкладку нужно открыть (особенно, когда их много). Ранее слышал, что любое принятие решение тратит когнитивные силы, поэтому убираем 🤔
🟢 Фиксировать момент потери фокуса. Вы отвлеклись на другое дело? Это важно, потому что фокус теряется не случайно.
📺 Кстати, у Андрея было классное видео про то, как он вернул себе фокус на задачах
Еще из прикольного: там говорится о разгрузке мозга с помощью любого текстового документа, физическую активность...
📕 В видео еще было упомянуто про исследование, в котором говорится о том, что постоянное переключение между потоками информации делает мозг менее способным сосредотачиваться и игнорировать отвлекающие раздражители, что ухудшает когнитивный контроль и рабочую эффективность. Интересно, что на некоторых местах работы считалось базой делать несколько задач одновременно. Все теперь понятно...
А как у вас с фокусом? Теряетесь или все в порядке? Ставьте🐳 , если пост понравился, делитесь с теми, у кого проблемы с фокусом
@zasql_python
Вы погружены в задачу, хочется ее решить.
Голова работает.
Но...
И под конец рабочего дня задача не сделана, вы устали, чувствуете вину
Фокус ломается не из-за лени, а из-за среды и когнитивной перегрузки. Это проблема неправильной организации внимания.
Еще из прикольного: там говорится о разгрузке мозга с помощью любого текстового документа, физическую активность...
А как у вас с фокусом? Теряетесь или все в порядке? Ставьте
@zasql_python
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from LLM под капотом
Я попробовал Linear, который OpenAI использует вместо JIRA для разработки
(еще его использует Cursor, Coinbase, Vercel, Perplexity, Substack, Lovable и Polymarket)
Linear выглядит как нормальная и удобная JIRA для разработки проектов (таски, проекты итп). Быстрая и легкая. Но там есть нативная интеграция для делегирования задач кодексу, которая настроилась в пару кликов. И получается, что я могу вести задачи в смешанной команде людей и агентов, раскидывая задачи между кодексом и людьми.
Кодекс при получении задачи браво рапортует в комментариях, запускает весь процесс, линкует прогресс (или возвращается с вопросами). А после выполнения задачи, когда я просмотрел PR и отправил его в main, Linear перетаскивает задачу в выполненное.
И вот это ощущение от интеграции масштабируемых агентов в старый и знакомый процесс разработки - второй слом моего мозга в этом году (первый).
Пару скриншотов кину в комментарии. Но внешне там нет ничего особенного, вся фишка от ощущения масштабирования процесса!
Ваш, @llm_under_hood 🤗
PS: Если вдруг забанило в комментариях после вступления - это нормально. Валидацию я переделываю, скоро поправим.
(еще его использует Cursor, Coinbase, Vercel, Perplexity, Substack, Lovable и Polymarket)
Linear выглядит как нормальная и удобная JIRA для разработки проектов (таски, проекты итп). Быстрая и легкая. Но там есть нативная интеграция для делегирования задач кодексу, которая настроилась в пару кликов. И получается, что я могу вести задачи в смешанной команде людей и агентов, раскидывая задачи между кодексом и людьми.
Кодекс при получении задачи браво рапортует в комментариях, запускает весь процесс, линкует прогресс (или возвращается с вопросами). А после выполнения задачи, когда я просмотрел PR и отправил его в main, Linear перетаскивает задачу в выполненное.
И вот это ощущение от интеграции масштабируемых агентов в старый и знакомый процесс разработки - второй слом моего мозга в этом году (первый).
Пару скриншотов кину в комментарии. Но внешне там нет ничего особенного, вся фишка от ощущения масштабирования процесса!
Ваш, @llm_under_hood 🤗
PS: Если вдруг забанило в комментариях после вступления - это нормально. Валидацию я переделываю, скоро поправим.
Forwarded from АННА В ДАННЫХ
Как в компаниях борются с тяжелыми запросами ⌨️
Существуют разные подходы к тому, чтобы не случилось мемной ситуации, когда аналитик случайно положил базу
Как правило аналитики не имеют доступа к продовой БД и работают в аналитических репликах, но плохой запрос там может помешать обновлению дашбордов, загрузке витрин и работе коллег
🔵 Автоматические лимиты в СУБД
Например, по времени выполнения или объему потребляемой памяти. При превышении запрос упадет с ошибкой, и аналитику ничего не останется, кроме как оптимизировать его
🔵 Киллеры плохих запросов
Может существовать скрипт с более гибкими и сложными условиями, который сканирует выполняющиеся запросы и “убивает” все подозрительные
🔵 Социальное давление или доска позора
Тогда явных ограничений может и не быть, но каждый аналитик знает: если из-за его запроса все начнет виснуть, админы опубликуют его в общий доступ с очень неприятной припиской. Опасаясь общественного порицания, аналитики пускают в ход все свои знания об оптимизации запросов
🔵 Другая версия этого - полная прозрачность
Когда каждый может посмотреть содержимое и авторов выполняющихся сейчас запросов. И в личку к виновнику сразу повалят его коллеги
🔵 Запрет доступа к сырым данным
Могут ограничить доступ к гигантским сырым таблицам для отдельных ролей, а дать только к витринам с уже агрегированными данными. Это избавляет от лишних вычислений и сокращает количество обрабатываемых строк
А какой подход выбран у вас в компании и какой предпочли бы?
Существуют разные подходы к тому, чтобы не случилось мемной ситуации, когда аналитик случайно положил базу
Например, по времени выполнения или объему потребляемой памяти. При превышении запрос упадет с ошибкой, и аналитику ничего не останется, кроме как оптимизировать его
Может существовать скрипт с более гибкими и сложными условиями, который сканирует выполняющиеся запросы и “убивает” все подозрительные
Тогда явных ограничений может и не быть, но каждый аналитик знает: если из-за его запроса все начнет виснуть, админы опубликуют его в общий доступ с очень неприятной припиской. Опасаясь общественного порицания, аналитики пускают в ход все свои знания об оптимизации запросов
Когда каждый может посмотреть содержимое и авторов выполняющихся сейчас запросов. И в личку к виновнику сразу повалят его коллеги
Могут ограничить доступ к гигантским сырым таблицам для отдельных ролей, а дать только к витринам с уже агрегированными данными. Это избавляет от лишних вычислений и сокращает количество обрабатываемых строк
А какой подход выбран у вас в компании и какой предпочли бы?
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Заметки LLM-энтузиаста
Обратите внимание на интересные функции Kilo Code
- App Builder (по сути, можно заменить функциональность bolt.new или lovable.dev - пока только фронтенд часть, но зато можно выбирать модели, и топовые "китайцы" сейчас бесплатные). Функциональность вышла прямо "под Новый Год"
- Deploy (можно сразу разворачивать next.js проекты)
Также используя комбинацию Cloud Agent + Sessions + Webhooks + Code Reviewer + Deploy можно выстроить AI-driven CI/CD пайплайн (как Github Actions, только с AI-"маршрутизацией")
При этом как в Roo Cloud есть возможность перехватывать сессию разработки, которая велась на локальном ПК
Также как в Claude Code есть свой Kilocode CLI, есть возможность использовать AGENTS.md файл и каталог со SKILLS (можно выбрать из библиотеки или создать собственный - skill builder прилагается), можно запускать агентов параллельно для ускорения разработки.
В общем, мне кажется, что если выбирать сейчас между Roo Code/Cline и Kilo Code, то Kilo Code лидирует (тем более, что в нем также как и в Roo Code теперь можно подключить Claude Max план)
Подробности есть в документации https://kilo.ai/docs
#kilocode #vibecoding
- App Builder (по сути, можно заменить функциональность bolt.new или lovable.dev - пока только фронтенд часть, но зато можно выбирать модели, и топовые "китайцы" сейчас бесплатные). Функциональность вышла прямо "под Новый Год"
- Deploy (можно сразу разворачивать next.js проекты)
Также используя комбинацию Cloud Agent + Sessions + Webhooks + Code Reviewer + Deploy можно выстроить AI-driven CI/CD пайплайн (как Github Actions, только с AI-"маршрутизацией")
При этом как в Roo Cloud есть возможность перехватывать сессию разработки, которая велась на локальном ПК
Также как в Claude Code есть свой Kilocode CLI, есть возможность использовать AGENTS.md файл и каталог со SKILLS (можно выбрать из библиотеки или создать собственный - skill builder прилагается), можно запускать агентов параллельно для ускорения разработки.
В общем, мне кажется, что если выбирать сейчас между Roo Code/Cline и Kilo Code, то Kilo Code лидирует (тем более, что в нем также как и в Roo Code теперь можно подключить Claude Max план)
Подробности есть в документации https://kilo.ai/docs
#kilocode #vibecoding
Forwarded from commit history
Как попробовать Claude Opus 4.5 и другие модели в CLI-агенте бесплатно
За последние полтора года из первого ряда наблюдал как сильно выросли способности моделей в формате кодинг агентов. При этом кто-то еще не пробовал сделать проект просто агентами, без погружения в код, хотя желание есть.
Не у всех есть enterprise-подписка на Codex, Claude или Cursor, либо лишние $100–200 в месяц. При этом $10 в том же Cursor выедаются довольно быстро, если запускать агента на задачах чуть сложнее простых автокомплитов.
Фронтирные модели уже нормально работают в агентских обвязках. На бенчмарках топовые модели идут примерно на одном уровне, на последнем ребенче например лидирует Opus. При этом сами агентские скаффолды сходятся к одному и тому же набору инструментов, поэтому можно спокойно пробовать разные cli агенты, не переживая, что они сильно отличаются.
Есть такой очередной агент/обвязка. AMP Code.
Они дают $10 в день, взамен показывают рекламу. Реклама ненавязчивая, просто висит над окном ввода.
Есть плагины почти для всего: VS Code, JetBrains, Neovim. Я пользуюсь CLI-версией.
https://ampcode.com/install
P.S.
Когда появляется такой инструмент, сначала может быть непонятно, что с ним делать. Поэтому для тестового запуска я всегда прошу реализовать браузерный Doom. В школе 21 этот проект раньше был в конце ветки геймдева.
В итоге вышло около $2 из суточных $10 за 1.5 млн токенов.
Тут можно посмотреть, какая траектория получилась:
https://ampcode.com/threads/T-019bcc0d-7ac8-710a-a273-8513be37694e
За последние полтора года из первого ряда наблюдал как сильно выросли способности моделей в формате кодинг агентов. При этом кто-то еще не пробовал сделать проект просто агентами, без погружения в код, хотя желание есть.
Не у всех есть enterprise-подписка на Codex, Claude или Cursor, либо лишние $100–200 в месяц. При этом $10 в том же Cursor выедаются довольно быстро, если запускать агента на задачах чуть сложнее простых автокомплитов.
Фронтирные модели уже нормально работают в агентских обвязках. На бенчмарках топовые модели идут примерно на одном уровне, на последнем ребенче например лидирует Opus. При этом сами агентские скаффолды сходятся к одному и тому же набору инструментов, поэтому можно спокойно пробовать разные cli агенты, не переживая, что они сильно отличаются.
Есть такой очередной агент/обвязка. AMP Code.
Они дают $10 в день, взамен показывают рекламу. Реклама ненавязчивая, просто висит над окном ввода.
Есть плагины почти для всего: VS Code, JetBrains, Neovim. Я пользуюсь CLI-версией.
https://ampcode.com/install
P.S.
Когда появляется такой инструмент, сначала может быть непонятно, что с ним делать. Поэтому для тестового запуска я всегда прошу реализовать браузерный Doom. В школе 21 этот проект раньше был в конце ветки геймдева.
В итоге вышло около $2 из суточных $10 за 1.5 млн токенов.
Тут можно посмотреть, какая траектория получилась:
https://ampcode.com/threads/T-019bcc0d-7ac8-710a-a273-8513be37694e
Ampcode
Doom 3D clone TypeScript project plan
Forwarded from Персонализация неизбежна
vklsd_presentation.pdf
2.1 MB
Моё решение — 5/216 место на VK RecSys Challenge LSVD
Мне было интересно снова поучаствовать в соревновании, чтобы проверить некоторые идеи, поучить Polars и поразвивать интуицию вокруг RecSys. Ниже кратко напишу про результаты.
Задача: нужно было предсказать 100 пользователей, которые лайкнут клип VK Видео, причём с самим клипом в истории нет взаимодействий.
Бейзлайн: будем «рекомендовать» тех юзеров, которые уже лайкали автора в прошлом. Сортируем по сумме лайков. Это уже ~30/216 место.
Решение: возьмём всех юзеров, которые видели автора клипа, и отсортируем их с помощью LGBMRanker. Подробнее — в презентации.
Чего было у тех, кто выше, но не было у меня: трансформер, DCN, SANSA, CatBoost. Я не смог это качественно заиспользовать.
Чем хочется поделиться:
1) Я использовал идею из поста 2023 года канала Wazowski Recommends с экспоненциальными счётчиками, чтобы «переварить» все данные. Для расчёта фичей я использовал словари в словарях в Python с помощью кода на ~500 строк, который мне полностью написала ChatGPT. Грубо говоря, я пробежался for-циклом по всему датасету и с экспоненциальным затуханием насчитал все фичи без даталиков.
2) Всех юзеров я разбил по user_id % M == k и работал только с выбранной пачкой (простое шардирование), что позволило гибко настраивать trade-off «скорость vs RAM». Это был ключевой шаг, чтобы обработать все данные.
3) Я пытался искусственно побить клипы на кластеры по контенту и насчитать фичи, но это оказалось бесполезным занятием. У меня есть теория, что когда ты создаёшь группировку user/item на основе контента, но такой группировки не существует в самом сервисе, — это бесполезно для качества.
Например, если мы рекомендуем продукты питания, у нас есть категоризация сервиса и фичи вида user–category. Категории существуют в каталоге → фичи значимые. Если же мы создадим semantic id и посчитаем фичи вида user–semantic-id, эти фичи дадут меньший эффект, чем user–category.
4) Задача подбора аудитории в целом — это во многом история про борьбу за активных людей. Если у вас есть приложение, в котором вы показываете баннер, и вы спросите: кто кликнет на него завтра? Я бы собрал аудиторию из самых активных пользователей приложения. Если отправлять email и собирать аудиторию, кто его прочитает, — это те, кто чаще всего читает email. Тут никакой RecSys / ML не нужен.
И здесь есть тонкая грань между персонализацией и простой эксплуатацией самого активного ядра юзеров под любые нужды. Недаром авторы RecSys Challenge поставили ограничение, что нельзя выбирать одного юзера 101+ раз.
5) Соревнование для меня — во многом про аккуратность, правильную приоритизацию гипотез и доведение их проверки до конца. Также важны тайм-менеджмент, готовность полностью погружаться в эксперименты и терпимость к тому, что очередная идея не улучшает результат.
В общем, участие оказалось очень полезным, всем советую попробовать себя в соревнованиях по Recsys)
Мне было интересно снова поучаствовать в соревновании, чтобы проверить некоторые идеи, поучить Polars и поразвивать интуицию вокруг RecSys. Ниже кратко напишу про результаты.
Задача: нужно было предсказать 100 пользователей, которые лайкнут клип VK Видео, причём с самим клипом в истории нет взаимодействий.
Бейзлайн: будем «рекомендовать» тех юзеров, которые уже лайкали автора в прошлом. Сортируем по сумме лайков. Это уже ~30/216 место.
Решение: возьмём всех юзеров, которые видели автора клипа, и отсортируем их с помощью LGBMRanker. Подробнее — в презентации.
Чего было у тех, кто выше, но не было у меня: трансформер, DCN, SANSA, CatBoost. Я не смог это качественно заиспользовать.
Чем хочется поделиться:
1) Я использовал идею из поста 2023 года канала Wazowski Recommends с экспоненциальными счётчиками, чтобы «переварить» все данные. Для расчёта фичей я использовал словари в словарях в Python с помощью кода на ~500 строк, который мне полностью написала ChatGPT. Грубо говоря, я пробежался for-циклом по всему датасету и с экспоненциальным затуханием насчитал все фичи без даталиков.
2) Всех юзеров я разбил по user_id % M == k и работал только с выбранной пачкой (простое шардирование), что позволило гибко настраивать trade-off «скорость vs RAM». Это был ключевой шаг, чтобы обработать все данные.
3) Я пытался искусственно побить клипы на кластеры по контенту и насчитать фичи, но это оказалось бесполезным занятием. У меня есть теория, что когда ты создаёшь группировку user/item на основе контента, но такой группировки не существует в самом сервисе, — это бесполезно для качества.
Например, если мы рекомендуем продукты питания, у нас есть категоризация сервиса и фичи вида user–category. Категории существуют в каталоге → фичи значимые. Если же мы создадим semantic id и посчитаем фичи вида user–semantic-id, эти фичи дадут меньший эффект, чем user–category.
4) Задача подбора аудитории в целом — это во многом история про борьбу за активных людей. Если у вас есть приложение, в котором вы показываете баннер, и вы спросите: кто кликнет на него завтра? Я бы собрал аудиторию из самых активных пользователей приложения. Если отправлять email и собирать аудиторию, кто его прочитает, — это те, кто чаще всего читает email. Тут никакой RecSys / ML не нужен.
И здесь есть тонкая грань между персонализацией и простой эксплуатацией самого активного ядра юзеров под любые нужды. Недаром авторы RecSys Challenge поставили ограничение, что нельзя выбирать одного юзера 101+ раз.
5) Соревнование для меня — во многом про аккуратность, правильную приоритизацию гипотез и доведение их проверки до конца. Также важны тайм-менеджмент, готовность полностью погружаться в эксперименты и терпимость к тому, что очередная идея не улучшает результат.
В общем, участие оказалось очень полезным, всем советую попробовать себя в соревнованиях по Recsys)
Forwarded from AI, больно! | Рома Филонов
Выкладываю ДВУХ часовое видео с разбором самых популярных вопросов по с СОБЕСЕДОВАНИЙ нейросеткам, торчу и компьютерному зрению.
Решил почему бы не оцифровать свои знания, если в беседах 1-1 это помогает людям, то пусть сразу всем будет доступно.
Разобрал там вопросы про (краткая выжимка):
И МНОГО ВСЕГО ДРУГОГО
СМОТРЕТЬ ТУТ:
ССЫЛКА
ССЫЛКА
ССЫЛКА
При его записи у меня открылась третья чакра(поехала крыша) и пошли нон-стоп идеи, что еще можно позаписывать и поделать. Если у вас тоже есть желание, увидеть что-то конкретное, то пишите в комментах тут
Практиковаться с впоросами можно ТУТ
Please open Telegram to view this post
VIEW IN TELEGRAM
BotayInterview
Как пройти собеседование в Яндекс, Сбер, Тинькофф, Т-Банк | BotayInterview
Узнай, как пройти собес в топовых компаниях. База собесов с реальными вопросами, mock interview с ИИ, подготовка к собеседованиям по ML и Python.
Forwarded from Awesome DL
How to build your search engine?
Понимание бэкенда + архитектуры помогает делать ваш вайбкод one-shot готовым решением. Поэтому я люблю читать блоги про о том, как создается архитектура разных приложений - так нарабатывается насмотренность для решения архитектурых задач. А тут бац, и человек собрал свой поисковик с 0 нуля и рассказал все нюансы создания:
- как парсить данные
- как их готовить
- как их хранить
- как эффективно инференсить поисковик, чтобы не ждать вечность
- и сделать своё ai overview
Сохраняйте и читайте🔖
Понимание бэкенда + архитектуры помогает делать ваш вайбкод one-shot готовым решением. Поэтому я люблю читать блоги про о том, как создается архитектура разных приложений - так нарабатывается насмотренность для решения архитектурых задач. А тут бац, и человек собрал свой поисковик с 0 нуля и рассказал все нюансы создания:
- как парсить данные
- как их готовить
- как их хранить
- как эффективно инференсить поисковик, чтобы не ждать вечность
- и сделать своё ai overview
Сохраняйте и читайте
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Андрей Созыкин (Andrey Sozykin)
LeetСode Study Plan SQL 50
Как я провеллето длинные зимние каникулы – решал задачки по SQL с LeetСode из SQL 50 Study Plan.
Study Plan'ы на LeetСode сделали достаточно давно, но я их открыл только перед новым годом 🤦♂️. Это коллекции задачек по заданной технологии, сгруппированных по темам и уровням. Я когда-то записывал видео с разбором задач по SQL c LeetСode, но тогда Study Plan еще не было. И в целом задач по SQL на LeetСode было не очень много. Поэтому видео получилось мало и по тематике они были разбросаны.
В плане SQL 50, как можно понять из названия, 50 задач по SQL. Что важно, все задачи бесплатные. По уровню задачи рассчитаны от начинающего до продвинутого (basic to intermediate). Задачи разбиты по темам:
- SELECT.
- Базовые JOIN'ы.
- Базовые функции агрегации.
- Сортировка и группировка.
- Продвинутые SELECT'ы и JOIN'ы.
- Подзапросы.
- Продвинутые функции для обработки срок и регулярные выражения.
Задачи в основном уровня Easy (32 штуки) и Medium (17 штук), уровня Hard всего одна задача. Причем Hard не очень сложная, в ней нужно применить много различных особенностей SQL одновременно, но особых хитростей нет. Над многими задачами уровня Medium я думал значительно дольше, чем над хардовой задачей.
В целом особенность задач по SQL на LeetСode в том, что почти все содержат хотя бы небольшие, но хитрости. Поэтому даже над простыми задачами приходится задумываться и решение получается не сразу. Зато значительно лучше понимаешь, как действительно работает SQL и как его применять для практических задач с реальными ограничениями.
За каникулы успел решить все задачи из SQL 50. Для их решения почти достаточно моего курса по SQL. Не хватает следующих тем:
- Условный оператор CASE.
- Работа с NULL, в том числе COALESCE.
- Функции работы с датами, строками, регулярными выражениями и т.п.
Также будут полезны CTE, но их использовать не обязательно.
Рекомендую решить SQL 50, если вы начинаете изучать SQL, или хотите его вспомнить для подготовки к собеседованию. Я сам дальше планирую решать на LeetCode задачи уровня Hard. А также задачи на оконные функции, т.к. их в SQL 50 не было.
На LeetCode также есть продвинутый Study Plan Advanced SQL 50, но он только за деньги 😞. Из полезного еще есть два Study Plan'а по Pandas: Introduction to Pandas и 30 Days of Pandas. Недостаток – в них много задачек из SQL 50, но решать их нужно не с помощью SQL, а в Pandas. Код на Pandas написать полезно, но думать второй раз над задачкой уже не придется...
Как я провел
Study Plan'ы на LeetСode сделали достаточно давно, но я их открыл только перед новым годом 🤦♂️. Это коллекции задачек по заданной технологии, сгруппированных по темам и уровням. Я когда-то записывал видео с разбором задач по SQL c LeetСode, но тогда Study Plan еще не было. И в целом задач по SQL на LeetСode было не очень много. Поэтому видео получилось мало и по тематике они были разбросаны.
В плане SQL 50, как можно понять из названия, 50 задач по SQL. Что важно, все задачи бесплатные. По уровню задачи рассчитаны от начинающего до продвинутого (basic to intermediate). Задачи разбиты по темам:
- SELECT.
- Базовые JOIN'ы.
- Базовые функции агрегации.
- Сортировка и группировка.
- Продвинутые SELECT'ы и JOIN'ы.
- Подзапросы.
- Продвинутые функции для обработки срок и регулярные выражения.
Задачи в основном уровня Easy (32 штуки) и Medium (17 штук), уровня Hard всего одна задача. Причем Hard не очень сложная, в ней нужно применить много различных особенностей SQL одновременно, но особых хитростей нет. Над многими задачами уровня Medium я думал значительно дольше, чем над хардовой задачей.
В целом особенность задач по SQL на LeetСode в том, что почти все содержат хотя бы небольшие, но хитрости. Поэтому даже над простыми задачами приходится задумываться и решение получается не сразу. Зато значительно лучше понимаешь, как действительно работает SQL и как его применять для практических задач с реальными ограничениями.
За каникулы успел решить все задачи из SQL 50. Для их решения почти достаточно моего курса по SQL. Не хватает следующих тем:
- Условный оператор CASE.
- Работа с NULL, в том числе COALESCE.
- Функции работы с датами, строками, регулярными выражениями и т.п.
Также будут полезны CTE, но их использовать не обязательно.
Рекомендую решить SQL 50, если вы начинаете изучать SQL, или хотите его вспомнить для подготовки к собеседованию. Я сам дальше планирую решать на LeetCode задачи уровня Hard. А также задачи на оконные функции, т.к. их в SQL 50 не было.
На LeetCode также есть продвинутый Study Plan Advanced SQL 50, но он только за деньги 😞. Из полезного еще есть два Study Plan'а по Pandas: Introduction to Pandas и 30 Days of Pandas. Недостаток – в них много задачек из SQL 50, но решать их нужно не с помощью SQL, а в Pandas. Код на Pandas написать полезно, но думать второй раз над задачкой уже не придется...