Hướng dẫn chi tiết nhất về MLOps: Phần 1

Xin chào Hackernoon! Trong bài viết này, tôi sẽ thảo luận chi tiết về khái niệm MLOps. Hơn nữa, tôi sẽ làm điều đó theo 3 cách. Đầu tiên, về mặt lý thuyết - thông qua sơ đồ MLOps hợp lý nhất. Sau đó, về mặt khái niệm, thông qua các tạo tác được đưa vào phương pháp tiếp cận. Và cuối cùng, thông qua việc hiểu MLOps như một hệ thống thông tin.

Vì vậy, hãy bắt đầu.

MLOps là gì?

Câu hỏi này từ lâu đã chiếm giữ tâm trí của nhiều nhóm phát triển hệ thống ML. Bằng hệ thống như vậy trong bài viết này, tôi sẽ hiểu một hệ thống thông tin, một hoặc nhiều thành phần trong đó chứa một mô hình được đào tạo để thực hiện một phần nào đó của logic nghiệp vụ tổng thể.

Giống như bất kỳ thành phần nào khác của hệ thống, phần logic kinh doanh này cần được cập nhật để đáp ứng những mong đợi luôn thay đổi của doanh nghiệp và khách hàng. MLOps là tất cả về bản cập nhật thường xuyên này.

Định nghĩa và giải thích MLOps

Vẫn chưa có một định nghĩa duy nhất và được thống nhất về MLOps. Nhiều tác giả đã cố gắng đưa ra nhưng thật khó để tìm được một mô tả rõ ràng và có hệ thống cùng một lúc.

Có một cái có thể được coi là như vậy:

MLOps là một chuyên ngành kỹ thuật nhằm mục đích thống nhất việc phát triển hệ thống ML (nhà phát triển) và triển khai hệ thống ML để chuẩn hóa và hợp lý hóa việc cung cấp liên tục các mô hình hiệu suất cao trong sản xuất.

Hãy nêu bật những phần quan trọng của định nghĩa MLOps:

• Kỷ luật kỹ thuật
• Nhằm mục đích thống nhất các quy trình phát triển và triển khai hệ thống ML
• Tiêu chuẩn hóa và tối ưu hóa việc phân phối liên tục các phiên bản mới
• Mô hình hiệu suất cao

Vì vậy, MLOps là một loại DevOps dành cho mô hình ML.

Lịch sử xuất hiện của MLOps

Thật dễ dàng để tin rằng ngành kỹ thuật như vậy bắt nguồn từ một công ty CNTT lớn. Vì vậy, chúng ta có thể tin tưởng vào giả thuyết rằng MLOps, như một cách tiếp cận có ý nghĩa, bắt nguồn từ Google, nơi D. Sculley đang cố gắng tiết kiệm thời gian và thần kinh của mình khỏi những công việc nhàm chán xung quanh việc xuất các mô hình ML sang các tiện ích mở rộng. D. Sculley hiện được biết đến rộng rãi với biệt danh "Bố già của MLOps" - podcast cùng tên rất dễ tìm thấy trên mạng.

D. Sculley bắt đầu xem xét công việc với các mô hình từ quan điểm nợ kỹ thuật của nhóm. Có, có thể nhanh chóng phát hành các phiên bản mới của mô hình, nhưng chi phí hỗ trợ hệ thống thu được sẽ ảnh hưởng đáng kể đến ngân sách của công ty.

Công việc của ông đã dẫn đến bài báo "Nợ kỹ thuật ẩn trong hệ thống máy học " được xuất bản vào năm 2015 tại hội nghị NeurIPS. Ngày xuất bản bài viết này có thể được coi là điểm khởi đầu cho sự tồn tại của MLOps.

Mức độ trưởng thành của MLOps: các mô hình nổi tiếng nhất

Giống như hầu hết các quy trình CNTT, MLOps có mức độ trưởng thành. Chúng giúp các công ty hiểu họ đang ở đâu và làm thế nào họ có thể chuyển sang cấp độ tiếp theo (nếu có mục tiêu như vậy). Ngoài ra, các phương pháp xác định thời hạn được chấp nhận chung cho phép bạn xác định vị trí của mình giữa các đối thủ cạnh tranh.

Mô hình trưởng thành GigaOm MLOps

Mô hình được mô tả kỹ lưỡng và dễ hiểu nhất là của công ty phân tích GigaOm . Nó gần nhất với Tích hợp mô hình trưởng thành năng lực (CMMI) của tất cả các mô hình. Đây là một bộ phương pháp cải thiện quy trình tổ chức, cũng bao gồm 5 cấp độ - từ 0 đến 4.

