Maxim.ML - канал

Архитектуру построили. А ML - нет 🤷‍♂️ Завершился наш с Никитой модуль по AI-агентам в ВШЭ и МФТИ Финальная задача - разработать агентную систему для решения ML-задач, aka MLE-STAR 57 студентов, 22 решения. Давайте разберем результаты 🧐 Немного про задачу и ограничения: ⚡️Соревнование на Kaggle, которое должно было решаться агентами - всё в лучших практиках - через MCP ⚡️Нужно было использовать только open source модели - так интереснее (конечно, ведь можно взять opus 4.6 и решить задачу в 3 промпта - но это скучно) ⚡️Пять критериев оценки: 1. Архитектура: качество системы, протоколы, современные паттерны; 2. Автоматизация и безопасность: полнота автоматизации, механизмы защиты и мониторинга; 3. Качество модели: результаты на тестах, устойчивость к атакам; 4. Бенчмаркинг: система оценки, сравнение архитектур; 5. Документированность: структурированность кода, качество документации, воспроизводимость; Что интересного нашел в процессе проверки: 95% команд получили ≥8 за архитектуру, но с качеством модели наоборот: 14 из 22 получили ≤6, и никто не получил 10. Почему? Корреляция между архитектурой и качеством модели: r = 0.16. Почти независимы. 1️⃣ Агенты не гарантируют качество модели. Оркестрация - про «как организовать работу», а не «какой будет результат». Можно идеально координировать 5 агентов, которые все делают посредственный feature engineering 2️⃣ Базовые ML-решения. Большинство команд ограничились LightGBM/XGBoost/CatBoost с дефолтными или минимальными настройками. Сложная агентная обёртка вокруг простого пайплайна. Ещё несколько находок: 🔵Корреляция между критериями оценки почти нулевая (r=0.06–0.24). Команды прокачивают разные навыки своей архитектуры независимо 🔵Каждая дополнительная интересная фича добавляет ~0.3 балла - сильнейший предиктор (r=0.56) (например: rag по открытой базе ноутбуков, изоляция исполнения кода в Docker, параллельные запуски конкурирующих агентов) ⚙️ Фреймворки LangGraph - 55% команд (ср. 7.60), Pure Python - 41% (7.09). Лучшие связки: LangGraph + codegen (7.80), LangGraph + plan-execute (7.60) Было реализовано много интересных мультиагентных архитектур, но не все они выигрывают соревнования. Нестандартные решения и сильный feature engineering все еще двигают метрику Так что агенты - все еще инструмент, а не замена ML-экспертизе ✨ Если интересно самим посмотреть решения ребят: 🔗 репо с решениями

Как неожиданно и приятно Месяц назад отправлял свою рукопись в ainl, сегодня пришёл результат: - strong accept x1 💪 ; - weak accept x2 👌 ; - weak reject x1 🤔 ; И как итог: принято, а значит поеду в Томск на защиту Тема статьи капец какая актуальная - атака ⚡️ и защита 🧐 VLM моделей И вообще напрямую связана с моим текущим open source проектом: http c++ api сервисом для локального сервинга моделей на NPU чипах И про первое и про второе скоро напишу на habr

Кажется, ИИ способен разогнать цену чего угодно 😓 TL;DR: Делюсь опытом, как развернуть ассистента почти как open claw на устройстве за 2к рублей, вместо Mac mini за 50к. Мир внезапно вспомнил, что существуют не только Mac mini, но и мини-серверы вроде Raspberry Pi. Продажи и тех, и других кратно выросли, спасибо вирусным постам про "домашний ИИ" (вот нам не хватало роста на RAM, да?) Поэтому держите классный хак: свой ассистент, не на Mac mini за 50к, не на Raspberry Pi за 15к, а на Orange Pi Zero 2 всего за ~2к рублей. Зачем переплачивать? 📈 Откуда растут ноги Есть прекрасный Claude CLI, который умеет, кажется, буквально всё. Если подключить к нему tmux и ловить все входы и выходы через hooks, можно транслировать происходящее прямо себе в Telegram, и переписываться со своим агентом. Агенту нужен лишь терминал и доступ в интернет. Всё остальное по сути переплата. Отсюда вырисовывается интересная схема работы с вашим claude cli терминалом (см картинку) Я, конечно, не блогер-миллионник, так что на цены Orange Pi мы вряд ли повлияем 😱 Схему Claude + tmux + Telegram тестирую уже почти три недели, накопилось много мыслей про "программирование с телефона". Скоро начну делиться. А пока, если хочется попробовать самому, загляните в проект ccc, там многое уже настроено

