خط لوله‌ی AWS Builder Cards عکس‌های خام را به صفحات وب تبدیل می‌کند

تصور کنید یک عکس کج و نامرتب از یک کارت کلکسیونی را با گوشی می‌گیرید و در کمتر از ۱۰ دقیقه، آن را به شکل یک صفحه‌ی وب استاندارد و فرمت‌شده می‌بینید. این اتفاق در سیستم AWS Builder Cards رخ می‌دهد؛ جایی که یک خط لوله‌ی رویدادمحور (Event-driven) بر روی زیرساخت AWS تمام کارهای خسته‌کننده‌ی پردازش تصویر را بر عهده می‌گیرد و انسان را فقط در نقش تاییدکننده‌ی نهایی قرار می‌دهد. این سیستم برای کاتالوگ کارت‌های کلکسیونی طراحی شده است تا اتوماسیون را با نظارت انسانی ترکیب کند.

در این سیستم، از ۱۰ دقیقه‌ی زمان کل، کمتر از یک دقیقه صرف محاسبات ماشین می‌شود و باقی زمان به بررسی انسانی اختصاص دارد. نکته مهم این است که این یک مدل تئوری یا یک دیاگرام ساده نیست، بلکه سیستمی است که در حال حاضر مستقر و فعال است.

بسیاری از سیستم‌های تولید محتوا کاربر را مجبور به ساخت حساب کاربری می‌کنند که همین موضوع باعث دلسرد شدن مشارکت‌کنندگان می‌شود. برای به حداکثر رساندن مشارکت، این معماری اجازه می‌دهد کاربران به‌صورت کاملاً ناشناس عکس‌ها را آپلود کنند. نویسنده تعمداً از سیستم ثبت‌نام اجتناب کرد، زیرا ساده‌ترین راه برای متوقف کردن مردم از مشارکت، مجبور کردن آن‌ها به ثبت‌نام در ابتدای مسیر است. اما باز بودن درها یعنی ورود داده‌های پرت؛ مثلاً عکس گربه، کارت‌های پوکمون یا کارت‌های NHL. بنابراین سیستم باید بتواند پیش از صرف هزینه‌های گران‌قیمت محاسباتی، یک کارت معتبر را از یک عکس تصادفی تشخیص دهد.

به نقل از مستندات فنی این پروژه، این خط لوله بر پایه هماهنگی ۵ تابع لَمبدا (Lambda) و سه مدل هوش مصنوعی مختلف بنا شده است. هدف این است که از یک تصویر کج و بدون برش، به یک فایل مارک‌داون (Markdown) تمیز در یک مخزن گیت‌هاب برسیم، بدون اینکه نیاز باشد یک سرور دائمی نگهداری شود. بار کاری این سیستم عمدتاً در حالت بیکاری است و گاهی هفته‌ها هیچ آپلودی صورت نمی‌گیرد؛ همین موضوع رویکرد بدون سرور (Serverless) را حیاتی می‌کند تا هزینه برای سروری که منتظر عکسی است که شاید هرگز نیاید، پرداخت نشود. این رویکرد یادآور اتوماسیون‌های مشابه در تولید محتواست، مشابه آنچه در بهره‌گیری از Node.js و Python برای نشر کتاب‌های مصور AI مشاهده شد.

اهداف فنی خط لوله

برای موفقیت، ستون فقرات این سیستم باید چندین هدف مشخص را محقق کند:

• شناسایی کارت‌های AWS Builder در میان تصاویر تصادفی.
• صاف کردن تصویر کارت و حذف پس‌زمینه.
• استخراج متادیتای کارت و ذخیره در پایگاه‌داده.
• پیش‌نویس توصیفات کارت برای وب.
• تضمین عدم انتشار هیچ محتوایی بدون تأیید انسانی.
• تضمین انتشار تمام مواردی که تأیید شده‌اند.
• حفظ ساختار کاملاً بدون سرور با هزینه‌ای که تقریباً صفر باشد.

