رویکردهای آزمایشی برای مدل‌های Amazon SageMaker ML

این پست با توبیاس ونزل، مدیر مهندسی نرم افزار پلتفرم یادگیری ماشین Intuit نوشته شده است.

همه ما اهمیت یک مدل یادگیری ماشینی (ML) با کیفیت بالا و قابل اعتماد را هنگام استفاده از رانندگی مستقل یا تعامل با الکسا، برای مثال، درک می کنیم. مدل‌های ML همچنین نقش مهمی را به روش‌های نه چندان واضح ایفا می‌کنند - آنها توسط برنامه‌های کاربردی تجاری، مراقبت‌های بهداشتی، مؤسسات مالی، amazon.com، TurboTax و موارد دیگر استفاده می‌شوند.

از آنجایی که برنامه های کاربردی دارای ML به هسته اصلی بسیاری از مشاغل تبدیل می شوند، مدل ها باید همان قوت و نظم را مانند برنامه های نرم افزاری دنبال کنند. یکی از جنبه‌های مهم MLOps، ارائه نسخه جدیدی از مدل ML قبلی توسعه‌یافته با استفاده از شیوه‌های توسعه‌یافته DevOps مانند آزمایش، نسخه‌سازی، تحویل مداوم و نظارت است.

چندین وجود دارد دستورالعمل دستورالعمل هایی در مورد MLO ها، و این پست یک نمای کلی از فرآیندی که می توانید دنبال کنید و ابزارهایی که برای آزمایش استفاده کنید ارائه می دهد. این بر اساس همکاری بین تعلیم دادن و AWS. ما با هم کار کرده‌ایم تا توصیه‌های توضیح داده شده در این پست را در عمل و در مقیاس اجرا کنیم. هدف Intuit از تبدیل شدن به یک پلتفرم متخصص مبتنی بر هوش مصنوعی به شدت به استراتژی افزایش سرعت توسعه مدل اولیه و همچنین آزمایش نسخه های جدید وابسته است.

مورد نیاز

موارد زیر زمینه های اصلی مورد توجه در هنگام استقرار نسخه های مدل جدید است:

1. عملکرد دقت مدل - مهم است که پیگیری کنید معیارهای ارزیابی مدل مانند دقت، دقت، و یادآوری، و اطمینان از اینکه معیارهای هدف نسبتاً یکسان باقی می مانند یا با نسخه جدید مدل بهبود می یابند. در بیشتر موارد، اگر تجربه کاربران نهایی بهبود نیابد، استقرار نسخه جدیدی از مدل منطقی نیست.
2. تست کیفیت داده ها – داده‌ها در محیط‌های غیرتولیدی، چه شبیه‌سازی‌شده یا نسخه‌ای در زمان، باید معرف داده‌هایی باشند که مدل پس از استقرار کامل، از نظر حجم یا توزیع دریافت می‌کند. در غیر این صورت، فرآیندهای آزمایشی شما نماینده نخواهند بود و مدل شما ممکن است در تولید متفاوت رفتار کند.
3. اهمیت ویژگی و برابری - اهمیت ویژگی در نسخه جدیدتر مدل باید نسبتاً با مدل قدیمی تر مقایسه شود، اگرچه ممکن است ویژگی های جدیدی معرفی شود. این برای اطمینان از عدم تعصب مدل است.
4. تست فرآیند کسب و کار - مهم است که یک نسخه جدید از یک مدل بتواند اهداف تجاری مورد نیاز شما را در پارامترهای قابل قبول برآورده کند. به عنوان مثال، یکی از معیارهای تجاری می تواند این باشد که تاخیر سرتاسر برای هر سرویسی نباید بیش از 100 میلی ثانیه باشد، یا هزینه میزبانی و آموزش مجدد یک مدل خاص نمی تواند بیش از 10,000 دلار در سال باشد.
5. هزینه - یک رویکرد ساده برای آزمایش، تکرار کل محیط تولید به عنوان یک محیط آزمایشی است. این یک روش معمول در توسعه نرم افزار است. با این حال، چنین رویکردی در مورد مدل‌های ML ممکن است بسته به اندازه داده‌ها، ROI مناسبی را به همراه نداشته باشد و ممکن است مدل را از نظر مشکل تجاری که به آن می‌پردازد، تحت تأثیر قرار دهد.
6. دوربین های مداربسته – معمولاً انتظار می‌رود که محیط‌های آزمایشی به جای داده‌های واقعی مشتری، داده‌های نمونه داشته باشند و در نتیجه، رسیدگی به داده‌ها و قوانین انطباق می‌تواند کمتر سخت‌گیرانه باشد. درست مانند هزینه، اگر به سادگی محیط تولید را در یک محیط آزمایشی کپی کنید، می توانید خطرات امنیتی و انطباق را معرفی کنید.
7. مقیاس پذیری فروشگاه ویژگی - اگر سازمانی به دلیل هزینه یا دلایل امنیتی تصمیم بگیرد که یک فروشگاه ویژگی های آزمایشی جداگانه ایجاد نکند، باید آزمایش مدل در فروشگاه ویژگی های تولید انجام شود، که می تواند باعث مشکلات مقیاس پذیری شود زیرا ترافیک در طول دوره آزمایش دو برابر می شود.
8. عملکرد مدل آنلاین - ارزیابی های آنلاین با ارزیابی های آفلاین متفاوت است و در برخی موارد مانند مدل های توصیه می تواند مهم باشد زیرا آنها رضایت کاربر را به جای رضایت درک شده در زمان واقعی اندازه گیری می کنند. شبیه سازی الگوهای ترافیک واقعی در حالت غیرتولیدی به دلیل فصلی بودن یا سایر رفتارهای کاربر دشوار است، بنابراین عملکرد مدل آنلاین فقط در زمان تولید قابل انجام است.
9. عملکرد عملیاتی – از آنجایی که مدل‌ها بزرگ‌تر می‌شوند و به طور فزاینده‌ای به صورت غیرمتمرکز روی سخت‌افزارهای مختلف مستقر می‌شوند، مهم است که مدل را برای عملکرد عملیاتی مورد نظر خود مانند تأخیر، نرخ خطا و موارد دیگر آزمایش کنید.

