<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>نوشته های Meysam.A</title><link>https://virgool.ir/feed/@DataJr</link><description>every day is a chance to learn more</description><language>fa</language><pubDate>2026-11-12 01:13:21</pubDate><image><url>https://files.virgool.ir/upload/users/1038676/avatar/5iXsc4.jpeg</url><title>Meysam.A</title><link>https://virgool.ir/@DataJr</link></image><item><title>ایجاد Transformer کاستوم در Pipelineهای Scikit-learn</title><link>https://virgool.ir/@DataJr/ایجاد-transformer-سفارشی-در-pipelineهای-sklearn-vfozoeekh727</link><description>اگه با کتابخونه‌ی Scikit-learn آشنایی دارید، حتما پیش اومده که حین train مدل‌هاتون از pipeline استفاده کردین. بعنوان مثال فرض کنید تمام داده‌های دیتافریم ما عددی هستند و در pipeline زیر ما تعیین کردیم که قبل از فیت شدن لاجستیک رگرسیون روی داده‌هامون، داده‌ها ابتدا scale بشن:حالا فرض کنید میخوایم از یک Transformer خاص و مد نظر خودمون به نام multiplierTransformer در Pipeline مون استفاده کنیم که یه ستون جدید (بنام multiple) به دیتافریم مون اضافه کنه که شامل حاصلضرب داده‌های دو ستون دلخواه a و b باشه:برای این منظور، کلاس زیر رو تعریف میکنیم که دارای دو متد fit و transform بوده، و در سازنده یا constructor اون، ستون‌هایی که قراره بعنوان ورودی بدیم  ست میکنیم: سپس میتونیم از Transformer جدیدمون استفاده کنیم و پایپلاینی که ایجاد کردیم رو روی داده‌هامون فیت کنیم و بعد روی داده‌های تست، predict انجام بدیم :و به این ترتیب با عبور داده‌ها از step اول pipelineمون، در هر سطر از دیتافریم، یه ستون جدید بنام &#39;multiple&#39; از حاصلضرب دو ستون a و b ایجاد میشه. و میتونیم ترنسفورمری که ساختیم رو  به تنهایی(میخوایم فقط خروجی ترنسفورمر رو چک کنیم) روی یه دیتافریم ساختگی امتحان کنیم:* در مثال بالا ما متد fit_transform رو فراخوانی کردیم تا خروجی رو ببینیم و در پایپلاینمون هیچ estimator ای نبود(مثل LogisticRegression)، چون estimatorها متد transform ندارن(predict دارن).نکته 1 : درواقع وقتی متد fit رو در pipeline فراخوانی می‌کنیم، متد fit مربوط به Transformerهای حاضر در pipeline  فراخوانی میشه. و با فراخوانی متد predict مربوط به pipeline، تنها متد transform مربوط به Transformerهای حاضر در pipeline فراخوانی میشه.نکته 2 : متد fit اونجاییه که فاز &#34;یادگیری (learning)&#34; اتفاق میوفته و پارامترهای مدلمون و همچنین Transformerهای حاضر در pipeline ، در متد fit ایجاد میشن. حالا بعنوان مثال فرض کنید بخوایم در ترسنفورمری که ساختیم، به اون حاصلضربمون(ضرب دو ستون a و b) میانگین داده‌های دو ستون رو اضافه کنیم و اینبار حاصل رو در ستون &#34;multipleAndMeans&#34; قرار بدیم. برای این منظور باید عملیات بدست آوردن میانگین‌ها رو در متد &#34;fit&#34; انجام بدیم تا وقتی متد transform فراخوانی شد، این مقادیر(میانگین اعداد دو ستون) رو داشته باشیم:میتونین ازین لینک به کدها دسترسی داشته باشین.</description><category>Meysam.A</category><author>Meysam.A</author><pubDate>Mon, 16 Aug 2021 21:52:14 +0430</pubDate></item><item><title>اعتبارسنجی متقابل تو در تو (Nested Cross Validation) در Scikit-learn</title><link>https://virgool.ir/@DataJr/اعتبارسنجی-متقابل-تو-در-تو-nested-cross-validation-در-sklearn-nxu4jwffmpch</link><description>آموزش مدل برای پیدا کردن پارامترای مناسب، و همچنین ارزیابی مدل روی یه دیتای یکسان، یه اشتباهه که میتونه منجر به overfitting بشه. و رویه درستش اینه که وقتی داریم عملکرد چندین مدل رو مقایسه میکنیم، دیتایی که برای hyperparameter tuning استفاده شده رو برای تست کردن مدل‌ها استفاده نکنیم.تو این مطلب درمورد cross validation یه توضیحاتی داده شد. و گفتیم که برای ارزیابی عملکرد مدل و همچنین انتخاب بهترین ترکیب پارامترای مدلمون حین train روی دیتاست، از cross validation استفاده میکنیم.اگه وقتی داریم مدل رو بر اساس یه سری از hyperparameterها tune میکنیم،بخوایم همزمان مدلمون رو ارزیابی(evaluate) کنیم، باید Nested Cross Validation انجام بدیم. در حالت عادی وقتی اینکارو نکنیم، و بیایم از همون دیتایی که برای انتخاب بهترین hyperparameterها استفاده کردیم، برای test کردن مدلمون استفاده کنیم، چون مدلمون در حین tuning ، داده‌ها رو تجربه کرده، test-score واقعی رو نشون نمیده(بهتر از چیزی که در واقع هست نشون میده) و اصطلاحا رو داده‌هامون overfit میشه، و اینو حتما باید وقتی عملکرد چندین مدل رو مقایسه میکنیم بهش توجه کنیم.وقتی که Nested CV انجام میدیم، از یه inner-cv برای انتخاب بهترین پارامترا، و از یه outer-cv برای تست کردن مدلمون استفاده میکنیم. بعنوان مثال همچین اتفاقی میوفته (درصدها هم فرضی هستن): اول دیتامون رو(در هر split از outer-cv) به دو قسمت 70-30 درصدی تقسیم میکنیم،بخش 30 درصدی(test set) رو برای تست نهایی(روی مدلی که tune شده) کنار میذاریم، و بعد خوده اون 70 درصد رو میاریم به دو قسمت 80-20 تقسیم میکنیم. بعد میایم hyperparameterهای مدل رو (در هر split از Inner-Cv) روی این 80 درصد train میکنیم(train set) و روی بخش 20 درصدی (validation set) ، test میکنیم تا بهترین پارامترا رو با توجه به عملکردشون انتخاب کنیم. بعد که مدلمون با بهترین پارامترا رو انتخاب کردیم، میایم  این مدل رو روی اون 30 درصدی که اول کار کنار گذاشته بودیم test میکنیم، و اینبار عملکرد واقعی‌تر و منطقی‌تری رو از مدلمون انتظار داریم. البته که میتونیم خودمون این روال رو بدون استفاده از Nested CV پیاده کنیم و دیتای تستمون رو جُدا از دیتایی که برای انتخاب پارامترا استفاده کردیم درنظر بگیریم. اما هدف ازین مطلب صرفا آشنایی با Nested CV هست.تو قطعه کد زیر، داخل حلقه for دوتا splitter ساده KFold تعریف کردیم(با توجه به اینکه میدونیم داده‌هامون ارتباط گروهی و ... ندارن) و هر بار یه random state جدید در نظر میگیریم و بهترین score  مربوط به GridSearch، و میانگین score مربوط به nested cros_val_score رو تو دوتا آرایه جُدا ذخیره می‌کنیم. و نهایتا خارج حلقه، اعداد این دو آرایه رو رسم کردیم:میبینیم که اکثر مواقع وقتی با test-set ای که در outer_cv کنار گذاشته شده، مدل رو ارزیابی میکنیم، accuracy پایین تری داریم و این نتیجه منطقی تره.ازین لینک میتونین به کدها دسترسی داشته باشین. موفق باشید ?منبع</description><category>Meysam.A</category><author>Meysam.A</author><pubDate>Thu, 15 Jul 2021 05:38:54 +0430</pubDate></item><item><title>آشنایی با Cross Validation در Scikit-Learn</title><link>https://virgool.ir/@DataJr/آشنایی-با-cross-validation-در-sklearn-wndk12xxcoiv</link><description>فرآیند cross validation به این شکله که دیتاست به k بخش(fold) تقسیم میشه و k بار از یه بخش جدید برای test و از بقیه(k-1) برای train استفاده میشه، به این ترتیب زیرمجموعه‌های مختلفی از کل دیتایی که داریم رو، برای تست استفاده میکنیم. حالا هدف ازین کار یا پیدا کردن بهترین hyperparameterهای مدلامون هست، یا ارزیابی مدل‌ها، که در هر صورت دید منطقی تری نسبت به generalization مدل پیدا میکنیم، یعنی میفهمیم مدلمون تا چه حد عملکرد خوبی روی دیتاهایی که تجربه نکرده(unseen data) خواهد داشت. به مثال زیر توجه کنید:اینجا هر بار دیتاستمون رو با یه نسبت دلخواه تقسیم کردیم و مدلمون رو با یه بخش از دیتا train و با یه بخش دیگه test کردیممیبینیم که طی هر split، مدلمون عملکرد خیلی متفاوتی داشته و دلیلش هم اینه که هر بار با نمونه‌های متفاوتی test شده. اما ما نمیتونیم به test کردن مدلمون به شکل بالا و با فقط یه بخش از دیتاست بسنده کنیم، چون گاهی میخوایم  چندین مدل رو باهم مقایسه میکنیم، و بهتره سعی کنیم از تمام دیتایی که داریم بعنوان test-set استفاده کنیم، همچنین این کارو باید طوری انجام بدیم که قبلش مدلمون این test-set رو تجربه نکرده باشه، تا بفهمیم در حالت کلی کدوم یکی از مدلامون عملکرد بهتری توی predict کردن داده‌هایی که تجربش نکردن(unseen data) دارن، و اینجاست که باید cross validation انجام بدیم(البته  اگه بخوایم همزمان هم مدلامون رو tune کنیم، و هم ارزیابیشون کنیم، باید از nested cross validation استفاده کنیم، که تو این پست راجبش توضیح داده شده)استراتژی‌های مختلفی برای cross validation بر اساس ماهیت داده‌ها وجود داره که در کتابخونه scikit-learn براشون کلاس‌هایی بنام Cross validation Splitters هست که بهشون cross validator هم گفته میشه(در حالی که صرفا splitter هستن فقط)، مثل KFoldStratified  ، LeaveOneOut ، ShuffleSplit ، KFold   و ... که میان به ما ایندکس داده‌های split شده در هر مرحله رو برمیگردونن و هر کدوم در موقعیت خاصی(با توجه به داده‌هامون) استفاده میشن که تو یه مطلب دیگه دقیق تر بهشون اشاره میکنیم. قطعه کدای زیر مثالی از ساده‌ترین splitter هستن بنام KFold، که تو مواقعی که دیتاهامون هیچ ترتیب زمانی یا هیچ ارتباط گروهی‌ای باهم ندارن(تاثیر وجود این ارتباط رو هم بعدا بررسی میکنیم)، استفاده میشه و خروجیشو میبینید:اینجا داده‌هارو به 3 قسمت تقسیم کردیم و از shuffle استفاده نکردیم، که یعنی داده‌های test با همون ترتیبی که داشتن جدا شدن(یه بار 3 تای اول، یبار 3 تای دوم و ...)اما اینجا با shuffle=True ، &#34; قبل از شروع&#34;  spilt کردن ، داده‌ها یبار بُر زده میشنخب، حالا فرض کنید با این splitterها میخوایم روی دیتاستمون cross validation انجام بدیم و درواقع مدلمون رو با زیر مجموعه‌های مختلفی از feature‌ها (X) و label‌ها (Y) مون ، train و test کنیم. بدون shuffle دیتامون(هم X و هم Y) به این شکل تقسیم میشه:به ترتیب هر بار یک چهارم بعدی ِدیتا split شده(ایندکسِ داده‌ها مرتب هستش)و همچنین با shuffle کردن دیتا، ایندکس داده‌ها بُر میخورن و تو هر split ، اون یک سوم داده‌ها (test set) از بخشهای رندومی انتخاب میشن:این splitter ها میتونن بعنوان ورودی&#34;cv&#34; در توابع cross_validate ، cross_val_score و  GridSearchCV و امثال اینا پاس داده بشن:از یکی از splitter هایی که ساخته بودیم بعنوان ورودی &#34;cv&#34; استفاده کردیمخب راست به چپ هم که نمیشه بنویسیم تو ویرگول? پس مجبوریم اول هر عنوان انگلیسی یه چیز فارسیم بذاریم ?فانکشن GridSearchCV : برای Hyperparameter tuning استفادش میکنیم و کارکردش به این شکله که طی فرآیند cross validation میاد یه دیکشنری از ما میگیره (به ورودی param_grid پاسش میدیم) که شامل یه سری پارامترهای مخصوص مدلمون هست و ما میخوایم بفهمیم مدلمون با کدوم ترکیب ازین پارامترها، روی دیتاستی که داریم، بهتر عمل میکنه و بعد از fit کردن روی دیتامون با مشخصه best_estimator ، مدلی که با بهترین پارامترا fit شده رو میتونیم داشته باشیم:توجه کنید که اینجا اصلا ورودی &#34;cv&#34; رو تعیین نکردیم (none)فانکشن cross_validate : صرفا خوده عمل cross validation رو انجام میده و خروجیش یه دیکشنری شامل زمان fit شدن، زمان evaluate کردن و scoreهای مربوط به split‌های مختلف هستش:اینجا ورودی &#34;cv&#34; رو یه آبجکت KFold  با 4 split دادیم، که یعنی 4 بار داده‌ها به 4 قسمت تقسیم میشن و 4 تا score داریم که مربوط به هر split هستنتو عکس بالا به  test_score مربوط به split چهارم توجه کنید، میبینیم که از همه split ها کمتره.دلیل این overfitting چی میتونه باشه؟ جواب: ازونجایی که &#34;cv&#34; رو یه آبجکت KFold دادیم، تو این حالت splitter ما داده‌ها رو بُر نمیزنه و عملا تو split آخر، 25% آخر دیتاست قرار گرفتن. پس باید دیتاستمون رو هم دقیق‌تر بررسی کنیم تا ببینیم دلیل چی میتونه باشه، و آیا دیتاهامون تو اون تیکه شکل خاصی دارن؟ البته این حالت با یه بُر زدن رفع میشه و حتی ممکنه تو همین مثالم علتش چیزه خاصی نباشه، ولی نکته اینجاست که بعضی وقتا(هر چند خیلی کم) ممکنه حین cross validation به همچین مواردی بر بخوریم که دید بهتری نسبت به داده‌هامون پیدا میکنیم.فانکشن cross_val_score : مستقیما test_score ها رو برمیگردونه:ورودی &#34;cv&#34; رو چیزی ندادیم(none) و میبینیم که بصورت پیشفرض تعداد split ها 5 هستیه سری دیگه هم ازین توابع هستن که خودتون در صورت نیاز بررسیشون کنین، مثل learning_curve ، RandomizedSearchCv و ...اغلب تو مواردی که برای آشنایی یا تمرین روی دیتاست‌ها ازین فانکشن‌ها استفاده میشه، پارامتر &#34;cv&#34; رو یه عددی مثل k و یا حتی &#34;none&#34; در نظر میگیریم،  که در این حالت، این فانکشن‌ها بصورت پیشفرض از (shuffle=False)StratifiedKFold بعنوان آبجکت &#34;cv&#34; استفاده میکنن که مشابه KFold هستش، منتهی میاد علاوه بر اینکه داده‌هامون رو هر بار به k دسته تقسیم میکنه، نسبت داده‌ها رو هم رعایت میکنه، یعنی اگه فرضا سه کلاس B ، A و C داشته باشیم که به ترتیب 40% ، 30% و 30% از داده‌هامون رو تشکیل بدن، تو هر split ، هم بخش test و هم بخش train، شامل 40% از کلاس A و 30% از کلاس B و 30% از کلاس C خواهند بود.نکته:   StratifiedKFold در صورتی که estimator مون یه classifier باشه(مثل SVM)، و داده‌هامون 2 دسته و یا بیشتر باشن بعنوان splitter پیشفرض هست، در غیر این صورت همون (shuffle=False)KFold فراخوانی میشه.حالا که تا اینجا اومدین، بد نیست نحوه split کردن خوده همین StratifiedKFold رو هم ببینید:میبینیم که نسبت کلاس‌ها در هر split حفظ شده (30% از هر کلاس برای train و 30% برای test)ضمنا شکل مربوط به (shuffle=True)StratifiedKFold هم شبیه (shuffle=True)Kfold میشد و از لحاظ بصری نمیشه تشخیص داد که نسبت کلاس‌ها حفظ شده واسه همین دیگه شکلشو نذاشتم.خب فعلا کافیه، ببخشید اگه طولانی شد. اینجا فقط سعی شد تا کلیت cross validation گفته بشه و یکم به اهمیت این کار اشاره کنیم و انشاالله تو مطلب مفصل تری به انواع روشهای cross validation (در واقع انواع استراتژی‌های splitting) و علت استفاده از هر نوع میپردازیم.ضمنا کدهای مربوط به این مطلب ازین آدرس قابل دسترسی هستن. موفق باشید?منبع</description><category>Meysam.A</category><author>Meysam.A</author><pubDate>Wed, 14 Jul 2021 22:30:31 +0430</pubDate></item></channel></rss>