Hiện đại hóa quản lý vòng đời khoa học dữ liệu với AWS và Wipro

bởi Stephen Randolph, Ajay Vishwakarma và Bhajandeep Singh | vào ngày 05 THG 1, 2024 |

Bài viết này được viết phối hợp với Bhajandeep Singh và Ajay Vishwakarma từ Phòng thực hành AI/ML của Wipro trên AWS.

Nhiều tổ chức đã sử dụng sự kết hợp giữa giải pháp khoa học dữ liệu mã nguồn mở và trên nền tảng để tạo và quản lý các mô hình học máy (ML).

Các đội ngũ khoa học dữ liệu và DevOps có thể phải đối mặt với thách thức quản lý những bộ công cụ và hệ thống cô lập này. Việc tích hợp nhiều bộ công cụ để xây dựng một giải pháp nhỏ gọn có thể đòi hỏi xây dựng kết nối hoặc quy trình làm việc tùy chỉnh. Việc quản lý các phụ thuộc khác nhau dựa trên phiên bản hiện tại của mỗi bộ công cụ và duy trì những phụ thuộc đó khi có bản cập nhật mới của mỗi bộ công cụ làm phức tạp giải pháp. Điều này làm tăng chi phí duy trì cơ sở hạ tầng và làm trở ngại đến năng suất.

Các dịch vụ trí tuệ nhân tạo (AI) và học máy (ML) từ Amazon Web Services (AWS), cùng với các dịch vụ giám sát và thông báo tích hợp, giúp các tổ chức đạt được mức độ tự động hóa, có thể mở rộng và chất lượng mô hình cần thiết với chi phí tối ưu. AWS cũng hỗ trợ các đội ngũ khoa học dữ liệu và DevOps hợp tác và tối ưu hóa quy trình vòng đời tổng thể của mô hình.

Bộ dịch vụ ML của AWS bao gồm một bộ dịch vụ mạnh mẽ mà bạn có thể sử dụng để tăng tốc quá trình phát triển, huấn luyện và triển khai ứng dụng học máy. Bộ dịch vụ này có thể được sử dụng để hỗ trợ toàn bộ quá trình vòng đời mô hình bao gồm giám sát và việc huấn luyện lại các mô hình học máy.

Trong bài viết này, chúng tôi thảo luận về việc phát triển mô hình và triển khai khung hệ thống MLOps cho một trong những khách hàng của Wipro sử dụng Amazon SageMaker và các dịch vụ khác của AWS.

Wipro là Đối tác Dịch vụ Premier Tier và Nhà cung cấp Dịch vụ Quản lý (MSP) của AWS. Các giải pháp AI/ML của họ đưa ra hiệu quả vận hành, năng suất và trải nghiệm khách hàng cải thiện cho nhiều doanh nghiệp khách hàng của họ.