نقطه ورود و دروازه امنیتی

فرآیند زمانی آغاز می‌شود که کاربر از طریق یک API Gateway عمومی، درخواست لینک آپلود می‌دهد. تابع لَمبدایی به نام get-upload-url این درخواست را اعتبارسنجی می‌کند. برای جلوگیری از سوءاستفاده و حملات، API Gateway به ۵ درخواست در ثانیه با قابلیت Burst تا ۱۰ درخواست محدود شده است؛ هر درخواستی بیش از این مقدار، خطای HTTP 429 (Too Many Requests) دریافت می‌کند.

پیش از امضای لینک آپلود، لَمبدا بررسی‌های زیر را انجام می‌دهد:

• نوع محتوا: فایل باید در لیست مجاز (JPEG, PNG, WebP, HEIC/HEIF, BMP, TIFF) باشد. در غیر این صورت، خطای HTTP 400 (Bad Request) بازگردانده می‌شود. لازم به ذکر است که این بررسی روی نوع محتوای اعلام شده (Declared Content Type) است، نه روی بایت‌های واقعی فایل.
• اعتبارسنجی سال: سال واردشده باید عددی ۴ رقمی بین ۲۰۲۰ تا سال جاری میلادی باشد.

سپس کاربر تصویر را مستقیماً به یک باکت Amazon S3 در مسیر images/raw/ با استفاده از یک Pre-signed POST می‌فرستد. این روش تضمین می‌کند که بایت‌های تصویر مستقیماً از گوشی به S3 منتقل شوند. S3 یک محدودیت سخت‌گیرانه ۲۵ مگابایت (۲۶,۲۱۴,۴۰۰ بایت) را اعمال می‌کند و هر فایلی بزرگ‌تر از این مقدار با خطای HTTP 413 (ContentTooLarge) رد می‌شود. این محدودیت خاص به این دلیل کار می‌کند که آپلود از نوع Pre-signed POST با شرط content-length-range است، چیزی که در متد PUT امکان‌پذیر نبود.

به محض رسیدن تصویر به S3 با کلیدی مانند images/raw/<event>_<year>_<uuid>.jpg ، اولین نگهبان هوش مصنوعی یعنی لَمبدای card-detect فعال می‌شود. این تابع یک مدل طبقه‌بندی تصویر زیرو-شات (Zero-shot) را درون یک Container Image اجرا می‌کند. Zero-shot به این معناست که مدل به‌طور خاص برای این هدف آموزش ندیده است؛ بلکه عکس را به یک بردار تبدیل کرده و آن را با لیستی از برچسب‌های انگلیسی دست‌نویس مانند «یک کارت رایانش ابری AWS»، «یک کارت پوکمون» یا «عکس یک شخص» مقایسه می‌کند.

مدل بر اساس امتیاز (Score) تصمیم می‌گیرد:

• امتیاز ۰.۵۰ و بالاتر: کارت معتبر است و برای پردازش ارسال می‌شود.
• امتیاز ۰.۲۰ تا ۰.۵۰: وضعیت نامشخص است اما برای احتیاط جهت پردازش ارسال می‌شود.
• امتیاز کمتر از ۰.۲۰: داده پرت (Junk) است؛ فایل به پوشه images/rejected/ منتقل شده و یک ایمیل SNS برای مدیر ارسال می‌شود که فقط حاوی مسیر فایل رد شده است.

ارسال برای پردازش به این معناست که لَمبدای card-detect به‌صورت Async (ناهمگام) تابع بعدی یعنی image-processor را فراخوانی کرده و دقیقاً همان رویداد S3 را به آن پاس می‌دهد. اشیایی که در پوشه images/rejected/ قرار می‌گیرند به بن‌بست رسیده‌اند و فقط به‌صورت دستی توسط مدیر حذف می‌شوند.

پردازش تصویر و استخراج متن

