Я когда-то писал про residential proxies, и вот случайно наткнулся на еще один способ, как такие компании набирают себе пул прокси.

Захотел поставить на телевизор Apple TV, пошел в LG app store, глаз зацепился за приложение Xmas Tree в блоке рекомендаций. Как нетрудно догадаться, приложение показывает елку на фоне горящего камина, но в настройках есть чекбокс "Режим HD" с любопытной подписью мелким шрифтом типа "Разрешить bright data ltd использовать вашу сеть". Bright data - один из крупных поставщиков прокси, на одной из прошлых работ использовали их как раз для парсинга цен конкурентов.

Киберпанк, который мы заслужили: рождественская OLED елка, которая в фоне что-то скрапит.

P.S. Всех с рождеством! 🎄🎅

Для тех, кто предпочитает аудиовизуальный контент, а не эту всю писанину: поговорили с Антоном, одним из самых крутых инженеров и спикеров в русскоязычной computer vision тусовке. Обсудили Copilot, chat GPT и прочие LLM-based инструменты, и как они могут повлиять на околоDS карьеры.

Увидел очередную статью про определение людей и их поз по WiFi-сигналу, и нахлынули воспоминания.

Идея "видеть сквозь стены через wifi" не отпускает ресерчеров уже давно, не меньше 10 лет. На этот раз к ней подошли через любимый мной densepose (я пару раз пытался применять его в работе, но всегда выживал какой-нибудь другой подход), и вроде даже работает. Я склонен верить картинкам и метрикам, потому что Fernando De la Torre - чувак довольно авторитетный!

В умеренно далеком 2019, когда я рисовал AR-кроссовки, на CVPR меня познакомили с Фернандо, который на тот момент был менеджером AR-ресерча в Facebook. Прекрасный шанс запитчить наши наработки и попасть на радар к Facebook, который тогда еще активно покупал стартапы. И вот, после нескольких минут хвастовства, какое у нас технологически охуенное приложение, он задал мне простой вопрос: "окей, приложение хорошее, а в чем ваша команда по-настоящему, на мировом уровне, сильна?". Я растерялся, пробубнил что-то невнятное, и Фернандо мгновенно утратил к нам интерес. Так я просрал шанс, но и он упустил шанс получить промо, недорого прикупив клевых белорусских гребцов.

Кстати, вопрос "в чем ты крут на мировом уровне" мне задавали с тех пор еще один раз, и я снова ответил уклончиво. Хороший повод для карьерной рефлексии!

Применил на работе прием, который считал общеизвестным, но, судя по реакции коллег, это не совсем так. Потому расскажу и здесь!

Предположим, для какой-то ML задачи нужна ручная разметка данных, и расходы сколько-то заметны💰 (а значит, в 2023 их наверняка предложат урезать 🔪). В такой ситуации хочется хотя бы приблизительно понимать, как эти инвестиции в разметку окупаются.

Мое сколько-то наивное решение такое:
- делим тренировочный датасет на бакеты так, минимизируя разницу размеров бакетов и некоторое сходство между семплами разных бакетов (например, все семплы одного пользователя попадают в один бакет, который определяется на базе хэша его id);
- фиксируем вычислительный бюджет (вне зависимости от размера датасета учимся на N батчей);
- учим модель на сабсетах в диапазоне от малой части датасета до целого датасета, обеспечивая кумулятивного увеличение датасета (например, если некий семпл X был в обучении на 10% сабсете, то он обязательно будет и в обучении на 20% датасета);
- для каждой обученной модели смотрим ключевую метрику и рисуем график: по оси X - размер датасета, по оси Y - улучшение метрики;
- включаем воображение и оцениваем с точностью до порядка, сколько данных нужно досыпать, чтобы выжать следующий 1% метрики.

Точность такой экстраполяции оставляет желать лучшего (например, совершенно не учитывает штуки типа concept drift), но она значительно лучше, чем "хер его знает!", и сильно упрощает принятие решений типа "что выгоднее: отправить джуна подбирать гиперпараметры или нанять десять разметчиков и дальше заваливать модель данными".

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

Задача такая: из некоторого списка тегов отбираем наиболее важные по словарю рангов, формируем промпт и отправляем в модель. Что не так с этим кодом?

import typing as t


def predict_from_tags(model: BertModel, tags: t.Sequence[str]):
    prompt = prompt_from_tags(tags, model.tag_ranks)
    return model.predict(prompt)


