IT

Про признак «у пользователя день рождения» в ML В этом году на день рождения (он был уже давно, сейчас просто вспомнил историю) я получил очень много поздравлений, и что-то меня побудило всем поздравившим ответить в тот же день. В итоге больше половины моих ответов телеграм удалил, решив, что я спамер. Даже были прецеденты, когда мы с человеком попереписывались, а на следующий день его реплики есть, а мои все потерли. В этом нашелся и позитивный момент, я до сих пор случайно нахожу диалоги с поздравлениями и снова радуюсь им, но конечно основное, что меня позабавило, это что в классификаторе спама либо нет признака «у пользователя ДР», либо он не работает. И это, кстати, частый недостаток ML моделей в B2C сервисах. Например, в одной компании, где я работал, два моих коллеги мужского пола постоянно определялись внутренним классификатором пола как женщины, а один из них на этот счет даже неплохо плевался желчью. Причина тому была очень простой: у них день рождения 8 марта, и они получают аномально высокое для мужчины количество звонков в этот день. Среди тысяч сотрудников оказалось достаточно мужчин, родившихся 8 марта, чтобы баг исправился сам собой, когда для модели сделали нормальные признаки. Общий же рецепт довольно простой: при разработке модели хорошо бы подумать, почему она может ошибаться на каких-то примерах, и что сделать, чтобы не ошибалась. Как правило первые ответы на этот вопрос будут касаться наличия и актуальности нужных признаков, корректности собранного таргета, баланса классов и в целом репрезентативности выборки.

Атаковать можно не только человека, банк или сервер. Атаковать можно робота. Причём иногда для этого даже не нужно ломать саму систему. Достаточно изменить данные, которые она получает, подменить сигнал или заставить устройство принять неправильное решение. В новом фрагменте подкаста с Алексеем Лукацким говорим о том, зачем вообще взламывать роботов и умные устройства и к чему такие атаки могут привести. Какие атаки уже происходили? Можно ли заставить робота выполнять не те команды? Насколько безопасны электронные замки, умные дома и другие устройства, которым мы постепенно передаём контроль над своей жизнью? И где проходит граница между удобством и ситуацией, когда обычная автоматизация превращается в новую уязвимость? Потому что сегодня к интернету подключают всё: автомобили, камеры, замки, медицинские устройства и даже интимные гаджеты. И если устройство может получать команды извне, возникает простой вопрос: а кто ещё, кроме владельца, сможет этими командами управлять? Стоит ли обычному человеку вообще идти в тотальную автоматизацию? Или иногда старый добрый механический ключ безопаснее самого современного электронного замка? Полная версия подкаста про кибербезопасность - «Доступ Разрешить?» с Алексеем Лукацким https://t.me/alukatsky Смотрим тут: ВК видео Ютуб видео Рутуб видео Звук подкаст Яндекс Музыка https://t.me/kruasanova_as Все еще пишет сама и помогает сохранять ваши данные #ИИ #AI #Кибербезопасность #ИнформационнаяБезопасность #Роботы #УмныйДом #Автоматизация

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

Размер системы Размер неудачи связан с размером системы: чем больше система, с которой мы взаимодействуем, чем больше потенциальная неудача. В случае с кофе-машиной максимальная неудача которая может быть — что мы сломаем кофе-машину. Это болезненно, но не смертельно. Ошибка при управлении велосипедом приведет к содранным коленям. Это печально, но не смертельно. Это может быть даже обязательным этапом, чтобы научится ездить на велосипеде: нельзя хорошо научиться ездить не велосипеде без падений. Ошибка при управлении Боингом приведет к намного более печальному результату. Но Боинг — гораздо большая система, чем велосипед. С другой стороны, в больших системах человек не работает один: там есть другие люди, механизмы и программные продукты. В больших системах редко бывает так, что от одного неправильного действия сразу все ломается. Между ошибочным действием и аварией всегда будет несколько шагов или барьеров. То есть, чем больше система, тем больше у нас возможностей недопустить или исправить. И тут уже встает вопрос организации системы так, что предотвращать или вовремя исправлять ошибки. #ЧФ #ошибки

