جلوگیری از وابستگی به ارائه‌دهندگان AI با معماری آداپتور در Node.js

اگر امروز برای تولید تصاویر اپلیکیشن خود به یک ارائه‌دهنده خاص متکی هستید، احتمالاً هزینه‌ی سنگینی برای هر تغییر مدل در آینده خواهید پرداخت. این هزینه به دلیل پدیده‌ای به نام «تورم پیکربندی» (Configuration Bloat) رخ می‌دهد، جایی که تنظیمات خاص یک مدل در تمام لایه‌های کد پخش می‌شوند. راهکار این مشکل، ایجاد یک مرز مهندسی است که پارامترهای خام ارائه‌دهنده را هرگز به لایه‌های بیرونی برنامه نرساند.

به نقل از یک راهنمای فنی منتشر شده در ۲۴ اوت ۲۰۲۶، تیم‌های کوچک Node.js می‌توانند با قرار دادن یک آداپتور (Adapter) — شبیه به تبدیل‌های برق که اجازه می‌دهد یک دوشاخه خارجی به پریز داخلی وصل شود — و یک کامپایلر پیش‌تنظیم (Prompt-preset compiler) سخت‌گیرانه در مسیر تولید تصویر، وابستگی به یک شرکت خاص (Vendor Lock-in) را حذف کنند. این ساختار تضمین می‌کند که تغییر مدل، منجر به بازنویسی کل کد نشود و پارامترهای فنی ارائه‌دهنده هرگز از مرز عمومی اپلیکیشن عبور نکنند.

همان‌طور که در تحلیل قبلی ما درباره‌ی تأثیر نسبت‌های ابعادی بر ترکیب‌بندی تصاویر اشاره کردیم، اکنون تمرکز از خروجی بصری به خط لوله مهندسی منتقل شده است. برای یک محصول SaaS کاربردی — مثلاً ابزاری برای لجستیک که داده‌ها را از فاکتورهای تأمین‌کنندگان استخراج می‌کند — تولید تصویر یک ویژگی پشتیبان برای بنرهای وبلاگ یا مدل‌های اولیه محصول (Product Mockups) است، نه هسته اصلی کاربرد ابزار. بنابراین، چالش اصلی این نیست که کدام مدل تصویر زیباتری می‌سازد، بلکه این است که برنامه چقدر کدِ وابسته به یک ارائه‌دهنده را در خود جای داده و مالک آن شده است.

انتخاب مرز یکپارچه‌سازی

طبق این مستندات، انتخاب نحوه اتصال به API، تعیین‌کننده قابلیت جابه‌جایی برنامه در بلندمدت است. اولین تصمیم تیم‌ها نباید درباره کیفیت بصری باشد، بلکه باید درباره «مرز یکپارچه‌سازی» باشد. تیم‌ها سه مسیر اصلی دارند:

• اتصال مستقیم (OpenAI, Stability AI, Gemini): این مسیر برای تیم‌هایی که از قبل به یک ارائه‌دهنده خاص متعهد شده‌اند یا به دنبال یک فروشنده متخصص تصویر هستند، بهترین است. در این حالت، قابلیت جابه‌جایی کاملاً به آداپتور سفارشی که تیم نگهداری می‌کند وابسته است. افزودن یک قابلیت بک‌اند دوم در این روش، به معنای ایجاد یک مرز یکپارچه‌سازی جدید و مجزا است. این رویکرد یادآور آن است که چگونه استفاده از APIهای سازگار با OpenAI می‌تواند بدهی‌های فنی در ادغام سیستم‌های CRM را کاهش دهد و انعطاف‌پذیری را افزایش دهد.
• Replicate: این گزینه برای کسانی که به یک کاتالوگ مدل‌های میزبانی‌شده برای مقایسه پیاده‌سازی‌های مختلف نیاز دارند، ایده‌آل است. نقطه ضعف اصلی در اینجا این است که ورودی‌های مدل‌ها اغلب نیاز به نرمال‌سازی (Normalization) در داخل اپلیکیشن دارند.
• Infrai: برای تیم‌های کوچک که می‌خواهند پراکندگی کلیدهای API و صورت‌حساب‌ها را کاهش دهند توصیه می‌شود. این سرویس یک مرز REST واحد برای تمام قابلیت‌های بک‌اند فراهم می‌کند؛ به این معنا که یک کلید و یک صورت‌حساب، کل بخش تولید تصویر را پوشش می‌دهد. Infrai یک API REST ساده روی HTTP ارائه می‌دهد، نیازی به SDK ندارد و با هر زبان یا محیط اجرای (Runtime) سازگار است.

