Denis about Data

Всем привет! Долго я думал об этом, и решил, что больше не буду писать в этот канал. У меня последнее время нет ни сил ни желаний посвящать себя работе во внерабочее время. Это было долгое и непростое решение, но я понимаю - меня уже не хватает на дополнительные разговоры про аналитику и айтишку. Я понимаю, что вне работы я наконец-то стал посвящать себя семье, хобби и тому, что мне хотелось давно: музыке. Так что, если вам интересно: • тут в телеграмм я пишу про музыку. • тут читаю стихи на русском • тут читаю стихи на английском Если вам интересно - подписывайтесь, мне будет приятно. Если нет - спасибо вам большое, это было классное время вместе! Желаю всем вам успехов, самореализации, карьерного и личностного роста! Вы все крутые! Спасибо вам!

Насколько же сильно меняется работа, когда есть ИИ агенты. Мой коллега, биоинформатик, увидел статью, в которой хитрым образом находят специфичные гены в картошке. Понял, что это может быть полезно для нашего отдела по селекции клубники. Потому что и то, и другое распространяется вегетативно - то есть не через семена, а усы и клубни - они не родня, конечно, но в генетическом плане есть о чем поговорить, так сказать. Он дал эту статью агенту, который вооружен до зубов скиллами нашего собственного приготовления, и поставил задачу воспроизвести методы из статьи на наших данных клубники. Агент прочел работу, скачал с гита код, подтянул наши данные из бд, адаптировал что-то по мелочи, собрал контейнер, создал джобу на кластере и вот оно там бодро считается на нескольких Н100. По сути это задача интерна/джуна - “вот тебе статья, вот данные, через неделю покажешь, не надо плакать, все будет хорошо, соберись уже” Прогресс, как это часто бывает, выглядит немного несправедливо. И это, заметьте, не задачи кодинга, это по сути своей - applied research. Ведь агент не просто пишет код (если вообше пишет), а таскает за собой весь исследовательский контекст, внутреннюю кухню по данным и инфре. До сих пор не верится, что это все настолько хорошо работает. Ощущение, что оно где-то да вот вот зафейлится - но оно раз за разом хорошо отрабатывает. Магия 🤷‍♂️

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

Фиона Фанг, Head of Engineering в Claude Code, сказала, что использование агентов делает инженеров более одинокими Люди перестают обмениваться опытом и в итоге все больше и больше зацикливаются на работе со своими агентами. Кодинг становится «изолированным». Фанг говорит, что это серьезная проблема, и Anthropic уже стараются с ней бороться. Оказывается, что помимо всяких хакатонов и кодинг-завтраков в компании проводят так называемые «maker time» встречи: инженеры собираются, вместе программируют и делятся практиками использования агентов. Вы там как, справляетесь с одиночеством? 😭

Вот это интересно, кстати. Человеку нужен чебурек (и человек). Кажется, что нужно общение и социализация. Это и раньше нужно было, но сейчас особенно. Что думаете?

Баттл по датавизу: R vs Python 📊 Не так давно я обещала анонсировать кое-что интересное, связанное с датавизом, пора раскрыть карты: 23 июня в 19:00 МСК проводим стрим в новом формате: кто быстрее и лучше визуализирует одни и те же данные – на 🖥 или 💻? На R пишу я - @stats_for_science На Python будет кодить Рома - Kotelok Формат простой: один датасет, есть вопрос, на который нужно ответить визуализацией. Всего будет три раунда, каждый следующий сложнее предыдущего. Ориентировочно займет полтора-два часа. Зрители увидят: - атмосферу баттла как на соревнованиях по геогессеру/тетрису - холивар ggplot2 vs matplotlib - что быстрее и проще кастомизировать - величие грамматики графики (или нет) Оценивать красоту и функциональность чартов будет приглашенный эксперт - Анастасия из настенька и графики 🔥 Ссылку на трансляцию пришлю незадолго до начала сюда. Присоединяйтесь, будет интересно! #data_vis #analytics

