#ml #dl

Привет, Друзья!

Копалась в интернете — нашла золото: библиотека NNsight

Смысл:

За счет некоторых оптимизаций, они позволяют обвешивать Hf модельки так, чтобы извлекать скрытые состояния для дальнейшего анализа.

Преимущества:

Скорость запуска и удобный интерфейс. Плюс понятные туториалы с красивыми картинками.

Практика:

1. Убедиться в скорости запуска моделей не успела, а вот в удобстве интерфейса — да. За счет того, что библиотека обвешана туториалами, удобно как минимум в образовательных целях пробовать их для себя.

На то, чтобы восстановить метод Logit Lens без либы у меня ушло +/- 3 часа (два — просто на визуализацию результата), так что, повторюсь, если хотите просто «потрогать метод» — must have.

2. Не все модели с Hf грузятся.

Примечание:

Как пишут авторы, библиотека находится на стадии становления. Ребятам удачи, действительно классный проект, и я не могла пройти мимо.

А завтра пятница, и я желаю вам провести её так, чтобы вечер был полностью ваш!

Со всем самым добрым,
Ваш Дата-автор!

P.S. Спасибо за поддержку на YouTube! Вы — лучшие ❤️

#ml #petproject

#дипломный_проект
#data_preprocessing

Часть 1.

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

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

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

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

Часть 2.

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

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


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

Часть 3.

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

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

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

Диплом был успешно защищен, а вот внедрение проекта не состоялось. Во-первых потому, что еще перед защитой я после 8 лет работы инженером нашел стажировку на позицию data scientist. А во-вторых, это уже была гораздо более трудная для меня на тот момент задача, требующая значительных изменений в порядке работы сервисного отдела. Однако, рассказ об этом проекте очень хорошо продавался на собеседованиях еще очень много лет! И поскольку на “добычу” и предобработку данных у меня суммарно ушло до 80% всего времени (я здесь не учитываю затраты на оформление проекта в дипломную работу) и только 20% на само моделирование, то с самого первого проекта я очень хорошо знаю, что подготовка данных зачастую важнее непосредственно моделирования.

#systemdesign #interesting

Как работает диспатчеризация байткода внутри VM? Tail call dispatch

(перед прочтением – советую прочитать пост ^ про computed goto)

https://github.com/python/cpython/pull/128718

В CPython новая оптимизация, которая дает где-то 5% производительности. Я уже рассказывал, что такое computed goto, но теперь есть еще более прикольная и быстрая штука для диспатчеризации байткода.

То есть: вызов следующего опкода в Python коде будет быстрее, а значит – все программы просто бесплатно станут быстрее.

(не путать с tail call оптимизацией для рекурсии)

Как работает?

Сначала делаем два макроса, которые будут устанавливать нужные атрибуты для компилятора.
Пока только [[clang::musttail]], про поддержку компиляторов будет ниже. Зачем нужен preserve_none – можно прочитать тут.

#ifdef Py_TAIL_CALL_INTERP
    // Note: [[clang::musttail]] works for GCC 15, but not __attribute__((musttail)) at the moment.
#   define Py_MUSTTAIL [[clang::musttail]]
#   define Py_PRESERVE_NONE_CC __attribute__((preserve_none))

// Для простоты еще два макроса, просто слишком часто повторяется код:
#define TAIL_CALL_PARAMS _PyInterpreterFrame *frame, _PyStackRef *stack_pointer, PyThreadState *tstate, _Py_CODEUNIT *next_instr, int oparg
#define TAIL_CALL_ARGS frame, stack_pointer, tstate, next_instr, oparg

Далее, создаем новый тип колбеков для "tail-call функций":

Py_PRESERVE_NONE_CC typedef PyObject* (*py_tail_call_funcptr)(TAIL_CALL_PARAMS);

Важный шаг: меняем дефиницию макросов TARGET и DISPATCH_GOTO по аналогии с computed gotos.
Теперь тут будет:

#   define TARGET(op) Py_PRESERVE_NONE_CC PyObject *_TAIL_CALL_##op(TAIL_CALL_PARAMS)
#   define DISPATCH_GOTO() \
        do { \
            Py_MUSTTAIL return (INSTRUCTION_TABLE[opcode])(TAIL_CALL_ARGS); \
        } while (0)

