Еще вопросики по Python:
- Когда GIL не помеха для multithreading?
- В чем разница между multithreading и async? А что у них общего?
- Как так получилось, что в Python есть GIL, который создает ограничения при работе с multithreading, когда в других языках, например, C#, многопоточность спокойно работает безо всяких GIL?
- Приведите известные примеры применения множественного наследования
- Про ускорение вычислений. Что такое numba, когда она может помочь ускорить выполнение кода, а когда нет? Аналогичный вопрос про Cython.
- Приведите примеры из Ваших проектов, где примененялись декораторы и генераторы. Как связаны генераторы и async?
- Какие объекты Python хранятся в стеке (stack), а какие - в куче (heap)?

Стало попадаться много высказываний вроде "ах, вот N лет назад чтобы устроиться в ДС/МЛ достаточно было сказать, что умеешь писать фит-предикт в ноутбучке и тебе апплодировали стоя и брали на работу с огромной зарплатой. А вот сейчас с джунов три шкуры на собеседованиях дерут, на которые еще и не пробиться никак сквозь тысячи откликов."

Вспомнил, как я искал свою первую работу в сфере в 2016-17 годах. На тот момент диплом, основанный на решении задачи из реальной жизни с помощью МЛ (прогнозирование стоимости ремонта оборудования) был уже фактически написан и оставалась только формальная защита, что сильно пригодилось при обсуждении опыта и навыков на собесах.

Из фейлов - общение с tutu.ru на джуна-аналитика. Вопросы по основам SQL, которые зашли, а затем последовала задача, где нужно было определить оптимальное кол-во СМС-напоминалок клиенту, чтобы он продолжил покупку билетов на сайте, если он вдруг забросил процесс по каким-то причинам. Наивно верящий тогда в то, что МЛ - это серебрянная пуля, я начал бормотать что-то про выборку, которую нам надо собрать, пробовать разное кол-во СМС ну и так далее. Естественно, решение было гораздо проще. Справедливый отказ как итог.

Из успехов - мой тогдашний шеф зареферил меня в известный рекламный холдинг на data scientist intern. Они только начали набирать команду, в которой еще никого не было, но главное, что они точно знали, какие задачи нужно было решать и кто именно им нужен, что далеко не всегда верно даже сегодня!
Собственно, собес:
- Две задачи по терверу, одна из которых нередко попадается и сейчас. Вторая на смесь комбинаторики с тервером на расчет агрегированных показателей ТВ охватов. Простой вариант затащил, а сложный - облом, причем как оказалось потом, эту задачу они сами не могли решить за вменяемое время (спойлер: потом мне ее как раз и дали в течение первых месяцев)
- Кодинг на бумаге: обход бинарного дерева в глубину. Кажется ерундой, но позиция стажерская да и без подготовки далеко не все мидлы осилят (сужу по опыту собесов уже со стороны собеседующего)
- Поскольку питона тогда в отделе еще и в помине не было, основным языком разработки был C# и требовалось знать и его, чтобы в первое время интегрировать наработки в существующую систему. C# на тот момент я уже год как изучал в универе, поэтому здесь тоже все было ок
- Вопросы по дипломному проекту. Как собирал данные, как строил модель, как валидировал и как это потом можно будет внедрить. Не очень-то отличается от того, что спрашивают сегодня, а это, еще раз напомню, стажерская позиция.
- Какие задачи интересны, чем хотелось бы заниматься .. бихейв. Здесь тоже сошлись

В итоге проработал в этой компании больше 3 лет и очень благодарен людям за наставничество.

Leetcode for ML

Super neat set of machine learning coding challenges.

It could be useful to prep for an exam or ML interview.

Link

Navigational hashtags: #armknowledgesharing #armsites
General hashtags: #ml #dl #machinelearning #deeplearning

