Telegram Web
Forwarded from Data Secrets
Известный мировой тех.подкаст про AI Latent.Space в честь Нового Года выложили 2025 AI Engineering Reading List

Это огромный список актуальных мастридов для ML/AI инженеров. В нем нет базовой базы, а только те статьи, которые непосредственно относятся к современным развивающимся методам и технологиям.

Охвачены 10 самых важных на сегодняшний день областей: файнтюнинг, агенты, диффузия, голос, вижн модели, генерация кода, RAG, цепочки рассуждений, бенчмарки и эвал, и frontier LLMs.

Список получился у ребят действительно очень крутой и насущный, так что обязательно забирайте себе в бэклог или в ридинг-клабы.
По многим источникам вижу, что подводить итоги почему-то нынче зашквар, наверное потому, что якобы никому не интересно их читать. Но лично мне это было очень даже интересно, много нового узнал о тех, за кем давно слежу. Поэтому напишу свои - у меня это первый раз, мне можно ))

Из профессионального:

- Ни разу не лейоффнули за 2024. Доволен, потому что в 2023 это случалось дважды.
- Оказавшись в коммьюнити “Hello New Job” в конце 23, рад состоять в нем, ибо продолжаю пожинать плоды весь этот год. Стало понятно, как искать работу, как составлять резюме, как проходить нетехнические интервью и так далее. После того, как стал следить за новыми выпусками по теме, ощущаю себя в курсе того, в каком состоянии рыночек в IT
- Ощутил мощь Linkedin, понял, как с ним работать, чтобы он приносил пользу (в первую очередь, предложения о работе), набрал 1к+ фолловеров, стали писать рекрутеры.
- Несмотря на то, что активно работу не искал, прошел 20+ собесов, с 2 неплохими офферами, один даже с релоком в ЕС. По результатам четко сформулировал слабые места по технике, работаю над ними.
- Сделали крутой проект в Нигерийском банке, написали с шефом статью, ждем публикации
- Понял, что могу работать на 2 работах постоянно. В наше время постоянных лейоффов это отлично страхует от голода и придает уверенности.
- Касаемо учебы. Наконец закрыл позорный гештальт: начал изучать DL, прошел специализацию от Deeplearning.AI. Andrew NG, как и много лет назад - топ! Начал вгрызаться в PyTorch, читать классические статьи, смотреть доклады - все как мы любим. Смотря на то, сколько всего появилось в контексте LLM, почти безуспешно борюсь с FOMO, но когда при близком рассмотрении оказывается, что большинство “эйай экспертов” дальше промтов “за ворота” и не выглядывали, начинаю успокаиваться: мой подход был и будет основан на изучении фундаментальных вещей. Хотел одновременно затащить курс по NLP ODS, но не осилил - вернусь в следующем году. Еще из нереализованного: не прочитал книгу по causal inference, не сдал ни одной сертификации по облакам.
- Планировал продолжить писать на медиуме, но под конец года совсем не осталось времени.
- Немного занимался менторством (2 человека обращались за консультацией), один в итоге нашел работу в ЕС. Для себя плюсы такой деятельности вижу как возможность самому разобраться еще глубже в теме, которую казалось бы и так знаешь хорошо. Ну и за менти порадоваться конечно же!
🔥6
Из личного:

- Поставил антирекорд: не выезжал из страны уже больше 2 лет, чего не было, наверное, со школы
- Получил постоянную резиденцию (больше никаких походов в миграционку!) и подал доки на второе гражданство - причина антирекорда из предыдущего пункта и причина непринятия офера из ЕС: из страны не стоит выезжать на время процесса.
- Приобрел велик, теперь почти не пользуюсь общественным транспортом, который, кстати, подорожал в несколько раз за 2 года. Все поездки до 15-20 км стараюсь совершать на нем. Благо в городе хорошо развита вело инфра. Фитнес и экономия!
- В теплое время года бегаю, но пока не достиг цели пробежать десятку. Пока 8км - мой максимум. Вообще без снега живется гораздо лучше (я не видел его почти 3 года, кроме как морозилке), а если очень хочется - есть горнолыжные курорты, но это не мое ))
- Под конец года взялся-таки за испанский, в магазинах и на рынках новому уже не научат, теперь придется учиться самому)
🔥6
В 2025 CI/CF продолжат набирать популярность. Сочетание спроса и небольшое количество толковых специалистов, очень большое поле для новаций. С одной стороны, LLMки, где 2000 человек на кв. см, много хайпа и существенное превышение затрат над value, с другой стороны, СF, causal investments, 2 десятка человек с пачкой проектов и с загруженностью до 2028 года, Марко де Прадо, его ученики, ученики его учеников, ученики Хайндмана, Цая и Атанасопулоса. Убытки в использовании цифровых двойников на ML-моделях, над которыми не надстроен каузальный анализ, колоссальные, но об этом часто исследователями умалчивается, а бизнес нередко разочаровывается в возможностях промышленного ML, хотя ML и не может ответить на вопрос, на сколько мне нужно изменить X, чтобы изменить Y на столько-то. Собственно в это направление перемещаюсь, бог даст, будет пара книжек в этом году. Для введения подойдет https://www.cambridge.org/core/services/aop-cambridge-core/content/view/9AFE270D7099B787B8FD4F4CBADE0C6E/9781009397292AR.pdf/causal-factor-investing.pdf
Apache Parquet: как Twitter и Cloudera развивали дата инжиниринг

