Làm thế nào một nên đối phó với dữ liệu ngầm trong khuyến nghị


9

Một hệ thống khuyến nghị giữ một bản ghi về những khuyến nghị đã được thực hiện cho một người dùng cụ thể và liệu người dùng đó có chấp nhận đề xuất đó không. Nó giống như

user_id item_id result
1       4       1
1       7       -1
5       19      1
5       80      1

trong đó 1 có nghĩa là người dùng chấp nhận đề xuất trong khi -1 có nghĩa là người dùng không phản hồi đề xuất.

Câu hỏi: Nếu tôi sẽ đưa ra đề xuất cho một nhóm người dùng dựa trên loại nhật ký được mô tả ở trên và tôi muốn tối đa hóa điểm số MAP @ 3, tôi nên xử lý dữ liệu ẩn (1 hoặc -1) như thế nào?

Ý tưởng của tôi là coi 1 và -1 là xếp hạng và dự đoán xếp hạng bằng thuật toán loại máy nhân tố. Nhưng điều này có vẻ không đúng, do tính không đối xứng của dữ liệu ngầm (-1 không có nghĩa là người dùng không thích đề xuất).

Chỉnh sửa 1 Chúng ta hãy suy nghĩ về nó trong bối cảnh của cách tiếp cận nhân tố ma trận. Nếu chúng ta coi -1 và 1 là xếp hạng, sẽ có một số vấn đề. Ví dụ: người dùng 1 thích phim A đạt điểm cao ở một yếu tố (ví dụ: có nhạc nền vinh quang) trong không gian yếu tố tiềm ẩn. Hệ thống khuyến nghị phim B cũng đạt điểm cao trong "nhạc nền vinh quang", nhưng vì một số lý do, người dùng 1 quá bận rộn để xem xét đề xuất và chúng tôi có phim xếp hạng -1 B. Nếu chúng tôi chỉ coi 1 hoặc -1 bằng nhau , sau đó hệ thống có thể không khuyến khích giới thiệu phim có BGM ​​vinh quang cho người dùng 1 trong khi người dùng 1 vẫn thích phim có BGM ​​vinh quang. Tôi nghĩ rằng tình huống này là để tránh.


Không có vấn đề gì mà -1 không có nghĩa là không thích. Nó chỉ đơn giản là một cách để phân biệt rằng ai đó đã nhìn thấy vật phẩm. Theo nghĩa đó, nó mang nhiều thông tin hơn một giá trị còn thiếu. Nó thực sự có thể làm tăng độ chính xác của khuyến nghị của bạn. Tùy thuộc vào số liệu khoảng cách của bạn khi đề xuất, bạn có thể xem xét thay đổi nó từ -1 thành giá trị số liệu nhỏ để nó không ảnh hưởng đến khoảng cách nhiều.
cwharland

1
Bài viết kinh điển cho phản hồi ngầm là Hu, Koren và Volinsky . Có rất nhiều khuyến nghị tốt trong đó, bao gồm ước tính sự tự tin của bạn trong đó -1 biểu thị sự không thích hoặc chỉ đơn thuần là "không thấy".
Trey

Câu trả lời:


5

Hệ thống của bạn không chỉ được đào tạo về các mặt hàng được khuyến nghị phải không? Nếu vậy bạn có một vòng phản hồi lớn ở đây. Bạn muốn học hỏi từ tất cả các lần nhấp / lượt xem, tôi hy vọng.

Bạn đề nghị rằng không nhìn vào một mục là một tín hiệu tiêu cực. Tôi thực sự khuyên bạn không nên đối xử với nó theo cách đó. Không tương tác với một cái gì đó hầu như luôn luôn được đối xử tốt nhất như không có thông tin. Nếu bạn có tín hiệu rõ ràng biểu thị sự không thích, như bỏ phiếu xuống (hoặc, có thể đã xem 10 giây video và dừng lại), có thể đó là hợp lệ.

Tôi sẽ không hiểu đầu vào này là dữ liệu giống như xếp hạng. (Mặc dù trong trường hợp của bạn, bạn có thể thoát khỏi nó.) Thay vào đó hãy nghĩ về chúng như trọng lượng, đó chính xác là cách xử lý trong bài báo Hu Koren Volinsky trên ALS mà @Trey đề cập trong một bình luận. Điều này cho phép bạn ghi lại sức mạnh tương đối của các tương tác tích cực / tiêu cực.

Cuối cùng tôi sẽ lưu ý rằng bài báo này, trong khi rất có thể là những gì bạn đang tìm kiếm, không cung cấp cho trọng lượng tiêu cực. Nó là đơn giản để mở rộng theo cách này. Nếu bạn đi xa đến đó tôi có thể chỉ cho bạn phần mở rộng dễ dàng, đã tồn tại trong hai triển khai mà tôi biết, trong SparkOryx .


2
Tôi nghĩ rằng việc đưa ra các giá trị tiêu cực nhỏ cho các mục đã được nhìn thấy nhiều lần nhưng không bao giờ được chọn là hợp lý. OP không cho biết họ có quyền truy cập vào dữ liệu đủ điều kiện cho những tranh chấp tiêu cực này nhưng tôi sẽ không loại trừ hoàn toàn chiến thuật đó. Độ lớn tối ưu của giá trị âm có thể được xác định từ dữ liệu. Tôi đã có những lợi ích nhỏ từ việc này trong các kịch bản recsys. Trong mọi trường hợp ... bạn có đề xuất các cách khác biệt giữa mục được nhìn thấy một lần và không được chọn so với lần xem N lần và không bao giờ được chọn bên cạnh việc phủ định tiêu cực không?
cwharland
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.