تصور کنید یک مربی مالی هوشمند داشته باشید که می‌تواند ۱۰۰۰ تراکنش بانکی شما با هزینه‌ای کمتر از ۲ سنت تحلیل کند. این بهره‌وری خیره‌کننده، دستاورد اصلی BudgetBot است؛ سامانه‌ای که در جریان رقابت XBrain AWS Accelerator برای حذف دشواری‌های ثبت دستی هزینه‌ها ساخته شد.
مدیریت امور مالی شخصی معمولاً با این سؤال شروع می‌شود: «پول‌هایم چطور به این سرعت تمام شد؟». در حال حاضر، کاربران یا باید در اپلیکیشن‌های بانکی میان تراکنش‌های نامفهوم و مخفف جست‌وجو کنند یا هر خرید کوچک را به‌صورت دستی ثبت کنند. واقعیت این است که اکثر مردم پس از سه روز این روند خسته‌کننده را رها می‌کنند.
BudgetBot این مشکل را با پذیرش فایل‌های CSV، اکسل، PDF و حتی عکس‌های پرداخت از بانک‌های مختلف حل می‌کند. این سیستم به‌طور خودکار تراکنش‌ها را طبقه‌بندی کرده، بودجه را محاسبه می‌کند و در قالب یک چت، توصیه‌های spending را ارائه می‌دهد. این رویکرد خودکارسازی تراکنش‌ها یادآور تجربه‌ی شرکت Xero است که با استفاده از سیستم‌های عامل‌محور توانست ۷۰٪ از ایمیل‌های ورودی خود را خودکار کند و بهره‌وری عملیاتی را افزایش دهد. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی بهینه‌سازی هزینه‌های ابری اشاره کردیم، انتقال از پروتکل‌های ساده به معماری‌های مقیاس‌پذیر، کلید بقای این ابزارها در دنیای واقعی است.
برای رسیدن به این سطح از کارایی، تیم توسعه از Amazon ECS Fargate به‌جای AWS Lambda استفاده کرد. به نقل از مستندات فنی پروژه، سه دلیل کلیدی برای این انتخاب وجود داشت:
- عبور از محدودیت‌های زمانی: پردازش‌های سنگین مانند نویسه‌خوانی نوری (OCR) — همان تبدیل عکس‌های رسید به متن قابل فهم — با استفاده از Amazon Textract یا طبقه‌بندی دسته‌ای در Bedrock، زمان زیادی می‌برد و محدودیت ۱۵ دقیقه‌ای Lambda باعث قطع شدن عملیات می‌شد.
- پیش‌بینی‌پذیری هزینه‌ها: برخلاف Lambda که هزینه‌ها را بر اساس تعداد درخواست و میلی‌ثانیه محاسبه می‌کند، Fargate اجازه مدیریت ظرفیت حداکثری و حداقلی را می‌دهد تا هزینه‌های پردازش‌های طولانی کنترل شود. این مدل مدیریت هزینه، شباهت زیادی به تغییر رویکرد مایکروسافت به سمت پرداخت بر اساس مصرف در Copilot دارد تا هزینه‌ها با میزان استفاده واقعی کاربر همسو شود.
- مدیریت اتصالات پایگاه‌داده: مقیاس‌دهی تهاجمی Lambda می‌تواند هزاران اتصال هم‌زمان به RDS PostgreSQL باز کند و باعث سقوط دیتابیس شود؛ اما کانتینرهای Fargate اجازه استفاده از Connection Pooling را می‌دهند تا اتصالات به‌جای ایجاد هرباره، بازاستفاده شوند.
در لایه شبکه، تیم توسعه برای حذف هزینه ثابت ۳۲ دلاری در ماه برای NAT Gateway، کانتینرهای Fargate را روی زیرشبکه‌های عمومی با IPهای عمومی استقرار داد. برای جبران این ریسک امنیتی، یک دفاع سه‌لایه پیاده شد:
اول، ایزوله‌سازی دیتابیس؛ به‌طوری‌که RDS و کش Valkey فقط ترافیک来自 کانتینرهای Fargate را می‌پذیرند. دوم، لایه حفاظتی لبه با استفاده از AWS WAFv2 و Application Load Balancer برای فیلتر کردن ترافیک مخرب و جلوگیری از حملات DDoS. سوم، استفاده از PrivateLink برای اتصال به سرویس‌های حساس مانند S3 و Bedrock؛ به این ترتیب تمام داده‌های حساس در بستر داخلی AWS باقی می‌مانند و هرگز وارد اینترنت عمومی نمی‌شوند.
مسیر یک تراکنش در این سیستم به‌صورت نامتقارن (Async) طراحی شده است. ابتدا فایل در S3 آپلود شده و سپس یک پیام به Amazon SQS ارسال می‌شود. یک Worker در Fargate این پیام را برمی‌دارد و پردازش می‌کند. اگر فایلی سه بار با خطا مواجه شود، به صف Dead Letter Queue (DLQ) منتقل می‌شود تا کاربر یا مدیر سیستم آن را بررسی کند.
برای جلوگیری از تکرار داده‌ها، چهار لایه فیلتر تعریف شده است: اثر انگشت SHA-256 برای کل فایل، امضای [مبلغ + شرح] برای هر تراکنش، هشدارهای نرم برای ورودی‌های دستی و تطبیق اثر انگشت PDFها.
در بخش استنتاج (Inference) — یعنی همان لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه آشپزی کردن پس از یادگیری دستور پخت — BudgetBot از یک خط لوله طبقه‌بندی لایه‌ای استفاده می‌کند. طبق گزارش تیم توسعه، حدود ۶۵٪ از تراکنش‌های عادی توسط یک دیکشنری قاعده‌محور (Regex) با هزینه صفر طبقه‌بندی می‌شوند (مثلاً کلمه «Grab» مستقیماً به «حمل‌ونقل» متصل می‌شود).
برای ۳۵٪ باقی‌مانده که مبهم هستند، سیستم از Amazon Bedrock با مدل Claude Haiku استفاده می‌کند. تراکنش‌ها در دسته‌های ۱۰ تایی گروه‌بندی می‌شوند و با جدا کردن پرامپت سیستمی از نمونه‌ها، قابلیت حافظه موقت پرامپت (Prompt Caching) فعال شده که هزینه توکن‌های ورودی را تا ۹۰٪ کاهش داده است. این ساختار انعطاف‌پذیر، نمونه‌ای از معماری‌های ماژولار هوش مصنوعی است که جایگزین بازسازی کامل سیستم‌ها در کسب‌وکارهای کوچک شده‌اند تا توسعه سریع‌تر و ارزان‌تر شود.
امنیت داده‌های شخصی (PII) نیز با سیاست‌های حفاظتی Bedrock تضمین شده تا داده‌های ورودی برای آموزش مدل‌های شرکت‌های ثالث استفاده نشوند. همچنین تمام داده‌ها در حالت استراحت با کلیدهای مدیریت‌شده KMS رمزنگاری شده‌اند.
بر اساس اسکریپت تخمین هزینه پروژه برای ۱۰۰۰ تراکنش در ماه، مجموع هزینه‌ها حدود ۳۰ دلار است:
- Amazon Bedrock: حدود ۰.۰۱۶۶ دلار (به دلیل بهینه‌سازی ۹۰ درصدی)
- Amazon RDS: حدود ۱۳ دلار (نسخه db.t3.micro)
- Amazon ECS Fargate: حدود ۱۶ دلار (برای دو تسک جهت پایداری بالا)
- Amazon S3: حدود ۰.۵۰ دلار (ذخیره‌سازی موقت)
- سایر سرویس‌ها (SQS, WAF): تقریباً صفر (در محدوده لایه رایگان)
گام بعدی شما
- اگر اپلیکیشن AI می‌سازید، به‌جای تکیه مطلق بر LLM، ابتدا یک لایه Regex یا قاعده‌محور برای داده‌های تکراری پیاده کنید تا هزینه‌ها را تا ۶۰٪ کاهش دهید.
- برای کاهش هزینه توکن‌ها در مدل‌های Claude، ساختار پرامپت خود را به‌گونه‌ای تغییر دهید که بخش‌های ثابت در حافظه موقت (Cache) باقی بمانند.
- در پروژه‌های MVP، از combination زیرشبکه‌های عمومی و VPC Endpoints برای حذف هزینه NAT Gateway استفاده کنید.
اما داستان بهینه‌سازی سخت‌افزاری برای این مدل‌ها حتی پیچیده‌تر است — به تحلیل ما درباره‌ی لایه‌های کشing در استنتاج مدل‌های زبانی مراجعه کنید.
گفتگو