Как оценить AI-генератор изображений: практический чеклист

Одна эффектная генерация не отвечает на вопрос, подходит ли инструмент для product illustration, рекламной серии, e-commerce mockup, локализованного баннера или контролируемого редактирования. До теста зафиксируйте пользователя, канал, формат, число вариантов, разрешённые reference assets, требования к тексту, срок жизни материала и дефект, который блокирует публикацию. Отдельно тестируйте consumer chat, design application и API: модели, лимиты, controls и условия могут различаться.

Определите decision contract: какой результат принимает art director, кто проверяет права и факты, где хранится approved asset и кто имеет право публиковать. Генератор создаёт candidate, но не получает publish authority. Медицинские, политические, финансовые и идентификационные изображения требуют отдельного risk review; правдоподобный вид не доказывает реальность события или человека.

• Use case → канал, аудитория, формат и срок жизни.
• Acceptance → композиция, точный текст, invariants и запрещённые дефекты.
• Authority → generate, review, approve и publish принадлежат разным ролям.
• Stop rule → нарушение прав, safety или существенная вводящая в заблуждение репрезентация.

Для каждого run сохраните provider, product surface, model или mode, plan, класс аккаунта, регион, дату, aspect ratio, resolution, seed если доступен, prompt, negative constraints, reference files и generation settings. OpenAI и Google документируют генерацию и редактирование в своих поверхностях, но documented capability не гарантирует одинаковую доступность для каждого аккаунта. Изменился manifest — это новый test slice, а не продолжение старого benchmark.

Соберите 18–30 fixtures из реальных задач без confidential assets: простая предметная сцена, несколько объектов с пространственными отношениями, руки и мелкие детали, короткая точная надпись, необычное соотношение сторон, редакционная иллюстрация, локализация, style reference, замена фона и серия с повторяющимся героем. Добавьте невозможные или противоречивые constraints: корректный отказ или уточнение полезнее, чем скрытое игнорирование.

До генерации разбейте prompt на checklist: subject, count, attributes, spatial relations, action, camera, lighting, palette, text, exclusions и output format. Blind reviewer отмечает каждое требование как satisfied, partial, contradicted или not judgeable. Не просите только оценку качества: она смешивает вкус с выполнением контракта и может скрыть критический дефект вроде неправильного продукта или лишнего логотипа.

Отдельно проверяйте factual boundary. Изображение исторического события, товара, интерфейса или научной схемы может выглядеть убедительно и выдумывать детали. Для factual visual нужны authoritative references и человеческая сверка подписей, пропорций и claims. Отмечайте synthetic или illustrative nature там, где аудитория может принять изображение за документальное доказательство.

Для edit fixture задайте requested delta — например, изменить только цвет чашки — и protected regions: лицо, руки, надпись, логотип, фон, crop и количество предметов. После каждого шага проверяйте оба списка. Правильно изменённый цвет не компенсирует новое лицо или искажённый бренд. Сохраняйте base asset hash, edit instruction, output и verdict, чтобы цепочку можно было воспроизвести.

Проведите минимум три последовательных edits и один rollback к approved base. Измеряйте drift после каждого шага, а не только финальную красоту. Если продукт не умеет точно восстанавливать версию, версионируйте файлы вне chat history. Для compositing проверяйте тени, перспективу, края mask и взаимодействие объектов; reference person или protected brand используйте только при подтверждённых правах.

Точный текст проверяйте посимвольно: регистр, пунктуация, цифры, валюта, язык и переносы. Короткий headline и длинный текст упаковки — разные slices. Если текст юридически или коммерчески значим, безопаснее генерировать visual без copy, а typography добавлять детерминированным design tool. Не скрывайте исправление: сохраняйте границу между model output и human layout.

Для серии зафиксируйте character sheet, palette, wardrobe, product geometry, viewpoint rules и запрещённые отклонения. Создайте пять сцен в разном порядке и повторите одну на следующий день в новой session. Reviewer сравнивает identity, пропорции, branding и style drift. Одна удачная сцена не доказывает production consistency; ideation можно оставить генератору, а серийную сборку — контролируемому pipeline.

Перед upload reference проверьте owner, license, consent, разрешённые transforms, territory, expiry и допустимость передачи asset выбранному сервису. Не используйте клиентские фото, unreleased products или персональные данные в consumer account без утверждённого data contract. Проверяйте retention, training controls, sharing, deletion и admin settings именно для выбранного plan; название vendor не заменяет account-level проверку.

Храните provenance packet: source assets и права, prompt, manifest, edits, reviewer, approved output, disclosure decision и доступные Content Credentials или аналогичные signals. Такие сигналы помогают проследить происхождение, но их отсутствие не доказывает человеческое создание, а наличие — правдивость сюжета. Safety test должен покрывать impersonation, public figure, child safety, hate, self-harm, deceptive document и попытки обхода policy без публикации вредных outputs.

Считайте subscription или API usage, число generations, upscale, storage, reviewer minutes, ручной retouch, typography, rights review, rejected variants и повторную работу после изменения модели. Полезный знаменатель — cost per approved asset для конкретного slice, а не цена одной генерации. Не превращайте vendor speed claim или случайный stopwatch run в общий рейтинг без одинакового manifest и достаточного числа повторов.

Операционно проверьте queue, rate limits, timeout, moderation response, export format, alpha channel, color handling, metadata preservation и recovery после interrupted edit. API workflow дополнительно требует idempotent job ID, bounded retries и postcondition check, чтобы timeout не создавал дубликаты. Raw model output не должен автоматически попадать в CMS, ad account или публичную asset library.

Сформируйте отдельные verdicts для ideation, single hero image, localized text, controlled edit, character series и API batch. Approve называет точный manifest и scope; restrict запрещает sensitive references, text-in-image или direct publish; reject возвращает задачу в known-good design workflow; re-evaluate ждёт изменения capability. Средний бал не должен компенсировать нарушение прав или deception failure.

Decision record содержит allowed users, data classes, approved routes, human checkpoints, evidence location, owner, review date и rollback. Существенное изменение model, product surface, terms, provenance behavior, safety policy или failure pattern повторно запускает frozen corpus. Rollback останавливает jobs, отзывает sharing, убирает спорные assets из publication queue и возвращает последнюю approved версию; уже опубликованные материалы проходят impact review.

• Approve → определённый slice, manifest и review route.
• Restrict → меньше данных, функций или publication authority.
• Reject → known-good human или design workflow.
• Re-evaluate → повторить corpus после material change.