Các phương pháp thử nghiệm cho các mô hình Amazon SageMaker ML

Bài đăng này được đồng viết với Tobias Wenzel, Giám đốc Kỹ thuật Phần mềm cho Nền tảng Máy học Intuit.

Chúng tôi đều đánh giá cao tầm quan trọng của mô hình máy học (ML) chất lượng cao và đáng tin cậy khi sử dụng lái xe tự động hoặc tương tác với Alexa, chẳng hạn. Các mô hình ML cũng đóng một vai trò quan trọng theo những cách ít rõ ràng hơn — chúng được sử dụng bởi các ứng dụng kinh doanh, chăm sóc sức khỏe, tổ chức tài chính, amazon.com, TurboTax, v.v.

Khi các ứng dụng hỗ trợ ML trở thành cốt lõi của nhiều doanh nghiệp, các mô hình cần tuân theo sự mạnh mẽ và kỷ luật giống như các ứng dụng phần mềm. Một khía cạnh quan trọng của MLOps là cung cấp phiên bản mới của mô hình ML đã phát triển trước đó trong quá trình sản xuất bằng cách sử dụng các phương pháp DevOps đã thiết lập như thử nghiệm, lập phiên bản, phân phối liên tục và giám sát.

Có một số mô tả hướng dẫn xung quanh MLOps và bài đăng này cung cấp tổng quan về quy trình mà bạn có thể làm theo và những công cụ nào sẽ sử dụng để kiểm tra. Điều này dựa trên sự hợp tác giữa Intuit và AWS. Chúng tôi đã và đang làm việc cùng nhau để thực hiện các khuyến nghị được giải thích trong bài đăng này trên thực tế và trên quy mô lớn. Mục tiêu của Intuit là trở thành một Nền tảng chuyên gia do AI điều khiển phụ thuộc nhiều vào chiến lược tăng tốc độ phát triển mô hình ban đầu cũng như thử nghiệm các phiên bản mới.

Yêu cầu

Sau đây là các lĩnh vực chính cần xem xét khi triển khai các phiên bản mô hình mới:

1. Hiệu suất độ chính xác của mô hình - Điều quan trọng là theo dõi các chỉ số đánh giá mô hình như độ chính xác, độ chính xác và khả năng thu hồi và đảm bảo rằng các chỉ số mục tiêu vẫn tương đối giống nhau hoặc cải thiện với phiên bản mới của mô hình. Trong hầu hết các trường hợp, việc triển khai một phiên bản mới của mô hình sẽ không có ý nghĩa gì nếu trải nghiệm của người dùng cuối không được cải thiện.
2. Kiểm tra chất lượng dữ liệu - Dữ liệu trong môi trường phi sản xuất, dù là bản sao mô phỏng hay điểm trong thời gian, phải đại diện cho dữ liệu mà mô hình sẽ nhận được khi triển khai đầy đủ, về khối lượng hoặc phân phối. Nếu không, các quy trình thử nghiệm của bạn sẽ không mang tính đại diện và mô hình của bạn có thể hoạt động khác trong quá trình sản xuất.
3. Mức độ quan trọng và ngang bằng của tính năng - Tầm quan trọng của tính năng trong phiên bản mới hơn của mô hình nên tương đối so với mô hình cũ hơn, mặc dù có thể có các tính năng mới được giới thiệu. Điều này là để đảm bảo rằng mô hình không bị sai lệch.
4. Kiểm tra quy trình kinh doanh - Điều quan trọng là phiên bản mới của một mô hình có thể đáp ứng các mục tiêu kinh doanh yêu cầu của bạn trong các thông số có thể chấp nhận được. Ví dụ: một trong những số liệu kinh doanh có thể là độ trễ end-to-end cho bất kỳ dịch vụ nào không được quá 100 mili giây hoặc chi phí để lưu trữ và đào tạo lại một mô hình cụ thể không được quá 10,000 đô la mỗi năm.
5. Phí Tổn - Một cách tiếp cận đơn giản để kiểm thử là nhân rộng toàn bộ môi trường sản xuất làm môi trường thử nghiệm. Đây là một thực tế phổ biến trong phát triển phần mềm. Tuy nhiên, cách tiếp cận như vậy trong trường hợp mô hình ML có thể không mang lại ROI phù hợp tùy thuộc vào quy mô dữ liệu và có thể ảnh hưởng đến mô hình về vấn đề kinh doanh mà nó đang giải quyết.
6. Bảo mật - Môi trường thử nghiệm thường được mong đợi có dữ liệu mẫu thay vì dữ liệu khách hàng thực và do đó, các quy tắc tuân thủ và xử lý dữ liệu có thể ít nghiêm ngặt hơn. Cũng giống như chi phí, nếu bạn chỉ cần sao chép môi trường sản xuất thành môi trường thử nghiệm, bạn có thể dẫn đến các rủi ro về bảo mật và tuân thủ.
7. Khả năng mở rộng cửa hàng tính năng - Nếu một tổ chức quyết định không tạo một cửa hàng tính năng thử nghiệm riêng biệt vì lý do chi phí hoặc bảo mật, thì việc thử nghiệm mô hình cần phải diễn ra trên cửa hàng tính năng sản xuất, điều này có thể gây ra các vấn đề về khả năng mở rộng khi lưu lượng truy cập tăng gấp đôi trong thời gian thử nghiệm.
8. Hiệu suất mô hình trực tuyến - Đánh giá trực tuyến khác với đánh giá ngoại tuyến và có thể quan trọng trong một số trường hợp như mô hình đề xuất vì chúng đo lường sự hài lòng của người dùng trong thời gian thực chứ không phải sự hài lòng theo cảm nhận. Thật khó để mô phỏng các mẫu lưu lượng truy cập thực trong trường hợp không sản xuất do tính thời vụ hoặc hành vi người dùng khác, vì vậy hiệu suất mô hình trực tuyến chỉ có thể được thực hiện trong sản xuất.
9. Hiệu suất hoạt động - Khi các mô hình ngày càng lớn hơn và ngày càng được triển khai theo cách phi tập trung trên các phần cứng khác nhau, điều quan trọng là phải kiểm tra mô hình cho hiệu suất hoạt động mong muốn của bạn như độ trễ, tỷ lệ lỗi và hơn thế nữa.

Hầu hết các đội ML có cách tiếp cận đa hướng để kiểm tra mô hình. Trong các phần tiếp theo, chúng tôi cung cấp các cách để giải quyết những thách thức này trong các giai đoạn thử nghiệm khác nhau.

Kiểm tra mô hình ngoại tuyến

Mục tiêu của giai đoạn thử nghiệm này là xác nhận các phiên bản mới của mô hình hiện có trên quan điểm độ chính xác. Điều này nên được thực hiện theo cách ngoại tuyến để không ảnh hưởng đến bất kỳ dự đoán nào trong hệ thống sản xuất đang phục vụ các dự đoán thời gian thực. Bằng cách đảm bảo rằng mô hình mới hoạt động tốt hơn đối với các chỉ số đánh giá hiện hành, thử nghiệm này giải quyết thách thức 1 (hiệu suất độ chính xác của mô hình). Ngoài ra, bằng cách sử dụng tập dữ liệu phù hợp, thử nghiệm này có thể giải quyết thách thức 2 và 3 (chất lượng dữ liệu kiểm tra, tầm quan trọng của tính năng và tính ngang bằng), với lợi ích bổ sung của việc giải quyết thách thức 5 (chi phí).

Giai đoạn này được thực hiện trong môi trường dàn dựng.