تصاویر معتبر از طریق فراخوانی ناهمگام به لَمبدای image-processor فرستاده می‌شوند. این یک نمونه arm64 با ۱۰ گیگابایت حافظه است. چون عکس‌های اصلی اغلب کج هستند یا نویز پس‌زمینه دارند، لَمبدا مراحل پاک‌سازی زیر را طی می‌کند:

• قطعه‌بندی تصویر (Image Segmentation): یک مدل پیکسل به پیکسل بررسی می‌کند که آیا یک پیکسل متعلق به «کارت» است یا «پس‌زمینه» و در نهایت یک ماسک تولید می‌کند.
• تشخیص گوشه‌ها: با استفاده از بینایی ماشین کلاسیک از طریق OpenCV، چهار گوشه کارت شناسایی می‌شوند.
• تبدیل پرسپکتیو: با استفاده از هندسه ساده و قطعی (Deterministic Geometry)، سیستم کارت را صاف کرده و به یک مستطیل برش‌خورده و تخت تبدیل می‌کند.
• کاهش ابعاد: برای مدیریت سقف حافظه، هر تصویری که طولانی‌ترین ضلع آن بیش از ۲۰۴۸ پیکسل باشد، در حافظه کوچک می‌شود، هرچند نسخه اصلی در پوشه raw دست‌نخورده باقی می‌ماند.

تصویر نهایی به صورت PNG در مسیر images/finished/<cardId>.png ذخیره شده و یک اعلان SNS برای مدیر ارسال می‌شود: «کارت جدید آپلود شد، آن را بررسی کنید».

بلافاصله پس از صاف شدن تصویر، همان فراخوانی لَمبدا، عکس تمیز شده را به Amazon Bedrock می‌فرستد تا مدل چندوجهی (Multimodal) Nova 2 Lite وارد عمل شود. این مدل متادیتای کارت شامل عنوان، اثر (Effect) و توصیفات را استخراج کرده و در Amazon DynamoDB می‌نویسد. این توانایی تبدیل تصاویر به داده‌های ساختاریافته، مشابه پیشرفت‌هایی است که در مدل Qwen-Image-3.0 برای تحلیل اینفوگرافیک‌های پیچیده دیده شده است. این مدل کاملاً در Bedrock اجرا می‌شود، به این معنی که هیچ کانتینری وجود ندارد، نیازی به مدیریت وزن‌های مدل نیست و نگرانی بابت محدودیت‌های حافظه وجود ندارد.

نظارت انسانی و استقرار

با وجود تمام این اتوماسیون، هوش مصنوعی هرگز اجازه انتشار ندارد. AI پیش‌نویس را آماده می‌کند و پاک‌سازی را انجام می‌دهد، اما هرگز تصمیم نهایی را نمی‌گیرد. تنها مرحله دستی، لَمبدای review-editor است که یک صفحه وب رندر شده در سرور را از طریق API Gateway خودش ارائه می‌دهد. این صفحه با احراز هویت HTTP Basic Auth محافظت می‌شود که اعتبارنامه‌های آن در AWS Secrets Manager ذخیره شده است و دارای محدودیت نرخ (Throttling) و Concurrency رزرو شده است.

در این صفحه، مدیر تصویر پردازش‌شده و متادیتای DynamoDB را در کنار هم می‌بیند. رابط کاربری همچنین شامل یک تب «ردشده‌ها» (Rejected) است که لیست تصاویر موجود در پوشه images/rejected/ در S3 را مستقیماً نمایش می‌دهد. این قابلیت به انسان اجازه می‌دهد کارت‌های معتبری را که مدل card-detect به اشتباه به عنوان Junk علامت‌گذاری کرده بود، «از قرنطینه خارج» کرده و دوباره به خط لوله پردازش بازگرداند.

پس از تأیید، لَمبدای committer به‌صورت همگام (Synchronous) فراخوانی می‌شود. کاتالوگ با استفاده از تولیدکننده سایت استاتیک Hugo ساخته شده که مارک‌داون را به HTML تبدیل می‌کند. لَمبدای committer یک فایل .md با Front-matter تولید کرده و آن را به همراه تصویر نهایی به مخزن گیت‌هاب Push می‌کند. یک نمونه از مارک‌داون تولید شده شامل فیلدهایی برای title ،slug ،weight ،event ،year ،effect ،image ،description ،category ،subcategory و uploader است.