Самое время начать сезон Context-Driven Solving ML соревнований 🦆 В прошлом году начинал развивать идею Context-Driven Solving (CDS) ML соревнований при помощи ai-агентов ✅(раз) ✅(два) Самое время продолжить, предлагаю попробовать свои силы на второй задаче этого соревнования Почему такие соревнования -  это идеальный полигон для тестов и обучения Понятные правила, табличные данные, встроенная система оценки - идеальная среда с обратной связью, чтобы протестировать свои знания и навык работы с агентами Почему именно вторая задача В ней легче настроить локальную валидацию. Для любых агентных систем важна среда оценивания, и для второй задачи вы без особых проблем сможете построить локальный процесс оценки работы агентов, который будет сильно коррелировать с public leaderboard. Первая задача в этом плане немного сложнее С чего начать 1️⃣ Соберите контекст - изучите лучшие подходы, найдите открытые проекты и публикации. Сохраните в базу знаний проекта только самое лучшее и релевантное 2️⃣ Настройте проект - создайте структуру, пропишите правила работы с каждой директорией в отдельном readme файле (так агенту будет проще ориентироваться). Если у вас особые вкусы, попробуйте писать спеки 3️⃣ Опишите свои идеи - сформулируйте пару гипотез и попробуйте настроить процесс так, чтобы агент мог проверять их автономно Всем удачи в новом сезоне 🙌

Уже приходил к ребятам на летнюю школу - в прошлый раз рассказывал про "Что делать с данными, когда их слишком много: от Big Data к Smart Data" В этот раз расскажу про еще более актуальную тему: "Почему фундамент важнее кода: как меняется Data Science с появлением AI-агентов" Приходите послушать и пообщаться 👋 Что: Зимняя школа по аналитике, Data Science и Data Engineering от Центра непрерывного образования ФКН НИУ ВШЭ Где: г. Москва, Покровский бульвар, 11. Когда: 14 февраля — офлайн, с 10:00 до 18:00. Участие бесплатное для всех желающих, требуется регистрация: по ссылке

Запустились 😎 Провели с Никитой первое занятие для студентов ВШЭ и МФТИ по курсу разработки ai-агентов для решения Data Science задач (будем делать своего MLE-STAR агента) Вот вам фотка из backstage 😐 И инфографика с первого занятия - объяснение формирования названий для GGUF - формата хранения языковых моделей.

Запустились 😎 Провели с Никитой первое занятие для студентов ВШЭ и МФТИ по курсу разработки ai-агентов для решения Data Science задач (будем делать своего MLE-STAR агента) Вот вам фотка из backstage 😐 И еще инфографика с первого занятия - объяснение формирования названий для GGUF - формата хранения языковых моделей.

Только не показывайте такие результаты менеджерам, иначе они поставят KPI +∞ к вашей бизнес-метрике после внедрения AI-агентов 😬 Что здесь происходит? На скриншоте мой Claude-агент отчитывается о проделанном рефакторинге. Сейчас я экспериментирую с моделями до 2B параметров на задачах RAG и изучаю влияние разных мультиагентных архитектур на качество ответов. Для тестов использую проработанный бенчмарк HotpotQA В этот раз агент исправил баг и искренне обрадовался, когда метрика выросла в бесконечность раз 📈

Кажется, это уже становится традицией: каждый год в январе собираю актуальные идеи для pet-проектов на год 🦌 📍Свежая подборка за 2026 тут: https://habr.com/ru/articles/988774 📍Прошлогодняя подборка за 2025 тут: https://habr.com/ru/articles/873300 И да, я сознательно не запихнул туда много идей. Осталась еще целая пачка невошедшее: 🔵самописный Deep Research 🔵агенты личной эффективности 🔵дообучение небольшой модели (3B–8B) под конкретный стиль/задачу 🔵RAG/поиск по редкому корпусу данных (письма, газеты, документы) Забирайте идеи и помните: с pet-проектами важно не только начать, но и не забросить 💪

