AI OPS зсередини: як за 20 секунд замінити фон і не зламати товар

Чому це складніше, ніж «просто замінити фон»

На перший погляд задача звучить просто: беремо фото товару, прибираємо фон, генеруємо новий. На практиці звичайні генератори ламають логотипи, шви, текстури та дрібний текст. Для інтернет-магазину це не «негарна картинка», а повернення, втрачений клієнт і гроші.

AI OPS — це не генератор зображень. Це пайплайн, у якому продукт залишається недоторканим, а змінюється лише оточення. Нижче — як він влаштований і які рішення виявилися важливими.

Що робить сервіс

Користувач завантажує фото товару, обирає або описує сцену та отримує готовий фон. Демо безкоштовне, з лімітами, працює трьома мовами. Генерація займає близько 20 секунд, а вартість однієї генерації — приблизно $0.02.

Під капотом — Next.js 16, Supabase, fal.ai і Telegram для сповіщень про ліди.

Архітектура

Browser → Next.js API → Supabase → fal.ai → Telegram

• Браузер надсилає фото та опис сцени.
• Next.js зберігає заявку та запуск пайплайна в Supabase.
• fal.ai генерує новий фон.
• Результат зберігається в pipeline_runs.result_url.
• Telegram отримує сповіщення про нового ліда.

Ключова ідея: API не чекає на генерацію. Він відповідає одразу, а робота продовжується у фоні.

Рішення 1. Черга без окремої інфраструктури

Для MVP не хотілося піднімати Redis, воркери та окремий сервіс черг. У Next.js є after() — функція, яка виконується після надсилання відповіді:

after(async () => {
  await processPipelineRun(runId);
});

Користувач одразу отримує runId, а пайплайн продовжує працювати. Якщо генерація впала, статус у базі стає error, і ліміт не витрачається.

Рішення 2. Polling, який переживає перезавантаження

Клієнт опитує /api/relight/[id] кожні дві секунди. runId зберігається в localStorage, тому навіть після перезавантаження сторінки можна продовжити чекати результат.

При мережевій помилці клієнт не показує «все зламалося», а перепідключається. Дрібниця, яка сильно впливає на відчуття надійності.

Рішення 3. Ліміти, які не скидаються помилкою

У демо діють ліміти: дві генерації на email і три на IP. Важливо, щоб невдала генерація не з'їдала спробу. Інакше користувач ловить випадкову помилку і більше не може спробувати.

Ліміти рахуються атомарно, через keyed-м'ютекс. Це захищає від гонок, коли кілька запитів приходять одночасно.

Рішення 4. Три мови та продакшен

Інтерфейс і юридичні сторінки перекладені на en, ru та uk. Мова визначається за браузером, ручний вибір зберігається.

Прод живе на цьому ж сервері: Caddy приймає HTTPS, systemd тримає Next.js, health-check перевіряє застосунок, а деплой іде через атомарну заміну .next з відкатом при помилці.

Що б я покращив далі

• Винести пайплайн в окремий воркер, якщо навантаження зросте.
• Додати чергу з ретраями та дедлайнами.
• Показувати прогрес генерації, а не лише spinner.
• Додати порівняння «до/після» прямо в результаті.

Підсумок

AI OPS — приклад того, як AI-продукт тримається не на одній моделі, а на інженерії навколо неї: лімітах, відновленні після збоїв, зберіганні результату, локалізації та деплої. Модель можна замінити. Надійний пайплайн — складніше.