#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

Я принес. Как искать работу IT-менеджеру?

Я частенько смотрю и слушаю подкаст ITBizRadio. Недавно там один из участников вышел на рынок труда ИТ-менеджеров и рассказал о своем опыте. В целом интересно послушать не в формате общих обзоров каких-нибудь рекрутеров, а вот прям на практике, что и как человек делал, с чем столкнулся, как получилось.

Ребята сделали 2 выпуска. Я уже посмотрел полтора.
1. https://www.youtube.com/watch?v=a8KLQ6PCiik
2. https://www.youtube.com/watch?v=1nMIoVsi7uM

Я искал работу в виде тимлида/тимлида тимлидов/технического менеджера/деливери менеджера 2 года назад. Опыт в чем-то был похожий.

От старта до выхода на работу прошло примерно 3 месяца. Пообщался с 5–6 компаниями, прошел всякие разные пайплайны собеседований, других посмотрел, себя показал)

Потом общался на конференциях с другими тимлидами/менеджерами, они так же примерно тратили месяца 3, если искать придирчиво, не кидаться на абы что.

Проектов много, а команда одна

Пока выбирал тему для очередного пятничного поста, копался в бэклоге и увидел, как меня полгода назад просили об этом написать, а я то ли забыл, то ли забил 🙁

Команда — заказчик — продукт/проект — сосредоточенная работа
За последнее время ко мне пришло несколько людей, у которых команды имеют четкие границы ответственности и приоритеты. Вот кроссфункциональная команда, вот продукт / модуль / сервис, вот продакт, генерящий идеи, или вот основной заказчик, приносящий хотелки. Там неплохо приживается классический скрам с понятным скоупом, целями спринта, демкой в результате и такой вот методичной итеративной моделью.

Команда — куча заказчиков — куча продуктов/проектов — замес
А бывает и так, что команда одна, а продуктов и разных проектов – больше даже, чем людей в команде. И сейчас мне кажется, что вроде всё понятно, надо просто удачно жонглировать этими горящими бензопилами и никогда не хвататься за лезвие. Но я вспомнил, как это фрустрировало меня раньше, и решил, что надо хоть чего-то полезного написать, что поможет на всех стульях посидеть и не разорваться.

Планирование
Про планирование я отдельно писал тут https://t.me/general_it_talks/760. Спойлер: заложить часть на плановую работу, часть – на саппорт, техдолг, возгорания и часть – на человеческий фактор (отпуска, болезни, ротация и прочее).

Еще тут я бы добавил, что для планирования хорошо иметь конкретные временные окна, чтобы каждый знал, когда надо суетиться и заносить заказы, а не вбрасывать потом, когда всё уже отранжировано и запланировано.

Выявление приоритетов
Заказчиков много, хотелок много, каждый считает, что ему надо ну прям обязательно. Это нормально. И точно так же нормально заколебывать всех вопросами, уточняющими НАСТОЯЩИЙ приоритет. Типа «что будет, если мы не успеем сделать эту задачу?», «что именно для вас блокируется от этой задачи?» и т. д. Тогда может оказаться, что блокер не такой уж и блокер, например.

ЛЮДИ
Написал капсом, потому что нужно прямо очень хорошо понимать своих соколов (кто узнал отсылку к «Кремниевой долине», ставьте молнию). Кто-то умеет забуриться в глубь сложной задачи, вынырнуть спустя неделю со всеми нужными решениями. Кому-то трудно долго вглубь, но вширь на все проекты – легко. Кто-то любит медитативно молотить огромные объемы монотонной работы.

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

А еще надо помнить, что люди и от вышеперечисленного могут устать, демотивироваться, захотеть разнообразия, так что это та еще шахматная партия на N шагов вперед. Но оно того точно стоит. И дела будут хорошо сделаны, и команда довольна.

Скрамбан
Я писал выше, что где-то скрам работает неплохо. Вот в случае, когда 1 команда и много разного замеса со всех сторон, я эмпирическим путем пришел к некоему мутанту скрама и канбана. Я разговаривал с рядом опытных менеджеров из разных компаний от мала до велика. Обычно люди приходят на своем опыте примерно к одному и тому же 🙂

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

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

А тимлид и техлид (или тимлид и ПМ, или кто еще у вас отвечает за технику и за проекты) раз в неделю собираются и причесывают бэклог согласно а) требованиям заказчиков, б) внутренних технических потребностей.

Итог
Я уверен, что что-то я точно забыл, а на что-то мне просто не хватило места в посте. Мне и так 2к символов пришлось удалить.