Как генерировать изображения через OpenAI API и проверять результат

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

Секрет храните в переменной окружения. Не помещайте его в браузерный JavaScript, статью, промпт или журнал. В рабочую систему переходите только после теста на копии данных.

Пошаговая настройка

1. Сначала выберите API по процессу: один независимый баннер — Image API; серия правок с сохранением контекста — image generation tool в Responses API.
2. Разделите техническое задание на сюжет, композицию, обязательные объекты, текст, запреты и формат. Не подменяйте размеры словами «для соцсетей».
3. В Image API укажите актуальную модель и только поддерживаемые ею параметры. Ответ декодируйте или скачайте согласно форме, которую возвращает текущий SDK.
4. После сохранения программно откройте файл: проверьте MIME type, ширину, высоту и возможность декодирования. Визуально проверьте текст, логотип, количество предметов и анатомические дефекты.
5. При правке меняйте одну характеристику и явно перечисляйте элементы, которые нельзя менять. Исходник и результат храните с разными именами и хешами.

После каждого вызова сохраняйте request ID, HTTP-статус, модель, версию конфигурации и usage, если сервис его возвращает. Полный чувствительный ввод в обычный лог не копируйте. Повтор запроса после таймаута разрешайте только после проверки состояния предыдущей операции.

Готовый шаблон

Скопируйте основу и замените значения в квадратных скобках:

Задача: квадратная карточка товара.
Объект: одна прозрачная бутылка воды без выдуманного логотипа.
Композиция: объект по центру, свободная зона 20% сверху под заголовок.
Фон: светлый нейтральный, мягкая тень.
Текст внутри изображения: не добавлять.
Запрещено: люди, дополнительные бутылки, водяные знаки, нечитаемые этикетки.
Критерии: один объект; края не обрезаны; фон однородный; место под текст сохранено.

Шаблон намеренно требует явного null или missing вместо догадки. Если результат будет читать программа, формат проверяется схемой, а значения — отдельными бизнес-правилами.

Реалистичный пример

Вход — ТЗ на квадратную карточку одной бутылки. Ожидаемый результат — декодируемый файл нужной геометрии, одна бутылка целиком и пустая верхняя зона. Две бутылки, псевдологотип или встроенная надпись означают отказ, даже если картинка выглядит красиво.

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

Как измерить качество

Создайте таблицу с колонками case_id, expected, actual, source, status, error_type. Идентификаторы, суммы, даты и единицы сравнивайте посимвольно. Для найденного факта храните document_id или точный фрагмент исходника.

Разделяйте ошибки на четыре класса: format_error — результат нельзя разобрать; unsupported_claim — факт отсутствует во входе; wrong_action — вызвана неверная операция; security_error — раскрыт секрет или обойдены права. Каждый класс требует своего исправления. Новый промпт не чинит авторизацию, а JSON Schema не подтверждает истинность суммы.

Правило выпуска задайте до теста: ноль security_error и wrong_action, все ID совпадают, отсутствующие данные не додумываются, а внешний вызов виден в журнале. Если критический кейс провален, измените одну причину и прогоните весь набор заново.

Контроль в рабочем приложении

Разделите сетевой вызов и использование результата. Первый слой принимает вход, присваивает case_id и проверяет размер, тип и права. Второй вызывает API с таймаутом. Третий разбирает ответ и применяет схему. Четвёртый сверяет бизнес-ограничения. Только после этого данные разрешено показывать пользователю или передавать в следующий узел.

Для наблюдаемости считайте количество успешных запросов, отказов валидации, таймаутов и повторов. Не смешивайте их в один процент «успеха». Отдельно отслеживайте долю ответов, отправленных на ручную проверку. Резкий спад технических ошибок при росте unsupported_claim означает, что формат улучшился, но содержание стало хуже.

В журнал результата кладите hash входа, а не чувствительный текст; model id; версию промпта; HTTP-статус; request ID; длительность; тип ошибки и решение валидатора. Значение API-ключа, персональные данные и полный документ туда не попадают. Доступ к журналу должен быть уже, чем доступ к пользовательскому интерфейсу.