Apache Parquet начинался как совместный проект Twitter (ныне X) и Cloudera — компании, известной своими дистрибутивами Hadoop и инструментами для работы с ним. Многие, кто работал с Hadoop, вероятно, сталкивались с Cloudera и пользовались их решениями. Например, в Сбербанке используют их софт для обработки больших данных (Сбер за рекламу не платил, а мог бы).

Теперь давайте наглядно сравним Parquet с традиционным CSV-файлом, чтобы понять его преимущества. Возьмем простой пример CSV:

Имя, Пол, Год рождения, Вес, Рост, Дата записи
Владимир, М, 1954, 74, 179, 01/01/2024
Борис, М, 1931, 88, 187, 01/01/2024
None, М, None, 77, 178, 02/01/2024
Валерия, Ж, 1950, 150, 168, 02/01/2024


1. Колоночный формат
Первая ключевая особенность Parquet — это колоночное хранение данных. В CSV данные хранятся построчно, и для вычисления среднего значения, скажем, веса, вам нужно пройти по каждой строке, извлекая из нее данные. Это требует времени, особенно для больших наборов данных.

Parquet же хранит данные по колонкам. Сначала записываются все значения первой колонки, затем второй, и так далее. Например, для расчета среднего роста нужно считать только колонку с ростом, не затрагивая остальные данные. Это заметно ускоряет обработку.

Более того, в Parquet применяется метод сжатия RLE (Run Length Encoding), что эффективно для хранения повторяющихся значений и пропусков. Например:

Имя: (Владимир, [0]), (Борис, [1]), (Валерия, [3])
Пол: (М, [0, 1, 2]), (Ж,[3])

Таким образом, можно обрабатывать большие объемы данных быстрее и с меньшими затратами памяти. Библиотеки вроде Polars, благодаря колоночному формату, не будут загружать лишние данные при ленивых вычислениях, что делает их работу еще эффективнее.

Типизация данных, схемы и партиционирование
Каждый Parquet-файл сопровождается схемой, которая описывает структуру данных: какие есть поля, их типы, и где начинается блок с данными. Так как данные типизированы, можно сэкономить место. Например, колонку "Пол" можно хранить в виде числовых значений, а в схеме — просто словарь, который сопоставляет числа с реальными значениями ("М" и "Ж"). Помните, в CSV каждый символ весит минимум байт!

Теперь представим, что наш CSV-файл содержит миллиард строк. Это около 100 ГБ данных, что вполне помещается на обычный компьютер, но работать с таким файлом будет неудобно. Чтобы оптимизировать работу с большими данными, применяют партиционирование. Это разделение файла на несколько частей по какому-то признаку — например, по дате записи.

Разделив данные по дням, вы сможете, например, быстро посчитать средний рост людей только за вчерашний день, не обрабатывая весь миллиард строк. Более того, партиции можно читать параллельно в разных потоках, что еще больше ускоряет вычисления на современных многопроцессорных архитектурах. Библиотеки Pandas, Polars и Spark поддерживают такое параллельное чтение с помощью Apache Arrow.