Вместо итогов года: анимация истории канала Если не нравятся чужие wrappers - надо делать свой 😊 Вместо традиционных итогов года написал свой пайплайн аналитики истории канала Считаю, что нельзя уместить всю историю канала на одной картинке или в сухом дашборде. Статичная инфографика - это, конечно, круто, но любой автор подтвердит: его канал - это не статика. Это живой процесс, который постоянно меняется вместе с самим автором. Для чего вообще заводят канал? Чтобы фиксировать мысли, расти и развиваться вместе со своей аудиторией Визуализация данных в динамике - это отдельный вид удовольствия, особенно если у автора накопилось 300+ публикаций (в комментах есть такие примеры). На такой анимации отлично видно, как меняются темы, смещаются интересы и как эволюционирует контент от первых постов к текущему моменту Поэтому поготовил такую аналитику в динамике, а еще прогнал для некоторых авторов, которых читал в этом году (все gif в комментариях) Вот чью историю года мне так же было интересно посмотреть: ✨e/acc (@cryptoEssay) ✨эйай ньюз (@ai_newz) ✨Дата канальи - про «специалистов» в данных / ML / AI (@datarascals) ✨Kantor.AI (@kantor_ai) ✨Время Валеры (@cryptovalerii) ✨Dealer.AI (@dealerAI) ✨Neural Kovalskii (@neuraldeep) ✨Силиконовый Мешок (@prompt_design) ✨Борис опять (@boris_again) ✨Сиолошная (@seeallochnaya) ✨И наш корп-блог - МТС True Tech (@truetechcommunity) (вся статистика по авторам в комментариях) Хотите такую же анимацию? Если у вас есть канал или вы хотите увидеть визуализацию истории вашего любимого блога - пишите в комментарии. Скидывайте ссылку на публичный канал, и если там до 1000 публикаций за 2025 год, скину ответным сообщением Масс-сервиса и API сейчас нет - мой ресурс этого года уже и так ушел в минус 🛌. Но для интересных каналов всегда найду возможность запустить скрипт Всех с наступающим! 🎅

😎 полезное про background agents Продолжаем LLM‑adoption в нашем финтехе: в этот раз добрались до фоновой аналитики и завели в прод (успели под конец года 🎉) background LLM агента, который сам поднимает данные, гоняет статистику и приносит аналитикам готовые инсайты 📈 Вот последняя в этом году статья про background agents на Habr 💪🎄 Там подробнее про то, как поставить такого агента в прод, какие ограничения надо учесть и за счет чего фоновые процессы реально начинают драйвить бизнес, а не просто жгут GPU по ночам Искренне верю, что именно background-агенты - следующий шаг после копилотов, которые монетизируют idle GPU и автоматизируют аналитику Если интересна предыстория всего сервиса и конкретно background agents, то: ⭐️ Вот тут предыдущие публикации про сервис Часть 1 Часть 2 ⭐️ А вот тут видео с выступления с разбором концепции background agents Предыдущий пост Всем новогоднего вайба 🌟

