Mistral Large 4 собрал кубик, а затем потерял его

Мэттью Берман, известный тестировщик производительности ИИ, недавно предложил Mistral Large 4 создать интерактивную симуляцию кубика Рубика в браузере. Эта задача выходит за рамки генерации статических изображений, требуя от модели создания функционального кода, способного отрисовывать 3D-объект и реагировать на действия пользователя.

Успешная симуляция требует большего, чем просто визуальное сходство. Она должна:

• Отрисовывать 27 отдельных кубиков, из которых состоит куб
• Принимать ввод пользователя для выбора и вращения определенных граней
• Точно сохранять цвет и положение каждого элемента при сложных трансформациях

Изначально Mistral Large 4 выдал визуально убедительный куб, который позволял полностью вращать камеру. Первая итерация выглядела многообещающе, но обнаружился критический недостаток: кнопка «перемешать» (scramble), предназначенная для рандомизации состояния куба, не реагировала, из-за чего куб оставался постоянно собранным. Берман назвал это «провалом» в своем cube test, подчеркнув разрыв между визуальным выводом и функциональной интерактивностью.

Вторая попытка Бермана добиться от Mistral Large 4 функционального кубика Рубика привела к разочаровывающему парадоксу. После еще одной итерации сгенерированный код успешно реализовал side rotations, позволяя пользователям вращать грани так, как задумано. Однако это исправление привело к новой ошибке: при каждом вращении все цвета исчезали с поверхностей куба.

Этот результат подчеркивает важное различие в 3D-симуляциях. Хотя камера все еще могла вращаться вокруг куба, предлагая динамическую перспективу, это визуальное движение полностью отделено от внутренней механики головоломки. Правильное обновление положения грани и состояния цвета требует тщательной синхронизации между отрисованной геометрией и базовой моделью данных.

Сложность заключается в управлении 3D transforms, идентификаторами кубиков и отрисованными материалами. Каждый из 26 видимых «кубиков» должен сохранять свою уникальную идентичность и информацию о цвете, даже когда он перемещается по разным граням и ориентациям. Когда код Mistral Large 4 привел к исчезновению цветов, это указало на рассинхронизацию: кубики физически вращались, но связанные с ними свойства материалов или UV-развертки — то, как цвета накладываются на поверхности — не обновлялись должным образом или перезаписывались.

Речь идет не только об отрисовке, но и о постоянном state management. Симуляция должна отслеживать положение и ориентацию каждого кубика относительно центра куба, гарантируя, что информация о цвете остается неизменно привязанной к нужным элементам на протяжении каждого перемешивания и поворота. Модель с трудом поддерживала это сложное, взаимосвязанное состояние при итеративных изменениях кода.

Видео Бермана «Mistral Large 4 провалил мой тест с кубиком Рубика» раскрывает критический нюанс, который часто упускается при оценке LLM: он приписывает окончательный провал не самой Mistral Large 4, а взаимодействию между моделью и ее «обвязкой» (harness). Это различие жизненно важно для понимания сложной разработки на базе ИИ.

Под «обвязкой» понимается окружающий рабочий процесс агента — автоматизированная система, которая предоставляет модели контекст, применяет ее правки, а также запускает или проверяет сгенерированный код. Ее поведение может существенно влиять на то, что модели удается исправить, особенно при итеративной отладке. Например, обвязка может некорректно применять diff-файлы, неверно интерпретировать инструкции модели или не предоставлять исчерпывающую обратную связь по результатам тестов.

В этом сценарии, хотя Mistral Mistral Large 4 создал код, который сделал боковые вращения функциональными, последующая обработка со стороны harness могла нарушить визуальное состояние кубика, из-за чего цвета исчезли. Видео демонстрирует результат, но не выявляет первопричину, что затрудняет однозначное определение вины: логика модели, сгенерированный код, применение правок или среда тестирования.

Это подчеркивает растущую проблему в разработке с помощью ИИ: отделение возможностей модели от производительности инструментов, которые ими управляют. По мере того как модели становятся сложнее, качество harness — его способность поддерживать состояние, управлять правками в нескольких файлах и предоставлять точную обратную связь — становится «узким местом». Разработчики, желающие получить более подробную информацию о текущих достижениях Mistral, могут ознакомиться с Mistral AI - Latest News and Model Announcements. Это различие имеет решающее значение для понимания того, почему сложные задачи, такие как тест с Rubik's cube, могут давать сбой даже при использовании мощных моделей.

Тест с кубиком от Berman подчеркивает критическое различие: статические бенчмарки кодирования или привлекательные первые рендеры часто упускают из виду основные недостатки. Интерактивные задачи с сохранением состояния показывают, как ИИ справляется с постоянными данными, прослушивателями событий и обновлениями пользовательского интерфейса в реальном времени на протяжении нескольких итераций. Модель может сгенерировать красивый начальный код, но не суметь поддерживать согласованность, когда пользователь взаимодействует с ним или когда сама система итерирует код.

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

Производительность Mistral Mistral Large 4 в Rubik's cube test служит показательным примером неудачи предпринятого рабочего процесса. Модель смогла сгенерировать визуально привлекательный интерактивный 3D-объект, а позже — функциональные вращения. Но сложное взаимодействие пространственных координат, синхронизации состояний и рендеринга UI оказалось слишком сложным для итеративного процесса, который использовал Berman.

Хотя эта единственная демонстрация не может в широком смысле доказать, что Mistral Mistral Large 4 не способен к программированию, она подчеркивает проблемы при генерации кода с сохранением состояния в несколько этапов. Проблема, как предполагает Berman, вероятно, кроется во взаимодействии между моделью и ее harness, а не только во внутренних возможностях модели. Этот сложный танец между ИИ и его операционной средой остается значительным препятствием для продвинутых ИИ-агентов по программированию.

Что Mistral Large 4 сделал не так в тесте с Rubik’s Cube?

Его первая версия отрисовала кубик, но не реагировала на кнопку перемешивания. Более поздняя итерация позволила вращать грани, но цвета кубика исчезли.

Не понял ли Mistral Large 4, как работает Rubik’s Cube?

Тест этого не доказывает. Он показывает, что сгенерированная реализация с трудом справлялась с одновременной работой взаимодействий и визуального состояния.

Что означает «harness» в этом тесте?

Harness — это инструментарий и рабочий процесс вокруг модели, который управляет правками, контекстом, выполнением кода и итерациями.

Почему Rubik’s Cube — это сложный тест для ИИ-кодирования?

Работающая симуляция должна координировать 3D-рендеринг, вращение граней, элементы управления и постоянное состояние цветов, а не просто рисовать кубик.