Parquet — это мощный инструмент для работы с большими объемами данных благодаря колоночному хранению, эффективным алгоритмам сжатия и возможностям партиционирования. Для задач, связанных с большими данными, Parquet сильно удобнее и быстрее, чем традиционный CSV. Используя такие библиотеки как Polars и Spark, можно значительно ускорить обработку данных и снизить затраты на вычисления. А еще можно каждый день дописывать новую партицию за день и не менять структуру файлов и избежать дублирования
👍2
Зайдя сегодня в Линкедин, увидел 2 противоречащие друг другу вещи:
- Мета уволила тех самых low performers, как и обещал Цукерберг. Оценки разные, видел 3-5 тысяч человек, что очень много для некоего "нижнего перцентиля"
- Рекрутер из той же Меты предлагает пособеситься на ML/SWE

Особенно странно, что они по-прежнему нанимают ML Generalist. А как же обещания заменить всех на эй ай в 2025?!
Много вопросов и мало ответов...
👍1🔥1
Как AI нас всех заменяет (нет).

Написали в линкедин, предложили помочь по MLE в стартапе, я в ответ всегда интересуюсь проектом, обязанностями и компенсацией (если пишущий не сообщает об этом самостоятельно).

Так вот, с его слов у них СЕО проникся вот этим самым "любой сможет накидать прототип в одиночку", "разработка теперь под силу любому" и решил, что справится сам. Он потратил месяц на то, чтобы накидать этот самый прототип, получилось около 100к строк кода с помощью Gemini. И вы представляете, этот код почему-то не заработал! И вот теперь они ищут несколько MLE , чтобы заставить это творение работать. А не проще ли было сразу нанять людей, чтобы они с самого начала писали все как положено? Как известно, разобраться и починить чужой код (тем более такой, как в этом примере) куда более затратно по ресурсам. Ну и месяц работы СЕО наверное, не самый дешёвый...

Продолжаю наблюдение:)
😁3
"Разработка теперь под силу любому!"
😁3
#дипломный_проект
#data_preprocessing

Часть 1.

В уже далеком 2016 году, когда я учился на вечерке ВМК, я работал МЛ сервисным инженером: ремонтировал и апгрейдил инфузионные насосы. Это небольшие, но напичканные электроникой аппараты, которые используются для очень точного дозирования препаратов на длительном отрезке времени, т.е. делают этакий очень долгий “укол” каким-либо препаратом, например, вводят 1 мл препарата в течение суток с определенной скоростью. Я надеюсь, что вживую вы их никогда не видели и уж тем более вам не доводилось испытывать на себе их действие.

За 5 лет работы я переремонтировал более 1.5 тысяч аппаратов, поэтому прекрасно знал все особенности как поломок, так и клиентов, которыми являлись либо гос, либо частные клиники. В мои обязанности входило составление акта обследования неисправного аппарата, где указывались поломки, их причины, нужные для ремонта запчасти и итоговая стоимость. Акт высылался клиенту, а он уже либо соглашался на ремонт, либо отказывался, если цена слишком высока и проще купить новый аппарат. В случае согласия на ремонт я обращался в бухгалтерию для выставления счета на оплату, который отправлялся клиенту.

Так как отказы от ремонта были нередки из-за слишком высокой цены на ремонт, а за диагностику выбить деньги было очень непросто (косяки head of service engineering), то я подумал, что, задав всего несколько вопросов клиенту перед отправкой на диагностику, можно заранее оценить порядок стоимости ремонта и, если она будет довольно высокой, то сразу предупредить клиента, что ремонт нецелесообразен и проще купить новый аппарат. А если наоборот, предполагаемая цена будет низкой, можно сразу после диагностики идти просить выставить счет, чтобы не тратить время на ожидание согласования от клиента.

Так родилась идея первого моего проекта по анализу данных с применением ML.
🔥2
Часть 2.

Обсудили с шефом, какие сценарии работы такой модели мы бы могли использовать в работе:
- Бинарная классификация: клиент согласится/не согласится ремонтировать аппарат
- Мультиклассовая классификация: низкая стоимость ремонта (делаем диагностику и сразу выставляем счет без согласования), средняя (делаем диагностику, но ждем подтверждения клиента о согласии на ремонт), высокая (прежде чем делать диагностику, говорим клиенту, что цена ремонта будет слишком высока и предлагаем вместо ремонта купить новый аппарат)
- Регрессия: модель прогнозирует саму стоимость ремонта