🤓 Интересное из собесов на ML-щика Давно не было про собесы, поэтому принес важные кейсы с моих собесов, что сейчас есть актуального по теории ML и практике в system design ⚡️ Кейс 1 - Алгоритмы бустинга Вот тут писал 💡, что сделаю разбор, что я спрашиваю на собесах про catboost. Исправляюсь - сегодня расскажу про важные особенности основных алгоритмов, понимание которых отличает новичка от профи. Джентельменский набор алгоритмов бустинга: Аманда, Линда и Роуз XGBoost, LightGBM и CatBoost 🌟 XGBoost (2016, original paper 📑) 🔵Особенность 1 - Функция оптимизации для деревьев. В objective явно добавляется штраф за сложность дерева (например, за число листьев и L2 по весам листьев), поэтому контроль переобучения вшит в математику алгоритма, а не только в внешние приемы вроде early stopping 🔵Особенность 2 - Параллелизация и системные оптимизации. XGBoost проектировался как scalable GBDT - поддерживает параллельный поиск сплитов (по фичам/блокам данных), эффективные структуры хранения и обработку данных, что дает выигрыш на больших датасетах и многоядерных CPU (один из самых первых!) 🔵Особенность 3 - Second-order boosting (использование гессиана). В XGBoost каждый шаг бустинга минимизирует локальную квадратичную аппроксимацию лосса: дерево строится так, чтобы наилучшим образом уменьшить сумму grad и hess вкладов по объектам, где градиенты задают направление исправления ошибок, а гессианы - насколько агрессивным может быть это исправление; из этой аппроксимации напрямую выводятся формулы и для выбора сплитов (gain), и для оптимальных весов листьев, что делает обучение и точнее, и стабильнее 🌟 LightGBM (2017, original paper 📑) 🔵Особенность 1 - Histogram-based обучение (binned признаки). Непрерывные величины бьются на бины, дальше сплиты считаются по гистограммам, что резко снижает стоимость поиска сплитов и память 🔵Особенность 2 - Leaf-wise (best-first) рост дерева. LightGBM обычно растит дерево в глубину по самому выгодному листу, а не layer-wise по уровням, из‑за чего при той же глубине может быть быстрее/точнее, но легче переобучиться (нужны ограничения вроде max_depth/num_leaves/min_data_in_leaf) 🔵Особенность 3 - Две ключевые оптимизации: GOSS и EFB. GOSS (Gradient-based One-Side Sampling) для уменьшения числа объектов при оценке gain и EFB (Exclusive Feature Bundling) для склейки взаимно-исключающих sparse фич (например one-hot), чтобы уменьшить effective features 🌟 CatBoost (2019, original paper 📑) 🔵Особенность 1 - Ordered boosting. Обучающие градиенты/статистики строятся по перестановке (permutation), чтобы снизить специфический target leakage, который возникает в классическом бустинге при некоторых схемах использования таргета/статистик 🔵Особенность 2 - Ordered target statistics / target encoding для categorical фичей. Категориальные признаки обрабатываются через целевые статистики по таргету, рассчитанные аккуратно (в ordered-порядке), чтобы не подглядывать в истинный таргет текущего объекта 🔵Особенность 3 - Симметричные деревья. Деревья одной структуры на уровне (один и тот же split на каждом уровне) дают быстрый инференс и удобную реализацию/векторизацию, ценой ограничений на класс деревьев (это часто ключ к скорости CatBoost на CPU) ⚡️ Кейс 2 - System design Это свежий кейс с недавнего собеса. Кандидату надо было показать и рассказать, как бы он собрал RAG Pipeline удобного QnA поиска по корпоративной JIRA, и его итоговый результат на картинке (последняя картинка 🖼). Вы уже могли заметить проблемы в схеме, особенно если помните эту публикацию 💡, в которой детально разобрано, что надо реализовывать и как улучшать. Вообще, вес секции system design сейчас подрос, особенно на middle+ позиции. И конечно одна из причин - активное внедрение copilots и coding agents. Становится критически важно держать в голове полную схем проекта, даже при разработке маленькой его части. Кстати, уже поднимал эту тему и писал об этом здесь 💡. Всем сильных собесов 💪 и усидчивости при подготовке