Bạn nên nắm bắt lưu lượng sản xuất, bạn có thể sử dụng lưu lượng này để phát lại trong quá trình kiểm tra lại ngoại tuyến. Tốt hơn là sử dụng lưu lượng sản xuất trước đây thay vì dữ liệu tổng hợp. Các Giám sát mô hình Amazon SageMaker tính năng chụp dữ liệu cho phép bạn nắm bắt lưu lượng sản xuất cho các mô hình được lưu trữ trên Amazon SageMaker. Điều này cho phép các nhà phát triển mô hình kiểm tra mô hình của họ với dữ liệu từ những ngày làm việc cao điểm hoặc các sự kiện quan trọng khác. Dữ liệu thu được sau đó sẽ được phát lại với phiên bản mô hình mới theo cách hàng loạt bằng cách sử dụng Chuyển đổi hàng loạt Sagemaker. Điều này có nghĩa là quá trình chạy biến đổi hàng loạt có thể kiểm tra dữ liệu đã được thu thập trong nhiều tuần hoặc nhiều tháng chỉ trong vài giờ. Điều này có thể tăng tốc đáng kể quá trình đánh giá mô hình so với việc chạy hai hoặc nhiều phiên bản của mô hình thời gian thực cạnh nhau và gửi các yêu cầu dự đoán trùng lặp đến mỗi điểm cuối. Ngoài việc tìm kiếm phiên bản hoạt động tốt hơn nhanh hơn, cách tiếp cận này cũng sử dụng tài nguyên máy tính trong một khoảng thời gian ngắn hơn, giảm chi phí tổng thể.

Một thách thức với cách tiếp cận thử nghiệm này là bộ tính năng thay đổi từ phiên bản mô hình này sang phiên bản mô hình khác. Trong trường hợp này, chúng tôi khuyên bạn nên tạo một bộ tính năng với một tập hợp các tính năng cho cả hai phiên bản để tất cả các tính năng có thể được truy vấn cùng một lúc và được ghi lại thông qua việc thu thập dữ liệu. Sau đó, mỗi lệnh gọi dự đoán chỉ có thể hoạt động trên những tính năng cần thiết cho phiên bản hiện tại của mô hình.

Như một phần thưởng bổ sung, bằng cách tích hợp Làm rõ Amazon SageMaker trong thử nghiệm mô hình ngoại tuyến của mình, bạn có thể kiểm tra phiên bản mới của mô hình để biết độ lệch và cũng có thể so sánh phân bổ tính năng với phiên bản trước của mô hình. Với đường ống, bạn có thể sắp xếp toàn bộ quy trình làm việc để sau khi đào tạo, bước kiểm tra chất lượng có thể diễn ra để thực hiện phân tích các chỉ số mô hình và tầm quan trọng của tính năng. Các chỉ số này được lưu trữ trong Đăng ký mô hình SageMaker để so sánh trong lần đào tạo tiếp theo.

Tích hợp và kiểm tra hiệu suất

Kiểm tra tích hợp là cần thiết để xác nhận các quy trình kinh doanh đầu cuối từ góc độ chức năng cũng như hiệu suất thời gian chạy. Trong quá trình này, toàn bộ đường ống phải được kiểm tra, bao gồm tìm nạp và tính toán các tính năng trong kho tính năng và chạy ứng dụng ML. Điều này nên được thực hiện với nhiều loại trọng tải khác nhau để đáp ứng nhiều tình huống và yêu cầu khác nhau và đạt được mức độ phù hợp cao cho tất cả các lần chạy mã có thể. Điều này giải quyết các thách thức 4 và 9 (kiểm tra quy trình kinh doanh và hiệu suất hoạt động) để đảm bảo không có quy trình kinh doanh nào bị hỏng với phiên bản mới của mô hình.

Thử nghiệm này nên được thực hiện trong một môi trường dàn dựng.

Cả kiểm tra tích hợp và kiểm tra hiệu suất đều cần được thực hiện bởi các nhóm riêng lẻ bằng cách sử dụng đường ống MLOps của họ. Đối với thử nghiệm tích hợp, chúng tôi đề xuất phương pháp đã thử và đã thử nghiệm là duy trì môi trường tiền sản xuất tương đương về chức năng và thử nghiệm với một số trọng tải khác nhau. Quy trình thử nghiệm có thể được tự động hóa như được hiển thị trong hội thảo này. Để kiểm tra hiệu suất, bạn có thể sử dụng Người đề xuất suy luận của Amazon SageMaker, cung cấp một điểm khởi đầu tuyệt vời để xác định loại phiên bản nào và số lượng phiên bản đó sẽ sử dụng. Đối với điều này, bạn sẽ cần sử dụng công cụ tạo tải, chẳng hạn như các dự án nguồn mở nhà sản xuất nước hoa và tăng kích thước mà Intuit đã phát triển. Perfsizesagemaker cho phép bạn tự động kiểm tra cấu hình điểm cuối của mô hình với nhiều yêu cầu về tải trọng, thời gian phản hồi và giao dịch cao nhất trên giây. Nó tạo ra kết quả kiểm tra chi tiết để so sánh các phiên bản mô hình khác nhau. Perfsize là công cụ đồng hành thử các cấu hình khác nhau chỉ cung cấp các giao dịch cao nhất mỗi giây và thời gian phản hồi dự kiến.