اکثر تیم های ML رویکردی چند جانبه برای آزمایش مدل دارند. در بخش‌های بعدی، راه‌هایی برای رسیدگی به این چالش‌ها در مراحل مختلف تست ارائه می‌کنیم.

تست مدل آفلاین

هدف از این مرحله آزمایش، اعتبارسنجی نسخه های جدید یک مدل موجود از نقطه نظر دقت است. این باید به صورت آفلاین انجام شود تا بر هیچ پیش‌بینی در سیستم تولید که به پیش‌بینی‌های بلادرنگ ارائه می‌شود تأثیری نگذارد. با حصول اطمینان از اینکه مدل جدید برای معیارهای ارزیابی قابل اجرا بهتر عمل می کند، این آزمایش به چالش 1 (عملکرد دقت مدل) می پردازد. همچنین، با استفاده از مجموعه داده مناسب، این آزمایش می‌تواند چالش‌های 2 و 3 (کیفیت داده‌های تست، اهمیت ویژگی و برابری) را با مزیت اضافی مقابله با چالش 5 (هزینه) برطرف کند.

این مرحله در محیط صحنه سازی انجام می شود.

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

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

به عنوان یک امتیاز اضافی، با ادغام Amazon SageMaker Clarify در آزمایش مدل آفلاین خود، می توانید نسخه جدید مدل را از نظر سوگیری بررسی کنید و همچنین انتساب ویژگی را با نسخه قبلی مدل مقایسه کنید. با خطوط لوله، می توانید کل گردش کار را به گونه ای تنظیم کنید که پس از آموزش، یک مرحله بررسی کیفیت برای انجام تجزیه و تحلیل معیارهای مدل و اهمیت ویژگی انجام شود. این معیارها در رجیستری مدل SageMaker برای مقایسه در دوره بعدی آموزش

یکپارچه سازی و تست عملکرد

تست یکپارچه سازی برای اعتبارسنجی فرآیندهای تجاری سرتاسر از منظر عملکردی و همچنین عملکرد زمان اجرا مورد نیاز است. در این فرآیند، کل خط لوله باید آزمایش شود، از جمله واکشی، و محاسبه ویژگی‌ها در فروشگاه ویژگی و اجرای برنامه ML. این باید با انواع بارهای مختلف انجام شود تا انواع سناریوها و درخواست ها را پوشش دهد و پوشش بالایی برای همه اجرای کدهای ممکن به دست آورد. این به چالش های 4 و 9 (تست فرآیند کسب و کار و عملکرد عملیاتی) می پردازد تا اطمینان حاصل شود که هیچ یک از فرآیندهای تجاری با نسخه جدید مدل شکسته نمی شوند.

