Artificial stupidity

​​#conference Осень уже в самом разгаре. А это значит, что скоро будет очередной Матемаркетинг. Я стараюсь гонять на него каждый год. В этот раз не успел податься с докладом, потому просто погляжу на других. И в этом году есть на что поглядеть. Я для себя выбрал несколько интересных докладов: 1. Ира Голощапова стабильно радует зрителей новым контентом. В этом году она рассказывает про "Agentic Engineering for Data Tasks Automation". Интересная для меня тема, очень хочется послушать, что там сделали коллеги из Райфа по агентной работе с данными (потому что лопатить их самому в 2026 что-то уже и не хочется особо). 2. Максим Стаценко расскажет про "Adoption, Harness, Knowledge: три драйвера апокалипсиса". Тут, конечно, интересно, как работают с агентами в плане сохранения и обработки знаний. Я и сам для диссера думаю над этими вопросами, ибо от качества нашей базы знаний и того, как мы их доносим до потребителя, зависит продуктивность работы как агентов, так и людей (я может коллегу и в кулуарах поймаю, мне еще интересно, что они делают с тацитным (неявным) знанием, ведь его перевести в явный вид гораздо сложнее, чем какие-то понятные и явные штуки). 3. Макс Коматовский поговорит на тему "Растим Иггдрассиль: как построить рабочий граф метрик". Я выступал как-то со схожим докладом. Интересно будет послушать, куда еще завела ребят дорога приключений с деревьями метрик. Думаю, что за прошедшее время появилось что-то новенькое и интересное из подходов. И это я еще прошелся по верхам. В общем, если хотите помучать спикеров вопросами, пересечься со мной (я не прочь поболтать на многие темы из нашей области), просто проникнуться атмосферой конференции и обсудить с коллегами насущные вопросы - пригоняйте на Матемаркетинг. Конференция 26–27 ноября, Москва, «Ломоносов» МГУ (еще будет онлайн-день 17 ноября). Полная программа и билеты по ссылочке.

Теренс Тао провел в Калтехе большую лекцию про математику в эру ИИ и выложил слайды https://terrytao.wordpress.com/2026/10/10/math-2-0/ Лекцию он назвал "Math 2.0", хотя еще в мае собирался читать ее под названием "Machine Assisted Proof". Сам он признается, что наполнение заметно изменилось "из-за недавних событий". Основная мысль Теренса такая: раньше математика строилась на допущении, что решить открытую задачу очень трудно и происходит это редко. Вокруг этого выросли институты, карьерные стимулы и традиции. Однако, на самом деле, решение задач – это лишь прокси метрика, а глобальная цель науки состоит в другом: в исследовании, поиске новых задач и понимании, как применить решения в реальном мире. Так вот, раньше эта прокси-метрика в виде решения открытых задач работала, потому что, решая задачи, математики копили опыт и понимание. Сейчас же, как говорит Тао, дальнейшая слепая оптимизация одного лишь решения задач "активно вредна для долгосрочного здоровья математики". Если ИИ просто выдает решения в обход людей, он как бы стерилизует окружающее задачу поле: непройденные пути так и остаются непройденными, цикл становится невозобновляемым, понимание не накапливается, и растет доля решений, которые как бы работают на бумаге, но расходятся с тем, что нам на самом деле нужно миру. В качестве аналогии Тао предлагает такой мысленный эксперимент: ИИ придумал коктейль, который убивает все раковые клетки, и он даже подтвержден клиническими испытаниями третьей фазы. Стали бы вы колоться, не зная, что хотя бы один человек-эксперт понимает механизм? В качестве решения Тао предлагает сместить фокус с уничтожения открытых задач на использование ИИ для укрепления человеческого понимания. Собственно, это он и называет "Math 2.0". ИИ может действительно помочь ускорить прогресс, если будет искать объяснения и новые принципы и исследовать окрестности гипотез, а не только генерировать доказательства. Это огромное непаханное поле, и главным ограничением тут Теренс называет уже не технологии, а воображение.