Вот это интересно!

У Elon Musk в пятницу большой праздник — SpaceX выходит на IPO, а он почти наверняка станет первым триллионером в мире 😇 В преддверии IPO команда подготовила получасовой ролик с «технической информацией о возможностях SpaceX по производству, запуску и эксплуатации спутников с искусственным интеллектом в больших масштабах». Я пока посмотрел малую часть, остаток досмотрю днём, вот главное: Общие характеристики спутника «AI1»: • Средняя мощность вычислительной полезной нагрузки: 120 кВт. • Это ровно столько, сколько ест серверная стойка на 72 видеокарты GB200 (у H100 было 30-40 кВТ), с учётом ЦПУ, памяти и прочих компонентов. • Вычислительное оборудование взаимозаменяемо (в видео можно посмотреть, как маленькие сегменты подлетают и подключаются) Габариты: • Размах крыла солнечных панелей: 70 метров • Высота в развернутом виде: 20 метров Система терморегуляции Thermal System: • Развертываемый жидкостный радиатор площадью 110 м² • Дублирующие насосные контуры на случай отказа основного • Встроенная защита от микрометеоритов • Развертываемые жидкостные радиаторы • В интернете разыскиваются эксперт, которые помогут оценить, хватит ли этого для охлаждения GPU Elon: «ИИ-спутник устроен гораздо проще, чем спутник Starlink. По сути, ИИ-спутник — это огромное количество солнечных элементов; вам всё ещё требуются некоторые лазерные каналы связи, но в нём нет всех тех сверхсложных антенн, что есть на спутнике Starlink. Спроектировать ИИ-спутник проще. Он больше по размеру. Во многом это технологии, которые мы уже создали для спутников Starlink V3». И параллельно с этим строится огромная фабрика по производству этих спутников + чипов для них, запуск планируется в конце 2027-го года. Наверное, какие-то тестовые полеты макетов спутников стоит ожидать до этого времени.

Ого!

💬 «Я гуманитарий, это не мое» В преддверии летнего буткемпа по R (стартует 26 июня) предлагаю встретиться на вебинаре и поговорить о том, что мешает нам начать "оцифровывать" наши исследования. Но не о любви к книжным корешкам (ее никто не отнимет), а о преградах другого рода. Например: 🌟 "Я гуманитарий, это не мое" 🌟"У меня нет подходящих данных" 🌟 "На это нужно много времени" 🌟"Мне это не нужно" 🌟 "В Экселе посчитаю" 🌟 "ИИ и так все умеет" Иногда это так. А иногда нет. Приходите, если задумываетесь, не пора ли начать программировать, но до конца не уверены и просто хотите "об этом" поговорить. Общаться будем без записи, можно задать все самые "глупые" (на самом деле нет) вопросы и предложить для обсуждения смутные исследовательские идеи. Если решите подписаться на курс -- в течение трех часов после вебинара можно будет воспользоваться промокодом, который я выдам участникам с лучшими вопросами. Участие свободное. 🌷Время и место: Zoom, 16 июня (вторник), 16:20-18:00 (мск) Форма для регистрации (закрывается за два часа до начала встречи). Ставьте огонек, если ждали этой встречи 🔥

Ольга классная! Если вам давно хотелось попробовать программирование, науку, или поговорить про латынь (а лучше всё сразу) - обратите внимание и приходите!

