Як оцінити 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 → rights, safety або consequential misrepresentation failure.

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

Побудуйте 18–30 fixtures із реальних задач без confidential assets: проста предметна сцена, кілька об'єктів із відносним положенням, руки й дрібні деталі, короткий точний напис, нетипове співвідношення сторін, редакційна ілюстрація, локалізація, style reference, background replacement і серія з повторюваним героєм. Додайте prompt із неможливими або суперечливими 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 і кількість предметів. Після кожного кроку reviewer перевіряє обидва списки. Успішно змінений колір не компенсує нове обличчя або спотворений бренд. Збережіть base asset hash, edit instruction, output і verdict, щоб ланцюг можна було відтворити.

Проведіть щонайменше три послідовні edits і один rollback до approved base. Виміряйте drift після кожного кроку, а не тільки фінальну красу. Якщо продукт не підтримує точне повернення, версіонуйте файли поза chat history. Для compositing перевірте тіні, перспективу, краї mask і взаємодію об'єктів; для reference person або protected brand використовуйте лише матеріали з підтвердженим правом.

Точний напис перевіряйте посимвольно: регістр, пунктуація, цифри, валюта, мова й переноси. Короткий headline і довга упаковка є різними slices. Якщо текст є юридично або комерційно значущим, безпечніший workflow може генерувати фон без напису, а typography додавати детермінованим design tool. Не виправляйте помилку непомітно: збережіть, де закінчився model output і почався human layout.

Для серії заморозьте character sheet, palette, wardrobe, product geometry, viewpoint rules і заборонені відхилення. Створіть п'ять сцен у різному порядку та повторіть одну через день у новій session. Reviewer порівнює identity, пропорції, branding і style drift. Одна вдала сцена не доводить production consistency; прийнятним результатом може бути routing: 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. Такі 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.

Сформуйте verdict окремо для ideation, single hero image, localized text, controlled edit, character series і API batch. `Approve` називає точний manifest та scope; `restrict` забороняє sensitive references, text-in-image або direct publish; `reject` повертає задачу до design team чи попереднього tool; `re-evaluate` чекає на зміну capability. Один середній бал не повинен компенсувати rights або deception failure.

Decision record містить allowed users, data classes, approved routes, human checkpoints, evidence location, owner, review date й rollback. Material change у model, product surface, terms, provenance behavior, safety policy або failure pattern запускає frozen corpus знову. Rollback зупиняє jobs, відкликає sharing, прибирає disputed 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.