آمازون با جایگزینی Sonnet 4.6 با Strands Decider، میلیون‌ها دلار صرفه‌جویی می‌کند

برای مدتی، تیم‌های آمازون و AWS به Claude Sonnet 4.6 برای برچسب‌گذاری بلیت‌ها در یک سیستم داخلی بدون شکستن بانک متکی بودند.

غزل 4.6 متناسب با انتخاب طلایی متعادل کردن هوش با هزینه است. با توجه به اینکه با یکی از بزرگترین سیستم های فروش بلیط داخلی دنیا سروکار داشت، مدل نه ماهه به خوبی عمل کرد. با این حال، دو مهندس آمازون اخیرا Sonnet 4.6 را با Strands Decider جایگزین کردند، مدل تصمیم گیری که ما یک ماه پیش راه اندازی کردیم، که با 98 درصد هزینه کمتر به همان خوبی عمل کرد. این تغییر باعث صرفه جویی میلیون ها دلار در هزینه های توکن در یک سال می شود.

کار و مهول، که روی سیستم فروش بلیط داخلی کار می‌کنند، در زیر به چگونگی این اتفاق می‌پردازند.

ما بلیت‌های برچسب‌گذاری Sonnet 4.6 را در مقیاس عظیم داشتیم. این بلیط ها می تواند افزایش مشتری، درخواست ظرفیت، هشدار خودکار، یافته های امنیتی، یا هر چیز دیگری در سراسر شرکت باشد که باید در 20 نوع دسته قرار گیرد. عامل با یک سیستم طولانی در هر بلیط اجرا شد، JSON تولید کرد و در برابر مجموعه ای ثابت از برچسب ها استدلال کرد.

یک مدل تصمیم نمی تواند متن تولید کند. ابتدا یک حالت و یک سوال با مجموعه ای از گزینه ها به آن داده می شود، سپس مدل تصمیم گیری یک احتمال برای هر گزینه به اضافه یک امتیاز اطمینان را برمی گرداند. دیدیم که این روش کاملا با برچسب‌گذاری بلیط مطابقت دارد: دولت بلیط است، گزینه‌ها کاتالوگ برچسب هستند.

ما با Strands Decider 2B اصلی شروع کردیم. در یک مجموعه آزمایشی از بلیط ها، ساخت E4B Gemma 4 به وضوح نتایج بهتری گرفت، بنابراین ما به آن تغییر کردیم. پس از آن، ما قبل از اعمال یک برچسب، مدل را تنظیم کردیم که چقدر باید مطمئن باشد. نتایج نشان داد که E4B در مجموعه جداگانه‌ای از بلیط‌های ما، غزل تولیدی را شکست می‌دهد.

ما E4B را در نمونه‌های SageMaker ml.g5.xlarge اجرا کردیم (یک A10G، هر کدام 24 گیگابایت). این مدل از حدود 19 گیگابایت استفاده می کرد و یک درخواست در یک نمونه حدود 640 میلی ثانیه طول کشید. نقطه پایانی با ترافیک خودکار مقیاس می شود، اما شبکه آن ایزوله بود و از دسترسی خروجی به کانتینر جلوگیری می کرد. SageMaker وزن های مدل را قبل از راه اندازی از S3 کپی می کند.

مشتریان نیز می توانند این کار را انجام دهند! به غیر از APIهای فروش بلیط ما، همه چیز در مسیر یک سرویس استاندارد AWS است. رویدادهای بلیط در یک صف SQS قرار می گیرند که سپس یک تابع Lambda را راه اندازی می کند. داده‌های بلیط را می‌خواند و مدل را یک نقطه پایانی هوش مصنوعی SageMaker با Strands Decider می‌نامد. AppConfig سوئیچ را نگه می دارد (در زیر توضیح داده شده است) و CloudWatch گزارش ها، معیارها و آلارم ها را حمل می کند. پشته در CDK با مراحل استقرار برای بتا، گاما و پرود تعریف شده است.

ما نمی خواستیم سوئیچ را باز کنیم و امیدوار باشیم. برچسب Lambda یک تنظیم سه طرفه از AWS AppConfig را در هر پیام می خواند:

افت توکن دو منبع داشت. Strands Decider به جای پاسخ JSON یک خروجی تولید کرد، انتخاب. درخواست آن نیز بسیار کوتاهتر از Sonnet 4.6 بود. توضیحات برچسب تولید به تنهایی طولانی تر از پنجره 4096 توکنی Strands Decider است، بنابراین هر یک از 20 برچسب را به عنوان یک معیار یک یا دو جمله ای بازنویسی کردیم و آنها را به عنوان گزینه های یک سوال تک گزینه ای به اضافه گزینه "هیچ" ارسال کردیم. داده‌های بلیط همان چیزی است که Sonnet دریافت می‌کند، با این تفاوت که در بلیط‌های طولانی Strands Decider قدیمی‌ترین نظرات را برای جا انداختن حذف می‌کند.

در زیر نموداری از مدت زمان Lambda ما در روزی که استفاده از Sonnet را خاموش کردیم، نشان می‌دهد که میانگین مدت اجرای لامبدا 74% کاهش یافته است.

این لیست قیمت های منتشر شده است. آنها لامبدا را کنار می گذارند، که هم اکنون برای هر بلیط زمان کمتری اجرا می شود.

چیزی که ما را شگفت زده کرد این بود که ترتیب کلید JSON پاسخ را تغییر داد. ارسال همان محتوا با کلیدها با ترتیبی متفاوت، احتمال خروجی را تا 0.19 افزایش داد. ما اکنون هر درخواستی را با کلیدهای مرتب شده ارسال می کنیم، بنابراین اگر یک مدل تصمیم را در پشت یک API ارائه می کنید، قبل از مقایسه اجراها این را بررسی کنید.

این کار به این دلیل کار کرد که این کار یک انتخاب بسته از یک کاتالوگ شناخته شده است، حجم بالا است و تأخیر مسیر قدیمی مهم است. اگر برچسب‌های شما نیاز به متن توضیحی دارند، اگر کاتالوگ هر هفته تغییر می‌کند، یا اگر نمی‌توانید زمینه مفید را در چند هزار توکن قرار دهید، احتمالا یک مدل تصمیم نمی‌تواند جایگزین کار LLM شود.

بخشی که ما بدون توجه به مدل کپی می کنیم سوئیچ سه طرفه است. اجرای هر دو در ترافیک واقعی، سپس قضاوت در مورد هر اختلاف نظر، بیش از هر ارزیابی آفلاینی به ما گفت. همچنین به این معنی بود که بازگشت به عقب یک تغییر پیکربندی 45 ثانیه ای بود.

دنیای نمایندگان با مدل های تصمیم گیری بسیار هیجان انگیزتر (و کم هزینه تر) می شود. اگر در حال اجرای یک عامل طبقه بندی هستید، مخزن Strands Decider و یادداشت های ارائه آن را امتحان کنید.