Mô hình từ GigaOm giải thích từng cấp độ trưởng thành thông qua 5 loại: chiến lược, kiến trúc, mô hình hóa, quy trình và quản trị.

Được hướng dẫn bởi mô hình này trong giai đoạn đầu xây dựng hệ thống ML, bạn có thể suy nghĩ trước về các khía cạnh thiết yếu và giảm nguy cơ thất bại. Việc chuyển từ cấp độ trưởng thành này lên cấp độ cao hơn sẽ đặt ra cho nhóm những thách thức mới mà trước đây họ có thể chưa nhận ra.

Mô hình trưởng thành MLOps của Google

Điều đáng chú ý là Google cũng có mô hình mức độ trưởng thành MLOps . Đó là một trong những người đầu tiên xuất hiện. Nó ngắn gọn và bao gồm 3 cấp độ:

• Cấp độ 0: Quy trình thủ công
• Cấp độ 1: Tự động hóa đường ống ML
• Cấp độ 2: Tự động hóa đường ống CI/CD

Thật khó để thoát khỏi suy nghĩ rằng mô hình này giống như một cuốn sách hướng dẫn vẽ một con cú. Đầu tiên, hãy làm mọi thứ bằng tay, lắp ráp các đường dẫn ML và hoàn thiện MLOps. Điều đó nói rằng, nó được mô tả tốt.

Mô hình trưởng thành Azure MLOps

Ngày nay, nhiều công ty lớn sử dụng ML đã biên soạn các mô hình trưởng thành của họ. Azure , sử dụng cách tiếp cận tương tự để phân biệt các cấp độ, cũng được đưa vào. Tuy nhiên, có nhiều trong số chúng hơn Google:

• Cấp độ 0: Không có MLOps
• Cấp độ 1: DevOps nhưng không có MLOps
• Cấp độ 2: Đào tạo tự động
• Cấp độ 3: Triển khai mô hình tự động
• Cấp độ 4: Hoạt động tự động hoàn toàn MLOps

Tất cả các mô hình nổi bật đều hội tụ về một điều. Ở mức độ 0, họ không có bất kỳ hoạt động ML nào. Ở cấp độ cuối cùng, họ có khả năng tự động hóa các quy trình MLOps. Luôn có điều gì đó khác biệt ở giữa liên quan đến quá trình tự động hóa quy trình gia tăng. Azure có tính năng tự động hóa quá trình đào tạo và sau đó triển khai mô hình.

Khung khái niệm MLOps

Bạn mô tả tất cả các quy trình liên quan đến khái niệm MLOps như thế nào? Điều đáng ngạc nhiên là ba người Đức - tác giả của bài báo " Hoạt động học máy (MLOps): Tổng quan, Định nghĩa và Kiến trúc " - thậm chí còn tìm cách gói gọn chúng trong một sơ đồ. Họ đã tiến hành một nghiên cứu thực tế và mô tả khái niệm MLOps một cách chi tiết.

Nó có thể đáng sợ vì nó có nhiều yếu tố tương tác với nhau. Tuy nhiên, có thể tìm thấy nhiều đặc điểm của mức độ trưởng thành nêu trên trong đó. Ít nhất là Đường ống tự động, CI/CD, Giám sát, Đăng ký mô hình, Điều phối quy trình công việc và Thành phần cung cấp.

Hãy thảo luận về sơ đồ này và nói về từng sơ đồ chi tiết hơn.

Quy trình cốt lõi MLOps

Các phần chính của sơ đồ là các khối ngang, trong đó các khía cạnh thủ tục của MLOps được mô tả (chúng được gán các chữ cái A, B, C và D). Mỗi người trong số họ được thiết kế để giải quyết các nhiệm vụ cụ thể trong khuôn khổ đảm bảo hoạt động trơn tru các dịch vụ ML của công ty. Để dễ hiểu sơ đồ, tốt hơn là nên bắt đầu không theo thứ tự.

Thử nghiệm

Nếu một công ty có dịch vụ ML, nhân viên sẽ làm việc trong Jupyter. Ở nhiều công ty, đây là công cụ tập trung vào tất cả các quy trình phát triển ML. Đây là nơi bắt đầu hầu hết các nhiệm vụ yêu cầu triển khai thực hành MLOps.

