Khi các doanh nghiệp sử dụng công nghệ máy học (ML) trong tổ chức của họ, các quy trình làm việc thủ công để xây dựng, đào tạo và triển khai các mô hình ML có xu hướng trở thành điểm nghẽn đối với sự đổi mới. Để khắc phục điều này, doanh nghiệp cần định hình một mô hình hoạt động rõ ràng xác định cách thức nhiều cá nhân, chẳng hạn như nhà khoa học dữ liệu, kỹ sư dữ liệu, kỹ sư ML, CNTT và các bên liên quan trong kinh doanh, nên hợp tác và tương tác; làm thế nào để tách biệt các mối quan tâm, trách nhiệm và kỹ năng; và cách sử dụng các dịch vụ AWS một cách tối ưu. Sự kết hợp giữa ML và hoạt động (MLOps) này đang giúp các công ty hợp lý hóa vòng đời ML từ đầu đến cuối của họ và tăng năng suất của các nhà khoa học dữ liệu trong khi duy trì độ chính xác cao của mô hình cũng như tăng cường bảo mật và tuân thủ.

Trong bài đăng này, bạn sẽ tìm hiểu về các giai đoạn chính của việc xây dựng nền tảng MLOps, cách nhiều cá thể làm việc cùng nhau trên nền tảng này và Amazon SageMaker các công cụ được xây dựng theo mục đích và tích hợp tích hợp với các dịch vụ AWS khác có thể đẩy nhanh việc áp dụng ML trong hoạt động kinh doanh của doanh nghiệp.

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

Việc xây dựng một nền tảng MLOps có thể bao gồm các hoạt động, con người và nhu cầu công nghệ của khách hàng doanh nghiệp là một thách thức. Do đó, chúng tôi xác định mô hình trưởng thành sau đây xác định các khả năng cần thiết của MLOps trong bốn giai đoạn chính.

1. Giai đoạn đầu: Trong giai đoạn này, các nhà khoa học dữ liệu có thể thử nghiệm và xây dựng, đào tạo và triển khai các mô hình trên AWS bằng các dịch vụ của SageMaker. Môi trường phát triển được đề xuất là Xưởng sản xuất Amazon SageMaker, trong đó các nhà khoa học dữ liệu có thể thử nghiệm và cộng tác dựa trên máy tính xách tay Studio.
2. Giai đoạn lặp lại - Với khả năng thử nghiệm trên AWS, bước tiếp theo là tạo quy trình công việc tự động để xử lý trước dữ liệu và xây dựng và đào tạo mô hình (đường ống ML). Các nhà khoa học dữ liệu cộng tác với các kỹ sư ML trong một môi trường riêng biệt để xây dựng các thuật toán và mã nguồn mạnh mẽ và sẵn sàng cho sản xuất, được điều phối bằng cách sử dụng Đường ống Amazon SageMaker. Các mô hình đã tạo được lưu trữ và chuẩn hóa trong sổ đăng ký mô hình Amazon SageMaker.
3. Giai đoạn đáng tin cậy - Mặc dù các mô hình đã được tạo ra thông qua các đường ống ML, chúng cần được thử nghiệm trước khi được đưa vào sản xuất. Do đó, trong giai đoạn này, phương pháp thử nghiệm tự động được giới thiệu, cho cả mô hình và cơ sở hạ tầng kích hoạt, trong một môi trường dàn dựng (tiền sản xuất) cô lập mô phỏng quá trình sản xuất. Sau khi chạy thử nghiệm thành công, các mô hình được triển khai trong môi trường sản xuất biệt lập. Để quảng bá các mô hình giữa nhiều môi trường, cần phải đánh giá và phê duyệt thủ công.
4. Giai đoạn có thể mở rộng - Sau khi sản xuất giải pháp ML đầu tiên, việc mở rộng nền tảng MLOps để hỗ trợ nhiều nhóm khoa học dữ liệu hợp tác và sản xuất hàng chục hoặc hàng trăm trường hợp sử dụng ML là cần thiết. Trong giai đoạn này, chúng tôi giới thiệu quá trình tạo khuôn mẫu của các giải pháp, mang lại tốc độ tăng giá trị bằng cách giảm thời gian phát triển các giải pháp sản xuất mới từ vài tuần xuống còn vài ngày. Ngoài ra, chúng tôi tự động hóa việc khởi tạo các môi trường MLOps an toàn để cho phép nhiều nhóm hoạt động trên dữ liệu của họ, giảm sự phụ thuộc và chi phí vào CNTT.

Trong các phần sau, chúng tôi chỉ ra cách xây dựng nền tảng MLOps dựa trên mô hình trưởng thành trước và các nguyên lý sau:

• Linh hoạt - Các nhà khoa học dữ liệu có thể đáp ứng mọi khuôn khổ (chẳng hạn như TensorFlow hoặc PyTorch)
• Khả năng tái lập - Các nhà khoa học dữ liệu có thể tạo lại hoặc quan sát các thí nghiệm trong quá khứ (mã, dữ liệu và kết quả)
• Tái sử dụng - Các nhà khoa học dữ liệu và kỹ sư ML có thể sử dụng lại mã nguồn và đường ống ML, tránh sự mâu thuẫn và tốn kém
• khả năng mở rộng - Các nhà khoa học dữ liệu và kỹ sư ML có thể mở rộng quy mô tài nguyên và dịch vụ theo yêu cầu
• Khả năng kiểm toán - Các nhà khoa học dữ liệu, bộ phận CNTT và pháp lý có thể kiểm tra nhật ký, phiên bản và sự phụ thuộc của các tạo tác và dữ liệu
• Tính nhất quán - Bởi vì MLOps bao gồm nhiều môi trường, nền tảng cần loại bỏ phương sai giữa các môi trường