#libraries Я тут когда-то писал, что навайбкодил драфт библиотеки для бутстрапа. С тех пор драфт дорос до версии 0.7.0. Покажу одну задачу, ради которой я продолжил его пилить. Предположим, у нас есть две обученные модели. Проверяем их на одних и тех же отложенных данных: 120 пациентов, по 5 записей на каждого. Обучались модели на других пациентах. Хотим сравнить их AUC и понять, насколько уверенно можно говорить о разнице. Тут у нас есть небольшая ловушка. Если бутстрапить 600 строк по отдельности, мы игнорируем, что записи одного пациента связаны. Посчитать AUC отдельно для каждого и усреднить мы тоже не можем, т.к. это будет уже другая метрика. К тому же у 22 пациентов в этой выборке встретился только один класс, и индивидуальный AUC для них вообще не определён. Если хотим понять, насколько разница AUC зависит от состава тестовой группы, бутстрапить нужно пациентов целиком, а не отдельные записи. В каждом повторе набираем 120 человек из исходных с возвращением: кто-то не попадёт, кто-то попадёт дважды. Если пациент выбран дважды, все пять его записей тоже попадут в выборку дважды. На одних и тех же получившихся записях считаем AUC обеих моделей и их разницу. В bootstrapx теперь можно сделать это в одну команду: import numpy as np from sklearn.metrics import roc_auc_score from bootstrapx import bootstrap_two_sample def auc(rows):   return roc_auc_score(rows[:, 0], rows[:, 1]) result = bootstrap_two_sample(   np.column_stack((y, predictions_a)),   np.column_stack((y, predictions_b)),   auc,   allow_2d=True,   paired=True,   paired_cluster_ids=patient_ids,   method="percentile",   n_resamples=999,   random_state=42, ) В синтетическом примере AUC равен 0.718 для модели A и 0.765 для B. Разница получается +0.047, а доверительный интервал примерно от +0.022 до +0.076. Я отдельно пересчитал все бутстрап-выборки циклом по пациентам и с результатом библиотеки они совпали. Тут сравниваются уже обученные модели: при бутстрапе меняется состав тестовых пациентов, сами модели не переобучаются. И если пациентов мало или один из классов редкий, то такому интервалу без дополнительной проверки не факт, что можно верить (тут это уже библиотекой не исправишь). В общем-то, это всё ещё во многом вайбкод. Поэтому я просил модельку еще накидывать статистических проверок, сравнивая результаты с SciPy (как ориентир, да и тогда петля обратной связи для агента понятнее). Вообще без дополнительной информации сложновато дальше пилить, ибо агент начинает выдумывать фигню в плане фичей. Потому сейчас полезнее будет ОС от реальных живых людей. Если в примере что-то не так или у вас есть данные со структурой похитрее - пишите и делайте issue. Особенно если я где-то наврал со статистикой.

Ну и раз уж сегодня 3 сентября, потестил создание 16-битной гифки в GLM