Hãy xem xét một ví dụ. Công ty A cần tự động hóa một phần của một số quy trình bằng cách sử dụng máy học (giả sử rằng có một bộ phận và chuyên gia tương ứng). Khó có thể biết trước cách giải quyết nhiệm vụ. Vì vậy, người thực thi cần nghiên cứu cách trình bày vấn đề và thử nghiệm các cách khả thi để hiện thực hóa nó.

Để thực hiện điều này, kỹ sư ML/nhà phát triển ML viết mã để triển khai các tác vụ khác nhau và đánh giá kết quả thu được theo các chỉ số mục tiêu. Tất cả điều này hầu như luôn được thực hiện trong Jupyter Lab. Ở dạng như vậy, cần phải nắm bắt nhiều thông tin quan trọng theo cách thủ công và sau đó so sánh việc triển khai giữa chúng.

Hoạt động như vậy được gọi là thử nghiệm. Điều đó có nghĩa là có được một mô hình ML đang hoạt động, mô hình này có thể được sử dụng thêm để giải quyết các vấn đề liên quan.

Khối C hiển thị trong sơ đồ mô tả quá trình tiến hành thí nghiệm ML.

Phân tích dữ liệu có sẵn trong phạm vi nhiệm vụ

Nhiều quyết định trong phát triển ML được đưa ra dựa trên việc phân tích dữ liệu có sẵn trong công ty. Không thể đào tạo một mô hình với các số liệu chất lượng mục tiêu trên dữ liệu chất lượng thấp hoặc dữ liệu không tồn tại.

Do đó, điều quan trọng là phải tìm ra dữ liệu nào chúng ta đã nhận được và chúng ta có thể làm gì với dữ liệu đó. Ví dụ: để làm điều này, chúng ta có thể:

• Tiến hành nghiên cứu ADHoc bằng Jupyter hoặc Superset
• EDA tiêu chuẩn (Phân tích dữ liệu thăm dò)

Sự hiểu biết tốt hơn về dữ liệu chỉ có thể đạt được khi kết hợp với phân tích ngữ nghĩa và cấu trúc.

Tuy nhiên, đôi khi việc chuẩn bị dữ liệu nằm trong tầm kiểm soát của nhóm dự án. Trong trường hợp này, những khó khăn bổ sung được đảm bảo. Đôi khi ở giai đoạn này, rõ ràng là không có ích gì khi phát triển dự án thêm vì dữ liệu không phù hợp cho công việc.

Hình thành bộ dữ liệu chất lượng

Khi đã tin tưởng vào dữ liệu có sẵn thì cần phải nghĩ đến các quy tắc tiền xử lý. Ngay cả khi có một tập dữ liệu phù hợp lớn nhưng cũng không có gì đảm bảo rằng nó không chứa những thiếu sót, giá trị bị bóp méo, v.v.. Nên nhắc đến thuật ngữ “chất lượng dữ liệu đầu vào” và cụm từ nổi tiếng “Rác vào - rác ra” đây.

Cho dù mô hình được sử dụng tốt đến đâu thì nó cũng sẽ tạo ra kết quả kém trên dữ liệu chất lượng thấp. Trong thực tế, nhiều nguồn lực của dự án được sử dụng để tạo ra bộ dữ liệu chất lượng cao.

Đào tạo và xác nhận mô hình ML

Sau giai đoạn trước, việc xem xét các số liệu của mô hình đã huấn luyện khi tiến hành thử nghiệm là điều hợp lý. Trong khuôn khổ khối đang được xem xét, thử nghiệm bao gồm liên kết đào tạo và xác thực mô hình ML.

Thử nghiệm bao gồm sơ đồ cổ điển để huấn luyện phiên bản mô hình mong muốn với tập hợp siêu tham số đã chọn trên tập dữ liệu đã chuẩn bị. Với mục đích này, bản thân tập dữ liệu được chia thành các mẫu đào tạo, kiểm tra và xác nhận:

• Hai cái đầu tiên được sử dụng để chọn bộ siêu tham số tối ưu
• Bước thứ ba là xác minh và xác nhận cuối cùng rằng mô hình được huấn luyện trên tập siêu tham số đã chọn hoạt động phù hợp trên dữ liệu chưa xác định không tham gia vào quá trình lựa chọn và huấn luyện siêu tham số

Bạn có thể đọc thêm về các mẫu xác nhận trong bài viết này .

Lưu mã và siêu tham số trong kho lưu trữ

Nếu số liệu học tập mô hình tốt thì mã mô hình và các tham số đã chọn sẽ được lưu trữ trong kho lưu trữ của công ty.