Thử nghiệm A / B

Trong nhiều trường hợp yêu cầu phản ứng của người dùng với đầu ra ngay lập tức của mô hình, chẳng hạn như các ứng dụng thương mại điện tử, đánh giá chức năng của mô hình ngoại tuyến là không đủ. Trong các tình huống này, bạn cần A / B kiểm tra các mô hình đang sản xuất trước khi đưa ra quyết định cập nhật mô hình. Thử nghiệm A / B cũng có rủi ro vì có thể có tác động thực sự đến khách hàng. Phương pháp kiểm tra này đóng vai trò là xác nhận hiệu suất ML cuối cùng, một kiểm tra kỹ thuật nhẹ. Phương pháp này cũng giải quyết các thách thức 8 và 9 (hiệu suất mô hình trực tuyến và sự xuất sắc trong hoạt động).

Thử nghiệm A / B nên được thực hiện trong môi trường sản xuất.

Với SageMaker, bạn có thể dễ dàng thực hiện thử nghiệm A / B trên các mô hình ML bằng cách chạy nhiều biến thể sản xuất trên một điểm cuối. Lưu lượng truy cập có thể được chuyển theo từng bước sang phiên bản mới để giảm rủi ro mà một mô hình hoạt động kém có thể xảy ra khi sản xuất. Nếu kết quả của bài kiểm tra A / B có vẻ tốt, lưu lượng truy cập sẽ được chuyển đến phiên bản mới, cuối cùng sẽ chiếm hơn 100% lưu lượng truy cập. Chúng tôi khuyên bạn nên sử dụng các lan can triển khai để chuyển đổi từ mô hình A sang B. Để có một cuộc thảo luận đầy đủ hơn về thử nghiệm A / B bằng cách sử dụng Cá nhân hóa Amazon mô hình làm ví dụ, hãy tham khảo Sử dụng thử nghiệm A / B để đo lường hiệu quả của các đề xuất do Amazon Personalize tạo ra.

Kiểm tra mô hình trực tuyến

Trong trường hợp này, phiên bản mới của một mô hình khác đáng kể so với phiên bản đã phục vụ lưu lượng truy cập trực tiếp trong quá trình sản xuất, do đó, phương pháp thử nghiệm ngoại tuyến không còn phù hợp để xác định hiệu quả của phiên bản mô hình mới. Lý do nổi bật nhất cho điều này là sự thay đổi trong các tính năng cần thiết để tạo ra dự đoán, do đó các giao dịch đã ghi trước đó không thể được sử dụng để kiểm tra mô hình. Trong trường hợp này, chúng tôi khuyên bạn nên sử dụng triển khai bóng. Triển khai bóng cung cấp khả năng triển khai bóng đổ (hoặc thách thức) mô hình cùng với sản xuất (hoặc nhà vô địch) mô hình hiện đang cung cấp các dự đoán. Điều này cho phép bạn đánh giá cách mô hình bóng hoạt động trong lưu lượng sản xuất. Các dự đoán của mô hình bóng không được cung cấp cho ứng dụng yêu cầu; chúng được ghi lại để đánh giá ngoại tuyến. Với phương pháp tiếp cận bóng để thử nghiệm, chúng tôi giải quyết các thách thức 4, 5, 6 và 7 (thử nghiệm quy trình kinh doanh, chi phí, bảo mật và khả năng mở rộng cửa hàng tính năng).

