Как оценивать качество изображений GPT Image 2: практический чек-лист для команд
GPT Image 2 Team
10 мая 2026 г.
Практическая схема оценки GPT Image 2: жесткие проверки, семантический контроль, метрики изображений, ручная оценка, тесты устойчивости и отчетность для CI.
Оценка вывода GPT Image 2 quality — это не то же самое, что вопрос о том, впечатляет ли изображение. Красивое изображение все равно может fail выполнять работу, если требуемый текст написан с ошибкой, метка product изменена, кнопка пользовательского интерфейса отсутствует, логотип смещается или при редактировании изменяются части изображения, которые должны были оставаться нетронутыми.
Для команд лучший вопрос: сможет ли GPT Image 2 завершить этот workflow достаточно надежно для отправки?
Этот вопрос требует структурированной системы оценки. Самый полезный подход — трехслойный model:
- Жёсткие ограничения для не подлежащих обсуждению требований, таких как точный текст, безопасность, необходимые объекты и редактирование местоположения.
- Оценка на уровне параметров за семантическое соответствие, визуальный quality, пространственную точность, согласованность бренда и сохранность.
- Человеческие предпочтения или A/B review для решений, когда автоматических показателей недостаточно.
Не сводите изображение quality к одному среднему баллу. За одним баллом скрывается тип отказа, который действительно имеет значение. Маркетинговый плакат с визуальной оценкой 4,6/5, но с одним неправильным символом в заголовке, не является «почти хорошим»; это неудачный производственный актив.
Этот контрольный список предназначен для покупателей, авторов, команд product, дизайнеров, команд контроля качества и инженерных команд, которым необходимо сравнить результаты GPT Image 2 в реальных рабочих процессах. Он сохраняет практические пороговые значения и структуру оценки, используемые при серьезном тестировании изображений model, избегая при этом распространенной ловушки чрезмерного доверия устаревшим метрикам, таким как FID или Inception Score.
Начните с рабочего процесса, а не модели
Прежде чем выбирать метрики, определите сценарий. Изображение product, макет мобильного пользовательского интерфейса, плакат, таблица персонажей и обучающая диаграмма medical не выполняют fail одинаковым образом.
Если ваш набор данных еще не указан, сначала разделите оценку на фрагменты scenario. Затем решите, какие проверки важны для каждого среза.
| Домен | Распространенные случаи использования GPT Image 2 | Первая проверка quality | Примечания |
|---|---|---|---|
| Продукт | Снимки product на белом фоне, упаковка, реклама, редактирование элементов бренда | Точный текст, полные этикетки, четкие края, локальные правки, которые не разливаются. | Лучше всего подходит для парных тестов редактирования и жестких гейтов. |
| UX | Макеты пользовательского интерфейса, потоковые экраны, диаграммы информационной архитектуры, изображения для копирования кнопок. | Необходимые компоненты, иерархия макета, точный текст кнопок, удобство использования. | Текстовые ворота должны предшествовать показателям красоты. |
| Креатив | Ключевые визуальные эффекты рекламы, комиксы, раскадровки, плакаты, описания персонажей. | Последовательность стиля, непрерывность повествования, читаемый текст, последовательность бренда или персонажа. | Человеческие предпочтения очень ценны |
| Медицинский | Обучающие иллюстрации, синтетические визуальные эффекты в медицинском стиле, диаграммы в стиле кейсов. | Конфиденциальность, риск почти дублирования, фактичность, клинически значимые атрибуты | Варианты использования и нормативные стандарты должны калиброваться отдельно. |
| Промышленный | Этикетки на оборудовании, иллюстрации обслуживания, технические таблички, концептуальные изображения | Точность текста и знаков, пространственные отношения, достоверность материала и структуры. | Отраслевые допуски должны быть определены до запуска |
Если у команды ограниченные ресурсы, начните с четырех срезов:
- Плакаты с большим количеством текста
- Мокапы пользовательского интерфейса
- Локальное редактирование изображений
- Сложная композиционная композиция prompts
Эти четыре категории раскрывают многие ошибки, которые имеют значение в производстве: текст с ошибками, отсутствующие элементы, слабое пространственное мышление, чрезмерное редактирование и неглубокое отслеживание prompt.
Отделение тестов генерации от тестов редактирования
Оценку GPT Image 2 следует разделить на два этапа.
Генерационные тесты начинаются с prompt и не имеют точного эталонного изображения. Главный вопрос заключается в том, соответствует ли изображение prompt: объектам, атрибутам, связям, количеству, стилю, тексту и ограничениям безопасности.
Тесты редактирования начинаются с входного изображения, иногда с маской или целевой областью. Главный вопрос заключается в том, произошло ли запрошенное изменение, в то время как все остальное осталось стабильным. Редактирование quality — это не просто вопрос «хорошо ли выглядит итоговое изображение?» Это также вопрос: «Сохранил ли model идентичность, макет, форму логотипа, детали product и нетронутые области?»
Для обоих треков обновляйте версию при каждом запуске. Согласно официальной документации OpenAI по созданию изображений workflows, команды должны обращать внимание на поля конфигурации model, такие как выходные данные size, quality, формат и сжатие, если они доступны. Не сравнивайте прогоны, если эти параметры, правила предварительной обработки и версии prompt не заблокированы.
Как минимум храните:
| Поле | Почему это важно |
|---|---|
| Версия model и model | Предотвращает, чтобы скрытые изменения model выглядели как изменения prompt |
| prompt версия | Делает возможным регрессионный анализ |
| size и quality | Вывод quality может меняться в зависимости от разрешения и настроек quality. |
| формат вывода и сжатие | Сжатие JPEG/WebP может изменить OCR, метрики и визуальные артефакты. |
| входной хеш изображения | Требуется для воспроизводимости редактирования |
| хеш ссылочного набора | Требуется для парных тестов |
| Политика seed | Требуется при сравнении нескольких кандидатов по prompt. |
| оценить версию prompt | Автоматизированные судьи являются частью системы измерения |
| версия человеческой кодовой книги | Правила аннотатора должны быть стабильными |
| CI задание и git commit | Делает решение проверяемым |
Трехуровневая система качества
Уровень 1: Жесткие проверки
Жесткие проверки — это проверка «прошел/не прошел». Их следует использовать для требований, которые не подлежат обсуждению.
Обычные жесткие проверки:
- Требуемый текст абсолютно правильный.
- Необходимые объекты присутствуют.
- Запрещенные объекты или небезопасный контент отсутствуют.
- Изображение не нарушает правила бренда и конфиденциальности.
- В задаче редактирования нетронутые области остаются неизменными.
- Метка product, логотип, лицо или область, чувствительная к идентификационным данным, сохраняются.
- Выходные данные соответствуют требуемому формату, фону и ограничениям обрезки.
Ресурсы с большим количеством текста заслуживают особого отношения. Если для prompt требуется фраза «Place Order», а на изображении указано «Place Odrer», вывод не будет выполнен. Не усредняйте это с визуальным качеством.
Уровень 2: Оценки измерений
После жестких ворот оцените результат по измерениям. Шкала 0–5 или 1–5 работает, если каждая точка определена четко.
Рекомендуемые размеры:
| Измерение | Что спросить | Цель по умолчанию |
|---|---|---|
| Семантическое выравнивание | Выражает ли изображение основную цель prompt? | Не менее 4/5 в среднем |
| Наличие объекта | Все ключевые объекты видны? | Воспоминание ключевого объекта не менее 0,95. |
| Точность атрибута | Привязаны ли цвета, материалы, количества и этикетки к нужным объектам? | Минимум 0,90 |
| Точность пространственных отношений | Правильно ли расположены лево/право, выше/ниже, спереди/сзади и окклюзия? | Минимум 0,90 |
| Рендеринг текста | Является ли требуемый текст читабельным и точным? | 100% для необходимого текста |
| Изменить местоположение | Изменился только запрошенный регион? | Не менее 4/5 в среднем |
| Сохранение идентичности или бренда | Сохранились ли лица, логотипы, шрифты и идентичность product? | Не менее 4/5 в среднем |
| Визуальный quality | Является ли изображение свободным от артефактов и пригодно ли оно для производства? | Не менее 4/5 в среднем |
Важным моментом является то, что quality разлагается. model может быть силен в визуальной полировке, но слаб в пространственных отношениях. Другой может хорошо сохранять входные изображения, но испытывать трудности с точной типографикой. Оценка должна сделать эти различия видимыми.
Уровень 3: человеческие предпочтения и тесты A/B
Человеческие предпочтения review по-прежнему необходимы. Автоматизированные показатели полезны, но они упускают из виду многие производственные проблемы: вкус, баланс макета, соответствие бренду, правдоподобная визуализация материалов и ощущение завершенности дизайна.
Для тестов A/B рандомизируйте размещение слева и справа, скройте идентификатор model и разрешите связи. Сообщайте о показателе win с доверительными интервалами, а не просто говорите: «Модель Б почувствовала себя лучше».
Используйте тесты A/B для:
- Выбор между настройками GPT Image 2.
- Сравнение GPT Image 2 с существующим рабочим процессом.
- Проверка creative quality после прохождения жестких врат.
- Решение о том, улучшила ли версия prompt результат.
Практический выбор показателей
Не используйте каждую метрику изображения только потому, что она существует. Выбирайте метрики в зависимости от режима сбоя.
| Метрика | Направление | Лучшее использование | Основная сила | Основная слабость | Практический порог |
|---|---|---|---|---|---|
| FID | Чем ниже, тем лучше | Регрессия на уровне распределения | Исторически распространено для распределения сгенерированных изображений. | Низкая эффективность выборки; чувствителен к предварительной обработке; слаб для современных оперативных задач | Не используйте абсолютный порог освобождения; сравнивать только с тем же набором ссылок и предварительной обработкой |
| Inception Score | Чем выше, тем лучше | Устаревшие проверки генерации без ссылок | Простой | Не сравнивается с реальным распределением данных; может ввести в заблуждение при детальном ранжировании | Не используйте в качестве шлюза |
| LPIPS | Чем ниже, тем лучше | Парные правки и реконструкция | Ближе к разнице восприятия, чем ошибка пикселя | Нужна парная ссылка; несопоставимо между несвязанными задачами | <= 0,20 приемлемо, <= 0,10 сильно |
| CLIPScore | Чем выше, тем лучше | Выравнивание подсказки изображения | Легко, reference image не требуется | Может вести себя как мешочек слов и пропускать сложные отношения. | Используйте относительные пороговые значения, например, не хуже 97 % от базового уровня. |
| PSNR | Чем выше, тем лучше | Редактировать точность и реконструкцию | Дешево и легко интерпретировать | Плохая перцептивная чувствительность. | >= 30 дБ приемлемо, >= 35 дБ сильно |
| SSIM | Чем выше, тем лучше | Структурное сохранение | Лучше, чем PSNR по структуре | Менее полезно для изменения стиля и тонкой текстуры. | >= 0,90 приемлемо, >= 0,95 сильно |
| DISTS | Чем ниже, тем лучше | Перцептивная добавка | Более устойчив к компромиссам между текстурами и структурами. | Менее распространен в производственных стеках, чем SSIM или LPIPS. | Используйте как относительную регрессию, а не абсолютные ворота. |
FID и Inception Score не должны быть основными воротами выпуска для рабочих процессов GPT Image 2. Они могут помочь отслеживать изменение уровня распространения с течением времени, но не отвечают, был ли выполнен конкретный prompt, правильна ли метка кнопки или изменилось ли редактирование не той части изображения product.
Для семантических проверок по возможности используйте оценку типа «вопрос-ответ» или оценку в стиле декомпозиции:
- Проверка в стиле TIFA на объект, атрибут, количество и фактическую согласованность.
- Проверка в стиле VQAScore на предмет согласованности изображений с помощью визуальных ответов на вопросы.
- Проверка в стиле GenEval на наличие, количество, цвет и положение объектов.
- Проверка в стиле VISOR на предмет пространственных отношений.
- Проверка в стиле I-HallA на наличие фактических галлюцинаций в содержании изображения.
Эти подходы ценны, потому что они позволяют разделить неудачи. Вместо одной оценки сходства вы получаете ответы типа «объект присутствует, цвет неправильный, пространственное отношение нарушено».
Контрольный список семантики, безопасности и надежности
Используйте эту таблицу в качестве практического значения по умолчанию.
| Проверять | Автоматизированный сигнал | Человеческий review вопрос | Порог по умолчанию |
|---|---|---|---|
| Выравнивание подписей | CLIPScore или судья в стиле VQAScore | Выражает ли изображение основную цель prompt? | Не ниже 97% от базового уровня |
| Наличие ключевого объекта | TIFA или проверки в стиле GenEval | Все ли необходимые объекты присутствуют? | Напомним >= 0,95 |
| Привязка атрибута | Проверки в стиле TIFA, GenEval или T2I-CompBench. | Привязаны ли цвет, материал, количество и текст к нужному объекту? | Точность >= 0,90 |
| Пространственные отношения | VISOR или VQA prompts | Верны ли лево/право, верх/низ, перед/зад и окклюзия? | Точность >= 0,90 |
| Рендеринг текста | OCR плюс точное совпадение или судья review | Требуемый текст точен? | 100% для необходимого текста |
| Изменить местоположение | Парный дифференциал плюс судья-человек | Нетронутые регионы остались неизменными? | Средний >= 4/5 |
| Айдентика и бренд | Проверка сходства плюс локальная обрезка review | Лицо, логотип, шрифт и идентичность product остались неизменными? | Средний >= 4/5 |
Безопасность и предвзятость следует оценивать отдельно от красоты изображения.
| Риск | Как протестировать | Тип результата |
|---|---|---|
| Вредный контент | Запустите prompt и выполните фильтрацию вывода; красная команда высокого риска prompts | Пройден/не пройден |
| Конфиденциальность или почти дублирующийся вывод | Используйте встраивания, перцептивные хеши или поиск ближайшего соседа по внутренним ресурсам. | Пройти/проверить |
| Фактическая галлюцинация | Используйте проверки в стиле VQA для выявления фактических утверждений. | 0-1 или 0-100 |
| Групповая предвзятость | Используйте контрфактические prompts, которые меняют только пол, возраст, этническую принадлежность или род занятий. | Разница в баллах |
| Злоупотребление брендом или личное использование | Применяйте более строгие правила review к реальным людям, товарным знакам, идентификаторам и изображениям медицинского характера. | Пройден/не пройден |
Высококачественное изображение не является автоматически изображением с низким уровнем риска. Практический командный метод — это контрфактическое тестирование: оставьте prompt постоянным и измените только атрибут группы, а затем проверьте, систематически ли меняются род занятий, поза, одежда, возраст или оттенок кожи.
Матрица испытаний на устойчивость
Не проверяйте только одну настройку выхода. GPT Image 2 quality может меняться при изменении разрешения, сжатия, quality или контекста редактирования.
Используйте небольшую матрицу:
| Переменная | Рекомендуемые значения |
|---|---|
| Разрешение | 1024x1024, 1536x1024, 2048x2048, 3840x2160 (где поддерживается) |
| Качество | low, medium, high, где поддерживается |
| Сжатие | PNG, JPEG/WebP 95, 85, 70 |
| Масштабный конвейер | Оригинал, пониженная дискретизация, пониженная дискретизация, затем повышенная дискретизация |
| Окклюзия и обрезка | 10%, 25%, 40% случайная окклюзия; краевые культуры; местные культуры |
| Семена | Не менее 3 кандидатов на prompt |
| Редактировать входные данные | Различные уровни входного изображения quality и области обрезки |
Это не бюрократия. Это не позволяет команде передать model при одном идеальном условии, а затем обнаружить сбой в реальном конвейере активов.
Протокол оценки человека
Человеческий review становится пригодным для принятия решений только тогда, когда протокол стабилен.
Используйте это значение по умолчанию:
- Не менее 100 prompts на scenario.
- Не менее 3 семян на prompt.
- Не менее 3 аннотаторов на изображение.
- Используйте 5 аннотаторов для категорий высокого риска, таких как medical, рабочие процессы, требующие конфиденциальности, юридические, конфиденциальные или критически важные для бренда.
- Отделите сложные вопросы от подсчета очков Likert.
- Используйте слепые тесты A/B при сравнении версий.
- Разрешить tie и неопределенные параметры.
Избегайте ленивых оценочных шкал, таких как «1 = плохо, 5 = хорошо». Определите каждую точку.
Пример шкалы выравнивания:
| Счет | Определение |
|---|---|
| 1 | Полностью не соответствует prompt |
| 2 | Лишь слегка соответствует prompt |
| 3 | Частичное совпадение, с важными упущениями или ошибками. |
| 4 | Почти полностью соответствует, есть небольшие недочеты. |
| 5 | Полностью соответствует prompt |
Пример визуального масштаба quality:
| Счет | Определение |
|---|---|
| 1 | Очевидно сломанный или непригодный для использования |
| 2 | Заметно несовершенен |
| 3 | Приемлемо для чернового использования |
| 4 | Хороший и, вероятно, полезный |
| 5 | Почти профессиональное производство quality |
В руководстве по аннотациям также должно быть определено:
- Какие части prompt являются жесткими ограничениями.
- Является ли отсутствие одного требуемого объекта ошибкой.
- Является ли один неправильный текстовый символ ошибкой.
- Как судить о пространственных отношениях, количестве и цветовой привязке.
- Разрешены ли дополнения creative.
- Что считается незапрошенным редактированием.
- Разница между приблизительной и точной правильностью.
- Когда аннотаторы могут выбрать tie или не уверены.
Без этих правил оценка будет не просто шумной. Это не воспроизводимо.
Размер выборки и статистическая отчетность
Небольшие оценки могут быть полезны для отладки, но они не должны влиять на решения о запуске.
Практические правила:
- Если prompts меньше 100, сравнения model могут легко перевернуться.
- Для двоичного показателя pass с 95% доверительным интервалом около плюс-минус 5% консервативная выборка size составляет около 384 образцов.
- Если ожидаемый уровень pass составляет около 85 %, примерно 196 образцов могут достичь аналогичного диапазона ошибок.
- Для теста предпочтений A/B, где ожидаемое преимущество составляет около 60/40, запланируйте примерно 200 действительных парных сравнений.
- Более сильное предпочтение 65/35 требует меньшего количества выборок, но при этом требует достаточного охвата всех сценариев.
Сообщите больше, чем среднее значение:
| Цель | Первичная метрика | Предлагаемый тест | Отчет |
|---|---|---|---|
| Отпустить ворота | Скорость отправки текстовых сообщений или безопасности pass | Точный биномиальный интервал или критерий двух пропорций | Процент сдачи, 95 % CI, абсолютная разница |
| Предпочтение A/B | Процент побед, игнорируя ничьи | Точный биномиальный тест | Процент побед, 95% CI, значение p |
| Парная оценка Likert | Выравнивание, quality, местоположение | Wilcoxon signed-rank | Медианная разница, значение p, эффект size |
| Независимые группы Likert | Сравнение сценариев или модельных семейств | Mann-Whitney U | Разница распределения, значение p |
| Соглашение аннотатора | Krippendorff's alpha для порядковых меток | Оценка надежности | Альфа-значение |
Используйте альфа = 0,05 в двустороннем формате, если только у вашей команды нет письменной причины поступить иначе. Если вы сообщаете несколько основных показателей, примените коррекцию множественного сравнения. Для согласия аннотаторов Krippendorff's alpha >= 0,80 является надежным целевым показателем; От 0,667 до 0,80 следует рассматривать как ориентировочные.
Автоматизация и воспроизводимость
Система оценки должна иметь версии кода product. Хороший конвейер выглядит так:
- Определите scenario фрагменты и уровни риска.
- Создайте prompts, введите изображения, маски и эталонные образцы.
- Создавайте пакеты по настройкам size, quality, формату, сжатию и seed.
- Запускайте жесткие проверки для текста, наличия объектов, безопасности и редактирования местоположения.
- Запускайте автоматические метрики, такие как LPIPS, SSIM, CLIPScore, проверки в стиле TIFA, проверки в стиле VQAScore, проверки в стиле GenEval и проверки в стиле VISOR.
- Отправьте пограничные и выборочные результаты на рассмотрение человека.
- Запустите статистические тесты и проверки согласия аннотаторов.
- Опубликуйте информационную панель, показывающую сбои по scenario, типу сбоя и конфигурации.
- Сохраняйте случаи сбоев и используйте их для улучшения prompts, масок или правил workflow.
Категории полезных инструментов:
| Категория инструмента | Примеры инструментов | Цель |
|---|---|---|
| Метрики изображения | TorchMetrics, PIQ | FID, IS, LPIPS, CLIPScore, PSNR, SSIM, DISTS, NIQE |
| Семантическая оценка | TIFA, VQAScore, GenEval, наборы тестов в стиле VISOR | Проверки объектов, атрибутов, количества, пространственных данных и достоверности подсказок. |
| Управление версиями | DVC, git, хранилище артефактов | Версия prompts, изображения, ссылки, показатели и выходные данные. |
| CI | GitHub Actions или эквивалент | Запускайте регрессионные тесты и блокируйте выпуски |
| Панель управления | Панель мониторинга BI или внутренний отчет | Показать показатели pass, распределение оценок, затраты, задержку и случаи сбоев. |
На информационной панели не должно отображаться только глобальное среднее значение. Как минимум, разбивайте результаты по:
- Сценарий
- Тип отказа
- Размер
- Настройка качества
- Сжатие
- Подскажите семью
- Уровень риска
- Версия модели
Также отслеживайте показатели операций. Если настройки высокого качества удваивают задержку или стоимость, лишь незначительно улучшая человеческие предпочтения, это решение product, а не просто результат исследования.
Пример схемы оценки
Простая схема CSV или JSON обеспечивает возможность аудита оценки.
| Поле | Тип | Значение |
|---|---|---|
| run_id | string | Идентификатор оценочного запуска |
| prompt_id | string | Уникальный идентификатор prompt |
| scenario | string | product, ux, creative, medical или industrial |
| risk_tier | string | low, medium или high |
| prompt_text | string | Исходный prompt |
| model | string | Название модели |
| model_version | string | Версия модели |
| size | string | Выход size |
| quality | string | Настройка качества |
| output_format | string | png, jpeg или webp |
| output_compression | int | Значение сжатия |
| seed | int | Идентификатор политики-кандидата seed или seed |
| reference_id | string | Ссылка на парные тесты |
| gate_instruction | int | 0 или 1 |
| gate_text_exact | int | 0 или 1 |
| gate_safety | int | 0 или 1 |
| object_presence | float | от 0 до 1 |
| attribute_accuracy | float | от 0 до 1 |
| spatial_accuracy | float | от 0 до 1 |
| locality_score | float | от 0 до 5 |
| visual_quality | float | от 0 до 5 |
| human_pref_win | string | win, loss или tie |
| annotator_id | string | Идентификатор рецензента-человека |
| rationale | string | Краткая причина |
| latency_ms | int | Задержка генерации |
| cost_estimate | float | Ориентировочная стоимость |
| overall_verdict | string | pass, review или fail |
Окончательный контрольный список команды
Прежде чем рассматривать GPT Image 2 как готовый к производству для workflow, убедитесь, что вы выполнили следующее:
- Определили цель выпуска: выбор model, регресс или запуск.
- Определены scenario фрагменты и уровни риска.
- Написанные жесткие ограничения для обязательных объектов, обязательного текста, запрещенного контента и областей, не подлежащих редактированию.
- Создал набор prompt с обычными примерами, сложными примерами и примерами безопасности или предвзятости.
- Сгенерировано не менее 3 кандидатов на каждое приглашение.
- Протестировано как минимум две настройки size и две настройки quality, если они поддерживаются.
- Запустите текстовые, объектные, безопасные и редактируемые шлюзы, прежде чем смотреть на среднее качество.
- Отдельно измеряется семантическое выравнивание, наличие объекта, привязка атрибутов, пространственные отношения и визуальный quality.
- Использовался человеческий review для соответствия creative, соответствия бренду и пограничных случаев.
- Сообщенные доверительные интервалы, размеры эффекта, статистическая значимость и согласие аннотаторов.
- Версия prompts, изображения, настройки, метрики, судья prompts, человеческие кодовые книги и сценарии.
- Создана информационная панель, показывающая, почему не удалось добиться результатов, а не только то, что они не удались.
Краткая версия: оценить GPT Image 2 с помощью вентилей workflow, семантической декомпозиции, человеческого review, статистической дисциплины и версионной регрессии. Не позволяйте идеальному среднему баллу скрыть производственный провал.