این آزمایش باید در یک محیط مرحله بندی انجام شود.

هر دو تست یکپارچه سازی و تست عملکرد باید توسط تیم های فردی با استفاده از خط لوله MLOps خود اجرا شوند. برای آزمایش یکپارچه‌سازی، روش آزمایش‌شده و آزمایش‌شده حفظ یک محیط پیش‌تولید از نظر عملکردی و آزمایش با چند بار مختلف را توصیه می‌کنیم. گردش کار تست می تواند همانطور که در نشان داده شده است خودکار شود این کارگاه. برای تست عملکرد، می توانید استفاده کنید توصیه کننده استنباط آمازون SageMaker، که یک نقطه شروع عالی برای تعیین نوع نمونه و تعداد نمونه های مورد استفاده ارائه می دهد. برای این کار، باید از یک ابزار مولد بار استفاده کنید، مانند پروژه های منبع باز perfsizesagemaker و شکل دادن که Intuit توسعه داده است. Perfsizesagemaker به شما این امکان را می‌دهد که پیکربندی‌های نقطه پایانی مدل را با انواع بارها، زمان‌های پاسخ و تراکنش‌های پیک در ثانیه به‌طور خودکار آزمایش کنید. نتایج آزمایش دقیقی را ایجاد می کند که نسخه های مدل های مختلف را با هم مقایسه می کند. Perfsize ابزار همراهی است که پیکربندی‌های مختلفی را با توجه به حداکثر تراکنش‌ها در ثانیه و زمان پاسخ مورد انتظار امتحان می‌کند.

تست / B

در بسیاری از موارد که واکنش کاربر به خروجی فوری مدل مورد نیاز است، مانند برنامه های کاربردی تجارت الکترونیک، ارزیابی عملکرد مدل آفلاین کافی نیست. در این سناریوها، قبل از تصمیم گیری برای به روز رسانی مدل ها، باید مدل های A/B را در تولید آزمایش کنید. تست A/B نیز خطرات خود را دارد زیرا ممکن است تأثیر واقعی مشتری بر آن وارد شود. این روش تست به عنوان تایید نهایی عملکرد ML، یک بررسی سلامت مهندسی سبک وزن عمل می کند. این روش همچنین به چالش های 8 و 9 (عملکرد مدل آنلاین و تعالی عملیاتی) می پردازد.

تست A/B باید در محیط تولید انجام شود.

با SageMaker می توانید به راحتی با اجرا کردن، تست A/B را روی مدل های ML انجام دهید انواع مختلف تولید در یک نقطه پایانی ترافیک را می توان به صورت افزایشی به نسخه جدید هدایت کرد تا خطری که یک مدل بد رفتار می تواند در تولید داشته باشد کاهش دهد. اگر نتایج تست A/B خوب به نظر برسد، ترافیک به نسخه جدید هدایت می‌شود و در نهایت 100 درصد ترافیک را به خود اختصاص می‌دهد. برای انتقال از مدل A به B، استفاده از نرده‌های حفاظتی استقرار را توصیه می‌کنیم. برای بحث کامل‌تر در مورد آزمایش A/B با استفاده از آمازون شخصی سازی کنید مدل ها به عنوان نمونه رجوع شود استفاده از تست A/B برای اندازه گیری اثربخشی توصیه های ایجاد شده توسط Amazon Personalize.

تست آنلاین مدل

در این سناریو، نسخه جدید یک مدل به طور قابل توجهی با نسخه ای که در حال حاضر به ترافیک زنده در تولید خدمات ارائه می دهد متفاوت است، بنابراین رویکرد آزمایش آفلاین دیگر برای تعیین کارایی نسخه مدل جدید مناسب نیست. برجسته ترین دلیل این امر تغییر در ویژگی های مورد نیاز برای تولید پیش بینی است، به طوری که تراکنش های ثبت شده قبلی نمی توانند برای آزمایش مدل استفاده شوند. در این سناریو، توصیه می کنیم از استقرار سایه ها استفاده کنید. استقرار سایه قابلیت استقرار یک سایه (یا رقیب) مدل در کنار تولید (یا قهرمان) مدلی که در حال حاضر پیش بینی ها را ارائه می کند. این به شما امکان می دهد نحوه عملکرد مدل سایه در ترافیک تولید را ارزیابی کنید. پیش بینی های مدل سایه به برنامه درخواست کننده ارائه نمی شود. آنها برای ارزیابی آفلاین وارد شده اند. با رویکرد سایه برای آزمایش، ما به چالش‌های 4، 5، 6 و 7 (تست فرآیند کسب‌وکار، هزینه، امنیت و مقیاس‌پذیری فروشگاه ویژگی‌ها) می‌پردازیم.