Модель тройного долга от соавтора фреймворка SPACE Маргарет-Энн Стори, соавтор фреймворка SPACE для повышения продуктивности разработчиков, недавно представила свою модель тройного долга (Triple Debt Model), в которой скрытые человеческие издержки ускоренной с помощью ИИ разработки программного обеспечения рассматриваются в трех категориях: технический долг, который накапливается в коде. когнитивный долг, который накапливается в людях, входящих в команду. долг намерений, который накапливается во внешних знаниях, состоящих из лежащих в основе проекта соображений, целей и проектных ограничений, которые недостаточно задокументированы. И идея там довольно простая: AI позволяет нам быстрее производить код, но это совсем не значит, что мы автоматически быстрее производим хорошие и понятные системы. Просто долг начинает накапливаться немного в других местах😉 Всего Стори выделяет три вида долга: 1. Технический долг Плохие архитектурные решения, костыли, сложный код, отсутствие тестов и все то, что потом делает систему дорогой в изменении и поддержке. Причем тут есть забавный парадокс. Именно этот долг AI потенциально умеет неплохо сокращать: -отрефакторить код; -написать тесты и т.п. То есть код может становиться даже лучше. 2. Когнитивный долг Это долг, который накапливается уже в голове разработчика: агент написал 1000 строк хорошего кода. И даже тесты все зеленые. Так что вперед и PR в проде. Только инженер, который этот PR принял, понимает систему чуть хуже, чем если бы писал это изменение самостоятельно. А потом еще один PR. И еще один. Иииии в какой-то момент получается довольно странная система: код работает, но никто толком не понимает почему. Скорость производства кода растет быстрее скорости нашего понимания системы. Вот это Стори и называет cognitive debt. И да, тот факт, что скорость производства выросла - это супер! В этом вся суть моей работы, в принципе. 3. Долг намерений — Intent Debt А вот это типовая проблема, которая всплыла наверх. Раньше она тоже была, но мы особо ей внимание не уделяли. Можно прекрасно понимать, как работает код, но совершенно не понимать: почему он работает именно так? Какие продуктовые ограничения существовали? Что вообще хотел пользователь? Какие компромиссы были приняты? Все это обычно живет где-то между: - ADR; - документацией; - и, конечно же в голове того самого Тим-лида😁 А теперь представьте AI-first разработку. Один агент написал изменение. Через полгода другой агент должен его изменить. И второй агент пытается понять намерения первого агента… по коду первого агента. Ну удачи. В мире AI-разработки документация, ADR, спецификации, acceptance criteria и domain model — это уже не какая-то бюрократия рядом с разработкой. Это внешняя память вашей системы (на следующей неделе расскажу, как решают и эту задачку) Причем память нужна уже не только людям, но и агентам. Последние пару лет мы в основном спрашивали: как заставить AI писать больше хорошего кода? Но следующий вопрос будет: как сделать так, чтобы люди и AI продолжали понимать систему, пока AI пишет все больше кода? Потому что код становится все дешевле. А вот понимание: -зачем система существует; - почему она устроена именно так; - какие ограничения нельзя нарушать; становится только дороже. И возможно, через несколько лет главным инженерным активом компании будет уже не сам код. А накопленный контекст вокруг него.

Мой ближайший сосед Эйлер, или математик берётся за вышивку На связи Ginger. Я знаю, что вы не забыли, но мне надо как-то начать. Итак, я {одной из своих бриллиантовых граней🤩} математик. Днём работаю в биоинженерии и drug discovery🤪. А по вечерам делаю платформу, создающую арт-вышивку из фото вашего питомца, которую можно носить, дарить или продавать как собственный мерч😎. И это второй эпизод сериала про неожиданные математические задачи, повстречавшихся мне среди катушек ниток. Всё началось невинно: хотелось сервис, который берёт фото кота (или собаки, или хомяка — никакой дискриминации🐈🐖🐶🐹🦈), отдаёт его ИИ, а результат превращает в файл для вышивальной машины за минуту вместо 3-5 дней ручного труда. Фото ➖дизайн ➖мастерская ➖готовая вещь 🌟, пока вы гладите своего питомца🐆🐈 Звучит просто? Ага. Как почти всё в жизни… пока не столкнешься с физическим миром. Генерации картинок опустим, nano banana и gpt-image по апи все умеют. Превратить PNG в SVG тоже решенная задача. Первая творческая задача: превратить SVG в набор стежков. SVG это кривые Безье, а кривую можно семплировать в точки. Каждая точка — стежок. Отсюда и математика. SVG это граф, набор путей, каждый из которых — цепочка рёбер. Когда машина переходит с одного пути на другой, она делает JUMP — прыжок иглой с протяжкой нити. Прыжки это плохо: торчащие нитки на изнанке, потерянное время, потенциальные проблемы с машинами. А если прыжок длинный, приходится ещё и обрезать нить (TRIM). И тут я поймала себя на мысли: это же задача о кёнигсбергских мостах. Классика теории графов. Как и положено калининградцам, я гуляла только по 3м из них, а в VIII в Эйлер гулял по всем 7ми, и в 1736 году доказал, что обойти все мосты Кёнигсберга ровно по разу нельзя, потому что у графа мостов есть вершины нечётной степени. В вышивке та же история. Если бы все пути складывались в эйлеров граф, машина прошла бы весь дизайн одним непрерывным движением. Но в реальности — десятки разрозненных контуров, каждый сам себе компонента связности. Прыжки и обрезки неизбежны. Раз неизбежны — минимизируем. Порядок обхода я строю строила раньше ближайшим соседом: от точки, где игла только что закончила, ищу ближайшее начало или конец следующей цепочки (строчку можно шить в любую сторону — беру ту ориентацию, где ближе). Это тот самый момент, когда ближайший сосед впервые в жизни пригодился мне в проде. O(n²), 30 строк кода. Жаль, недолго. В июле на замену ему пришел китайский почтальон. Почему заменила: локально все хорошо, глобально — силуэт шьется кусками, 20 обрезок там, где хватает 4. Но настоящая мораль — я оптимизировала не ту задачу…Надо было не «посетить вершины» (задача коммивояжера), а «покрыть рёбра» (задача китайского почтальона). Правильная постановка задачи > оптимизация неправильной. Результат по Эйлеру: тонкий контурный рисунок, ~1-3к стежков, как карандашный набросок. Работает для тонких тканей, которые не выдержат 10-20тыс проколов иглой. Просто, элегантно, минималистично. Но для футболок и свитшотов выглядит слишком просто. Поэтому, в следующей серии будет сатиновая атласная строчка, скелеты и немного дифференциальной геометрии.