Что мы могли бы использовать как фичи для такой модели? Остановились на таком списке фичей, которые можно было бы узнать у клиента по телефону:
- Сам клиент - отличная фича. Все учреждения по-разному обращаются с оборудованием
- Гос клиника или частная клиника: разница в отношении к оборудованию колоссальная! В российских гос больницах обычно подход “не мое - не жалко”, когда в частной у персонала просто вычитают стоимость ремонта из зарплат, если доказана его вина
- Серийный номер: чем он меньше, тем старше аппарат, тем больший износ у него. Плюс есть диапазоны номеров с известными дефектами в производстве, когда какой-то узел выходил из строя сильно быстрее.
- Тип поломки? Не качает, не горит экран, не включается вообще, не работает от батареи и прочие.
- После чего прибор перестал работать? Самые частые ответы здесь это: уронили, залили дезинфекционной жидкостью, перепад напряжения в сети, включили после долгого хранения на складе (прибор мог отсыреть и получить коррозию электронных плат)
- Пробовали ли ремонтировать самостоятельно? Да, это реальность РФ, когда в немецкий аппарат лезет больничный инженер, пытаясь заставить аппарат работать путем наколхоживания самодельных “запчастей” и тем самым сэкономить на ремонте. Так вот мало того, что по очевидным причинам категорически запрещено потом использовать в работе такой аппарат, так это еще зачастую увеличивало цену ремонта: стараясь починить самостоятельно, такие инженеры обычно доламывали то, что еще было исправно
- Был ли аппарат в ремонте ранее? Если да, то как давно? Это мы уже могли посмотреть в базе самостоятельно и здесь еще важно было уточнить, что в нем менялось - если менялся, например, главный привод (двигатель), то скорее всего в этот раз сломано что-то другое.


Чтобы решить, по какому из трех путей пойти, конечно же сначала нужно было проанализировать имеющиеся данные. А это оказалась та еще задачка: все акты хранились в SAP , из которого нельзя было просто взять и выгрузить Excel со всей нужной информацией. Можно было выгрузить акт, где указан сам клиент, дефекты, жалобы клиента, потенциальные причины поломки и цена ремонта с детализацией по отдельным работам и запчастям. Поскольку SAP дорабатывался двумя немцами, которые обслуживали всю Европу и РФ, то у них была полугодовая очередь даже на критически важные доработки. Поэтому рассчитывать на то, что они хотя бы поставят нас в очередь с сомнительным запросом для какого-то там ML, точно не стоило.
Поэтому я решил собрать все данные сам, и это оказалось очень непросто, но при этом увлекательно.
🔥2
Часть 3.

Каким-то образом я добыл 6 тысяч номеров актов, имея номер акта можно было скачать PDF файл, причем только один за раз, процедура требовала одну минуту времени и десяток кликов мышкой. Поскольку у меня не было 6000 свободных минут, я написал автокликер, что-то вроде современного Selenium, который за несколько суток (не считая нескольких часов отладки, разумеется) скачал все нужные PDF файлы.

Далее нужно было вытащить инфу из PDF в текст. Нашел питоновский тул PDFminer, который решил эту задачу, сложил содержимое всех 6000 пдфок в один текстовый файл. Теперь предстояло при помощи магии регулярок распарсить все это добро и разложить в CSV по колонкам. Задача осложнялась довольно хаотичным расположением полей, которые нужно было идентифицировать (по сути, все, что было указано в нашем списке фичей + итоговая цена ремонта). Расположение зависело от порядка заполнения документа, например, сначала внесли дефекты, а потом их причины. Но могло быть и наоборот. В итоге полтора десятка if-else + столько же регулярок на питоне заработали после недели отладки, и долгожданный CSV был собран. Эх, вот бы тогда иметь AI-агентов, которые есть сегодня!

Анализ распределения цен ремонтов показал три четких кластера с низкой, средней и высокой ценой, причем в последнем из них высока была доля отказов от ремонта. В детали feature engineering вдаваться не буду, но там ничего необычного не было - все, можно сказать, по учебнику. Упомяну лишь, что пришлось приводить цены в рублях в цены в евро, т.к. мы все прекрасно знаем, что случилось в 2014 года с курсом рубля. Все перечисленные фичи были добавлены в логистическую регрессию для 3 классов, которая показала приемлемое качество и особенно хорошо отделяла последний, самый “дорогой” класс, что нам и было нужно.

