Отношение к агентским системам стало более «взрослым»: не как к набору эвристик вокруг модели, а как к полноценной инженерной системе, где каждый компонент заслуживает внимания и постепенно становится отдельным объектом оптимизации.

1. Написание промптов превращается в ML-задачу

Понравилась линия работ вроде GEPA и ACE. Главная мысль: промпт — это уже не «текст, который хорошо написал человек», а оптимизируемый компонент системы.

В GEPA промпт улучшают эволюционным алгоритмом, но мутации придумывает не случайность, а LLM-рефлектор: он смотрит на траектории текущего кандидата (рассуждения, вызовы инструментов, ответы), формулирует на естественном языке, что пошло не так, и на основе этой критики предлагает правку c красивым названием — natural language reflection. Кандидаты держатся на Pareto-фронте по разным задачам, чтобы отбор не схлопывал разнообразие в один «усреднённо хороший» промпт.

На фото — «было-стало»: стартовый промпт и тот, до которого дошла система.

ACE расширяет эту идею: оптимизировать можно не только промпт, но и рабочий контекст агента — инструкции, память, накопленные стратегии. Мне понравилась формулировка context as an evolving playbook: контекст не переписывается целиком (что ведёт к потере деталей), а обновляется инкрементально: новые наблюдения добавляются, старые — уточняются или удаляются.

2. Оптимальный выбор примеров для обучения

Хорошая мысль — обучать модель на примерах из «зоны её ближайшего развития». Слишком простые примеры не развивают — модель и так хорошо умеет их решать. Слишком сложные — тоже плохо: модель не может извлечь из них стабильный сигнал. Самые ценные — те, где модель уже почти может, но ещё ошибается.

Ниже — несколько докладов примерно на эту тему.

В работе Prompt Curriculum Learning авторы показывают, что задачи промежуточной сложности — где модель имеет около 50% вероятности успеха — оказываются наиболее эффективными. Предлагают PCL — алгоритм, в котором обученная value-модель за один forward pass предсказывает вероятность, что текущая политика справится с промптом, и отбирает в батч примеры с вероятностью ~0,5. Value-модель обучается параллельно с политикой, поэтому понятие «средней сложности» сдвигается вместе с ростом модели.

Похожая, но с другим механизмом — работа Actor-Curator. Идея в том, чтобы обучить модель-«куратора», которая отбирает не просто сложные или лёгкие примеры, а те, что должны дать максимальный прирост качества текущей модели.

Ещё одна интересная работа — Cram Less to Fit More — о том, что у модели есть ограниченная «память» на факты. Если пытаться запихнуть в обучение слишком много фактической информации, она начинает запоминать хуже. Авторы показывают, что иногда лучше не добавлять всё подряд, а аккуратно отбирать данные — тогда модель удерживает больше полезного.

В целом это рифмуется с DATA-FM invited talk Baharan Mirzasoleiman — о том, что для SFT/RL нужно не просто «больше данных», а данные правильной сложности и разнообразия.

3. Для tool-calling-агентов можно оценивать не только финальный ответ

Если агент ответил правильно, это ещё не значит, что он хорошо пользовался инструментами. Может быть, поиск вообще был не нужен. Или поиск был нужен, но запрос был плохой. Идея в том, чтобы оценивать тулколы независимо: был ли вызов инструмента нужен, был ли он полезен, улучшил ли вероятность правильного ответа. В Tool-call Reward Model предлагают делать реворд на уровне каждого вызова инструмента.

4. О выборе рецепта обучения

Percy Liang красочно рассказал о Marin — опенсорсном проекте, где с нуля обучили 32B-модель. В докладе много интересного о факапах, практические рецепты обучения, scaling laws, и то, как их вывели. Автор постулирует открытость — не только весов, но и всего процесса обучения модели. Команда Marin открыла даже свою очередь тикетов.

RL сейчас становится одним из самых дорогих и плохо предсказуемых этапов после претрейна — особенно, если много генерировать длинные reasoning/tool-calling-траектории. Допустим, мы используем GRPO: берём батч запросов, и для каждого сэмплируем G траекторий/ответов. Для них считаем reward, а advantage определяется относительно остальных ответов на тот же запрос.

Если запрос слишком лёгкий или слишком сложный, все G ответов могут получить одинаковый reward — например, все правильные или все неправильные. Тогда такой пример даёт мало полезного RL-сигнала. Помимо этого, цепочки генерировать дорого, а длинные — очень дорого. Несколько классов идей о борьбе с этим:

1. Curriculum — идея не новая. Давайте растить сложность запросов в процессе улучшения модели. Есть много вариантов, как это делать. Один из них — использовать трансформерное предсказание сложности и бандитов. Думаю, конкретная реализация не так важна, главное, что при смешивании множества RL-сред в одном обучении единой модели нужно иметь хорошие мониторинги доли успехов по каждой задаче и бороться, если возникает проблема.

2. Генерировать роллауты не каждый раз с нуля, а начинать с префиксов предыдущих. Тогда можно получить больше бит информации на единицу компьюта и получить дерево траекторий. Для внутренних вершин дерева можно подсчитывать статистику успехов и использовать для process reward.

3. В случае, если основной тул в цепочках — это web search, то можно отдельно оценивать, насколько очередное добавление в инфоконтекст полезно: нельзя ли было дать ответ без него и продвинуло ли оно к правильному ответу (observation reward).

Комбинация второго и третьего подходов заставила меня вспомнить AlphaZero, где модель предсказывает распределение по возможным ходам P и оценку позиции Value. Затем Tree Search строит дерево и получает более информативную статистику по ходам, после чего модель учится приближать результаты этого Tree Search.

В LLM-случае «ход» — это не дискретный шахматный ход, а кусок reasoning плюс очередной tool call, плюс observation, и пространство ходов не только больше, но и гораздо менее структурированное. Напрямую не используешь, но точно интересно подумать над экспериментами, где после генерации скольки-то роллаутов из позиции переранжируем их по process и observation reward.

4. Scaling recipes плюс scaling laws для RL. Тема неплохо изучена для претрейна. В Meta* считают, что у них работает для RL. Scaling там устроен по-другому — имеет форму сигмоиды и можно экстраполировать качество с малых запусков на более крупные. Если правда работает, точно надо использовать — особенно, когда смешиваем несколько RL-сред для понимания, сколько нужно тратить компьюта на оптимизацию каждой.

Чтобы повысить продуктивность, к каждому дню нужно готовиться минимум по паре часов, составляя с LLM-ассистентом план того, что хочешь посетить. Помогают промпты в стиле «Завтра утренняя постер-сессия на ICLR, интересны такие-то темы, в основном топовые лабы, раньше были интересны такие-то работы. Что посмотреть?» Дальше фильтруешь, просишь отсортировать постеры, часть просишь удалить, а где-то предлагаешь добавить. Затратно, но зато не просто бродишь, читая бесконечные названия статей.

Первое, что я заметил, ещё до приезда в Рио, что в этом году на ICLR было заметно больше погодных работ, чем раньше. С одной стороны, это хорошо, что область погодного ML развивается. С другой — конкуренция растёт, и надо постоянно больше и качественнее работать, чтобы успевать за отраслью и сохранять лидирующие позиции. Основная масса работ была по двум направлениям: foundation-погодные модели и наукаст.

Task-Adaptive Parameter-Efficient Fine-Tuning for Weather Foundation Models

Есть такое направление, как тюнинг fountation-погодных моделей под различные downstream-задачи. Это связано с тем, что для финальной решаемой задачи не всегда необходимо моделировать с хорошим качеством всю атмосферу, но при этом всё-таки хочется учитывать эту информацию. Поэтому можно подтюнить модель под необходимый параметр и немного принебречь качеством остальных.

Здесь авторы предлагают не тюнить модель целиком, а использовать, так называемый, обучаемый soft prompt, чтобы говорить модели, какую именно задачу она должна сейчас решать. Утверждается, что модель хорошо учится с ним работать. Авторы проверяли работу своего подхода поверх модели Aurora от Microsoft и получили хорошие результаты для задач super-resolution, прогноза осадков и постпроцессинга ансамблевых прогнозов.

Идейно подход выглядит интересно, но пока он проверялся только на грубом разрешении сетки, и не совсем понятно как этот подход себя покажет на продовых моделях.

Extreme Weather Nowcasting via Local Precipitation Pattern Prediction

Если рассматривать наукаст, как задачу перемещения существующих осадков, то она — по большей части — уже решена. Но есть две открытых проблемы в этой области: возникновение новых осадков и прогноз экстремальных значений. Здесь авторы концентрируются на второй подзадаче.

Они делают предположение, что одна из причин плохого восстановления сильных осадков — структура декодера, и предлагают его модификацию. При этом в работе сравнивают разные варианты того, как можно делать апсемплинг картинки в процессе декодирования. Интересно, что авторы — одни из немногих, у которых Фурье-лосс для задачи наукаста заработал лучше стандартно используемых MSE и MAE.

Авторы проверялись на стандартных датасетах SEVIR и MeteoNet, а также на их собственном KMA, который должен быть публично доступен. Не во всех сетапах удалось получить SotA, но картинки выглядят заметно чётче по сравнению с аналогами.