Tên tôi là Pavel Parkhomenko, tôi là nhà phát triển ML. Trong bài viết này, tôi muốn nói về cấu trúc của dịch vụ Yandex.Zen và chia sẻ những cải tiến kỹ thuật, việc triển khai cải tiến này đã giúp nâng cao chất lượng của các đề xuất. Từ bài đăng này, bạn sẽ học cách tìm những tài liệu phù hợp nhất cho người dùng trong số hàng triệu tài liệu chỉ trong vài mili giây; cách thực hiện phân tách liên tục một ma trận lớn (bao gồm hàng triệu cột và hàng chục triệu hàng) để các tài liệu mới nhận được vectơ của chúng trong hàng chục phút; cách sử dụng lại phân tách ma trận bài viết của người dùng để có được biểu diễn vectơ tốt cho video.
Cơ sở dữ liệu đề xuất của chúng tôi chứa hàng triệu tài liệu ở nhiều định dạng khác nhau: các bài viết văn bản được tạo trên nền tảng của chúng tôi và lấy từ các trang web, video, bài tường thuật và bài đăng ngắn bên ngoài. Sự phát triển của một dịch vụ như vậy gắn liền với một số lượng lớn các thách thức kỹ thuật. Dưới đây là một số trong số họ:
- Phân chia các tác vụ tính toán: thực hiện tất cả các tác vụ nặng ngoại tuyến và trong thời gian thực chỉ thực hiện ứng dụng nhanh các mô hình để chịu trách nhiệm trong 100-200 ms.
- Nhanh chóng tính đến hành động của người dùng. Để làm được điều này, điều cần thiết là tất cả các sự kiện phải được gửi ngay lập tức đến người giới thiệu và ảnh hưởng đến kết quả của mô hình.
- Tạo nguồn cấp dữ liệu để người dùng mới nhanh chóng thích ứng với hành vi của họ. Những người mới tham gia hệ thống sẽ cảm thấy rằng phản hồi của họ ảnh hưởng đến các đề xuất.
- Nhanh chóng hiểu ai sẽ giới thiệu một bài viết mới cho.
- Đáp ứng nhanh chóng với sự xuất hiện liên tục của nội dung mới. Hàng chục nghìn bài báo được xuất bản mỗi ngày và nhiều bài trong số đó có thời lượng tồn tại hạn chế (chẳng hạn như tin tức). Đây là điểm khác biệt giữa họ với phim ảnh, âm nhạc và những nội dung dài hạn và tốn kém khác để tạo ra.
- Chuyển kiến thức từ lĩnh vực này sang lĩnh vực khác. Nếu một hệ thống đề xuất có các mô hình được đào tạo cho các bài viết văn bản và chúng tôi thêm video vào đó, thì chúng tôi có thể sử dụng lại các mô hình hiện có để loại nội dung mới được xếp hạng tốt hơn.
Tôi sẽ cho bạn biết chúng tôi đã giải quyết những vấn đề này như thế nào.
Lựa chọn ứng viên
Làm cách nào để giảm số lượng tài liệu đang được xem xét hàng nghìn lần trong vài mili giây mà hầu như không làm giảm chất lượng xếp hạng?
Giả sử chúng ta đã đào tạo nhiều mô hình ML, tạo các tính năng dựa trên chúng và đào tạo một mô hình khác để xếp hạng tài liệu cho người dùng. Mọi thứ sẽ ổn, nhưng bạn không thể chỉ lấy và tính toán tất cả các dấu hiệu cho tất cả tài liệu trong thời gian thực, nếu có hàng triệu tài liệu này và các đề xuất cần được xây dựng trong 100-200 mili giây. Nhiệm vụ là chọn một tập hợp con nhất định từ hàng triệu tập hợp con này sẽ được xếp hạng cho người dùng. Giai đoạn này thường được gọi là lựa chọn ứng viên. Có một số yêu cầu cho nó. Thứ nhất, việc lựa chọn phải diễn ra rất nhanh chóng, sao cho có nhiều thời gian nhất có thể cho việc xếp hạng. Thứ hai, sau khi giảm đáng kể số lượng tài liệu để xếp hạng, chúng tôi phải lưu giữ các tài liệu liên quan đến người dùng một cách đầy đủ nhất có thể.
Nguyên tắc lựa chọn ứng viên của chúng tôi đã phát triển và hiện tại chúng tôi đã đạt được một kế hoạch gồm nhiều giai đoạn:
Đầu tiên, tất cả các tài liệu được chia thành các nhóm và những tài liệu phổ biến nhất được lấy từ mỗi nhóm. Các nhóm có thể là các trang web, chủ đề, cụm. Đối với mỗi người dùng, dựa trên lịch sử của anh ta, các nhóm gần gũi nhất với anh ta sẽ được chọn và những tài liệu tốt nhất sẽ được lấy từ họ. Chúng tôi cũng sử dụng chỉ mục kNN để chọn các tài liệu gần gũi nhất với người dùng theo thời gian thực. Có một số phương pháp để xây dựng chỉ mục kNN; phương pháp của chúng tôi hoạt động tốt nhất (Biểu đồ Thế giới nhỏ có thể điều hướng theo cấp bậc). Đây là mô hình phân cấp cho phép bạn tìm N vectơ gần nhất cho người dùng từ cơ sở dữ liệu hàng triệu trong vài mili giây. Trước tiên, chúng tôi lập chỉ mục ngoại tuyến toàn bộ cơ sở dữ liệu tài liệu của mình. Vì việc tìm kiếm trong chỉ mục hoạt động khá nhanh nên nếu có một số nội dung nhúng mạnh, bạn có thể tạo một số chỉ mục (một chỉ mục cho mỗi nội dung nhúng) và truy cập từng chỉ mục đó trong thời gian thực.
Chúng tôi vẫn còn hàng chục nghìn tài liệu cho mỗi người dùng. Con số này vẫn còn rất nhiều để tính hết các tính năng nên ở giai đoạn này chúng tôi sử dụng xếp hạng nhẹ - một mô hình xếp hạng nặng nhẹ với ít tính năng hơn. Nhiệm vụ là dự đoán những tài liệu nào mà một mô hình nặng sẽ có ở trên cùng. Các tài liệu có chỉ số dự đoán cao nhất sẽ được sử dụng trong mô hình hạng nặng, tức là ở giai đoạn xếp hạng cuối cùng. Cách tiếp cận này cho phép bạn giảm cơ sở dữ liệu tài liệu được xem xét cho người dùng từ hàng triệu xuống hàng nghìn trong hàng chục mili giây.
Bước ALS trong thời gian chạy
Làm cách nào để tính đến phản hồi của người dùng ngay sau khi nhấp chuột?
Một yếu tố quan trọng trong khuyến nghị là thời gian phản hồi phản hồi của người dùng. Điều này đặc biệt quan trọng đối với người dùng mới: khi một người mới bắt đầu sử dụng hệ thống đề xuất, anh ta sẽ nhận được nguồn cấp tài liệu không được cá nhân hóa về các chủ đề khác nhau. Ngay khi anh ấy thực hiện cú nhấp chuột đầu tiên, bạn cần tính đến ngay điều này và điều chỉnh cho phù hợp với sở thích của anh ấy. Nếu bạn tính toán tất cả các yếu tố ngoại tuyến, phản hồi nhanh của hệ thống sẽ không thể thực hiện được do độ trễ. Vì vậy cần phải xử lý hành động của người dùng theo thời gian thực. Với những mục đích này, chúng tôi sử dụng bước ALS trong thời gian chạy để xây dựng biểu diễn vectơ của người dùng.
Giả sử chúng ta có biểu diễn vectơ cho tất cả tài liệu. Ví dụ: chúng tôi có thể tạo nội dung nhúng ngoại tuyến dựa trên văn bản của bài viết bằng ELMo, BERT hoặc các mô hình học máy khác. Làm cách nào chúng tôi có thể có được biểu diễn vectơ của người dùng trong cùng một không gian dựa trên tương tác của họ trong hệ thống?
Nguyên tắc chung về hình thành và phân rã ma trận tài liệu người dùngGiả sử chúng ta có m người dùng và n tài liệu. Đối với một số người dùng, mối quan hệ của họ với một số tài liệu nhất định đã được biết. Sau đó, thông tin này có thể được biểu diễn dưới dạng ma trận mxn: các hàng tương ứng với người dùng và các cột tương ứng với các tài liệu. Vì người đó chưa xem hầu hết các tài liệu nên hầu hết các ô ma trận sẽ vẫn trống, trong khi những ô khác sẽ được lấp đầy. Đối với mỗi sự kiện (thích, không thích, nhấp chuột), một số giá trị được cung cấp trong ma trận - nhưng hãy xem xét một mô hình đơn giản trong đó lượt thích tương ứng với 1 và lượt không thích tương ứng với -1.
Hãy phân tách ma trận thành hai: P (mxd) và Q (dxn), trong đó d là thứ nguyên của biểu diễn vectơ (thường là một số nhỏ). Khi đó, mỗi đối tượng sẽ tương ứng với một vectơ d chiều (đối với người dùng - một hàng trong ma trận P, đối với tài liệu - một cột trong ma trận Q). Các vectơ này sẽ là phần nhúng của các đối tượng tương ứng. Để dự đoán liệu người dùng có thích một tài liệu hay không, bạn chỉ cần nhân các phần nhúng của họ.
Một trong những cách khả thi để phân tách ma trận là ALS (Bình phương nhỏ nhất xen kẽ). Chúng ta sẽ tối ưu hóa hàm mất mát sau:
Ở đây rui là sự tương tác của người dùng u với tài liệu i, qi là vectơ của tài liệu i, pu là vectơ của người dùng u.
Sau đó, vectơ người dùng tối ưu theo quan điểm sai số bình phương trung bình (đối với vectơ tài liệu cố định) được tìm thấy bằng phương pháp phân tích bằng cách giải hồi quy tuyến tính tương ứng.
Đây được gọi là "bước ALS". Và bản thân thuật toán ALS là chúng tôi lần lượt sửa một trong các ma trận (người dùng và bài viết) và cập nhật ma trận còn lại, tìm ra giải pháp tối ưu.
May mắn thay, việc tìm kiếm biểu diễn vectơ của người dùng là một thao tác khá nhanh có thể được thực hiện trong thời gian chạy bằng cách sử dụng các lệnh vectơ. Thủ thuật này cho phép bạn ngay lập tức xem xét phản hồi của người dùng khi xếp hạng. Việc nhúng tương tự có thể được sử dụng trong chỉ mục kNN để cải thiện việc lựa chọn ứng viên.
Lọc cộng tác phân tán
Làm cách nào để thực hiện phân tích nhân tử ma trận phân tán gia tăng và nhanh chóng tìm thấy biểu diễn vectơ của các bài viết mới?
Nội dung không phải là nguồn tín hiệu đề xuất duy nhất. Một nguồn quan trọng khác là thông tin hợp tác. Các tính năng xếp hạng tốt theo truyền thống có thể thu được từ việc phân rã ma trận tài liệu người dùng. Nhưng khi cố gắng thực hiện việc phân rã như vậy, chúng tôi đã gặp phải các vấn đề:
1. Chúng tôi có hàng triệu tài liệu và hàng chục triệu người dùng. Ma trận không hoàn toàn phù hợp trên một máy và việc phân tách sẽ mất một thời gian rất dài.
2. Hầu hết nội dung trong hệ thống có thời gian tồn tại ngắn: tài liệu chỉ có giá trị trong vài giờ. Vì vậy, cần phải xây dựng biểu diễn vectơ của chúng càng nhanh càng tốt.
3. Nếu bạn xây dựng một bản phân tách ngay sau khi tài liệu được xuất bản, thì sẽ không có đủ số lượng người dùng để đánh giá nó. Vì vậy, sự biểu diễn vector của nó rất có thể sẽ không tốt lắm.
4. Nếu người dùng thích hoặc không thích, chúng tôi sẽ không thể tính đến điều này ngay lập tức khi phân tích.
Để giải quyết những vấn đề này, chúng tôi đã triển khai phân tách phân tán ma trận tài liệu người dùng với các bản cập nhật gia tăng thường xuyên. Chính xác thì nó hoạt động như thế nào?
Giả sử chúng ta có một cụm gồm N máy (N lên tới hàng trăm) và chúng ta muốn thực hiện phân tách phân tán một ma trận trên chúng không vừa với một máy. Câu hỏi đặt ra là làm thế nào để thực hiện việc phân tách này sao cho một mặt có đủ dữ liệu trên mỗi máy và mặt khác để các phép tính được độc lập?
Chúng tôi sẽ sử dụng thuật toán phân rã ALS được mô tả ở trên. Hãy xem cách thực hiện một bước ALS theo cách phân tán - các bước còn lại sẽ tương tự. Giả sử chúng ta có một ma trận tài liệu cố định và chúng ta muốn xây dựng một ma trận người dùng. Để làm điều này, chúng ta sẽ chia nó thành N phần theo dòng, mỗi phần sẽ chứa số dòng xấp xỉ bằng nhau. Chúng tôi sẽ gửi đến từng máy các ô không trống của các hàng tương ứng, cũng như ma trận nhúng tài liệu (toàn bộ). Vì kích thước của nó không lớn lắm và ma trận tài liệu người dùng thường rất thưa thớt nên dữ liệu này sẽ vừa với một máy thông thường.
Thủ thuật này có thể được lặp lại qua nhiều kỷ nguyên cho đến khi mô hình hội tụ, xen kẽ từng ma trận cố định. Nhưng ngay cả khi đó, việc phân tách ma trận có thể mất vài giờ. Và điều này không giải quyết được vấn đề là bạn cần nhanh chóng nhận được các phần nhúng của tài liệu mới và cập nhật phần nhúng của những tài liệu có ít thông tin khi xây dựng mô hình.
Việc giới thiệu các bản cập nhật mô hình gia tăng nhanh chóng đã giúp chúng tôi. Giả sử chúng ta có một mô hình hiện đang được đào tạo. Kể từ khi cô ấy đào tạo, đã có những bài viết mới mà người dùng của chúng tôi tương tác cũng như những bài viết có ít tương tác trong quá trình đào tạo. Để nhanh chóng có được phần nhúng của các bài viết như vậy, chúng tôi sử dụng phần nhúng của người dùng thu được trong quá trình đào tạo mô hình lớn đầu tiên và thực hiện một bước ALS để tính toán ma trận tài liệu cho ma trận người dùng cố định. Điều này cho phép bạn nhận được các phần nhúng khá nhanh - trong vòng vài phút sau khi tài liệu được xuất bản - và thường cập nhật các phần nhúng của các tài liệu gần đây.
Để đưa ra các đề xuất ngay lập tức có tính đến hành động của con người, trong thời gian chạy, chúng tôi không sử dụng nội dung nhúng của người dùng thu được ngoại tuyến. Thay vào đó, chúng tôi thực hiện bước ALS và lấy vectơ người dùng thực tế.
Chuyển sang vùng miền khác
Làm cách nào để sử dụng phản hồi của người dùng về các bài viết văn bản để xây dựng hình ảnh vector của video?
Ban đầu, chúng tôi chỉ đề xuất các bài viết văn bản nên nhiều thuật toán của chúng tôi được điều chỉnh cho phù hợp với loại nội dung này. Nhưng khi thêm các loại nội dung khác, chúng tôi phải đối mặt với nhu cầu điều chỉnh mô hình. Chúng tôi đã giải quyết vấn đề này bằng cách sử dụng ví dụ video như thế nào? Một lựa chọn là đào tạo lại tất cả các mô hình từ đầu. Nhưng việc này mất nhiều thời gian và một số thuật toán yêu cầu về kích thước của mẫu đào tạo, chưa có đủ số lượng cần thiết cho một loại nội dung mới trong những giây phút đầu tiên xuất hiện trên dịch vụ.
Chúng tôi đã làm theo cách khác và sử dụng lại các mẫu văn bản cho video. Thủ thuật ALS tương tự đã giúp chúng tôi tạo ra các biểu diễn dạng vector cho video. Chúng tôi lấy biểu đồ vectơ của người dùng dựa trên các bài viết văn bản và thực hiện bước ALS bằng cách sử dụng thông tin xem video. Vì vậy, chúng tôi dễ dàng có được biểu diễn vector của video. Và trong thời gian chạy, chúng tôi chỉ tính toán khoảng cách giữa vectơ người dùng thu được từ các bài viết văn bản và vectơ video.
Kết luận
Việc phát triển cốt lõi của hệ thống khuyến nghị theo thời gian thực có nhiều thách thức. Bạn cần xử lý nhanh dữ liệu và áp dụng các phương pháp ML để sử dụng hiệu quả dữ liệu này; xây dựng các hệ thống phân tán phức tạp có khả năng xử lý tín hiệu người dùng và đơn vị nội dung mới trong thời gian tối thiểu; và nhiều nhiệm vụ khác.
Trong hệ thống hiện tại, thiết kế mà tôi đã mô tả, chất lượng đề xuất cho người dùng tăng lên cùng với hoạt động của họ và thời gian sử dụng dịch vụ. Nhưng tất nhiên, khó khăn chính nằm ở đây: hệ thống khó có thể hiểu ngay được sở thích của một người ít tương tác với nội dung. Cải thiện đề xuất cho người dùng mới là mục tiêu chính của chúng tôi. Chúng tôi sẽ tiếp tục tối ưu hóa các thuật toán để nội dung phù hợp với một người được đưa vào nguồn cấp dữ liệu của người đó nhanh hơn và nội dung không liên quan sẽ không được hiển thị.
Nguồn: www.habr.com