Диплом был успешно защищен, а вот внедрение проекта не состоялось. Во-первых потому, что еще перед защитой я после 8 лет работы инженером нашел стажировку на позицию data scientist. А во-вторых, это уже была гораздо более трудная для меня на тот момент задача, требующая значительных изменений в порядке работы сервисного отдела. Однако, рассказ об этом проекте очень хорошо продавался на собеседованиях еще очень много лет! И поскольку на “добычу” и предобработку данных у меня суммарно ушло до 80% всего времени (я здесь не учитываю затраты на оформление проекта в дипломную работу) и только 20% на само моделирование, то с самого первого проекта я очень хорошо знаю, что подготовка данных зачастую важнее непосредственно моделирования.
🔥4
Forwarded from partially unsupervised
Месяц как перекатился из мира, где комбинировал kNN и PCA, в мир MCP и ToT. Продолжая жонглировать акронимами, назову это мягким переходом из ML в AI - прототипирую некие инструменты для разработчиков, чем давно хотел заняться. Впечатления такие:

Во-первых, software engineering аспект стал прям важен! Раньше умение завернуть свою поделку в докер и высунуть хендлер уже считалось кое-каким уровнем, а умение покрыть это все хоть какими-нибудь тестами выделяло из толпы jupyter-писателей. Сейчас иначе: например, в первую неделю в рамках онбординга нужно было оптимизировать алгоритм обхода графа. Из других нетривиальных задач: придумать и добавить кастомное правило для линтера, спроектировать удобную стейт-машину поверх других низкоуровневых стейт-машин.

Во-вторых, LLM провоцируют выводить все на метауровень. Например, типичная итерация улучшения выглядит так: внес изменение, дальше в одну команду запустил пайплайн на сгенеренных сценариях, достал логи, проанализировал логи LLM-кой, сгенерил отчет, и только потом смотришь глазами на популярные failure modes. Все это занимает 10-15 минут (если не падает в рантайме, ыхыхы), так что итерироваться можно много и часто.

Во-третьих, порой ощущаю себя дурачком, во многом нужно разбираться с нуля и задавать коллегам неловкие вопросы. После рабочего дня голова часто трещит и настойчиво требует отдыха. Но главные навыки - декомпозировать проблему и анализовать ошибки - оказались абсолютно переносимы. Опыт таки пригодился!
(здесь могла быть реклама книги, и особенно глав про preliminary research и error analysis).
🔥2
Всех приветствую!
Спасибо тем, кто поинтересовался, куда это я пропал - все в порядке: брал доп проекты, чтобы прокачаться в современном дашбордостроительстве и Airflow, чтобы прикрыть дыры в хардах, которые вскрылись на собеседованиях в прошлом году. Еще раз убедился, что лучший способ освоить что-то - это практика, а лучшая практика - в реальном бою.

Пост с вакансией
помог нам найти нужного человека именно здесь, поэтому скоро запощу еще пару вакансий в тот самый нигерийский банк.
🔥2
По поводу холивара в Data Science Chat «нужны ли собесы на знание алгоритмов, задачки LeetCode или нет», отвечаю, есть у нас такое. Это про дисциплину, структурное мышление. Ну как в одежде. Можно, конечно, забить на то, как одеваться, смешивать стили, одеваться в 5-6 разных цветов, как попугай, выглядеть нелепо. Для MLE, SSE всегда полезно, для ресерчера, дата аналитика лучше вложиться в статистику, тервер, Causal Inference, ML/DL-практику, продвинутый EDA.

Андрей пишет, что гораздо важнее уметь бизнес-задачу перевести в язык data science, но MLE, SSE в крупных компаниях чаще всего не участвуют в формулировании бизнес-задач напрямую. Переводом бизнес-задач в data science задачи занимаются Product Managers (PM), Data Analysts (DA), Applied Scientists / Research Scientists, Business Analysts, обычно группа из продакта, дата аналитика и бизнес-аналитика. Здесь Андрей скорее всего накладывает СНГ’шную практику на западную. В России, Украине да, там ты и швец, и жнец, и на дуде игрец.В западных компаниях роли четко определены.

И направления, которые надо качать, чтобы уметь переводить бизнес-задачи в DS-задачи, - это product thinking, это наш любимый causal inference, это operation research (методы оптимизации, моделирования процессов, логистики, ресурсного планирования, особенно актуально, когда у нас есть задача с ограничениями по материальным, временным, людским ресурсам), продуктовая аналитика, бизнес-аналитика.
2025/10/23 17:44:46
Back to Top
HTML Embed Code: