با مجموعهها، منظم بمانید ذخیره و طبقه‌بندی محتوا براساس اولویتهای شما.
آزمایش‌ها یک پروژه را به سمت دوام می‌آورند. آنها فرضیه هایی قابل آزمایش و تکرار هستند. هنگام اجرای آزمایش‌ها، هدف این است که با ارزیابی انواع معماری‌ها و ویژگی‌های مدل، بهبودهای مستمر و تدریجی ایجاد کنیم. هنگام آزمایش، می خواهید کارهای زیر را انجام دهید:
عملکرد پایه را تعیین کنید. با ایجاد یک متریک پایه شروع کنید. خط مبنا به عنوان یک چوب اندازه گیری برای مقایسه آزمایش ها با آن عمل می کند.
در برخی موارد، راه حل غیر ML کنونی می تواند اولین متریک پایه را ارائه دهد. اگر در حال حاضر راه حلی وجود ندارد، یک مدل ML با معماری ساده، چند ویژگی ایجاد کنید و از معیارهای آن به عنوان خط پایه استفاده کنید.
تغییرات کوچک و تکی ایجاد کنید. در هر زمان فقط یک تغییر کوچک ایجاد کنید، به عنوان مثال، در هایپرپارامترها، معماری یا ویژگی ها. اگر تغییر مدل را بهبود بخشد، معیارهای آن مدل به خط پایه جدیدی برای مقایسه آزمایش‌های آینده تبدیل می‌شوند.
در زیر نمونه‌هایی از آزمایش‌هایی هستند که یک تغییر کوچک ایجاد می‌کنند:
شامل ویژگی X باشد.
از 0.5 dropout در اولین لایه پنهان استفاده کنید.
تبدیل log ویژگی Y را بگیرید.
نرخ یادگیری را به 0.001 تغییر دهید.
پیشرفت آزمایش ها را ثبت کنید. به احتمال زیاد باید آزمایش های زیادی انجام دهید. آزمایش‌هایی با کیفیت پیش‌بینی ضعیف (یا خنثی) در مقایسه با خط پایه هنوز برای ردیابی مفید هستند. آنها سیگنال می دهند که کدام رویکرد کار نمی کند. از آنجایی که پیشرفت معمولاً غیرخطی است، مهم است که نشان دهید با برجسته کردن همه راه‌هایی که یافتید که کار نمی‌کنند - علاوه بر پیشرفت در افزایش کیفیت پایه، روی مشکل کار می‌کنید.
از آنجایی که هر آموزش کامل روی یک مجموعه داده دنیای واقعی می‌تواند ساعت‌ها (یا روزها) طول بکشد، آزمایش‌های مستقل متعددی را به صورت همزمان اجرا کنید تا فضا را سریع کشف کنید. همانطور که به تکرار ادامه می دهید، امیدواریم به سطح کیفیتی که برای تولید نیاز دارید نزدیکتر و نزدیکتر شوید.
نویز در نتایج تجربی
توجه داشته باشید که ممکن است در نتایج تجربی با نویزهایی روبرو شوید که ناشی از تغییرات مدل یا داده‌ها نیست، که تعیین اینکه آیا تغییری که انجام داده‌اید واقعاً مدل را بهبود داده است یا خیر، دشوار است. موارد زیر نمونه هایی از مواردی هستند که می توانند در نتایج تجربی نویز ایجاد کنند:
ترکیب داده ها: ترتیب ارائه داده ها به مدل می تواند بر عملکرد مدل تأثیر بگذارد.
مقداردهی اولیه متغیر: نحوه مقداردهی اولیه متغیرهای مدل نیز می تواند بر عملکرد آن تأثیر بگذارد.
موازی سازی ناهمزمان: اگر مدل با استفاده از موازی سازی ناهمزمان آموزش داده شود، ترتیب به روز رسانی قسمت های مختلف مدل نیز می تواند بر عملکرد آن تأثیر بگذارد.
مجموعه‌های ارزیابی کوچک: اگر مجموعه ارزیابی خیلی کوچک باشد، ممکن است نشان‌دهنده عملکرد کلی مدل نباشد و تغییرات ناهمواری در کیفیت مدل ایجاد کند.
اجرای چندین بار آزمایش به تأیید نتایج آزمایشی کمک می کند.
مطابق با شیوه های آزمایشی
تیم شما باید با مجموعه‌ای از شیوه‌ها و مصنوعات، درک روشنی از چیستی «آزمایش» داشته باشد. شما اسنادی می خواهید که موارد زیر را مشخص کند:
مصنوعات. مصنوعات یک آزمایش چیست؟ در بیشتر موارد، یک آزمایش یک فرضیه آزمایش شده است که می تواند بازتولید شود، معمولاً با ثبت فراداده (مانند ویژگی ها و فراپارامترها) که نشان دهنده تغییرات بین آزمایش ها و نحوه تأثیر آنها بر کیفیت مدل است.
شیوه های کدنویسی آیا همه از محیط های آزمایشی خود استفاده خواهند کرد؟ متحد کردن کار همه در کتابخانه های مشترک چقدر ممکن (یا آسان) خواهد بود؟
تکرارپذیری و ردیابی استانداردهای تکرارپذیری چیست؟ به عنوان مثال، آیا تیم باید از همان شیوه‌های خط لوله داده و نسخه‌سازی استفاده کند، یا اینکه فقط نمودارها را نشان می‌دهد خوب است؟ چگونه داده های تجربی ذخیره می شوند: به عنوان پرس و جوهای SQL یا به عنوان عکس های فوری مدل؟ گزارش‌های مربوط به هر آزمایش کجا مستند می‌شوند: در یک سند، یک صفحه گسترده یا یک CMS برای مدیریت آزمایش‌ها؟
پیش بینی های اشتباه
هیچ مدل دنیای واقعی کامل نیست. سیستم شما چگونه پیش بینی های اشتباه را مدیریت می کند؟ از همان ابتدا در مورد نحوه برخورد با آنها فکر کنید.
یک استراتژی بهترین عملکرد، کاربران را تشویق می کند تا به درستی پیش بینی های اشتباه را برچسب گذاری کنند. به عنوان مثال، برنامه‌های ایمیل، ایمیل‌های طبقه‌بندی‌شده اشتباه را با ورود کاربران ایمیل به پوشه هرزنامه خود و همچنین برعکس، ضبط می‌کنند. با گرفتن برچسب های حقیقت زمینی از کاربران، می توانید حلقه های بازخورد خودکار برای جمع آوری داده ها و بازآموزی مدل طراحی کنید.
توجه داشته باشید که اگرچه نظرسنجی‌های تعبیه‌شده با رابط کاربری بازخورد کاربر را دریافت می‌کنند، داده‌ها معمولاً کیفی هستند و نمی‌توانند در داده‌های آموزش مجدد گنجانده شوند.
یک راه حل انتها به انتها را اجرا کنید
در حالی که تیم شما در حال آزمایش بر روی مدل است، ایده خوبی است که شروع به ساخت بخش هایی از خط لوله نهایی کنید (اگر منابع لازم برای انجام این کار را دارید).
ایجاد قطعات مختلف خط لوله - مانند دریافت داده و بازآموزی مدل - انتقال مدل نهایی به تولید را آسان‌تر می‌کند. به عنوان مثال، دریافت یک خط لوله سرتاسر برای دریافت داده ها و ارائه پیش بینی ها می تواند به تیم کمک کند تا مدل را در محصول ادغام کرده و آزمایش کاربر در مراحل اولیه را آغاز کند.
عیب یابی پروژه های متوقف شده
ممکن است در سناریوهایی باشید که پیشرفت یک پروژه متوقف شود. شاید تیم شما روی یک آزمایش امیدوارکننده کار کرده باشد اما هفته‌ها در بهبود مدل موفق نبوده است. چه کاری باید انجام دهید؟ در زیر برخی از رویکردهای ممکن وجود دارد:
استراتژیک. ممکن است لازم باشد مشکل را دوباره قالب بندی کنید. پس از گذراندن زمان در مرحله آزمایش، احتمالاً مشکل، داده ها و راه حل های ممکن را بهتر درک می کنید. با دانش عمیق تر از دامنه، احتمالاً می توانید مشکل را با دقت بیشتری چارچوب بندی کنید.
به عنوان مثال، شاید در ابتدا می خواستید از رگرسیون خطی برای پیش بینی یک مقدار عددی استفاده کنید. متأسفانه، داده ها برای آموزش یک مدل رگرسیون خطی قابل دوام به اندازه کافی خوب نبودند. شاید تجزیه و تحلیل بیشتر نشان دهد که می توان با پیش بینی اینکه آیا یک مثال بالاتر یا پایین تر از یک مقدار خاص است، مشکل را حل کرد. این به شما امکان می‌دهد مشکل را به عنوان یک طبقه‌بندی باینری مجدداً قاب بندی کنید.
اگر پیشرفت کندتر از حد انتظار است، تسلیم نشوید. بهبودهای تدریجی در طول زمان ممکن است تنها راه حل مشکل باشد. همانطور که قبلاً ذکر شد، انتظار نداشته باشید که میزان پیشرفت هفته در طول هفته یکسان باشد. اغلب، تهیه یک نسخه آماده برای تولید یک مدل به زمان زیادی نیاز دارد. بهبود مدل می تواند نامنظم و غیرقابل پیش بینی باشد. دوره‌های پیشرفت آهسته را می‌توان با افزایش‌هایی در بهبود یا برعکس دنبال کرد.
فنی. زمانی را صرف تشخیص و تجزیه و تحلیل پیش بینی های اشتباه کنید. در برخی موارد، می‌توانید با جداسازی چند پیش‌بینی اشتباه و تشخیص رفتار مدل در آن موارد، مشکل را پیدا کنید. برای مثال، ممکن است مشکلاتی را در معماری یا داده ها کشف کنید. در موارد دیگر، دریافت داده های بیشتر می تواند کمک کننده باشد. ممکن است سیگنال واضح‌تری دریافت کنید که نشان می‌دهد در مسیر درستی قرار گرفته‌اید، یا ممکن است نویز بیشتری تولید کند که نشان می‌دهد مشکلات دیگری در این رویکرد وجود دارد.
اگر روی مشکلی کار می‌کنید که به مجموعه داده‌های برچسب‌گذاری شده توسط انسان نیاز دارد، ممکن است بدست آوردن یک مجموعه داده برچسب‌دار برای ارزیابی مدل دشوار باشد. منابعی را برای دریافت مجموعه داده هایی که برای ارزیابی نیاز دارید، بیابید.
شاید هیچ راه حلی ممکن نباشد. رویکرد خود را در جعبه زمان تنظیم کنید، اگر در بازه زمانی پیشرفت نکرده اید، متوقف شوید. با این حال، اگر یک بیانیه مشکل قوی دارید، احتمالاً راه حل را تضمین می کند.
درک خود را بررسی کنید
یکی از اعضای تیم ترکیبی از فراپارامترها را پیدا کرد که متریک مدل پایه را بهبود می بخشد. سایر اعضای تیم چه باید بکنند؟
شاید یک فراپارامتر را بگنجانند، اما به آزمایشات خود ادامه دهید.
درست است. اگر یکی از فراپارامترهای آنها انتخاب معقولی به نظر می رسد، آن را امتحان کنید. با این حال، همه انتخاب های فراپارامتر در هر زمینه تجربی منطقی نیستند.
همه فراپارامترهای آنها را در آزمایش فعلی خود تغییر دهید تا با همکارشان مطابقت داشته باشد.
فراپارامترهایی که یک مدل را بهبود بخشیده اند به این معنی نیست که مدل دیگری را نیز بهبود خواهند بخشید. سایر هم تیمی ها باید به آزمایشات خود ادامه دهند، که در واقع ممکن است بعداً خط پایه را حتی بیشتر بهبود بخشد.
شروع به ساخت یک خط لوله انتها به انتها کنید که برای پیاده سازی مدل استفاده می شود.
مدلی که خط پایه را بهبود می بخشد به این معنی نیست که این مدلی است که در نهایت در تولید استفاده می شود. آنها باید به آزمایشات خود ادامه دهند، که در واقع ممکن است بعداً خط پایه را حتی بیشتر بهبود بخشد.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی."],[[["\u003cp\u003eExperiments involve making single, small, iterative changes to model features, architecture, or hyperparameters to improve performance compared to a baseline.\u003c/p\u003e\n"],["\u003cp\u003eIt's crucial to track all experimental results, including unsuccessful ones, to understand which approaches work and which don't.\u003c/p\u003e\n"],["\u003cp\u003eTeams should establish clear experimentation practices, including defining artifacts, coding standards, reproducibility measures, and tracking methods.\u003c/p\u003e\n"],["\u003cp\u003ePlan for handling wrong predictions early on, potentially by incorporating user feedback for model improvement.\u003c/p\u003e\n"],["\u003cp\u003eConsider building parts of the final pipeline alongside experimentation to facilitate a smoother transition to production.\u003c/p\u003e\n"]]],[],null,["Experiments drive a project toward viability. They are testable and\nreproducible hypotheses. When running experiments, the\ngoal is to make continual, incremental improvements by evaluating a variety of\nmodel architectures and features. When experimenting, you'll want to do\nthe following:\n\n- **Determine baseline performance.** Start by establishing a\n [baseline](/machine-learning/glossary#baseline) metric. The baseline\n acts as a measuring stick to compare experiments against.\n\n In some cases, the current non-ML solution can provide the first baseline\n metric. If no solution currently exists, create a ML model with a simple\n architecture, a few features, and use its metrics as the baseline.\n- **Make single, small changes.** Make only a single, small change at a time,\n for example, to the hyperparameters, architecture, or features. If the\n change improves the model, that model's metrics become the new baseline to\n compare future experiments against.\n\n The following are examples of experiments that make a single, small change:\n - include feature *X*.\n - use 0.5 dropout on the first hidden layer.\n - take the log transform of feature *Y*.\n - change the learning rate to 0.001.\n- **Record the progress of the experiments.** You'll most likely need to do\n lots of experiments. Experiments with poor (or neutral) prediction quality\n compared to the baseline are still useful to track. They signal which\n approaches won't work. Because progress is typically non-linear, it's\n important to show that you're working on the problem by highlighting all\n the ways you found that don't work---in addition to your progress at\n increasing the baseline quality.\n\nBecause each full training on a real-world dataset can take hours (or days),\nconsider running multiple independent experiments concurrently to explore the\nspace quickly. As you continue to iterate, you'll hopefully get closer and\ncloser to the level of quality you'll need for production.\n\nNoise in experimental results\n\nNote that you might encounter noise in experimental results that aren't from\nchanges to the model or the data, making it difficult to determine if a change\nyou made actually improved the model. The following are examples of things that\ncan produce noise in experimental results:\n\n- Data shuffling: The order in which the data is presented to the model can\n affect the model's performance.\n\n- Variable initialization: The way in which the model's\n variables are initialized can also affect its performance.\n\n- Asynchronous parallelism: If the model is trained using asynchronous\n parallelism, the order in which the different parts of the model are updated\n can also affect its performance.\n\n- Small evaluation sets: If the evaluation set is too small, it may\n not be representative of the overall performance of the model, producing\n uneven variations in the model's quality.\n\nRunning an experiment multiple times helps confirm experimental results.\n\nAlign on experimentation practices\n\nYour team should have a clear understanding of what exactly an \"experiment\" is,\nwith a defined set of practices and artifacts. You'll want documentation that\noutlines the following:\n\n- **Artifacts.** What are the artifacts for an experiment? In most cases, an\n experiment is a tested hypothesis that can be reproduced, typically by\n logging the metadata (like the features and hyperparameters) that indicate\n the changes between experiments and how they affect model quality.\n\n- **Coding practices.** Will everyone use their own experimental environments?\n How possible (or easy) will it be to unify everyone's work into shared\n libraries?\n\n- **Reproducibility and tracking.** What are the standards for\n reproducibility? For instance, should the team use the same data pipeline\n and versioning practices, or is it OK to show only plots? How will\n experimental data be saved: as SQL queries or as model snapshots? Where will\n the logs from each experiment be documented: in a doc, a spreadsheet, or a\n CMS for managing experiments?\n\nWrong predictions\n\nNo real-world model is perfect. How will your system handle wrong predictions?\nBegin thinking early on about how to deal with them.\n\nA best-practices strategy encourages users to correctly label wrong predictions.\nFor example, mail apps capture misclassified email by logging the mail users\nmove into their spam folder, as well as the reverse. By capturing ground truth\nlabels from users, you can design automated feedback loops for data collection\nand model retraining.\n\nNote that although UI-embedded surveys capture user feedback, the data is\ntypically qualitative and can't be incorporated into the retraining data.\n\nImplement an end-to-end solution\n\nWhile your team is experimenting on the model, it's a good idea to start\nbuilding out parts of the final pipeline (if you have the resources to do so).\n\nEstablishing different pieces of the pipeline---like data intake and model\nretraining---makes it easier to move the final model to production. For\nexample, getting an end-to-end pipeline for ingesting data and serving\npredictions can help the team start integrating the model into the product and\nto begin conducting early-stage user testing.\n\nTroubleshooting stalled projects\n\nYou might be in scenarios where a project's progress stalls. Maybe your\nteam has been working on a promising experiment but hasn't had success\nimproving the model for weeks. What should you do? The following are some\npossible approaches:\n\n- **Strategic.** You might need to reframe the problem. After spending time in\n the experimentation phase, you probably understand the problem, the data,\n and the possible solutions better. With a deeper knowledge of the domain,\n you can probably frame the problem more precisely.\n\n For instance, maybe you initially wanted to use linear regression to predict\n a numeric value. Unfortunately, the data wasn't good enough to train a\n viable linear regression model. Maybe further analysis reveals the problem\n can be solved by predicting whether an example is above or below a specific\n value. This lets you reframe the problem as a binary classification one.\n\n If progress is slower than expected, don't give up. Incremental improvements\n over time might be the only way to solve the problem. As noted earlier,\n don't expect the same amount of progress week over week. Often, getting a\n production-ready version of a model requires substantial amounts of time.\n Model improvement can be irregular and unpredictable. Periods of slow\n progress can be followed by spikes in improvement, or the reverse.\n- **Technical.** Spend time diagnosing and analyzing wrong predictions. In\n some cases, you can find the issue by isolating a few wrong predictions and\n diagnosing the model's behavior in those instances. For example, you might\n uncover problems with the architecture or the data. In other cases,\n getting more data can help. You might get a clearer signal that suggests\n you're on the right path, or it might produce more noise, indicating other\n issues exist in the approach.\n\n If you're working on a problem that requires human-labeled datasets,\n getting a labeled dataset for model evaluation might be hard to obtain. Find\n resources to get the datasets you'll need for evaluation.\n\nMaybe no solution is possible. Time-box your approach, stopping if you haven't\nmade progress within the timeframe. However, if you have a strong problem\nstatement, then it probably warrants a solution.\n\nCheck Your Understanding \nA team member found a combination of hyperparameters that improves the baseline model metric. What should the other members of the team do? \nMaybe incorporate one hyperparameter, but continue with their experiments. \nCorrect. If one of their hyperparameters seems like a reasonable choice, try it. However, not all hyperparameter choices make sense in every experimental context. \nChange all their hyperparameters in their current experiment to match their co-worker's. \nHyperparameters that improved one model doesn't mean they'll also improve a different model. The other teammates should continue with their experiments, which might actually improve the baseline even more later on. \nStart building an end-to-end pipeline that will be used to implement the model. \nA model that improves the baseline doesn't mean it's the model that will ultimately be used in production. They should continue with their experiments, which might actually improve the baseline even more later on.\n| **Key Terms:**\n|\n| - [baseline](/machine-learning/glossary#baseline)"]]
