Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Tất cả các dự án kỹ thuật phần mềm tốt đều dành nhiều năng lượng cho việc kiểm thử ứng dụng. Tương tự, bạn nên kiểm thử mô hình học máy để xác định độ chính xác của các dự đoán.
Tập huấn, xác thực và kiểm thử
Bạn nên kiểm thử mô hình dựa trên một tập hợp ví dụ khác với những ví dụ dùng để huấn luyện mô hình. Như bạn sẽ tìm hiểu sau một chút, việc kiểm thử trên nhiều ví dụ là bằng chứng mạnh mẽ hơn về khả năng phù hợp của mô hình so với việc kiểm thử trên cùng một tập hợp ví dụ. Bạn lấy những ví dụ đó ở đâu? Theo truyền thống, trong quá trình học máy, bạn sẽ nhận được các ví dụ khác nhau đó bằng cách tách tập dữ liệu ban đầu. Do đó, bạn có thể giả định rằng bạn nên chia tập dữ liệu ban đầu thành hai tập con:
Giả sử bạn huấn luyện trên tập huấn luyện và đánh giá trên tập kiểm thử trong nhiều vòng. Trong mỗi vòng, bạn sử dụng kết quả tập kiểm thử để hướng dẫn cách cập nhật các tham số siêu dữ liệu và tập tính năng. Bạn có thấy phương pháp này có gì sai không? Chỉ chọn một câu trả lời.
Việc thực hiện nhiều vòng của quy trình này có thể khiến mô hình phù hợp ngầm với các đặc điểm của tập kiểm thử.
Có! Bạn càng sử dụng cùng một tập dữ liệu kiểm thử thường xuyên, thì mô hình càng có nhiều khả năng phù hợp với tập dữ liệu kiểm thử đó. Giống như một giáo viên "dạy theo bài kiểm tra", mô hình vô tình phù hợp với tập dữ liệu kiểm thử, điều này có thể khiến mô hình khó phù hợp với dữ liệu thực tế hơn.
Bạn có thể sử dụng phương pháp này. Xét cho cùng, bạn đang huấn luyện trên bộ dữ liệu huấn luyện và đánh giá trên một bộ dữ liệu kiểm thử riêng biệt.
Thực ra, có một vấn đề nhỏ ở đây. Hãy nghĩ về những điều có thể dần dần diễn ra không đúng cách.
Phương pháp này không hiệu quả về mặt tính toán. Không thay đổi siêu tham số hoặc bộ tính năng sau mỗi vòng kiểm thử.
Việc kiểm thử thường xuyên tốn kém nhưng rất quan trọng. Tuy nhiên, việc kiểm thử thường xuyên sẽ tốn ít chi phí hơn nhiều so với việc đào tạo thêm. Việc tối ưu hoá các tham số siêu dữ liệu và tập hợp tính năng có thể cải thiện đáng kể chất lượng mô hình, vì vậy, hãy luôn dành thời gian và tài nguyên tính toán để xử lý các tham số này.
Việc chia tập dữ liệu thành hai tập là một ý tưởng hay, nhưng tốt hơn là bạn nên chia tập dữ liệu thành ba tập con. Ngoài tập huấn luyện và tập kiểm thử, tập con thứ ba là:
Bộ dữ liệu xác thực thực hiện kiểm thử ban đầu trên mô hình khi mô hình đang được huấn luyện.
Hình 9. Phân tách tốt hơn nhiều.
Sử dụng nhóm dữ liệu xác thực để đánh giá kết quả từ nhóm dữ liệu huấn luyện. Sau khi sử dụng nhiều lần tập hợp dữ liệu xác thực cho thấy mô hình của bạn đang đưa ra dự đoán chính xác, hãy sử dụng tập hợp dữ liệu kiểm thử để kiểm tra lại mô hình của bạn.
Hình sau đây đề xuất quy trình công việc này. Trong hình, "Tweak model" (Chỉnh sửa mô hình) có nghĩa là điều chỉnh mọi thứ về mô hình – từ thay đổi tốc độ học, thêm hoặc xoá các tính năng, cho đến thiết kế một mô hình hoàn toàn mới từ đầu.
Hình 10. Quy trình làm việc hiệu quả để phát triển và kiểm thử.
Quy trình làm việc trong Hình 10 là tối ưu, nhưng ngay cả với quy trình làm việc đó, các tập hợp kiểm thử và tập hợp xác thực vẫn "mệt mỏi" khi sử dụng nhiều lần. Tức là, bạn càng sử dụng cùng một dữ liệu để đưa ra quyết định về các chế độ cài đặt tham số siêu dữ liệu hoặc các điểm cải tiến khác của mô hình, thì bạn càng ít tin tưởng rằng mô hình sẽ đưa ra dự đoán chính xác về dữ liệu mới. Vì lý do này, bạn nên thu thập thêm dữ liệu để "làm mới" tập dữ liệu kiểm thử và tập dữ liệu xác thực. Việc bắt đầu lại là một cách đặt lại tuyệt vời.
Bài tập: Kiểm tra trực giác của bạn
Bạn đã xáo trộn tất cả các ví dụ trong tập dữ liệu và chia các ví dụ đã xáo trộn thành các tập huấn luyện, xác thực và kiểm thử. Tuy nhiên, giá trị tổn thất trên tập dữ liệu kiểm thử của bạn thấp đến mức đáng kinh ngạc nên bạn nghi ngờ có lỗi. Có thể đã xảy ra lỗi gì?
Nhiều ví dụ trong tập kiểm thử là bản sao của các ví dụ trong tập huấn luyện.
Có. Đây có thể là vấn đề trong một tập dữ liệu có nhiều ví dụ thừa. Bạn nên xoá các ví dụ trùng lặp khỏi bộ kiểm thử trước khi kiểm thử.
Quá trình huấn luyện và kiểm thử là không xác định. Đôi khi, do tình cờ, tổn thất thử nghiệm của bạn rất thấp. Chạy lại kiểm thử để xác nhận kết quả.
Mặc dù tổn thất có thay đổi một chút trong mỗi lần chạy, nhưng không được thay đổi quá nhiều đến mức bạn nghĩ rằng mình đã thắng xổ số học máy.
Tình cờ, tập dữ liệu kiểm thử lại chứa các ví dụ mà mô hình hoạt động hiệu quả.
Các ví dụ đã được xáo trộn kỹ, nên điều này rất khó xảy ra.
Các vấn đề khác về bộ kiểm thử
Như câu hỏi trước đã minh hoạ, các ví dụ trùng lặp có thể ảnh hưởng đến việc đánh giá mô hình. Sau khi chia một tập dữ liệu thành tập huấn luyện, tập xác thực và tập kiểm thử, hãy xoá mọi ví dụ trong tập xác thực hoặc tập kiểm thử trùng lặp với ví dụ trong tập huấn luyện. Cách kiểm thử công bằng duy nhất của một mô hình là so sánh với các ví dụ mới, chứ không phải các ví dụ trùng lặp.
Ví dụ: hãy xem xét một mô hình dự đoán xem một email có phải là email vi phạm hay không, bằng cách sử dụng tiêu đề, nội dung email và địa chỉ email của người gửi làm các đặc điểm. Giả sử bạn chia dữ liệu thành tập huấn luyện và tập kiểm thử, với tỷ lệ phân chia là 80-20. Sau khi huấn luyện, mô hình đạt được độ chính xác 99% trên cả tập huấn luyện và tập kiểm thử. Bạn có thể dự kiến độ chính xác thấp hơn trên tập kiểm thử, vì vậy, bạn hãy xem lại dữ liệu và phát hiện ra rằng nhiều ví dụ trong tập kiểm thử là bản sao của các ví dụ trong tập huấn luyện. Vấn đề là bạn quên xoá các mục nhập trùng lặp cho cùng một email rác khỏi cơ sở dữ liệu đầu vào trước khi tách dữ liệu. Bạn đã vô tình huấn luyện trên một số dữ liệu kiểm thử.
Tóm lại, một tập hợp kiểm thử hoặc tập hợp xác thực tốt đáp ứng tất cả các tiêu chí sau:
Đủ lớn để mang lại kết quả thử nghiệm có ý nghĩa thống kê.
Đại diện cho toàn bộ tập dữ liệu. Nói cách khác, đừng chọn một tập kiểm thử có đặc điểm khác với tập huấn luyện.
Đại diện cho dữ liệu thực tế mà mô hình sẽ gặp phải trong mục đích kinh doanh của mô hình.
Không có ví dụ nào bị trùng lặp trong tập huấn luyện.
Bài tập: Kiểm tra mức độ hiểu biết
Với một tập dữ liệu có số lượng ví dụ cố định, câu nào sau đây là đúng?
Mỗi ví dụ được dùng để kiểm thử mô hình sẽ là một ví dụ ít hơn được dùng để huấn luyện mô hình.
Việc chia các ví dụ thành tập huấn luyện/kiểm thử/xác thực là một trò chơi có tổng bằng 0. Đây là điểm đánh đổi chính.
Số lượng ví dụ trong tập kiểm thử phải lớn hơn số lượng ví dụ trong tập xác thực.
Về lý thuyết, tập hợp xác thực và tập hợp kiểm thử phải chứa cùng một số lượng ví dụ hoặc gần như vậy.
Số lượng ví dụ trong tập kiểm thử phải lớn hơn số lượng ví dụ trong tập xác thực hoặc tập huấn luyện.
Số lượng ví dụ trong tập huấn luyện thường lớn hơn số lượng ví dụ trong tập xác thực hoặc tập kiểm thử; tuy nhiên, không có yêu cầu về tỷ lệ phần trăm cho các tập khác nhau.
Giả sử tập dữ liệu kiểm thử của bạn chứa đủ ví dụ để thực hiện một kiểm thử có ý nghĩa thống kê. Hơn nữa, việc kiểm thử dựa trên tập kiểm thử sẽ mang lại tổn thất thấp. Tuy nhiên, mô hình này hoạt động kém trong thế giới thực. Bạn nên làm gì?
Xác định sự khác biệt giữa tập dữ liệu gốc và dữ liệu thực tế.
Có. Ngay cả những tập dữ liệu tốt nhất cũng chỉ là một bản tổng quan nhanh về dữ liệu thực tế; sự thật cơ bản cơ bản có xu hướng thay đổi theo thời gian. Mặc dù tập dữ liệu kiểm thử của bạn khớp với tập dữ liệu huấn luyện đủ tốt để cho thấy chất lượng mô hình tốt, nhưng tập dữ liệu của bạn có thể không khớp đủ với dữ liệu thực tế. Bạn có thể phải huấn luyện lại và kiểm thử lại dựa trên một tập dữ liệu mới.
Kiểm thử lại trên cùng một bộ kiểm thử. Kết quả kiểm thử có thể là một ngoại lệ.
Mặc dù việc kiểm thử lại có thể mang lại kết quả hơi khác, nhưng chiến thuật này có thể không hữu ích lắm.
Bộ kiểm thử phải chứa bao nhiêu ví dụ?
Có đủ ví dụ để tạo ra một kiểm thử có ý nghĩa thống kê.
Có. Có bao nhiêu ví dụ như vậy? Bạn sẽ cần thử nghiệm.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 2025-01-03 UTC."],[[["\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,["# Datasets: Dividing the original dataset\n\nAll 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-----------------------------------\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\n### Exercise: Check your intuition\n\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\n### Exercise: Check your intuition\n\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----------------------------------\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\n### Exercises: Check your understanding\n\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)"]]
