Ngay cả khi có một bộ công cụ MLOps hoàn hảo, các nhóm vẫn gặp khó khăn trong việc cung cấp các sản phẩm ML. Vì vậy, nếu các công cụ không phải là mảnh ghép duy nhất, thì nó để lại gì? Trong bài đăng cuối cùng của tôi , tôi tranh luận những phần còn lại là Văn hóa và Quy trình.

Hãy đi sâu vào quy trình MLOps — cụ thể là một số phần cơ bản mà hầu hết các đội đều mắc sai lầm . Quy trình MLOps thành công trông như thế nào và các học viên ML riêng lẻ có thể giúp xây dựng quy trình đó như thế nào?

TL;DR

• Bắt đầu với một sản phẩm, không phải là một mô hình
• Khảo sát dữ liệu trong sản xuất , không phải trong kho của bạn
• Bắt đầu đơn giản — với dữ liệu và mô hình
• Hợp tác với các kỹ sư

Bắt đầu với một sản phẩm ML

Có lẽ cách thực hành quan trọng nhất giúp các dự án ML thành công là thiết kế một sản phẩm chứ không phải một mô hình . Một trong những cạm bẫy lớn nhất mà tôi từng thấy ở hàng chục công ty là giao “dự án” cho các nhóm dữ liệu, thay vì để họ tham gia vào giai đoạn thiết kế sản phẩm.

Để xây dựng một sản phẩm ML thành công, ba bên liên quan cần tham gia vào quá trình thiết kế sản phẩm:

• PM / Business Stakeholder : Thành công trông như thế nào?
• Người ML : Điều gì (có khả năng) có thể xảy ra với ML?
• Kỹ sư sản phẩm : Điều gì khả thi và những hạn chế là gì?

Một số ví dụ về các nhóm liên kết kém:

• Người ML tối ưu hóa độ chính xác của mô hình (thay vì kết quả kinh doanh!)
• Các dự án đã bắt đầu có thể không khả thi để giải quyết bằng ML
• Mô hình không đáp ứng các ràng buộc về hiệu suất trong sản xuất
• Các tính năng khó hoặc không thể tính toán trong sản xuất

• Người học máy hiểu được sự đánh đổi giữa độ chính xác và thời gian đưa ra thị trường
• Giám sát được xây dựng vào ngày đầu tiên để đảm bảo kết quả kinh doanh được đo lường một cách nhất quán
• Kỹ sư giúp người ML hiểu bối cảnh dữ liệu sản xuất
• SLA mẫu được xác định và đo lường rõ ràng

Đây là một ví dụ về “căn chỉnh tốt” trong phần trước, nhưng nó xứng đáng có phần riêng. Hầu hết tất cả các nhà xây dựng ML mà tôi từng thấy đều bắt đầu các dự án ML của họ bằng một cuộc khảo sát về dữ liệu có sẵn. Vấn đề? Họ thường khảo sát dữ liệu có sẵn để đào tạo chứ không phải dữ liệu sẽ có sẵn trong quá trình sản xuất.

Một số người có thể hỏi - không phải tất cả dữ liệu có sẵn để đào tạo đều có sẵn trong một hệ thống sản xuất sao?

Hầu hết thời gian, câu trả lời là có , nhưng với một loạt dấu hoa thị. Dữ liệu đó có sẵn nhanh như thế nào? Làm thế nào mới là dữ liệu đó? Bao nhiêu tiền xử lý cần phải được thực hiện trên dữ liệu sản xuất để làm cho nó có thể tiêu thụ được? Ai sở hữu dữ liệu đó?

Vì vậy, nhiều dự án ML bị đình trệ do các vấn đề với dữ liệu sản xuất. Tôi đã nhiều lần thấy rằng có sự khác biệt lớn giữa người học máy và kỹ sư sản phẩm. Một ví dụ về hai tính năng vô hại với các yêu cầu khác nhau đáng kể:

• Mã zip nhà của người dùng : có thể rất đơn giản để sử dụng trong sản xuất. Truy vấn một cơ sở dữ liệu.
• Vị trí trung bình của người dùng trong năm phút qua : có thể là PITA! Dữ liệu vị trí của người dùng có trên Luồng Kafka? Nó cần phải tươi như thế nào? Tập hợp phát trực tuyến rất khó! Có lẽ các vấn đề về đào tạo / phục vụ sai lệch!

bắt đầu đơn giản

Có lẽ là lời khuyên ML phổ biến nhất, nhưng đó là lời khuyên tốt. Bắt đầu với một giải pháp đơn giản.

Bổ sung của tôi - hầu hết mọi người sẽ bảo bạn bắt đầu với một mô hình đơn giản , nhưng điều quan trọng không kém là bắt đầu với dữ liệu đơn giản! Để giải quyết ví dụ trên:

• Vị trí trung bình của người dùng trong năm phút qua: cứng
• Vị trí gần đây nhất của người dùng: có thể dễ dàng hơn nhiều!

Bạn có thể thực hiện giao dịch đó mọi lúc. Bạn luôn có thể xây dựng phiên bản V2 với tính năng đẹp hơn và việc xây dựng các cải tiến gia tăng sẽ dễ dàng hơn nhiều so với việc gửi một thứ gì đó phức tạp ngay lần đầu tiên.

Hợp tác với các kỹ sư

Điều lạ lùng là nếu bạn là một nhà khoa học dữ liệu, không phải tất cả các câu hỏi đặt ra ở trên đều rõ ràng để trả lời. Lần cuối cùng tôi bắt tay vào xây dựng các mô hình ML, tôi không biết truyền dữ liệu là gì (chưa nói đến cách nghĩ về nó).

Giải pháp là kết bạn với các kỹ sư và làm việc với họ trong suốt quá trình phát triển mô hình ML. Việc xây dựng bất kỳ dự án phần mềm nào không thể được thực hiện trong một silo và ML trong một silo thậm chí còn tệ hơn. Các kỹ sư có thể trợ giúp về "dữ liệu nào có sẵn", "tôi nên biết về những hạn chế nào", "SLA nào khả thi" và hơn thế nữa.

Làm việc với một kỹ sư sớm và thường xuyên. Bạn sẽ xây dựng các dự án nhanh hơn.

Sự kết luận

Các bước này không phải là cái nhìn toàn diện về quy trình MLOps — có rất nhiều phần chuyển động dẫn đến thành công (đánh giá mã, CI/CD, giám sát,…). Đây là một điểm khởi đầu. Như đã đề cập ở trên, hầu hết các lỗi ML mà tôi từng thấy là do sự cố căn chỉnh. Các nguyên tắc quy trình này chủ yếu nhằm giúp bạn sắp xếp nhóm của mình để đạt được thành công.

Bạn cần một nền tảng vững chắc để xây dựng một phương pháp MLOps đặc biệt.

David Hershey là nhà đầu tư tại Unusual Ventures , nơi ông đầu tư vào máy học và cơ sở hạ tầng dữ liệu. David bắt đầu sự nghiệp của mình tại Ford Motor Company, nơi anh thành lập nhóm cơ sở hạ tầng ML của họ. Gần đây, anh làm việc tại Tecton và AI xác định , giúp các nhóm MLOps áp dụng các công nghệ đó. Nếu bạn đang xây dựng một công ty cơ sở hạ tầng máy học hoặc dữ liệu, hãy liên hệ với David trên LinkedIn .