آزمایش مدل آنلاین باید در محیط های صحنه سازی یا تولید انجام شود.

این روش برای آزمایش نسخه های مدل جدید باید به عنوان آخرین راه حل استفاده شود اگر همه روش های دیگر قابل استفاده نیستند. ما آن را به‌عنوان آخرین راه‌حل توصیه می‌کنیم، زیرا تماس‌های دوطرفه به مدل‌های متعدد، بار اضافی بر روی تمام خدمات پایین‌دستی تولید ایجاد می‌کند، که می‌تواند منجر به گلوگاه‌های عملکرد و همچنین افزایش هزینه در تولید شود. آشکارترین تأثیر این امر بر روی لایه سرویس دهی ویژگی است. برای موارد استفاده که ویژگی‌های مشترکی از داده‌های فیزیکی را به اشتراک می‌گذارند، باید بتوانیم موارد استفاده چندگانه را با دسترسی همزمان به جدول داده‌ای مشابه شبیه‌سازی کنیم تا اطمینان حاصل کنیم که قبل از انتقال به تولید، هیچ اختلاف منابع وجود ندارد. تا جایی که ممکن است، باید از جستجوهای تکراری در فروشگاه ویژگی اجتناب شود و ویژگی های مورد نیاز برای هر دو نسخه مدل باید برای استنتاج دوم مجدداً استفاده شود. فروشگاه های ویژه بر اساس آمازون DynamoDBهمانطور که Intuit ساخته است، می تواند پیاده سازی کند شتاب دهنده DynamoDB آمازون(DAX) برای کش کردن و جلوگیری از دو برابر کردن I/O به پایگاه داده. این گزینه‌ها و سایر گزینه‌های ذخیره‌سازی می‌توانند چالش 7 (مقیاس‌پذیری فروشگاه ویژگی) را کاهش دهند.

برای پرداختن به چالش 5 (هزینه) و همچنین 7، ما استفاده از استقرار سایه‌ها را برای نمونه‌برداری از ترافیک ورودی پیشنهاد می‌کنیم. این به صاحبان مدل یک لایه دیگر از کنترل برای به حداقل رساندن تأثیر بر سیستم های تولید می دهد.

استقرار سایه باید به روی برد مانیتور مدل ارائه ها درست مانند استقرار تولید معمولی به منظور مشاهده پیشرفت های نسخه چالشگر.

نتیجه

این پست بلوک های ساختمانی را برای ایجاد مجموعه ای جامع از فرآیندها و ابزارها برای رفع چالش های مختلف با آزمایش مدل نشان می دهد. اگرچه هر سازمانی منحصر به فرد است، این باید به شما کمک کند تا شروع کنید و ملاحظات خود را هنگام اجرای استراتژی تست خود محدود کنید.

---

درباره نویسندگان

توبیاس ونزل یک مدیر مهندسی نرم افزار برای پلت فرم یادگیری ماشین Intuit در Mountain View، کالیفرنیا است. او از زمان آغاز به کار آن در سال 2016 روی این پلتفرم کار کرده است و از ابتدا به طراحی و ساخت آن کمک کرده است. در کار خود، او بر برتری عملیاتی پلت فرم و ارائه موفقیت آمیز آن از طریق تجارت فصلی Intuit تمرکز کرده است. علاوه بر این، او مشتاق گسترش مداوم پلتفرم با آخرین فناوری‌ها است.

شیوانشو آپادحیای یک معمار اصلی راه حل در گروه توسعه تجارت و صنایع استراتژیک AWS است. در این نقش، او به اکثر پذیرندگان پیشرفته AWS کمک می کند تا صنعت خود را با استفاده موثر از داده ها و هوش مصنوعی تغییر دهند.

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