Все наслышаны с избытком про LLM и про NVIDIA, которая прославилась беспрецендентным ростом благодаря продаже чипов, своебразных "лопат" для бигтехов, разрабатывающих AI. Этот факт подсвечивает проблему монополии на рынке чипов. Но есть еще ряд компаний, не столь популярных, но играющих не менее важную роль в этом процессе. И если у NVIDIA есть более-менее достойные конкуренты, то вот среди производителей чипов рынок производителей еще уже. Самих по себе производителей чипов в мире много, но здесь речь именно о самых передовых чипах с техпроцессом <10 нМ - именно они используются для AI и в современных компьютерах и смартфонах. Так вот дело в том, что компания TSMC производит большую часть таких чипов, и именно от нее почти полностью зависят Apple и NVIDIA (Apple когда-то делала свои чипы на заводах Samsung, но поскольку это прямые конкуренты на рынке смартфонов, то было решено перенести производство на TSMC). TSMC удивительная компания, которую называют "странообразующим" предприятием для Тайвани. У TSMC положение не только монопольное, но еще довольно уязвимое: мало того что Китай постоянно угрожает Тайвани войной, так еще и сам остров Тайвань находится в сесмоопасной зоне и землятресения там не редкость. Понятно, что у TSMC есть заводы и в других странах, но они производят менее современные чипы. Так что если с TSMC что случится, то последствия для мировой экономики будут катастрофическими. Рекомендую посмотреть вот этот видос про TSMC.

Но и TSMC в свою очередь находится в зависимости от одной малоизвестной компании - нидерландской ASML, которая произвоизводит литографические машины, которые и создают "рисунок" из транзисторов на кристалле. И здесь ситуация аналогичная самой TSMC: производителей литографов в мире много, но вот для самых передовых чипов здесь ASML монополист. Эти машины - настоящее инженерное чудо (рекомендую вот это видео про ASML): тысячи уникальных компонентов, миллиарды долларов инвестиций в исследования и десятки лет разработок, причем при поддержке со стороны мировых производителей электроники, которые между собой конкурируют - неудивительно, что такая компания будет уникальной. Так что если с ней что-то произойдет, то TSMC останется без средств производства, ну и далее - те же последствия. Так что весь технологический мир сегодня буквально зависит от этих двух компаний.

Write faster Python code, and ship your code faster

Faster and more memory efficient data
- Articles: Learn how to speed up your code and reduce memory usage.
- Products: Observability and profiling tools to help you identify bottlenecks in your code.

Docker packaging for Python
- Articles: Learn how to package your Python application for production.
- Products: Educational books and pre-written software templates.

Navigational hashtags: #armknowledgesharing #armsites
General hashtags: #python #development #docker

1 сентября... 20 лет назад я стал студентом МАИ, 10 лет назад - студентом МГУ. В этот раз похвастаться чем-то похожим, не могу😁

AWS based risk engine (part 1)

Наконец-то с коллегами осуществили вывод в прод написанного за 5 месяцев с нуля risk engine (не знаю точного перевода на русский, но среди русскоговорящих коллег мы называем это “риск-движок”) для нигерийского финтеха.

Что это такое и для чего нужно?
Risk engine - это совокупность скоринговых моделей, антифрод моделей и правил (они называются policies или по-нашему “политики”), которые в определенной последовательности обрабатывают заявки клиентов на выдачу кредитов и принимают решение о выдаче, а также сроке и процентной ставке, если решение о выдаче положительное.

Как это работает?
Клиент отправляет заявку на кредит через мобильное приложение или сайт, по предоставленной клиентом информации запрашивается его кредитная история из БКИ, обогащается данными с его мобильного устройства, дополнительно запрашиваются данные из баз о мошенниках и из прочих источников. Все эти данные идут на вход риск-движка. Сначала он поочередно опрашивает антифрод модели, которые определяют вероятность мошенничества, затем скоринговые модели, которые прогнозируют вероятность невозврата кредита. Ответы от моделей используются политиками (которые представляют собой около сотни правил вроде “если возраст < 25 лет, то ставку нужно поднять” и т.д.) для принятия решения о выдаче. Решение отдается в бэкенд, и далее уже запускается механизм выдачи кредита или информирования об отказе.

Как это работало до нас?
Использовалась кастомная платформа (примеры: раз, два). Они все как один заявляют, что если вы дадите им ведро денег, то они вам все настроят один раз, а дальше вы будете как в зерокодинге соединять квадратики стрелочками, ничего программировать не надо, и никакие дорогостоящие инженеры вам не понадобятся! Как оно оказалось на самом деле? Комментировать особо не стану, легко можно догадаться, что почти так же, как и с зерокодингом:) Упомяну лишь, что задеплоить простой логрег на десяток фичей занимало до 2 недель. Зато без дорогих инженеров!

AWS based risk engine (part 2)

Что сделали?

