Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Систему научили самостоятельно улучшать LLM под конкретную задачу в пределах фиксированного вычислительного бюджета. Хотя препринт команды из HKUST(GZ), Xiaohongshu и других организаций не прошёл рецензирование и числа получили сами авторы, максимальный прирост составил 41,96 процентного пункта. Такой контур может заменить часть ручных экспериментов при настройке модели, но пока не инженера, который отвечает за данные и безопасный запуск кода.
Каждый цикл начинается с одного слабого места
ImproveAnyTask начинает с оценки текущей модели на проверочной выборке. Система собирает общий результат, показатели отдельных частей задачи, ответы модели и сведения о том, почему проверка их не засчитала.
Затем она сопоставляет два уровня ошибок. Общие показатели показывают масштаб проблемы, а отдельные примеры объясняют, как именно модель ошибается. Из найденных проблем система выбирает одну, которая сильнее всего влияет на целевой показатель.
Это ограничение защищает цикл от удобных, но второстепенных улучшений. Если одновременно передать агенту несколько проблем, он может выбрать ту, для которой проще найти данные или готовый рецепт, даже когда она почти не влияет на итоговый результат.
Для выбранной проблемы ImproveAnyTask ищет несколько подходов в статьях, коде и наборах данных. Каждый вариант описывает по общей схеме: откуда он взят, подходит ли текущей задаче, какой результат давал раньше, что потребуется для воспроизведения и насколько сложно подготовить ресурсы.
Система сравнивает ожидаемую пользу с трудоёмкостью и проверяет, укладывается ли метод в доступные ресурсы. В следующих циклах она использует не только новый поиск, но и историю отклонённых вариантов, результаты неудачных запусков и библиотеку уже проверенных решений.
Выбранный метод превращается в данные и конфигурацию обучения. Сначала система обрабатывает небольшую группу реальных примеров, проверяет формат и шаблон, затем запускает короткое обучение. Полный запуск начинается только после исправления ошибок загрузки, несовместимых шаблонов и проблем в конвейере данных.
Новая модель проходит ту же проверку, что и исходная. Если результат не вырос, следующий эксперимент снова начинается от предыдущей лучшей версии. Вместе с итогом сохраняются стратегия, сценарии обработки, параметры обучения и данные — в том числе для неудачных попыток.
Прирост проверили на знаниях, коде и работе с инструментами
Эксперименты провели с Qwen3.5-4B-Base и Qwen3.5-4B-Instruct на 11 задачах: от математики и следования инструкциям до программирования, вызова функций и общих агентов. Каждый запуск ограничили 24 часами и ресурсами, эквивалентными восьми NVIDIA H20.
Для выбора стратегии использовали только проверочную выборку, а итоговую тестовую часть скрывали от системы до конца оптимизации. Все варианты оценивали одним официальным кодом, с жадным выбором следующего токена; неудачные и пустые ответы получали нулевой балл.
Средний прирост базовой модели составил 18,29 процентного пункта. У версии Instruct, которая уже прошла постобучение до начала эксперимента, средний прирост достиг 11,97 пункта. Разница ожидаема по направлению: у исходной базовой модели оставалось больше слабых мест, которые можно исправить специализированными данными.
Авторы также заменяли диагностику ошибок, выбор стратегии и предварительные проверки более простыми процедурами, не ломая остальной цикл. Полная схема закончила с лучшим средним результатом в каждом выбранном бенчмарке. Значит, эффект связан не только с дополнительным обучением: важны выбор проблемы, сравнение методов и проверка исполнения до дорогого запуска.
Граница результата задана самим экспериментом: систему проверяли на двух вариантах одной модели размером 4B и на задачах с формальной оценкой ответа. Работа показывает, что такой цикл действует в этих условиях, но высокий балл на бенчмарке сам по себе не подтверждает безопасность, отсутствие утечек из внешних данных или пригодность модели для производственной среды.
Командам нужен управляемый контур, а не полностью автономный тренер
Работа меняет планы команд, которые регулярно адаптируют одну модель под разные функции продукта. Вместо отдельных сценариев для генерации данных, обучения и оценки имеет смысл проектировать единый контур, где каждый эксперимент начинается с разбора текущих ошибок и заканчивается записью воспроизводимых артефактов.
Практическая ценность здесь не в обещании «самообучающейся модели». ImproveAnyTask автоматизирует работу вокруг обучения: определяет приоритет, ищет рецепт, собирает данные, проверяет код и решает, какой вариант оставить. Параметры модели меняются обычным постобучением.
Для внедрения понадобится изолировать исполнение сгенерированного кода, ограничить доступ к внешним API и проверять происхождение данных и их лицензии. Нужна и отдельная тестовая выборка, которую агент не видит во время поиска: многократная настройка по одной проверочной части постепенно подгоняет решения под неё.
Поэтому ImproveAnyTask пока стоит рассматривать как архитектурный образец для внутренней платформы экспериментов. Он показывает, какие сведения следует передавать между этапами и почему неудачные попытки нужно хранить вместе с удачными. Переход к полностью автономному постобучению потребует воспроизвести результаты на собственных данных и определить, какие действия агент может выполнять без подтверждения инженера.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