Thử nghiệm mô hình trực tuyến nên được thực hiện trong môi trường dàn dựng hoặc sản xuất.

Phương pháp kiểm tra các phiên bản mô hình mới này nên được sử dụng như một phương sách cuối cùng nếu tất cả các phương pháp khác không thể sử dụng được. Chúng tôi khuyên bạn nên sử dụng phương pháp cuối cùng vì các cuộc gọi song công đến nhiều mô hình tạo ra tải bổ sung cho tất cả các dịch vụ hạ nguồn trong quá trình sản xuất, điều này có thể dẫn đến tắc nghẽn hiệu suất cũng như tăng chi phí sản xuất. Tác động rõ ràng nhất mà điều này có là đối với lớp phân phát tính năng. Đối với các trường hợp sử dụng chia sẻ các tính năng từ một nhóm dữ liệu vật lý chung, chúng tôi cần có khả năng mô phỏng nhiều trường hợp sử dụng đồng thời truy cập vào cùng một bảng dữ liệu để đảm bảo không tồn tại sự tranh chấp tài nguyên trước khi chuyển sang sản xuất. Bất cứ khi nào có thể, nên tránh các truy vấn trùng lặp đến cửa hàng tính năng và các tính năng cần thiết cho cả hai phiên bản của mô hình nên được sử dụng lại cho suy luận thứ hai. Cửa hàng tính năng dựa trên Máy phát điện Amazon, như Intuit đã xây dựng, có thể triển khai Trình tăng tốc Amazon DynamoDB(DAX) để lưu vào bộ nhớ cache và tránh nhân đôi I / O vào cơ sở dữ liệu. Những tùy chọn này và các tùy chọn bộ nhớ đệm khác có thể giảm thiểu thách thức 7 (khả năng mở rộng cửa hàng tính năng).

Để giải quyết thách thức 5 (chi phí) cũng như 7, chúng tôi đề xuất sử dụng triển khai bóng để lấy mẫu lưu lượng đến. Điều này cung cấp cho chủ sở hữu mô hình một lớp kiểm soát khác để giảm thiểu tác động đến hệ thống sản xuất.

Việc triển khai Shadow nên được tích hợp vào Màn hình mẫu cung cấp giống như triển khai sản xuất thông thường để quan sát những cải tiến của phiên bản thách thức.

Kết luận

Bài đăng này minh họa các khối xây dựng để tạo ra một bộ quy trình và công cụ toàn diện nhằm giải quyết các thách thức khác nhau với thử nghiệm mô hình. Mặc dù mỗi tổ chức là duy nhất, điều này sẽ giúp bạn bắt đầu và thu hẹp các cân nhắc khi thực hiện chiến lược thử nghiệm của riêng mình.

---

Giới thiệu về tác giả

Tobias Wenzel là Giám đốc Kỹ thuật Phần mềm cho Nền tảng Máy học Intuit ở Mountain View, California. Anh ấy đã làm việc trên nền tảng này kể từ khi thành lập vào năm 2016 và đã giúp thiết kế và xây dựng nó từ đầu. Trong công việc của mình, anh ấy đã tập trung vào sự xuất sắc trong hoạt động của nền tảng và mang lại thành công cho nó thông qua hoạt động kinh doanh theo mùa của Intuit. Ngoài ra, anh ấy còn đam mê liên tục mở rộng nền tảng với các công nghệ mới nhất.

Shivanshu Upadhyay là Kiến trúc sư giải pháp chính trong nhóm Các ngành chiến lược và phát triển kinh doanh của AWS. Với vai trò này, anh ấy giúp hầu hết những người áp dụng AWS tiên tiến chuyển đổi ngành của họ bằng cách sử dụng hiệu quả dữ liệu và AI.

Alan Tấn là Giám đốc Sản phẩm Cấp cao của SageMaker, dẫn đầu nỗ lực về suy luận mô hình lớn. Anh ấy đam mê ứng dụng học máy vào lĩnh vực phân tích. Ngoài công việc, anh ấy thích hoạt động ngoài trời.