Giai đoạn đầu

Trong giai đoạn đầu, mục tiêu là tạo ra một môi trường thử nghiệm an toàn, nơi nhà khoa học dữ liệu nhận được ảnh chụp nhanh của dữ liệu và thử nghiệm bằng cách sử dụng sổ ghi chép SageMaker để chứng minh rằng ML có thể giải quyết một vấn đề kinh doanh cụ thể. Để đạt được điều này, khuyến nghị nên sử dụng môi trường Studio với quyền truy cập phù hợp vào các dịch vụ thông qua điểm cuối VPC. Mã nguồn của kiến ​​trúc tham chiếu có sẵn trong các ví dụ do nhóm SageMaker cung cấp trên Khoa học dữ liệu an toàn với kiến ​​trúc tham chiếu Amazon SageMaker Studio Kho lưu trữ GitHub.

Ngoài các dịch vụ của SageMaker, các nhà khoa học dữ liệu có thể sử dụng các dịch vụ khác để xử lý dữ liệu, chẳng hạn như Amazon EMR, amazon Athenavà Keo AWS, với sổ tay được lưu trữ và tạo phiên bản trong Cam kết mã AWS kho (xem hình sau).

Giai đoạn lặp lại

Sau khi các nhà khoa học dữ liệu chứng minh rằng ML có thể giải quyết vấn đề kinh doanh và đã quen với việc thử nghiệm, đào tạo và triển khai các mô hình của SageMaker, bước tiếp theo là bắt đầu sản xuất giải pháp ML. Hình sau minh họa kiến ​​trúc này.

Ở giai đoạn này, việc tách rời mối quan tâm là cần thiết. Chúng tôi chia môi trường thành nhiều tài khoản AWS:

1. Hồ dữ liệu - Lưu trữ tất cả dữ liệu được nhập từ tại chỗ (hoặc các hệ thống khác) vào đám mây. Các kỹ sư dữ liệu có thể tạo các đường ống trích xuất, chuyển đổi và tải (ETL) kết hợp nhiều nguồn dữ liệu và chuẩn bị các bộ dữ liệu cần thiết cho các trường hợp sử dụng ML. Dữ liệu được lập danh mục thông qua Danh mục dữ liệu AWS Glue và được chia sẻ với người dùng và tài khoản khác qua Sự hình thành hồ AWS (lớp quản trị dữ liệu). Trong cùng một tài khoản, Cửa hàng tính năng Amazon SageMaker có thể được lưu trữ, nhưng chúng tôi không đề cập đến nó trong bài đăng này. Để biết thêm thông tin, hãy tham khảo Cho phép sử dụng lại tính năng trên các tài khoản và nhóm bằng Amazon SageMaker Feature Store.
2. Thử nghiệm - Cho phép các nhà khoa học dữ liệu tiến hành nghiên cứu của họ. Sự khác biệt duy nhất là nguồn gốc của các ảnh chụp nhanh dữ liệu là hồ dữ liệu. Các nhà khoa học dữ liệu chỉ có quyền truy cập trong các tập dữ liệu cụ thể, có thể được ẩn danh trong trường hợp GDPR hoặc các ràng buộc về quyền riêng tư dữ liệu khác. Hơn nữa, tài khoản thử nghiệm có thể có quyền truy cập internet để cho phép các nhà khoa học dữ liệu sử dụng các khuôn khổ khoa học dữ liệu mới hoặc các thư viện mã nguồn mở của bên thứ ba. Do đó, tài khoản thử nghiệm được coi là một phần của môi trường phi sản xuất.
3. Phát triển (nhà phát triển) - Giai đoạn đầu của môi trường sản xuất. Các nhà khoa học dữ liệu chuyển từ sổ ghi chép sang thế giới quy trình làm việc tự động và Đường ống SageMaker. Họ cần cộng tác với các kỹ sư ML để tóm tắt mã của họ và đảm bảo phạm vi kiểm tra, xử lý lỗi và chất lượng mã. Mục tiêu là phát triển các đường ống ML, là các quy trình công việc tự động xử lý trước, đào tạo, đánh giá và đăng ký các mô hình vào sổ đăng ký mô hình SageMaker. Việc triển khai các đường ống ML chỉ được điều khiển thông qua các đường ống CI / CD và quyền truy cập vào Bảng điều khiển quản lý AWS bị hạn chế. Kết nối Internet không được phép vì đường ống ML có quyền truy cập vào dữ liệu sản xuất trong hồ dữ liệu (chỉ đọc).
4. Dụng cụ (hoặc tự động hóa) - Lưu trữ kho CodeCommit, Đường ống dẫn mã AWS Đường ống CI / CD, sổ đăng ký mô hình SageMaker và Amazon ECR để lưu trữ các vùng chứa tùy chỉnh. Bởi vì hồ dữ liệu là điểm trung thực duy nhất cho dữ liệu, tài khoản công cụ dành cho mã, vùng chứa và các hiện vật được tạo ra.

Lưu ý rằng quy ước đặt tên tài khoản và chiến lược nhiều tài khoản này có thể khác nhau tùy thuộc vào nhu cầu kinh doanh của bạn, nhưng cấu trúc này nhằm thể hiện các mức độ riêng biệt được khuyến nghị. Ví dụ: bạn có thể đổi tên tài khoản phát triển thành tài khoản đào tạo hoặc xây dựng mô hình.

