Как сравнивать ИИ-модели на SVG и воксельной графике: сложность, детализация и аккуратность результата

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

Один удачный скриншот ещё не доказывает превосходство модели.

Что именно проверяет тест

SVG-сцена и воксельный мир предъявляют к модели разные требования. В SVG изображение описывают через векторные элементы, координаты, контуры, заливки, обводки и порядок слоёв. Воксельная графика требует пространственного мышления: модель должна разместить объекты в объёме, связать архитектуру с окружением и сохранить целостность сцены при добавлении деталей.

В пользовательском эксперименте GPT-6 Astra создала детализированный городской пейзаж в формате SVG, включив большое количество объектов и аккуратно расположив их на сцене. В сравнительном запуске с тем же заданием результат Fable 5, по оценке автора эксперимента, оказался заметно проще. Это наблюдение относится к конкретному сценарию, а не к универсальному рейтингу моделей.

В другом пользовательском тесте Astra сгенерировала воксельную сцену с архитектурой, окружением и множеством мелких элементов. Автор также сравнивал её результаты с Fable, Soul, Grok, Gemini и Claude и счёл сцену Astra более сложной и аккуратной. Независимая метрика, единый набор повторов и опубликованные исходные файлы для такого вывода не приведены, поэтому корректнее называть его оценкой автора эксперимента.

Одинаковое задание для всех моделей

Сравнение начинается с единого задания. Если одной модели разрешить несколько уточнений, а другой оставить только первоначальный запрос, результат будет отражать не только возможности моделей, но и разницу в процессе работы. Для каждого запуска фиксируют текст запроса, модель, режим генерации, доступные инструменты, ограничения по времени и момент, когда тест считают завершённым.

Хорошее задание описывает сцену через проверяемые признаки. Например, для городского SVG можно задать улицу, ряд зданий разной высоты, транспорт, деревья, фонари, окна, вывески, тени и определённое расположение объектов относительно горизонта. Для воксельной сцены полезно перечислить типы построек, рельеф, растительность, источники света, малые объекты и требования к свободным проходам между элементами.

• Один и тот же промпт передают всем моделям без ручной адаптации смысла.
• Одинаковые обязательные объекты отмечают в отдельном чек-листе.
• Каждую модель запускают в одинаковом или сопоставимом режиме.
• Результат сохраняют до исправлений и после каждой существенной итерации.
• Для повторяемости фиксируют дату теста и доступную версию модели.

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

Критерии оценки SVG-графики

SVG нельзя оценивать только по превью в браузере. Одинаково привлекательные изображения могут иметь совершенно разную ценность для дизайнера и frontend-разработчика: один файл будет разбит на понятные группы и легко изменяемые элементы, а другой окажется длинной последовательностью путей с повторяющимися координатами.

Структура и читаемость кода

Проверяют наличие осмысленных групп, повторное использование элементов, понятные идентификаторы, единообразную систему координат и отсутствие лишних фрагментов. Код выигрывает, если здания, фон, транспорт и декоративные элементы разделены логически, а повторяющиеся окна или деревья создаются через символы и ссылки, а не копируются без необходимости.

Геометрия и композиция

Геометрическая оценка отвечает на вопрос, совпадает ли описание с фактическим расположением объектов. Измеряют относительные размеры зданий, расстояние между ними, положение линии горизонта, перспективу улицы и пересечения контуров. Композиционная оценка учитывает визуальный центр, баланс крупных пятен, читаемость переднего и заднего планов, а также то, не перекрывают ли второстепенные детали главный объект.

Детализация без визуального шума

Количество элементов само по себе не равно качеству. Десятки окон, случайных линий и мелких прямоугольников могут увеличить объём SVG, но не сделать сцену информативнее. Полезная детализация поддерживает смысл изображения: фонари обозначают улицу, вывески различаются по назначению, деревья отделяют пространство, а тени помогают понять глубину.

Редактируемость

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

Критерии оценки воксельной графики

Воксельная сцена требует отдельной шкалы, поскольку двумерное превью не показывает всех пространственных ошибок. Объект может выглядеть убедительно с одного ракурса, но оказаться пустой оболочкой сзади, пересекаться с землёй или терять связь с окружением при повороте камеры.

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