Mục tiêu cơ bản của quá trình thử nghiệm là kỹ thuật mô hình, bao gồm việc lựa chọn thuật toán tốt nhất và lựa chọn điều chỉnh siêu tham số tốt nhất.

Khó khăn khi tiến hành thử nghiệm là nhà phát triển cần kiểm tra nhiều tổ hợp tham số vận hành mô hình ML. Và chúng ta không nói về các biến thể khác nhau của bộ máy toán học đã sử dụng.

Nói chung, nó cần có công việc. Và phải làm gì nếu không đạt được số liệu mong muốn trong khuôn khổ kết hợp các tham số mô hình?

Kỹ thuật tính năng

Nếu không thể đạt được số liệu mong muốn của hoạt động mô hình ML, bạn có thể thử mở rộng mô tả tính năng của các đối tượng tập dữ liệu bằng các tính năng mới. Nhờ chúng, bối cảnh của mô hình sẽ mở rộng và do đó, các số liệu mong muốn có thể được cải thiện.

Các tính năng mới có thể bao gồm:

• Đối với dữ liệu dạng bảng: các phép biến đổi tùy ý của các thuộc tính đối tượng đã tồn tại - ví dụ: X^2, SQRT(X), Log(x), X1*X2, v.v.
• Dựa vào đối tượng: chỉ số khối cơ thể, số lần trả nợ quá hạn trong một năm, v.v.

Chúng ta hãy xem phần sơ đồ liên quan đến Kỹ thuật tính năng.

Khối B1 nhằm mục đích hình thành một tập hợp các yêu cầu để chuyển đổi dữ liệu nguồn có sẵn và thu được các tính năng từ chúng. Bản thân việc tính toán các thành phần được thực hiện từ những dữ liệu đã được xử lý trước và làm sạch này theo các "công thức" do nhà phát triển ML nhập vào.

Điều cần thiết là phải nói rằng làm việc với các tính năng là lặp đi lặp lại. Áp dụng một tập hợp các tính năng, một ý tưởng mới có thể nảy ra trong đầu, được hiện thực hóa bằng một tập hợp các tính năng khác, v.v., đến vô tận. Điều này được thể hiện rõ ràng trong sơ đồ dưới dạng Vòng phản hồi.

Khối B2 mô tả quá trình ngay lập tức thêm các tính năng mới vào dữ liệu.

Kết nối và truy xuất nguồn dữ liệu là các hoạt động kỹ thuật có thể khá phức tạp. Để đơn giản cho việc giải thích, tôi sẽ giả định rằng có một số nguồn mà nhóm có quyền truy cập và các công cụ để tải dữ liệu từ các nguồn này (ít nhất là các tập lệnh Python).

Làm sạch và chuyển đổi dữ liệu. Giai đoạn này gần như thực hiện bước tương tự trong khối thí nghiệm (C) – chuẩn bị số liệu. Ngay từ khi bắt đầu các thử nghiệm đầu tiên, bạn đã hiểu được dữ liệu nào và định dạng nào cần thiết để đào tạo các mô hình ML. Tất cả những gì còn lại là tạo và thử nghiệm các tính năng mới một cách chính xác, nhưng quy trình chuẩn bị dữ liệu cho mục đích này phải được tự động hóa nhiều nhất có thể.

Tính toán các tính năng mới. Như đã lưu ý ở trên, những hành động này có thể chỉ bao gồm việc chuyển đổi một vài phần tử của bộ dữ liệu. Một tùy chọn khác là chạy một quy trình xử lý lớn riêng biệt để thêm một tính năng duy nhất vào cùng một bộ dữ liệu. Dù bằng cách nào thì cũng có một tập hợp các hành động được thực hiện tuần tự.

Thêm kết quả. Kết quả của các hành động trước đó sẽ được thêm vào tập dữ liệu. Thông thường, các tính năng được thêm vào tập dữ liệu theo đợt để giảm tải cơ sở dữ liệu. Nhưng đôi khi cần phải thực hiện một cách nhanh chóng (streaming) để tăng tốc độ thực hiện các nhiệm vụ kinh doanh.

Điều cần thiết là phải sử dụng các tính năng thu được một cách hiệu quả nhất có thể: lưu và tái sử dụng chúng trong các nhiệm vụ của các nhà phát triển ML khác của công ty. Chương trình này có một cửa hàng Tính năng cho mục đích này. Nó phải có sẵn trong công ty, được quản lý riêng biệt và được phiên bản hóa tất cả các tính năng có trong đó. Kho tính năng có 2 phần: trực tuyến (dành cho tập lệnh phát trực tuyến) và ngoại tuyến (đối với tập lệnh bó).