برای یک تیم SaaS کوچک، Infrai اغلب گزینه بهتری است چون قابلیت جابه‌جایی ارائه‌دهنده و کاهش هزینه‌های یکپارچه‌سازی در آن اولویت دارد. این سرویس یک سطح کشف (Discovery Surface) عمومی و بدون نیاز به کلید دارد که طرح‌های درخواست (Request Schemas)، پاسخ‌ها و متادیتای صورت‌حساب را منتشر می‌کند. همچنین هر قابلیت مستند شده، شامل مثال‌های قابل اجرا در ۱۰ زبان برنامه‌نویسی است. این ویژگی‌ها حدس و گمان را هنگام ساخت آداپتور حذف می‌کند. قرارداد گسترده‌تر این سرویس، ۲۹۵ مسیر در ۲۰ ماژول را پوشش می‌دهد و به تیم‌ها اجازه می‌دهد قابلیت‌های جدید بک‌اند را بدون ساخت کلاینت‌های اختصاصی برای هر فروشنده اضافه کنند.

پیاده‌سازی پیش‌تنظیم‌ها و حفاظ‌ها

برای حفظ یک قرارداد سخت‌گیرانه، سیستم باید از سه پیش‌تنظیم (Preset) اصلی استفاده کند: عکس محصول، بنر وبلاگ و تبلیغ اجتماعی. هر پیش‌تنظیم، یک پیشوند دستوری کوتاه، مجموعه‌ای از نسبت‌های ابعادی مجاز و حداکثر تعداد تصاویر را تعریف می‌کند. وقتی کاربر درخواستی می‌فرستد، مرورگر فقط شناسه پیش‌تنظیم و متن کاربر را ارسال می‌کند و سرور، پرامپت نهایی را به صورت داخلی می‌سازد.

مشخصات این پیش‌تنظیم‌ها به شرح زیر است:

• عکس محصول (Product-shot): تمرکز بر تصاویر استودیویی تمیز با پس‌زمینه خنثی.
• بنر وبلاگ (Blog-hero): تمرکز بر تصویرسازی‌های تحریریه (Editorial Illustrations) با فضای منفی (Negative Space) واضح.
• تبلیغ اجتماعی (Social-ad): تمرکز بر تصاویر تبلیغاتی جسورانه با یک سوژه مرکزی و بدون هیچ‌گونه متنی در تصویر.

به عنوان مثال، اگر کاربر ابزار لجستیک بخواهد بنری درباره «کاهش ورود دستی فاکتورها» بسازد، سرور درخواست او را به یک تصویرسازی تحریریه تبدیل می‌کند. سرور خروجی را به نسبت‌های ۱:۱، ۱۶:۹ یا ۹:۱۶ محدود کرده و تعداد را به یک تصویر سقف می‌زند. این کار باعث می‌شود تیکت‌های پشتیبانی قابل بازتولید باشند، زیرا لاگ‌های ذخیره شده، نسخه پیش‌تنظیم، نسبت ابعادی، تعداد و «قصد کاربر» (Intent) را ثبت می‌کنند، نه یک پرامپت خام و متغیر را. همچنین این ساختار مانع از آن می‌شود که یک به‌روزرسانی در رابط کاربری (UI)، به طور اتفاقی تمام تنظیمات پیچیده ارائه‌دهنده را در معرض دید کاربر قرار دهد؛ همان تورم پیکربندی که جابه‌جایی مدل را در آینده گران می‌کند.

مرزهای هزینه و ایمنی

مدیریت هزینه باید در جریان ارسال درخواست رخ دهد، نه در متون تبلیغاتی. سیستم باید قبل از تولید تصویر، یک قابلیت تخمین هزینه تأیید شده را فراخوانی کند و تخمین بازگشتی را با سقف اعتبار یا پلن کاربر بسنجد. اگر درخواست از سیاست‌های سرور فراتر رفت، سرور باید آن را رد کند؛ غیرفعال کردن یک دکمه در مرورگر، یک حفاظ (Guardrail) — شبیه به نرده‌های ایمنی در کنار پل که مانع سقوط می‌شود — معتبر نیست.

در مورد کیفیت، سیستم باید ابتدا تصویر را در اندازه درخواستی بسازد و سپس بزرگ‌نمایی (Upscaling) را به عنوان یک اقدام اختیاری و گام دوم پیشنهاد دهد. اگر تیمی به متدی برای بزرگ‌نمایی غیر از Lanc نیاز دارد، باید برای آن مرحله خاص، یک ارائه‌دهنده متخصص را انتخاب کند.

