#ML

В продолжение предыдущей истории — у тимлида первой команды были все основания ждать подвоха, ведь тимлид второй разошелся на цитаты:

мы сделали прогнозную модель с точностью 75% которая достигается тем что модель анализирует 800+ признаков

по факту -- one-hot на всем что было 🤦‍♂️

а вообще усреднять тема вот у нас в прогнозной модели 36 бустингов и точность высокая поэтому

🤦‍♂️

а зачем ты разбиваешь на train val test по времени? Можно же рандомно

😁

-обучать llm через lora неправильно
-а как правильно?
- ну там данных много надо, а вот мы сделали ии агента с рагом

👏🙌

построение эмбеддингов через tf-idf не является интеллектуальным анализом данных

👏

tf-idf - это не эмбеддинги это численное представление

🤦‍♂️

tf-idf - это низкоуровневные эмбеддинги

🤦‍♂️

Ну мы твой проект для задачи 1 внедрим, а для управления промо как пойдет

Возможный эффект задачи 1 - три копейки
Возможные эффект управления промо - сотни миллионов 😆💡

а зачем ты логарифмируешь цену? так хуже качество будет

🤔

Буду рад сегодня вас видеть на митапе! 🍿🍿🍿🍻

Кто не знаком лично - давайте знакомиться 🤝

На всякий случай уточню:

Если вам не пришло письмо подтверждения регистрации, но вы регистрировались — приходите, вас добавили в списки для входа.

Немного спойлеров )

Если кто забыл программу )

Спасибо тем кто вчера пришел, задавал вопросы, поддерживал спикеров и просто встретил друзей! ☺️♥️
Надеемся что фоточки будут готовы на сл неделе, а пока упрашиваем спикеров (а они свои пиар-службы) поделиться с вами презентациями.
Stay tuned, до встречи на новых митапах!

#ML

В комментах к последним постам про логарифмирование таргета (а в комментах был материал про другие модификации и их свойства) задавались вопросы по прогнозированию временных рядов.

Ок, лучшее, что я могу посоветовать - презентация с наших совместных с ВШЭ ML-тренировок by Дмитрий Симаков, Kaggle competitions master, тимлид Sber AI Lab

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

жаль что в СНГ суды не так работают, особенно в части публичных оферт в контексте трудового законодательства

200 000 – 320 000 баксов в месяц -- и пусть попробуют не выкатить оффер

UPD -- поправил, это же Армения!

Data Engineer (Scala)
200 000 – 320 000 $/месяц
Удаленка, Фултайм

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

#кейсы #ML #корпжиза

Пока кто-то разрабатывает модели для работы с неструктурированными данными, KPI каналий на внедрение LLM заставляет решать проблему по-другому:

(утащил с гз-шного форума)

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

В процессе разработки "агента", который заменит дорогого CFA возникают естественные на текущем этапе развития технологии трудности. На имеющемся потоке документов нужно слишком много few-shot-ов, чтобы этот несчастный агент хедо-бедно работал. Или нужен дополнительный SFT, или еще того хуже RLHF / DPO, чтобы он хотя бы справлялся чаще, чем не справлялся (про accuracy ~99% там речи даже близко не идёт). Проблема в том, что документы достаточно разнообразны. Ну и естественно, чтобы повысить accuracy (и получить бонус) разработчики и их менеджеры выдвигают крамольные идеи, например: а почему бы нам не сделать данные более структурированными? Скажем, например, что в отчете должны быть определенные разделы. И таких разделов должно быть много, чтобы отвечать на все необходимые вопросы, и LLM могла бы легче извлечь правильные данные или ответить на вопрос. Так вот, в текущем процессе так и происходит: к писателям возникают требования структурировать отчеты. Существенно детализируется перечень информации, который обязательно должен быть в отчете. Разрабы составляют "идеальные отчеты", которые LLM точно прочитает правильно (т.к они есть во few-shot) и приводят их в пример писателям отчетов. Данные становятся более структурированными, а значит автоматизация планктона постепенно становится проще. Собственно очевидный вывод: то, что раньше даже в голову не приходило автоматизировать, сейчас начинают шатать не только со стороны LLM, но и стороны неструктурированных данных. А значит рано или поздно все данные станут достаточно структурированными, чтобы планктон стал не нужен.
Интересная

точка зрения и кмк более перспективный подход

У вас в компаниях тоже процесс оструктурирования всего чего можно?

#ML

Курс по Базе ML мы с Витей и Ильей Ирхиным запустили год назад — для тех кто хочет детально разобраться как все устроено, а решать зубодробительные задания в ШАД в планы не входит.

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

Вот уже и третий поток запускаем 5 августа

Велкам!

Напомню формат — 4-6 мес (зависит от начального уровня, есть подготовительные модули по статистике и питону — ведет их Дима)

По вопросам отвечает замечательная Марина

Вот и фоточки с митапа подъехали

#кейсы #ML

Кейс из двух частей

Часть 1

Лет пять назад в одной сети по продаже техники решили попробовать ML, но относились с недоверием.

Куда ML применить в ритейл? Повысить продажи, например.

Как вообще происходит управление продажами крупной сети?

Если совсем на пальцах:
1) Для каждой точки продаж строится прогноз — сколько они продадут в следующем месяце.
2) Это число умножается на повышающий коэффициент — тн «амбицию» и объявляется бизнес-планом точки на сл месяц.
А сам процесс называется бизнес-планированием.

3) Далее в дело вступает перфоманс-менеджемент — выполнившим бизнес-план — 🤝премия (или грамота — зависит от), невыполнявшим — развитие 🤕.

ML в бизнес-планирование было решено внедрять в 2 этапа:

1) На пилоте (на части точек продаж) убедиться что с помощью ML прогнозы получаются точнее чем текущий у аналитиков (линейный прогноз на трех лагах)
2) Если ML точнее — пропилотировать план с амбицией, отсчитанной уже от ML-прогноза

Если по итогам продажи растут — молодцы 🙌

Итак, на первом этапе посчитали что понадобится 4 месяца для пилота

Команда аналитики дала свой прогноз, команда ML— свой (чуть покрутили prophet)

Но через 2 мес CEO решил оба прогноза увеличить на 8% и спустить пилотным точкам 🤣
До конца пилота оставалось 2 мес

Здесь просится голосовалка