Quy trình làm việc ML tự động

Ở đầu bài viết, tôi đã chỉ ra rằng hệ thống ML có nghĩa là một hệ thống thông tin, một hoặc nhiều thành phần trong đó chứa một mô hình được đào tạo để thực hiện một số phần của logic kinh doanh tổng thể. Mô hình ML thu được càng tốt do phát triển thì hiệu quả hoạt động của nó càng lớn. Một mô hình được đào tạo sẽ xử lý luồng yêu cầu đến và đưa ra một số dự đoán phản hồi, từ đó tự động hóa một số phần của quá trình phân tích hoặc ra quyết định.

Quá trình sử dụng một mô hình để tạo ra các dự đoán được gọi là suy luận và việc huấn luyện một mô hình được gọi là huấn luyện. Bạn có thể mượn lời giải thích rõ ràng về sự khác biệt giữa 2 loại này từ Gartner. Ở đây tôi sẽ thực hành trên mèo.

Để hệ thống ML sản xuất hoạt động hiệu quả, điều quan trọng là phải theo dõi các số liệu suy luận của mô hình. Ngay sau khi chúng bắt đầu giảm, mô hình phải được đào tạo lại hoặc thay thế bằng mô hình mới. Thông thường, nó xảy ra do những thay đổi trong dữ liệu đầu vào (trôi dữ liệu). Ví dụ: có một vấn đề kinh doanh trong đó mô hình có thể nhận ra những chiếc bánh nướng nhỏ trong ảnh và lấy thông tin này làm đầu vào. Những chú chó Chihuahua trong ví dụ này mang tính cân bằng:

Mô hình trong tập dữ liệu gốc không biết gì về chó Chihuahua nên dự đoán không chính xác. Vì vậy, cần phải thay đổi tập dữ liệu và tiến hành các thí nghiệm mới. Mẫu mới sẽ được sản xuất càng sớm càng tốt. Không ai cấm người dùng tải lên hình ảnh chó Chihuahua nhưng sẽ nhận được kết quả sai.

Bây giờ đến nhiều ví dụ thực tế hơn. Hãy xem xét việc phát triển một hệ thống khuyến nghị cho thị trường.

Dựa trên lịch sử mua hàng của người dùng, giao dịch mua hàng của những người dùng tương tự và các thông số khác, một mô hình hoặc tập hợp các mô hình sẽ tạo ra một khối với các đề xuất. Nó chứa các sản phẩm có doanh thu mua hàng được tính và theo dõi thường xuyên.

Có điều gì đó xảy ra và nhu cầu của khách hàng thay đổi. Do đó, những khuyến nghị của họ không còn phù hợp nữa. Nhu cầu về các sản phẩm được đề xuất giảm xuống. Tất cả điều này dẫn đến giảm doanh thu.

Những người quản lý tiếp theo hét lên và yêu cầu mọi thứ phải được khôi phục vào ngày mai, điều này chẳng dẫn đến kết quả gì. Tại sao? Không có đủ dữ liệu về sở thích của khách hàng mới, vì vậy bạn thậm chí không thể tạo mô hình mới. Bạn có thể sử dụng một số thuật toán cơ bản về tạo đề xuất (lọc cộng tác dựa trên mục) và thêm chúng vào sản xuất. Bằng cách này, các đề xuất sẽ có tác dụng bằng cách nào đó, nhưng đây chỉ là giải pháp tạm thời.

Lý tưởng nhất là quy trình này nên được thiết lập theo cách mà quá trình đào tạo lại hoặc thử nghiệm các mô hình khác nhau được bắt đầu dựa trên các số liệu mà không cần người quản lý yêu cầu họ làm như vậy. Và cái tốt nhất cuối cùng sẽ thay thế cái hiện tại đang được sản xuất. Trong sơ đồ, đây là Đường ống quy trình làm việc ML tự động (khối D), được khởi động bằng trình kích hoạt trong một số công cụ điều phối.

Đây là phần được tải nặng nhất của chương trình. Một số thành phần chính của bên thứ ba có liên quan đến hoạt động của khối D:

• Thành phần điều phối quy trình công việc, chịu trách nhiệm khởi chạy quy trình theo lịch trình hoặc sự kiện được chỉ định
• Cửa hàng tính năng, từ đó lấy dữ liệu về các tính năng cần thiết cho mô hình
• Kho lưu trữ siêu dữ liệu ML và Sổ đăng ký mô hình, nơi đặt các mô hình và số liệu của chúng, thu được sau khi hoạt động của Đường ống đã khởi chạy, được đặt

