Bên trong Monolith của ByteDance: Động cơ cung cấp các nguồn cấp dữ liệu thông minh, 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 Phúc Đán 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 gợi ý có khả năng mở rộng và theo thời gian thực là rất quan trọng đối với nhiều doanh nghiệp dựa trên phản hồi nhạy cảm về thời gian của khách hàng, 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 rộng rãi, 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 gợi ý 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 gợi ý với các đặc trưng động và thưa thớt gây bất lợ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 cả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 căn bả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 việc huấn luyện trực tuyến. Thiết kế của chúng tôi được thúc đẩy bởi các 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 sự khác biệt rõ rệt so với các hệ thống gợi ý 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 xung đột với các tối ưu hóa như bảng nhúng có thể hết hạn và lọc tần suất để giảm dấu chân 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 lấy việc học theo thời gian thực. Monolith đã được triển khai thành công trong sản phẩm BytePlus Recommend2. 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 hỗ trợ bởi các kỹ thuật gợi ý. Để 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 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 mới 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ẽ phản ánh tốt nhất chân dung người dùng và đưa ra dự đoán về sở thích cũng như hành vi tương lai của người dùng. Học sâu đã thống trị các mô hình gợi ý [ , , , , , ] 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 dựa trên dữ liệu quy mô lớn. Tuy nhiên, những nỗ lực khai thác sức mạnh của học sâu trong các hệ thống gợi ý 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. Những dữ liệu này khác biệt đáng kể so với những dữ liệu được sử dụng trong các vấ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à trôi dạt khái niệm (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 về hệ thống gợi ý. 1.1 Tính thưa thớt và động Dữ liệu cho gợi ý 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ạ chúng vào không gian nhúng có chiều cao 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ừ phụ giới hạn, số lượng người dùng và các mục xếp hạng lớn hơn nhiều lần. Một bảng nhúng khổng lồ như vậy sẽ khó có thể nằm vừa 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 có 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 để biểu diễn bảng nhúng. 1 17 Trong thực tế, nhiều hệ thống sử dụng băm có ít xung đột [ , ] như một cách để giảm dấu chân bộ nhớ và cho phép ID phát triển. Đ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 xung đột 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 gợi ý 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ự tăng trưởng tự nhiên về kích thước bảng nhúng, cơ hội xung đột 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 đó, một nhu cầu tự nhiên đối với các hệ thống gợi ý 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. Kết quả là, 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à Trôi dạt khái niệm (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 Trôi dạt khái niệm, 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 với 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à trong 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 gợi ý quy mô lớn để giải quyết những khó khăn này. Chúng tôi đã thực hiện các thí nghiệm sâu 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 sức biểu đạt đầy đủ cho các đặc trưng thưa thớt bằng cách thiết kế bảng băm không xung đột và cơ chế loại bỏ đặc trưng động; (2) Lặp lại phản hồi phục vụ trở lại việc 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 những khả năng 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ó xung đột 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 gây quá tải cho sức mạnh tính toán của máy chủ của chúng tôi. 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 xung đột 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ề 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 nói chung 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 xác định 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 gợi ý, các tham số được phân loại thành hai tập hợp: dày đặc và thưa thớt. Các tham số dày đặc là trọng số/biến trong một mạng nơ-ron sâu, và các 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 xung đột 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ừ việc tách biệt huấn luyện và suy luận, việc 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 khoảng thời gian ngắn, với sự đả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 nhồi nhét thông tin từ các ID khác nhau vào cùng một 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 chắc chắn dẫn đến xung đột 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 dựa 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 [ ] bên dưới, hỗ trợ chèn khóa mới mà không xung đột với các khóa hiện có. Băm Cuckoo đạt được độ phức tạp thời gian 𝑂 (1) trong trường hợp xấu nhất cho tra cứu và xóa, và 𝑂 (1) thời gian trung bình dự kiến cho 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ó đầu tiên 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 cùng một logic. 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 chèn gặp chu kỳ. Giảm dấu chân 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 là chèn mọi ID mới vào HashTable sẽ làm cạn kiệt bộ nhớ nhanh chóng. 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 đuôi dài, trong đó 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 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, các 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 này; (2) Các ID lỗi thời 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ể 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 nhúng cho các ID này không thể giúp ích gì cho mô hình mà chỉ làm cạn kiệt 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 cho việc 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 dưới dạng 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 được 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ớ; ![#Figure 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ẽ mất 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 nhanh hơn.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) Các ID được đặt hẹn giờ và đặt thành hết hạn sau một thời gian không hoạt động nhất định. 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 TensorFlow. Tương tự như Biến, 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 để tích hợp dễ dàng hơn và khả năng tương thích tốt hơn. 2.2 Huấn luyện trực tuyến Trong Monolith, việc 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ộ nhớ, yêu cầu tham số từ PS, tính toán một lần truyền xuôi và một lần truyền ngược, và cuối cùng đẩy các tham số đã cập nhật lên PS huấn luyện. Khác một chút so với các tác vụ học sâu phổ biến khác, chúng tôi chỉ huấn luyện tập dữ liệu của mình trong một lần lướt qua. 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, việc 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ộ nhớ, một nhân viên huấn luyện tiêu thụ 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 đối với phía người dùng ngay lập tức. Đ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 kích hoạt bởi thiết kế công cụ streaming của chúng tôi như minh họa trong Hình 2.2.1 Công cụ Streaming. 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 Bộ kết hợp đặc trưng trực tuyến (online feature Joiner). Bộ kết hợp trực tuyến nối các đặc trưng với nhãn từ các 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 một 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 đủ lượng, nhân viên huấn luyện sẽ truy xuất 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 đến 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 bộ kết hợp trực tuyến (Hình mà không có đảm bảo về 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 Bộ kết hợp trực tuyến (Online Joiner). 5) Độ trễ của hành động người dùng cũng có thể là một vấn đề. Ví dụ, người dùng có thể mất vài ngày trước khi họ quyết định mua một món hàng được giới thiệu cách đây vài ngày. Đây là một thách thức đối với bộ kết hợp vì nếu tất cả các đặc trưng được giữ trong bộ nhớ cache, 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 nhật ký hành động của người dùng đến, nó đầu tiên tra cứu bộ nhớ cache trong bộ nhớ, sau đó tra cứu bộ lưu trữ khóa-giá trị trong trường hợp thiếu bộ nhớ cache. Một vấn đề khác phát sinh trong ứ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 đây 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ị các ví dụ tiêu cực lấn át, một chiến lược phổ biến là lấy mẫu tiêu cực. Điều này chắc chắn sẽ thay đổi phân phối cơ bản của mô hình được 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. Như một biện pháp 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 tiếp 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 hưởng lợi từ các tham số mới được huấn luyện 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à do đó việc thay thế tất cả các tham số mất một thời gian. Sẽ không thể chấp nhận được việc dừng PS trực tuyến phục vụ mô hình trong quá trình thay thế và các cập nhật phải được thực hiện ngay lập tức; 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ẽ gây áp lực lớn lên cả băng thông mạng và bộ nhớ trên PS, vì nó đòi hỏi 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 ngay lập tức 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) Các tham số thưa thớt chiếm ưu thế về kích thước của các mô hình gợi ý; (2) Trong một khoảng thời gian ngắn, chỉ một tập hợp con các ID được huấn luyện và các nhúng của chúng được cập nhật; (3) Các biến dày đặc di chuyển chậm hơn nhiều so với các 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 gợi ý, trong khi chỉ một vài nhúng thưa thớt nhận được 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 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 đã được 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 vài 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ẹ nhàng cho việc truyền mạng và sẽ không gây ra đỉnh bộ nhớ đột ngột 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 lỗi thời so với phần thưa thớt. Tuy nhiên, sự không nhất quán như vậy có thể chấp nhận được 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 thấy. 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 một cách định kỳ và phục hồi từ ảnh chụp nhanh gần đây nhất khi phát hiện lỗi PS. 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 bị mất í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 miễn phí. Nó gây ra các bản sao bộ nhớ và I/O đĩa lớn. 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ả các PS huấn luyện hàng ngày. Mặc dù một PS sẽ mất một ngày cập nhật trong trường hợp xảy ra lỗi, chúng tôi phát hiện ra rằng sự suy giảm hiệu suất 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 đã tiến hành một số thí nghiệm ở quy mô sản xuất và thử nghiệm 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 nhằm mục đích 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ừ Bảng băm không xung đột? (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 các 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à những phát hiện của chúng tôi. 3.1 Thiết lập thử nghiệm Như được mô tả trong Phần các bảng nhúng trong Monolith được triển khai dưới dạng Bảng băm không xung đột. Để chứng minh sự cần thiết của việc tránh xung đột trong bảng nhúng và định lượng lợi ích từ việc triển khai không xung đột 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 xếp hạng phim, chứa 25 triệu xếp hạng liên quan đến khoảng 162.000 người dùng và 62.000 bộ phim. MovieLens 11 • . Nhãn gốc là xếp hạng 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 đo thành nhãn nhị phân bằng cách coi điểm ≥ 3,5 là các mẫu tích cực và phần còn lại là các 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 vấn đề gợi ý. Nó bao gồm một thành phần FM và một thành phần dày đặc (Hình 6). Các dự đoán được đánh giá bằng AUC vì đây là thước đo chính cho các mô hình thực tế. • Xung đột 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 bảng nhúng không xung đột, chúng tôi đã thực hiện một nhóm thử nghiệm khác nơi các ID được tiền xử lý bằng băm MD5 và sau đó ánh xạ vào một không gian ID nhỏ hơn. Kết quả là, một số ID sẽ chia sẻ nhúng của chúng với những ID khác. Bảng 1 cho thấy 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 gợi ý 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 gợi ý 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à 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 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 hủy để 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 nhúng duy nhất cho mỗi ID bằng cách kết hợp vector: trong đó 𝐸𝑟 , 𝐸𝑞 là các nhúng tương ứng với 𝐼𝐷𝑟 , 𝐼𝐷𝑞. Điều này hiệu quả làm 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 phục vụ 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 chúng tôi với bộ tham số mới nhất với khoảng thời gian vài 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 vài 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 sang 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 tiêu chuẩn quy mô lớn để đánh giá hiệu suất mô hình CTR. Nó chứa 7 ngày dữ liệu được sắp xếp theo 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 cho huấn luyện theo lô và 2 ngày cho huấn luyện trực tuyến. Chúng tôi chia thêm 2 ngày dữ liệu thành 𝑁 phân đoạn theo 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 vớ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, tương ứng với khoảng thời gian cập