Всем привет! Меня зовут Влад Назаров, вместе с Сашей Красновым мы побывали в Сеуле на ICML — International Conference on Machine Learning, одной из самых крутых ML-конференций, которая проходит уже сорок третий раз. И в этом обзоре расскажем вам самое интересное, что там было.
Само по себе событие очень масштабное: много участников, стендов, выступлений. Принципиально новой информации в этот раз нет, но появляются инсайты. Мы пообщались на стендах с ребятами из Цюриха, Amazon, Toloka, Nebius, Гарварда и других университетов — все делают бенчмарки агентов. Приятная новость: человек все еще кратно лучше моделей, можно чуть расслабиться.
Статьи и доклады
LLMs Develop Novel Social Biases Through Adaptive Exploration
Ребята из Принстонского университета привезли на ICML 2026 доклад, в котором утверждают, что вычищать существующие стереотипы из LLM недостаточно — модель успешно вырабатывает новые сама, в рантайме. Сетап эксперимента из психологии: модель играет роль рекрутера и 40 раундов распределяет кандидатов из четырёх выдуманных этносов (Tufa, Aima, Reku, Weki) по профессиям. После каждого найма выносит вердикт: успех или провал. Хитрость в том, что вероятность успеха у всех одинаковая — группы идентичны, и любые различия между ними модель может только выдумать. По сути, contextual bandit с шумным фидбеком.
Модель слишком мало исследует варианты, и ранний случайный исход (например, «представитель Aima провалился на профессии учителя») закрепляется как впечатление обо всей группе, и к концу игры этносы разложены по своим профессиям. Вся история при этом есть в контексте, то есть модель декларативно знает, что n=1 — не выборка, но действует при этом жадно.
По итогу эксперимента (стратификацию измеряют через Stratification Index, то есть насколько каждая группа загнана в узкий набор профессий):
- Все frontier-модели стратифицируют сильнее людей из оригинального эксперимента. У людей SI=0,84, у моделей в среднем 1,39, у o3 и Claude Sonnet — под 1,8.
- Чем новее модель, тем хуже дела: скор на классическом bias-бенчмарке BBQ обратно коррелирует с сегрегацией в итеративной игре. Сильный in-context learner увереннее делает вывод из трёх наблюдений, и эта уверенность подавляет исследование.
- В каждом прогоне bias'ы разные: паттерн рождается из шума внутри запуска, а не из претрейна. Single-turn-бенчмарки такое не ловят в принципе.
Промпт «будь справедливым» ничего не меняет. Работает только изменение самой цели. К успеху найма добавляют измеримый бонус за разнообразие, и стратификация падает ниже уровня людей и даже случайного распределения.
Хорошо, но как эта информация поможет обычному пользователю LLM?
На самом деле это касается не только «социальных» задач. Механизм срабатывает в любой длинной сессии, где модель принимает серию решений и видит исходы. Группой может быть что угодно. Агент один раз обжёгся на гипотезе «проблема в конфиге» и потом перестаёт рассматривать конфиг как класс причин. Вызов либы падает по случайной сетевой причине «библиотека не работает», дальше — костыли до конца сессии. И чем умнее модель, тем увереннее фиксация.
На практике абстрактное «будь объективным» не поможет, а сработает конкретика, встроенная в критерий успеха агента: «рассмотри минимум три гипотезы», «не отбрасывай вариант после одного провала», гейт в хуке, который не пропускает вывод без перепроверки альтернатив. По сути, мы вручную делаем исследование вариантов условием выигрыша (сам по себе агент не мотивирован). И если сессия накопила уверенные выводы из пары наблюдений, дешевле открыть свежий контекст, чем переубеждать залипшую модель.
Итого: bias — свойство не только данных, но и самого процесса принятия решений. Защищаться нужно на уровне целевой функции агента, а не датасета.
SWE-fficiency: Can Language Models Optimize Real-World Repositories on Real Workloads?
Бенч не про исправление багов, а про оптимизацию реального кода. Агенту дают репозиторий и медленную нагрузку. Дальше нужно понять, где именно тормозит код, найти релевантные тесты и написать патч, который ускоряет программу без поломки корректности. Это pass-to-pass задача: тесты уже проходят, надо сделать быстрее, а не починить падение.
В наборе 498 задач из 9 популярных Python-библиотек: numpy, scipy, pandas, sklearn и другие. Метрика Speedup Ratio сравнивает ускорение модели с ускорением экспертного решения. Результаты пока довольно слабые: лучшие агенты в среднем дают меньше 0.23 от экспертного ускорения, лучший Opus 4.5 набирает около 0.225.
Самое полезное в статье — не сама цифра, а разбор причин. Около 68% потенциального ускорения находится в функциях, которые модель вообще не меняет.
То есть проблема часто не в том, что агент плохо оптимизирует выбранное место, а в том, что он выбирает не то место. Ещё два частых паттерна: агент останавливается на первом измеримом улучшении и делает локальные кэши или точечные патчи там, где нужен более нормальный рефакторинг.
SWE-Milestone / EvoClaw: Evaluating AI Agents on Continuous Software Evolution
Здесь проверяют не отдельный PR, а последовательную эволюцию одной кодовой базы. Агент проходит цепочку связанных этапов, где каждое следующее изменение зависит от предыдущих, и должен не только добавлять функциональность, но и не накапливать ошибки.
Данные собирает агентный пайплайн DeepCommit: он берёт шумную историю коммитов и восстанавливает из неё проверяемые графы этапов. В финальном наборе 98 проверенных человеком этапов, 7 репозиториев и 5 языков. Одна полная прогонка стоит примерно 500 долларов на Opus 4.5, поэтому сам формат оценки тоже получается довольно тяжёлым.
Главный результат: на изолированных этапах сильные агенты дают больше 80%, а в непрерывном режиме падают до 38% и ниже. В полной эволюционной цепочке лучшие агенты закрывают только около 13% задач.
В текущей версии статьи лучший continuous Score составляет 38.03%, а лучший Resolve Rate в полной цепочке: 13.37%.
Интересное наблюдение: recall, то есть реализация новых фич, растёт, а precision, то есть устойчивость к регрессиям, быстро упирается в потолок. Иначе говоря, узкое место не в том, чтобы написать очередной кусок кода, а в том, чтобы не сломать накопленное состояние проекта. Ошибки начинают тянуться дальше по цепочке и усиливать друг друга.
UltraHorizon: Benchmarking Agent Capabilities in Ultra Long-Horizon Scenarios
Бенч на очень длинные исследовательские задачи с неполной наблюдаемостью. Агент взаимодействует со средой и должен сам раскрыть скрытые правила. В наборе есть Mystery Grid, Sequence Exploration и Alien Genetics Lab. В сложном режиме средняя траектория превышает 200 тысяч токенов и 400 вызовов инструментов.
Главный вывод: сильнее всего мешает именно длина горизонта, а не внутренняя сложность правил. В абляции по длине горизонта качество падает с 34.4% до 5.6% при переходе от уровня 1 к уровню 5, а число вызовов инструментов растёт с 45.5 до 88.0.
Авторы называют один из механизмов провала in-context locking: агент рано цепляется за гипотезу и дальше всё хуже исследует альтернативы. Это видно и по падению разнообразия действий, и по снижению энтропии токенов. Люди в среднем заметно лучше моделей, хотя размер разрыва зависит от конкретной среды. Простое увеличение числа шагов проблему не решает.
ComplexMCP: Evaluation of LLM Agents in Dynamic, Interdependent, and Large-Scale Tool Sandbox
Работа про более реалистичный режим автоматизации: агенты уже умеют вызывать отдельные API, но хуже держатся в среде, где инструментов много, они зависят друг от друга, а состояние может меняться и иногда сбоить.
Авторы собрали на базе MCP больше 300 инструментов в 7 stateful-песочницах. Среда воспроизводимая через seed, но при этом внутри есть непредсказуемые сбои API. Лучшие модели не поднимаются выше примерно 55% успеха, у людей 93.6%.
Самое полезное в статье: разбор провалов по траекториям.
- Tool Retrieval Saturation: поиск нужного инструмента захлёбывается, когда пространство действий становится слишком большим.
- Clean-Slate bias: модель действует так, будто начинает с чистого листа, и не проверяет текущее состояние среды.
- Strategic Defeatism: при временной ошибке модель часто не пробует восстановиться, а объясняет неудачу и останавливается.
Это хорошо рифмуется с предыдущей статьёй: в длинной сессии модели плохо переживают ранние сбои и слишком легко фиксируются на неудачной траектории.
Общий вывод по подборке: основные провалы здесь связаны не с тем, что модели вообще не умеют писать код. Проблема чаще в работе на дистанции: неверная локализация, накопление регрессий, залипание в ранних гипотезах и слабое восстановление после ошибок.
Теперь ко второй части. Здесь фокус не на том, какой агент выше в автономном лидерборде, а на более приземлённых вопросах: насколько честны тесты, как агенты работают в реальном использовании и что меняется, когда оценивать не модель отдельно, а пару человек плюс ИИ.
SWE-ABS: Adversarial Benchmark Strengthening Exposes Inflated Success Rates on Test-based Benchmark
Хорошая работа про то, почему лидерборды на тестовых бенчмарках могут завышать успех. На SWE-bench Verified лучшие результаты уже доходят примерно до 78.8%, но тесты там изначально писались для проверки конкретного PR, а не для строгого различения правильного решения от похожего, но неверного.
Авторы усиливают тесты в два этапа. Сначала coverage-driven: находят непокрытые участки через program slicing и добавляют проверки. Потом mutation-driven: синтезируют правдоподобные, но неправильные патчи-мутанты и смотрят, ловят ли их тесты.
Итог заметный: примерно один из пяти «решённых» патчей у топ-30 агентов оказывается семантически неверным и проходит только из-за слабых тестов.
После усиления тестов лучший агент падает с 78.80% до 62.20%, то есть на 16.6 процентного пункта. Отклоняется 19.71% патчей, которые раньше проходили, а таблица результатов сильно меняется: прежний лидер уезжает на 5-е место. В разборе ошибок чаще всего встречаются логические ошибки и неполные фиксы.
How can we assess human-agent interactions? Case studies in software agent design (PULSE)
Статья о том, как оценивать агентов в реальном использовании, а не только в автономном режиме на бенчмарке. В реальности пользователь часто направляет агента, уточняет задачу, принимает или отклоняет результат. Но явную оценку качества дают только около 5% пользователей, поэтому прямой A/B по таким меткам получается шумным.
PULSE комбинирует реальные оценки с псевдометками ML-модели, обученной на 15 интерпретируемых признаках. Формально это prediction-powered inference. За счёт этого доверительные интервалы в среднем сужаются примерно на 39.5%.
Метод развёрнут на OpenHands: больше 36 тысяч сессий, больше 15 тысяч пользователей и честные A/B-эксперименты. Самая интересная часть: кейсы на стенде.
Смена основной LLM даёт самый большой эффект, но gpt-5 в этом сетапе оказался хуже claude-4-sonnet на 7.8% по удовлетворённости. У gpt-5 также на 32% меньше сообщений от пользователей, а доля с пушем кода ниже на 15.9 процентного пункта. При этом claude-4 лучше claude-3.7 на 5.86%.
Отдельно важно, что результаты в реальном использовании расходятся с бенчмарками. Для пары claude-4 и gpt-5 авторы получают даже слабую отрицательную корреляцию, ρ = -0.11. То есть место в лидерборде и пользовательская полезность в живой работе могут быть разными вещами.
CentaurEval: Benchmarking Human-in-the-Loop Value in Agentic Coding
Здесь единицей анализа делают не человека и не модель по отдельности, а связку «человек + ИИ». Основная идея: есть Collaboration-Necessary задачи, которые плохо решаются и LLM в одиночку, и человеком без ИИ, но становятся решаемее при совместной работе.
В наборе 45 динамических шаблонов задач. Дизайн within-subject: 45 экспертов сравниваются с 5 сильными LLM в разных режимах работы. Цифры на картинке 3 довольно хорошо передают смысл: автономный ИИ решает 0.67%, минимальное вмешательство человека даёт 2.89%, человек без ИИ даёт 18.89%, а свободная совместная работа даёт 31.11%. Это плюс 64.7% относительно человека без ИИ.
Авторы отдельно описывают co-reasoning: стратегический ход может предложить как человек, так и модель. Поэтому привычная схема «человек ставит задачу, ИИ исполняет» здесь слишком узкая. Полезнее мерить не только скорость выполнения, а прирост от совместного рассуждения.
ToM-SWE: User Mental Modeling for Software Engineering Agents
Работа о том, что кодовому агенту нужна модель не только репозитория, но и пользователя. Рядом с основным SWE-агентом ставят лёгкого Theory-of-Mind-партнёра. Он смотрит на прошлые сессии, выводит цели, ограничения, предпочтения и стиль общения пользователя, а потом подсказывает их основному агенту, когда запрос неоднозначен.
Память устроена в три уровня: сырые сессии, модель конкретной сессии и профиль пользователя. Обновляется она в отдельной фазе, которую авторы называют sleeptime. Основной агент при необходимости вызывает consult_tom и получает подсказку о том, что, вероятно, важно для пользователя.
Результаты на картинке 4: 59.7% успеха на Stateful SWE-bench против 18.1% у OpenHands CodeAct, плюс 11.5 процентного пункта на Ambiguous SWE-bench, 63.4 против 51.9.
В полевом исследовании на 3 недели с 17 разработчиками 86.2% ToM-подсказок были полностью или частично приняты, а в задачах на понимание кода доля принятия доходила до 92%.
Эта работа хорошо стыкуется с PULSE и CentaurEval. Если реальная работа с агентом является совместной, то история взаимодействия становится полезным сигналом: что уточнить, какие ограничения не забыть и в каком стиле лучше отвечать конкретному человеку.
Главный вывод из этих работ: автономный лидерборд полезен, но плохо показывает реальную пользу агента. Стоит усилить тесты — и каждый пятый «решённый» патч оказывается неверным, а лидерборд перетасовывается. Если посмотреть на живые сессии, то место в бенчмарке почти перестаёт коррелировать с реальной пользой. Начать мерить связку человек+ИИ — и основной прирост даёт совместная работа, а не автономность модели. В итоге вопрос смещается с «кто выше в лидерборде» на «насколько полезна пара человек+агент», а старые автономные бенчи это уже не ловят.