Программирование с явно выделенным состоянием Одна из моих любимых тем, про которую не устаю говорить. В модели данных часто бывает ситуация, когда состояние выражено не прямым образом, а косвенно. Буквально вчера я реализовывал кастомные тарифы под конкретных пользователей. Отличие такого тарифа от обычного сводится к тому, заполнено ли поле user_id в тарифе или нет. Если не заполнено, то значит это общий тариф, если заполнено, значит под конкретного пользователя и другие его не могут видеть. Это вполне рабочая схема и она встречается повсеместно, особенно в связке с датами типа deleted_at, но она обладает одним очень важным недостатком. Понимание того, что эта запись находится в особом состояние вычисляется через косвенный признак или, что хуже, через набор признаков. Об этом надо думать и каждый раз вспоминать и выуживать эту информацию. Сейчас, в эру агентного программирования, это стало еще важнее. Агент может догадаться до правила, но ему нужно на это время и отдельный анализ. Можно конечно написать об этом в правилах, но зачем, когда можно просто поправить модель данных? Все что требуется, это введение текстового поля со статусом, которое явным образом скажет о происходящем с этой записью. В общем не полагайтесь на то как заполнены поля, вводите нужные статусы, которые явно будут говорить о том что происходит. Заодно это дает более удобную аналитику и выборки Telegram | YouTube | AI Клуб

Разработчик Александр Романов выложил на GitHub открытый проект Cassette Simulation, который через FFmpeg имитирует звучание кассетных лент пяти производителей. Инструмент накладывает шум ленты, детонацию wow и flutter, режет полосу пропускания и крутит эквалайзер. Код опубликован под лицензией MIT, для запуска хватает bash и ffmpeg, собранного с libmp3lame. Профилей шесть, и каждый тянет цифровой звук к своим дефектам. Немецкая BASF LH Extra C90 добавляет умеренное шипение и лёгкий флаттер, Maxell UD C90 шипит меньше и берёт диапазон шире. Винтажные Sony CHF60 и CHF90 1978 года дают тёплую середину, а 90-минутная сильнее плывёт по скорости. Поздняя TDK D90 середины 90-х имитирует чистый звук с тонким аналоговым характером. На другом полюсе советская МК-60, которая заваливает трек сильным шумом, мощными wow и флаттером и агрессивно срезает частоты. FFmpeg, инструмент для честной цифровой обработки, здесь возвращает записи шипение, дрейф скорости и зарезанный верх.

Все, с выходом Fable и 5.6 sol вы больше не должны понимать, что происходит у вас в коде. Не до всех еще дошло, но вы больше не software engineer, вы loop engineer

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

Ну камон, ребят. Все же понимают, что публичные лица компаний, который продают лопаты всегда будут преувеличивать ценность этих лопат и формировать хайп, который через какое-то время действительно пушанет технологии до уровня, который они продвигали. Типичный fake it till your make it – так все технологии развиваются и всегда развивались. Но мы то с вами не обязаны собой жертвовать ради этого, ну Почему я считаю, что сейчас это все еще не работает и хорошие инженеры должны понимать что происходит под капотом систем, которые они строят (даже если они строят их печатая/наговаривая английский/русский текст)? Постараюсь порассуждать "из первых принципов": Дело в том, что это всегда так и было – хороший инженер всегда понимал систему как минимум на один уровень абстракции ниже того, на котором её писал. Хороший Python разработчик знает про GIL и 3.13, PyMalloc, сборщик мусора, ссылочную природу объектов, и что многие библиотеки написаны на других языках со своими ограничениями и возможностями. И для него код на пайтоне на самом деле раскрывается гораздо глубже чем он выглядит на первый взгляд – тот самый tacit context Хороший C++ разработчик скорее всего знает не только про разные виды памяти, устройство умных указателей и виртуальные таблицы, но и в курсе про уровни хардварного кэша, особенности архитекутры процессора и хаки, которые использует компилятор для компиляции под эти архитекутры. И может даже знать, в какие конкретно ассемблерные инструкции раскроется его код. Понимает как треды устроены на уровне ОС, какие механизмы их переключения на уровне ядра, и как писать lock-free код ↑ Этого всего нет напрямую в синтаксисе языка. Это особенности поведения систем на гораздо более низких уровнях. И проблема в том, что если инженер их не знает, то он даже не знает чего он не знает. А значит, не узнает и о наличии проблем на этих уровнях. В итоге прод ложится под растущей нагрузкой, баги не находятся неделями и затыкаются костылями, из-за которых прод снова ложится, но уже в следующем квартале ——— Короче, мало топить за loop enginering. Нужно понимать что в результате этих циклов получится Так же как когда вы пишете цикл на C++, вы понимаете, как данные будет лежать в кэше (и в каком), будут ли лишние аллокации в куче, и раскроется ли ваша числодробилка в SIMD-инструкции В общем, это фундаментальное свойство любого профессионала – видеть систему глубже чем она описана Подгорело, @ai_grably