Стек: Python, pyembroidery, svgelements, NumPy, SciPy, scikit-image. 
Дизайны и мокапы рисуют по очереди nano-banana и gpt-image. 
Фронтэнд: Next.js + Express + Telegram-бот. 

Часть 1 тут. Поиграться: petstitch.art @PetStitch_bot Бэкстейдж проекта: @robin_bobbin_tensorflow

От стажёра до Head of DS: что я узнал, изучив почти 700 карьер в Data Science 🧬 Наконец-то дождались 🗿 Чуть больше года назад вы заполнили мой зарплатный опрос. Я обещал проанализировать результаты, но 695 анкет превратились в технический долг, о котором мне регулярно напоминали в комментариях. Сегодня я этот долг возвращаю. Кажется, даже с процентами: вместо очередной таблицы «кто сколько получает» получилось большое исследование карьер в Data Science. Да, за прошедшее время зарплатные вилки успели сдвинуться. Но карьерные зависимости никуда не делись, поэтому статья не только о суммах, а о профессиональном росте, удовлетворённости работой и готовности её сменить. Внутри вас ждет лонгрид, где в том числе есть ответы на пять не самых очевидных вопросов: 1️⃣ Можно ли удержать недовольного дата-сайентиста высокой зарплатой и запереть его в золотой клетке? 2️⃣ Какие навыки помогут быстрее вырасти в грейде и больше зарабатывать? 3️⃣ Одинаково ли зарабатывают мужчины и женщины с одним грейдом и опытом? 4️⃣ Что дата-сайентисты хотят сказать Head of DS, когда отвечают анонимно? 5️⃣ Как часто дата-сайентисты ******* и связано ли это с доходом и удовлетворённостью работой? Ещё там премии стажёров, ШАД на скейтборде, зарплата CDS до 4,5 млн рублей 😳, переработки и попытка понять, где заканчивается развитие и начинается менеджмент. В анализ вошли 694 анкеты. Спасибо «Start Career in DS», «DziS Science | Data Science», «girafe.ai», «Artificial stupidity», «LightAutoML framework» и «Борис опять» 👉 Читать на Хабре

Немного обеденного вахаслопа