Để triển khai tự động, điều quan trọng là phải hiểu cách di chuyển từ sổ ghi chép sang đường ống ML và chuẩn hóa kho mã và cấu trúc dữ liệu, mà chúng ta sẽ thảo luận trong các phần sau.

Từ máy tính xách tay đến đường ống ML

Mục tiêu của môi trường phát triển là tái cấu trúc, bổ sung, cải tiến và mở rộng quy mô mã trong sổ ghi chép và chuyển nó đến các đường ống ML. Đường ống ML là một tập hợp các bước chịu trách nhiệm xử lý trước dữ liệu, đào tạo hoặc sử dụng mô hình và xử lý sau kết quả. Mỗi bước phải thực hiện một nhiệm vụ chính xác (một phép chuyển đổi cụ thể) và đủ trừu tượng (ví dụ: chuyển tên cột làm tham số đầu vào) để cho phép khả năng sử dụng lại. Sơ đồ sau minh họa một đường ống dẫn ví dụ.

Để thực hiện đường ống ML, các nhà khoa học dữ liệu (hoặc kỹ sư ML) sử dụng Đường ống SageMaker. Đường ống SageMaker là một chuỗi các bước được kết nối với nhau (các công việc xử lý SageMaker, đào tạo, HPO) được xác định bằng định nghĩa đường ống JSON sử dụng SDK Python. Định nghĩa đường ống này mã hóa đường ống bằng cách sử dụng Đồ thị vòng có hướng dẫn (DAG). DAG này cung cấp thông tin về các yêu cầu và mối quan hệ giữa từng bước trong đường dẫn ML của bạn.

Tùy thuộc vào trường hợp sử dụng, bạn có thể tách đường ống ML thành hai loại chính: đào tạo và suy luận hàng loạt.

Hình sau minh họa luồng đường ống ML huấn luyện.

Giai đoạn tiền xử lý có thể bao gồm nhiều bước. Các phép biến đổi khoa học dữ liệu phổ biến là phân tách và lấy mẫu dữ liệu (đào tạo, xác thực, bộ thử nghiệm), mã hóa một nóng hoặc vector hóa, phân loại và chia tỷ lệ. Bước đào tạo mô hình có thể là một công việc đào tạo, nếu nhà khoa học dữ liệu biết về cấu hình mô hình tốt nhất hoặc công việc tối ưu hóa siêu tham số (HPO), trong đó AWS xác định siêu tham số tốt nhất cho mô hình (phương pháp Bayes) và tạo ra hiện vật mô hình. Trong bước đánh giá, tạo tác mô hình được tạo ra được sử dụng để thực hiện suy luận đối với tập dữ liệu xác nhận. Sau đó, đường ống ML sẽ kiểm tra xem các chỉ số về độ chính xác được tạo ra (chẳng hạn như F1, độ chính xác và độ lợi) có vượt qua các ngưỡng cần thiết hay không. Nếu bước này thành công, các tạo tác mô hình và siêu dữ liệu sẽ được chuyển đến sổ đăng ký mô hình để sản xuất. Lưu ý rằng bước cơ sở xuất sẽ khai thác Giám sát mô hình Amazon SageMaker chức năng, tạo ra một đối tượng JSON với các thống kê được sử dụng sau này để phát hiện trôi dạt mô hình và có thể được lưu trữ trong sổ đăng ký mô hình SageMaker dưới dạng siêu dữ liệu mô hình.

Trong trường hợp suy luận theo lô, các nhà khoa học dữ liệu có thể tạo ra các đường ống tương tự, như được minh họa trong hình sau.

Bước tiền xử lý của suy luận theo lô thường giống như đào tạo bằng cách loại trừ lấy mẫu dữ liệu và cột sự thật cơ bản. Suy luận hàng loạt là bước gửi dữ liệu theo lô để suy luận đến điểm cuối tương ứng và có thể được thực hiện bằng cách sử dụng biến đổi hàng loạt. Bước xử lý sau tạo ra các thống kê bổ sung, chẳng hạn như phân phối kết quả hoặc kết hợp các kết quả với ID bên ngoài. Sau đó, bước giám sát mô hình có thể so sánh thống kê cơ sở của dữ liệu được sử dụng để đào tạo (siêu dữ liệu JSON mô hình trong sổ đăng ký mô hình) với dữ liệu mới đến để suy luận.

Bạn có thể bỏ qua các bước tiền xử lý nếu các nhà khoa học dữ liệu tạo mô hình đường ống có thể được lưu trữ trong sổ đăng ký mô hình SageMaker. Để biết thêm chi tiết, hãy tham khảo Các mô hình máy chủ cùng với logic tiền xử lý dưới dạng đường ống suy luận nối tiếp phía sau một điểm cuối.

Chuẩn hóa kho lưu trữ

Để cho phép sự hợp tác giữa các nhà khoa học dữ liệu và các kỹ sư ML, việc chuẩn hóa cấu trúc kho lưu trữ mã là cần thiết. Ngoài ra, tiêu chuẩn hóa có lợi cho cấu trúc đường ống CI / CD, cho phép kết hợp xác thực tự động, xây dựng (chẳng hạn như xây dựng thùng chứa tùy chỉnh) và các bước thử nghiệm.

Ví dụ sau minh họa việc tách các giải pháp ML thành hai kho: kho xây dựng và huấn luyện để huấn luyện (và mô hình đường ống tùy chọn), và triển khai để thúc đẩy các mô hình đường ống suy luận theo lô hoặc khởi tạo các điểm cuối thời gian thực:

Kho xây dựng / đào tạo