Hãy trước tiên hiểu một số thách thức mà đội ngũ khoa học dữ liệu và DevOps của khách hàng đang phải đối mặt với cấu hình hiện tại của họ. Sau đó, chúng ta có thể xem xét cách các dịch vụ AI/ML tích hợp của SageMaker đã giúp giải quyết những thách thức đó.```
  • Hợp tác – Các nhà khoa học dữ liệu đều làm việc trên các sổ tay Jupyter cục bộ của họ để tạo và huấn luyện các mô hình ML. Họ thiếu một phương pháp hiệu quả để chia sẻ và hợp tác với các nhà khoa học dữ liệu khác.
  • Khả năng mở rộng – Việc huấn luyện và đào tạo lại các mô hình ML đang mất nhiều thời gian hơn và hơn khi các mô hình trở nên phức tạp trong khi khả năng cấp phát hạ tầng vẫn giữ nguyên.
  • MLOps – Giám sát mô hình và quản lý liên tục không được tích hợp và tự động chặt chẽ với các mô hình ML. Có sự phụ thuộc và phức tạp khi tích hợp các công cụ bên thứ ba vào đường ống MLOps.
  • Khả năng tái sử dụng – Mà không có khung hệ thống MLOps có thể tái sử dụng, mỗi mô hình phải được phát triển và quản lý riêng biệt, điều này làm tăng tổng nỗ lực và trì hoãn quá trình vận hành mô hình.

Biểu đồ này tóm tắt các thách thức và cách triển khai của Wipro trên SageMaker đã giải quyết chúng bằng các dịch vụ và ưu đãi tích hợp của SageMaker.

Hình 1 – Các ưu đãi của SageMaker cho quá trình di chuyển khối lượng công việc ML

Wipro đã định nghĩa một kiến trúc giải quyết các thách thức một cách tối ưu về chi phí và hoàn toàn tự động.

Dưới đây là trường hợp sử dụng và mô hình được sử dụng để xây dựng giải pháp:

  • Trường hợp sử dụng: Dự đoán giá dựa trên bộ dữ liệu xe ô tô đã qua sử dụng
  • Loại vấn đề: Hồi quy
  • Các mô hình sử dụng: XGBoost và Linear Learner (Các thuật toán tích hợp sẵn của SageMaker)

Kiến trúc giải pháp

Các tư vấn của Wipro đã tiến hành một buổi làm việc phát hiện sâu rộng cùng với đội ngũ khoa học dữ liệu, DevOps và kỹ sư dữ liệu của khách hàng để hiểu rõ môi trường hiện tại cũng như các yêu cầu và kỳ vọng của họ đối với một giải pháp hiện đại trên AWS. Đến cuối quá trình tư vấn, đội ngũ đã triển khai kiến trúc sau đây một cách hiệu quả để đáp ứng các yêu cầu cốt lõi của đội ngũ khách hàng, bao gồm:

Code Sharing – Các sổ tay SageMaker cho phép các nhà khoa học dữ liệu thử nghiệm và chia sẻ mã với các thành viên khác trong nhóm. Wipro đã tăng tốc thêm nữa hành trình mô hình ML của họ bằng cách triển khai bộ tăng tốc mã và đoạn mã của Wipro để đẩy nhanh quá trình kỹ thuật đặc trưng, huấn luyện mô hình, triển khai mô hình và tạo đường ống.

Continuous integration and continuous delivery (CI/CD) pipeline – Sử dụng kho lưu trữ GitHub của khách hàng đã cho phép phiên bản mã và các kịch bản tự động để triển khai ống đường mỗi khi phiên bản mã mới được commit.

MLOps – Kiến trúc triển khai một ống đường giám sát mô hình SageMaker để thực hiện việc duy trì chất lượng mô hình liên tục bằng cách xác nhận sự biến động dữ liệu và mô hình theo định kỳ được xác định. Khi phát hiện biến động, một sự kiện sẽ được khởi chạy để thông báo cho các nhóm tương ứng để thực hiện hành động hoặc bắt đầu quá trình huấn luyện lại mô hình.

Event-driven architecture – Các ống đường cho việc huấn luyện mô hình, triển khai mô hình và giám sát mô hình được tích hợp tốt thông qua việc sử dụng Amazon EventBridge, một hệ thống sự kiện serverless. Khi sự kiện đã được xác định, EventBridge có thể triệu hồi một ống đường để chạy phản ứng. Điều này tạo ra một bộ ống đường gián đoạn có thể chạy khi cần thiết phản ứng với môi trường.

Hình 2 – Kiến trúc MLOps động sự kiện với SageMaker

Các thành phần của giải pháp

Phần này mô tả các thành phần khác nhau của kiến trúc.

Sổ tay thử nghiệm

  • Mục tiêu: Đội ngũ khoa học dữ liệu của khách hàng muốn thử nghiệm với các bộ dữ liệu khác nhau và nhiều mô hình để tạo ra các đặc trưng tối ưu, sử dụng chúng như là đầu vào tiếp theo cho ống đường tự động.
  • Giải pháp: Wipro đã tạo các sổ tay thử nghiệm SageMaker với đoạn mã nguồn mở cho mỗi bước có thể tái sử dụng, như đọc và viết dữ liệu, kỹ thuật đặc trưng mô hình, huấn luyện mô hình và điều chỉnh siêu tham số. Công việc kỹ thuật đặc trưng cũng có thể được chuẩn bị trong Data Wrangler, nhưng khách hàng cụ thể yêu cầu các công việc xử lý SageMaker và AWS Step Functions vì họ thoải mái sử dụng các công nghệ này hơn. Chúng tôi đã sử dụng AWS step function data science SDK để tạo một bước hàm chức năng – cho việc kiểm tra luồng – trực tiếp từ máy tính cá nhân để tạo đầu vào được định nghĩa rõ ràng cho các ống đường. Điều này đã giúp đội ngũ khoa học dữ liệu tạo và kiểm thử các ống đường một cách nhanh chóng hơn.

Bảng tự động hóa quá trình huấn luyện

  • Mục tiêu: Cho phép một bảng tự động quá trình huấn luyện và huấn luyện lại với các tham số có thể cấu hình như loại instance, siêu tham số và vị trí của một Bucket Amazon Simple Storage Service (Amazon S3). Bảng cũng nên được khởi chạy bằng sự kiện đẩy dữ liệu vào S3.
  • Giải pháp: Wipro triển khai một bảng huấn luyện có thể tái sử dụng bằng cách sử dụng SDK Step Functions, xử lý SageMaker, công việc huấn luyện, một container SageMaker model monitor để tạo lập mô hình cơ sở, các dịch vụ AWS Lambda và EventBridge. Sử dụng kiến trúc sự kiện động của AWS, bảng được cấu hình để tự động khởi chạy dựa trên sự kiện đẩy dữ liệu mới vào Bucket S3 được ánh xạ. Các thông báo được cấu hình để được gửi đến các địa chỉ email được xác định. Ở mức cao, luồng huấn luyện trông như sơ đồ sau:

Figure 3 – Training pipeline step machine.

Mô tả luồng cho bảng tự động hóa quá trình huấn luyện

Sơ đồ trên là một bảng tự động hóa quá trình huấn luyện được xây dựng bằng cách sử dụng Step Functions, Lambda và SageMaker. Đây là một bảng có thể tái sử dụng để thiết lập quá trình huấn luyện mô hình tự động, tạo dự đoán, tạo cơ sở cho giám sát mô hình và giám sát dữ liệu, và tạo và cập nhật một điểm cuối dựa trên giá trị ngưỡng mô hình trước đó.

  1. Pre-processing: Bước này lấy dữ liệu từ một vị trí Amazon S3 làm đầu vào và sử dụng container SageMaker SKLearn để thực hiện các nhiệm vụ kỹ thuật chọn đặc trưng và tiền xử lý dữ liệu cần thiết, như phân chia train, test và validate.
  2. Model training: Sử dụng SDK SageMaker, bước này chạy mã huấn luyện với hình ảnh mô hình tương ứng và huấn luyện bộ dữ liệu từ các kịch bản tiền xử lý trong khi tạo ra các tư liệu mô hình đã được huấn luyện.
  3. Save model: Bước này tạo một mô hình từ tư liệu mô hình đã được huấn luyện. Tên mô hình được lưu để tham chiếu trong bảng tự động khác sử dụng AWS Systems Manager Parameter Store.
  4. Query training results: Bước này gọi hàm Lambda để lấy các chỉ số của công việc huấn luyện đã hoàn tất từ bước huấn luyện mô hình trước đó.
  5. RMSE threshold: Bước này kiểm tra chỉ số mô hình đã được huấn luyện (RMSE) so với một ngưỡng đã định để quyết định liệu có tiến đến triển khai điểm cuối hay từ chối mô hình này.
  6. Model accuracy too low: Ở bước này, độ chính xác của mô hình được kiểm tra so với mô hình tốt nhất trước đó. Nếu mô hình không đáp ứng được kiểm tra chỉ số, một thông báo được gửi bởi hàm Lambda đến chủ đề mục tiêu đã đăng ký trong Amazon Simple Notification Service (Amazon SNS). Nếu kiểm tra này thất bại, luồng kết thúc vì mô hình mới đã được huấn luyện không đạt đến ngưỡng đã định.
  7. Baseline job data drift: Nếu mô hình đã được huấn luyện vượt qua các bước kiểm tra, các thông số cơ bản được tạo cho phiên bản mô hình đã được huấn luyện này để cho phép giám sát và các bước nhánh song song được chạy để tạo cơ sở cho kiểm tra chất lượng mô hình.
  8. Create model endpoint configuration: Bước này tạo cấu hình điểm cuối cho mô hình đã được đánh giá ở bước trước với cấu hình bắt đầu việc chụp dữ liệu.
  9. Check endpoint: Bước này kiểm tra xem điểm cuối có tồn tại hay cần được tạo. Dựa vào kết quả, bước tiếp theo là tạo hoặc cập nhật điểm cuối.
  10. Export configuration: Bước này xuất các thông số tên mô hình, tên điểm cuối và cấu hình điểm cuối sang AWS Systems Manager Parameter Store.

Các cảnh báo và thông báo được cấu hình để được gửi đến email của chủ đề SNS đã được cấu hình khi trạng thái của máy trạng thái thay đổi, bất kể là thành công hay thất bại. Cấu hình cùng được sử dụng lại cho mô hình XGBoost.

Automated batch scoring pipeline

  • Mục đích: Khởi chạy điểm đánh giá theo lô ngay khi dữ liệu đầu vào cho điểm đánh giá theo lô có sẵn tại vị trí Amazon S3 tương ứng. Điểm đánh giá theo lô nên sử dụng mô hình đã đăng ký mới nhất để thực hiện điểm đánh giá.
  • Giải pháp: Wipro triển khai một ống đựng điểm đánh giá có thể tái sử dụng bằng cách sử dụng SDK của Step Functions, các công việc biến đổi hàng loạt của SageMaker, Lambda và EventBridge. Luồng công việc này tự động kích hoạt dựa trên sự có sẵn của dữ liệu điểm đánh giá mới đối với vị trí S3 tương ứng.

Hình 4 – Máy tính điểm đường ống cho mô hình học tuyến tính và XGBoost

Mô tả luồng cho ống đựng điểm đánh giá tự động:

  1. Pre-processing: Đầu vào cho bước này là một tệp dữ liệu từ vị trí S3 tương ứng và thực hiện xử lý trước cần thiết trước khi gọi công việc biến đổi hàng loạt của SageMaker.
  2. Scoring: Bước này chạy công việc biến đổi hàng loạt để tạo ra dự đoán, gọi phiên bản mới nhất của mô hình đã đăng ký và lưu trữ đầu ra điểm đánh giá trong một bucket S3. Wipro đã sử dụng bộ lọc và chức năng ghép nối đầu vào của API biến đổi hàng loạt SageMaker. Nó giúp làm phong phú dữ liệu điểm đánh giá để đưa ra quyết định tốt hơn.

Hình 5 – Bộ lọc đầu vào và luồng nối để chuyển đổi hàng loạt

  1. Trong bước này, ống đựng trạng thái được khởi chạy bởi một tệp dữ liệu mới trong bucket S3.

Thông báo được cấu hình để gửi đến email của chủ đề SNS được cấu hình khi trạng thái của ống đựng thay đổi.

Real-time inference pipeline

  • Mục đích: Kích hoạt suy luận thời gian thực từ cả hai mô hình (Linear Learner và XGBoost) và nhận giá trị dự đoán tối đa (hoặc sử dụng bất kỳ logic tùy chỉnh nào có thể được viết dưới dạng hàm Lambda) để trả về cho ứng dụng.
  • Giải pháp: Nhóm Wipro đã triển khai kiến trúc có thể tái sử dụng bằng cách sử dụng Amazon API Gateway, Lambda và điểm kết của SageMaker như thể hiện trong Hình 6:

Hình 6 – Real-time inference pipeline

Mô tả quy trình cho ống đựng suy luận thời gian thực được hiển thị trong Hình 6:

  1. Dữ liệu gửi từ ứng dụng đến Amazon API Gateway, sau đó được định tuyến đến hàm Lambda tương ứng.
  2. Một hàm Lambda (với một lớp tùy chỉnh SageMaker tích hợp) thực hiện việc tiền xử lý cần thiết, định dạng dữ liệu đầu vào JSON hoặc CSV, và gọi các điểm kết tương ứng.
  3. Phản hồi được trả về Lambda và gửi trở lại ứng dụng thông qua API Gateway.

Khách hàng đã sử dụng ống đựng này cho các mô hình quy mô nhỏ và trung bình, bao gồm việc sử dụng nhiều loại thuật toán mã nguồn mở khác nhau. Một trong những lợi ích chính của SageMaker là nhiều loại thuật toán có thể được đưa vào SageMaker và triển khai bằng cách sử dụng kỹ thuật mang theo container của riêng bạn (BYOC). BYOC bao gồm việc đặt thuật toán vào container và đăng ký hình ảnh trong Amazon Elastic Container Registry (Amazon ECR), sau đó sử dụng cùng hình ảnh đó để tạo một container để thực hiện quá trình đào tạo và suy luận.

Việc mở rộng là một trong những vấn đề lớn trong chu kỳ học máy. SageMaker đi kèm với các công cụ cần thiết để mở rộng mô hình trong suy luận. Trong kiến trúc trước đó, người dùng cần kích hoạt tự động mở rộng của SageMaker, điều này cuối cùng sẽ xử lý công việc. Để kích hoạt tự động mở rộng, người dùng phải cung cấp một chính sách tự động mở rộng yêu cầu thông lượng cho mỗi trường hợp và số trường hợp tối đa và tối thiểu. Với chính sách đã đặt, SageMaker tự động xử lý công việc cho các điểm kết thời gian thực và chuyển đổi giữa các trường hợp khi cần thiết.

Quy trình giám sát mô hình tùy chỉnh

  • Mục đích: Đội ngũ của khách hàng muốn có giám sát mô hình tự động để theo dõi cả biến thiên dữ liệu và biến thiên mô hình. Nhóm Wipro đã sử dụng giám sát mô hình SageMaker để kích hoạt cả biến thiên dữ liệu và biến thiên mô hình với một ống đựng có thể tái sử dụng cho suy luận thời gian thực và biến đổi theo lô. Lưu ý rằng trong quá trình phát triển giải pháp này, giám sát mô hình SageMaker không cung cấp khả năng phát hiện biến thiên dữ liệu hoặc mô hình cho biến đổi theo lô. Chúng tôi đã thực hiện các tùy chỉnh để sử dụng container giám sát mô hình cho các dữ liệu đầu vào của biến đổi theo lô.
  • Giải pháp: Nhóm Wipro triển khai một ống đựng giám sát mô hình có thể tái sử dụng cho các dữ liệu suy luận thời gian thực và theo lô bằng cách sử dụng AWS Glue để chụp dữ liệu tăng dần và kích hoạt công việc giám sát mô hình theo lịch trình đã xác định.

Figure 7 – Model monitor step machine

Mô tả quy trình cho ống đựng giám sát mô hình tùy chỉnh:

Ống đựng chạy theo lịch trình đã xác định thông qua EventBridge.

  1. CSV consolidation – Sử dụng tính năng đánh dấu trang của AWS Glue để phát hiện sự hiện diện của dữ liệu tăng dần trong thùng chứa S3 đã định nghĩa của việc thu thập dữ liệu thời gian thực và phản hồi và dữ liệu phản hồi theo lô. Sau đó, nó tập hợp dữ liệu đó để tiếp tục xử lý.
  2. Evaluate payload – Nếu có dữ liệu tăng dần hoặc dữ liệu cho chạy hiện tại, nó kích hoạt nhánh giám sát. Ngược lại, nó tránh xử lý và thoát khỏi công việc mà không xử lý.
  3. Post processing – Nhánh giám sát được thiết kế để có hai nhánh con song song—một cho biến thiên dữ liệu và một cho biến thiên mô hình.
  4. Monitoring (data drift) – Nhánh biến thiên dữ liệu chạy mỗi khi có dữ liệu tăng dần. Nó sử dụng các ràng buộc và tập tin thống kê cơ bản của mô hình được đào tạo mới nhất được tạo thông qua đường ống đào tạo cho các đặc trưng dữ liệu và chạy công việc giám sát mô hình.
  5. Monitoring (model drift) – Nhánh biến thiên mô hình chỉ chạy khi có dữ liệu thực tế được cung cấp, cùng với dữ liệu suy luận. Nó sử dụng các ràng buộc và tập tin thống kê cơ bản của mô hình được đào tạo mới nhất được tạo thông qua đường ống đào tạo cho các đặc trưng chất lượng mô hình và chạy công việc giám sát mô hình.
  6. Evaluate drift – Kết quả của cả biến thiên dữ liệu và biến thiên mô hình là một tệp vi phạm ràng buộc được đánh giá bởi hàm đánh giá biến thiên Lambda, sau đó gửi thông báo đến các chủ đề Amazon SNS tương ứng với chi tiết về biến thiên. Dữ liệu biến thiên được bổ sung thêm với việc thêm các thuộc tính cho mục đích báo cáo. Các email thông báo về biến thiên sẽ giống như ví dụ trong Hình 8.

Figure 8 – Data and model drift notification message

Figure 9 – Data and model drift notification message

Insights with Amazon QuickSight visualization:

  • Mục tiêu: Khách hàng muốn có thông tin chi tiết về sự biến thiên của dữ liệu và mô hình, liên quan dữ liệu biến thiên với công việc giám sát mô hình tương ứng và tìm hiểu xu hướng dữ liệu suy luận để hiểu rõ bản chất của các xu hướng dữ liệu suy luận.
  • Giải pháp: Đội ngũ Wipro đã bổ sung dữ liệu biến thiên bằng cách kết nối dữ liệu đầu vào với kết quả biến thiên, giúp quá trình triển khai từ biến thiên đến giám sát và dữ liệu suy luận tương ứng. Các hình ảnh và bảng điều khiển được tạo bằng Amazon QuickSight với Amazon Athena làm nguồn dữ liệu (sử dụng dữ liệu biểu diễn và biến thiên CSV Amazon S3).

Figure 10 – Model monitoring visualization architecture

Các yếu tố thiết kế:

  1. Sử dụng bộ dữ liệu spice của QuickSight để đạt được hiệu suất tốt hơn trong bộ nhớ.
  2. Sử dụng API cập nhật bộ dữ liệu của QuickSight để tự động cập nhật dữ liệu spice.
  3. Thực hiện bảo mật dựa trên nhóm cho quyền truy cập bảng điều khiển và phân tích.
  4. Tự động triển khai qua các tài khoản bằng cách sử dụng các cuộc gọi API xuất và nhập bộ dữ liệu, nguồn dữ liệu và phân tích do QuickSight cung cấp.

Bảng điều khiển giám sát mô hình:

Để kích thích hiệu suất hiệu quả và thông tin có ý nghĩa của các công việc giám sát mô hình, đã được tạo ra các bảng điều khiển tùy chỉnh cho dữ liệu giám sát mô hình. Các điểm dữ liệu đầu vào được kết hợp song song với dữ liệu yêu cầu suy luận, dữ liệu công việc và kết quả giám sát để tạo ra một biểu đồ hóa về xu hướng được bật mí bởi giám sát mô hình.

Điều này thực sự đã giúp đội ngũ của khách hàng hình dung về các khía cạnh của các đặc điểm dữ liệu khác nhau cùng với kết quả dự đoán của mỗi lô yêu cầu suy luận.

Figure 11 – Model monitor dashboard with selection prompts

Figure 12 – Model monitor drift analysis

Kết luận

Việc triển khai được giải thích trong bài viết này đã giúp Wipro chuyển đổi mô hình từ on-premises hiệu quả sang AWS và xây dựng một khung hệ thống phát triển mô hình tự động có thể mở rộng.

Việc sử dụng các thành phần khung hệ thống có thể tái sử dụng giúp đội ngũ khoa học dữ liệu đóng gói công việc của họ một cách hiệu quả như là các thành phần JSON của AWS Step Functions có thể triển khai. Đồng thời, các đội DevOps đã sử dụng và cải thiện ống cống CI/CD tự động để tạo điều kiện thuận lợi cho việc thăng cấp và đào tạo lại các mô hình ở môi trường cao hơn.

Thành phần giám sát mô hình đã kích thích giám sát liên tục về hiệu suất của mô hình, và người dùng nhận được cảnh báo và thông báo mỗi khi phát hiện có sự thay đổi trong dữ liệu hoặc mô hình.

Đội ngũ của khách hàng đang sử dụng khung hệ thống MLOps này để chuyển đổi hoặc phát triển thêm các mô hình và tăng cường việc sử dụng SageMaker.

Bằng cách tận dụng bộ dịch vụ SageMaker toàn diện kết hợp với kiến trúc được thiết kế tỉ mỉ của chúng tôi, khách hàng có thể dễ dàng triển khai nhiều mô hình, giảm đáng kể thời gian triển khai và giảm bớt những phức tạp liên quan đến việc chia sẻ mã nguồn. Hơn nữa, kiến trúc của chúng tôi đơn giản hóa việc bảo trì phiên bản mã, đảm bảo một quy trình phát triển mạch lạc.

Kiến trúc này xử lý toàn bộ chu kỳ học máy, bao gồm việc đào tạo mô hình tự động, suy luận thời gian thực và theo lô, giám sát mô hình proactively, và phân tích sự thay đổi. Giải pháp từ đầu đến cuối này giúp khách hàng đạt được hiệu suất mô hình tối ưu trong khi duy trì khả năng giám sát và phân tích nghiêm túc để đảm bảo độ chính xác và đáng tin cậy liên tục.

Để tạo kiến trúc này, bắt đầu bằng việc tạo các nguồn lực cơ bản như Amazon Virtual Private Cloud (Amazon VPC), SageMaker notebooks và các hàm Lambda. Hãy đảm bảo thiết lập các chính sách quản lý truy cập và xác thực (IAM) AWS phù hợp cho những nguồn lực này.

Tiếp theo, tập trung vào việc xây dựng các thành phần của kiến trúc – chẳng hạn như kịch bản đào tạo và tiền xử lý – trong SageMaker Studio hoặc Jupyter Notebook. Bước này liên quan đến việc phát triển mã và cấu hình cần thiết để kích hoạt các chức năng mong muốn.

Sau khi các thành phần của kiến trúc được xác định, bạn có thể tiếp tục xây dựng các hàm Lambda để tạo các dự đoán hoặc thực hiện các bước xử lý sau khi dữ liệu được xử lý.

Cuối cùng, sử dụng Step Functions để kết nối các thành phần và thiết lập một luồng công việc mượt mà điều phối việc chạy từng bước.

Về tác giả: 

Stephen Randolph là Kiến trúc sư giải pháp đối tác cấp cao tại Amazon Web Services (AWS). Anh tạo điều kiện và hỗ trợ các đối tác của Nhà tích hợp hệ thống toàn cầu (GSI) về công nghệ AWS mới nhất khi họ phát triển các giải pháp ngành nhằm giải quyết các thách thức kinh doanh. Stephen đặc biệt đam mê Bảo mật và AI sáng tạo, đồng thời giúp khách hàng và đối tác xây dựng các giải pháp an toàn, hiệu quả và sáng tạo trên AWS.

Bhajandeep SinghBhajandeep Singh đã từng giữ chức vụ Giám đốc Trung tâm xuất sắc AI/ML AWS tại Wipro Technologies, dẫn đầu các hoạt động tương tác với khách hàng để cung cấp giải pháp phân tích dữ liệu và AI. Anh có chứng chỉ Chuyên môn AI/ML của AWS và là tác giả của các blog kỹ thuật về các giải pháp và dịch vụ AI/ML. Với kinh nghiệm dẫn đầu về các giải pháp AI/ML của AWS trong nhiều ngành, Bhajandeep đã giúp khách hàng tối đa hóa giá trị của các dịch vụ AI/ML của AWS thông qua kiến thức chuyên môn và khả năng lãnh đạo của mình.

Ajay VishwakarmaAjay Vishwakarma là kỹ sư ML cho bộ phận AWS về thực hành giải pháp AI của Wipro. Anh ấy có kinh nghiệm tốt trong việc xây dựng giải pháp BYOM cho thuật toán tùy chỉnh trong SageMaker, triển khai quy trình ETL từ đầu đến cuối, xây dựng chatbot bằng Lex, chia sẻ tài nguyên QuickSight trên nhiều tài khoản và xây dựng các mẫu CloudFormation để triển khai. Anh ấy thích khám phá AWS, coi mọi vấn đề của khách hàng là một thử thách để khám phá nhiều hơn và cung cấp giải pháp cho họ.