То есть теперь по факту – все TARGET макросы будут разворачиваться в отдельные функции:

Py_PRESERVE_NONE_CC static PyObject *_TAIL_CALL_BINARY_OP(TAIL_CALL_PARAMS);

В теле такой функции будет очень мало кода – только обработка ее логики. Пример для BINARY_OP.
Вот они, для каждого опкода:

Py_PRESERVE_NONE_CC static PyObject *_TAIL_CALL_BINARY_OP(TAIL_CALL_PARAMS);
Py_PRESERVE_NONE_CC static PyObject *_TAIL_CALL_LIST_APPEND(TAIL_CALL_PARAMS);
// ...

И мы так же ищем следующий опкод в INSTRUCTION_TABLE[opcode], но теперь мы вызываем функцию, которая там лежит в DISPATCH_GOTO. То есть теперь – у нас теперь есть буквально:

callbacks = {
    'BINARY_OP': lambda *args, **kwargs: ...
    'LIST_APPEND': lambda *args, **kwargs: ...
}

callbacks[opcode](*args, **kwargs)

И во время конфигурации сборки питона – проверяем, поддерживает ли наш компилятор такое.

Так почему быстрее?

Теперь – все функции маленькие, их удобно оптимизировать. Вот тут уточнение из комментов.

Потому что для [[mustail]] не создается дополнительный стекфрейм, asm получается более оптимальным. Я подготовил для вас пример: https://godbolt.org/z/T3Eqnd33e (для таких простых случаев -O2 более чем работает, но все равно)

Для вызова функции foo(int a) было:

mov     edi, dword ptr [rbp - 4]
call    foo(int)@PLT
add     rsp, 16
pop     rbp
ret

Стало:

mov     edi, dword ptr [rbp - 4]
pop     rbp
jmp     foo(int)@PLT

call -> jmp!

Статья по теме от автора __attribute__((musttail))

Ограничения

Пока что данное поведение скрыто за флагом --with-tail-call-interp, по-умолчанию в 3.14 оно работать не будет. В следующих версиях – включат по-умолчанию для всех.

Есть еще и техническое ограничение. Пока что такой __attribute__ компилятора поддерживает только clang в llvm>=19 на x86-64 и AArch64. В следующем релизе gcc, вроде бы, завезут поддержку

Ну и последнее: пока проверили только перформанс с Profile Guided Optimization (pgo), сколько будет без него – еще не мерили. Сначала вообще заявили прирост на 15%, но потом нашли баг в llvm, который замедлял код без такой фичи.

Да, у нас тут с вами душный канал, где нет ярких заголовков :(

Обсуждение: чего ждете от 3.14 больше всего?

| Поддержать | YouTube | GitHub | Чат |

#dl #systemdesign

Apprise

Очень часто нам нужно оперативно получать информацию о том, что происходит с сервером, программой или пайплайном. Но смотреть дашборды 24/7 — занятие, которое приносит мало удовольствия. В то же время, все мы ежедневно пользуемся мессенджерами и электронной почтой.

Для решения этой проблемы на помощь приходит Apprise — универсальная библиотека для отправки уведомлений. С его помощью вы сможете быстро и удобно настроить доставку сообщений в любые привычные сервисы — от Telegram и Slack до электронной почты и SMS. Установка и настройка занимают минимум времени — достаточно добавить несколько строк кода. В новой статье мы подробно расскажем, как это можно сделать и интегрировать уведомления в ваш проект: https://deepschool-pro.notion.site/Apprise-1ab640e53434803391b9d2a46b6f9295?pvs=4

What happens when...
you type google.com into your browser's address box and press enter?

This repository is an attempt to answer the age-old interview question "What happens when you type google.com into your browser's address box and press enter?"

Except instead of the usual story, we're going to try to answer this question in as much detail as possible. No skipping out on anything.

This is a collaborative process, so dig in and try to help out! There are tons of details missing, just waiting for you to add them! So send us a pull request, please!

Link: GitHub

Navigational hashtags: #armrepo
General hashtags: #systemdesign

@data_science_weekly

#ml #systemdesign