def prompt_from_tags(tags: t.Sequence[str],
                     tag_ranks: t.Dict[str, float],
                     max_tags: int = 20,
                     allow_duplicates: bool = False,
                     ) -> str:

    if not allow_duplicates:
        tags = list(set(tags))

    sorted_tags = sorted(tags, key=lambda x: tag_ranks.get(x, float("inf")))
    return " ".join(sorted_tags[:max_tags])

Автор первого правильного ответа в комментариях не получит ничего, кроме респекта от таких же любопытных, которым зачем-то интересно просто так искать баги в чужом коде.

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

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

Мой босс был отличным мужиком, который в т.ч. ценил шутки. И вместо того, чтобы выдать мне заслуженных пиздюлей, он отсмеялся и начал диктовать мне следующий пранк-емейл своему другу и коллеге: "Уважаемый Н.Г.! Просьба явиться завтра в 13:00 по адресу [главное управление КГБ Беларуси] для проведения оперативно-розыскных мероприятий…".

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

Грустная ирония всплыла в новостях спустя 12 лет. С подачи КГБ уважаемый Н.Г. внесен в список лиц, причастных к «финансировании террористической деятельности», что в переводе с белорусского мусорского новояза чаще всего значит что-то очень достойное.

Давно ничего не писал про прогресс с книгой, а ведь он есть!

Позавчера созванивались с новым редактором книги по ML System Design - предыдущий уволился после пяти глав, интересно, насколько велик наш вклад в его решение. Новый редактор оказался приятным и толковым дядькой, хотя его linkedin сначала вызвал у меня скепсис: например, до работы в издательстве он долго работал в одной компании на позициях типа Senior XML Architect 🤯. Но большe меня удивило то, что он одновременно работает над 18 (!) книгами. Я бы свихнулся от такого переключения контекстов.

А вообще мы обсуждали early access: продажи книги Chip Huyen ярко подтвердили интерес к теме; и мы, и издательство хотим зарелизить первые главы до окончания всей книги. Сейчас в работе седьмая глава из семнадцати запланированных, в ранний доступ пока планируется выложить пять глав, и добавлять примерно по главе в месяц.

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

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

Кстати, про IDE - утащу из одного чатика инсайд от сотрудника Jetbrains:
> В JB было сделано внутреннее исследование, сколько кодят разработчики - и выяснилось, что почти по всем языкам это порядка 10 строк кода в день в среднем; потом это исследование решили не публиковать.

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

Когда именно с этим парадоксом сталкивается конкретный IC, зависит от окружения. Эвристика простая: чем более ты сеньорный относительно прочих в своей команде/организации, тем меньше кода нужно писать. И потому на каком-то этапе карьеры надо либо осознанно перековываться в человеки-которые-[почти]-не-пишут-код, либо целенаправленно идти в такой орг, где личная максимальная полезность оказывается именно в написании кода, обычно это какие-то сложные специфические системы, и такого в индустрии маловато.

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

Большую часть своей ML карьеры я был участником сообщества Open Data Science aka ODS.ai: сначала скромным читателем, потом активным комментатором, примерно с 2017 - одним из админов. В 2017-2019 мы сделали три датафеста в Минске, собрали большую тусовку местных data-related людей, я лично познакомился с кучей отличных людей: с кем-то мы работали, с кем-то рубились в Kaggle, с кем-то вместе разбирались в сложных статьях или понемногу контрибьютили в опенсорс, с кем-то просто трепались и пили пиво.

В ODS активно контрибьютили сотни людей; благодаря ODS многие, включая меня и значительную часть читателей канала, сильно выросли профессионально, но тусовка, которая сложилась там, лично для меня еще важнее.

Сообщество начало сколько-то увядать в ковидные времена: сложно поддерживать большое количество слабых социальных связей fully remote. Но по-настоящему все треснуло с началом войны: где-то проявились латентные "где вы были восемь лет" ватники, где-то, наоборот, люди начали уходить, возмущенные отсутствием яркого антивоенного консенсуса. Появились вопросы к основателю коммьюнити насчет его связей с государством, не получившие толком ответов. Наконец, недавно Slack пообещал окончательно закрыть все организации с российскими корнями. Это все привело к диссоциации: от ODS откололось не меньше пяти разных коммьюнити на разных платформах.

Вместе с группой друзей мы вспомнили принцип "If you can't beat them, lead them" и тоже сделали форк - singularis.ai. Это тоже Slack-чат, среди админов - исключительно достойные люди, которых я давно и хорошо знаю. Мы хотим сохранить тот дух научного и профессионального любопытства, который когда-то царил в ODS, но избавиться от токсичности и вотэбаутизма, и, конечно, никак не будем заигрывать ни с каким государством.

