Bên trong Monolith của ByteDance: Công cụ cung cấp các nguồn cấp dữ liệu nội dung thông minh hơn, nhanh hơn

Tác giả: Zhuoran Liu, Bytedance Inc. Leqi Zou, Bytedance Inc. Xuan Zou, Bytedance Inc. Caihua Wang, Bytedance Inc. Biao Zhang, Bytedance Inc. Da Tang, Bytedance Inc. Bolin Zhu∗, Đại học Fudan Yijie Zhu, Bytedance Inc. Peng Wu, Bytedance Inc. Ke Wang, Bytedance Inc. Youlong Cheng†, Bytedance Inc. (youlong.cheng@bytedance.com) TÓM TẮT Việc xây dựng một hệ thống đề xuất có khả năng mở rộng và thời gian thực rất quan trọng đối với nhiều doanh nghiệp được thúc đẩy bởi phản hồi của khách hàng theo thời gian nhạy cảm, chẳng hạn như xếp hạng video ngắn hoặc quảng cáo trực tuyến. Mặc dù các framework học sâu ở quy mô sản xuất như Ten-sorFlow hoặc PyTorch được áp dụng phổ biến, các framework đa dụng này không đáp ứng được nhu cầu kinh doanh trong các tình huống đề xuất vì nhiều lý do: một mặt, việc tinh chỉnh hệ thống dựa trên các tham số tĩnh và tính toán dày đặc cho đề xuất với các đặc trưng động và thưa thớt có hại cho chất lượng mô hình; mặt khác, các framework như vậy được thiết kế với giai đoạn huấn luyện theo lô và giai đoạn phục vụ hoàn toàn tách biệt, ngăn mô hình tương tác với phản hồi của khách hàng theo thời gian thực. Những vấn đề này đã thúc đẩy chúng tôi xem xét lại các phương pháp truyền thống và khám phá các lựa chọn thiết kế khác biệt hoàn toàn. Trong bài báo này, chúng tôi giới thiệu 1, một hệ thống được tùy chỉnh cho huấn luyện trực tuyến. Thiết kế của chúng tôi được thúc đẩy bởi những quan sát về khối lượng công việc ứng dụng và môi trường sản xuất của chúng tôi, phản ánh một sự thay đổi rõ rệt so với các hệ thống đề xuất khác. Đóng góp của chúng tôi rất đa dạng: thứ nhất, chúng tôi đã tạo ra một bảng nhúng không va chạm với các tối ưu hóa như nhúng có thể hết hạn và lọc tần suất để giảm dấu vết bộ nhớ của nó; thứ hai, chúng tôi cung cấp một kiến trúc huấn luyện trực tuyến sẵn sàng cho sản xuất với khả năng chịu lỗi cao; cuối cùng, chúng tôi đã chứng minh rằng độ tin cậy của hệ thống có thể được đánh đổi để học theo thời gian thực. Monolith đã được triển khai thành công trong sản phẩm BytePlus Recommend2 của chúng tôi. Monolith 1 GIỚI THIỆU Thập kỷ qua đã chứng kiến sự bùng nổ của các doanh nghiệp được cung cấp bởi các kỹ thuật đề xuất. Để theo đuổi trải nghiệm khách hàng tốt hơn, việc cung cấp nội dung cá nhân hóa cho từng người dùng riêng lẻ như một phản hồi theo thời gian thực là mục tiêu chung của các ứng dụng kinh doanh này. Để đạt được điều này, thông tin từ tương tác gần đây nhất của người dùng thường được sử dụng làm đầu vào chính để huấn luyện mô hình, vì nó sẽ thể hiện tốt nhất chân dung người dùng và đưa ra dự đoán về sở thích và hành vi tương lai của người dùng. Học sâu đã thống trị các mô hình đề xuất [ , , , , , ] vì lượng dữ liệu người dùng khổng lồ phù hợp một cách tự nhiên với các mô hình mạng nơ-ron được điều khiển bởi dữ liệu quy mô lớn. Tuy nhiên, các nỗ lực khai thác sức mạnh của học sâu trong các hệ thống đề xuất cấp công nghiệp liên tục gặp phải các vấn đề phát sinh từ các đặc điểm độc đáo của dữ liệu có nguồn gốc từ hành vi người dùng trong thế giới thực. Dữ liệu này khác biệt đáng kể so với dữ liệu được sử dụng trong các bài toán học sâu thông thường như mô hình hóa ngôn ngữ hoặc thị giác máy tính ở hai khía cạnh: 5 6 10 12 20 21 (1) Các đặc trưng chủ yếu là thưa thớt, phân loại và thay đổi động; (2) Phân phối cơ bản của dữ liệu huấn luyện không ổn định, hay còn gọi là Concept Drift . Sự khác biệt này đã đặt ra những thách thức độc đáo cho các nhà nghiên cứu và kỹ sư làm việc trên các hệ thống đề xuất. 1.1 Sự thưa thớt và động Dữ liệu cho đề xuất chủ yếu chứa các đặc trưng phân loại thưa thớt, một số trong đó xuất hiện với tần suất thấp. Việc ánh xạ phổ biến chúng vào không gian nhúng nhiều chiều sẽ dẫn đến một loạt các vấn đề: • Không giống như các mô hình ngôn ngữ có số lượng từ hạn chế, số lượng người dùng và các mục xếp hạng lớn hơn nhiều lần. Bảng nhúng khổng lồ như vậy khó có thể nằm trong bộ nhớ của một máy chủ duy nhất; • Tệ hơn nữa, kích thước của bảng nhúng dự kiến sẽ tăng theo thời gian khi nhiều người dùng và mục được thêm vào, trong khi các framework như [ , ] sử dụng các biến dày đặc có kích thước cố định để đại diện cho bảng nhúng. 1 17 Trên thực tế, nhiều hệ thống áp dụng băm có va chạm thấp [ , ] như một cách để giảm dấu vết bộ nhớ và cho phép tăng ID. Điều này dựa trên một giả định quá lý tưởng rằng các ID trong bảng nhúng được phân phối đều về tần suất và các va chạm không gây hại cho chất lượng mô hình. Không may, điều này hiếm khi đúng đối với hệ thống đề xuất trong thế giới thực, nơi một nhóm nhỏ người dùng hoặc mục có số lần xuất hiện nhiều hơn đáng kể. Với sự phát triển tự nhiên của kích thước bảng nhúng, cơ hội va chạm khóa băm tăng lên và dẫn đến suy giảm chất lượng mô hình 3 6 . Do đó, nhu cầu tự nhiên đối với các hệ thống đề xuất quy mô sản xuất là có khả năng nắm bắt càng nhiều đặc trưng trong các tham số của nó, và cũng có khả năng điều chỉnh linh hoạt số lượng người dùng và mục mà nó cố gắng theo dõi. 1.2 Phân phối không ổn định Các mẫu hình ảnh và ngôn ngữ hầu như không phát triển trong thang thời gian hàng thế kỷ, trong khi cùng một người dùng quan tâm đến một chủ đề có thể thay đổi sự nhiệt tình của họ ngay phút tiếp theo. Do đó, phân phối cơ bản của dữ liệu người dùng không ổn định, một hiện tượng thường được gọi là Concept Drift . Theo trực giác, thông tin từ lịch sử gần đây hơn có thể đóng góp hiệu quả hơn vào việc dự đoán sự thay đổi trong hành vi của người dùng. Để giảm thiểu ảnh hưởng của Concept Drift, các mô hình phục vụ cần được cập nhật từ phản hồi mới của người dùng càng gần thời gian thực càng tốt để phản ánh sở thích mới nhất của người dùng. Dựa trên những điểm khác biệt này và quan sát các vấn đề phát sinh từ sản xuất của chúng tôi, chúng tôi đã thiết kế , một hệ thống đề xuất quy mô lớn để giải quyết những vấn đề nan giải này. Chúng tôi đã thực hiện các thí nghiệm mở rộng để xác minh và lặp lại thiết kế của chúng tôi trong môi trường sản xuất. Monolith có thể Monolith (1) Cung cấp toàn bộ sức mạnh biểu đạt cho các đặc trưng thưa thớt bằng cách thiết kế một bảng băm không va chạm và một cơ chế loại bỏ đặc trưng động; (2) Lặp lại phản hồi phục vụ trở lại quá trình huấn luyện theo thời gian thực với huấn luyện trực tuyến. Được trao quyền bởi các năng lực kiến trúc này, Monolith liên tục vượt trội hơn các hệ thống áp dụng các thủ thuật băm có va chạm với mức sử dụng bộ nhớ tương tự, và đạt được AUC phục vụ trực tuyến hàng đầu mà không làm quá tải sức mạnh tính toán của máy chủ. Phần còn lại của bài báo được tổ chức như sau. Chúng tôi đầu tiên trình bày chi tiết thiết kế về cách Monolith giải quyết các thách thức hiện có với bảng băm không va chạm và huấn luyện thời gian thực trong Phần 2. Các thí nghiệm và kết quả sẽ được trình bày trong Phần 3, cùng với các kết luận đã được kiểm nghiệm trong sản xuất và một số thảo luận về sự đánh đổi giữa độ nhạy cảm với thời gian, độ tin cậy và chất lượng mô hình. Phần 4 tóm tắt công việc liên quan và so sánh chúng với Monolith. Phần 5 kết luận công trình này. 2 THIẾT KẾ Kiến trúc tổng thể của Monolith thường tuân theo cài đặt Worker- arameter erver phân tán của TensorFlow (Hình Trong kiến trúc Worker-PS, các máy được gán các vai trò khác nhau; máy Worker chịu trách nhiệm thực hiện các phép tính được định nghĩa bởi biểu đồ, và máy PS lưu trữ các tham số và cập nhật chúng theo gradient được tính bởi Workers. P S 2). Trong các mô hình đề xuất, các tham số được phân loại thành hai tập hợp: dày đặc và thưa thớt. Tham số dày đặc là trọng số/biến trong một mạng nơ-ron sâu, và tham số thưa thớt đề cập đến các bảng nhúng tương ứng với các đặc trưng thưa thớt. Trong thiết kế của chúng tôi, cả tham số dày đặc và thưa thớt đều là một phần của Biểu đồ TensorFlow và được lưu trữ trên các máy chủ tham số. Tương tự như Biến của TensorFlow cho các tham số dày đặc, chúng tôi đã thiết kế một bộ các hoạt động HashTable hiệu quả cao, không va chạm và linh hoạt cho các tham số thưa thớt. Như một sự bổ sung cho hạn chế của TensorFlow phát sinh từ sự tách biệt giữa huấn luyện và suy luận, huấn luyện trực tuyến có khả năng mở rộng linh hoạt của Monolith được thiết kế để đồng bộ hóa hiệu quả các tham số từ PS huấn luyện sang PS phục vụ trực tuyến trong các khoảng thời gian ngắn, với đảm bảo độ bền của mô hình được cung cấp bởi cơ chế chịu lỗi. 2.1 Bảng băm Nguyên tắc đầu tiên trong thiết kế biểu diễn tham số thưa thớt của chúng tôi là tránh dồn thông tin từ các ID khác nhau vào cùng một bản nhúng có kích thước cố định. Mô phỏng một bảng nhúng có kích thước động với một biến TensorFlow có sẵn không thể tránh khỏi va chạm ID, điều này càng trầm trọng hơn khi các ID mới xuất hiện và bảng phát triển. Do đó, thay vì xây dựng trên Biến, chúng tôi đã phát triển một HashTable khóa-giá trị mới cho các tham số thưa thớt của chúng tôi. HashTable của chúng tôi sử dụng Cuckoo Hashmap [ ] dưới lớp vỏ, hỗ trợ chèn các khóa mới mà không va chạm với các khóa hiện có. Cuckoo Hashing đạt được độ phức tạp thời gian 𝑂(1) trong trường hợp xấu nhất cho việc tra cứu và xóa, và độ phức tạp thời gian trung bình dự kiến là 𝑂(1) cho việc chèn. Như minh họa trong Hình , nó duy trì hai bảng 𝑇0, 𝑇1 với các hàm băm khác nhau ℎ0 (𝑥), ℎ1 (𝑥), và một phần tử sẽ được lưu trữ trong một trong hai bảng đó. Khi cố gắng chèn một phần tử 16 3 𝐴 vào 𝑇0, nó sẽ cố gắng đặt 𝐴 tại ℎ0 (𝐴); Nếu ℎ0 (𝐴) bị chiếm bởi một phần tử khác 𝐵, nó sẽ loại bỏ 𝐵 khỏi 𝑇0 và cố gắng chèn 𝐵 vào 𝑇1 với logic tương tự. Quá trình này sẽ được lặp lại cho đến khi tất cả các phần tử ổn định, hoặc băm lại xảy ra khi việc chèn gặp chu kỳ. Giảm dấu vết bộ nhớ cũng là một cân nhắc quan trọng trong thiết kế của chúng tôi. Một phương pháp đơn giản để chèn mọi ID mới vào HashTable sẽ nhanh chóng làm cạn kiệt bộ nhớ. Quan sát các mô hình sản xuất thực tế dẫn đến hai kết luận: (1) Các ID chỉ xuất hiện một vài lần có đóng góp hạn chế vào việc cải thiện chất lượng mô hình. Một quan sát quan trọng là các ID được phân phối theo đuôi dài, nơi các ID phổ biến có thể xuất hiện hàng triệu lần trong khi các ID không phổ biến chỉ xuất hiện không quá mười lần. Các bản nhúng tương ứng với các ID không thường xuyên này bị thiếu dữ liệu huấn luyện và mô hình sẽ không thể đưa ra ước tính tốt dựa trên chúng. Cuối cùng, những ID này không có khả năng ảnh hưởng đến kết quả, vì vậy chất lượng mô hình sẽ không bị ảnh hưởng bởi việc loại bỏ các ID có số lần xuất hiện thấp; (2) Các ID cũ từ lịch sử xa xôi hiếm khi đóng góp vào mô hình hiện tại vì nhiều trong số chúng không bao giờ được truy cập. Điều này có thể xảy ra do một người dùng không còn hoạt động, hoặc một video ngắn đã lỗi thời. Lưu trữ các bản nhúng cho các ID này không giúp ích gì cho mô hình mà chỉ làm lãng phí bộ nhớ PS của chúng tôi một cách vô ích. Dựa trên những quan sát này, chúng tôi đã thiết kế một số heuristic lọc ID đặc trưng để triển khai HashTable hiệu quả bộ nhớ hơn: (1) Các ID được lọc trước khi chúng được chấp nhận vào bảng nhúng. Chúng tôi có hai phương pháp lọc: Đầu tiên, chúng tôi lọc theo số lần xuất hiện của chúng trước khi chúng được chèn làm khóa, trong đó ngưỡng số lần xuất hiện là một siêu tham số có thể điều chỉnh thay đổi cho mỗi mô hình; Ngoài ra, chúng tôi sử dụng bộ lọc xác suất giúp giảm thêm việc sử dụng bộ nhớ; ![#Hình 4: Streaming Engine. Vòng lặp phản hồi thông tin từ [Người dùng → Máy chủ Mô hình → Nhân viên Huấn luyện → Máy chủ Mô hình → Người dùng] sẽ tốn nhiều thời gian khi đi theo đường Huấn luyện theo lô, trong khi Huấn luyện Trực tuyến sẽ đóng vòng lặp tức thời hơn.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) Các ID được đặt hẹn giờ và đặt hết hạn sau một khoảng thời gian không hoạt động được xác định trước. Thời gian hết hạn cũng có thể điều chỉnh được cho mỗi bảng nhúng để cho phép phân biệt các đặc trưng có độ nhạy cảm khác nhau với thông tin lịch sử. Trong quá trình triển khai của chúng tôi, HashTable được triển khai dưới dạng một hoạt động tài nguyên của Tensor-Flow. Tương tự như Biến, việc tra cứu và cập nhật cũng được triển khai dưới dạng các hoạt động TensorFlow gốc để dễ dàng tích hợp và tương thích tốt hơn. 2.2 Huấn luyện trực tuyến Trong Monolith, quá trình huấn luyện được chia thành hai giai đoạn (Hình 1): (1) Giai đoạn huấn luyện theo lô. Giai đoạn này hoạt động như một vòng lặp huấn luyện TensorFlow thông thường: Trong mỗi bước huấn luyện, một nhân viên huấn luyện đọc một lô nhỏ các ví dụ huấn luyện từ bộ lưu trữ, yêu cầu các tham số từ PS, thực hiện một lượt truyền xuôi và một lượt truyền ngược, và cuối cùng đẩy các tham số đã cập nhật tới PS huấn luyện. Khác một chút so với các tác vụ học sâu thông thường khác, chúng tôi chỉ huấn luyện tập dữ liệu của mình trong một lượt. Huấn luyện theo lô hữu ích cho việc huấn luyện dữ liệu lịch sử khi chúng tôi sửa đổi kiến trúc mô hình và huấn luyện lại mô hình; (2) Giai đoạn huấn luyện trực tuyến. Sau khi mô hình được triển khai để phục vụ trực tuyến, quá trình huấn luyện không dừng lại mà chuyển sang giai đoạn huấn luyện trực tuyến. Thay vì đọc các ví dụ theo lô nhỏ từ bộ lưu trữ, một nhân viên huấn luyện xử lý dữ liệu thời gian thực theo yêu cầu và cập nhật PS huấn luyện. PS huấn luyện định kỳ đồng bộ hóa các tham số của nó với PS phục vụ, điều này sẽ có hiệu lực ngay lập tức đối với người dùng. Điều này cho phép mô hình của chúng tôi tương tác thích ứng với phản hồi của người dùng theo thời gian thực. Monolith được xây dựng với khả năng chuyển đổi liền mạch giữa huấn luyện theo lô và huấn luyện trực tuyến. Điều này được hỗ trợ bởi thiết kế của chúng tôi về công cụ streaming như minh họa trong Hình 2.2.1 Streaming Engine. 4. Trong thiết kế của chúng tôi, chúng tôi sử dụng một hàng đợi Kafka [ ] để ghi lại các hành động của người dùng (Ví dụ: Nhấp vào một mục hoặc thích một mục, v.v.) và một hàng đợi Kafka khác cho các đặc trưng. Cốt lõi của công cụ là một công việc streaming Flink [ ] cho trình kết hợp đặc trưng trực tuyến. Trình kết hợp trực tuyến nối các đặc trưng với các nhãn từ hành động của người dùng và tạo ra các ví dụ huấn luyện, sau đó được ghi vào hàng đợi Kafka. Hàng đợi cho các ví dụ huấn luyện được tiêu thụ bởi cả huấn luyện trực tuyến và huấn luyện theo lô: 13 4 Đối với huấn luyện trực tuyến, nhân viên huấn luyện đọc trực tiếp dữ liệu từ hàng đợi Kafka; Đối với huấn luyện theo lô, một công việc đổ dữ liệu sẽ trước tiên đổ dữ liệu vào HDFS [ ]; Sau khi dữ liệu trong HDFS tích lũy đến một lượng nhất định, nhân viên huấn luyện sẽ lấy dữ liệu từ HDFS và thực hiện huấn luyện theo lô. 18 Các tham số đã cập nhật trong PS huấn luyện sẽ được đẩy tới PS phục vụ theo lịch trình đồng bộ hóa tham số. Trong các ứng dụng thực tế, nhật ký hành động của người dùng và các đặc trưng được truyền trực tuyến vào trình kết hợp trực tuyến (Hình mà không đảm bảo thứ tự thời gian. Do đó, chúng tôi sử dụng một khóa duy nhất cho mỗi yêu cầu để hành động của người dùng và các đặc trưng có thể được ghép nối chính xác. 2.2.2 Online Joiner. 5) Độ trễ của hành động người dùng cũng có thể là một vấn đề. Ví dụ, một người dùng có thể mất vài ngày trước khi họ quyết định mua một mặt hàng đã được giới thiệu cho họ vài ngày trước. Đây là một thách thức đối với trình kết hợp vì nếu tất cả các đặc trưng được giữ trong bộ nhớ đệm, nó sẽ đơn giản là không vừa với bộ nhớ. Trong hệ thống của chúng tôi, một bộ lưu trữ khóa-giá trị trên đĩa được sử dụng để lưu trữ các đặc trưng đang chờ đợi trong một khoảng thời gian nhất định. Khi một nhật ký hành động người dùng đến, nó trước tiên tra cứu bộ nhớ đệm trong bộ nhớ, và sau đó tra cứu bộ lưu trữ khóa-giá trị trong trường hợp bộ nhớ đệm bị thiếu. Một vấn đề khác phát sinh trong các ứng dụng thực tế là phân phối các ví dụ tiêu cực và tích cực không đồng đều, trong đó số lượng ví dụ trước có thể cao hơn nhiều lần so với ví dụ sau. Để ngăn chặn các ví dụ tích cực bị lấn át bởi các ví dụ tiêu cực, một chiến lược phổ biến là lấy mẫu âm. Điều này chắc chắn sẽ thay đổi phân phối cơ bản của mô hình đã huấn luyện, điều chỉnh nó theo hướng xác suất dự đoán tích cực cao hơn. Để khắc phục, chúng tôi áp dụng hiệu chỉnh log odds [ ] trong quá trình phục vụ, đảm bảo rằng mô hình trực tuyến là một ước lượng không thiên vị của phân phối ban đầu. 19 Trong quá trình huấn luyện trực tuyến, cụm huấn luyện Monolith liên tục nhận dữ liệu từ mô-đun phục vụ trực tuyến và cập nhật các tham số trên PS huấn luyện. Một bước quan trọng để PS phục vụ trực tuyến được hưởng lợi từ các tham số được huấn luyện mới này là đồng bộ hóa các tham số mô hình đã cập nhật. Trong môi trường sản xuất, chúng tôi gặp phải một số thách thức: 2.2.3 Đồng bộ hóa tham số. Các mô hình trên PS phục vụ trực tuyến không được phép ngừng phục vụ khi cập nhật. Các mô hình của chúng tôi trong sản xuất thường có kích thước vài terabyte, và kết quả là việc thay thế tất cả các tham số mất một thời gian. Việc dừng PS trực tuyến phục vụ mô hình trong quá trình thay thế sẽ không thể chấp nhận được, và các bản cập nhật phải được thực hiện theo yêu cầu; Việc truyền toàn bộ mô hình đa terabyte từ PS huấn luyện sang PS phục vụ trực tuyến sẽ tạo áp lực lớn lên cả băng thông mạng và bộ nhớ trên PS, vì nó yêu cầu bộ nhớ gấp đôi kích thước mô hình để chấp nhận mô hình mới đến. Để huấn luyện trực tuyến có thể mở rộng quy mô theo kích thước kịch bản kinh doanh của chúng tôi, chúng tôi đã thiết kế một cơ chế đồng bộ hóa tham số định kỳ tăng dần theo yêu cầu trong Monolith dựa trên một số đặc điểm đáng chú ý của mô hình của chúng tôi: (1) Tham số thưa thớt chiếm ưu thế trong kích thước của các mô hình đề xuất; (2) Với một cửa sổ thời gian ngắn, chỉ một tập hợp con nhỏ các ID được huấn luyện và các bản nhúng của chúng được cập nhật; (3) Biến dày đặc di chuyển chậm hơn nhiều so với nhúng thưa thớt. Điều này là do trong các bộ tối ưu hóa dựa trên động lượng, sự tích lũy động lượng cho các biến dày đặc được phóng đại bởi kích thước khổng lồ của dữ liệu huấn luyện đề xuất, trong khi chỉ một vài nhúng thưa thớt nhận được các bản cập nhật trong một lô dữ liệu duy nhất. (1) và (2) cho phép chúng tôi khai thác các bản cập nhật thưa thớt trên tất cả các ID đặc trưng. Trong Monolith, chúng tôi duy trì một tập hợp băm các khóa đã chạm, đại diện cho các ID có nhúng được huấn luyện kể từ lần đồng bộ hóa tham số cuối cùng. Chúng tôi đẩy tập hợp con các tham số thưa thớt có khóa nằm trong tập hợp khóa đã chạm với khoảng thời gian phút từ PS huấn luyện đến PS phục vụ trực tuyến. Gói cập nhật tham số tăng dần tương đối nhỏ này nhẹ cho việc truyền mạng và sẽ không gây ra đột biến bộ nhớ trong quá trình đồng bộ hóa. Chúng tôi cũng khai thác (3) để giảm thêm I/O mạng và việc sử dụng bộ nhớ bằng cách đặt lịch trình đồng bộ hóa tích cực hơn cho các tham số thưa thớt, trong khi cập nhật các tham số dày đặc ít thường xuyên hơn. Điều này có thể dẫn đến tình huống mà các tham số dày đặc chúng tôi phục vụ là một phiên bản tương đối cũ so với phần thưa thớt. Tuy nhiên, sự không nhất quán như vậy có thể được chấp nhận do lý do được đề cập trong (3) vì không có tổn thất rõ rệt nào được quan sát. 2.3 Khả năng chịu lỗi Là một hệ thống trong sản xuất, Monolith được thiết kế với khả năng phục hồi PS trong trường hợp nó bị lỗi. Một lựa chọn phổ biến cho khả năng chịu lỗi là chụp nhanh trạng thái của mô hình định kỳ và phục hồi từ ảnh chụp nhanh mới nhất khi lỗi PS được phát hiện. Việc lựa chọn tần suất chụp nhanh có hai tác động chính: (1) Chất lượng mô hình. Theo trực giác, chất lượng mô hình chịu ít tổn thất lịch sử gần đây hơn với tần suất chụp nhanh tăng lên. (2) Chi phí tính toán. Chụp nhanh một mô hình đa terabyte không phải là miễn phí. Nó đòi hỏi các bản sao bộ nhớ lớn và I/O đĩa. Như một sự đánh đổi giữa chất lượng mô hình và chi phí tính toán, Monolith chụp nhanh tất cả PS huấn luyện hàng ngày. Mặc dù PS sẽ mất một ngày cập nhật trong trường hợp bị lỗi, chúng tôi phát hiện ra rằng sự suy giảm hiệu suất là có thể chấp nhận được thông qua các thí nghiệm của chúng tôi. Chúng tôi sẽ phân tích hiệu quả của độ tin cậy PS trong phần tiếp theo. 3 ĐÁNH GIÁ Để hiểu rõ hơn về lợi ích và sự đánh đổi do thiết kế đề xuất của chúng tôi mang lại, chúng tôi đã thực hiện một số thí nghiệm ở quy mô sản xuất và kiểm tra A/B với lưu lượng truy cập phục vụ trực tiếp để đánh giá và xác minh Monolith từ các khía cạnh khác nhau. Chúng tôi đặt mục tiêu trả lời các câu hỏi sau bằng các thí nghiệm của mình: (1) Chúng ta có thể hưởng lợi bao nhiêu từ HashTable không va chạm? (2) Huấn luyện trực tuyến theo thời gian thực quan trọng như thế nào? (3) Thiết kế đồng bộ hóa tham số của Monolith có đủ mạnh mẽ trong kịch bản sản xuất quy mô lớn không? Trong phần này, chúng tôi đầu tiên trình bày thiết lập thử nghiệm của chúng tôi và sau đó thảo luận chi tiết về kết quả và phát hiện của chúng tôi. 3.1 Thiết lập thử nghiệm Như đã mô tả trong Phần các bảng nhúng trong Monolith được triển khai dưới dạng HashTable không va chạm. Để chứng minh sự cần thiết của việc tránh va chạm trong bảng nhúng và định lượng lợi ích từ việc triển khai không va chạm của chúng tôi, chúng tôi đã thực hiện hai nhóm thí nghiệm trên tập dữ liệu Movielens và trên tập dữ liệu sản xuất nội bộ của chúng tôi: 3.1.1 Bảng nhúng. 2.1, (1) Tập dữ liệu ml-25m [ ]. Đây là một tập dữ liệu công khai tiêu chuẩn cho đánh giá phim, chứa 25 triệu đánh giá liên quan đến khoảng 162.000 người dùng và 62.000 phim. MovieLens 11 • . Nhãn gốc là điểm đánh giá từ Tiền xử lý nhãn 0,5 đến 5,0, trong khi trong sản xuất các tác vụ của chúng tôi chủ yếu nhận tín hiệu nhị phân từ người dùng. Để mô phỏng tốt hơn các mô hình sản xuất của chúng tôi, chúng tôi đã chuyển đổi nhãn thang điểm thành nhãn nhị phân bằng cách coi điểm ≥ 3,5 là mẫu tích cực và phần còn lại là mẫu tiêu cực. • Mô hình và chỉ số. Chúng tôi đã triển khai một mô hình DeepFM tiêu chuẩn, một kiến trúc mô hình được sử dụng phổ biến cho các bài toán đề xuất. Nó bao gồm một thành phần FM và một thành phần dày đặc (Hình 6). Dự đoán được đánh giá bằng AUC vì đây là phép đo chính cho các mô hình thực tế. • Va chạm nhúng. Tập dữ liệu này chứa khoảng 160K ID người dùng và 60K ID phim. Để so sánh với phiên bản không va chạm của việc triển khai bảng nhúng, chúng tôi đã thực hiện một nhóm thí nghiệm khác trong đó các ID được tiền xử lý bằng băm MD5 và sau đó được ánh xạ tới một không gian ID nhỏ hơn. Kết quả là, một số ID sẽ chia sẻ bản nhúng của chúng với những ID khác. Bảng 1 hiển thị số liệu thống kê chi tiết về ID người dùng và phim trước và sau khi băm. (2) . Tập dữ liệu đề xuất nội bộ Chúng tôi cũng đã thực hiện các thí nghiệm trên một mô hình đề xuất trong môi trường sản xuất. Mô hình này nói chung tuân theo kiến trúc đa tháp, với mỗi tháp chịu trách nhiệm học để dự đoán một loại hành vi người dùng chuyên biệt. Mỗi mô hình có khoảng 1000 bảng nhúng, và sự phân phối kích thước của các bảng nhúng rất không đồng đều; Không gian ID gốc của bảng nhúng là 248. Trong đường cơ sở của chúng tôi, chúng tôi đã áp dụng một thủ thuật băm bằng cách phân rã để hạn chế kích thước của bảng nhúng. Cụ thể hơn, chúng tôi sử dụng hai bảng nhúng nhỏ hơn thay vì một bảng khổng lồ để tạo ra một bản nhúng duy nhất cho mỗi ID bằng cách kết hợp vectơ: trong đó 𝐸𝑟 , 𝐸𝑞 là các bản nhúng tương ứng với 𝐼𝐷𝑟 , 𝐼𝐷𝑞. Điều này hiệu quả giảm kích thước bảng nhúng từ 248 xuống 225; • Mô hình này đang phục vụ trong sản xuất thực tế, và hiệu suất của thí nghiệm này được đo bằng AUC trực tuyến với lưu lượng phục vụ thực tế. Trong quá trình huấn luyện trực tuyến, chúng tôi cập nhật PS phục vụ trực tuyến của mình với tập hợp tham số mới nhất với khoảng thời gian phút. Chúng tôi đã thiết kế hai nhóm thí nghiệm để xác minh chất lượng mô hình và độ bền của hệ thống. 3.1.2 Huấn luyện trực tuyến. (1) . Để điều tra sự cần thiết của tần suất cập nhật cấp phút, chúng tôi đã tiến hành các thí nghiệm đồng bộ hóa tham số từ mô hình huấn luyện đến mô hình dự đoán với các khoảng thời gian khác nhau. Tần suất cập nhật Tập dữ liệu chúng tôi sử dụng là tập dữ liệu Criteo Display Ads Challenge3, một tập dữ liệu quy mô lớn tiêu chuẩn để đánh giá mô hình CTR. Nó chứa 7 ngày dữ liệu được sắp xếp theo trình tự thời gian ghi lại các đặc trưng và hành động nhấp chuột. Đối với thí nghiệm này, chúng tôi sử dụng mô hình DeepFM tiêu chuẩn như được mô tả trong 6. Để mô phỏng huấn luyện trực tuyến, chúng tôi đã thực hiện tiền xử lý sau cho tập dữ liệu. Chúng tôi lấy 7 ngày dữ liệu từ tập dữ liệu và chia nó thành hai phần: 5 ngày dữ liệu để huấn luyện theo lô và 2 ngày để huấn luyện trực tuyến. Chúng tôi tiếp tục chia 2 ngày dữ liệu thành 𝑁 phân đoạn theo trình tự thời gian. Huấn luyện trực tuyến được mô phỏng bằng thuật toán 1. Do đó, chúng tôi mô phỏng việc đồng bộ hóa các tham số đã huấn luyện tới PS phục vụ trực tuyến với một khoảng thời gian được xác định bởi số lượng phân đoạn dữ liệu. Chúng tôi đã thử nghiệm với 𝑁 = 10, 50, 100