# Building/Training Repository
algorithms/
    shared_libraries/
        test/
            input/ # (optional)
            output/ # (optional)
            test_<step>.py
        <help_functions1>.py
        <help_functions2>.py
        README.md
    preprocessing/ # 1 folder per pre-processing job, order is defined in the ml pipeline logic
        <preprocessing_job_name1> # e.g classic ml: one hot encoding
            test/
                input/ # (optional)
                output/ # (optional)
                test_<step>.py
            __main__.py
            dockerfile # (optional) define dockerfile in case of custom containers
            README.md
       <preprocessing_job_name2> # e.g classic ml: one hot encoding
        ...
    training/ # (optional) each one is a training job in SageMaker
        <training_job_name>/
            test/
                input/ # (optional)
                output/ # (optional)
                test_<step>.py
            __main__.py
            README.md
    inference/ # (optional) for batch inference
        <batch_inference_job_name>/ # one job per training job name if we're building multiple models
            __main__.py
            README.md
    postprocessing/ # each one is a processing job in SageMaker
        <postprocessing_job_name1>/
            test/
                input/ # (optional)
                output/ # (optional)
                test_<step>.py
           __main__.py
            README.md
        <postprocessing_job_name2>/
        ...
ml_pipelines/
    training/ # (note) Multiple training ML pipelines can be defined
        ml-pipeline-training.py # Define training ML pipelines using SageMaker Pipeline SDK
        input.json # (optinal - json or yaml) ML pipeline configuration to enable reusability
    README.md
notebooks/
    *.ipynb # the original notebooks as has been created by the data scientists
    README.md
build_spec.yml
README.md

Kho lưu trữ triển khai

# Deployment Repository
inference_config/
    staging/
        inference_config.json # Batch inference ML pipeline or real-time model endpoint configuration to enable reusability
    prod/
        inference_config.json # Batch inference ML pipeline or real-time model endpoint configuration to enable reusability
    README.md
app_infra/
    api_gateway/...
    lambda/...
    event_bridge/...
    batch_inference/ml-pipeline-inference.py # Define batch inference SageMaker Pipeline
tests/
    integration_test/
        test_<description>.py
        test_<description>.py
        # …
    stress_test/
        test_<description>.py
    other_test/
        test_<description>.py
    README.md
README.md

Kho xây dựng và đào tạo được chia thành ba thư mục chính:

• Các thuật toán - Các nhà khoa học dữ liệu phát triển mã cho từng bước của đường ống ML trong thư mục gốc của thuật toán. Các bước có thể được nhóm lại trong tiền xử lý, đào tạo, suy luận hàng loạt và hậu xử lý (đánh giá). Trong mỗi nhóm, nhiều bước có thể được xác định trong các thư mục con tương ứng, chứa thư mục cho các bài kiểm tra đơn vị (bao gồm đầu vào và đầu ra tùy chọn), các chức năng chính, readme và tệp Docker trong trường hợp cần vùng chứa tùy chỉnh. Ngoài tệp chính, nhiều tệp mã có thể được lưu trữ trong cùng một thư mục. Thư viện trợ giúp chung cho tất cả các bước có thể được lưu trữ trong một thư mục thư viện dùng chung. Các nhà khoa học dữ liệu chịu trách nhiệm phát triển các bài kiểm tra đơn vị vì họ sở hữu logic của các bước và các kỹ sư ML chịu trách nhiệm nâng cao xử lý lỗi và đề xuất phạm vi kiểm tra. Đường ống CI / CD chịu trách nhiệm chạy các bài kiểm tra, xây dựng các vùng chứa tự động (nếu cần) và đóng gói nhiều tệp mã nguồn.
• Đường ống ML - Sau khi bạn phát triển mã nguồn và kiểm tra từng bước, bước tiếp theo là xác định các đường ống dẫn của SageMaker trong một thư mục gốc khác. Mỗi định nghĩa đường ống ML được đặt trong thư mục con chứa tệp .py và tệp JSON hoặc .yaml cho các tham số đầu vào, chẳng hạn như phạm vi siêu tham số. Một tệp readme để mô tả các đường ống ML là cần thiết.
• máy tính xách tay - Thư mục này lưu trữ các sổ ghi chép gốc mà nhà khoa học dữ liệu đã sử dụng trong quá trình thử nghiệm.

Kho lưu trữ triển khai bao gồm ba phần chính:

• Cấu hình suy luận - Chứa cấu hình của các điểm cuối thời gian thực hoặc suy luận hàng loạt cho mỗi môi trường phát triển, chẳng hạn như các loại cá thể.
• Cơ sở hạ tầng ứng dụng - Lưu trữ mã nguồn của cơ sở hạ tầng cần thiết để chạy suy luận, nếu cần. Đây có thể là một cơ chế kích hoạt thông qua Sự kiện Amazon, Cổng API Amazon, AWS Lambda chức năng, hoặc Đường ống SageMaker.
• Kiểm tra - Bao gồm nhiều thư mục con tùy thuộc vào phương pháp kiểm tra của khách hàng. Là bộ kiểm tra tối thiểu, chúng tôi đề xuất kiểm tra tích hợp (chạy từ đầu đến cuối của suy luận bao gồm cơ sở hạ tầng ứng dụng), kiểm tra căng thẳng (kiểm tra các trường hợp cạnh) và kiểm tra ML (chẳng hạn như phân phối điểm tin cậy hoặc xác suất).

Bằng cách cam kết các thay đổi đối với kho lưu trữ xây dựng và đào tạo, đường ống CI / CD chịu trách nhiệm xác thực cấu trúc kho lưu trữ, thực hiện các bài kiểm tra, triển khai và chạy đường ống ML. Một đường ống CI / CD khác chịu trách nhiệm thúc đẩy các mô hình, chúng tôi sẽ xem xét trong phần sau.

