Когда пытался выкрутить serendipity на максимум, но не выкрутилось , да еще что-то пошло не так 😁
1😁23👍1
Forwarded from Neural Shit
Наткнулся на интересную статью. Это буквально самый тупой (и одновременно гениальный) промпт-хак.
Исследователи из Google Research выяснили, что если нейронка тупит, не надо придумывать сложные цепочки рассуждений или молиться духам машины. Нужно просто повторить промпт два раза подряд. Буквально CTRL+C —> CTRL+V.
Почему? Почти все современные LLM читают слева направо. Токены в начале промпта "не видят" токенов в конце. А когда вы дублируете запрос, вторая копия промпта через механизм внимания может смотреть на первую копию целиком. Получается, что модель сразу видит весь контекст и лучше понимает задачу.
Протестили на Gemini, GPT-4o, Claude 3 и DeepSeek. По цифрам из статьи:
— Метод победил в 47 из 70 тестов (0 поражений, остальные — ничья).
— В задачах на поиск инфы в тексте точность взлетала с убогих 21% до 97%!
— Время генерации не растет
И да, работает это только на моделях с выключенным режимом размышлений, ибо модели в reasoning режиме сами повторяют себе запрос в процессе.
Промпт-инжиниринг, который мы заслужили
тут статья
Исследователи из Google Research выяснили, что если нейронка тупит, не надо придумывать сложные цепочки рассуждений или молиться духам машины. Нужно просто повторить промпт два раза подряд. Буквально CTRL+C —> CTRL+V.
Почему? Почти все современные LLM читают слева направо. Токены в начале промпта "не видят" токенов в конце. А когда вы дублируете запрос, вторая копия промпта через механизм внимания может смотреть на первую копию целиком. Получается, что модель сразу видит весь контекст и лучше понимает задачу.
Протестили на Gemini, GPT-4o, Claude 3 и DeepSeek. По цифрам из статьи:
— Метод победил в 47 из 70 тестов (0 поражений, остальные — ничья).
— В задачах на поиск инфы в тексте точность взлетала с убогих 21% до 97%!
— Время генерации не растет
И да, работает это только на моделях с выключенным режимом размышлений, ибо модели в reasoning режиме сами повторяют себе запрос в процессе.
Промпт-инжиниринг, который мы заслужили
тут статья
arXiv.org
Prompt Repetition Improves Non-Reasoning LLMs
When not using reasoning, repeating the input prompt improves performance for popular models (Gemini, GPT, Claude, and Deepseek) without increasing the number of generated tokens or latency.
2🤣71❤13🔥10👍3🤷1
будем рады всех видеть вечером субботы! Одно из самых классных в Сергее то что он до сих пор активно участвует в соревнованиях и его точно стоит послушать, даже безотносительно Kaggle. А еще он покажет как решать соревы агентами )
PS Сайт тренировок и их чат
PS Сайт тренировок и их чат
cs.hse.ru
Тренировки по машинному обучению
1👍10❤2
Тренировки по ML
➖ ➖ ➖ ➖ ➖ ➖
1️⃣ 7️⃣ января состоится восьмая встреча в рамках тренировок по машинному обучению ❤️
Что будет:
⚪️ разберём черную магию рандома в соревнованиях из области финансов
⚪️ обсудим почему мл-щики до сих пор не заработали все деньги мирового рынка
⚪️ пробуем использовать kaggle mcp с агентами для проверки гипотез в прямом эфире
📢 Спикер: Сергей Фиронов, Kaggle Competition Grandmaster, ведущий data scientist в Yandex self driving cars
📆 Когда: 17 января с 18:00
🗺️ Где: Покровский бульвар, 11, ауд. R405
Подробнее про челленджи🐭
Студентам других вузов необходимо заполнить форму для заказа пропуска не позднее чем за 24 часа до дня проведения тренировок, по организационным вопросам вы можете обращаться к Марии↩️
#анонсы #студенты #ии
Что будет:
Подробнее про челленджи
Студентам других вузов необходимо заполнить форму для заказа пропуска не позднее чем за 24 часа до дня проведения тренировок, по организационным вопросам вы можете обращаться к Марии
#анонсы #студенты #ии
Please open Telegram to view this post
VIEW IN TELEGRAM
cs.hse.ru
Тренировки по машинному обучению
1👍14❤5🔥5
#корпжиза
У подписчиков могло сложиться впечатление что каналья-манагеры сплошь состоят из продактов и вообще «людей бизнеса».
Однако это не так — в конце концов бизнес нам зп платит, в тч и за свои капризы.
Гораздо брутальнее когда канальи пролезают на позиции технических манагеров.
Причем отбор только по техническим знаниям (а-ля leetcode) скорее вредит
Пару мес назад ребята анонимно прислали перлы своего нового AI-лида, прошедшего суровые алгоритмические этапы, наслаждайтесь:
здесь перестраховываемся во имя анонимности:
У подписчиков могло сложиться впечатление что каналья-манагеры сплошь состоят из продактов и вообще «людей бизнеса».
Однако это не так — в конце концов бизнес нам зп платит, в тч и за свои капризы.
Гораздо брутальнее когда канальи пролезают на позиции технических манагеров.
Причем отбор только по техническим знаниям (а-ля leetcode) скорее вредит
Пару мес назад ребята анонимно прислали перлы своего нового AI-лида, прошедшего суровые алгоритмические этапы, наслаждайтесь:
— Какие метрики важны заказчику?
— Хз, не спрашивал
— Что по железу? Какие будут ограничения? Нам надо понимать, с чего начинать
— Хз, не спрашивал
— Наши текущие задачи и KPI как-то учтены в годовых целях?
— Нет
— Ты с руководством согласовал эти цели?
— Ну я им показал, они промолчали, поэтому считаем что да
— ...
— Надо будет сделать инструмент для другого заказчика
— Мы же не продовая команда, мы не занимаемся продуктивизацией MVP
— ...
— Заказчику нужно простое прикладное решение
— У заказчика ресурсов больше чем у нас, если решение простое, он сделает это быстрее нас
здесь перестраховываемся во имя анонимности:
— Заказчику нужен адаптер для XXX
— Что за XXX?
— Ну база эмбеддингов
— А мы тут причем?
— Мы сделаем адаптер
— Что за адаптер?
— Чтобы получить эмбеддинги
— Это картиночная модель чтобы получить эмбеддинги?
— Возможно, я не знаю
— У вас на днях был созвон по этой теме, что выяснил?
— Мы не успели обсудить, разговаривали про XXX
— Это же не наша тема
— Так получилось
2😁38❤12🙉7🫡3👍2🕊2🔥1😱1
В этом году ODS дата-елку 24 января хостит VK, и я уже буду не спикером, а зрителем, что тоже очень приятно)
Темы как всегда следуют за трендами, Елка — это еще и подведение итогов ушедшего года по ключевым направлениям: RecSys, CodeGen, NLP, Open Source, MLOps & DE, PyData и другим.
В Москве:
- Любимые RecSys - расскажет Вова Байкалов из AI VK - интересно, что поменялось (в том году я пропустил елку, а два года назад сам был спикером про RecSys)
- NLP - традиционно Валя Малых об итогах года
- DS/ML Career - не менее традиционно Антон Воронов, Авито
- (!) Robotics от Сбера -- надеюсь тут услышать про успехи RL
- AI4SE / CodeGen - Дима Бабаев, автор CoLES и библиотеки для обучения транзакционных эмбеддингов ptls, он, кстати, когда-то работал у нас в BigData МТС
В Питере будет больше инженерный трэк — MLOps & DE, Open Source, Healthcare, Rust
Обязательно гляну разбор решений соревы VK RecSys Challenge, хоть и не поучаствовал — в отличии от 800 более мотивированных ребят )
Если кто хочет пересечься — буду рад на площадке в Мск, кто не сможет — можно принять участие офлайн в Питере или посмотреть в трансляции (да-да, она будет)
Регистрация до 22 января, увидимся!
Темы как всегда следуют за трендами, Елка — это еще и подведение итогов ушедшего года по ключевым направлениям: RecSys, CodeGen, NLP, Open Source, MLOps & DE, PyData и другим.
В Москве:
- Любимые RecSys - расскажет Вова Байкалов из AI VK - интересно, что поменялось (в том году я пропустил елку, а два года назад сам был спикером про RecSys)
- NLP - традиционно Валя Малых об итогах года
- DS/ML Career - не менее традиционно Антон Воронов, Авито
- (!) Robotics от Сбера -- надеюсь тут услышать про успехи RL
- AI4SE / CodeGen - Дима Бабаев, автор CoLES и библиотеки для обучения транзакционных эмбеддингов ptls, он, кстати, когда-то работал у нас в BigData МТС
В Питере будет больше инженерный трэк — MLOps & DE, Open Source, Healthcare, Rust
Обязательно гляну разбор решений соревы VK RecSys Challenge, хоть и не поучаствовал — в отличии от 800 более мотивированных ребят )
Если кто хочет пересечься — буду рад на площадке в Мск, кто не сможет — можно принять участие офлайн в Питере или посмотреть в трансляции (да-да, она будет)
Регистрация до 22 января, увидимся!
1👍18❤12👎2🔥1
Попросили разобрать пост про аренду жилья через одну из популярных площадок с позиций DS/ML — как сделать так, чтобы все были довольны.
Канал ведет Никита -- классный аналитик и не менее классный коллега)
Вкратце, схема оплаты: платишь 1/3 площадку как комиссию а остаток напрямую арендодателю, кинуть арендатора супер-легко: отказать в заселении за час до приезда или подсунуть убитую халупу без wifi и горячей воды и пр.
У автора мелькает что гораздо понятнее и надежнее было бы если бы все «проводилось через Авито», еще и с холлом денег до выселения.
Прежде чем начать делать модели, DS немного вникнет в домен:
Если принимать такие предложения в лоб, в идеальном мире автора площадка должна:
⁃ Создать продукт который по сути является покрытым аккредитивом
⁃ Но для него нужна банковская лицензий
⁃ Площадка получает банковскую лицензию (от 1 млрд рублей, бюрократически проще — купить какой-н мелкий банк — см график числа неотозванных лицензий)
⁃ Площадка заводит отделы KYC (и теперь паспорт нужно получать, хранить и обрабатывать площадке объявлений а не только арендодателю), комплаенс, рисков, взаимодействия с регулятором (как минимум, обязательной отчетности)
⁃ Чтобы разбирать обращения клиентов, которые теперь, в случае недовольства, могут обращаться с жалобой в ЦБ, нужно нанимать поддержку и юристов, чтобы не получить оборотный штраф
⁃ ….
Итого, «проводить через площадку» — это несколько млрд затрат при непонятном векторе движения прибыли — действительно, аккредитив еще же и на съемщиков накладывает обязательства — мб число заказов вообще упадет.
Все бы ничего, но у той площадки с 2025 таки есть финтех!
Это, конечно, не банк — а «финансовый маркетплейс» — то есть можно легально заворачивать продукты партнеров.
То есть площадка могла бы предоставить аккредитивы от банков-партнеров
Итого, в съем «квартирки в Питере» была бы вшита
⁃ Комиссия агента (самой площадки обявлений) — и здесь бы лежали косты
⁃ Налоги
⁃ Комиссия банка-партнера за аккредитив
⁃ Выручка арендодателя
Какой порядок комиссии аккредитивов для юрлиц?
Ну вот, например, в Сбере для мелких сделок — от 0.3% суммы сделки, но не менее 15 000 рублей
Повлияло бы на цены аренды, как думаете?
Вообще забавно, как бы решали дорогие юристы крупных организаций спор съемщика и арендодателя насчет сломанной полки / неработающего wifi / горячей воды — раскрывать аккредитив частично или вообще не раскрывать.
Или привлекали компанию-оценщика для определения степени ущерба обоям // разбитую тарелку по остаточной стоимости.
К чему это все
Это тот случай когда корректная юридическая обвязка фин инструментами будет слишком дорогой и накладной бюрократически для всех сторон — площадки (Авито), арендодателя, съемщика.
Чтобы я сделал?
Сделал бы модели, конечно:
⁃ Конфликтности арендрдателя
⁃ Конфликтности съемщика
⁃ Проблем этого конкретного съемщика с этим конкретным арендрдателем
Кстати, многие площадки такие модели закупают, например у нас
Собственно, в таких кейсах ML и работает лучше всего — если сравнивать затраты / результат на ML и на 100% надежное юридическое решение
PS: График построил ChatGPT по источнику
PPS: Вот еще пару прикольных постов у Никиты о том что творится на рынке:
- собес в магнит
- собес в Узум
Канал ведет Никита -- классный аналитик и не менее классный коллега)
Вкратце, схема оплаты: платишь 1/3 площадку как комиссию а остаток напрямую арендодателю, кинуть арендатора супер-легко: отказать в заселении за час до приезда или подсунуть убитую халупу без wifi и горячей воды и пр.
У автора мелькает что гораздо понятнее и надежнее было бы если бы все «проводилось через Авито», еще и с холлом денег до выселения.
Прежде чем начать делать модели, DS немного вникнет в домен:
Если принимать такие предложения в лоб, в идеальном мире автора площадка должна:
⁃ Создать продукт который по сути является покрытым аккредитивом
⁃ Но для него нужна банковская лицензий
⁃ Площадка получает банковскую лицензию (от 1 млрд рублей, бюрократически проще — купить какой-н мелкий банк — см график числа неотозванных лицензий)
⁃ Площадка заводит отделы KYC (и теперь паспорт нужно получать, хранить и обрабатывать площадке объявлений а не только арендодателю), комплаенс, рисков, взаимодействия с регулятором (как минимум, обязательной отчетности)
⁃ Чтобы разбирать обращения клиентов, которые теперь, в случае недовольства, могут обращаться с жалобой в ЦБ, нужно нанимать поддержку и юристов, чтобы не получить оборотный штраф
⁃ ….
Итого, «проводить через площадку» — это несколько млрд затрат при непонятном векторе движения прибыли — действительно, аккредитив еще же и на съемщиков накладывает обязательства — мб число заказов вообще упадет.
Все бы ничего, но у той площадки с 2025 таки есть финтех!
Это, конечно, не банк — а «финансовый маркетплейс» — то есть можно легально заворачивать продукты партнеров.
То есть площадка могла бы предоставить аккредитивы от банков-партнеров
Итого, в съем «квартирки в Питере» была бы вшита
⁃ Комиссия агента (самой площадки обявлений) — и здесь бы лежали косты
⁃ Налоги
⁃ Комиссия банка-партнера за аккредитив
⁃ Выручка арендодателя
Какой порядок комиссии аккредитивов для юрлиц?
Ну вот, например, в Сбере для мелких сделок — от 0.3% суммы сделки, но не менее 15 000 рублей
Повлияло бы на цены аренды, как думаете?
Вообще забавно, как бы решали дорогие юристы крупных организаций спор съемщика и арендодателя насчет сломанной полки / неработающего wifi / горячей воды — раскрывать аккредитив частично или вообще не раскрывать.
Или привлекали компанию-оценщика для определения степени ущерба обоям // разбитую тарелку по остаточной стоимости.
К чему это все
Это тот случай когда корректная юридическая обвязка фин инструментами будет слишком дорогой и накладной бюрократически для всех сторон — площадки (Авито), арендодателя, съемщика.
Чтобы я сделал?
Сделал бы модели, конечно:
⁃ Конфликтности арендрдателя
⁃ Конфликтности съемщика
⁃ Проблем этого конкретного съемщика с этим конкретным арендрдателем
Кстати, многие площадки такие модели закупают, например у нас
Собственно, в таких кейсах ML и работает лучше всего — если сравнивать затраты / результат на ML и на 100% надежное юридическое решение
PS: График построил ChatGPT по источнику
PPS: Вот еще пару прикольных постов у Никиты о том что творится на рынке:
- собес в магнит
- собес в Узум
2❤18🥰5
#корпжиза
На вопрос «почему вы ушли из компании?» этот кандидат ответил подробно:
На вопрос «почему вы ушли из компании?» этот кандидат ответил подробно:
У меня в xxx был руководительНегороСебастьян Перейра, торговец черным деревом.
Бывший IT-директор yyy. Легенда. Человек, который “очень успешно внедрил SAP”.
Настолько успешно, что по итогам внедрения его оттуда попросили.
Но это мелочи.
Говорят, за откат с SAP он купил остров в Карибском море, яхту и рок-группу с набором солисток, с которыми одновременно поддерживал “нескучные взаимоотношения”. Причем это не корпоративный фольклор уровня “знакомый знакомого”.
У Негоро реально есть клипы на YouTube.
Плюс параллельно он еще успевал заниматься гастродеятельностью. Короче, нормальный такой руководитель: и SAP, и остров, и творческая самореализация.
Но вот наступил кризисный год.
Дружественная верхушка компании отчалила, и Себастьян Перейра решил производить впечатление на оставшихся уважаемых людей презентациями. И тут я впервые увидел идеальную модель корпоративной эффективности: 20% времени — что-то реально делаем, 80% времени — рисуем слайды и занимаемся креативом, чтобы это выглядело как “стратегическая инициатива”. Половина команды начинает жить в PowerPoint, как в основной системе учета реальности.
Ну и, разумеется, при таком руководстве к нам подтянулись очень интересные люди.
Например, глава разработки. Чем он занимался по работе — я так и не понял.
Но у него был побочный бизнес:
• гештальт-терапевт
• коуч ICF
• плюс подработка тамадой на свадьбах и ведущим корпоративов
То есть человек буквально мог:
• утром “закрыть гештальт”
• днем “проработать границы”
• вечером “ДЕВОЧКИ, ДАВАЙТЕ ПООРЕМ ГОРЬКО”
Универсальный сотрудник, мечта HR.
Но это все еще не топ.
Самый топ я увидел, когда по контракту был “директором по чему-то там” в одном большом облаке.
Формально не CTO, но задачи выполнял примерно CTO. Пару месяцев.
И вот у них генеральным был… финалист Битвы экстрасенсов на ТНТ.
Без шуток. Я даже интервью смотрел.
Дипломированный телепат. Астролог. Таролог (и, конечно же, “эксперт по энергиям бизнеса”)
Лучшее — он мог разговаривать с животными.
На съемках у него на плече висел здоровенный ворон, и этим вороном он “допрашивал” кота в музее Булгакова. И ты сидишь такой, обсуждаешь облачную стратегию, SLA и CAPEX…
а рядом реальность, где CEO разговаривает с вороном, чтобы принимать управленческие решения.
1😁83🤣35🔥13❤2🤯2😨1
Lakehouse для аналитиков и инженеров данных. Новый старт — 5 февраля.
Изучи набирающий популярность подход к построению хранилищ данных Data Lakehouse c разделенным Compute и Storage на основе Iceberg и Trino.
🌐 В программе курса:
▪️Современная архитектура аналитических систем от DWH и Data Lake до Lakehouse с разделением Compute и Storage на базе Apache Iceberg и Trino.
▪️Iceberg: управление файлами, снимками, каталогами, схемами изменений и очисткой.
▪️Практическое использование Iceberg Catalog, работа с кластером Trino (на Kubernetes), подключение данных на S3 и выполнение SQL/Python-запросов.
▪️Работа с Iceberg+Trinо на больших масштабах: сложные запросы к датасету TPC-DS (2.8 млрд строк), интеграция с DBT, Apache Airflow, оценка производительность систем.
▪️Построение пайплайнов, инструменты для корректной поддержки, обновления и масштабирования Lakehouse-инфраструктуры на уровне предприятия.
🥸 Кто мы: R&D-центр Devhands.io, наш канал. Автор курса — Алексей Белозерский, руководитель направления Big Data Services в компании VK Tech.
🗓 Старт курса: 5 февраля, 18:00, 6 недель обучения.
Изучить программу и записаться можно здесь.
Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2VtzqxKvM6b
Изучи набирающий популярность подход к построению хранилищ данных Data Lakehouse c разделенным Compute и Storage на основе Iceberg и Trino.
▪️Современная архитектура аналитических систем от DWH и Data Lake до Lakehouse с разделением Compute и Storage на базе Apache Iceberg и Trino.
▪️Iceberg: управление файлами, снимками, каталогами, схемами изменений и очисткой.
▪️Практическое использование Iceberg Catalog, работа с кластером Trino (на Kubernetes), подключение данных на S3 и выполнение SQL/Python-запросов.
▪️Работа с Iceberg+Trinо на больших масштабах: сложные запросы к датасету TPC-DS (2.8 млрд строк), интеграция с DBT, Apache Airflow, оценка производительность систем.
▪️Построение пайплайнов, инструменты для корректной поддержки, обновления и масштабирования Lakehouse-инфраструктуры на уровне предприятия.
Изучить программу и записаться можно здесь.
Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2VtzqxKvM6b
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤12👍6
#корпжиза
Эталонный каналья-манагер на собесе
Один из самых драматичных жанров для обеих сторон — собеседования, есть и у меня десяток постов про них:
Раз
Два
Три
Четыре
Пять
Шесть
Семь
Восемь
Девять
Десять
И бонус
И они все блекнут в свете цитат c собеседования эталонного канальи на роль СТО:
Эталонный каналья-манагер на собесе
Один из самых драматичных жанров для обеих сторон — собеседования, есть и у меня десяток постов про них:
Раз
Два
Три
Четыре
Пять
Шесть
Семь
Восемь
Девять
Десять
И бонус
И они все блекнут в свете цитат c собеседования эталонного канальи на роль СТО:
Я драйвлю экзекьюшен
— А какой ваш план работы на 3 месяца?
— <долго думает> За три месяца планирую понять в чем суть работы.
Я хочу привести company_name в эффективный вид для трамплина company_name в сторону инноваций для синергий по всем направлениям
Я могу прийти в любое подразделение и указать своим приходом где можно найти эффект
Бизнес-модель Москвы отличается от мира
У меня есть документ с сигналами для трансформации
— С какими командами работаете?
— Я предпочитаю keep in touch с людьми кто кует железо
— Назови артефакт, который ты сделал руками?
— Половцы-печенеги … <80 слов с корнем «трансформ»>
3😁57🔥7❤3👍2😢2
#ML
Про анализ важности фичей
В очередной модели, которую попросили «посмотреть», обнаружил сразу три графика по важности фичей в бустинге:
— По числу сплитов по фиче (дефолтный feature_importances_)
— По gain
— По tree shap
Пропустим пока вопрос о дрифте фич (а они бывают разные с разными эффектами) — про них отдельно стоит написать.
Дальше я наивно ждал интерпретации — но увы.
Когда я об этом спросил услышал две версии от двух тимлидов:
Астерикс— «где gain выше та фича и сильнее»,
Обеликс — «где shap выше та фича и сильнее».
Поскольку галлы строят модели под влиянием волшебного друидского зелья и не знакомы с латинским, немного навайбкодил примеров чтобы показать что для анализа фичей нужны все три важности (это еще не считая анализа стабильности этой важности во времени / по фолдам).
Ключевое в них — кросс-плоты feature_importance по cплитам vs по gain и по shap vs по gain.
Это два графика, которые нужно обязательно смотреть в бустингах.
Если вкратце:
1. Важность по gain сильно завышает редкие бинарные фичи с резким эффектом (в тетрадке это x_strong_rare). Модель редко использует их (малый SHAP), но когда использует — один сплит даёт огромный выигрыш.
Что с такими фичами делать?
Если они сами по себе интерпретируемы и срабатывают редко —
Иначе будут проблемы и с обучением (понадобится больше деревьев и стабильность пострадает) и с интерпретируемостью — такая фича забьет рабочие лошадки по важности + начнет ломать интерпретируемость shap (либо придется считать отдельно для x_strong_rare = 1 или x_strong_rare = 0).
Смотрят либо фичи вылетевшие вверх на графике shap vs gain либо проверяют фичи которые в топе по gain но не в топе по shap.
Бонусом к отдельному сигналу — частота у такой фичи может сильно скакать во времени что еще больше нарушит стабильность модели.
Так что вынос такой фичи в отдельный сигнал — это еще и интерпретабельность PSI модели.
Как это повлияет на калибровку?
Ухудшит “глобальную” калибровку, но улучшает там, где модель реально работает (при x_strong_rare = 0).
2. Есть фичи вроде x_weak_often — с высоким сплитом, но низким shap и gain.
Здесь может быть несколько вариантов:
— +/- симметрично распределенный непрерывный шум
— фича костыль: есть небольшая коррекции с таргетом, но в модель ничего не добавляет
— фича по построения состоит из нескольких бакетов
В любом случае если зажали max_depth / n_estimators чтобы «регуляризоваться» то модель потратит кучу деревьев и сплитов на такие шумные и удобные для сплита фичи вместо того чтобы поймать реальный сигнал.
Еще она может массировать другие проблемы вроде мультиколлинеарности или ликов.
Как еще их можно отловить?
Строить feature_importance по месяцам/фолдам и проверять стабильность важности фичи.
Следить за дисперсией метрики (ex: Gini) на CV.
3. Есть фичи с низким split и не самым высоким gain, но с высоким SHAP.
То есть модель редко по ним сплитится, но почти в каждом объекте они двигают prediction.
Итого:
1. Строим:
- split vs gain
- shap vs gain
2. Если фича:
- top gain, но не top shap → кандидат в сигнал
- top split, но низко по shap и gain → кандидат на выброс
- low split, not high gain, high shap → не трогать, это рабочая фича (пока мы не исследовали ее стабильность по времени)
3. Проверяем:
- стабильность importance по фолдам / времени
- Дисперсию метрики по фолдам кросс-валидации
- PSI условно (x_strong_rare=0)
4. Только после этого:
- feature selection
- регуляризация
Те кто внезапно дочитал до этого момента могут заключить что второй тимлид был прав и надо смотреть только на shap.
Но
.
Особенно, если:
⁃ Он высокий только на трейне
⁃ Нестабилен по фолдам / или времени
⁃ Фича сама по себе нестабильна
⁃ Модель деградирует на OOT
PS.
низкий SHAP не значит что фича плохая.
Например:
— фича-разделитель (регион),
— стабилизирует модель,
— работает только в хвостах,
часто имеют низкий SHAP, но без них качество и стабильность падают.
Про анализ важности фичей
В очередной модели, которую попросили «посмотреть», обнаружил сразу три графика по важности фичей в бустинге:
— По числу сплитов по фиче (дефолтный feature_importances_)
— По gain
— По tree shap
Пропустим пока вопрос о дрифте фич (а они бывают разные с разными эффектами) — про них отдельно стоит написать.
Дальше я наивно ждал интерпретации — но увы.
Когда я об этом спросил услышал две версии от двух тимлидов:
Астерикс— «где gain выше та фича и сильнее»,
Обеликс — «где shap выше та фича и сильнее».
Поскольку галлы строят модели под влиянием волшебного друидского зелья и не знакомы с латинским, немного навайбкодил примеров чтобы показать что для анализа фичей нужны все три важности (это еще не считая анализа стабильности этой важности во времени / по фолдам).
Ключевое в них — кросс-плоты feature_importance по cплитам vs по gain и по shap vs по gain.
Это два графика, которые нужно обязательно смотреть в бустингах.
Если вкратце:
1. Важность по gain сильно завышает редкие бинарные фичи с резким эффектом (в тетрадке это x_strong_rare). Модель редко использует их (малый SHAP), но когда использует — один сплит даёт огромный выигрыш.
Что с такими фичами делать?
Если они сами по себе интерпретируемы и срабатывают редко —
их нужно выносить в сигналы до модели!
Иначе будут проблемы и с обучением (понадобится больше деревьев и стабильность пострадает) и с интерпретируемостью — такая фича забьет рабочие лошадки по важности + начнет ломать интерпретируемость shap (либо придется считать отдельно для x_strong_rare = 1 или x_strong_rare = 0).
Смотрят либо фичи вылетевшие вверх на графике shap vs gain либо проверяют фичи которые в топе по gain но не в топе по shap.
Бонусом к отдельному сигналу — частота у такой фичи может сильно скакать во времени что еще больше нарушит стабильность модели.
Так что вынос такой фичи в отдельный сигнал — это еще и интерпретабельность PSI модели.
Как это повлияет на калибровку?
Ухудшит “глобальную” калибровку, но улучшает там, где модель реально работает (при x_strong_rare = 0).
2. Есть фичи вроде x_weak_often — с высоким сплитом, но низким shap и gain.
Здесь может быть несколько вариантов:
— +/- симметрично распределенный непрерывный шум
— фича костыль: есть небольшая коррекции с таргетом, но в модель ничего не добавляет
— фича по построения состоит из нескольких бакетов
В любом случае если зажали max_depth / n_estimators чтобы «регуляризоваться» то модель потратит кучу деревьев и сплитов на такие шумные и удобные для сплита фичи вместо того чтобы поймать реальный сигнал.
Еще она может массировать другие проблемы вроде мультиколлинеарности или ликов.
Не выбросить такую фичу — ошибка!
Как еще их можно отловить?
Строить feature_importance по месяцам/фолдам и проверять стабильность важности фичи.
Следить за дисперсией метрики (ex: Gini) на CV.
3. Есть фичи с низким split и не самым высоким gain, но с высоким SHAP.
То есть модель редко по ним сплитится, но почти в каждом объекте они двигают prediction.
Выбрасывать такие фичи — тоже ошибка!
Итого:
1. Строим:
- split vs gain
- shap vs gain
2. Если фича:
- top gain, но не top shap → кандидат в сигнал
- top split, но низко по shap и gain → кандидат на выброс
- low split, not high gain, high shap → не трогать, это рабочая фича (пока мы не исследовали ее стабильность по времени)
3. Проверяем:
- стабильность importance по фолдам / времени
- Дисперсию метрики по фолдам кросс-валидации
- PSI условно (x_strong_rare=0)
4. Только после этого:
- feature selection
- регуляризация
Те кто внезапно дочитал до этого момента могут заключить что второй тимлид был прав и надо смотреть только на shap.
Но
высокий shap ничего не гарантирует!
.
Особенно, если:
⁃ Он высокий только на трейне
⁃ Нестабилен по фолдам / или времени
⁃ Фича сама по себе нестабильна
⁃ Модель деградирует на OOT
PS.
низкий SHAP не значит что фича плохая.
Например:
— фича-разделитель (регион),
— стабилизирует модель,
— работает только в хвостах,
часто имеют низкий SHAP, но без них качество и стабильность падают.
2🔥67❤22👍18👏1😭1
#ML
Повезет ли мне?
DS и карьерным стратегиям в целом и по фильмам научиться можно.
Вот например, некогда популярная задача на собеседованиях по статистике (мне вот задавали году в 17м):
PS: Конечно я не столь узнаваем как молодой Клинт Иствуд на картинке выше, но мини-интервью N прекрасным айтишницам таки дал, будем знакомы!
PPS: Сам фильм с точной фразой
PPPS: в игре в русскую рулетку используетс один шестизардный револьвер
Повезет ли мне?
DS и карьерным стратегиям в целом и по фильмам научиться можно.
Вот например, некогда популярная задача на собеседованиях по статистике (мне вот задавали году в 17м):
Вы вдвоем играете в русскую рулетку, в револьвере ровна два вставленных подряд патрона..
Оппонент крутит барабан, стреляет — и остается жив. Ваша очередь: будете крутить барабан или сразу стреляться? Почему?
PS: Конечно я не столь узнаваем как молодой Клинт Иствуд на картинке выше, но мини-интервью N прекрасным айтишницам таки дал, будем знакомы!
PPS: Сам фильм с точной фразой
PPPS: в игре в русскую рулетку используетс один шестизардный револьвер
2😁16
Не двигайтесь: вы в ИИ-кадре
Этот бот создает фото для соцсетей в футуристичном стиле. Его можно поставить на аватарку, особенно если идете на t-sync conf. Конференция от Группы «Т-Технологии» для опытных инженеров впервые пройдет в Москве 7 февраля.
Попробовать бота можно здесь. А узнать больше о t-sync conf и зарегистрироваться — здесь
Этот бот создает фото для соцсетей в футуристичном стиле. Его можно поставить на аватарку, особенно если идете на t-sync conf. Конференция от Группы «Т-Технологии» для опытных инженеров впервые пройдет в Москве 7 февраля.
Попробовать бота можно здесь. А узнать больше о t-sync conf и зарегистрироваться — здесь
🤣16👍5❤3🔥2🥴1
RAG_datarascals.pdf
11.9 MB
#ML
В этом семестре ведем c Максом курс по ИИ-агентам во ВШЭ и ВШПИ МФТИ, и на специализации по ML у Вити.
Вокруг темы сейчас много хайпа и поделий вроде написать промпт + накинуть StructuredOutputParser + завернуть в langchain / crewai / qwen-agent etc., поэтому делюсь своим видением об этом всем рассказывать — во вложении одна лекция курса — по RAG.
Что скажете?
Буду благодарен за любой фидбек, в тч и неконструктивный
В этом семестре ведем c Максом курс по ИИ-агентам во ВШЭ и ВШПИ МФТИ, и на специализации по ML у Вити.
Вокруг темы сейчас много хайпа и поделий вроде написать промпт + накинуть StructuredOutputParser + завернуть в langchain / crewai / qwen-agent etc., поэтому делюсь своим видением об этом всем рассказывать — во вложении одна лекция курса — по RAG.
Что скажете?
Буду благодарен за любой фидбек, в тч и неконструктивный
❤29🔥20🤯7👏3❤🔥1