Нас уже больше двух тысяч, join us, we have no cookies.

Предсказание: в ближайшие пару лет Rust наконец-то пойдет в массы.

Rust уже давно был в странной позиции самого любимого языка, на котором пишут в основном пет-проекты и редкие системы с повышенными требованиями к безопасности (читай веб3 и криптографию). Порог входа относительно высокий, разработчиков на рынке мало - нужно быть довольно рисковым, чтобы стартовать новый проект на нем. Но кажется, что для него есть еще две созревшие ниши:
1) очевидная - язык для dev-инструментов,
2) неочевидная - быть вторым языком в проекте.

Эти две ниши хорошо сочетаются.

Rust хорошо интегрируется с двумя самыми популярными языками современности: c Python через maturin, с JS через WebAssembly. Я не знаком с миром JS, видел краем глаза пару примеров дев-тулов на расте. В Python тусовке знаю больше: набирающий популярность линтер, два популярных токенайзера
(второй используют OpenAI!), новая версия валидатора pydantic. Уверен, что в течение пары лет появится популярный Python веб-фреймворк типа FastAPI/Starlite с ядром, написанным на расте.

И тут я наконец вверну кусок про LLM. У нас на работе Rust уже давно использовался именно как второй язык бэкенда, для ускорения узких мест, и за день перед отпуском (не начинать же Большую Задачу) в обучающих целях я решил слегка ускорить кусок препроцессинга. Нашел профайлером пару относительно медленных функций, скормил их в GPT-4, получил аналог на расте, поправил пару мест, повозился с интеграцией, получил комментарий на ревью от человека, который, в отличие от меня, на расте писать умеет, починил, смержил. Короче, оно уже в проде (люблю запах деплоя пятничными вечерами!), экономит 1 ms на запрос (в масштабах тысяч RPS имеет некоторый смысл), а ведь я даже учебник по расту не дочитал.

В мире JS уже есть даже специальные курсы типа Rust for JS devs. Думаю, автор учебника Rust for Python developers будет крайне успешен. Если кто-то из читателей хочет этим заняться, но не знает, как начать, пишите - поделюсь опытом работы с издательством.

Вчера летел ранним рейсом в шесть утра, и в самолете сонно писал очередную главу для книги (кстати, надеюсь, что в течение месяца первые главы будут доступны в early access). У меня не было иллюзий, что текст будет качественным: план я набросал раньше, но согласованность предложений, грамматика и общий стиль явно страдали от депривации сна.

С другой стороны, в 2023 good prompt is all you need (хотя некоторые ресерчеры не согласны). Значит, можно взять главу, разбить на части, и отправить их на GPT-корректуру. Понадобилось несколько уточнений в промпте, чтобы "корректор" не становился "редактором": был не слишком активным в изменениях, чистил фигню, но более или менее сохранял стиль.

Но ведь хороший редактор это тоже полезно! Только если правки корректора можно принимать практически не глядя, то замечания редактора - это как комментарии на code review, над ними нужно подумать, но далеко не на все нужно реагировать изменениями. Значит, надо усовершенствовать промпт: ...If there is a statement that seems to be wrong, suggest a detailed comment in a square brackets, e.g. [This might be wrong because ...], and keep the sentence as is.

Для теста добавил в часть про training pipeline такое:

...Using training pipeline is dangerous as it could be poisonous. There are 1 million people who died from poisonous training pipelines.

На выходе:

...[The statement "Using training pipeline is dangerous as it could be poisonous. There are 1 million people who died from poisonous training pipelines." seems to be incorrect and irrelevant to the topic. Please consider removing it.]

Теперь хочется прогнать через GPT-редактора и написанные ранее главы; вдруг найдется где-то полная дичь.

Два мелких наблюдения про GPT-driven написание кода:

1) за последний месяц написал больше регулярок, чем за всю предыдущую карьеру - нужно выковыривать результат из GPT и фиксить (например, добавлять пропущенные запятые в невалидный JSON). К счастью, писать их руками тоже необязательно, copilot справляется.
2) надо думать своей головой дважды (трижды для таких невнимательных людей, как я), принимая какие-то дизайн-решения на базе ответов ChatGPT. Недавно лопухнулся: спросил, как сделать некую интеграцию с гуглдоками, посмотрел код и подумал, что после мелких фиксов все заработает. После многих часов в попытках это завести обнаружил, что такого API не существует, есть вроде бы похожее, но совершенно не решающее мою задачу.

