Triển khai hệ thống đề xuất đa phương thức đa giai đoạn trên Amazon Elastic Kubernetes Service

Học máy Triển khai hệ thống đề xuất đa giai đoạn, đa phương thức trên Amazon Elastic Kubernetes Service Với các bộ lọc Bloom, bộ nhớ đệm tính năng, xếp hạng theo ngữ cảnh và quy trình đầu cuối từ chuẩn bị dữ liệu đến phục vụ mô hình. Mustapha Momoh Ngày 19/5/2026 20 phút đọc Chia sẻ Hình 1: Kiến trúc của Hệ thống đề xuất đa giai đoạn được triển khai trên Amazon EKS. Hình ảnh do tác giả cung cấp, lấy cảm hứng từ các công trình trước đây của Even Oldridge và Karl Byleen-Higley, cũng như của Sam, Tyler và Nathan. Xây dựng một hệ thống đề xuất đa giai đoạn, đa phương thức trong môi trường sản xuất không phải là điều đơn giản, đặc biệt khi hệ thống cần mở rộng quy mô, thích ứng gần như theo thời gian thực và chạy ổn định trên đám mây. Trong bài viết này, tôi trình bày kinh nghiệm của mình trong việc thiết kế và triển khai một hệ thống như vậy từ đầu đến cuối, bao gồm chuẩn bị dữ liệu, huấn luyện mô hình đến phục vụ các mô hình trong môi trường sản xuất. Chúng ta sẽ khám phá toàn bộ quy trình, bao gồm truy xuất, lọc, chấm điểm và xếp hạng, cùng với cơ sở hạ tầng và các quyết định quan trọng giúp hệ thống hoạt động. Điều này bao gồm các kho tính năng, bộ lọc Bloom, Kubeflow, thích ứng ưu tiên gần như theo thời gian thực và một cải tiến lớn về độ trễ nhờ bộ nhớ đệm tính năng trong bộ nhớ. Đây là một bài viết dài, nhưng nếu bạn đang xây dựng hoặc mở rộng hệ thống đề xuất, bạn sẽ tìm thấy các mẫu thực tế có thể áp dụng trực tiếp vào các dự án của mình. Các phần chính của bài viết này: Một số thông tin về hệ thống Lý do lựa chọn thiết kế hiện tại Các thành phần hệ thống Nguồn dữ liệu Quy trình huấn luyện và triển khai hoàn chỉnh Quy trình tinh chỉnh liên tục Xử lý các yêu cầu thông qua 14 mô hình trong NVIDIA Triton Inference Server Cải thiện độ trễ tra cứu tính năng mục bằng bộ nhớ đệm trong bộ nhớ Tự động điều chỉnh quy mô Triton Inference Server trên EKS Xác thực các đề xuất theo ngữ cảnh, lọc bằng bộ lọc Bloom và cập nhật đề xuất gần như theo thời gian thực (kèm bản demo) Hạn chế và công việc trong tương lai Kết luận Tài nguyên Một số thông tin về hệ thống Hệ thống đề xuất bao gồm bốn giai đoạn chính: một mô hình Two-Tower tạo ra các ứng viên, một bộ lọc Bloom tạm thời ẩn các mục mà người dùng đã tương tác gần đây, một bộ xếp hạng DLRM chấm điểm các mục còn lại bằng cách sử dụng các tính năng của người dùng, mục và ngữ cảnh, và một giai đoạn sắp xếp lại cuối cùng để sắp xếp và lấy mẫu từ các điểm số này để tạo ra các đề xuất cuối cùng. Các mô hình sử dụng cả các tính năng cộng tác dạng bảng và các nhúng hình ảnh CLIP (Contrastive Language-Image Pre-training) được tính toán trước và nhúng văn bản Sentence-BERT. Trong mô hình truy xuất, các nhúng được huấn luyện trước này được đưa vào tháp ứng viên cùng với các tính năng mục đã học, cung cấp cho tháp ứng viên cả tín hiệu ngữ nghĩa dựa trên nội dung và tín hiệu cộng tác. Tích vô hướng giữa đầu ra tháp truy vấn và đầu ra tháp ứng viên sau đó được sử dụng làm điểm số liên quan đã học trong không gian nhúng chung này. Trong bộ xếp hạng DLRM, các nhúng hình ảnh và văn bản được huấn luyện trước tham gia vào lớp tương tác tích vô hướng. Các tương tác cặp này sau đó được chuyển đến MLP (Multi-Layer Perceptron) trên cùng, cho phép các tín hiệu dựa trên nội dung từ các nhúng được huấn luyện trước bổ sung cho các tín hiệu cộng tác và ngữ cảnh được sử dụng để dự đoán nhấp chuột. Lý do lựa chọn thiết kế hiện tại Trường hợp sử dụng mục tiêu là một nền tảng thương mại điện tử cần đề xuất các sản phẩm phù hợp ngay khi người dùng truy cập trang chủ. Nền tảng này phục vụ cả người dùng đã đăng ký và khách truy cập ẩn danh, và hành vi người dùng có thể thay đổi đáng kể tùy theo ngữ cảnh yêu cầu, chẳng hạn như loại thiết bị, thời gian trong ngày hoặc ngày trong tuần. Điều đó có nghĩa là dịch vụ đề xuất phải cung cấp các đề xuất khởi động lạnh (cold-start recommendations) hợp lý cho người dùng mới và phải điều chỉnh các đề xuất theo ngữ cảnh của yêu cầu hiện tại. Giải pháp cũng cần có khả năng mở rộng. Khi có thêm nhiều nhà bán lẻ tham gia, danh mục sản phẩm có thể tăng lên hàng triệu mặt hàng. Tại thời điểm đó, việc chấm điểm toàn bộ danh mục trên mỗi yêu cầu là không thực tế. Một thiết kế đa giai đoạn giải quyết vấn đề này bằng cách sử dụng giai đoạn truy xuất nhẹ để tìm nạp các ứng viên nhanh chóng và giai đoạn xếp hạng nặng hơn để chấm điểm các ứng viên đó. Ngoài ra, các mô hình đề xuất cần được cập nhật với các tương tác mới, tuy nhiên việc xây dựng lại toàn bộ ngăn xếp truy xuất mỗi ngày là không thực tế. Vì lý do này, hai Kubeflow pipeline được định nghĩa. Pipeline đầu tiên thiết lập các quy trình tiền xử lý, huấn luyện các mô hình từ đầu, xây dựng chỉ mục ANN và triển khai máy chủ Triton cùng các mô hình. Pipeline thứ hai quản lý việc tinh chỉnh hàng ngày, chủ yếu cập nhật tháp truy vấn và bộ xếp hạng; các mô hình được cập nhật với các tín hiệu tương tác mới nhưng các nhúng mục (item embeddings) không được tạo lại. Các thành phần hệ thống Tất cả các thành phần của hệ thống hoạt động cùng nhau để đảm bảo mục tiêu tổng thể là cung cấp các đề xuất phù hợp một cách nhanh chóng và ở quy mô hợp lý được thực hiện. Kubeflow Pipelines quản lý cả quy trình huấn luyện đầy đủ và quy trình tinh chỉnh hàng ngày trên hệ thống dựa trên Kubernetes. Ngăn xếp NVIDIA Merlin xử lý kỹ thuật tính năng tăng tốc GPU, tiền xử lý, huấn luyện các mô hình truy xuất và xếp hạng. Máy chủ Triton Inference lưu trữ biểu đồ phục vụ đa giai đoạn dưới dạng một mô hình tập hợp duy nhất. FAISS đóng vai trò là chỉ mục láng giềng gần đúng (approximate nearest neighbor index) để truy xuất ứng viên. Feast quản lý các tính năng người dùng và mục trên toàn bộ quá trình huấn luyện và phục vụ. ElastiCache cho Valkey (Redis) hỗ trợ kho tính năng trực tuyến, quản lý bộ lọc Bloom của mỗi người dùng để cho phép lọc các mục đã xem khỏi danh sách đề xuất của người dùng và lưu trữ thông tin phổ biến của mục toàn cầu và theo danh mục dựa trên số lượng tương tác. Amazon Athena (với S3 và Glue) hỗ trợ kho tính năng ngoại tuyến. Amazon Elastic Kubernetes Service (EKS) chạy các quy trình học máy được đóng gói và mở rộng quy mô tính toán để đáp ứng nhu cầu khối lượng công việc thay đổi. Hình 2: MLOps hệ thống đề xuất với Kubeflow trên Amazon Elastic Kubernetes Service (hình ảnh của tác giả) Nguồn dữ liệu Dữ liệu huấn luyện đến từ một phiên bản sửa đổi của trình tạo tương tác AWS Retail Demo Store. Nhóm người dùng được mở rộng lên 300.000 trong khi danh mục sản phẩm được giữ ở mức 2.465 mặt hàng, với các hình ảnh và mô tả liên quan. Dữ liệu