Chuẩn hóa phân nhánh kho lưu trữ và CI / CD

Để đảm bảo tính mạnh mẽ của đường ống ML trong tài khoản nhà phát triển, chiến lược kho lưu trữ nhiều nhánh được đề xuất, trong khi việc triển khai chỉ được thực hiện thông qua đường ống CI / CD. Các nhà khoa học dữ liệu nên sử dụng một nhánh tính năng để phát triển chức năng mới của họ (mã nguồn). Khi họ sẵn sàng triển khai các đường ống ML tương ứng, họ có thể đẩy điều này đến nhánh phát triển. Một thay thế cho cách tiếp cận này là cho phép triển khai các đường ống ML trên mỗi nhánh tính năng. Để biết thêm thông tin, hãy tham khảo Cải thiện quy trình làm việc khoa học dữ liệu của bạn với một đường dẫn MLOps đào tạo đa nhánh sử dụng AWS.

Hình dưới đây minh họa chiến lược phân nhánh và các bước đường ống CI / CD cần thiết mà chúng ta chạy trong môi trường nhà phát triển để xây dựng đường ống và mô hình ML.

Ví dụ mã của phương pháp tiếp cận đa nhánh có sẵn trong Quy trình đào tạo MLOps đa nhánh. Chúng tôi có thể lưu trữ các mô hình được tạo ra bởi một đường ống ML dựa trên nhánh tính năng trong một nhóm mô hình tính năng riêng biệt và hủy bỏ chúng trong khi yêu cầu hợp nhất với nhánh chính. Các mô hình trong nhóm mô hình chính là những mô hình được thúc đẩy sản xuất.

Chuẩn hóa cấu trúc dữ liệu

Điều quan trọng không kém đối với tiêu chuẩn hóa mã nguồn là tiêu chuẩn hóa cấu trúc của dữ liệu, cho phép các nhà khoa học dữ liệu và kỹ sư ML gỡ lỗi, kiểm tra và theo dõi nguồn gốc và lịch sử của các mô hình và đường ống ML. Sơ đồ sau đây minh họa một ví dụ như vậy.

Để đơn giản hơn, hãy giả sử rằng dữ liệu lịch sử đầu vào nằm trong một nhóm của tài khoản phát triển dưới khóa phụ đầu vào (thông thường, dữ liệu này nằm trong hồ dữ liệu). Đối với mỗi trường hợp sử dụng ML, một khóa phụ riêng biệt cần được tạo. Để kích hoạt đường ống ML mới chạy, nhà khoa học dữ liệu phải thực hiện cam kết và đẩy git, điều này sẽ kích hoạt đường ống CI / CD. Sau đó, đường dẫn CI / CD tạo một khóa phụ bằng cách sao chép các thành phần mã ( code khóa phụ) và dữ liệu đầu vào ( input khóa phụ) trong một phân vùng phụ của ID bản dựng. Ví dụ: ID bản dựng clà sự kết hợp của date-time và git hash, hoặc ID chạy đường ống SageMaker. Cấu trúc này cho phép nhà khoa học dữ liệu kiểm tra và truy vấn các hoạt động triển khai và chạy trước đây. Sau đó, đường ống CI / CD triển khai và kích hoạt đường ống ML. Trong khi đường ống ML đang chạy, mỗi bước xuất kết quả trung gian sang ml-pipeline-outputs. Điều quan trọng cần lưu ý là các nhánh tính năng khác nhau triển khai và chạy phiên bản mới của ML Pipeline và mỗi nhánh cần xuất kết quả trung gian sang thư mục con khác nhau với khóa phụ mới và / hoặc tiền tố hoặc hậu tố được chuẩn hóa bao gồm id nhánh tính năng.

Cách tiếp cận này hỗ trợ khả năng kiểm tra hoàn chỉnh của mọi thử nghiệm. Tuy nhiên, cách tiếp cận đa nhánh của chiến lược phát triển tạo ra một lượng lớn dữ liệu. Do đó, một chiến lược vòng đời dữ liệu là cần thiết. Chúng tôi khuyên bạn nên xóa ít nhất dữ liệu của mỗi đường ống ML nhánh tính năng trong mỗi yêu cầu kéo / hợp nhất thành công. Nhưng điều này phụ thuộc vào mô hình hoạt động và mức độ chi tiết kiểm toán mà doanh nghiệp của bạn cần hỗ trợ. Bạn có thể sử dụng một cách tiếp cận tương tự trong các đường ống ML suy luận theo lô

Giai đoạn đáng tin cậy

Sau khi tách biệt ban đầu mối quan tâm giữa các nhà khoa học dữ liệu, kỹ sư ML và kỹ sư dữ liệu bằng cách sử dụng nhiều tài khoản, bước tiếp theo là thúc đẩy các mô hình đã sản xuất từ ​​sổ đăng ký mô hình sang một môi trường biệt lập để thực hiện suy luận. Tuy nhiên, chúng ta cần đảm bảo tính mạnh mẽ của các mô hình đã triển khai. Do đó, việc mô phỏng mô hình đã triển khai sang môi trường phản chiếu của quá trình sản xuất là bắt buộc, cụ thể là tiền sản xuất (hoặc dàn dựng).

Hình sau minh họa kiến ​​trúc này.

