ИИ научили рисовать не пикселями, а кодом, через обучение с подкреплением

У генерации изображений ИИ есть ограничение: единственный способ участвовать в процессе, промпт. Поправить готовую картинку напрямую нельзя, для любого изменения нужно заново обращаться к модели. Именно это раздражение и подтолкнуло автора статьи, Сурью, вместе с другом Кэмероном Франц (в команде проекта также значится Алекс Ван) обучить языковую модель методом обучения с подкреплением писать не пиксели, а код: полноценные JavaScript-скетчи на базе библиотеки p5.brush, которые затем рендерятся в изображение. Код остаётся артефактом и его можно редактировать напрямую, без нового прохода через модель.

Обучение построено как цикл из четырёх шагов, повторяемый тысячи раз. Модель получает промпт вида «нарисуй персиковый гибискус акварелью» и пишет полный p5.brush-скетч. Скетч рендерится в изолированной среде Puppeteer и превращается в PNG. Картинку сравнивают с двумя случайными эталонными картинами из вручную оценённого пула, отдельная модель-судья решает, какая акварель лучше. Это решение превращается в сигнал вознаграждения, который обновляет модель через алгоритм GRPO, после чего цикл повторяется заново.

Эталонный пул содержит 581 картину, вручную отобранную из 1664 сгенерированных вариантов: 117 отнесены к «топ-уровню», 266, к «нормальным», ещё 198 добавлены из отдельного прогона генерации, чтобы расширить набор по цветам, где рейтинговых примеров не хватало. Все изображения в пуле, сами продукт ИИ: человеческих образцов авторы найти не смогли, поскольку p5.brush, нишевый инструмент, которым пользуется мало художников. Генерация шла по двум конвейерам: «AutoResearch», где Opus 4.6, GPT-5.4 и Gemini 3.1 Pro итеративно дорабатывали изображения по эталонным фотографиям под контролем модели-судьи с обратной связью, и более крупный прогон только на Gemini 3.1 Pro. Оба конвейера использовали системный промпт, который сам был выведен методом GEPA.

Работа над системным промптом оказалась отдельной задачей. Ранние версии включали 400-строчное описание API библиотеки p5.brush, и модель уверенно писала код, вызывая функции, которых в библиотеке не существует. Решение нашли через GEPA, библиотеку оптимизации промптов, которая эволюционирует формулировку против функции оценки: авторы прогнали 200 итераций против судьи с семью примерами «вкуса». В итоге промпт сошёлся к строгому списку всего из восьми разрешённых кистей, без документации API и без примеров. Именно на версии, из которой убрали 400-строчный референс целиком, впервые получилось так, что три генерации из трёх дали узнаваемые очертания гибискуса. Вывод авторов: подробная справочная документация в системном промпте заставляет модели придумывать несуществующие функции API, а короткий и жёсткий список разрешённого ограничивает вывод лучше, чем исходная полная спецификация.

Автор подчёркивает: обучение с подкреплением требует проверяемого вознаграждения, математическая задача решена верно или нет, партия выиграна или проиграна. Эстетическое качество не проверяется ни так, ни так: критерии оценки и функцию вознаграждения приходится придумывать вручную, и здесь легко просчитаться в обе стороны, слишком жёсткая функция заставляет модель просто копировать оценённые примеры, слишком мягкая, не даёт ей научиться чему-то конкретному. Сам Сурья не считает получившийся способ рисования лучшим, он заметно медленнее обычной генерации по промпту, но ему важно, что теперь можно прикладывать усилия и к промпту, и к модели, и к самому артефакту, а не только к формулировке запроса. Проект не завершён: команда планирует ещё один финальный прогон обучения, чтобы исправить обнаруженные проблемы, а полный технический отчёт обещают опубликовать в июне 2026 года.

Ключевые факты

Сурья и Кэмерон Франц (в команде также Алекс Ван) обучили языковую модель методом RL писать JavaScript-код (p5.brush-скетчи), рендерящийся в изображение, вместо прямой генерации пикселей, код остаётся редактируемым артефактом.
Цикл обучения повторялся тысячи раз: модель пишет скетч, скетч рендерится в PNG через Puppeteer, модель-судья сравнивает результат с двумя случайными картинами из эталонного пула, сигнал вознаграждения обновляет модель через алгоритм GRPO.
Эталонный пул, 581 картина, вручную отобранная из 1664 генераций (117 «топ-уровня», 266 «нормальных», 198 дополнений); все изображения в пуле сами сгенерированы ИИ (Opus 4.6, GPT-5.4, Gemini 3.1 Pro), человеческих образцов не нашлось.
400-строчное описание API в системном промпте заставляло модель придумывать несуществующие функции; после оптимизации методом GEPA за 200 итераций прописали строгий список всего из восьми разрешённых кистей без документации, и именно эта версия впервые дала узнаваемый цветок сразу в трёх генерациях из трёх.
Автор считает подход не лучшим способом рисовать, он заметно медленнее промпт-генерации, но ценит контроль над промптом, моделью и артефактом сразу; проект не завершён, полный технический отчёт обещают в июне 2026 года.

Почему это важно

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

Кому это важно

Исследователям, которые проектируют функции вознаграждения для RL на творческих и субъективных задачах, там, где нет однозначно верного ответа. Инженерам, строящим системы «модель-судья» поверх LLM. Разработчикам, работающим с генеративным искусством на основе кода (creative coding), и всем, кто использует GEPA или похожие инструменты для эволюции системных промптов вместо их ручного написания.

Как это применить

Из статьи можно вынести готовый рецепт: цикл из четырёх шагов (промпт → модель пишет код → код рендерится в изолированной среде → отдельная модель-судья сравнивает результат с эталонами и выдаёт сигнал вознаграждения → обновление весов через GRPO), повторяемый тысячи раз. Системный промпт стоит не писать вручную, а выводить оптимизатором вроде GEPA против функции оценки. Эталонный набор для сравнения можно собрать даже полностью из образцов, сгенерированных другими моделями, если человеческих примеров недостаточно, но каждый образец нужно вручную оценить. А описание доступных модели инструментов (API) лучше делать не исчерпывающей документацией, а коротким жёстким списком разрешённого, по опыту авторов, это ограничивает вывод модели лучше, чем полная спецификация.

Можно ли доверять

Это личный проект команды из трёх человек, Сурьи, Кэмерона Франц и Алекса Вана, а не публикация исследовательской лаборатории или компании; в тексте не указана ничья институциональная принадлежность (университет, работодатель), и базовая модель, которую дообучали, в тексте статьи не названа явно, на неё указывает только URL статьи (Qwen). Численного сравнения качества обученной модели с базовой линией в статье нет, только кривые вознаграждения и качественное описание результатов, представленные самими авторами. Полный технический отчёт с более подробной методологией обещан на июнь 2026 года, но пока не опубликован, детали стоит считать предварительными до его выхода.

Риски и подводные камни

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

«Я не думаю, что это, лучший способ создавать изображения. Он, по сути, гораздо медленнее.»

— Сурья, автор проекта