با مجموعه‌ها، منظم بمانید ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
همه پروژه های خوب مهندسی نرم افزار انرژی قابل توجهی را صرف آزمایش برنامه های خود می کنند. به طور مشابه، ما قویاً توصیه می کنیم مدل ML خود را برای تعیین صحت پیش بینی های آن آزمایش کنید.
مجموعه های آموزش، اعتبار سنجی و تست
شما باید یک مدل را با مجموعه‌ای از نمونه‌های متفاوت از نمونه‌هایی که برای آموزش مدل استفاده می‌شوند، آزمایش کنید. همانطور که کمی بعداً یاد خواهید گرفت، آزمایش بر روی نمونه‌های مختلف، اثبات قوی‌تر بر تناسب مدل شما نسبت به آزمایش بر روی مجموعه‌ای از نمونه‌های مشابه است. این نمونه های مختلف را از کجا می آورید؟ به طور سنتی در یادگیری ماشینی، با تقسیم مجموعه داده اصلی، آن نمونه های مختلف را دریافت می کنید. بنابراین، ممکن است فرض کنید که باید مجموعه داده اصلی را به دو زیر مجموعه تقسیم کنید:
فرض کنید در مجموعه تمرینی تمرین می کنید و در مجموعه تست در چندین راند ارزیابی می کنید. در هر دور، شما از نتایج مجموعه تست برای راهنمایی نحوه به روز رسانی هایپرپارامترها و مجموعه ویژگی ها استفاده می کنید. آیا می توانید در این رویکرد اشکالی ببینید؟ فقط یک پاسخ را انتخاب کنید
انجام دورهای زیادی از این روش ممکن است باعث شود که مدل به طور ضمنی با ویژگی‌های مجموعه تست مطابقت داشته باشد.
بله! هر چه بیشتر از یک مجموعه تست استفاده کنید، احتمال بیشتری وجود دارد که مدل با مجموعه تست مطابقت داشته باشد. مانند معلمی که «تدریس به آزمون» را انجام می دهد، مدل به طور ناخواسته با مجموعه آزمون مطابقت دارد، که ممکن است تطبیق داده های دنیای واقعی را برای مدل دشوارتر کند.
این رویکرد خوب است. پس از همه، شما در حال تمرین در مجموعه آموزشی و ارزیابی در یک مجموعه تست جداگانه هستید.
در واقع، یک مسئله ظریف در اینجا وجود دارد. به این فکر کنید که چه چیزی ممکن است به تدریج خراب شود.
این رویکرد از نظر محاسباتی ناکارآمد است. پس از هر دور آزمایش، هایپرپارامترها یا مجموعه ویژگی ها را تغییر ندهید.
آزمایشات مکرر گران اما حیاتی است. با این حال، آزمایش های مکرر بسیار ارزان تر از آموزش های اضافی است. بهینه‌سازی فراپارامترها و مجموعه ویژگی‌ها می‌تواند به طور چشمگیری کیفیت مدل را بهبود بخشد، بنابراین همیشه زمان و منابع محاسباتی را برای کار روی این موارد اختصاص دهید.
تقسیم مجموعه داده به دو مجموعه ایده مناسبی است، اما رویکرد بهتر این است که مجموعه داده را به سه زیر مجموعه تقسیم کنیم. علاوه بر مجموعه آموزشی و مجموعه تست، زیر مجموعه سوم نیز عبارتند از:
یک مجموعه اعتبار سنجی آزمایش اولیه را بر روی مدل در حین آموزش انجام می دهد.
شکل 9. یک تقسیم بسیار بهتر.
از مجموعه اعتبارسنجی برای ارزیابی نتایج مجموعه آموزشی استفاده کنید. پس از اینکه استفاده مکرر از مجموعه اعتبار سنجی نشان داد که مدل شما پیش بینی های خوبی انجام می دهد، از مجموعه تست برای بررسی مجدد مدل خود استفاده کنید.
شکل زیر این گردش کار را نشان می دهد. در شکل، «مدل توییک» به معنای تنظیم هر چیزی در مورد مدل است - از تغییر نرخ یادگیری، اضافه کردن یا حذف ویژگی‌ها، تا طراحی یک مدل کاملاً جدید از ابتدا.
شکل 10. یک گردش کار خوب برای توسعه و آزمایش.
گردش کار نشان داده شده در شکل 10 بهینه است، اما حتی با آن گردش کار، مجموعه های تست و مجموعه های اعتبار سنجی همچنان با استفاده مکرر "فرسوده" می شوند. به این معنا که هر چه بیشتر از داده های مشابه برای تصمیم گیری در مورد تنظیمات هایپرپارامتر یا سایر بهبودهای مدل استفاده کنید، اطمینان کمتری نسبت به اینکه مدل پیش بینی های خوبی را روی داده های جدید انجام دهد، کاهش می یابد. به همین دلیل، ایده خوبی است که داده های بیشتری را برای "بازسازی" مجموعه تست و مجموعه اعتبار سنجی جمع آوری کنید. شروع مجدد یک تنظیم مجدد عالی است.
ورزش: شهود خود را بررسی کنید
شما تمام نمونه‌های موجود در مجموعه داده را به هم ریخته و نمونه‌های به هم ریخته را به مجموعه‌های آموزشی، اعتبارسنجی و تست تقسیم می‌کنید. با این حال، ارزش تلفات در مجموعه آزمایشی شما به قدری سرسام آور کم است که به اشتباه مشکوک می شوید. چه اشتباهی ممکن است رخ داده باشد؟
بسیاری از نمونه های مجموعه تست، تکراری از نمونه های مجموعه آموزشی هستند.
بله این می تواند در یک مجموعه داده با نمونه های اضافی زیاد مشکل ایجاد کند. اکیداً توصیه می‌کنیم قبل از آزمایش، نمونه‌های تکراری را از مجموعه تست حذف کنید.
آموزش و آزمایش غیر قطعی است. گاهی اوقات، به طور تصادفی، از دست دادن تست شما بسیار کم است. برای تایید نتیجه آزمایش را دوباره اجرا کنید.
اگرچه ضرر در هر دویدن کمی متفاوت است، اما نباید آنقدر تغییر کند که فکر کنید در قرعه کشی یادگیری ماشین برنده شده اید.
اتفاقاً مجموعه آزمایشی حاوی نمونه هایی بود که مدل به خوبی در آنها عمل کرد.
مثال ها به خوبی در هم ریخته شده بودند، بنابراین این بسیار بعید است.
مشکلات اضافی با مجموعه تست
همانطور که سوال قبلی نشان می دهد، مثال های تکراری می توانند بر ارزیابی مدل تاثیر بگذارند. پس از تقسیم یک مجموعه داده به مجموعه‌های آموزشی، اعتبارسنجی و آزمایشی، هر نمونه‌ای را در مجموعه اعتبارسنجی یا مجموعه آزمایشی که تکراری از نمونه‌های مجموعه آموزشی هستند حذف کنید. تنها آزمون منصفانه یک مدل در برابر نمونه های جدید است، نه تکراری.
به عنوان مثال، مدلی را در نظر بگیرید که با استفاده از خط موضوع، متن ایمیل و آدرس ایمیل فرستنده به عنوان ویژگی، پیش‌بینی می‌کند که ایمیل هرزنامه است یا خیر. فرض کنید داده ها را به مجموعه های آموزشی و آزمایشی با تقسیم 80-20 تقسیم می کنید. پس از آموزش، مدل به دقت 99 درصدی هم در مجموعه آموزشی و هم در مجموعه تست دست می یابد. احتمالاً انتظار دارید دقت کمتری در مجموعه تست داشته باشید، بنابراین نگاهی دیگر به داده ها بیندازید و متوجه شوید که بسیاری از نمونه های مجموعه آزمایشی تکراری از نمونه های مجموعه آموزشی هستند. مشکل این است که از پاک کردن ورودی های تکراری برای همان ایمیل هرزنامه از پایگاه داده ورودی خود غفلت کرده اید قبل از تقسیم داده ها. شما به طور ناخواسته روی برخی از داده های آزمایشی خود آموزش دیده اید.
به طور خلاصه، یک مجموعه تست خوب یا مجموعه اعتبار سنجی تمام معیارهای زیر را برآورده می کند:
به اندازه کافی بزرگ است تا نتایج آزمایش آماری قابل توجهی را به همراه داشته باشد.
نماینده مجموعه داده به عنوان یک کل. به عبارت دیگر، مجموعه تستی با ویژگی های متفاوت از مجموعه آموزشی انتخاب نکنید.
نماینده داده های دنیای واقعی که مدل به عنوان بخشی از هدف تجاری خود با آن مواجه می شود.
نمونه های صفر تکراری در مجموعه آموزشی.
تمرینات: درک خود را بررسی کنید
با توجه به یک مجموعه داده منفرد با تعداد ثابت مثال، کدام یک از عبارات زیر درست است؟
هر مثالی که در آزمایش مدل استفاده می شود، یک نمونه کمتر در آموزش مدل استفاده می شود.
تقسیم مثال‌ها به مجموعه‌های قطار/آزمون/ اعتبارسنجی یک بازی با مجموع صفر است. این معامله مرکزی است.
تعداد نمونه‌های مجموعه آزمایشی باید بیشتر از تعداد نمونه‌های مجموعه اعتبارسنجی باشد.
در تئوری، مجموعه اعتبارسنجی و آزمون آزمون باید شامل تعداد مشابه یا تقریباً بیشتر باشد.
تعداد نمونه‌های مجموعه تست باید بیشتر از تعداد نمونه‌های مجموعه اعتبارسنجی یا مجموعه آموزشی باشد.
تعداد نمونه‌های مجموعه آموزشی معمولاً از تعداد نمونه‌های مجموعه اعتبارسنجی یا مجموعه آزمایشی بیشتر است. با این حال، هیچ درصدی الزامی برای مجموعه های مختلف وجود ندارد.
فرض کنید مجموعه تست شما شامل نمونه های کافی برای انجام یک آزمون آماری معنی دار است. علاوه بر این، آزمایش در برابر مجموعه آزمایشی تلفات کمی را به همراه دارد. با این حال، این مدل در دنیای واقعی ضعیف عمل کرد. چه کاری باید انجام دهید؟
تعیین کنید که چگونه مجموعه داده اصلی با داده های واقعی متفاوت است.
بله حتی بهترین مجموعه داده ها فقط یک عکس فوری از داده های واقعی هستند. حقیقت زمینه ای در طول زمان تغییر می کند. اگرچه مجموعه آزمایشی شما به اندازه کافی با مجموعه آموزشی شما مطابقت دارد که کیفیت مدل خوبی را نشان دهد، مجموعه داده شما احتمالاً به اندازه کافی با داده های دنیای واقعی مطابقت ندارد. ممکن است مجبور شوید دوباره آموزش دهید و در مقابل یک مجموعه داده جدید آزمایش کنید.
در همان مجموعه تست مجددا تست کنید. نتایج آزمایش ممکن است یک ناهنجاری باشد.
اگرچه آزمایش مجدد ممکن است نتایج کمی متفاوت به همراه داشته باشد، این تاکتیک احتمالاً چندان مفید نیست.
مجموعه تست باید شامل چند مثال باشد؟
مثال های کافی برای به دست آوردن یک آزمون آماری معنی دار است.
تاریخ آخرین بهروزرسانی 2025-01-03 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-01-03 بهوقت ساعت هماهنگ جهانی."],[[["\u003cp\u003eMachine learning models should be tested against a separate dataset, called the test set, to ensure accurate predictions on unseen data.\u003c/p\u003e\n"],["\u003cp\u003eIt's recommended to split the dataset into three subsets: training, validation, and test sets, with the validation set used for initial testing during training and the test set used for final evaluation.\u003c/p\u003e\n"],["\u003cp\u003eThe validation and test sets can "wear out" with repeated use, requiring fresh data to maintain reliable evaluation results.\u003c/p\u003e\n"],["\u003cp\u003eA good test set is statistically significant, representative of the dataset and real-world data, and contains no duplicates from the training set.\u003c/p\u003e\n"],["\u003cp\u003eIt's crucial to address discrepancies between the dataset used for training and testing and the real-world data the model will encounter to achieve satisfactory real-world performance.\u003c/p\u003e\n"]]],[],null,["All good software engineering projects devote considerable energy to\n*testing* their apps. Similarly, we strongly recommend testing your\nML model to determine the correctness of its predictions.\n\nTraining, validation, and test sets\n\nYou should test a model against a *different* set of examples than those\nused to train the model. As you'll learn\n[a little later](#additional_problems_with_test_sets), testing\non different examples is stronger proof of your model's fitness than testing\non the same set of examples.\nWhere do you get those different examples? Traditionally in machine learning,\nyou get those different examples by splitting the original dataset. You might\nassume, therefore, that you should split the original dataset into two subsets:\n\n- A [**training set**](/machine-learning/glossary#training-set) that the model trains on.\n- A [**test set**](/machine-learning/glossary#test-set) for evaluation of the trained model.\n\n**Figure 8.** Not an optimal split.\n\nExercise: Check your intuition \nSuppose you train on the training set and evaluate on the test set over multiple rounds. In each round, you use the test set results to guide how to update hyperparameters and the feature set. Can you see anything wrong with this approach? Pick only one answer. \nDoing many rounds of this procedure might cause the model to implicitly fit the peculiarities of the test set. \nYes! The more often you use the same test set, the more likely the model closely fits the test set. Like a teacher \"teaching to the test,\" the model inadvertently fits the test set, which might make it harder for the model to fit real-world data. \nThis approach is fine. After all, you're training on the training set and evaluating on a separate test set. \nActually, there's a subtle issue here. Think about what might gradually go wrong. \nThis approach is computationally inefficient. Don't change hyperparameters or feature sets after each round of testing. \nFrequent testing is expensive but critical. However, frequent testing is far less expensive than additional training. Optimizing hyperparameters and the feature set can dramatically improve model quality, so always budget time and computational resources to work on these.\n\nDividing the dataset into two sets is a decent idea, but\na better approach is to divide the dataset into *three* subsets.\nIn addition to the training set and the test set, the third subset is:\n\n- A [**validation set**](/machine-learning/glossary#validation-set) performs the initial testing on the model as it is being trained.\n\n**Figure 9.** A much better split.\n\nUse the **validation set** to evaluate results from the training set.\nAfter repeated use of the validation set suggests that your model is\nmaking good predictions, use the test set to double-check your model.\n\nThe following figure suggests this workflow.\nIn the figure, \"Tweak model\" means adjusting anything about the model\n---from changing the learning rate, to adding or removing\nfeatures, to designing a completely new model from scratch.\n**Figure 10.** A good workflow for development and testing. **Note:** When you transform a feature in your training set, you must make the *same* transformation in the validation set, test set, and real-world dataset.\n\nThe workflow shown in Figure 10 is optimal, but even with that workflow,\ntest sets and validation sets still \"wear out\" with repeated use.\nThat is, the more you use the same data to make decisions about\nhyperparameter settings or other model improvements, the less confidence\nthat the model will make good predictions on new data.\nFor this reason, it's a good idea to collect more data to \"refresh\" the test\nset and validation set. Starting anew is a great reset.\n\nExercise: Check your intuition \nYou shuffled all the examples in the dataset and divided the shuffled examples into training, validation, and test sets. However, the loss value on your test set is so staggeringly low that you suspect a mistake. What might have gone wrong? \nMany of the examples in the test set are duplicates of examples in the training set. \nYes. This can be a problem in a dataset with a lot of redundant examples. We strongly recommend deleting duplicate examples from the test set before testing. \nTraining and testing are nondeterministic. Sometimes, by chance, your test loss is incredibly low. Rerun the test to confirm the result. \nAlthough loss does vary a little on each run, it shouldn't vary so much that you think you won the machine learning lottery. \nBy chance, the test set just happened to contain examples that the model performed well on. \nThe examples were well shuffled, so this is extremely unlikely.\n\nAdditional problems with test sets\n\nAs the previous question illustrates, duplicate examples can affect model evaluation.\nAfter splitting a dataset into training, validation, and test sets,\ndelete any examples in the validation set or test set that are duplicates of\nexamples in the training set. The only fair test of a model is against\nnew examples, not duplicates.\n\nFor example, consider a model that predicts whether an email is spam, using\nthe subject line, email body, and sender's email address as features.\nSuppose you divide the data into training and test sets, with an 80-20 split.\nAfter training, the model achieves 99% precision on both the training set and\nthe test set. You'd probably expect a lower precision on the test set, so you\ntake another look at the data and discover that many of the examples in the test\nset are duplicates of examples in the training set. The problem is that you\nneglected to scrub duplicate entries for the same spam email from your input\ndatabase before splitting the data. You've inadvertently trained on some of\nyour test data.\n\nIn summary, a good test set or validation set meets all of the\nfollowing criteria:\n\n- Large enough to yield statistically significant testing results.\n- Representative of the dataset as a whole. In other words, don't pick a test set with different characteristics than the training set.\n- Representative of the real-world data that the model will encounter as part of its business purpose.\n- Zero examples duplicated in the training set.\n\nExercises: Check your understanding \nGiven a single dataset with a fixed number of examples, which of the following statements is true? \nEvery example used in testing the model is one less example used in training the model. \nDividing examples into train/test/validation sets is a zero-sum game. This is the central trade-off. \nThe number of examples in the test set must be greater than the number of examples in the validation set. \nIn theory, the validation set and test test should contain the same number of examples or nearly so. \nThe number of examples in the test set must be greater than the number of examples in the validation set or training set. \nThe number of examples in the training set is usually greater than the number of examples in the validation set or test set; however, there are no percentage requirements for the different sets. \nSuppose your test set contains enough examples to perform a statistically significant test. Furthermore, testing against the test set yields low loss. However, the model performed poorly in the real world. What should you do? \nDetermine how the original dataset differs from real-life data. \nYes. Even the best datasets are only a snapshot of real-life data; the underlying [ground truth](/machine-learning/glossary#ground-truth) tends to change over time. Although your test set matched your training set well enough to suggest good model quality, your dataset probably doesn't adequately match real-world data. You might have to retrain and retest against a new dataset. \nRetest on the same test set. The test results might have been an anomaly. \nAlthough retesting might yield slightly different results, this tactic probably isn't very helpful. \nHow many examples should the test set contain? \nEnough examples to yield a statistically significant test. \nYes. How many examples is that? You'll need to experiment. \nAt least 15% of the original dataset. \n15% may or may not be enough examples.\n| **Key terms:**\n|\n| - [Test set](/machine-learning/glossary#test-set)\n| - [Training set](/machine-learning/glossary#training-set)\n- [Validation set](/machine-learning/glossary#validation_set) \n[Help Center](https://support.google.com/machinelearningeducation)"]]