Việc thúc đẩy triển khai mô hình và điểm cuối trong môi trường tiền sản xuất được thực hiện bằng cách sử dụng các sự kiện cập nhật trạng thái đăng ký mô hình (hoặc git push trên kho lưu trữ triển khai), kích hoạt đường ống CI / CD riêng biệt bằng cách sử dụng các sự kiện EventBridge. Bước đầu tiên của quy trình CI / CD yêu cầu phê duyệt thủ công bởi nhà khoa học dữ liệu chính (và có thể là chủ sở hữu sản phẩm, nhà phân tích kinh doanh hoặc các nhà khoa học dữ liệu chính khác). Người phê duyệt cần xác thực các KPI hiệu suất của mô hình và QA của mã trong kho triển khai. Sau khi phê duyệt, đường ống CI / CD chạy mã kiểm tra đến kho triển khai (kiểm tra tích hợp, kiểm tra căng thẳng, kiểm tra ML). Ngoài điểm cuối của mô hình, CI / CD cũng kiểm tra cơ sở hạ tầng kích hoạt, chẳng hạn như EventBridge, các chức năng Lambda hoặc API Gateway. Sơ đồ sau đây cho thấy kiến ​​trúc được cập nhật này.

Sau khi chạy thử nghiệm thành công, đường ống CI / CD thông báo cho những người phê duyệt mới (hoặc tương tự) rằng một mô hình đã sẵn sàng để đưa vào sản xuất. Ở giai đoạn này, nhà phân tích kinh doanh có thể muốn thực hiện một số thử nghiệm giả thuyết thống kê bổ sung về kết quả của mô hình. Sau khi được phê duyệt, các mô hình và cơ sở hạ tầng kích hoạt sẽ được triển khai vào sản xuất. Nhiều phương pháp triển khai được hỗ trợ bởi SageMaker, chẳng hạn như thử nghiệm xanh lam / xanh lá cây, Canary và A / B (xem thêm trong Lan can triển khai). Nếu đường ống CI / CD không thành công, cơ chế khôi phục sẽ trả hệ thống về trạng thái mạnh mẽ mới nhất.

Sơ đồ sau minh họa các bước chính của đường ống CI / CD để quảng bá một mô hình và cơ sở hạ tầng để kích hoạt điểm cuối của mô hình, chẳng hạn như API Gateway, các hàm Lambda và EventBridge.

Tích hợp hồ dữ liệu và MLOps

Tại thời điểm này, điều quan trọng là phải hiểu các yêu cầu dữ liệu cho mỗi giai đoạn phát triển hoặc tài khoản và cách kết hợp MLOps với một hồ dữ liệu tập trung. Sơ đồ sau đây minh họa các MLOps và các lớp hồ dữ liệu.

Trong hồ dữ liệu, các kỹ sư dữ liệu chịu trách nhiệm kết hợp nhiều nguồn dữ liệu và tạo tập dữ liệu tương ứng (ví dụ: một bảng dữ liệu cấu trúc hoặc một thư mục có tệp PDF hoặc hình ảnh) cho các trường hợp sử dụng ML bằng cách xây dựng ETL đường ống do các nhà khoa học dữ liệu xác định (trong giai đoạn phân tích dữ liệu thăm dò). Các bộ dữ liệu đó có thể được chia thành dữ liệu lịch sử và dữ liệu để suy luận và thử nghiệm. Tất cả dữ liệu được lập danh mục (ví dụ: với Danh mục dữ liệu AWS Glue) và có thể được chia sẻ với các tài khoản và người dùng khác bằng cách sử dụng Lake Formation làm lớp quản trị dữ liệu (đối với dữ liệu có cấu trúc). Theo bài viết này, Lake Formation chỉ tương thích với các truy vấn Athena, công việc AWS Glue và Amazon EMR.

Mặt khác, môi trường MLOps cần tưới các đường ống ML bằng các bộ dữ liệu cụ thể nằm trong các thùng cục bộ trong dev, pre-prod và prod. Môi trường dành cho nhà phát triển chịu trách nhiệm xây dựng và đào tạo các mô hình theo yêu cầu bằng cách sử dụng các đường ống SageMaker kéo dữ liệu từ hồ dữ liệu. Do đó, chúng tôi đề xuất là bước đầu tiên của quy trình nên có bước Athena, nơi chỉ yêu cầu lấy mẫu và truy vấn dữ liệu hoặc bước Amazon EMR, nếu yêu cầu các biến đổi phức tạp hơn. Ngoài ra, bạn có thể sử dụng công việc AWS Glue thông qua bước gọi lại, nhưng không phải là bước gốc như với SageMaker Pipelines.

Pre-prod và prod chịu trách nhiệm kiểm tra hoặc thực hiện suy luận hàng loạt và thời gian thực. Trong trường hợp suy luận theo thời gian thực, việc gửi dữ liệu đến các tài khoản tiền và tài khoản MLOps là không cần thiết vì đầu vào cho phép suy luận có thể dựa trên tải trọng của yêu cầu API Gateway. Trong trường hợp suy luận theo lô (hoặc dữ liệu đầu vào có kích thước lớn), các bộ dữ liệu cần thiết, dữ liệu kiểm tra hoặc dữ liệu để suy luận, cần được đưa vào nhóm dữ liệu ML cục bộ (pre-prod hoặc prod). Bạn có hai tùy chọn để di chuyển dữ liệu sang pre-prod và prod: bằng cách kích hoạt Athena hoặc Amazon EMR và kéo dữ liệu từ hồ dữ liệu hoặc đẩy dữ liệu từ hồ dữ liệu sang các tài khoản MLOps đó. Tùy chọn đầu tiên yêu cầu phát triển các cơ chế bổ sung trong tài khoản MLOps, ví dụ: tạo các sự kiện EventBridge đã lên lịch (mà không cần biết nếu dữ liệu trong hồ dữ liệu đã được cập nhật) hoặc dữ liệu đến các sự kiện S3 EventBridge trong hồ dữ liệu (đối với biết thêm chi tiết, xem Đơn giản hóa việc truy cập nhiều tài khoản với các chính sách tài nguyên của Amazon EventBridge). Sau khi nắm bắt sự kiện ở phía MLOps, một truy vấn Athena hoặc Amazon EMR có thể tìm nạp dữ liệu cục bộ và kích hoạt suy luận không đồng bộ or biến đổi hàng loạt. Điều này có thể được gói vào một đường ống SageMaker cho đơn giản. Tùy chọn thứ hai là thêm vào bước cuối cùng của đường ống ETL chức năng đẩy dữ liệu vào nhóm MLOps. Tuy nhiên, cách tiếp cận này kết hợp các trách nhiệm (hồ dữ liệu kích hoạt suy luận) và yêu cầu Lake Formation cung cấp quyền truy cập vào hồ dữ liệu để ghi vào các nhóm MLOps.