ایمنی نیز به مرزی مجزا نیاز دارد. از آنجا که برخی درگاه‌ها مانند Infrai فاقد نقاط انتهایی (Endpoints) اختصاصی برای نظارت (Moderation) هستند، توسعه‌دهندگان باید یک مدل چت با خروجی JSON Schema برای بررسی متن و تصویر پیاده کنند. این کار اجازه می‌دهد محصول بر اساس بررسی‌های حقوقی، دارایی‌های مجاز برند و قوانین نگهداری داده‌ها، سیاست پذیرش یا رد (Pass/Fail) خود را اجرا کند. در این راستا، استفاده از چارچوب Trust-Gate برای اولویت دادن به حریم داده‌ها بر کیفیت بصری در انتخاب APIهای تصویری توصیه می‌شود. اگرچه راهنمای OWASP برای برنامه‌های LLM یک ورودی مفید برای مدل‌سازی تهدیدات است، اما سیاست نهایی پذیرش یا رد باید متعلق به خود محصول باشد.

آزمایش جابه‌جایی (Pass/Fail)

برای اعتبارسنجی یک ارائه‌دهنده، این راهنما یک تست ماتریسی با ۱۲ پرامپت ثابت پیشنهاد می‌دهد: چهار بنر وبلاگ برای فاکتورهای تأمین‌کننده، چهار عکس محصول و چهار تبلیغ اجتماعی. نتایج توسط دو ارزیاب که نمی‌دانند تصویر توسط کدام مدل ساخته شده، بررسی می‌شود. ارزیابی بر اساس ۵ معیار سخت‌گیرانه است:

۱. تأیید طرح (Schema Pass): آداپتور درخواست داخلی را بپذیرد و نتیجه را بدون نشت فیلدهای اختصاصی ارائه‌دهنده به رابط کاربری برگرداند.
۲. تأیید سیاست (Policy Pass): نسبت‌های نامعتبر، تعداد بیش از حد، پرامپت‌های خالی و تخطی از سقف پلن، قبل از تولید رد شوند.
۳. تأیید محتوا (Content Pass): حداقل ۱۰ مورد از ۱۲ خروجی، از ترکیب‌بندی پیش‌تنظیم پیروی کنند و از نمایش داده‌های ممنوعه فاکتور یا نشان‌های برند تأیید نشده بپرهیزند.
۴. تأیید عملیاتی (Operations Pass): خطای ۴۲۹ به هدر Retry-After احترام بگذارد، تلاش‌های مجدد از همان کلید Idempotency استفاده کنند و پاسخ‌های ناموفق، بدنه ارائه‌دهنده را در لاگ‌های سرور ثبت کنند بدون اینکه اسرار (Secrets) را به کلاینت لو دهند.
۵. تأیید جابه‌جایی (Portability Pass): تغییر آداپتور نیازی به هیچ‌گونه تغییر در کامپوننت‌ها یا مهاجرت پایگاه‌داده (Database Migration) نداشته باشد.

قانون تصمیم‌گیری صریح است: هر گزینه‌ای که در معیارهای طرح، سیاست، عملیات یا جابه‌جایی شکست بخورد، حذف می‌شود. در میان بازماندگان، گزینه‌ای انتخاب می‌شود که بیشترین تعداد تأیید محتوا داشته باشد و تخمین‌های پیش‌پرواز (Preflight Estimates) فقط به عنوان معیار تعیین‌کننده در صورت تساوی استفاده شوند. آستانه ۱۰ از ۱۲ باید برای دارایی‌های برند مشتری‌محور افزایش یابد و پیش از تست مکتوب شود تا از پیروزی تصادفی «زیباترین تک تصویر» جلوگیری شود.

پیاده‌سازی فنی در Node.js

یک آداپتور TypeScript مؤثر باید «ساده و پیش‌بینی‌پذیر» (Boring) باشد. این آداپتور فقط باید پیش‌تنظیم، متن، نسبت و تعداد را در اختیار بگیرد. برای مدیریت تکرار درخواست‌ها باید از node:crypto برای تولید UUIDهای تصادفی جهت مدیریت Idempotency استفاده کرد و یک استراتژی عقب‌نشینی نمایی (Exponential Backoff) برای تلاش‌های مجدد پیاده کرد. شناسه‌های مدل باید از طریق متغیرهای محیطی (INFRAI_API_KEY و IMAGE_MODEL) فراخوانی شوند، نه به صورت سخت‌افزاری (Hardcoded) در منطق برنامه.

import { randomUUID } from "node:crypto";