Наконец-то выкатили в early access первую версию книги! 📖

В раннем доступе 5 глав из 16, новые будут добавляться с небольшим лагом (на самом деле уже готово 8 глав целиком и еще что-то в виде черновиков разной степени читабельности), аналогично будут фикситься опечатки и прочие мелочи. Пока есть только электронная версия; бумажная выйдет только в следующем году.

По промокоду mlkravchenko скидка 45% до 9 мая.

Я уже недавно писал, что в эпоху LLM регулярки снова стали актуальным инструментом так называемого AI. Regex-in-the-loop как промежуточный вариант между "слепо доверимся черному ящику" и относительно дорогим human-in-the-loop.

И вот для тех, кто уже перешел с ChatGPT на что-то опенсорсное из зоопарка парнокопытных, уже появился враппер, который заставляет LLM-ку отвечать в заданном формате. Идея очень простая:

ReLLM filters non-matching tokens pre-generation. For each token, ReLLM tests every possible completion against a partial regex. For the potential completions that do not match the pattern, ReLLM masks the logits so that the language model does not generate them.

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

Получил доступ к превью Copilot for Docs.

В отличие от обычного Github Copilot, это набор chat LLM, зафайнтюненных на определенные сабсеты данных: например, документация Azure, Github, TypeScript, React... Всего доступно 12 топиков, ни один из них лично мне не слишком близок (наверное, из всего доступного у меня за последний год были только вопросы по Github Actions).

UI похож на уже привычные LLM чаты, но с удобными референсами, где искать детали.

В общем, когда допилят больше топиков, будет полезно, а пока - скорее не для меня.

Пока во всех ML-related каналах пишут о том, что OpenAI массово раздает доступ к плагинам для GPT, я спрятался от хайпа, добрался до watch later и посмотрел два старых видео про профайлинг: Performance matters и Python performance matters.

Оба видео - доклады Emery Berger, автора известных инструментов профайлинга, на конференции Strange Loop. Просмотр обоих толсто намекнул, что некоторые мои потуги в вопросах оптимизации были довольно наивны, а кроличья нора профайлинга - куда глубже, чем может показаться ("ну а че там, запускаешь функцию, меряешь время, все просто"). Если тема интересна, но жалко времени, то посмотрите хотя бы первое видео, чтобы узнать о роли memory layout в бенчмарках и о том, почему не все ускорения одинаково полезны.

Emery Berger - вообще очень интересный чувак. Например, еще в 2014 он работал над идеей автоматического поиска ошибок в Excel таблицах (и развил метод в работе 2019 года). В Scalene - Python-профайлере из второго видео - давно прикручен OpenAI для подсказок оптимизация. Еще одна похожая утилита про dev tools meeting generative AI - ChatDBG, дебаггер с интегрированным ChatGPT.

С интересом прочитал короткую статью Bytes Are All You Need: Transformers Operating Directly On File Bytes.

TL;DR: авторы попробовали учить трансформеры на недекодированных файлах (картинки и звуки), модель очень простая: сырые байты => token embedding => conv1d для уменьшения размерности => transformer go brrr. Работает на JPEG, TIFF, PNG, WAV, MP3; ожидаемо, форматы с компрессией работают хуже. Метрики не самые клевые для 2023, но авторы явно и не пытались побить state of the art.

Интересно другое:

1) Всеми любимый Andrej Karpathy давно восхищается тем, насколько трансформер сближает домены: раньше ML-задачи на картинках, текстах и аудиоданных решались совсем по-разному, а сейчас полковник Кольт уравнял их шансы решения разных задач все больше похожи друг на друга. Эта статья - еще один шаг в том же направлении: домен не важен, засунул байтики и норм.

Наверное, похожие чувства были у людей, когда AlexNet вдруг всех победил: "это что, не надо пилить дескрипторы, просто пихаешь RGB-датку в свертки, добился сходимости (без батчнормов и residual connections, хехе) и все??".

2) В статье рассказывается, что такой подход может привнести новые элементы в построение безопасных систем. Например, можно представить камеру, которая в принципе не формирует полное RGB изображение, а только рандомные пиксели, и на этом можно успешно учиться (метрики прилагаются). Или, например, можно консистентно обфусцировать инпуты, и это тоже потенциально полезно для приватности. Учитывая, что авторы статьи из Apple, подозреваю, что они вполне могут использовать идеи byteformer для privacy-preserving задач в реальных устройствах.