Про Context-Driven Solving Вчера я рассказал про свое VLM-решение на Yandex Cup: Qwen, STEM-задачи и все, что вокруг них. Теперь - более верхнеуровневая часть истории: про мой подход к соревнованиям, когда в процессе появился co-solver, и почему я называю этот метод Context-Driven Solving Что такое Context-Driven Solving Коротко: это способ решать ML-задачи, где вы управляете контекстом и постановкой, а агент берет на себя максимально возможный объем итеративных изменений. Главная валюта и фактор успеха - это не только GPU и токены, но и количество осмысленных гипотез, которые вы успеваете проверить, плюс ширина вашего понимания задачи Что нужно сделать, чтобы ваш co-solver заработал Если совсем упрощать, вам нужно создать три вещи 1️⃣ Честную систему оценки решения (метрики) 2️⃣ Пространство для записи и чтения логов экспериментов 3️⃣ Пространство с контекстом для генерации идей В моем случае co-solver - это Cursor, который умеет писать и перебирать код. Но у него нет понимания, как итеративно идти к улучшению решения. Для этого нужно создать удобный контур локальной валидации. Например: поднять контейнер с решением, прогонять его на val-выборке и сделать результаты доступными для Cursor - например, через MCP (Model Context Protocol) Как это работало у меня 🔵 Собрал около 9k примеров из трех датасетов, затем отобрал по 250 из каждого для быстрой локальной валидации 🔵 Описал правила: какие изменения считаются новой гипотезой, как меряем качество, когда считаем эксперимент неуспешным. Это определяющий шаг для автономности: чем лучше прописаны правила, тем меньше у co-solver'а галлюцинаций 🔵 Дал агенту право генерировать варианты кода, промптов и пайплайнов, а система валидации сама выявляла лучшие идеи В итоге получилось провести 64 эксперимента за время соревнования. В ручном режиме я еле-еле дожал бы до двух десятков Ловушка контекста При этом co-solver - все еще помощник. Если вы плохо понимаете доменную область, даете сырое описание задачи и расплывчатые метрики, агент просто масштабирует это непонимание. Он честно и быстро ведет вас в локальный оптимум. Ваша задача - создать систему проверки и качественно описать идеи. Результат оказывается лучше суммы частей только если архитектор силен. Если архитектор слабый - co-solver просто ускоряет путь в тупик. Что будет в соревновательном ML в 2026 Думаю, 2026 год будет еще интереснее: 1. Задачки вида «подкрутите fine-tune» уйдут. Уже появляются skills, которые делают finetune «из коробки». По сути, за нас сделали MCP для задач обучения - это круто. 2. Появятся сложные форматы с агентами, многошаговой логикой и ограничениями по контексту. Ориентиром уже сейчас выглядят соревнования уровня AI Journey 2025 у Сбера, где одной «большой моделью» без архитектурного дизайна не обойтись (вот тут в канале у дяди делали разбор топовых решений - получилось интересно). Итог Призываю всех пробовать участвовать в соревнованиях. В первую очередь самостоятельно, чтобы расширять свой контекст, но и во вторую - при помощи LLM и co-solver’ов. Даже если ваша цель - не победа, а просто практика, вы: 🔵 лучше поймете, как ставить задачи моделям 🔵 научитесь строить рабочие контексты 🔵 увидите, где ваш способ мышления реально упирается в потолок Соревнования - это безопасная песочница, где можно экспериментировать с Context-Driven Solving и учиться работать в паре с ИИ

Разбор решения Yandex Cup Прошел Yandex Cup, где в треке ML я выбрал задачу STEM problem Q&A для VLM моделей (это когда надо решать задачи по математике и физике с листочка - но только в нашем случае, при помощи VLM) Самое время подвести черту и поделиться решением 📃 Сразу отмечу: радует, что агенты стали нормой. Комьюнити созрело, орги не банят за LLM-кодинг. Кажется, все приняли как данность, что без этого теперь никуда. Мой технический стек В итоге я вышел на такое решение: Ядро: Qwen3-VL-8B-Instruct + 4-bit квантование Методы: Chain of Thought + Prompt Routing Почему так: Большие модели лучше маленьких - это факт. Я пробовал собирать ансамбли из мелких моделей, но они никак не могли приблизиться к одной большой. Time Limit в 1 час сильно ограничивал: на полноценную Thinking-модель времени инференса мне просто не хватило (квантованные версии не попробовал). До finetune версий моделей тоже не дошел Что было больно (и интересно) 🔵Недетерминированность. На графике динамики лидеров видно, как участников штормило. Один из вариантов решения - поставить высокую температуру и устроить Voting одной и той же версии модели. Понятно что такое решение невоспроизводимо. Даже с температурой 0 метрика гуляла. Ты запускаешь топовое решение второй раз, и оно падает в рейтинге Инженерные вызовы и хаки 🔵Контейнеризация. Часть успеха - корректно развернуть модель в докере. Это был отдельный инженерный вызов 🔵Железо. Хорошо бы иметь домашний Linux GPU-кластер (ну или брать его в аренду). Это единственный способ сделать локальную валидацию быстрой и приближенной к проду. Моя главная ошибка: Я собрал неверный сет для локальной валидации. Использовал ScienceQA, Geometry3k и MathVista, но поздно понял, что у меня нет корреляции Local / Public Leaderboard. Был момент, когда из-за бага давали 8 сабмитов в день - идеальный шанс подобрать val data, но я его упустил. В итоге локально метрика росла, а на лидерборде - нет. Классический совет себе на будущее: Не нужно долбиться в одно решение. Не работает с трех попыток - делаем шаг назад и думаем еще Завтра расскажу про свой подход к vibe-competiting - как решать задачи с помощью co-solver’а и не сойти с ума P.S. Интересно, кто-то из финалистов уже рассказал о своем решении? Если знаете - скидывайте ссылки в комментарии