#llm #agents Забавные наблюдения над мультиагентной системой. Как и обещал, расскажу. В Hermes agent есть такая тема с kanban доской. Можно настроить роли агентов и дать им создавать на доске задачки, потом их брать и выполнять, чтобы делать узкоспециализированные задачки специальной ролью со своими промптами, скиллами и т.п. И в процессе было несколько забавных наблюдений, которые весьма похожи (в шуточном смсле, хотя, как обычно, в любой шутке лишь доля шутки) на реальность. Итак: 1. Агент-менеджер сразу предложил сделать ему модельку попроще и выключит ризонинг. Вероятно, посчитал, что менеджеру думать особо и незачем. 2. У меня не было роли техписа, потому менеджер заставлял фронтенда писать доку (посчитал, что самый ненужный? я хз, если честно). 3. Менеджер вообще невзлюбил фронтенда. Каждый раз на выполненную задачку он ругался и говорил, что тот ничего не сделал. А потом я просил проверить и было "ой, а он сделал, зря быканул". 4. Бэк начал делать себе сам задачки, чтобы побольше поковыряться в библиотеках, от которых зависел проект (классика). 5. Бэк жестко отказывался от задач, которые были вне его скоупа и переводил их на других членов команды (что вполне себе тоже классика). 6. Архитектор писал какие-то доки и спецификации, которые команда дружно игнорировала (кек). Хотя они их и видели, в задачи им артефакты прокидывались. Меня здесь больше позабавило, как это все стало похоже на обычную реальность (пускай и в кривом зеркале агентской системы). Я местами прямо орнул с этих случаев (особенно с менеджера, который отказывался думать). А какой вывод? Какого-то очень умного вывода нет особо (кроме того, что у меня тут может быть skill issue и эта фича еще весьма сырая у Hermes). Но я бы все же сделал такое наблюдение — не исключено, что многим из нас придется подтянуть именно менеджерские навыки: планирование, управление (особенно кем-то, кого ты не понимаешь), установка границ и дедлайнов, настройка flow получения полезности. Потому что теперь каждый суслик в поле агроном (ну или каждый становится своего рода менеджером команды железяк).

Да

#LLM И еще немного околошизы. Я тут заметил, что Qwen-3.6-35b-a3b страдает в размышлениях синдромом лейтенанта Коломбо (буду считать придуманным мною термином). Был, значит, такой сериал. Классический детективный процедуриал (если ничего не путаю). Там одна из классических фраз была у ГГ "И ещё кое-что…" ("Just one more thing…"). Обычно он ее говорил, когда чел уже под подозрением и его сейчас ловко прищучит наш летеха. Ну так вот. Qwen именно так часто в thinking и пишет, если смотреть логи. Вот постоянно "И еще один момент". И пошел на новый цикл размышлений (что местами подбешивает). Точь-в-точь как Коломбо. Я теперь думаю, а не может китайцы подмешали субтитров из старого сериала, а моделька представляет себя героем детектива? Было бы забавно. Ну и явно лучше, чем если бы она представляла себя крестным отцом ("ты пишешь мне промпт, но делаешь это без уважения"). Вот такое вот забавное наблюдение. P.S. У меня еще есть несколько наблюдений от игр с kanban в Hermes, но их я напишу как-нибдуь потом.

#LLM #шиза #agents Особо времени писать нет. Пока жду обучения модельки, накидаю быстренько небольшую шизу. Я тут подумал, что все истории с harness'ом для агентов мне что-то напоминают. И вспомнил, что именно. Помните такой фильм Memento? Там ГГ потерял память после происшествия, так что каждый сон ему стирает события за день. У него еще татуировки по телу были и 100500 фоток с подписями. А теперь по агентам: 1. Моделька ограничена своим обучением. Если ей новых данных в контекст не подкинуть — она ничего и не знает из новой информации, только что помнила до этого. Checked. 2. Если сессию вырубаем, контекст у нас нужно загружать заново. Иначе не помнит нифига. Checked. 3. Приходится прописывать всякие memory и т.п., чтобы моделька могла проснуться и снова их посмотреть, чтобы узнать, а что же с ней происходило. Checked. 4. Если подсунуть отравленный контекст, модельку можно будет обмануть. Checked. 5. Все это сделал Нолан. Вот тут проблемка, да, недосмотр. В общем, наши агенты чисто живут в Memento. Ну... тут главное, чтобы мстить никому не стали из-за фоток каких-то. Но тут уж как повезет, хехехе.

Кто будет отвечать на неудобные вопросы про вайб-кодинг и разыгрывать подарки? Уже 25 июня в Сфере X5 состоится первый митап из серии AI & ML Talks. Показываем наших героев на карточках и делимся программой вечера:

18:30 — проходим регистрацию, пьём кофе и общаемся 19:00 — слушаем выступление Павла Гагарского, директора департамента «Интеграции и Парсинг», Х5Digital, на тему «Корпоративный корпус: как собрать контекст компании для AI» 19:25 — переключаем внимание на Александра Охонченко, ведущего разработчика в X5 Tech и его tech speech на тему «Лидвайбкодинг, а не шизофрения ИИ: как пускать vibe-код в прод без техдолга» 19:50 — наступает время для Hot Battle! Тема дискуссии: «Вайбкодинг — это фабрика техдолга, а не ускорение разработки». Модератор: Артем Ерохин — ведущий инженер нейросетей, Х5 Tech 20:15 — обсуждаем выступления, дискутируем и подводим итоги розыгрыша

Что разыгрываем? Пока секрет! Следи за новыми постами в канале и не забывай оставлять комментарии 🤫 Ещё раз важная информация: 📍 Сфера X5 25 июня, 18:30 🔗 регистрация на мероприятие это бесплатно

Завтра буду модератором митапа в Сфере X5 в Парке Горького. Приходите послушать про вайбкодинг, будут доклады от коллег и дискуссия про полезность вайбкодинга (ну или его бесполезность, тут уж кто лучше позицию отстоит) P.S. В пятницу буду там же, но уже в качестве выступающего. Буду шутить шутки про работу на Слайдапе.

🕒 Синдром «Серебряной пули» История про «эффективного менеджера» направления CVM (customer value management) Задача ребят — продавать доп. услуги клиентам и повышать конверсию. Вводные от заказчика прекрасны:

«Мы тут ходили к другой команде, они нам собрали фичу — "лучшее время отправки SMS". Мы полгода крутили пилот, получили нулевой результат. Хотим, чтобы вы сделали то же самое, но лучше».

Начинаем копать от бизнес-задачи. Выясняется: конверсия низкая. Почему? Ну, логично же: мы просто отправляем SMS не в то время! 🤡 Дальше — диалог, достойный войти в учебники по «продукт-менеджменту»: — Вы же уже проверили гипотезу на пилоте, результат нулевой. Зачем развивать безнадежную идею? — Мы в это верим. — Мы работали со многими крупными компаниями, решали эту задачу. Вы первые, кто просит именно эту фичу. — Мы переиграем рынок. — Ок, если я получу ваш пуш в 10:00 вместо 12:00, реально есть вера, что конверсия взлетит? — Разве это не очевидно? Тут мы немного выпали в осадок, но решили узнать, как устроена сегментация и выборка клиентов. — А как вы понимаете, кому слать? Есть функция ранжирования (uplift-модели, скоринг)? — Не понял вопрос. — Ну как вы понимаете, кто сконвертится лучше или хуже? — А-а-а, никак. Просто случайно выбираем из сегмента. Они же ВСЕ заинтересованы в продукте! — То есть ваш сегмент — это просто жесткие бизнес-правила (условия типа ЕСЛИ/ИЛИ)? — Если упрощенно, то да. Мы строим гипотезы и тестируем их через А/Б! То есть ребята делают А/Б тест на абсолютно случайной выборке внутри кастомного сегмента, не умеют в предсказание оттока/конверсии, но верят в тайминг. Пытаемся нащупать омниканальность. У них есть SMS, пуши и звонки. — А не пробовали выстроить каскадную стратегию? Например: сначала SMS, через день — звонок? — Ну и чем это кончится? — Оптимизацией стратегии... *(Повисла неловкая пауза)* — У нас либо звонки, либо SMS! ❌ Итог: Мы рассказали, как строим нормальный ML-пайплайн для CVM у других заказчиков (с моделированием, склонностью к покупке и оптимизацией стратегии). Продукту не зашло. Ведь у нас нет самого главного — алгоритма, который высчитывает идеальную секунду для отправки SMS человеку, которому это предложение вообще не всралось. Как называется эта болезнь? В медицине не знаем, но в ИТ это «карго-культ фичи». Когда команда игнорирует базовую математику, отсутствие нормальной сегментации и кривую коммуникацию, но свято верит, что одна «модная» фича переиграет рынок. Сталкивались с такими «верующими» заказчиками? Какую самую дикую фичу у вас просили завернуть в ML? 👇