Моя любимая художественная книга - "Криптономикон" Нила Стивенсона, ставший уже классическим исторический боевик про вторую мировую, криптографию и бум доткомов одновременно. Кстати, именно Стивенсон придумал metaverse в своем раннем посткиберпанк-романе "Лавина", таким образом внеся значительный вклад в нынешнее безумие Цукерберга.

Стивенсон популярен среди нердов за проработанность деталей, в т.ч. исторических: например, вымышленные персонажи участвуют в "Барочном цикле" наравне с Ньютоном, Лейбницем и Вильгельмом Оранским, а в "Криптономиконе" - с Аланом Тьюрингом и генералом Макартуром. Таким образом фикшен переплетается с нон-фикшеном: "Барочный цикл" до сих пор остается моим основным источником знаний о 17-18 веках в Европе.

И вот недавно я нашел книгу, которая во многом похожа на "Криптономикон" по духу, будучи при этом полностью нон-фикшеном. Это "Отряд отморозков" (в оригинале The Bastard Brigade) - популярно рассказанная история о том, какие открытия привели к возможности создания атомной бомбы и как правительственные агентства пытались помешать немецкому Урановому Клубу ее все-таки создать.

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

Пилю один прототип, нужно гонять инференс относительно тяжелых моделей, но мало и нечасто. Так я добрался потрогать кое-что из современного GPU serverless - Replicate и Runpod.

Replicate - относительно модный стартап, из W20 батча YCombinator, они фокусируются на чистом serverless. Довольно богатый набор популярных опенсорс моделей, собственно, ради одной из них я и пришел - разворачивать инференс своими руками было немного лень. Для выкатывания своих моделей предлагают использовать Cog, я с этим фреймворком не сталкивался, но выглядит перспективно. В целом продукт выглядит причесанным, но недешевым: там есть всего два вида GPU, T4 GPU за $0.00055 per second и A100 (40GB) за $0.0023 per second.

Потому я глянул и на Runpod. Они более известны не serverless платформой, а обычными GPU нодами, которые у них тоже есть, причем куда дешевле больших популярных облаков типа AWS. Но serverless тоже есть, и тоже довольно простой в освоении: нужно написать хендлер для их библиотеки, похожий на обычную лямбду, запаковать в докер и готово. Доступно несколько разных GPU, и даже самая мощная A100 (80Gb) всего $0.001 per second. Но надо понимать, что прайсинг хитрый: дополнительно оплачивается диск, дополнительно оплачивается idle (если не хотите, чтобы воркер сразу вырубался после одного запроса). Хвастаются, что колдстарт оптимизирован, сам я всерьез не бенчмаркал. Еще понравилась возможность настраивать параметры скейлинга вручную, в обычных лямбдах иногда не хватало такой гибкости.

В комментарии отдельно приглашаются эксперты, которые очень хотят рассказать, что serverless - говно, а деды завещали использовать bare metal.

Видел недавно вакансию, в которой была формулировка "интерес к промт-инженирингу и отсутствие снобизма по этому поводу". Так вот, у меня есть пусть и не снобизм, но некоторый скепсис.

Типичная работа с промптами - это не инжиниринг, а скорее алхимия. Алхимия - это уже не шаманские ритуалы (не способные повторяемо вызвать дождь вопреки мнению камлающего), а протонаука, которая, хоть и содержала в себе много странного по современным меркам, иногда приводила к неплохим результатам (см. например историю открытия фарфора в Европе). Да, есть набор полезных эвристик типа chain of thought, который помогает выжать больше пользы из вашей любимой LLM, и вообще сколько-то воспроизводимы между разными задачами/моделями. Но воспроизводимость оставляет желать лучшего, и если что-то не работает, то для подавляющего большинства адептов промпт-инжиниринга остается только перебор этих самых эвристик из твиттера и awesome-prompt-engineering списков.

Или вот еще видел формулировку "Need to setup ChatGPT prompts that guarantee...". Ага, конечно, промпты к внешнему черному ящику с гарантией, и немного философского камня заодно.

Важное примечание, чтобы не считаться совсем луддитом: штуки типа P-tuning - это уже не алхимия, и в работе со своими - не 3rd party API - LLM можно добывать какие-то гарантии (см, например, guidance).

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

Наверное, я уже похож на тех дедов, которые восемь лет назад бубнили "да что этот ваш ML, сейчас я напишу ифов с регулярками, и норм" и "к черту ваш диплернинг, сейчас SVM поверх HOG обучим и хватит".