- За основу взяли AWS Step functions (SF), на которые идеально ложится логика работы движка, по сути это граф или блок-схема, состоящая из логических блоков. Словами эти блоки можно описать так:
Возьми входной джейсон. Если такая заявка уже была, то сходи в S3 за ее логами и верни как ответ. Если нет, то вызови скоринговую модель, затем антифрод модель передай ответы в политики. Выполни цепочку из политик (последняя из них собирает решения всех предыдущих блоков и принимает решение). Залогируй ответ и отдай его бэкенду.

- Каждый блок SF может быть lambda (политики и простые модели), sagemaker endpoint (модели посложнее), внешнее API (запросы внешних данных) или тоже SF, которые в свою очередь состоят из аналогичных элементов.

- На этапе прототипирования, когда нужно было доказать руководству жизнеспособность этого решения, эти блоки создавались вручную через AWS консоль. Но, понятное дело, что далеко так не уйдешь. Поэтому для промышленного решения после одобрения все блоки прописывали в CloudFormation (амазоновский аналог Terraform), для создания однотипных блоков вроде лямбд взяли jinja, настроили CI/CD и тесты.

AWS based risk engine (part 3)

Результаты?

- Сокращение инфраструктурных затрат почти в 20 раз! Serverless решает, когда вам не нужно что-то эдакое, где AWS упирается в потолок возможностей.
- Выкатка новой модели - 1 час вместо недели. Да, для этого нужен дорогостоящий инженер. Но зато только один, и платить нужно только за один его час, а не за неделю:)
- Возможность мгновенно развернуть несколько независимых контуров (по сути копий движка), обычно это dev, stage, prod.
- Возможности масштабирования, задеплоить можно хоть сотню моделей
- Тесты, которые спасают от сердечных приступов при выкатке в прод

Недостатки есть?

Конечно, я же не продаю вам коробочки со стрелками за ведро денег :)

- AWS Step functions имеет лимит на размер входного джейсона в 256Кб, что не так уж много, поэтому много данных передать таким способом не получится.
- Пока не знаем, как подружить Grafana с CloudWatch (это встроенный сервис логирования в AWS), а мониторинг очень нужен. Ну и встроенный в Sagemaker мониторинг моделей уж очень убогий.
- Графы в Step functions описываются своим собственным языком, который очень далек от идеала и можно провести часы, роясь в доке, чтобы вкурить, что не так. И да, ChatGPT вам тут не сильно поможет, т.к. на этом языке не так много всего в мире написано.

Скоро выложим статью с подробностями.

Любопытная статья (сорри, пэйволл) про добавление монотонных ограничений в бустинговые модели. Показан пример с ценами на недвижку, где по балльной оценке ее "состояния" от 1 до 10 и цене, за которую ее агентство изначально покупало, строится модель оценки цены, за которую ее можно перепродать. Логично, что конечная цена должна монотонно зависеть и от начальной цены и от состояния, но из-за шума в данных и небольшой выборки эти правила могут нарушаться при обучении модели. Тогда можно добавить искусственные ограничения на монотонность, что при фикс начальной цене, конечная цена монотонно растет при росте начальной цены, что звучит вплоне логично. Т.е. мы как бы искуственно добавляем наши доменные знания в модель, которые она может и не "добыть" исключительно из данных, если их немного и/или они некачественные.

Другой пример, с которым лично столкнулся недавно. В кредитном скоринге обычно участвует доход заемщика (опустим сейчас детали, как именно он может быть получен, когда заемщик в анкете врет). Модель показала, что с ростом доходов надежность заемщика сначала растет, но потом неожиданно начинает снижаться, что странно. Продакт, принимающий модель, указал на эту проблему и обоснованно потребовал переделать модель так, чтобы с ростом дохода благонадежность тоже монотонно росла. Но как быть, если модель - лог рег, основанный на биннинге + WOE? Оказывается, либа для биннинга, которую недавно обсуждали, например тут, тоже так умеет! Для этого нужно поставить нужное значение параметра monotonic_trend , тогда вещ фича будет разбита на интервалы так, что средний таргет изменяется монотонно, без максимумов/минимумов где-то посередине

Вакансия (и не одна) DS в ASML

Доклад про Polars c Датафеста-2024

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

Эксклюзивный контент!

Ищем в наш нигерийский банк DS с уклоном в риск-аналитику.

Задачи - развивать риск-движок, "пополнять" его новыми моделями, интегрировать новые истоники данных и многое другое.
Подойдет тем, кто хочет в перспективе выйти на международный рынок труда, освоить "мировые" облачные технологии (AWS) и при этом работать на удаленке из РФ. Год назад здесь не было буквально ничего, так что работать еще есть над чем, многое предстоит сделать с нуля.
Точно не подойдет, если вы привыкли, что все данные разложены по полочкам, все процессы выстроены и каждый занимается только своими задачами. Плюс много общения с нигерийцами, что требует много усилий и терпения.