Чем вообще занимается служба безопасности GitHub? Прямо сейчас на GitHub есть тысячи репозиториев, которые раздают вирусы через ссылку на zip-архив в readme. Чтобы найти их, не нужны никакие специальные знания, хватает обычного поиска по сайту. Схема живёт около двух лет. Автор показывает, как от простого заголовка с эмодзи дойти до запроса, который выдаёт репозитории с трояном пачками, счёт идёт на тысячи. А потом вспоминает, что месяц назад уже публиковал скрипт, нашедший 10 000 таких репозиториев, статья попала в топ Hacker News, и GitHub отреагировал ровно одним действием. После чего остановился, хотя новые появляются за часы. Узнаем, что сделала площадка с миллиардными доходами и штатной службой безопасности.

Песочница Наверное, каждый из нас хотя бы раз в жизни игрался в песочнице. У кого-то при этом была гора песка, лопаточки, ведёрки, формочки — в общем, полный "жир", а у другого и песка особо не было. Часто песочница выглядела как обрамленный деревянными досками квадрат, но и гора песка без всяких барьеров — это не редкий случай, особенно в регионах 😍. Песочница — масштаб небольшой, тем не менее, обычно среди всей детворы выделялся явно один лидер, у которого было "видение", как из всего имеющегося сделать "конфетку". Примечательно, что явных ресурсов у него не было, но особо талантливые могли организовать и постройку мини-замка. Из моих личных наблюдений (а возможно и снов) такие ребята могли чудом выпросить новый инструмент для дальнейшей работы, не всегда получалось, но за спрос не осудят 🤨. Если оторваться от конкретной песочницы, можно заметить, что их много. И вообще, за границами этого "квадрата" много чего происходит, что не подвластно нашему начинающему лидеру: у него за рамками нет ни ресурсов, ни влияния (хотя со временем, если не зазнается, составит себе "банду" уже не только в песочнице, но и во всём дворе). Всё, что у него есть, досталось ему либо потому что хорошо попросил, либо как-то оно материализовалось само. Вообще, к чему это я. Песочница — это интересная метафора к управлению IT-проектами в организациях 😃. Эти "горы песка" могут быть большими и маленькими, в рамках них руководители вольны делать много вещей, желательно позитивно влияющих на бизнес-метрики. Но это всё ещё "песочница", а серьезные риски, "взрослое" управление ресурсами скрыты за ней. В моей картине мира, уровень "песочниц" заканчивается на этапе, когда ты начинаешь отвечать за реальные деньги. Т.е. в тот момент, когда у тебя на руках условные $50 млн, а дальше твоя задача приумножить этот капитал за счёт новых исследований/IT-продуктов. А может, я всё это придумал и во "взрослом" мире всё немного по-другому. Есть тут кто из взрослых? Расскажите, а то очень интересно 😍.