Bước cuối cùng là chuyển kết quả suy luận trở lại hồ dữ liệu. Để lập danh mục dữ liệu và cung cấp dữ liệu cho những người dùng khác, dữ liệu phải trở lại dưới dạng nguồn dữ liệu mới trở lại nhóm đích.

Giai đoạn có thể mở rộng

Sau khi phát triển nền tảng MLOps và sản xuất end-to-end của trường hợp sử dụng ML đầu tiên, cơ sở hạ tầng của dev, pre-prod, prod và kho lưu trữ, đường ống CI / CD và cấu trúc dữ liệu đã được kiểm tra và hoàn thiện . Bước tiếp theo là đưa các nhóm và trường hợp sử dụng ML mới vào nền tảng. Để đảm bảo tốc độ thành giá trị, SageMaker cho phép bạn tạo các mẫu dự án SageMaker tùy chỉnh, mà bạn có thể sử dụng để khởi tạo các kho lưu trữ mẫu và đường ống CI / CD một cách tự động. Với các mẫu dự án SageMaker như vậy, các nhà khoa học dữ liệu chính chịu trách nhiệm khởi tạo các dự án mới và phân bổ một nhóm chuyên dụng cho mỗi trường hợp sử dụng ML mới.

Sơ đồ sau đây minh họa quá trình này.

Vấn đề trở nên phức tạp hơn nếu các nhóm nhà khoa học dữ liệu khác nhau (hoặc nhiều đơn vị kinh doanh cần sản xuất ML) có quyền truy cập vào dữ liệu bí mật khác nhau và nhiều chủ sở hữu sản phẩm chịu trách nhiệm thanh toán một hóa đơn riêng cho việc đào tạo, triển khai và chạy các mô hình . Do đó, cần phải có một bộ tài khoản MLOps riêng biệt (thử nghiệm, nhà phát triển, tiền sản xuất và tiền sản phẩm) cho mỗi nhóm. Để cho phép dễ dàng tạo các tài khoản MLOps mới, chúng tôi giới thiệu một tài khoản khác, tài khoản quản trị phân tích nâng cao, mà các thành viên CNTT có thể truy cập và cho phép họ lập danh mục, khởi tạo hoặc hủy bỏ các tài khoản MLOps theo yêu cầu. Cụ thể, tài khoản này lưu trữ các kho chứa với mã cơ sở hạ tầng của tài khoản MLOps (VPC, mạng con, điểm cuối, nhóm, Quản lý truy cập và nhận dạng AWS (IAM) vai trò và chính sách, Hình thành đám mây AWS ngăn xếp), một Danh mục dịch vụ AWS sản phẩm để tự động triển khai các ngăn xếp CloudFormation của cơ sở hạ tầng cho nhiều tài khoản chỉ bằng một cú nhấp chuột và Máy phát điện Amazon bảng để lập danh mục siêu dữ liệu, chẳng hạn như nhóm nào chịu trách nhiệm cho từng nhóm tài khoản. Với khả năng này, nhóm CNTT khởi tạo tài khoản MLOps theo yêu cầu và phân bổ người dùng cần thiết, quyền truy cập dữ liệu trên mỗi tài khoản và các ràng buộc bảo mật nhất quán.

Dựa trên kịch bản này, chúng tôi tách các tài khoản thành tạm thời và lâu dài. Data lake và tooling là những tài khoản lâu bền và đóng vai trò là điểm trung thực duy nhất cho dữ liệu và mã nguồn, tương ứng. Các tài khoản MLOps chủ yếu là không có trạng thái và được khởi tạo hoặc ngừng hoạt động theo yêu cầu, khiến chúng trở nên vô dụng. Ngay cả khi một tập hợp các tài khoản MLOps ngừng hoạt động, người dùng hoặc người đánh giá vẫn có thể kiểm tra các thử nghiệm và kết quả trong quá khứ vì chúng được lưu trữ trong môi trường lâu bền.

Nếu bạn muốn sử dụng Studio UI cho MLOps, tài khoản công cụ là một phần của tài khoản nhà phát triển, như hình sau.

Nếu người dùng muốn sử dụng Sagemaker Studio UI cho MLOps, thì tài khoản công cụ là một phần của nhà phát triển
tài khoản như hình trên. Mã nguồn mẫu của nền tảng MLOPs này có thể được tìm thấy trong
Bảo mật nền tảng MLOps đa tài khoản dựa trên CDK.

Lưu ý rằng Sagemaker cung cấp khả năng thay thế CodeCommit và CodePipeline bằng các công cụ phát triển của bên thứ ba khác, chẳng hạn như GitHub và Jenkins (có thể tìm thấy thêm chi tiết trong Tạo các dự án Amazon SageMaker sử dụng kiểm soát nguồn của bên thứ ba và Jenkins và Các MLOps của Dự án Amazon SageMaker Mẫu với GitLab và GitLab Pipelines).