Писать в личку.

Простая на первый взгляд задачка

потрясающий текст про закат компании ABBYY как наименьшее из последствий краха всей компьютерной лингвистики под натиском статистических моделей языка. Пластмассовый мир chatGPT победил все попытки построить детерминированные онтологии, а способ решения любой проблемы "завалить вычислительными мощностями", оказался более надежным и масштабируемым, чем любая попытка разобраться что же происходит внутри системы (и язык здесь только один из примеров)

по ссылке обзор развития компьютерной лингвистики от ранних моделей до трансформеров, которые появились как способ улучшить качество гугл-переводчика, расцвет ABBYY как одной из самых успешных российских ИТ-компаний, почти академическая культура физтехов внутри, «горький урок» больших данных и сгоревшие сотни миллионов долларов на амбициозную попытку построить дерево онтологий всех языков сразу (ABBYY compreno).

про мегапроект ABBYY compreno я когда-то очень давно случайно увидел статью и будучи студентом физиком, конечно, был очарован масштабом. это же такая мечта технаря в вакууме: давайте мы все тексты сведем к логическим инвариантам, соединим их стрелочками и построим граф всего языка. то есть к сущностям типа собака / стол / книга, которые не теряют своей сути при переезде между странами. тогда для перевода между языками можно будет делать преобразование в этот мета-язык и из него в еще один шаг переводить тексты в любой другой. впечатлился, посмотрел на страшные диаграммы простых предложений (скину их в комменты, зацените) и забыл об этом на долгие годы. но конечно и представить не мог, сколько копий было поломано и сколько ресурсов потрачено (получается, что впустую).

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

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

очень рекомендую прочитать целиком: https://sysblok.ru/blog/gorkij-urok-abbyy-kak-lingvisty-proigrali-poslednjuju-bitvu-za-nlp/

ML and LLM system design: 500 case studies to learn from

How do companies like Netflix, Airbnb, and Doordash apply AI to improve their products and processes? We put together a database of 500 case studies from 100+ companies that share practical ML use cases, including applications built with LLMs and Generative AI, and learnings from designing ML and LLM systems.

Navigation tips. You can play around with the database by filtering case studies by industry or ML use case. We added tags based on recurring themes. This is not a perfect or mutually exclusive division, but you can use the tags to quickly find:
- Generative AI use cases. Look for tags “generative AI” and “LLM” to find examples of real-world LLM applications.
- ML systems with different data types: computer vision (CV) or natural language processing (NLP).
- ML systems for specific use cases. The most popular are recommender systems, search and ranking, and fraud detection.
- We also labeled use cases where ML powers a specific user-facing "product feature": from grammatical error correction to generating outfit combinations.

Link: Site

Navigational hashtags: #armknowledgesharing #armsites
General hashtags: #mlsystemdesign #ml #systemdesign #llm

Почти в каждом deep learning-based продукте, над которым я работал, на каком-то этапе где-то сбоку появляется небольшая линейная модель, обучаемая отдельно, иногда даже на классических фичах. Она, конечно, не может решать основную сложную задачу, но внезапно сильно помогает с каким-нибудь корнеркейсом. Например:
- определять резкую смену контекста (и необходимость сбросить стейт),
- детектить потенциальные ошибки или аномалии,
- слегка уточнять результаты сложного пайплайна,
- роутить инпут между компонентами,
- заполнять недостающий параметр, если в API вдруг не приходит какое-то поле, а менять что-то на клиенте слишком дорого,
- подсвечивать потенциальные проблемы человекам in the loop.

Этой модели никогда нет в изначальном дизайне: если проблема была бы заметна изначально, она бы зачастую решалась элегантнее - например, добавлением дополнительной головы в основную модель. Она появляется, когда все вроде почти работает, и не хватает совсем чуть-чуть.

Вот сейчас у меня есть матрица расстояний в чем-то вроде матчинга, и нужно оценивать уверенность матча, потому что иногда лучше ответить ничего, чем неправильно. Сначала берешь собственно дистанцию, потом хочется добавить еще пару эвристик типа расстояния до second best кандидата, их нужно как-то взвешивать... Так что не надо брезговать классикой, и умение выжать лишний процент из линейной модели все еще полезно.