12 октября Meta* выпустила Muse Wonder и Muse Wonder Full. Компания акцентировала внимание на таких возможностях моделей, как Coding Agent, вызов инструментов и выполнение длительных задач. Wonder Full набрала 57,5 балла в SWE-Marathon, а DeepSWE 1.1 — 79,0 баллов.
Однако у Muse Wonder обнаружились проблемы с 3D-моделированием. BridgeMind провёл тест: требовалось создать лампу с прозрачным стеклянным корпусом, динамической лавой и эффектами освещения («»). Muse Wonder сгенерировала лишь красный цилиндр. BridgeMind усомнился в возможностях Muse Wonder из‑за Benchmaxxing — оптимизации под бенчмарки.
Александр Ван, главный по ИИ в Meta*, признал, что команда не проводила явного обучения под 3D‑демонстрации. Он призвал разработчиков оценить Coding‑способности Muse Wonder. В Model Card Meta* подтвердила: визуальное и пространственное рассуждение, особенно в 3D‑задачах, — слабое место модели.
Процесс обучения Muse Wonder включает два этапа. На этапе Pre‑training модель обучается на больших данных (язык, код, пространственные отношения и т. д.). Post‑training с помощью обучения с подкреплением формирует у модели устойчивые стратегии выполнения задач — например, поиск ошибок в коде, их исправление и запуск тестов. При увеличении масштаба обучения модель осваивает сложные стратегии разработки ПО: сужение области поиска, выбор инструментов, обработку ошибок, поддержание состояния задачи при многократных изменениях.
Meta* в технической статье указывает, что Muse Wonder прошла обучение на разнообразных длительных задачах и использует Active Focus. Благодаря этому при возникновении препятствий модель может пробовать другие варианты, восстанавливать выполнение и продолжать задачу. Ключевое условие такого обучения — среда должна давать модели полезную обратную связь.
Задача создания вулканической лампы («») усложняет привычные способы обратной связи для Coding Agent. Она включает 3D‑геометрию, прозрачные материалы, расчёт освещения и динамические деформации. При использовании Three.js модель должна создать стеклянный абажур, сформировать нерегулярную геометрию для расплава и использовать временные переменные или шумовые функции для изменения формы. Даже при корректном выполнении кода результат может быть ошибочным — например, из‑за неправильной настройки параметров прозрачности или отсутствия механизма плавного изменения формы расплава.
Компилятор и модульные тесты не способны напрямую выявить такие визуальные ошибки. Поэтому Agent должен иметь механизм визуальной обратной связи: делать скриншоты рендера, выявлять отклонения на изображении и преобразовывать визуальные проблемы в правки кода. Простое увеличение числа вызовов инструментов или времени рассуждений не заменяет этот механизм.
Причины генерации красного цилиндра можно установить только после полного выполнения траектории. Среди возможных причин — неправильное построение пространственной структуры, некорректное использование графических инструментов, отсутствие эффективной визуальной проверки после генерации.
Современные Agent Benchmark уже не сводятся к простому задаванию вопросов языковой модели. Например, SWE‑Marathon проверяет выполнение длительных задач по разработке ПО: модель должна выполнять в репозитории кода несколько операций (читать файлы, вызывать терминал, редактировать код) и проверять результаты через тесты. Успешность выполнения таких задач зависит не только от базовой модели, но и от Harness — фреймворка, который организует интерфейсы инструментов, управляет контекстом, сохраняет состояние задачи и обрабатывает исключения.
Грамотный Harness может автоматически извлекать важные ошибки, сжимать бесполезную информацию и сохранять прогресс изменений. При увеличении времени выполнения задачи способность управлять контекстом напрямую влияет на возможность системы работать непрерывно. Механизмы восстановления после ошибок тоже важны: если система сохраняет контрольные точки, определяет шаги, приведшие к ошибке, и позволяет выполнить частичный откат, можно избежать повторного выполнения всей цепочки задач.
На результаты также влияет бюджет рассуждений: разрешение Agent использовать больше токенов, выполнять больше вызовов инструментов или пробовать несколько вариантов решений расширяет пространство поиска и увеличивает шансы на исправление ошибок, но ведёт к росту затрат на выполнение.
В оценке SWE‑Marathon участвуют GPT‑6 Astra и Claude Fable 5. Проект использует Codex и Claude Code, что не позволяет провести контролируемое сравнение в едином Harness. Различия в конфигурации влияют на интерпретацию результатов. Для сравнения базовых моделей нужно унифицировать инструменты, Harness и бюджет на вывод.
Для оценки готовых Coding Agent важен результат полного выполнения системы. При сведении результатов в рейтинг сложно определить, за счёт чего вырос балл: из‑за возможностей модели, оптимизации фреймворка или большего объёма вычислительных ресурсов. Требуется детализация данных оценки Agent: уровень выполнения задач, расход Token, количество вызовов инструментов, время выполнения, случаи восстановления после сбоев.
Meta* изучает Benchmaxxing. В технической статье Muse Wonder есть раздел Capabilities That Generalize о проблемах Benchmaxxing. Meta* отмечает: модели с похожими результатами в стандартных Benchmark могут сильно отличаться в выполнении незнакомых задач. Задачи разделены на In-distribution (оптимизированы после обучения) и Out-of-distribution (без целевой оптимизации).
Сравнивалось поведение Muse Spark 1.3 и Muse Wonder Full при разном бюджете на вывод. Wonder Full лучше справляется с незнакомыми задачами по сравнению с предыдущей моделью. Meta* связывает это с улучшением базовой модели. Проблема оценки: неясно, насколько задача должна быть незнакомой. Смена репозитория кода — близкая задача для агента по исправлению кода, а смена фреймворка или API требует нового понимания среды.
Задача создания 3D-плавильной лампы включает не только разработку ПО, но и пространственное моделирование, рендеринг материалов и оценку визуального качества. Для оценки обобщения вне распределения недостаточно среднего балла — важны расстояние между задачами, требуемые знания и методы оценки. Чтобы выявить переобучение под Benchmark, нужны системные эксперименты: постепенно менять распределение задач — от исправления ошибок в незнакомом репозитории до использования новых API и задач визуального разработки без тестовых скриптов.
Можно изменять условия тестирования: временно заменять интерфейсы инструментов, вводить новые сообщения об ошибках, требовать от Agent самостоятельного проектирования программ проверки. Это позволяет проверить, умеет ли модель работать в незнакомых условиях: читать документацию, разрабатывать решения, проверять гипотезы, исправлять ошибки.
Для задач типа «» нужно не только проверять итоговое изображение, но и фиксировать, использует ли модель инструмент для создания скриншотов, распознаёт ли ошибки в материалах и геометрии, вносит ли эффективные изменения после получения обратной связи.
Анализ траектории выполнения задач полезнее простой статистики успехов — он помогает выявить пробелы в возможностях Agent и определить причину проблем: недостаток знаний, ошибки инструментов или сбои механизма обратной связи.
По мере развития открытых Benchmark разработка моделей будет использовать известные структуры задач для совершенствования методов обучения. Динамические задачи, скрытые тесты и более полная оценка процесса выполнения станут дополнением к фиксированным рейтингам.
Неудача Muse Wonder в задаче «» не отменяет её достижений в области разработки ПО и не доказывает недобросовестности Meta*. При этом разработчикам нужно переосмыслить текущие показатели Agent. Высокие баллы в рейтингах отражают выполнение задач в определённых условиях. Они полезны для выбора модели, но в сложных сценариях единичный балл даёт мало информации.
Разработка будущих Agent будет направлена на усиление возможностей в кодировании, вызове инструментов и выполнении длительных задач. Когда модели начнут выполнять самостоятельные задачи по разработке ПО, круг решаемых ими проблем выйдет за рамки существующих обучающих задач. Способность распознавать проблемы в незнакомых условиях, самостоятельно разрабатывать методы проверки и корректировать стратегию выполнения на основе обратной связи будет определять масштаб реальных задач, которые сможет решать Agent. Задача «» не даёт полного представления о возможностях Muse Wonder, но напоминает: успехи модели в знакомых задачах и её способность самостоятельно работать в неизвестных условиях нужно проверять отдельно.
* Meta Platforms Inc. признана экстремистской организацией, её деятельность запрещена на территории РФ.
Подписаться в Макс