NLP stuff

سفت کردن جای پا با فریم‌بندی درست مسائل ML

در ادامه رشته‌پست‌ها از کتاب Designing Machine Learning Systems با یک موضوع مهم از فصل دوم این کتاب در خدمتتون هستیم. فریم‌بندی درست مسائل در حوزه ML می‌تونه درصد موفقیت پروژه‌ها رو در این حوزه تا حد زیادی بالا ببره. برای فریم‌بندی می‌تونیم به این شکست فکر کنیم که چه نوع ورودی باید به مدل بدیم (input features)، چه خروجی باید بگیریم (target labels) و انتظار داریم چه چیزی رو مدل یاد بگیره (objective functions).
درباره مورد اول و دوم یک چاله رایج وجود داره و اون هم وابسته کردن مدل به مفاهیمیه که متغیر هستند. کتاب درباره نوع خروجی دادن مدل یک مثال میزنه و اون هم مساله تشخیص اپ بعدی‌ای ست که کاربر بر روی اون در یک اپ‌استور کلیک می‌کنه. یک مدل اولیه می‌تونه این باشه که خروجی مدل رو یک وکتور به اندازه سایز تمام اپ‌ها درنظر بگیریم و مدل با دادن فیچرهای ترجیحات کاربر، حدس بزنه که احتمال کلیک بر روی هر یک از اپ‌ها چقدر هست. با این فریم‌بندی عملا سایز خروجی مدل به تعداد اپ‌های حاضر بر روی اپ استور bind شده که می‌دونیم با نرخ بالایی تغییر می‌کنه. همچنین مساله شبیه یک multi class classification شده که مساله‌ای به مراتب سخت‌تر از binary classification است. شکل درست کار در این جا می‌تونه ورودی دادن فیچرهایی از ترجیحات کاربر و فیچرهای اپ‌ها به صورت توامان با هم باشه و از مدل بخوایم که بگه فلان اپ رو کاربر کلیک میکنه یا نه (طبق تصاویر در اینجا موقع inference نیاز داریم که به تعداد اپ‌ها مدل رو صدا بزنیم که قابلیت موازی‌سازی داره و مشکلی ایجاد نمی‌کنه ولی در عوض خروجی باینری برای مدل داریم و ابعاد خروجی متغیر نیست).
با این تغییر همچنین نیاز نیست برای adopt شدن مدل با هر اپ جدید، حتما retrain انجام بشه و حتی چالش cold start برای اپ‌های جدید هم تا حدی با الگویابی مدل از اپ‌های قبلی که شبیه اپ‌های جدید هستند، می‌تونه بهتر بشه.
همین چاله برای فیچرهای ورودی هم می‌تونه پیش بیاد که البته کتاب بهش اشاره‌ای نمی‌کنه اما با کمی فکر کردن می‌تونیم مثال‌های مختلفی براش پیدا کنیم. مثلا ممکنه شما در مساله‌تون فیچری داشته باشید که انواع مختلف واکنش‌های کاربر رو بخواید بشمارید و ممکنه مثلا واکنش‌های مثبت، انواع مختلفی داشته باشند که اثر یکسانی در بیزنس دارند اما بسته به برخی تصمیمات دیزاین یا بیزنس کم و زیاد می‌شند. در اینجا یک مفهوم ثابت وجود داره و اون واکنش مثبت کاربره و تفکیک انواع واکنش‌ها باعث میشه روی فیچری تکیه کنید که جزییات بیشتری رو فراهم می‌کنه اما در عوض می‌تونه تغییر کنه و یا حتی مرز مشخصی بین کاربر‌ها برای اون وجود نداره.
نکته‌ای که مهمه اینه که با فریم‌بندی درست مسائل ML می‌تونیم تا حد زیادی از effort مساله کم کنیم و به نوعی جای پامون رو برای توسعه پروژه در آینده سفت‌تر کنیم.

#book

@nlp_stuff

Telegram

stuff

www.tg-me.com/us/NLP stuff/com.nlp_stuff/350