Cấu trúc của khối tự nó kết hợp các giai đoạn của khối thử nghiệm và phát triển tính năng (B2). Không có gì đáng ngạc nhiên khi đây là những quy trình cần được tự động hóa. Sự khác biệt chính là ở 2 giai đoạn cuối:

• Mô hình xuất khẩu
• Đẩy vào sổ đăng ký mô hình

Các bước còn lại giống hệt như mô tả ở trên.

Riêng biệt, tôi muốn đề cập đến các tạo phẩm dịch vụ được người điều phối yêu cầu để chạy quy trình đào tạo lại mô hình. Đây là mã được lưu trữ trong kho và chạy trên các máy chủ được chọn. Nó được phiên bản và nâng cấp tuân theo tất cả các quy tắc phát triển phần mềm. Mã này triển khai quy trình đào tạo lại mô hình và kết quả phụ thuộc vào tính chính xác của nó.

Thông thường, các công cụ ML khác nhau được chạy trong mã, trong đó việc thực thi các bước của quy trình diễn ra, ví dụ:

• Bộ điều phối luồng không khí chạy mã để thực thi các giai đoạn của đường ống
• Feast tải dữ liệu về các tính năng trong tập dữ liệu theo lệnh
• Sau đó, ClearML tạo một tập dữ liệu mới và chạy thử nghiệm với bộ số liệu hiệu suất mô hình cần thiết mà nó lấy từ kho lưu trữ của chính nó
• Sau khi điều tra hoàn tất, ClearML lưu mô hình và số liệu hiệu suất của nó vào bộ lưu trữ

Điều đáng lưu ý ở đây là nhìn chung không thể tự động hóa các thử nghiệm. Tất nhiên, có thể thêm khái niệm AutoML vào quy trình. Tuy nhiên, hiện tại không có giải pháp nào được công nhận có thể được sử dụng với kết quả tương tự cho bất kỳ đối tượng thử nghiệm nào.

Trong trường hợp chung, AutoML hoạt động như sau:

1. Bằng cách nào đó tạo ra một tập hợp nhiều tham số vận hành mô hình
2. Chạy thử nghiệm cho mỗi kết hợp thu được. Sửa các số liệu cho từng thử nghiệm dựa trên mô hình tốt nhất được chọn
3. AutoML thực hiện tất cả các thao tác mà Nhà khoa học dữ liệu cấp cơ sở/trung cấp sẽ thực hiện trong một vòng tròn các nhiệm vụ tiêu chuẩn ít nhiều

Tự động hóa đã được xử lý một chút. Tiếp theo, chúng ta cần tổ chức đưa phiên bản mới của mô hình vào sản xuất.

Mô hình phục vụ và giám sát

Mô hình ML là cần thiết để tạo dự đoán. Nhưng bản thân mô hình ML là một tệp, không thể tạo ra chúng một cách nhanh chóng như vậy. Bạn thường có thể tìm thấy giải pháp như vậy trên Internet: một nhóm sử dụng FastAPI và viết trình bao bọc Python xung quanh mô hình để bạn có thể “làm theo các vị từ”.

Kể từ thời điểm nhận được tệp mô hình ML, có một số cách có thể diễn ra. Đội có thể đi:

• Viết tất cả mã để xây dựng dịch vụ RESTfull
• Thực hiện tất cả các gói xung quanh nó
• Xây dựng tất cả thành hình ảnh Docker
• Và ở đâu đó từ hình ảnh đó, bạn sẽ xây dựng một thùng chứa
• Quy mô nó bằng cách nào đó
• Tổ chức thu thập các số liệu
• Thiết lập cảnh báo
• Thiết lập quy định tung ra phiên bản mới của mô hình
• Rất nhiều thứ khác

Đây là một nhiệm vụ tốn nhiều công sức để thực hiện việc này cho tất cả các mô hình và duy trì toàn bộ cơ sở mã trong tương lai. Để dễ dàng hơn, các công cụ phục vụ đặc biệt đã xuất hiện, giới thiệu 3 thực thể mới:

• Phiên bản/Dịch vụ suy luận
• Máy chủ suy luận
• Công cụ phục vụ

Phiên bản suy luận hoặc Dịch vụ suy luận là một mô hình ML cụ thể được chuẩn bị để nhận truy vấn và tạo dự đoán phản hồi. Một thực thể như vậy có thể đại diện cho một thực thể phụ trong cụm Kubernetes bằng một thùng chứa mô hình ML cần thiết và công cụ kỹ thuật để chạy nó.