سایت نهایی از طریق AWS Amplify مستقر می‌شود. هنگام وقوع Push، Amplify یک Job ساخت (Build) را آغاز کرده و یک رویداد تغییر وضعیت به EventBridge می‌فرستد. اگر وضعیت Job برابر با SUCCEED یا FAILED باشد، SNS یک ایمیل نهایی ارسال می‌کند. رویداد FAILED مهم‌تر تلقی می‌شود زیرا نشان‌دهنده شکست در خط لوله است.

تحلیل هزینه‌ها و عملکرد

به دلیل ماهیت بدون سرور، هزینه‌ها در زمان بیکاری تقریباً صفر است. وقتی سیستم فعال است، هزینه‌های محاسباتی هر کارت بر اساس حافظه و زمان اجرا به شرح زیر است:

• طبقه‌بندی تصویر (Lambda): حدود ۰.۰۰۰۲۵ دلار (۲ گیگابایت حافظه، ۹.۳ ثانیه اجرا)
• قطعه‌بندی تصویر (Lambda): حدود ۰.۰۰۴۷۴ دلار (۱۰ گیگابایت حافظه، ۳۵.۶ ثانیه اجرا)
• استخراج متن (Bedrock): حدود ۰.۰۰۰۶۵ دلار

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

این رویکرد رویدادمحور جداسازی عالی منابع را فراهم می‌کند. card-detect و image-processor واحدهای مستقلی هستند. این جداسازی یک ضرورت بود زیرا مجموع حافظه مورد نیاز هر دو مدل، از حداکثر حافظه مجاز برای یک تابع لَمبدا در AWS فراتر می‌رفت.

با این حال، این ساختار باعث فقدان ایزولاسیون در برابر شکست (Failure Isolation) می‌شود. اگر لَمبدای card-detect از کار بیفتد، کل خط لوله متوقف می‌شود زیرا هیچ تصویری به پردازشگر ارسال نمی‌شود. برای تبدیل این سیستم به یک محصول در سطح تجاری، نویسنده پیشنهاد می‌کند:

• پیاده‌سازی یک صف (مانند SQS) بین مراحل تشخیص و پردازش.
• افزودن صف‌های پیام‌های مرده (Dead Letter Queues - DLQ) برای رویدادهای شکست‌خورده.
• استفاده از AWS Step Functions برای ارکستراسیون کل جریان کاری.

این خط لوله نشان می‌دهد که چگونه ترکیب مدل‌های کوچک و تخصصی با یک دروازه سخت‌گیرانه تأیید انسانی می‌تواند یک سیستم خودکار با اعتماد بالا ایجاد کند. با سپردن «کارهای سخت» مانند برش زدن و تایپ کردن به هوش مصنوعی، مدیر انسانی فقط زمان خود را صرف بررسی نهایی کیفیت می‌کند. این «شکل» از خط لوله — یعنی درِ ورودی ناشناس، فیلتر AI، پردازشگر AI و دروازه انسانی — می‌تواند برای هر پروژه‌ای که با تصاویر حاوی متن (مانند نشان‌ها یا برچسب‌ها) سروکار دارد، به کار گرفته شود.

گام بعدی شما

• اگر پروژه‌ای دارید که ورودی‌های تصویری نامنظم دریافت می‌کند، از الگوی «دروازه AI $\rightarrow$ پردازش $\rightarrow$ تأیید انسانی» استفاده کنید.
• برای کاهش هزینه‌ها، مدل‌های سنگین را در توابع لَمبدای مجزا با حافظه اختصاصی قرار دهید.
• برای مدیریت خطاهای زنجیره‌ای در سیستم‌های Serverless، پیاده‌سازی Dead Letter Queues (DLQ) را بررسی کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.