Tóm tắt về Personas, hoạt động và công nghệ

Với mô hình trưởng thành MLOps, chúng ta có thể xác định một lộ trình phân phối và thiết kế kiến ​​trúc rõ ràng. Tuy nhiên, mỗi cá nhân cần có cái nhìn rõ ràng về các tài khoản và dịch vụ AWS chính để tương tác và các hoạt động cần tiến hành. Sơ đồ sau đây tóm tắt các danh mục đó.

Kết luận

Một nền tảng MLOps mạnh mẽ, xác định rõ ràng sự tương tác giữa nhiều cá nhân và công nghệ, có thể tăng tốc độ thành giá trị và giảm chi phí, đồng thời cho phép các nhà khoa học dữ liệu tập trung vào các đổi mới. Trong bài đăng này, chúng tôi đã chỉ ra cách xây dựng nền tảng như vậy theo từng giai đoạn, dẫn đến mô hình hoàn thiện MLOps suôn sẻ cho doanh nghiệp và khả năng hỗ trợ nhiều nhóm khoa học dữ liệu và các trường hợp sử dụng ML trong sản xuất. Chúng tôi đã xác định một mô hình hoạt động bao gồm nhiều cá nhân với nhiều kỹ năng và trách nhiệm. Cuối cùng, chúng tôi đã chia sẻ các ví dụ về cách chuẩn hóa phát triển mã (kho lưu trữ và đường ống CI / CD), lưu trữ và chia sẻ dữ liệu cũng như cung cấp cơ sở hạ tầng an toàn MLOps cho môi trường doanh nghiệp. Nhiều khách hàng doanh nghiệp đã áp dụng cách tiếp cận này và có thể sản xuất các giải pháp ML của họ trong vòng vài ngày thay vì vài tháng.

Nếu bạn có bất kỳ ý kiến ​​hoặc câu hỏi nào, vui lòng để lại trong phần bình luận.

Lưu ý

Tiến sĩ Sokratis Kartakis là Kiến trúc sư Giải pháp Chuyên gia về Máy học Cấp cao cho Dịch vụ Web của Amazon. Sokratis tập trung vào việc cho phép khách hàng doanh nghiệp công nghiệp hóa các giải pháp Học máy (ML) của họ bằng cách khai thác các dịch vụ AWS và định hình mô hình hoạt động của họ, tức là nền tảng MLOps và lộ trình chuyển đổi tận dụng các phương pháp phát triển tốt nhất. Ông đã dành hơn 15 năm để phát minh, thiết kế, lãnh đạo và triển khai các giải pháp ML và Internet of Things (IoT) cấp độ sản xuất đầu cuối sáng tạo trong các lĩnh vực năng lượng, bán lẻ, y tế, tài chính / ngân hàng, đua xe thể thao, v.v. Sokratis thích dành thời gian rảnh rỗi cho gia đình và bạn bè, hoặc đi xe máy.

Georgios Schinas là Kiến trúc sư Giải pháp Chuyên gia về AI / ML trong khu vực EMEA. Anh ấy có trụ sở tại London và làm việc chặt chẽ với các khách hàng ở Vương quốc Anh và Ireland. Georgios giúp khách hàng thiết kế và triển khai các ứng dụng học máy trong sản xuất trên AWS đặc biệt quan tâm đến các hoạt động MLOps và cho phép khách hàng thực hiện học máy trên quy mô lớn. Khi rảnh rỗi, anh ấy thích đi du lịch, nấu nướng và dành thời gian cho bạn bè và gia đình.

Giuseppe Angelo Porcelli là Kiến trúc sư chính về Giải pháp Chuyên gia về Máy học cho Dịch vụ Web của Amazon. Với nền tảng ML nhiều năm về kỹ thuật phần mềm, anh ấy làm việc với khách hàng ở mọi quy mô để hiểu sâu sắc nhu cầu kinh doanh và kỹ thuật của họ, đồng thời thiết kế các giải pháp AI và Machine Learning để tận dụng tốt nhất Đám mây AWS và ngăn xếp Amazon Machine Learning. Anh ấy đã làm việc trong các dự án trong các lĩnh vực khác nhau, bao gồm MLOps, Computer Vision, NLP và liên quan đến một loạt các dịch vụ AWS. Khi rảnh rỗi, Giuseppe thích chơi bóng đá.

Shelbee Eigenbrode là Kiến trúc sư chính về giải pháp chuyên gia về AI và học máy tại Amazon Web Services (AWS). Cô đã làm việc trong lĩnh vực công nghệ được 24 năm với nhiều lĩnh vực, công nghệ và vai trò khác nhau. Cô ấy hiện đang tập trung vào việc kết hợp nền tảng DevOps và ML của mình vào lĩnh vực MLOps để giúp khách hàng phân phối và quản lý khối lượng công việc ML trên quy mô lớn. Với hơn 35 bằng sáng chế được cấp trên các lĩnh vực công nghệ khác nhau, cô ấy có niềm đam mê đổi mới liên tục và sử dụng dữ liệu để thúc đẩy kết quả kinh doanh. Shelbee là người đồng sáng tạo và là người hướng dẫn chuyên môn Khoa học Dữ liệu Thực tế trên Coursera. Cô cũng là Đồng Giám đốc phụ nữ trong dữ liệu lớn (WiBD), chương Denver. Khi rảnh rỗi, cô ấy thích dành thời gian cho gia đình, bạn bè và những chú chó hiếu động của mình.