Máy chủ suy luận là người tạo ra các trường hợp/dịch vụ suy luận. Có nhiều cách triển khai Máy chủ suy luận. Mỗi khung có thể hoạt động với các khung ML cụ thể, chuyển đổi các mô hình được đào tạo trong chúng thành các mô hình sẵn sàng sử dụng để xử lý các truy vấn đầu vào và tạo dự đoán.

Công cụ phục vụ thực hiện các chức năng quản lý chính. Nó xác định Máy chủ suy luận nào sẽ được sử dụng, số lượng bản sao của Phiên bản suy luận kết quả sẽ được khởi động và cách mở rộng quy mô của chúng.

Trong sơ đồ đang được xem xét, không có chi tiết nào về các thành phần phục vụ mô hình nhưng các khía cạnh tương tự được nêu ra:

• Thành phần CI/CD, triển khai các mô hình sẵn sàng chạy trong production (có thể coi là một trong những phiên bản của Serve Engine)
• Phục vụ mô hình, trong cơ sở hạ tầng có sẵn, tổ chức sơ đồ tạo dự đoán cho các mô hình ML, cho cả kịch bản phát trực tuyến và hàng loạt (nó có thể được coi là một trong các phiên bản của Máy chủ suy luận)

Để biết ví dụ về ngăn xếp hoàn chỉnh cho Cung cấp, chúng ta có thể tham khảo ngăn xếp từ Seldon:

• Seldon Core là Công cụ phục vụ
• Máy chủ Seldon ML là Máy chủ suy luận, chuẩn bị quyền truy cập vào mô hình thông qua REST hoặc gRPC
• Seldon MLServer Custom Runtime là Phiên bản suy luận, một phiên bản shell cho bất kỳ mô hình ML nào có ví dụ cần được chạy để tạo dự đoán.

Thậm chí còn có một giao thức được tiêu chuẩn hóa để triển khai Cung cấp, việc hỗ trợ cho giao thức này trên thực tế là bắt buộc trong tất cả các công cụ như vậy. Nó được gọi là Giao thức suy luận V2 và được phát triển bởi một số công ty nổi tiếng trên thị trường - KServe, Seldon và Nvidia Triton.

Phục vụ so với Triển khai

Trong nhiều bài viết khác nhau, bạn có thể tìm thấy tài liệu tham khảo về các công cụ Cung cấp và Triển khai dưới dạng một thực thể duy nhất. Tuy nhiên, điều cần thiết là phải hiểu sự khác biệt trong mục đích của cả hai. Đây là một vấn đề còn gây tranh cãi, nhưng bài viết này sẽ trình bày như sau:

• Cung cấp - tạo mô hình API và khả năng nhận dự đoán từ mô hình đó. Cuối cùng, bạn nhận được một phiên bản dịch vụ duy nhất có mô hình bên trong.
• Triển khai - phân phối phiên bản dịch vụ với số lượng cần thiết để xử lý các yêu cầu đến (có thể được biểu diễn dưới dạng bộ bản sao trong triển khai Kubernetes).

Nhiều chiến lược có thể được sử dụng để Triển khai các mô hình , nhưng đây không phải là chiến lược dành riêng cho ML. Nhân tiện, phiên bản trả phí của Seldon hỗ trợ một số chiến lược, vì vậy bạn chỉ cần chọn ngăn xếp này và tận hưởng cách mọi thứ hoạt động.

Hãy nhớ rằng các số liệu hiệu suất của mô hình phải được theo dõi. Nếu không, bạn sẽ không thể giải quyết vấn đề kịp thời. Làm thế nào để theo dõi số liệu một cách chính xác là câu hỏi lớn. Arize AI đã xây dựng toàn bộ hoạt động kinh doanh dựa trên điều này, nhưng chưa ai hủy bỏ Grafana và VictoriaMetrics.

Dự án ban đầu

Với mọi thứ được viết ở trên, hóa ra lệnh ML:

• Tạo tập dữ liệu
• Tiến hành thử nghiệm trên chúng trên các mô hình ML
• Phát triển các tính năng mới để mở rộng bộ dữ liệu và cải thiện chất lượng của mô hình
• Lưu các mô hình tốt nhất trong Sổ đăng ký mô hình để sử dụng lại trong tương lai
• Tùy chỉnh việc phục vụ và triển khai các mô hình
• Tùy chỉnh giám sát các mô hình trong sản xuất và tự động đào tạo lại các mô hình hiện tại hoặc tạo mô hình mới