ggcube Для создания 3D моделей в R существует замечательный набор библиотек, объединенных как Rayverse. В частности, rayshader позволяет превращать ggplot2-графики в 3D-изображения. Кроме того, кто-то возможно вспомнит библиотеку ggrgl, но она не так просто устанавливалась (если я не путаю). Также 3D-графики строит matplotlib. Новая библиотека ggcube позволяет создавать 3D-фигуры с помощью грамматики ggplot2, просто указав в "эстетике" z-координату. Код ниже дает представление о возможностях ggcube, попробуйте: library(ggplot2) library(ggcube) butterfly <- ggcube:::lorenz_attractor(n_points = 8000, dt = .01) ggplot(butterfly, aes(x, y, z, color = time)) + geom_path_3d(linewidth = 0.1, color = "black", position = position_on_face(c("xmax", "ymax", "zmin"))) + geom_path_3d(linewidth = 0.3) + scale_color_gradientn(colors = c("blue", "purple", "red", "orange")) + coord_3d() + labs(color = "время") + theme_light()

Это красиво.

🤖 Self-service аналитика в Anthropic Аналитическая команда из Anthropic рассказала в статье как они делают аналитику на базе Claude. Получилась крепкая статья, где расписаны все основные концепты, которые нужны чтобы агенты меньше тупили при работе с данными. Забавно, что начинают они с того, что вот при работе с кодом всё хорошо — там ведут документацию, есть история изменений и часто есть только один верный результат. А вот в аналитике данные не описаны, нет точной проверки результата и просто бардак. Сложно с ними не согласиться, но думаю, что с кодом всё примерно так же на самом деле 😅 Поэтому основные действия направлены именно на улучшение контекста и качества описания данных. Так как именно это даёт наибольший буст (как и для вообще любых агентских задач, а не только для данных). Они разделяют эту работу на 4 уровня: — Data foundations — Sources of truth — Skills — Validation С первыми двумя всё довольно скучно и стандартно: внедряйте процессы data governance, стройте семантический слой и linage, сделайте набор "золотых" курируемых таблиц (вообще были бы такие источники и агенты бы были не нужны 🤣), с которыми будет в первую очередь работать агент И делать это желательно руками, а не агентами: One idea we tried that didn’t work: bootstrapping the semantic layer by having an LLM auto-generate metric definitions from raw tables and query logs. It produced plausible-looking definitions that encoded the very ambiguities we were trying to eliminate, and was net-negative on our evals versus a smaller, human-curated layer. Из интересных идей: можно подсунуть в контекст SQL запросы из дашбордов и предыдущих исследований. И ещё важно скармливать не только исторический курируемый бизнес контекст (аля вики с процессами), но и текущий операционный (чаты, роадмапы и таски). В общем никуда от скучной работы по причесыванию документации и данных не деться. А вот со скилами и валидацией в статье для меня были новые идеи. Скиллы становятся такой же важной сущностью как и код для ETL / дашборды / документация. Это ещё одна сущность, которая должна обновляться и при обновлении схемы данных, и при изменении бизнес-процессов. Если этим не заниматься, то быстро происходит падение качества: We watched our offline accuracy drift from ~95% at launch to ~65% over a month before we treated this as an engineering problem. То есть за скиллами тоже надо будет следить и настраивать все инженерные практики, как и для кода. А улучшать их можно через «A/Б-тесты» и эксперименты. Microsoft даже уже сделали open-source проект заточенный на это. Для правильной же валидации приходиться делать слепки данных, которые использовались при создании скилла. Чтобы можно было сравнивать яблоки с яблоками при его изменении, иначе будет невозможно иттеративно их улучшать. И это прям ещё один большой слой по работе с базой — как это делать если база большая, куда всё это складывать и т.п. И ещё одна нерешенная задача это silent failure — как искать случаи когда модель дала ответ, но пользователь не понял, что он плохой или просто не сообщил про это. Получается, что очень сложно отслеживать реальное качество и непонятно насколько 95% evals траслируется в реальное качество. Жалко, что совсем ничего не рассказали про конечный опыт пользователя и UI: как делают дашборды и чаты, как они разделяют доступ по доменам и т.п. Просто голый Claude чат тут не подойдет и это тоже важная часть, которую нужно научиться строить для полноценной системы. В общем общий вывод — чтобы аналитика на базе LLM работала надо делать много процессов и внедрять инженерные практики. Чооооорт 😈