В пользовательском эксперименте Astra создала клон Minecraft в одном HTML-файле, включив трёхмерный мир, окружение, объекты и мелкие детали; автор описал результат как полученный практически с нуля и без серии последующих исправлений. Такая демонстрация показывает широту одного запуска, однако не заменяет проверку исходного кода, стабильности, производительности и поведения проекта в разных браузерах.

Логотип OpenAI и его анимация, добавленные в отдельном эксперименте Astra, тоже следует рассматривать как часть конкретной демонстрации. Наличие заметного брендированного элемента не говорит само по себе о качестве пространственной модели, если тест не проверяет его геометрию, анимационную логику и корректность отображения на разных размерах экрана.

Как отделить сложность от полезности

Сложная сцена может быть бесполезной, если её трудно исправлять, долго загружать или невозможно встроить в проект. Для SVG полезно разделять визуальную сложность и техническую сложность: первая описывает число осмысленных объектов и уровней композиции, вторая включает размер файла, количество узлов, повторяемость элементов и понятность структуры.

Для воксельного мира добавляют проверку поведения. Сцена с большим количеством блоков не получает высокий балл автоматически, если камера проваливается под землю, здания не имеют проходов, а объекты стоят случайно. Нужен отдельный показатель функциональной завершённости, который не смешивают с художественной детализацией.

Итерации, токены, время и стоимость

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

В пользовательских тестах Astra описывали как модель, которая иногда получает хороший результат за меньшее число попыток. Автор связывал это с потенциальным сокращением расхода токенов и времени выполнения. Такая связь правдоподобна только для сценариев, где стоимость действительно зависит от длины запросов, ответов и количества запусков; конкретные цифры по этим тестам не приведены.

Для каждого запуска записывают входные и выходные токены, количество итераций, время до первого рабочего результата, время до финальной версии и объём ручных исправлений. Стоимость рассчитывают по тарифу, действовавшему на дату теста, и отдельно указывают, какие операции входили в оплату. Нельзя переносить стоимость одного интерфейса или режима на все задачи модели.

Как оформить сравнительную таблицу

Итоговая таблица должна показывать измеряемые свойства, а не объявлять универсального победителя. Для каждого критерия указывают наблюдение, способ проверки и степень уверенности. Если оценка сделана автором по визуальному впечатлению, это прямо обозначают; если есть автоматическая проверка или подсчёт элементов, приводят её отдельно от экспертного мнения.

Какие выводы нельзя обобщать

Сравнение Astra и Fable 5 на одной SVG-сцене не доказывает, что Astra лучше Fable 5 в дизайне, программировании или всех видах генерации графики. На результат влияют формулировка запроса, длина контекста, температура, доступные инструменты, ограничения среды и способность пользователя оценивать код.

То же правило относится к сравнению Astra с Soul, Grok, Gemini и Claude в воксельных мирах. Пользовательские демонстрации полезны для поиска гипотез, но они не заменяют независимое исследование с заранее заданными критериями и повторными запусками. Отсутствие опубликованных метрик не позволяет честно утверждать, что одна модель стабильно превосходит остальные.

А что считать победой: самый подробный кадр или самый удобный исходный файл? Ответ зависит от задачи. Дизайнеру важнее композиция и скорость правок, frontend-разработчику нужны валидный SVG и понятная структура, а исследователю требуется повторяемая процедура с журналом запусков и прозрачными ограничениями.

Практический протокол теста

1. Сформулируйте одно задание для SVG и одно задание для воксельной сцены.
2. Разделите требования на обязательные объекты, желательные детали и запрещённые упрощения.
3. Запустите каждую модель без ручной корректировки промпта.
4. Сохраните исходный ответ, визуальный результат и код.
5. Проверьте геометрию, композицию, структуру, редактируемость и полноту.
6. Проведите разрешённые итерации по заранее установленному правилу.
7. Запишите токены, время, число попыток и объём ручной работы.
8. Повторите запуск, если требуется оценить устойчивость результата.
9. Опубликуйте сырые материалы рядом с итоговой таблицей.

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