Bên trong Monolith của ByteDance: Công cụ cung cấp các nguồn cấp dữ liệu 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à theo thời gian thực là rất quan trọng đối với nhiều doanh nghiệp dựa vào phản hồi của khách hàng nhạy cảm về thời gian, 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, nhưng các framework đa dụng này không đáp ứng được nhu cầu kinh doanh trong các kịch bản đề 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 gây tổn hại đến chất lượng mô hình; mặt khác, các framework nà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ôi thúc 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 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 đề 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 xung đột 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 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. 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. Trong việc 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ẽ mô tả 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 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, các nỗ lực tận dụng 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. 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 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 đào tạo dữ liệu cơ bản là không ổn định, còn gọi là Sự trôi dạt khái niệm . 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 đề xuất. 1.1 Sự thưa thớt và tính độ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. Thực hành phổ biến là ánh xạ chúng vào không gian nhúng có số 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ừ 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 gọn 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 lên theo thời gian khi có nhiều người dùng và mục hơn, 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 áp dụng băm va chạm thấp [ , ] như một cách để giảm dấu vết 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 va chạm không gây hại cho chất lượng mô hình. Thật không may, điều này hiếm khi đúng đối với một 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 hữu cơ 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 đó, đó là nhu cầu tự nhiên đối với các hệ thống đề xuất quy mô sản xuất để có khả năng nắm bắt càng nhiều đặc trưng càng tốt 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 dữ liệu người dùng cơ bản là không ổn định, một hiện tượng thường được gọi là Sự trôi dạt khái niệm . 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 tác động của Sự 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 người dùng mới nhất 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. Với những khác biệt này và dựa trên 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 điểm khó khăn 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 sức biểu cảm đầ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) Vòng lặp 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 các 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ó 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 tiên tiến 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 Mục 2. Các thí nghiệm và kết quả sẽ được trình bày trong Mục 3, cùng với các kết luận đã được kiểm tra 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. Mục 4 tóm tắt các công việc liên quan và so sánh chúng với Monolith. Mục 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 thiết lập 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; các 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 đồ thị, và các 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. Các tham số dày đặc là trọng số/biến trong 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 Đồ thị 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 tập hợp 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 bổ sung cho hạn chế của Tensor-Flow phát sinh từ việc tách biệt huấn luyện và suy luận, huấn luyện trực tuyến có thể 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 sự đảm bảo độ mạnh mẽ 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. Việc mô phỏng một bảng nhúng có kích thước động bằng Biến TensorFlow có sẵn sẽ dẫn đến va chạm ID, điều này càng làm trầm trọng thêm 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 bảng HashTable khóa-giá trị mới cho các tham số thưa thớt của mình. HashTable của chúng tôi sử dụng Cuckoo Hashmap [ ] bên trong, hỗ trợ chèn khóa mới mà không xung đột 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 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 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 chèn gặp phải một chu kỳ. Giảm dấu vết bộ nhớ cũng là một yếu tố quan trọng trong thiết kế của chúng tôi. Một cách tiếp cận đơn giản là 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 dạng đ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 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 lượng 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 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 người dùng không còn hoạt động hoặc một video ngắn đã lỗi thời. Việc 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 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ố heuristics lọc ID đặc trưng cho việc triển khai HashTable hiệu quả hơn về bộ nhớ: (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: Thứ nhất, 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 được cho mỗi mô hình; Ngoài ra, chúng tôi sử dụng một bộ lọc xác suất giúp giảm thêm việc sử dụng bộ nhớ; ![#Figure 4: Công cụ Truyền phát. Vòng lặp phản hồi thông tin từ [Người dùng → Máy chủ Mô hình → Worker 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 dẫn 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 thời gian 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 cách triển khai của chúng tôi, HashTable được triển khai dưới dạng 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 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, 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 worker 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, tính toán một lượt chuyển tiếp và một lượt ngược, và cuối cùng đẩy các tham số đã cập nhật đế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 bộ 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ột 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ộ lưu trữ, một worker 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 đối với 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 thích ứng một cách tương tác theo 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ông cụ truyền phát của chúng tôi như được minh họa bởi Hình 2.2.1 Công cụ Truyền phát. 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 nhật ký 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 truyền phát Flink [ ] cho bộ kết hợp đặc trưng trực tuyến. 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, worker 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ẽ đầu tiên đổ dữ liệu vào HDFS [ ]; Sau khi dữ liệu trong HDFS tích lũy đủ lượng, worker 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 đế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 người dùng và các đặc trưng được truyền vào bộ 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 Bộ kết hợp trực tuyến. 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 cho họ vài ngày trước. Đâ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ẽ không vừa với bộ nhớ. Trong hệ thống của chúng tôi, 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 quá 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ó sẽ tìm kiếm bộ nhớ cache trong bộ nhớ, sau đó tìm kiếm bộ lưu trữ khóa-giá trị trong trường hợp bộ nhớ cache bị thiếu. 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 của cái trước có thể lớn hơn nhiều lần so với cái sau. Để ngă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 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 có thể 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. Sẽ không thể chấp nhận được nếu dừng PS trực tuyến phục vụ mô hình trong quá trình thay thế, 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ẽ 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ô cho kích thước của 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) Các 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) Trong một khoảng 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) Các biến dày đặc di chuyển chậm hơn nhiều so với các bản nhúng thưa thớt. Điều này là do trong các trình 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 khuếch đạ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 bản 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 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ó bản 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à 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ể đượ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ó gặp 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 phát hiện lỗi PS. 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ị suy giảm ít hơn do mất lịch sử gần đây khi 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. Là 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 mỗi ngày. Mặc dù PS sẽ mất một ngày cập nhật trong trường hợp gặp lỗi, chúng tôi nhận thấy 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 tác động 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 mà 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 mình 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ư đã mô tả trong Mục 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 va chạm 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 bộ dữ liệu Movielens và trên bộ 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) Bộ dữ liệu ml-25m [ ]. Đây là một bộ 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 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 số ≥ 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 đề đề 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à thước đo chính cho các mô hình thực tế. • Va chạm nhúng. Bộ dữ liệu này chứa khoảng 160 nghìn ID người dùng và 60 nghìn 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 trong đó các ID được tiền xử lý bằng băm MD5 và sau đó ánh xạ vào 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ị các thống kê chi tiết về ID người dùng và phim trước và sau khi băm. (2) . Bộ 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 cách 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 đườ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 tích để kiểm soát 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 vector: trong đó 𝐸𝑟 , 𝐸𝑞 là các bản 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 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 bộ 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à độ mạnh mẽ 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 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 Bộ dữ liệu chúng tôi sử dụng là bộ dữ liệu Criteo Display Ads Challenge3, một bộ dữ liệu quy mô lớn tiêu chuẩn để đánh giá hiệu suất của các 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 bộ dữ liệu. Chúng tôi lấy 7 ngày dữ liệu từ bộ 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 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 với PS phục vụ trực tuyến với khoảng thời gian được xác định bởi số lượng phần dữ liệu. Chúng tôi đã thử nghiệm với 𝑁 = 10, 50,