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