Вот, кстати, тоже очень интересно.

Claude помогает создавать следующего Claude. К чему это нас приведет? Anthropic выпустили большой текст о recursive self-improvement, то есть о концепции, в которой модель самоулучшается и обучает сама себя. По данным стартапа, на май 2026 года больше 80% кода, который попадает в их продовую кодовую базу, написан Claude. А во втором квартале 2026 типичный инженер мержил в 8 раз больше кода в день, чем в 2024 году. У людей все еще есть преимущество в большом контексте, постановке целей и выборе направления (в общем, в research taste). НО Claude уже автоматизирует большую часть работы, из которой состоит разработка следующего Claude. Чем вам не начало полного цикла self-improvement? Плюс, агенты уже хорошо справляются даже с рисерчем, особенно если есть заданная метрика. Антропики пишут, что проводили эксперимент, в котором дали агентам и людям одинаковую задачу по AI-safety, и в итоге два человека за неделю улучшили решение примерно на 23%, а агенты (внимание) – на 97%. Так что количество делегируемых агентам задач в сфере обучения моделей и исследованиях увеличивается и будет увеличиваться. Anthropic пишут, что процесс развивается быстрее, чем они думали, и что миру нужны механизмы координации, вплоть до возможности замедления или паузы frontier-разработки. Сингулярность, ты ли это?

А вот это интересно. То есть инструмент пишет сам себя. Самое интересное, что из этого получится и как много люди отслеживают? К чему приведёт саморазвивающийся инструмент? Что думаете?

Минутка саморекламы! Я кроме анализа данных ещё немного играю на музыкальных инструментах и иногда пишу про музыку. Для музыки создал отдельный канал, вдруг интересно будет! Буду всем рад https://t.me/musician_about_music

Митчелл Хашимото (создатель HashiCorp и Ghostty) написал важный пост про агентное программирование. Он хорошо подсвечивает проблему, того, что будет происходить если использование агента не будет подкреплено пониманием происходящего. tldr; нас ждет медленный и бажный софт. Дальше вольный перевод. Я запустил агента в цикле оптимизации рендерера. Цель была снизить время рендеринга кадра. Для измерения были тесты. Агент снизил время с 88ms до 2ms, а количество аллокаций примерно со 150K до 500. Звучит хорошо, правда? Нет. Именно поэтому агентный психоз это большая проблема. В качестве эксперимента я переписал core render state из Ghostty на Go. У него были точно такие же структуры данных, как в Ghostty, и те же самые тесты валидации. Сначала я сделал намеренно наивный рендерер. Простой, корректный, но медленный. 88ms на кадр и 150 000 аллокаций. Ужасно. Потом я запустил Ralph loop, чтобы снизить время рендеринга. Я сказал агенту, что он не может менять входные структуры данных, публичный API и тесты, потому что они корректные. Всё остальное менять можно. Агент работал около четырёх часов. Я потратил на эксперимент примерно $350. Результат? 88ms => 1.5ms 150K аллокаций => примерно 500 Впечатляет? Нет. Моя ручная реализация того же рендерера работает на том же бенчмарке примерно за 20µs, то есть 0.020ms, и делает 0 аллокаций в update path. Вот в чём проблема агентного психоза и отсутствия системного понимания. Если ты не понимаешь систему, ты примешь это за невероятный результат. Если понимаешь систему, то сразу увидишь лучшие решения и сможешь получить примерно в 75 раз большую пропускную способность. Люди, которые слепо доверяют результатам агентов, находятся в первой группе. Они слишком много пьют из фонтана посредственности. Стандартный дисклеймер: я постоянно использую AI. Мне нравится AI. Мысль не в том, что AI плохой. Мысль в том, что нельзя слепо принимать результаты. Думайте. Анализируйте. Учитесь. Telegram | YouTube | Сообщество