2.0K viewsMay 12 at 05:30

سفت کردن جای پا با فریم‌بندی درست مسائل ML

در ادامه رشته‌پست‌ها از کتاب Designing Machine Learning Systems با یک موضوع مهم از فصل دوم این کتاب در خدمتتون هستیم. فریم‌بندی درست مسائل در حوزه ML می‌تونه درصد موفقیت پروژه‌ها رو در این حوزه تا حد زیادی بالا ببره. برای فریم‌بندی می‌تونیم به این شکست فکر کنیم که چه نوع ورودی باید به مدل بدیم (input features)، چه خروجی باید بگیریم (target labels) و انتظار داریم چه چیزی رو مدل یاد بگیره (objective functions).
درباره مورد اول و دوم یک چاله رایج وجود داره و اون هم وابسته کردن مدل به مفاهیمیه که متغیر هستند. کتاب درباره نوع خروجی دادن مدل یک مثال میزنه و اون هم مساله تشخیص اپ بعدی‌ای ست که کاربر بر روی اون در یک اپ‌استور کلیک می‌کنه. یک مدل اولیه می‌تونه این باشه که خروجی مدل رو یک وکتور به اندازه سایز تمام اپ‌ها درنظر بگیریم و مدل با دادن فیچرهای ترجیحات کاربر، حدس بزنه که احتمال کلیک بر روی هر یک از اپ‌ها چقدر هست. با این فریم‌بندی عملا سایز خروجی مدل به تعداد اپ‌های حاضر بر روی اپ استور bind شده که می‌دونیم با نرخ بالایی تغییر می‌کنه. همچنین مساله شبیه یک multi class classification شده که مساله‌ای به مراتب سخت‌تر از binary classification است. شکل درست کار در این جا می‌تونه ورودی دادن فیچرهایی از ترجیحات کاربر و فیچرهای اپ‌ها به صورت توامان با هم باشه و از مدل بخوایم که بگه فلان اپ رو کاربر کلیک میکنه یا نه (طبق تصاویر در اینجا موقع inference نیاز داریم که به تعداد اپ‌ها مدل رو صدا بزنیم که قابلیت موازی‌سازی داره و مشکلی ایجاد نمی‌کنه ولی در عوض خروجی باینری برای مدل داریم و ابعاد خروجی متغیر نیست).
با این تغییر همچنین نیاز نیست برای adopt شدن مدل با هر اپ جدید، حتما retrain انجام بشه و حتی چالش cold start برای اپ‌های جدید هم تا حدی با الگویابی مدل از اپ‌های قبلی که شبیه اپ‌های جدید هستند، می‌تونه بهتر بشه.
همین چاله برای فیچرهای ورودی هم می‌تونه پیش بیاد که البته کتاب بهش اشاره‌ای نمی‌کنه اما با کمی فکر کردن می‌تونیم مثال‌های مختلفی براش پیدا کنیم. مثلا ممکنه شما در مساله‌تون فیچری داشته باشید که انواع مختلف واکنش‌های کاربر رو بخواید بشمارید و ممکنه مثلا واکنش‌های مثبت، انواع مختلفی داشته باشند که اثر یکسانی در بیزنس دارند اما بسته به برخی تصمیمات دیزاین یا بیزنس کم و زیاد می‌شند. در اینجا یک مفهوم ثابت وجود داره و اون واکنش مثبت کاربره و تفکیک انواع واکنش‌ها باعث میشه روی فیچری تکیه کنید که جزییات بیشتری رو فراهم می‌کنه اما در عوض می‌تونه تغییر کنه و یا حتی مرز مشخصی بین کاربر‌ها برای اون وجود نداره.
نکته‌ای که مهمه اینه که با فریم‌بندی درست مسائل ML می‌تونیم تا حد زیادی از effort مساله کم کنیم و به نوعی جای پامون رو برای توسعه پروژه در آینده سفت‌تر کنیم.

#book

@nlp_stuff

BY NLP stuff