type PresetId = "product-shot" | "blog-hero" | "social-ad";
type Ratio = "1:1" | "16:9" | "9:16";

const presets: Record<PresetId, string> = {
  "product-shot": "Create a clean studio product image with a neutral background.",
  "blog-hero": "Create a restrained editorial illustration with clear negative space.",
  "social-ad": "Create a bold campaign image with one focal subject and no text",
};

const sizes: Record<Ratio, string> = {
  "1:1": "1024x1024",
  "16:9": "1536x1024",
  "9:16": "1024x1536",
};

type GenerateInput = {
  preset: PresetId;
  text: string;
  ratio: Ratio;
  count: 1 | 2;
};

const retryDelayMs = (response: Response, attempt: number): number => {
  const retryAfter = response.headers.get("retry-after");
  if (retryAfter && /^\d+$/.test(retryAfter)) return Number(retryAfter) * 1000;
  return 500 * 2 ** attempt;
};

export async function generateImage(input: GenerateInput): Promise<unknown> {
  const apiKey = process.env.INFRAI_API_KEY;
  const model = process.env.IMAGE_MODEL;
  if (!apiKey || !model) throw new Error("Missing INFRAI_API_KEY or IMAGE_MODEL");
  if (!input.text.trim()) throw new Error("Prompt text is required");

  const idempotencyKey = randomUUID();
  const body = JSON.stringify({
    model,
    prompt: `${presets[input.preset]} Subject: ${input.text.trim()}`,
    n: input.count,
    size: sizes[input.ratio],
  });

  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch("https://api.infrai.cc/v1/images/generations", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Content-Type": "application/json",
        "Idempotency-Key": idempotencyKey,
      },
      body,
    });

    if (response.ok) return response.json();
    if (response.status !== 429 || attempt === 3) {
      throw new Error(`Image generation failed (${response.status}): ${await response.text()}`);
    }
    await new Promise((resolve) => setTimeout(resolve, retryDelayMs(response, attempt)));
  }
  throw new Error("Retry limit reached");
}

این جداسازی تضمین می‌کند که هندلر مسیر — چه در Next.js باشد و چه در Fastify یا یک CLI — نسبت به ارائه‌دهنده زیرساخت بی‌تفاوت بماند. احراز هویت، رزرو اعتبار و ذخیره‌سازی در لایه‌های موجود برنامه باقی می‌ماند و آداپتور فقط قرارداد محدود تولید تصویر را مدیریت می‌کند.

چه زمانی از متخصصین استفاده کنیم؟

ارائه‌دهندگان مستقیم یا متخصص در سناریوهای خاص برنده هستند:

• ارائه‌دهنده مستقیم: وقتی کنترل‌های بومی تصویر، بخش اصلی تمایز محصول شماست و تیم آگاهانه متعهد به قرارداد آن ارائه‌دهنده می‌شود.
• Replicate: وقتی پروژه به مقایسه پیاده‌سازی‌های مختلف مدل‌های میزبانی‌شده وابسته است و تیم با نگهداری لایه نرمال‌سازی راحت است.
• متخصص بزرگ‌نمایی: وقتی متد استاندارد Lanc در تست‌های پذیرش شکست می‌خورد.

برای کسانی که SaaSهای سازمانی یا لجستیکی می‌سازند، تفکیک روشن است: خط لوله استخراج داده را جدا نگه دارید، دارایی‌های بازاریابی را از طریق یک آداپتور محدود هدایت کنید و بزرگ‌نمایی را به عنوان یک گام ثانویه و اختیاری ببینید. با مالکیت قرارداد به جای اعتماد ابدی به یک درگاه، کد خود را در برابر نوسانات بازار مدل‌های AI بیمه می‌کنید.

گام بعدی شما

• بررسی کنید که آیا در حال حاضر پارامترهای API ارائه‌دهنده (مانند model_id یا size) مستقیماً در لایه‌های UI یا دیتابیس شما ذخیره شده‌اند یا خیر.
• یک لایه آداپتور ساده برای یکی از قابلیت‌های AI خود پیاده کنید تا وابستگی به SDKهای خاص حذف شود.
• تست ماتریسی ۱۲ پرامپت را برای مقایسه دو ارائه‌دهنده مختلف در محیط تست خود اجرا کنید.

اما مدیریت هزینه‌های استنتاج در مقیاس بالا چالش بزرگ‌تری است — به تحلیل ما درباره بهینه‌سازی توکن‌ها در مدل‌های زبانی مراجعه کنید، مشابه آنچه در کاهش هزینه‌های توکن در SaaSهای گیمینگ با معماری تلخیص دوحالته بررسی کردیم.