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.
Thử nghiệm giúp dự án trở nên khả thi. Đó là các giả thuyết có thể kiểm thử và tái tạo. Khi chạy thử nghiệm, mục tiêu là cải thiện liên tục bằng cách đánh giá nhiều cấu trúc và tính năng của mô hình. Khi thử nghiệm, bạn nên làm những việc sau:
Xác định hiệu suất cơ sở. Hãy bắt đầu bằng cách thiết lập chỉ số đường cơ sở. Đường cơ sở đóng vai trò là thước đo để so sánh các thử nghiệm.
Trong một số trường hợp, giải pháp không sử dụng công nghệ học máy hiện tại có thể cung cấp chỉ số cơ sở đầu tiên. Nếu hiện không có giải pháp nào, hãy tạo một mô hình học máy có cấu trúc đơn giản, một vài tính năng và sử dụng các chỉ số của mô hình đó làm đường cơ sở.
Thay đổi từng chút một. Mỗi lần chỉ thay đổi một chút, ví dụ: đối với các tham số siêu dữ liệu, cấu trúc hoặc tính năng. Nếu thay đổi này cải thiện mô hình, thì các chỉ số của mô hình đó sẽ trở thành đường cơ sở mới để so sánh với các thử nghiệm trong tương lai.
Sau đây là ví dụ về các thử nghiệm chỉ thực hiện một thay đổi nhỏ:
bao gồm tính năng X.
sử dụng tỷ lệ loại bỏ 0,5 trên lớp ẩn đầu tiên.
lấy phép biến đổi logarit của đặc điểm Y.
thay đổi tốc độ học thành 0,001.
Ghi lại tiến trình của các thử nghiệm. Rất có thể bạn sẽ phải thực hiện nhiều thử nghiệm. Các thử nghiệm có chất lượng dự đoán kém (hoặc trung tính) so với đường cơ sở vẫn hữu ích để theo dõi. Các lỗi này cho biết những phương pháp nào sẽ không hoạt động. Vì tiến trình thường không tuyến tính, nên điều quan trọng là bạn phải cho thấy rằng bạn đang giải quyết vấn đề bằng cách nêu bật tất cả các cách mà bạn nhận thấy không hiệu quả, ngoài tiến trình tăng chất lượng cơ sở.
Vì mỗi lần huấn luyện đầy đủ trên một tập dữ liệu thực tế có thể mất hàng giờ (hoặc vài ngày), nên hãy cân nhắc chạy đồng thời nhiều thử nghiệm độc lập để nhanh chóng khám phá không gian. Khi tiếp tục lặp lại, bạn sẽ ngày càng đạt được chất lượng cần thiết cho bản phát hành chính thức.
Độ nhiễu trong kết quả thử nghiệm
Xin lưu ý rằng bạn có thể gặp phải nhiễu trong kết quả thử nghiệm không phải do các thay đổi đối với mô hình hoặc dữ liệu, khiến bạn khó xác định liệu thay đổi mà bạn thực hiện có thực sự cải thiện mô hình hay không. Sau đây là ví dụ về những yếu tố có thể tạo ra nhiễu trong kết quả thử nghiệm:
Đánh xáo dữ liệu: Thứ tự trình bày dữ liệu cho mô hình có thể ảnh hưởng đến hiệu suất của mô hình.
Khởi tạo biến: Cách khởi tạo biến của mô hình cũng có thể ảnh hưởng đến hiệu suất của mô hình.
Tính song song không đồng bộ: Nếu mô hình được huấn luyện bằng tính song song không đồng bộ, thì thứ tự cập nhật các phần khác nhau của mô hình cũng có thể ảnh hưởng đến hiệu suất của mô hình.
Tập hợp đánh giá nhỏ: Nếu tập hợp đánh giá quá nhỏ, thì tập hợp này có thể không đại diện cho hiệu suất tổng thể của mô hình, tạo ra sự biến động không đồng đều về chất lượng của mô hình.
Việc chạy thử nghiệm nhiều lần giúp xác nhận kết quả thử nghiệm.
Điều chỉnh các phương pháp thử nghiệm
Nhóm của bạn phải hiểu rõ "thử nghiệm" là gì, cùng với một bộ phương pháp và cấu phần phần mềm được xác định. Bạn cần có tài liệu nêu rõ những thông tin sau:
Cấu phần phần mềm. Cấu phần phần mềm là gì đối với một thử nghiệm? Trong hầu hết các trường hợp, một thử nghiệm là một giả thuyết đã được kiểm thử và có thể được tái tạo, thường là bằng cách ghi lại siêu dữ liệu (chẳng hạn như các tính năng và tham số siêu dữ liệu) cho biết những thay đổi giữa các thử nghiệm và mức độ ảnh hưởng của các thay đổi đó đến chất lượng mô hình.
Phương pháp lập trình. Mọi người có sử dụng môi trường thử nghiệm riêng không? Bạn có thể (hoặc dễ dàng) hợp nhất công việc của mọi người vào thư viện dùng chung không?
Khả năng tái tạo và theo dõi. Tiêu chuẩn về khả năng tái tạo là gì? Ví dụ: nhóm có nên sử dụng cùng một quy trình dữ liệu và các phương pháp tạo phiên bản hay chỉ hiển thị các biểu đồ là được? Dữ liệu thử nghiệm sẽ được lưu như thế nào: dưới dạng truy vấn SQL hay dưới dạng ảnh chụp nhanh mô hình? Nhật ký của từng thử nghiệm sẽ được ghi lại ở đâu: trong một tài liệu, bảng tính hoặc CMS để quản lý thử nghiệm?
Dự đoán không chính xác
Không có mô hình thực tế nào là hoàn hảo. Hệ thống của bạn sẽ xử lý các dự đoán sai như thế nào? Hãy bắt đầu suy nghĩ sớm về cách xử lý các vấn đề này.
Chiến lược theo các phương pháp hay nhất khuyến khích người dùng gắn nhãn chính xác cho các dự đoán không chính xác. Ví dụ: ứng dụng thư sẽ ghi lại email bị phân loại sai bằng cách ghi lại thư mà người dùng di chuyển vào thư mục thư rác, cũng như ngược lại. Bằng cách thu thập nhãn giá trị thực tế từ người dùng, bạn có thể thiết kế các vòng phản hồi tự động để thu thập dữ liệu và huấn luyện lại mô hình.
Xin lưu ý rằng mặc dù các bản khảo sát được nhúng trong giao diện người dùng thu thập ý kiến phản hồi của người dùng, nhưng dữ liệu này thường mang tính chất định tính và không thể được đưa vào dữ liệu huấn luyện lại.
Triển khai giải pháp toàn diện
Trong khi nhóm của bạn đang thử nghiệm mô hình, bạn nên bắt đầu xây dựng các phần của quy trình cuối cùng (nếu có đủ tài nguyên).
Việc thiết lập các phần khác nhau của quy trình (chẳng hạn như nhập dữ liệu và huấn luyện lại mô hình) giúp bạn dễ dàng chuyển mô hình cuối cùng sang môi trường sản xuất. Ví dụ: việc có một quy trình toàn diện để nhập dữ liệu và phân phát dự đoán có thể giúp nhóm bắt đầu tích hợp mô hình vào sản phẩm và bắt đầu tiến hành thử nghiệm người dùng ở giai đoạn đầu.
Khắc phục sự cố về dự án bị đình trệ
Bạn có thể gặp phải trường hợp tiến trình của dự án bị đình trệ. Có thể nhóm của bạn đang nỗ lực thực hiện một thử nghiệm đầy hứa hẹn nhưng không thành công trong việc cải thiện mô hình trong nhiều tuần. Bạn nên làm gì? Sau đây là một số phương pháp có thể áp dụng:
Chiến lược. Bạn có thể cần phải định hình lại vấn đề. Sau khi dành thời gian cho giai đoạn thử nghiệm, có thể bạn sẽ hiểu rõ hơn về vấn đề, dữ liệu và các giải pháp có thể áp dụng. Khi có kiến thức sâu hơn về miền, bạn có thể xác định vấn đề chính xác hơn.
Ví dụ: ban đầu, có thể bạn muốn sử dụng hồi quy tuyến tính để dự đoán giá trị số. Rất tiếc, dữ liệu không đủ tốt để huấn luyện một mô hình hồi quy tuyến tính khả thi. Có thể việc phân tích thêm sẽ cho thấy vấn đề này có thể được giải quyết bằng cách dự đoán xem một ví dụ có cao hơn hay thấp hơn một giá trị cụ thể. Điều này cho phép bạn định hình lại vấn đề dưới dạng một vấn đề phân loại nhị phân.
Nếu tiến trình diễn ra chậm hơn dự kiến, đừng bỏ cuộc. Việc cải tiến dần theo thời gian có thể là cách duy nhất để giải quyết vấn đề. Như đã lưu ý trước đó, đừng mong đợi tiến trình sẽ giống nhau giữa các tuần. Thông thường, việc tạo phiên bản mô hình sẵn sàng để sản xuất sẽ mất nhiều thời gian. Việc cải thiện mô hình có thể không đều đặn và khó dự đoán. Các giai đoạn tiến trình chậm có thể được theo sau bằng sự cải thiện đột biến hoặc ngược lại.
Kỹ thuật. Dành thời gian chẩn đoán và phân tích các dự đoán không chính xác. Trong một số trường hợp, bạn có thể tìm thấy vấn đề bằng cách tách riêng một vài dự đoán sai và chẩn đoán hành vi của mô hình trong những trường hợp đó. Ví dụ: bạn có thể phát hiện vấn đề về cấu trúc hoặc dữ liệu. Trong các trường hợp khác, việc thu thập thêm dữ liệu có thể hữu ích. Bạn có thể nhận được tín hiệu rõ ràng hơn cho biết bạn đang đi đúng hướng hoặc tín hiệu đó có thể tạo ra nhiều tạp âm hơn, cho biết có các vấn đề khác tồn tại trong phương pháp này.
Nếu bạn đang giải quyết một vấn đề cần có tập dữ liệu được gắn nhãn thủ công, thì bạn có thể khó có được tập dữ liệu được gắn nhãn để đánh giá mô hình. Tìm tài nguyên để lấy các tập dữ liệu mà bạn cần cho việc đánh giá.
Có thể không có giải pháp nào. Đặt thời gian cho phương pháp của bạn, dừng lại nếu bạn chưa đạt được tiến trình trong khung thời gian. Tuy nhiên, nếu bạn có một câu nhận định rõ ràng về vấn đề, thì có thể bạn cần phải tìm giải pháp.
Kiểm tra mức độ hiểu biết
Một thành viên trong nhóm đã tìm thấy một tổ hợp các tham số siêu dữ liệu giúp cải thiện chỉ số mô hình cơ sở. Các thành viên khác trong nhóm nên làm gì?
Có thể kết hợp một tham số siêu dữ liệu, nhưng tiếp tục với các thử nghiệm của chúng.
Chính xác. Nếu một trong các tham số siêu dữ liệu của chúng có vẻ là một lựa chọn hợp lý, hãy thử tham số đó. Tuy nhiên, không phải lựa chọn tham số siêu dữ liệu nào cũng phù hợp với mọi ngữ cảnh thử nghiệm.
Thay đổi tất cả các tham số siêu dữ liệu trong thử nghiệm hiện tại để khớp với tham số siêu dữ liệu của đồng nghiệp.
Các tham số siêu dữ liệu giúp cải thiện một mô hình không có nghĩa là chúng cũng sẽ cải thiện một mô hình khác. Các thành viên khác trong nhóm nên tiếp tục thử nghiệm. Điều này có thể thực sự cải thiện cơ sở ban đầu hơn nữa sau này.
Bắt đầu xây dựng quy trình toàn diện sẽ được dùng để triển khai mô hình.
Một mô hình cải thiện đường cơ sở không có nghĩa là đó là mô hình cuối cùng sẽ được sử dụng trong quá trình sản xuất. Họ nên tiếp tục thử nghiệm, điều này có thể thực sự cải thiện điểm cơ sở hơn nữa sau này.
[[["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-07-27 UTC."],[[["\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)"]]