Nó có vẻ tốn kém và đôi khi chỉ hợp lý. Do đó, có một khối Khởi tạo dự án MLOps (A) riêng biệt trong sơ đồ chịu trách nhiệm thiết lập mục tiêu hợp lý.

Một ví dụ về cách lập luận của giám đốc CNTT có thể minh họa cho lối suy nghĩ ở đây. Một người quản lý dự án đầy cảm hứng đến gặp anh ấy và yêu cầu cài đặt nền tảng mới để xây dựng hệ thống ML. Nếu cả hai đều hành động vì lợi ích tốt nhất của công ty, giám đốc CNTT sẽ đưa ra các câu hỏi làm rõ:

• Bạn định giải quyết vấn đề kinh doanh nào với hệ thống ML mới?
• Tại sao bạn quyết định rằng hệ thống ML mới sẽ giải quyết vấn đề này?
• Liệu việc thay đổi quy trình hoặc thuê thêm người hỗ trợ kỹ thuật có dễ dàng và rẻ hơn không?
• Bạn có thể xem phân tích so sánh các thành phần hệ thống ML đã hình thành cơ sở cho lựa chọn hiện tại của bạn ở đâu?
• Kiến trúc hệ thống ML được chọn sẽ giúp giải quyết vấn đề kinh doanh như thế nào?
• Bạn có chắc chắn rằng ML có bộ máy toán học cần thiết để giải quyết vấn đề đã xác định không?
• Tuyên bố vấn đề cho giải pháp là gì?
• Bạn sẽ lấy dữ liệu ở đâu để đào tạo các mô hình? Bạn có biết những dữ liệu nào bạn cần để chuẩn bị các mô hình?
• Bạn đã kiểm tra dữ liệu có sẵn chưa?
• Chất lượng của dữ liệu có đủ để giải quyết mô hình không?

Giám đốc CNTT sẽ được đưa xuống làm giáo viên ở một trường đại học nhưng sẽ tiết kiệm được chi phí cho công ty. Nếu tất cả các câu hỏi đã được trả lời thì thực sự cần có hệ thống ML.

Câu hỏi tiếp theo: Tôi có cần thực hiện MLOps trong đó không?

Phụ thuộc vào vấn đề. Nếu bạn cần tìm giải pháp một lần, chẳng hạn như PoC (Proof of Concept), thì bạn không cần MLOps. Nếu cần phải xử lý nhiều yêu cầu đến thì cần phải có MLOps. Về bản chất, cách tiếp cận này tương tự như việc tối ưu hóa bất kỳ quy trình nào của công ty.

Để chứng minh sự cần thiết của MLOps trong quản lý, bạn cần chuẩn bị câu trả lời cho các câu hỏi:

• Điều gì sẽ trở nên tốt hơn?
• Chúng ta sẽ tiết kiệm được bao nhiêu tiền?
• Liệu chúng ta có cần mở rộng đội ngũ nhân viên của mình không?
• Chúng ta cần mua gì?
• Học chuyên môn ở đâu?

Việc tiếp theo cần làm là thi lại giám đốc CNTT.

Các thách thức vẫn tiếp tục diễn ra vì nhóm cũng phải được thuyết phục về sự cần thiết phải thay đổi quy trình làm việc và nền tảng công nghệ của họ. Đôi khi, điều này còn khó khăn hơn việc yêu cầu quản lý ngân sách.

Để thuyết phục nhóm, cần chuẩn bị câu trả lời cho các câu hỏi:

• Tại sao cách làm việc cũ không còn khả thi?
• Mục đích của sự thay đổi là gì?
• Ngăn xếp công nghệ sẽ là gì?
• Học cái gì và học từ ai?
• Công ty sẽ hỗ trợ thực hiện những thay đổi như thế nào?
• Mất bao lâu để thực hiện thay đổi?
• Điều gì xảy ra với những người không làm được điều đó?

Như bạn có thể thấy, quá trình này không hề đơn giản.

Kết luận nhỏ

Ở đây tôi đã hoàn thành nghiên cứu chi tiết về sơ đồ MLOps. Tuy nhiên, đây chỉ là những khía cạnh lý thuyết. Việc triển khai thực tế luôn tiết lộ những chi tiết bổ sung có thể thay đổi nhiều thứ.

Trong bài viết tiếp theo, tôi sẽ thảo luận:

• Hiện vật MLOps
• MLOps như một hệ thống thông tin
• Nguồn mở cho MLOps: Kubeflow so với MLflow so với Pachyderm

Cám ơn vì sự quan tâm của bạn!