https://virgool.ir/feed/@soheil.koohiمهندس یادگیری ماشینfa2026-11-11 06:57:50https://files.virgool.ir/upload/users/28272/avatar/ixM6R4.pnghttps://virgool.ir/@soheil.koohihttps://virgool.ir/snapp-eng/سیستم-یادگیری-ماشین-برای-پیش-بینی-eta-داستان-یک-بلوغ-oi0crxocax4jمنبع عکس: Erik Johansson، ارتقا کیفیت توسط Let's Enhanceمقدمهپیش‌بینی ETA (تخمین زمان رسیدن سفر) یکی از مهمترین سرویس‌های زیر مجموعه نقشه در هر اپلیکیشن تاکسی اینترنتی است. در اسنپ از سرویس ETA در جاهای گوناگون مثل قیمت گذاری سفر، پیشنهاد سفر به راننده و نمایش تخمین زمان رسیدن به راننده و مسافر در مراحل مختلف سفر، استفاده می‌شود. بنابراین دقت ETA همواره یکی از مهمترین متریک‌ها در تیم نقشه است و تغییرات هرچند کوچک آن می‌تواند متریک‌های مهم بیزینسی را تغییر دهد.به طور کلاسیک برای محاسبه ETA از روش‌های مبتنی بر دیتای ترافیکی و مسیریابی استفاده میشود. به این صورت که با در اختیار داشتن داده‌‌‌های live و historical ترافیکی می‌توان با استفاده از الگوریتم‌های مسیریابی، مدت زمان حدودی هر سفر را پیش‌بینی کرد. در سال‌های اخیر برای افزایش دقت ETA،از روش‌های یادگیری ماشین در کنار روش‌های مسیریابی، و یا به صورت مستقل استفاده شده است .در این مقاله قصد داریم داستان استفاده از سیستم‌ یادگیری ماشین برای کمک به محاسبه ETA و چالش‌های مهندسی آن، و همینطور رویکرد ما برای حل این چالش‌ها رو با شما به اشتراک بگذاریم.از آنجایی که تجربه‌های جدی استفاده از سیستم‌های یادگیری ماشین در فضای پروداکشن و در مقیاس بالا خیلی در دسترس نیست، سعی کردیم نگاه ما در این مقاله به جای بیان مشکلات و چالش های الگوریتمی و دیتا‌ساینسی و یا بهبود دقت مدل‌ها، نگاه به چالش‌های این سیستم با هدف رسیدن به یک سیستم قابل اتکا، مقیاس پذیر و قابل نگه‌داری باشد.فاز اول، تلاش برای کشف یک مسیردر ابتدای مسیر پروژه‌های یادگیری ماشین، مهمترین مسئله، سریع بودن در رسیدن به یک نمونه اولیه است که اثبات کند مسئله با استفاده از روش‌های یادگیری ماشین قابل حل است (PoC). دلیل این رویکرد و تفاوت آن نسبت به دیگر پروژه‌های توسعه نرم افزار این است که در مسائل یادگیری ماشین یک ابهام بزرگ برای مهندسان، تیم محصول و بیزینس وجود دارد که آیا مسئله اصولا قابل حل شدن با روش های یادگیری ماشین است یا خیر؟ دلیل این ابهام هم متفاوت بودن هر مسئله در یادگیری ماشین با توجه به دیتای موجود، نوع فرمول بندی مسئله و روش‌های حل آن است. به طور مثال هیچ نمونه مشابهی در کارهای منتشر شده وجود ندارد که نشان دهد مسئله پیشبینی یا بهبود ETA (دقیقا با داده های موجود در اسنپ) قابل حل با روش X است. حال این مسئله را مقایسه کنید با توسعه یک API که تا حد خیلی زیادی برای اکثر چالش‌های آن صدها ابزار، Best Practice و نمونه‌های موفق وجود دارد. بنابراین در شروع پروژه‌های یادگیری ماشین هدف اصلی برطرف کردن ابهامات و رسیدن به یک راه حل اولیه قابل قبول و انجام آزمایشات متنوع در سریع ترین زمان ممکن است و داشتن یک ساختار منظم برای توسعه، کدهای تمیز و رعایت همه‌ی اصول مهندسی نرم افزار از اهمیت کمتری برخوردار است.همین الگو در پروژه بهبود ETA اسنپ هم در دستور کار بود. در ابتدا سعی کردیم همه توانمان را بر روی مطالعه روش‌های منتشر‌ شده، جمع آوری و تمیز کردن داده، و آزمایش سناریو های مختلف صرف کنیم. پس از چندین ماه فاز تحقیق و توسعه به راه‌حلی رسیدیم که حداقل نیازمندی‌های بیزینس را چه از نظر دقت و چه از نظر سرعت و مصرف منابع برطرف میکرد. با توجه به اهمیت ETA در سرویس‌های مختلف اسنپ به سرعت یک سرویس برای serve کردن مدل را توسعه دادیم و پس از چند مرحله تست سرویس بر روی production مستقر شد.خروجی این مرحله اولیه، تعداد زیادی Jupyter Notebook بود که آزمایشات مختلف بر روی آن‌ها انجام شده بود و همینطور یک سرویس API بسیار ابتدایی با یک endpoint صرفا جهت serve مدل اولیه.چالش های فاز اولهمانطوری که در بخش قبلی اشاره کردیم، از آنجایی که هدف ما در فاز اولیه صرفا رسیدن به یک جواب معقول برای مسئله بود، بسیاری از استاندارد‌‌های توسعه در این فاز رعایت نشده بود و ادامه دادن پروژه ازینجا به بعد با شرایط فعلی کمی چالش برانگیز بود. در ادامه به تعدادی از این چالش‌ها اشاره میکنیم.نبود مستند سازی به شکل منظم و ساختارمند باعث شده بود پس از مدتی با اضافه شدن افراد جدید و خروج برخی از نیرو‌ها از پروژه، میزان زیادی از تاریخچه آزمایشات قبلی موجود نباشد و گاها مجبور به تکرار آزمایشات با افراد جدید باشیم.کد‌های پروژه همگی بر روی تعداد زیادی Jupyter Notebook بود که روی هر کدام، آزمایشات مختلفی انجام شده بود؛ بخش های زیادی از کدها کامنت بودند، ترتیب اجرای کد‌ها مشخص نبود، بخش های زیادی از کدها در نوت‌بوک های مختلف تکرار شده بودند، و در کل ادامه دادن آزمایشات قبلی و ایجاد بهبود بر روی همین کد‌ها تا حد زیادی ناممکن بود.آموزش مدل‌ها با داده‌های به روز، کاری پرهزینه بود چرا که تعداد زیادی فرآیند دستی و غیر بهینه باید اجرا انجام میشد، که هم ساعت‌های زیادی از تیم مهندسی میگرفت و هم از طرفی احتمال خطا در هر بخش را زیاد می‌کرد.مدل پیشنهادی یک مدل بسیار سنگین از نظر منابع مصرفی بود که هم زمان آموزش زیادی را می‌طلبید، و هم ذخیره سازی مدل‌ها را با چالش همراه میکرد. از طرفی با وجود این مدل حجیم، سرویس نهایی سرویسی گران و پرمصرف از نظر مصرف منابع سخت افزاری مثل رم، سی پی یو و جی پی یو بود.سیستم serving مدل‌ها بسیار نابالغ بود و observability و scalability لازم را نداشت. به عبارت دیگر فرآیند دیپلوی کردن یک مدل جدید هزینه مهندسی بالایی داشت و از طرفی سیستم monitoring و tracing مناسبی برای پایش سیستم و پیدا کردن خطاهای احتمالی موجود نبود.‌امکان تشخیص کاهش دقت مدل‌ها در طول زمان به صورت آنلاین وجود نداشت و هر بار تیم مهندسی با چند روز تاخیر متوجه کاهش دقت مدل می‌شد که reliability سیستم از نظر پایداری دقت را کاهش میداد.به طور خلاصه موارد بالا باعث شده بود تا نگهداری سیستم به طور reliable و scalable کاری بسیار پرهزینه باشه و از طرفی فرآیند‌های بهبود دقت و اجرای ایده‌های جدید هم با کندی زیادی پیش برود.فاز دوم، تلاش برای بلوغپس از مشاهده چالش‌هایی که در بخش قبل عنوان کردیم، فاز دوم توسعه این سیستم یادگیری ماشین را با هدف ارائه سیستمی قابل نگهداری و قابل اتکا آغاز کردیم. به طور عمومی در این مرحله از توسعه، پس از اینکه از feasible بودن حل مسئله با استفاده از روش‌های یادگیری ماشین اطمینان حاصل شد، تلاش می‌شود سیستم اولیه با استفاده از best practice های مهندسی نرم افزار و MLOps برای استفاده در محیط های پروداکشنی بازنگری شود.در ادامه این بخش به مروری اجمالی از ماژول‌های استفاده شده در این فاز برای غلبه بر چالش‌های ذکر شده می‌پردازیم.پروسه مستند‌سازی منظمیک بخش بسیار مهم از پروژه‌های یادگیری ماشین، دانشی است که در طول پروژه و با انجام آزمایشات مختلف در تیم به وجود می‌آید. این دانش که گنج بزرگی برای حال و آینده پروژه است، در صورت مستند‌‌سازی ناقص و غیر منظم، پس از مدتی از بین می‌رود و باعث ‌می‌شود مجبور به تکرار آزمایشات قبلی شویم و یا نتوانیم به درستی برای آینده پروژه تصمیم بگیریم. اولین اقدامی که در این فاز انجام دادیم توسعه یک روش مستند‌سازی بود. به این شکل که پس از هر آزمایش، تیم باید یک کارت مستندسازی برای آن پر میکرد که خلاصه‌ای از مهمترین اطلاعات آن آزمایش بود. اطلاعاتی که در هر کارت پر میشد شامل فرضیه ای که این آزمایش در تلاش تست آن بود، دیتای استفاده شده، روش آزمایش و نتایج حاصل بود. سعی کردیم این کارت تا حد ممکن خلاصه باشد تا پر کردن آن هزینه اضافه برای تیم نداشته باشد و از طرفی شامل همه موارد ضروری باشد. از طرفی پر کردن این کارت‌ها را به بخشی از Definition of Done برای تسک‌ها تبدیل کردیم تا از پر شدن منظم آن در طول زمان اطمینان کسب کنیم. با این کار آرشیوی ارزشمند از تاریخچه پروژه تهیه شد که به سوالات زیادی در آینده پاسخ می‌داد و باعث میشد تیم صرفا بر روی کارهای خلاقانه جدید تمرکز کند و بتواند از مشاهده کار‌های گذشته دانش انباشته‌ای را کسب کند.نمونه کارت مستند سازی هر آزمایش کد‌های ماژولاریکی از مواردی که در اکثر پروژه‌های یادگیری ماشین رعایت نمی‌شود رعایت حداقل استاندارد‌های مهندسی نرم افزار مانند نوشتن کد‌های ماژولار و تمیز است. اکثر اوقات وقتی در مورد پروژه‌های یادگیری ماشین فکر می‌کنیم تعدادی فایل ‌ Jupyter Notebook به ذهن می‌آید که پر از کد‌های کثیف، پرینت های طولانی، کد‌های کامنت شده و در مجموع مشخص نبودن روند کد‌ها است. همانطور که در فاز قبلی گفتیم این موضوع به ماهیت آزمایش محور پروژه‌های یادگیری ماشین برمیگردد. در ابتدای پروژه مهندسین تمام تمرکز خود را به اکتشاف مسئله و تست ایده‌های مختلف می‌گذارند که ابزاری تعاملی مثل Jupyter Notebook انتخاب مناسبی برای این نوع از اکتشافات و بررسی سریع نتیجه است. با گذشت زمان و بلوغ نسبی پروژه این رویکرد باعث کند شدن آزمایشات و عدم توانایی در استفاده از ابزار‌های مختلف برای Scale کردن پروژه می‌شود. به عنوان مثال اگر بخواهیم یک پایپ لاین آموزش اتوماتیک را توسعه دهیم، باید کد‌هایی تمیز و ساختارمند داشته باشیم.از این رو در این بخش پس از تحقیق بر روی چندین ابزار و فریمورک به ابزار Kedro رسیدیم که هدف آن همین ماژولار کردن کدهای یادگیری ماشین بر طبق استاندارد‌های توسعه نرم افزار بود. پس از این سعی کردیم همه کد‌های موجود در Jupyter Notebook ها را بر طبق این فریمورک بازنویسی کنیم. در انتها موفق به توسعه یک کد بیس تمیز، ماژولار، و با ویژگی اضافه یا کم کردن یک قابلیت به هر بخش از فرایند آموزش شدیم. این کد بیس جدید شامل چهار پایپ لاین کاملا جدا از هم برای جمع آوری داده، پیش پردازش داده، آموزش مدل و ارزیابی مدل بود. هر پایپلاین شامل تعدادی node بود که هر یک وظیفه ای را بر عهده داشتند. همه پایپ لاین ها و node ها به راحتی با یک فایل Yaml قابل مدیریت و تغییر بود و آزمایشات مختلف را بسیار سریع و منظم میکرد. حالا کافی بود بجای گشتن در کدهای تو در تو برای تغییر یک پارامتر (مثل learning rate) صرفا در فایل کانفیگ، پارامتر مورد نظر را تغییر دهیم. از طرفی این کدبیس جدید قابلیت‌های دیگری مثل integrate کردن فرایند آموزش با ابزارهای دیگر هم به ما داد. مثلا در سیستم آموزش اتوماتیک که جلو‌تر به آن می پردازیم، در هر راند از آموزش اتوماتیک صرفا یک فایل کانفیگ آماده و آموزش شروع میشد. در انتها ویژگی مهم دیگر این ساختار امکان آسان اضافه کردن ماژول‌های جدید برای آزمایشات بود. به طور مثال اگر تیم سعی داشت تا یک feature جدید را به مدل اضافه کند به راحتی به پایپلاین پیش پردازش داده ها رجوع می کرد، ایده خود را در قالب یک node پیاده سازی میکرد و در فایل کانفیگ آن node را فراخوانی میکرد.ماژولار کردن پایپلاین آموزش با Kedroبهینه سازی مدلبه دلیل تمرکز زیاد بر دقت مدل در گام‌‌های اولیه، احتمال استفاده از مدل‌های حجیم و غیر بهینه بسیار زیاد است. در فاز اولیه شما اصلا ایده‌ای ندارید که راه‌حل شما به جواب معقولی می‌رسد یا نه. پس دلیلی وجود ندارد که ذهن خود را درگیر بهینه بودن راه‌حل از نظر استفاده از منابع یا سریع بودن بکنید. اما زمانی که از این مرحله عبور کردیم و به یک راه‌حل معقول رسیدیم همه این دغدغه ها اهمیت پیدا می‌کنند. پس در این مرحله، ماجراجویی ما در جهت بهینه کردن مدل‌ها به هدف کم کردن منابع مصرفی، افزایش سرعت پاسخ مدل و مقیاس پذیر بودن مدل در عین حفظ دقت اولیه آغاز شد. همانطور که می‌دانیم در بسیاری از موارد یک مصالحه (Trade off) بین دقت مدل و سبک بودن آن برقرار است و محدودیت‌های بیزینسی مثل حداقل دقت قابل قبول و یا حداکثر میزان منابع مصرفی مجاز تعیین کننده این موضوع هستند که تا چه میزان می‌توانیم دقت را فدای بهینه کردن راه‌حل ها کنیم. در این مرحله چندین گزینه برای بهینه کردن مدل پیش روی ما بود. یک گزینه بهینه کردن هایپر پارامتر‌های مدل در جهت کوچک کردن مدل بود. تعداد لایه‌های شبکه‌های عصبی یا میزان عمق درخت در روش‌های مبتنی بر درخت تصمیم از جمله این موارد هستند. گزینه دیگر استفاده از یک runtime بهینه تر مانند استفاده از LightGBM به جای Scikit Learn یا استفاده از ONNX به جای TensorFlow بود. پس از آزمایشات مختلف بر روی هر دوی این مسیر‌ها به راه‌حلی رسیدیم که از نظر منابع مصرفی حدود ۵۰ برابر کمتر، از نظر سرعت حدود ۲ برابر سریعتر و تقریبا با همان دقت سابق بود. این مدل مسیر‌های جدیدی مانند استفاده از این راه‌حل در شهر‌های مختلف یا آموزش مدل بر روی فضای ابری اسنپ را به ما داد.تشخیص دریفتنگهداری سیستم‌های یادگیری ماشین از جوانبی شبیه به نگهداری دیگر سیستم‌های نرم‌افزاریست. هر دو این سیستم‌ها نیازمند نگهداری در زمان بروز خطاهای انسانی در مرحله توسعه، بروز خطاهای سخت افزاری و معیوب شدن آنها و همچنین بروز باگ‌های پیش بینی نشده نرم‌افزاری هستند. سیستم‌های یادگیری ماشین در ابعاد دیگری نیز نیازمند انواعی از نگهداری هستند که فقط مختص خود آنهاست. از آنجایی که مدل‌های یادگیری ماشین در تعامل مستقیم با دنیای بیرون هستند و دقت آنها تابعی از رفتار محیط است، در صورت بروز تغییراتی در رفتار محیط امکان کاهش دقت این سیستم‌ها وجود دارد که نیازمند نگهداری و توجه است. به مجموعه تغییرات محیط که باعث کاهش دقت مدل‌ها می شود، دریفت (Drift) می‌گویند که به دسته های مختلفی، مثل Data Drift که شامل تغییر توزیع داده‌های ورودی مدل است، و یا Concept Drift که به تغییر رابطه ورودی مدل با خروجی قابل انتظار مربوط می‌شود، تقسیم‌بندی می‌شوند. در صورت بروز Drift سیستم نیازمند تغییراتی است تا دقت سیستم حفظ شود. مهمترین و سرراست ترین کاری که در زمان بروز دریفت می‌توان انجام داد، آموزش مجدد مدل با داده‌های جدیدتر است (Retraining). در سیستم پیشبینی ETA ما هم بروز دریفت‌های مختلف مثل تغییرات پترن ترافیکی به دلایل مختلف مثل بازگشایی مدارس در مهرماه یا تغییرات ترافیکی در روزهای بارانی یا برفی و یا هر پدیده از قبل پیش‌بینی نشده‌، باعث کاهش دقت مدل می‌شد که علاقمند بودیم با توسعه یک سیستم اتوماتیک، این دریفت‌ها را تشخیص دهیم و قبل از آنکه دقت مدل به حد غیر قابل قبولی برسد، اقدامی در جهت تطبیق سیستم با شرایط به وجود آمده انجام دهیم.برای توسعه این سیستم پس از مطالعه و بررسی روش‌ها و ابزار‌های مختلف تصمیم گرفتیم که از ابزار DeepCheck که راه‌حل های مختلفی برای تشخیص انواع دریفت در اختیار قرار‌ می‌داد، استفاده کنیم. معماری این سیستم به این شکل بود که در هر ساعت، یکبار داده‌های موجود این ساعت با داده‌های همین ساعت در هفته‌های گذشته مقایسه می‌شد و یک متریک Drift Score در سیستم مانیتورینگ ثبت می‌شد. اگر در یک بازه زمانی مشخص تعداد مشخصی از Drift Score ها از حد آستانه‌ای بیشتر بود، سیستم مانیتورینگ یک Alert تولید می‌کرد تا تیم فنی از بروز Drift مطلع شود و اقدام لازم را انجام دهد.سیستم آموزش اتوماتیکدر سیستم‌های بالغ یادگیری ماشین یکی از متریک‌ها برای ارزیابی کارایی سیستم، زمان مورد نیاز برای آموزش یک مدل تا Deploy کردن مدل آموزش دیده است. در سیستم پیش‌بینی ETA هم علاقمند بودیم در کمترین زمان بتوانیم مدلی را آموزش دهیم. به این منظور کدبیس ماژولار شده ای که در بخش‌های قبل ذکر کردیم را به عنوان یک DAG که مخفف (Directed Acyclic Graph) است در سرویس Apache AirFlow که یک Workflow Orchestrator برای مدیریت کردن اجرای تسک‌های مختلف است، درآوردیم. با این کار کل فرآیند Retrain کردن مدل با زدن یک دکمه اجرا می‌شد و نتایج داخل ابزار Experiment management ما که یک سرویس MLFlow بود ذخیره ‌می‌شد. توسعه این DAG به ما امکان Retrain کردن اتوماتیک، در بازه‌های زمانی مشخص مثلا هفته‌ای یک بار و یا بر اساس یک رویداد مشخص، مثل اعلام آلرت از سمت سیستم تشخیص دریفت را می‌داد. با توسعه این سیستم و اتصال آن به سیستم تشخیص دریفت مطمئن شدیم که مدل همواره می‌تواند خود را به سرعت با شرایط مختلف سازگار نگه دارد و از طرفی اگر قرار بود به هر دلیلی مدل را آموزش دهیم به جای صرف مدت زیادی از زمان نیروی فنی برای جمع آوری داده، آموزش مدل و ارزیابی آن، صرفا با زدن یک دکمه فرایند آموزش را اجرا می‌شد.بلوغ سیستم سروینگهمانطور که قبلتر شاره کردیم در فاز اولیه سیستم serve کردن مدل‌های آموزش دیده، یک سیستم بسیار ساده بود. با بلوغ سیستم، بروز نیازمندی‌های جدیدی مثل نیاز به تعامل API با دیگر سیستم‌ها مثل سیستم آموزش اتوماتیک و یا نیاز به Serve شدن تعداد بیشتری مدل که در شرایط گوناگون نیاز به اجرا داشتند، باعث شد تا در این فاز سعی کنیم سیستم سروینگ را بهبود دهیم. در این مرحله یک کد Extendable برای افزودن انواع مدل‌ها با انواع پیش‌پردازش‌ها توسعه داده شد تا بر اساس شرایط مختلف بتواند، مدل‌ها با کانفیگ‌های مختلفی را اجرا کنند. از طرف دیگر، امکان Serve چندین مدل به طور همزمان به این سرویس اضافه شد و همچنین با افزودن چندین endpoint سعی کردیم تعامل این سرویس با اجزای دیگر سیستم را برقرار سازیم.پایپلاین آموزش اتوماتیکدستاورد‌هابا توسعه ماژول‌هایی که در بخش قبل ذکر کردیم موفق شدیم:مدت زمان آموزش تا Deploy یک مدل را از حدود ۱ روز، به ۲ ساعت کاهش دهیم.هزینه نیروی مهندسی برای کار‌های تکراری، مانند Retrain کردن مدل‌ها را به حداقل برسانیم و تمرکز نیرو‌های متخصص را بر توسعه روش‌های جدید و بهبود کلی سیستم نگه‌ داریم.مشاهده پذیری (Observability) سیستم را با مانیتور کردن مداوم رفتار مدل و رفتار محیط بهبود ببخشیم.در پاسخگویی به تغییرات چابک‌تر باشیم.امکان تست سریع ایده‌های جدید را داشته باشیم.دانش انباشته از آزمایشات مختلف را به طور منظم نگهداری کنیم.و در مجموع یک سیستم یادگیری ماشین قابل اتکا، قابل نگهداری و مقیاس پذیر را توسعه دهیم.مسیر پیش رودر ادامه مسیر برای بلوغ بیشتر این سیستم سعی داریم تا پایپلاین‌های داده‌های ورودی برای آموزش و inference را بهینه و غنی کنیم که در این راستا استفاده از تکنولوژی‌های feature store را در دست بررسی داریم. همچنین استفاده از inference server ها برای serve کردن مدل‌ها با قابلیت‌های بیشتر مثل امکان A/B Testing، Canary Testing، auto scaling و batch inference را در دست بررسی داریم که در این راستا، در حال تست ابزار‌هایی مثل Seldon و KServe هستیم.جمع بندیدر این مقاله سعی کردیم روایتی از یک مسئله واقعی یادگیری ماشین و چالش‌های استفاده آن در محیط‌های پروداکشنی حساس را بیان کنیم و رویکرد ما نسبت به حل مشکلات و چالش‌ها را شرح دهیم. امیدواریم در ادامه بتوانیم از این دست از مقاله‌ها که چالش‌هایی کمتر پرداخته شده، در حوزه یادگیری ماشین و علوم داده را عنوان می‌کند را بیشتر منتشر کنیم.در انتها از همه اعضای تیم فنی و پروداکت تیم ETA Enabling نقشه اسنپ تشکر می‌کنم که با تلاش و انرژی همیشگی ساخت یک سیستم قابل اتکا را ممکن کردند.سهیل کوهیسهیل کوهیMon, 07 Apr 2025 12:41:07 +0330https://virgool.ir/@soheil.koohi/machine-learning-open-source-p8lrsemocldiفرض کنید به عنوان یه مهندس یادگیری ماشین موفق شدید با کلی تلاش و جلسات مختلف و سر و کله زدن با کارفرما‎ها، یه پروژه بگیرید که مربوط به تشخیص الفبای زبان اشاره از روی تصویره. کارفرما به شما میگه دیتای خاصی برای این کار نداره و از صفر تا صد پروژه رو باید خودتون انجام بدید. سخت شد نه؟توی کورس های دانشگاهی یا آنلاین ماشین لرنینگ روند کار اینجوریه که یه سری دیتاست تر و تمیز بهمون میدن و ما هم به لطف Google Colab به یه سری GPU خوب دسترسی داریم و یکی از مدل های معروف مثل ResNet رو انتخاب میکنیم و باهاشون مدلمون رو ترین می‌کنیم. ولی وقتی این ماه عسل تموم میشه و وارد فضای کار می‌شیم، با این واقعیت تلخ روبرو می‌شیم که خیلی از پروژه‎‎‌های واقعی اینجوری نیستن. یعنی یا اصلا دیتایی موجود نیست یا میزان دیتای در دسترس خیلی کمه. البته این موضوع خیلی طبیعیه، چون هزینه گردآوری دیتا زیاده و پیچیدگی های خاص خودش رو داره، و عموما شرکت ها توی فاز اولیه صرفا دنبال اینن که ببینن ایدشون کار میکنه و ماشین لرنینگ می‌تونه راه‌حلی بهشون ارائه بده یا نه، و همچین هزینه هایی رو برای چیزی که ازش مطمئن نیستن نمیپردازن.خب حالا توی این شرایط فرضی اولین راه حلی که به ذهن شما میرسه چیه؟ طبق چیزایی که توی دانشگاه و کورس های مختلف بهمون یاد دادن مهندس ماشین لرنینگ یا دیتا ساینتیست کسیه که نشسته صبح تا شب داره مدل ترین (train) میکنه، هایپرپارامتر‌ها (hyperparameters) رو دست کاری میکنه و کارای این تیپی تا به یه مدل خوب برسه. حالا ما که دیتا نداریم چیکار می‌کنیم؟ خب واضحه دیگه، میریم توی اینترنت سرچ میکنیم ببینیم دیتایی برای مسئله ما هست یا نه؟ خوشبختانه برای پروژه ای که گرفتیم یعنی تشخیص الفبای زبان اشاره یه سری دیتاست پیدا میکنیم که میشه ازش استفاده کرد. ایول! ولی یه لحظه صبر کنید، بیاید با هم یکم دقیق‌تر این فرآیند رو بشکافیم.خب ما یه سری دیتاست پیدا کردیم. کار بعدی اینه که یه مدل پیدا کنیم که بشه این دیتا رو روش ترین (train) کرد. اونم کار زیاد سختی نیست (حداقل برای مسئله ما). هر کلسیفایر عمومی ای مثل ResNet یا VGG احتمالا مناسبه. حالا باید دیتاست‌ها رو طوری که مدل انتظار داره مرتب کنیم. مثلا یه سری مدل ها دیتا رو توی یه سری فولدر، که هر فولدر معرف یه کلاسه، میگیرن. یه سری دیگه نه، باید یه فایل تکست بهشون بدی که توش آدرس هر دیتا و لیبلش رو مشخص کرده باشیم. یا هزار مدل دیگه. حالا چالش بعدی یک دست کردن دیتاست های مختلفه. مثلا یه دیتاست عکساش سیاه سفیده، یه دیتاست دیگه رنگی. یا حتی یه دیتاست پیدا کردیم که جای عکس، ویدئو رو لیبل زدن. حالا با هزار بدبختی اینارو تبدیل به یه دیتاست تجمیع شده کردیم و بالاخره ترین رو شروع کردیم. کلی آزمایش باید بکنیم، هزار تا فرضیه رو تست بکنیم، تا به یه مدل نسبتا قابل قبول برسیم.کافیه این پلن رو به کارفرما بگیم تا تمام موهای سر و تنش بریزه. حق هم داره، اون ما رو استخدام کرده تا مثلا توی نهایت یک ماه به یه راه حل اولیه برسیم ولی الان پلنی که ما داریم میذاریم جلوش سه یا چهار ماه کار تمام وقته.خب دوستان اینجا باید این واقعیت تلخ رو بهتون بگم که توی پروژه های دنیای واقعی وقت خیلی کمه و این دید که من به عنوان یه مهندس یادگیری ماشین کارم فقط ترین کردن مدل و این چیزاست خیلی وقتا جواب نمیده.پس چیکار باید بکنیم؟شغلمون رو عوض کنیم؟با مشتری سر و کله بزنیم؟دست به خشونت بزنیم؟هوش مصنوعی همه اش یه دروغه؟نه یه لحظه صبر کنید!تقریبا من میتونم با اطمینان زیاد بهتون بگم که درصد زیادی از مسئله هایی که به ما می‌سپرند، چه طبقه بندی باشه، Object detection باشه، Activity recognition باشه یا هر چیز دیگه ای، قبل از ما کلی آدم دیگه سعی کردند حل کنند و راه حل هاشون و مدل های ترین شده رو سخاوت‌مندانه با ما به اشتراک گذاشتند. کافیه برای هر موضوعی که بهش علاقمندید بریم توی گیتهاب یه سرچ بکنیم تا با دنیایی از پروژه ها و راه حل ها روبرو بشیم.مثلا برای همین مثالمون، من رفتم توی گیتهاب عبارت "Sign Language Recognition" رو سرچ کردم. همونطوری که می‌بینید نزدیک 1000 تا پروژه هست که یا دقیقا مربوط به همین موضوعه، یا مرتبطه باهاش.خب پس تا اینجا فهمیدیم که نیاز نیست چرخو دوباره اختراع کنیم، کارفرما رو دیوونه کنیم و خودمون رو از کار بی‌کار کنیم.ولی سوالی که اینجا باز به وجود میاد اینه که خب از بین این هزار تا پروژه، کدومش مناسب کار منه؟کل چیزی که من میخوام توی این پست بگم دقیقا همینه. که از بین این همه پروژه اوپن سورس چجوری یکی یا چند تاشونو انتخاب کنیم که هم کارمون راه بیوفته، هم وقتمون با سر و کله زدن با پروژه های به درد نخور هدر نره، و هم اینکه یه چیزی یاد بگیریم از کار کردن با یه پروژه خوب.مطلبی که در بالا درباره راه حل پیشنهادی و قبول نکردن کارفرما گفتم یک تجربه واقعی از یکی از پروژه های قبلیم بود و مطالبی که در ادامه میخونید هم حاصل 4-5 سال سر و کله زدن من با پروژه های اوپن سورسه. جا داره اینجا بگم که همه این پیشنهادات صرفا از تجربیات شخصی من میاد و هیچ کدومش وحی مُنزل نیست.کجا دنبال این پروژه ها بگردم؟من سایت هایی که می‌تونید ازشون برای پیدا کردن پروژه های اوپن سورس استفاده کنید رو دو بخش میکنم: سایت هایی که فقط مدل های pretrained ارائه میدن (یا model zoo ها)سایت هایی که پروژه های کامل از کد گرفته تا مدل رو ارائه میدندسته اول چند تا سایت و سرویس خیلی خوب براشون هست که لیستش رو اینجا میارم:TensorFlow HubHuggingface modelsmodelzoo.coسایت TensorFlow Hub توجه کنید که این سایت ها فقط یه سری مدل از پیش آموزش دیده (Pretrained) رو به همراه یه اسکریپت یا یه نوت بوک که بتونید مدل رو برای ورودی مورد نظر ران کنید در اختیار قرار میدن و برای تست های اولیه خوبن.ولی اگه دنبال یه سری پروژه کامل هستید که کد های ترینینگ داشته باشن بهتره به سایت‌های دسته دوم سر بزنید:Papers with CodeHugging FaceGitHubمن خودم برای هر پروژه اولین جایی که سر می‌زنم Papers with Code هستش. این سایت یه دسته بندی خیلی خیلی مفصل و جذاب داره و برای هر موضوعی یه سری جدول و نمودار ارائه میده که نشون میده هر مقاله چه دقتی رو داره و نسبت به بقیه رقبا چند مرده حلاجه. از طرف دیگه هم خود مقاله‌ها رو در اختیار قرار میده، و هم یه لیست از همه پیاده سازی های هر مقاله داخل گیتهاب.سایت Papers with Codeخب تا اینجا فهمیدیم از چه منابعی میشه پروژه های ماشین لرنینگی رو پیدا کرد. حالا برگردیم به سوال اولمون چجوری بین 20-30 تا پروژه که مربوط به کار ماست بتونیم 2-3 تا رو انتخاب کنیم؟ معیار های اولیهوقتی مثلا توی یه سایتی مثل گیتهاب یا Papers with Code دارید دنبال پروژه می‌گردید، خوبه که به چند تا نکته اولیه توجه کنید. اول اینکه اگه یه پروژه ای پیاده سازی یه مقاله است، خوبه که چکیده مقاله رو بخونید تا بفهمید چقدر راه حلی که ارائه میده به درد مسئله شما میخوره. مثلا توی همین مثال خودمون، یه سری ها روی تشخیص زبان اشاره از روی ویدئو کار میکنن، یه سری روی عکس های تکی. یا یه سری زبان اشاره یه کشور خاص رو روش کار کردن که ممکنه به کار شما نیاد. پس حتما توجه کنید که اون پروژه چه مسئله ای رو حل کرده و روی چه دیتایی کار کرده.معیار بعدی جدید بودن مقاله است، البته این میتونه یه جاهایی نقض بشه ولی خب بر اساس یه قانون من درآوردی پروژه هایی که مال بیشتر از 3-4 سال قبل هستن احتمالا به کار نیان و پروژه های جدیدتر شانس بیشتری دارن که مسئله مارو بهتر و دقیق تر حل کنن.معیار بعدی میتونه دقتی که مقاله ریپورت کرده باشه. اینجا Papers with Code خیلی به کمک ما میاد. توی این سایت یه سری جدول و نمودار هست که مقاله ها و پروژه های مختلف رو بنچ مارک کرده. اونجا خیلی راحت میتونید پروژه‌ها رو با هم مقایسه کنید.بنچ مارک سایت Papers with Code برای یکی از تسک های تشخیص زبان اشارهاقبال کامیونیتییه موضوع مهم دیگه اینه که از تجربه بقیه افراد برای انتخاب پروژه استفاده کنید. یعنی بعد از اینکه با معیار های قسمت قبل مثلا 7-8 تا پروژه رو انتخاب کردید برید توی صفحات گیتهاب اون پروژه ها و تعداد star ها، تعداد fork ها و تعداد pull request های پروژه ها رو با هم مقایسه کنید. اینها معیار های خوبی هستند که ببینید آدم های قبلی ای که از این پروژه ها استفاده کردن چقدر راضی بودن.پاسخگو بودن گردانندگان پروژهیه نکته خیلی مهم که ممکنه در نگاه اول به چشم نیاد اینه که چقدر گردانندگان اون پروژه نسبت به سوالات و مشکلاتی که کاربر‌ها بهش برمی‌خورند پاسخگو هستند. بررسی این مسئله دو چیز رو تضمین میکنه: اول اینکه فیدبک‌های کاربرها مورد توجه قرار گرفته و مشکلات احتمالی اولیه حل شده و دوم اینکه اگر شما هم در طول کار کردن با اون پروژه به مشکل یا سوالی بر بخورید میتونید امیدوار باشید که جوابتون رو میگیرید.پس یه سری به صفحه Issues اون پروژه بزنید و ببینید میزان پاسخگویی به سوالات و مشکلات چقدر بوده.دسترسی به مدل pre-trained و کدهای trainingدو تا چیز مهم هست که خوبه توی README پروژه دنبالش بگردید اول این که آیا مدل های آماده رو در دسترس قرار دادند یا نه؟ و بعد هم آیا کد برای ترین کردن مدل روی دیتاست های شخصی موجود هست یا نه؟ بودن این دو تا به شما کمک میکنه که هم بتونید بدون نیاز به ترین کردن و دسترسی به سخت افزار قوی صرفا مدل های از پیش ترین شده رو روی دیتای خودتون آزمایش کنید، تا ببینید اصلا این پروژه به درد شما میخوره یا نه، و همچنین با وجود کد های ترینینگ میتونید بعدا اگر خواستید با دست باز، این مدل رو روی دیتاست اختصاصی خودتون ترین کنید و یا هر تغییری که دوست داشتید رو اعمال کنید.بررسی وجود مدل pretrained و کد training در یک پروژهداکیومنتیشن کاملموضوع بعدی که واقعا مهمه و اگه بهش توجه نکنید در طول کار کردن با پروژه خیلی اذیت می‌شید اینه که آیا این پروژه داکیومنتیشن خوبی داره یا نه؟کافیه چند خط یا پاراگراف از README رو بخونید و ببینید باهاش ارتباط برقرار میکنید یا نه؟ آیا نحوه استفاده از همه بخش های پروژه واضح بیان شده یا نه؟یه کار خوبی که یه سری از پروژه ها جدیدا می‌کنند اینه که یه جوپیتر نوت بوک داخل پروژه میذارن که نحوه استفاده از بخش های مختلف به همراه دستورات مورد نیاز رو اونجا میذارن و کافیه شما فقط با همون نوت بوک کار کنید و مراحل رو به ترتیب اجرا کنید. اگه یه همچین چیزی دیدید توجه ویژه ای به اون پروژه بکنید چون کار کردن باهاش خیلی ساده است.ساختن environmentیه مرحله خیلی مهم توی استفاده از یه پروژه دقیقا همون اول ماجراست، یعنی جایی که شما می‌خواید پکیج های مورد نیاز پروژه رو نصب کنید و در واقع environment پروژه رو بسازید. بسته به اینکه سازندگان پروژه چقدر به این موضوع بها داده باشند این مرحله میتونه برای شما در یک چشم به هم زدن انجام بشه و یا تبدیل به کابوس شبهاتون بشه و یهو به خودتون بیاید و ببینید روزهاست فقط درگیر نصب پکیج ها و متعلقاتشون هستید، بدون اینکه اصلا بدونید این پروژه برای مسئله شما خوب هست یا نه.حتما توی README دنبال پکیج های پیش نیاز پروژه بگردید. ببینید هر پکیج به همراه ورژن مورد نیازش قید شده یا نه. اگر پروژه فایل requirement.txt داشته باشه خیلی خوبه. ازون بهتر اگه پروژه Docker file داشت بدونید که شانس باهاتون یار بوده و بچسبید به اون پروژه و ولش نکنید.لایسنسآخرین معیاری که میخوام راجع بهش حرف بزنم درسته در آخر بیان شده، ولی واقعا یکی از مهم ترین هاست. چه از نظر اخلاقی و حرفه ای، و چه از نظر بیزینسی حتما قبل از استفاده از پروژه لایسنس اون پروژه رو مطالعه کنید. همه پروژه هایی که توی گیتهاب هستند، هم یه فایل LICENCE دارن و هم سمت راست صفحه نوع لایسنسشون قید شده. درسته که ما توی ایران خیلی به مسائل مالکیت معنوی و کپی رایت توجهی نمی‌کنیم ولی در نظر بگیرید که اگه کارفرماتون خارج از کشوره و یا می‌خواد محصولش رو در خارج از کشور عرضه کنه، موضوع لایسنس بسیار بسیار بسیار مهم میشه و اگر بهش توجه نکنید، میتونه همه زحمت هاتون رو خراب کنه و شما رو یه آدم غیر حرفه ای نشون بده. از طرف دیگه از لحاظ اخلاقی هم مهمه که به حق مالکیت اشخاص اهمیت بدید.یه سری لایسنس هستند که اگه اونارو دیدید با خیال راحت هر کاری خواستید با پروژه بکنید؛ مثل لایسنس Apache یا MIT. ولی یه سری لایسنس هستند که استفاده تجاری از اون پروژه رو بدون دریافت مجوز از صاحبان پروژه منع می‌کنند. در مجموع سعی کنید قبل از کار کردن با هر پروژه لایسنس اون پروژه رو مطالعه کنید و در جریان محدودیت های استفاده ازش قرار بگیرید و این موضوعات رو به کارفرماتون منتقل کنید.نوع و فایل لایسنس در یک پروژه گیتهابو در آخرنکته پایانی ای که خیلی وقت ها من رو اذیت کرده اینه که یه سری از پروژه هایی که از طریق دانشگاه ها تولید میشن خیلی از ملاحظات دنیای عملی رو رعایت نمی‌کنند. مثلا داکیومنت های مناسبی برای پروژه نمی‌نویسند، یا سوالات رو جواب نمیدند و باگ ها رو برطرف نمی‌کنند. واسه همین اگه یه مقاله خوندید که بهترین نتایج قرن رو گرفته بود، یا بدیع ترین ایده ها رو توش داشت فکر نکنید که این بهترین پروژه برای کار منه. توجه داشته باشید که خیلی از نکات عملی که در بالا گفتم می‌تونند خیلی خیلی مهم تر از دقتی باشند که یه مقاله گزارش کرده.همیشه سعی کنیم وقتی کارمون با یک پروژه تموم شد، اگر ازش راضی بودیم حتما بریم به صفحه گیتهاب پروژه و بهش star بدیم. اگر ایمیلی از گردانندگان اون پروژه موجود بود، بهشون ایمیل بزنیم و تشکر کنیم و تجربه استفاده از پروژشون رو باهاشون در میون بذاریم. همچنین اگر باگی در پروژه پیدا کردیم و خودمون حل کردیم، و یا فیچری به پروژه اضافه کردیم اونو در قالب یه Pull Request برای پروژه ارسال کنیم تا بقیه هم از کار ما بهره‌مند بشن. این کارها باعث میشه فقط مصرف کننده نباشیم و خودمون هم در جهت بهبود پروژه ها گامی برداریم.کلام پایانیبه نظر من توی دنیای امروز که علم به راحتی در اختیار همگان هست یکی از مهمترین هنر‌هایی که هر کدوم از ما به عنوان یه مهندس یادگیری ماشین یا دیتا ساینتیست باید داشته باشیم، انتخاب بین پروژه هاییه که بقیه توسعه دادند و استفاده از اونها به بهترین شکل برای مسئله و کار خودمونه.من توی این پست سعی کردم تجربیات خودم رو توی این حوزه باهاتون در میون بذارم. امیدوارم برای کسایی که دغدغشون بوده مفید بوده باشه. اگر دوست داشتید شما هم تجربیاتتون رو زیر این مطلب با من و دوستان در میون بذارید.سهیل کوهیسهیل کوهیSun, 17 Apr 2022 16:04:06 +0430https://virgool.ir/dataio/در-باب-هوش-مصنوعی-با-شلوارک-یا-چرا-قرنطینه-را-دوست-دارم-te5ewlpjxqldیک روز عادی توی زمستونه، ساعت ۹ صبح از خواب بیدار میشم، دیشب قبل خواب دو تا فرضیه جدید درباره بهبود دقت مدلی که دارم روش کار میکنم به ذهنم رسیده، بی نهایت ذوق دارم تا تستشون کنم و نتیجه اش رو ببینم. با انرژی زیاد از تخت پا میشم تا زودتر حاضر شم و برم سر کار. تو این لحظه یه چیزی یه لحظه میاد تو ذهنم. یادم میوفته فاصله خونم تا شرکت ۱۵ دقیقه پیاده روی، یه کورس تاکسی و ۱۸ ایستگاه متروئه. یعنی به زبون ساده تر هر لحظه ای که تصمیم بگیرم برم سر کار یا از شرکت برگردم خونه ۱ ساعت و نیم از عمرم رو باید تلف کنم. یکم اون شوق اولیه ام از بین رفته، یه صدای دیگه ای تو مغزم میگه بیخیال، هرچی باشه تو عاشق محل کارتی، همکارات مثل دوستای صمیمیت هستند، کلی بهت خوش میگذره اونجا و از همه مهمتر تو فقط توی اون فضا میتونی کار کنی، اگه بشینی تو خونه و زور بالا سرت نباشه عمرا کار نمیکنی و گند میزنی تو زندگیت. یکم فکر میکنم به صدای تو مغزم، وقتی به خودم میام میبینم توی مترو نشستم و خداروشکر ۱۰ تا ایستگاهو پست سر گذاشتم و فقط و فقط ۸ تا ایستگاه مونده تا برسم سر کار و تازه روزم رو آغاز کنم...چیزی که بالا تعریف کردم داستان زندگی خیلی از روز های من و شاید خیلی از ماهاییه که توی یه شهر بزرگ زندگی می‌کنیم و زمان زیادی از زندگیمون رو در رفت و آمد از خونه به محل کاریم. این حس‌های دوگانه‌ی خستگی از یه طرف و لذت محیط کار از طرف دیگه همیشه در من در جدال بودند تا وقتی که تقریبا از یک ماه پیش این بلای کورونا نازل شد و تیم مدیریتی شرکت ما تصمیم گرفت به کارمند ها امکان ریموت کار کردن رو بده و این آغاز یه حس دوگانه جدید درون من بود...توی لحظه اول خیلی خوشحال شدم که توی این شلوغی های آخر سال دیگه نیاز نیست هر روز از خونه برم بیرون و با کلی خستگی شب برگردم خونه، ولی کم کم یه ترس درونم قوت گرفت که آقا جان! تو که توی خونه کار نمیکنی، آخرشم قبل اینکه این بیماری رو از کشور بیرون کنن تو رو از کارت بیرون میکنن! حقیقتا هم تا حد زیادی به این بخش از ذهنم حق میدادم چون همه این ترس ها از تجربیات دوران دانشگاه و مدرسه میومد که هیچوقت نتونسته بودم یه برنامه رو درست توی خونه اجرا کنم.خلاصه با همه این ابهام ها الان بعد از یک ماه از این تجربه عجیب و غیر منتظره نکات جالبی از این مدل از زندگی کردن یاد گرفتم که دوست دارم با شماها هم در میون بذارم.تنبلی یا تعهد، کدام پیروز است؟خب مشکلاتی که من با مدیریت زمان و بازدهیم سر کار داشتم چند دسته بود، اولیش اینکه من چند تا کار رو همیشه همزمان باید انجام بدم که فضاهاشون خیلی خیلی از هم دور هست خیلی از مواقع، مثلا هم باید کد بزنم، هم با یه تعدادی آدم مصاحبه کنم، هم مقالات فنی بخونم، هم توی جلسات استراتژیک شرکت باشم و هم با مشتری ها جلسه داشته باشم. این باعث میشد که خیلی از وقت ها زمان کم بیارم و مشکل context switching داشته باشم، یعنی یه زمان زیادی طول میکشید تا بتونم از یک موضوع به یک موضوع دیگه برم و روی کار بعدی تمرکز کنم. یک مشکل اساسی دیگه هم این بود که در زمان های حضورم توی شرکت عوامل حواس پرت کن زیادی وجود داشت که باعث میشد نتونم روی کارهام تمرکز کنم، مثلا خیلی پیش میومد که درگیر کارهایی می‌شدم که لزوما به من ربطی نداشت، مثلا درگیر مسائل بقیه بچه ها شدن به خاطر کنجکاوی خودم یا خیلی وقت ها صداهای پس زمینه، مثل حرف زدن دو نفر ذهنمو درگیر میکرد. خلاصه که این مشکلات رو فقط وقتی فهمیدم که مجبور شدم توی خونه کار کنم.توی خونه که بودم به طرز عجیبی دیدم دیگه هیچکدوم ازین حواس پرتی ها وجود نداره و میتونم خیلی راحت مدت زیادی روی کارم متمرکز بمونم (خصوصا شب‌ها). از یک طرف هم دیگه محدود به ۸ ساعت زمان کاری نبودم و میتونستم از هر ساعتی که از خواب بیدار میشم تا هر وقت که میخوام بخوابم کار کنم، مثلا این آپشن رو داشتم که صبح ها رو به کار های غیر فنی اختصاص بدم، بعد ظهر ها یکم کار شخصی کنم، عصر ها رو با آدم ها مصاحبه کنم، بعد با خانواده وقت بذارم و در نهایت شب ها که همه خوابن و تمرکز بیشتری دارم کد بزنم. با این روش دیگه اون مشکل تغییر بین کارهای مختلف رو نداشتم و بین هر کدوم میتونستم یه زمانی رو کار نکنم و ذهنم رو آزاد کنم از موضوع قبلی.این آزادی عمل رو فقط این مدل کار کردن به من میداد، چون زمانی که سر کار میرفتم فقط همون ۸ ساعت رو وقت داشتم که کار کنم و بقیه زمان هارو یا «باید» به جنبه های دیگه زندگیم اختصاص میدادم یا حتی اگر میخواستم هم انقدر خسته از رفت و آمد و ۸ ساعت روی یه صندلی نشستن بودم که جونی برای کار نداشتم.مشکلی که اولش ازش میترسیدم یعنی تنبلی و عقب انداختن کار ها هم به طرز عجیبی وجود نداشت و حتی برعکس هم بود یعنی زمانی که توی این شرایط جدید به کار اختصاص می‌دادم به مراتب بیشتر از وقتی بود که سر کار می‌رفتم. به دلایلش که فکر کردم اول این به نظرم رسید که خب الان چون یک مسئولیت جدی و مهم دارم شاید ذهنم اجازه نمیده که از زیر کار در برم یا شاید دیگه از اون بازیگوشی های اوایل جوانی فاصله گرفتم و همین کار کردن هم وقت‌های زیادی برام یه جور تفریحه. ولی خب اینا همش یه جنبه دیگه هم داره و اونم اینه که بخاطر شرایط خاص این روز‌ها خیلی گزینه خاصی برای تفریح هم وجود نداره و محکومیم که همه‌ی وقتمون رو توی خونه بگذرونیم. در نهایت ولی همینکه تونستم خودم رو کنترل کنم و وظایفم رو سر زمان و با کیفیتی که خودم رو راضی میکنه انجام بدم دستاورد ارزشمندی بود.موازنه زندگی کاری و زندگی شخصی، بندبازی در ارتفاع ۳۰۰ متری!بیاین این ساعت ها رو باهم جمع بزنیم: ۹ ساعت کار روزانه، ۳ ساعت رفت و آمد، ۸ ساعت خواب. خب چند ساعت شد؟ آفرین ۲۰ ساعت. یعنی در هر شبانه روز من فقط ۴ ساعت وقت دارم که به «همه» مسائل شخصیم رسیدگی کنم. حالا این مسائل میتونه تفریح باشه، میتونه وقت گذاشتن برای خانواده باشه یا دیدن دوستان و بقیه عزیزان باشه یا حتی انجام یه پروژه شخصی باشه. خب شمام اگه مثل من آدمی باشید که همه زندگیتون فقط کار نباشه و علاقمند باشید که به بقیه جنبه های زندگی هم توجه کنید، حتما میدونید که برقرار کردن توازن بین کار و زندگی شخصی چقدر سخته، چقدر نیاز به برنامه ریزی داره و از طرف دیگه چقدر نیاز به از خود گذشتگی آدم‌های اطرافتون داره.یعنی اگه مثل من آدم خوشبختی باشید که خانوادتون درک این رو داشته باشه که شما به تفریح با دوستان هم نیاز دارید و دوستانتون هم متوجه باشن که شما درگیر کار و بقیه موارد زندگیتون هستید و همش ازتون گله‌مند نباشن، شاید بتونید با یه برنامه ریزی دقیق در طول هفته یه تایمی رو به همه اینها اختصاص بدید و احتمالا هم این تایم شخصی در پایین ترین سطح انرژی شماست و فقط حس خستگی براتون میمونه و به طور قطع از خیلی از کار ها که نیازمند تمرکز و انرژی هستند (مثل انجام پروژه های شخصی) باز می‌مونید. در ضمن کافیه که چند وقت این برنامه ریزی از دستتون در بره، اونوقت به سرعت برق و باد میبینید که مدت هاست از خیلی از جنبه های زندگیتون عقب افتادید. حالا اتفاقی که توی این دوران قرنطینه افتاد یکی این بود که دیگه اون ۳ ساعت از زمان روزمره‌ام صرف رفت و آمد نمیشد و چیز دیگه هم اینکه زمان کار کردنم تا حد خیلی زیادی دست خودم بود (به جز زمانی که جلسه داشتم و باید با بقیه هماهنگ میبودم.) یعنی مثلا میتونستم شب ها که خانواده خوابن یه سری از کارهامو بکنم درعوض زمان‌هایی که همه دور هم جمع هستند رو باهاشون وقت بذارم، یا بین کارم خیلی راحت برم دو تا از دوستام رو ببینم و برگردم. (البته با رعایت موارد بهداشتی و در یکی دو هفته اول قرنطینه که خودم هم خیلی جدیت شرایط رو درک نکرده بودم.) خلاصه که این افزایش زمان و همچنین منعطف بودن استفاده ازش باعث شد اون فشار زیادی که درباره رسیدگی به کارهای شخصیم بود از روی دوشم برداشته بشه و هم بتونم اوقات شخصی و فراغت با کیفیت تری داشته باشم و هم کارم رو با خیال راحت انجام بدم.همه اش همین؟!خب تا اینجا به تاثیراتی که این سبک زندگی جدید توی زندگی کاری و شخصی من داشت پرداختم، ولی در طول روزمره که به چیزای مختلف توجه میکنم میبینم مسائل ریز دیگه ای هم هست که تحت تاثیر این مدل زندگیمون قرار گرفته.مثلا بعد از یک مدت به طرز عجیبی دیدم که حساب بانکیم هیچ تکونی نمیخوره، خب دلیلش هم خیلی واضحه، یکی بحث هزینه های رفت و آمد که حذف شده و یک بحث دیگه هم اینه که خب وقتی شما بیرون نرید خرجی هم نمیکنید قائدتا! حالا این مسئله بخش زیادیش تحت تاثیر این وضعیت خاصه که همه جا تعطیله، غذا از بیرون نمیشه خرید و با دوستان نمیشه تفریح کرد. ولی نکته دیگه ای که برای من داشت این موضوع این بود که خب بدون خیلی از این خرج ها هم میشه زندگی با کیفیتی داشت و از طرفی بخش زیادی از درآمد رو میشه پس انداز کرد.یا مثلا یه نکته مهم دیگه این بود که من تونستم یه جورایی مراقبه بکنم توی خیلی از مسائل، از پایبند بودن به برنامه کاری گرفته تا سیگار نکشیدن و خیلی از رفتار های دیگه که توی این شرایط باید رعایت کنیم، یعنی یک جورایی همه اینا یه تمرین بود برای من تا یکم به زندگیم نظم بدم و از اون حالت قبلی که هر کاری دوست داشتم میکردم، یک مقدار فاصله بگیرم.یا یه مسئله دیگه که شخصی هم نبود این بود که با گسترش این بیماری ما تونستیم به خیلی از منابعی که تا قبل از این بخاطر تحریم یا هزینه های زیاد ازش بی بهره بودیم، استفاده کنیم. مثلا خیلی از کنفرانس های تخصصی به خاطر این بیماری کنفرانس رو زنده توی اینترنت پخش کردن یا خیلی از سایت های آموزشی یه سری دور هاشون رو رایگان کردن، یا خیلی از موزه ها اومدن تور مجازی رایگان گذاشتن که در حالت عادی ما هیچ شانسی نداشتیم تا از این منابع استفاده کنیم.خب که چی؟؟؟همه این موضوعات رو نگفتم که صرفا یک روایت شخصی کرده باشم از این حدود یک ماهی که سبک زندگیم عوض شده. بیشتر هدفم این بود که بگم این بیماری با اینکه خیلی ها رو بیمار کرد، خیلی ها رو عزادار کرد، خیلی‌ها رو بیکار کرد و احتمالا هممون رو دلتنگ اطرافیانمون کرد، چند تا نکته خیلی مهم چه از جنبه شخصی و چه از جنبه اجتماعی داشت که توی روایتم مثال هایی ازش بود.مثلا با اینکه نفوذ اینترنت توی شهری مثل تهران به مراتب زیاده و اکثرمون چه به آسونی و چه به لطف فیلترینگ به سختی، به سرویس های ارتباطی مختلفی دسترسی داریم، ولی خیلی از فرآیند‌های کاری و سبک زندگیمون هنوز این امکانات رو توی خودش جا نداده. به عنوان مثال توی شهری که به شدت مشکل ترافیک و جابجایی وجود داره ما هنوز خیلی از جلساتمون رو «باید» حضوری برگزار کنیم و ۱۰ نفر آدم رو از شرق و غرب تا شمال و جنوب تهران یکجا جمع کنیم تا مثلا ۱ ساعت جلسه داشته باشیم. در حالی که توی این مدت دیدیم جای اینکه وقت تعداد زیادی آدم رو هدر بدیم، خیلی راحت با یک ارتباط تصویری همشون در یک لحظه کنار هم جمع میشن. یا به نظر میرسه تا حدی تابوی دور کاری کردن، هم برای کارمند ها و هم برای کارفرما‌ها داره از بین میره و هممون داریم یاد میگیریم که قوائد این مدلی کار کردن چیه. همین باعث میشه فرصت های خیلی زیادی برای کسانی فراهم بشه که تا پیش از این صرفا بخاطر بُعد مسافت از حضور در خیلی از کار‌ها و پروژه ها محروم بودن. پس نظر شخصیم اینه که تغییرات زیادی در مورد نگاه مشاغل به نحوه انجام کارها داره اتفاق میوفته، حتی در یک حالت مبالغه آمیز بعید نمیدونم در آینده نزدیک شرکت های موفقی با صدها کارمند رو داشته باشیم که هیچکدوم یکبار هم حضوری همدیگر رو نمیبینن و هر کدوم از یک نقطه از جهان برای یک هدف مشترک کار کنند. کما اینکه هین الان هم تعدادی از شرکت های بین المللی همین مدل رو تا حدی پیاده کرده اند.از جنبه شخصی هم به نظرم به هممون یادآوری شد که قوائدی که برامون مثل وَحی مُنزل بوده رو همیشه میشه یک تجدید نظری روش کرد و شاید چیزی که فکر میکنیم بهترین راه انجام یک کاره لزوما اینجوری نیست. مثلا شخصاً برای من اینجوری بود که همواره فکر میکردم بهترین عملکرد کاریم رو زمانی دارم که در محیط شرکت باشم ولی این چند وقت دیدم نه تنها توی این فضای کاری عملکردم بهتر بوده بلکه زندگی فردیم هم کیفیت بهتری پیدا کرده. پس شاید بد نباشه این ارزیابی رو هر چند وقت یکبار روی همه موضوعات زندگیمون داشته باشیم و از ریسک کردن و تجربه فضاهای جدید کمتر نترسیم.نکته مهم پایانیدر آخر حتما به این نکته توجه داشته باشید که نکات و پیشنهاداتی که مطرح کردم همگی در مورد شخص من صدق میکرد و لزوما تعمیم پذیر برای بقیه افراد و بقیه کارها نیست. چه بسا که تجربه کار با اشخاصی رو داشتم که مدت های زیادی با هم همکاری خوبی داشتیم و اشخاص منظم و حرفه ای بودند ولی به محض اینکه مدت کوتاهی همکاری به صورت دورکاری داشتیم به شدت بی نظم و بدقول بودند و تجربه های بدی رو رقم زدند.پس حتما این نکته رو توجه داشته باشیم که لازمه موفقیت در این نوع سبک زندگی، رعایت نظم، کنترل احساسات و خود ارزیابی های منظم هست و این مدل برای خیلی ها هم اصلا مناسب نیست. پس بهتره هر کدوممون سعی کنیم شیوه‌ای رو پیدا کنیم که توش موفق تریم و آدم خوشحال تری هستیم.سهیل کوهیسهیل کوهیFri, 03 Apr 2020 16:27:46 +0430