Зачем тратить сутки на перелёты, мчаться на другой конец света и жить неделю в режиме нон‑стоп на одной из главных ML‑конференций планеты, когда пейпер уже на arXiv, код — на GitHub, а краткие выжимки из выступлений — мгновенно в соцсетях?
Меня зовут Карина Романова, я разработчик в Яндексе и занимаюсь LLM‑агентами в Алисе. В июле мы с командой прилетели в Сеул на ICML 2026, и я ответила себе на вопрос «зачем?». Для нас офлайн‑конференции — это единственный способ за несколько дней прочувствовать реальный фокус сообщества, встретиться с авторами работ и узнать детали, которых нет в опубликованных текстах.
В этой статье расскажу, как устроена ICML изнутри, чем запомнилась программа этого года, какие наши исследования вызвали наибольший ажиотаж и почему заметная часть разговоров на конференции снова вращалась вокруг AI‑агентов.
Конференция, которую невозможно посмотреть целиком
ICML 2026 проходила с 6 по 11 июля в сеульском выставочном центре COEX. Представьте, что вам нужно изучить больше шести тысяч научных статей всего за несколько дней — примерно так ощущается попытка охватить ICML.
Шесть дней прошли в формате абсолютного нон‑стопа:
один день был посвящён Expo и туториалам;
три дня продолжался интенсивный марафон основной программы;
оставшиеся два дня занял финишный рывок с воркшопами.
Цифры этого года отлично иллюстрируют масштаб конференции:
23 918 заявок в основной трек;
6352 принятые работы, акцептанс‑рейт — около 26,6%;
536 Spotlight‑докладов;
168 Oral‑презентаций (159 из основного трека и 9 из position track).
Охватить ICML целиком просто невозможно — каждый день ты выбираешь несколько интересных направлений, отмечаешь доклады и постеры, а потом всё равно половину планов меняешь на ходу. Причём самые полезные вещи часто происходят вне расписания: пятиминутный разговор у постера может дать больше часового доклада, а случайный кофе может закончиться новой коллаборацией.
Исследования Яндекса на ICML
В этом году исследователи представили на ICML 16 работ, восемь — в основном треке, столько же — на воркшопах. Темы получились очень разными: графовые и табличные модели, оптимизация обучения LLM, поиск и рекомендательные технологии, перенос знаний и оценка качества моделей.
Подробно пересказывать все статьи в одной статье было бы чересчур. поэтому я остановлюсь на трёх исследованиях, которые собрали больше всего вопросов у постеров и вызвали самый живой отклик у коллег.
Как ускорить графовые нейросети, если проблема не только в вычислениях
Первое исследование — статья On Efficient Scaling of GNNs via IO‑Aware Layers Implementations, подготовленная ребятами из ШАД и Yandex Research. Работа получила статус Spotlight — его присваивают небольшой доле особенно заметных статей конференции.
В чём суть исследования
Когда мы пытаемся ускорить GNN на GPU, сразу хочется оптимизировать математические вычисления. На практике же выясняется, что GNN чаще упираются не в compute, а в память и скорость передачи данных.
Авторы разобрали популярные семейства графовых моделей, нашли их узкие места при работе с памятью и адаптировали низкоуровневые GPU‑оптимизации под особенности графовых данных, по сути, применив IO‑aware‑подход, похожий на идеи из FlashAttention.
Что получилось
Для GATv2: кастомные GPU‑ядра показали ускорение до 8,5 раз относительно библиотеки DGL (медиана — в два раза), а пиковое потребление памяти снизилось до 76 раз (медиана — в шесть раз).
Для Graph Transformer: отдельная block‑sparse‑реализация под Tensor Cores ускорила работу до 7,3 раза на локально плотных графах.
GraphPFN: foundation model для графов
Ещё одна статья Yandex Research — GraphPFN: A Prior‑Data Fitted Graph Foundation Model. Она вошла в основной трек и получила Best Paper Award на воркшопе Graph Foundation Models: A New Era for Graph Machine Learning.
Сам воркшоп был посвящён развитию graph foundation models — переходу от узкоспециализированных моделей для отдельных задач к универсальным foundation‑моделям для работы с графами.
Как устроена GraphPFN
В основе — подход PFN: модель развивает концепцию Prior‑Data Fitted Networks.
GraphPFN предобучают на миллионах специально сгенерированных синтетических графов.
Благодаря синтетическому претрейну модель умеет работать с реальными графами прямо «из коробки» в режиме in‑context learning без долгого переобучения или после минимального файнтюнинга.
Результаты: на широком наборе реальных графовых датасетов GraphPFN показала лучшие результаты среди протестированных в работе подходов.
В рамках того же воркшопа Людмила Прохоренкова из Yandex Research участвовала в панельной дискуссии о будущем graph foundation models вместе с исследователями из RWTH Aachen, Georgia Tech и Arizona State University. На панельной дискуссии обсуждались последние достижения, открытые проблемы и перспективные направления развития графовых foundation‑моделей.
Weight‑Space Geometry of Offline Reasoning Training
Третья статья — наше совместное исследование с Владимиром Платоновым (Head of Alice AI) и коллегами из Keenable.ai: Weight‑Space Geometry of Offline Reasoning Training, которое мы представили на одном из профильных воркшопов.
Обычно offline RL‑лоссы для RFT, RIFT, DFT, Offline GRPO и DPO сравнивают с SFT по финальной accuracy. Мы решили посмотреть на другую сторону этих методов: насколько различаются изменения, которые они вносят в модель.
Как проводили эксперимент
Чтобы сравнение было честным, мы зафиксировали условия:
Взяли единый набор математических rollout’ов.
Обучили все шесть методов на модели Qwen3-4B‑Instruct с attention‑only LoRA.
Сравнили получившиеся LoRA‑дельты (ΔW).
Что получилось
Оказалось, что у SFT, RFT и RIFT эти дельты направлены почти в одну сторону, хотя их величина различается. DFT отклоняется от этого направления заметно сильнее, а у Offline GRPO около 67% апдейта глобально и до 86% в последних слоях приходится на компоненту, ортогональную направлению SFT.
DPO занимает почти отдельное подпространство и показывает лучшую accuracy в нашем протоколе. Однако его обучали с learning rate в десять раз меньше и на меньшем числе примеров, поэтому разницу нельзя объяснять только устройством loss’а.
Получается, что разные методы могут сильно различаться по формуле, но в контролируемом эксперименте приводить к неожиданно близким направлениям адаптации весов. При этом важно учесть, что вывод относится именно к фиксированным математическим rollout’ам, Qwen3-4B‑Instruct и attention‑only LoRA, а не ко всем весам и сценариям обучения вообще.
Expo и туториалы: ещё один способ увидеть индустрию
ICML состоит не только из основной программы: первый день традиционно отведён под Expo и туториалы, и это два довольно разных способа посмотреть на то, что сейчас происходит в ML.
Сам Expo похож скорее на большую технологическую выставку. Компании показывают исследования и инструменты, проводят технические сессии и стараются придумать что‑нибудь, чтобы к их стенду хотелось подойти. Amazon, например, оформил свой стенд как огромную фирменную коробку. Людей вокруг было постоянно очень много, а происходило на стендах буквально всё: варили кофе, раздавали мерч, показывали демо и рассказывали об исследованиях.
Теперь об AI‑агентах: как из базовой LLM получить работающий продукт
Я занимаюсь LLM‑агентами, поэтому на ICML, конечно, больше всего смотрела именно на агентские работы. Но пересказывать по очереди несколько статей, кажется, не очень интересно, а гораздо интереснее попробовать собрать из них одну историю: что делать, если у тебя уже есть сильная модель от фронтирной лабы и теперь хочется получить из неё агента под свои задачи.
Подход «взяли модель, подфайнтюнили, стало чуть лучше» в реальной разработке быстро упирается в потолок, и приходится решать более сложные системные проблемы:
как дообучить модель работать со сложной внутренней инфраструктурой и специфическими API;
как управлять поведением агента на этапе исполнения и гарантировать предсказуемость;
как проверить, что агент реально научился решать задачи и планировать, а не просто зазубрил конкретный интерфейс или среду.
Начнём как раз с последнего. В статье What Do Agents Learn from Trajectory‑SFT: Semantics or Interfaces? авторы проверяют, что именно усваивает агент после стандартного SFT на траекториях.
Для этого они сделали довольно простой тест: оставили задачу, состояние среды и описание инструментов прежними, но переименовали сами функции. Если агент действительно понял семантику взаимодействия, новое название не должно его смутить.
На практике после SFT некоторые модели начинают сильно проседать и продолжают вызывать старые функции даже после зааугментированного тул‑кола (когда мы внесли изменение в название). То есть вместе с полезными навыками агент выучивает конкретный интерфейс, на котором его тренировали.
Если этот этап пройден, хочется обучаться на большем количестве разных сред и не давать модели привязываться к одной инфраструктуре для генерализации. Но где эти среды брать?
Agent World Model предлагает генерировать их: LLM создаёт SQLite‑базу с состоянием, Python®‑tools, задачи и verifier, а агент потом взаимодействует с этой средой через реальные изменения state.
Таким способом авторы собрали 1000 сред, 10 000 задач и больше 35 000 инструментов, а затем использовали их для обучения через GRPO. В тестах на Qwen3-4B число обучающих сред последовательно увеличивали с 10 до 100 и 526 — и результаты на бенчмарках (BFCLv3, τ²‑bench и MCP‑Universe) стабильно росли. То есть масштабировать agentic RL можно не только количеством траекторий, но и количеством разных environment’ов, в которых агент учится действовать.
Но даже при наличии среды полноценный RL остаётся дорогим. Агенту приходится собирать длинные траектории, а надёжный финальный reward во многих задачах получить сложно. В работе исследователей Meta* и Ohio State University — Agent Learning via Early Experience — предлагается промежуточный этап: дать агенту собственный опыт ещё до RL.
Для этого берут состояния из экспертных траекторий. В каждом из них модель предлагает несколько альтернативных действий, каждое действие исполняют в среде на один шаг и сохраняют получившееся состояние. Затем модель либо учится предсказывать следующий state по паре «состояние/действие», либо сравнивает последствия своего и экспертного действий и формулирует, почему экспертный вариант оказался лучше.
Получается промежуточный подход между imitation learning и RL. Он всё ещё опирается на экспертные траектории и требует доступа к среде, зато для дополнительного обучения не нужны явный reward и длинные rollouts.
В экспериментах такая подготовка улучшила результаты на OOD‑сплитах ALFWorld, BFCLv3 и SearchQA. А после одинакового числа шагов GRPO на WebShop, ALFWorld и SearchQA модели, прошедшие early experience, достигли более высоких итоговых результатов, чем модели со стандартным imitation‑learning warm start.
Допустим, вы успешно обучили агента и выкатили его на пользователей. Следующий инженерный вопрос: насколько хорошо мы понимаем, что именно он делает в процессе? В работе OpenAI Monitoring Monitorability авторы проверяют, может ли отдельная модель‑монитор определить по траектории конкретное свойство поведения агента. Например, признаки reward hacking или саботажа.
Монитору давали разный объём информации:
Только цепочку рассуждений (Chain‑of‑Thought).
Только вызовы инструментов и финальный ответ.
Всю траекторию целиком.
Что выяснилось:
Действия менее информативны, чем CoT, а лучшие результаты даёт полный доступ ко всей траектории.
Чем длиннее CoT агента, тем легче его контролировать. Дополнительный reasoning effort самого монитора тоже повышает качество аудита.
Но CoT не гарантирует, что модель показывает свои реальные внутренние намерения.
Авторы также провели ограниченные эксперименты, в которых модель напрямую поощряли за сокрытие информации в CoT. Качество мониторинга просело — в основном из‑за того, что модель просто резко сократила свои рассуждения. Более узкое давление дало небольшое ухудшение только в одном из 13 eval’ов. Поэтому результат показывает, что канал мониторинга можно ослабить прямой оптимизацией, но не доказывает, что мониторинг неизбежно и быстро ломается. При этом предложенный набор eval’ов успешно заметил само ухудшение.
И тут хочется залезть на уровень глубже и отойти от текстовых рассуждений к hidden states, если у нас есть к ним доступ. Именно это предлагают авторы работы Activation Oracles.
Для каждой базовой модели обучают отдельную LLM‑оракула: activation vectors извлекают из residual stream исследуемой модели и инжектируют в residual stream оракула, после чего задают ей обычный вопрос на естественном языке. В основных экспериментах oracle работает с той же базовой моделью, на активациях которой её обучали, либо с её файнтюнами.
Что показали тесты:
В задачах на удержание секрета (secret‑keeping) оракул восстанавливал скрытые слова и инструкции, которые целевая модель вообще не произносила в ответе.
По разнице активаций между базовой и дообученной моделями оракул смог точно определить область файнтюна — например, выявить склонность давать рискованные финансовые советы.
Пока это скорее дополнительный канал аудита внутренних представлений, чем готовый цензор для полноценных агентов: эксперименты проведены на контролируемых задачах, а сама oracle иногда ошибается и не умеет надёжно оценивать собственную уверенность.
Если собрать все эти работы вместе, получается не готовый end‑to‑end‑пайплайн, а полезная карта проблем на пути от базовой LLM к готовому агенту:
Интерфейсы: проверить, действительно ли модель освоила суть задачи или просто заучила синтаксис конкретного API.
Среды: дать агенту опыт работы в сотнях разнообразных окружений.
Опыт: накопить локальный опыт действий до запуска дорогого RL.
Мониторинг: научиться вовремя находить нежелательное поведение по текстовой траектории или через аудит активаций.
Эти методы пока не проверялись как единая система, но вместе хорошо показывают, какие разрывы остаются между сильной моделью и агентом, которому можно доверять в реальной среде.
Конференция не заканчивается вместе с программой
После целого дня постеров, докладов и воркшопов участники не расходились — вечером компании и исследовательские команды устраивали встречи, ужины и вечеринки. И это, пожалуй, одна из самых приятных частей большой конференции: можно наконец познакомиться с людьми, которых до этого знал только по статьям, или спокойно обсудить работу, на постере которой днём стояла очередь.
Яндекс тоже устроил в Сеуле вечеринку для участников ICML. Никаких докладов, официала и слайдов — просто музыка, отличная атмосфера и сотни исследователей из разных компаний и университетов, которые на несколько дней оказались в одном городе.
Главный вывод после недели в Сеуле: что я увезла с ICML 2026
Главное ощущение после недели на ICML: ML одновременно становится всё масштабнее и всё более приземлённым. Мы продолжаем масштабировать модели, данные и compute, но самые интересные вопросы всё чаще начинаются после «окей, модель стала сильнее»:
Как модель ведёт себя в неидеальной среде?
Чему научилась на самом деле — сути задачи или просто синтаксису?
Насколько хорошо мы вообще понимаем и контролируем её поведение?
С агентами это особенно заметно: уметь планировать и вызывать тулы уже недостаточно. Теперь интересно, не запомнил ли агент интерфейс вместо самой задачи, умеет ли он восстанавливаться после ошибок и можем ли мы по его CoT понять, что он собирается делать.
ICML настолько большая, что у каждого в итоге получается своя конференция — из выбранных направлений, постеров и разговоров. И кажется, именно ради этого всё ещё стоит лететь через полмира: статьи можно прочитать на arXiv, а за несколько дней увидеть, какие вопросы одновременно волнуют всё ML‑сообщество, сильно сложнее.
Поэтому мой ответ такой: лететь через полмира стоит не ради доступа к статьям. Стоит — ради контекста, разговоров и возможности за несколько дней увидеть не отдельные исследования, а всю область в движении.
Ну и напоследок: прямо у входа на конференцию участников ICML встречала наша традиционная пасхалка:)
Всё самое интересное из мира ML мы с коллегами разбираем в телеграм‑канале ML Underhood. А ещё я веду свой канал, где тоже делюсь интересными находками по NLP, CV и AI.
