Hình 44: Cập nhật đối tượng nested sử dụng update script viết bằng ngôn ngữ painless Update By Query: có cú pháp tương tự với Update API, nhưng cho phép truyền vào
truy vấn như lúc tìm kiếm để cập nhật các thực thể phù hợp với kết quả tìm kiếm. Ở hình dưới, hệ thống sử dụng API này để cập nhật tồn bộ thực thể nhóm có chứa người dùng X và xóa người đó khỏi danh sách thành viên trong trường người dùng này bị xóa khỏi cơ sở dữ liệu chính.
Hình 45: Cập nhật dữ liệu bằng Update-by-query API
6.4.3 Truy vấn kết quả
Mỗi một câu truy vấn của các index trong hệ thống thường bao gồm các phần sau:
match query: truy vấn kết quả dựa vào từ khóa tìm kiếm với các trường dữ liệu dạng
text. Đối với trường hợp cho phép tìm kiếm nhiều trường khác nhau, hệ thống sử dụng
multi-match query thay thế.
filter query: lọc kết quả ở các trường nested và không nested dựa trên các kiểu dữ liệu
còn lại.
must_not: lọc kết quả không thỏa mãn điều kiện.
pagination: thông qua from và size (phân trang truyền thống) và search_after (phân
6.5 Hệ thống giới thiệu
Như đã trình bày ở phần Cơ sở lý thuyết, nhóm làm đề tài sử dụng cách tiếp cận là sử dụng giải thuật đề xuất được cung cấp bởi phần mềm mã nguồn mở ActionML có tên là The Universal Recommender để hiện thực tính năng gợi ý. The Universal Recommender có nền tảng là giải thuật Correlated Cross-Occurrence, cho phép lời giới thiệu được học từ nhiều loại sự kiện và hành vi khác nhau của người dùng. Mục này sẽ trình bày kỹ hơn quá trình hiện thực, bao gồm cơng đoạn thử nghiệm và cơng đoạn tích hợp vào hệ thống.
6.5.1 Thử nghiệm
Nhóm làm đề tài sử dụng tập dữ liệu RetailRocket chứa dữ liệu hành vi của người dùng trong một website Ecommerce để tiến hành thử nghiệm và đánh giá chất lượng của ActionML so với một vài giải thuật và mơ hình Giới thiệu khác. Cụ thể, chúng là Alternating Least Square – là một giải thuật trong họ Thừa số hóa ma trận – và Spotlight – một thư viện sử dụng các mơ hình Deep Learning để hiện thực Hệ thống giới thiệu.
Đối với ALS, có rất nhiều thư viện hiện thực giải thuật này nhưng nhóm làm đề tài chọn Implicit vì nó cải biến giải thuật để phù hợp với các tập dữ liệu chứa các phản hồi tiềm ẩn. RetailRocket là một tập dữ liệu như vậy vì thơng tin được lưu trữ khơng phải là một con số đánh giá thể hiện mức độ yêu thích của người dùng mà là các sự kiện thuộc ba nhóm: mua (transaction), xem thơng tin (view) và đưa vào giỏ hàng (add-to-cart). Đối với SpotLight, nhóm làm đề tài lựa chọn mô hình Sequence làm đối tượng kiểm thử. Đây là mô hình
timeseries được xây dựng dựa trên mạng Long Short-term Memory và 1D CNN. Việc lựa
chọn giải thuật và mơ hình thỏa mãn hai yêu cầu sau:
Phải thuộc lớp giải thuật Collaborative Filtering. Điều này là bởi các giải thuật Content- based Filtering khá phụ thuộc vào tiến trình trích xuất đặc trưng, địi hỏi hiểu biết chuyên sâu về lĩnh vực cần đưa ra giới thiệu.
Có khả năng làm việc dữ liệu là phản hồi tiềm ẩn (implicit feedback).
Bước đầu tiên cần tiến hành đó là tiền xử lý và chuẩn bị dữ liệu. Dữ liệu RetailRocket khá là lớn và được thu thập từ rất nhiều các thể loại sản phẩm khác nhau trong hệ thống ecommerce. Nhóm làm đề tài quyết định chỉ sử dụng dữ liệu thuộc duy nhất một phân lớp là Electronics để đảm bảo không gặp phải hiện tượng out of memory trong quá trình thử nghiệm. Có ba loại sự kiện trong tập dữ liệu là “mua”, “xem hàng” và “đưa vào giỏ hàng”. Trong đó, sự kiện “mua” được lựa chọn làm sự kiện chính vì nó là mục đích cuối cùng của việc Giới thiệu trong hệ thống ecommerce. Tuy vậy, sự kiện “mua” trong tập dataset này rất hiếm, chỉ chiếm 1%, và có rất nhiều người dùng khơng hề mua hoặc mua rất ít mặt hàng, khiến cho ma trận utility khá thưa. Để giải quyết vấn đề này, nhóm làm đề tài lựa chọn ra 10 000 người dùng có số lượng sự kiện mua hàng nhiều nhất và chỉ đánh giá trên những người đó. Nhóm làm đề tài cũng loại bỏ các sự kiện ngoài sự kiện “mua” ra khỏi tập dữ liệu và đánh giá kịch bản một loại sự kiện giữa ba mô hình vì ALS và SpotLight chỉ có khả năng làm việc với một loại phản hồi tiềm ẩn duy nhất.
Nhóm làm đề tài tiến hành chia tập dữ liệu này thành 2 tập là tập huấn luyện và tập kiểm thử. Chiến lược chia như sau: Với mỗi người dùng trong tập dữ liệu, sự kiện “mua” cuối cùng của người đó sẽ được tách ra khỏi tập dữ liệu ban đầu và đưa vào tập kiểm thử. Phần còn lại được dùng làm tập huấn luyện. Ta đánh giá các mơ hình bằng cách huấn luyện mơ hình với tập huấn luyện, rồi cho mơ hình đó dự đốn K sản phẩm giới thiệu đến người dùng (với tham số K được nhóm làm đề tài chọn là 5). Chất lượng của mơ hình được tính bằng thương số giữa các lời giới thiệu có ít nhất một sản phẩm trúng (hit) với sản phẩm trong sự kiện mua cuối cùng của từng người, chia cho tổng số người dùng trong tập dữ liệu (1000), thu được hit ratio của mơ hình đó. Chiến lược kiểm thử trên được gọi là leave one out.
Nhóm làm đề tài tiến hành kiểm thử cho từng mơ hình và thu được kết quả như sau:
Model Hit Ratio (%)
ALS (Implicit) 23.62
Sequence Model (SpotLight) 10.68
The Universal Recommender
(ActionML) 16.12
The Universal Recommender (sử
dụng cả 3 loại event) 18.51
Bảng 100: Kết quả đánh giá một vài mơ hình Giới thiệu trên tập dữ liệu RetailRocketKết quả ở hàng cuối rút ra từ mơ hình The Universal Recommender khi nhóm làm đề tài Kết quả ở hàng cuối rút ra từ mơ hình The Universal Recommender khi nhóm làm đề tài thử nghiệm với cả ba loại sự kiện để tiên đoán cho sự kiện mua cuối cùng của từng người dùng (vì mơ hình này cho phép nhận vào nhiều hơn 1 phản hồi tiềm ẩn). Có thể thấy, ALS cho kết quả khá tốt. Điều này cho thấy mơ hình này sẽ làm việc rất tốt đối với những người dùng có lịch sử “mua hàng” dồi dào. Ngược lại, mơ hình deep learning của SpotLight cho kết quả không được tốt như mong đợi. The Universal Recommender cho kết quả vừa phải, tuy nhiên
chất lượng của nó tăng lên rõ rệt khi sử dụng thêm các sự kiện phụ trợ cho sự kiện “mua” để đưa ra lời giới thiệu.
Từ kết quả trên, nhóm làm đề tài đi đến quyết định vẫn sử dụng The Universal Recommender làm mơ hình cho hệ thống giới thiệu của đề tài. Mặc dù ALS cho kết quả tốt, nhưng vì nó khơng có khả năng tiếp nhận các sự kiện phụ trợ khác khiến việc giới thiệu hoàn toàn phụ thuộc vào mức độ dồi dào của sự kiện chính. Vì lẽ đó, ALS thường dễ gặp phải tình trạng cold start: người dùng mới sử dụng hệ thống sẽ có rất ít sự kiện chính như “mua hàng”, trái lại các sự kiện như “xem thông tin”, “đưa vào giỏ hàng” xảy ra thường xuyên hơn. The Universal Recommender mang đến sự linh hoạt trong việc đưa ra lời giới thiệu đến nhiều thành phần khác nhau trong tập khách hàng, bao gồm cả những người sử dụng nhiều tương tác và ít tương tác. Ngồi ra, The Universal Recommender cịn có các tùy chọn dự phịng như giới thiệu các sản phẩm phổ biến.
6.5.2 Tích hợp vào hệ thống
Xây dựng một hệ thống giới thiệu sử dụng ActionML trải qua bốn giai đoạn chính như sau:
1. Hiện thực file config chứa các đặc tả cấu hình của engine tương ứng với thực thể mà chúng ta muốn gợi ý, trong đó quan trọng nhất là việc định nghĩa ra các sự kiện được hệ thống thu thập phục vụ mục đích đưa ra lời giới thiệu.
2. Hiện thực ở application các logic gọi API đến instance host máy chủ ActionML tương ứng với những sự kiện trên.
3. Hiện thực logic gọi API training của ActionML để huấn luyện mơ hình. 4. Hiện thực logic truy vấn các kết quả giới thiệu tùy vào yêu cầu nghiệp vụ.
Trong đó, bước 1 là quan trọng nhất vì nó ảnh hưởng trực tiếp đến chất lượng của mơ hình. Nhóm làm đề tài xác định bốn thực thể tương ứng với bốn engine dùng cho mục đích gợi ý là: course (khóa học), group (Nhóm), user (người dùng) và post (bài viết trong nhóm). Với mỗi thực thể, nhóm làm đề tài định nghĩa ra hệ thống các sự kiện khác nhau, cụ thể như sau:
Đối với thực thể course:
enroll: Người dùng ghi danh vào khóa học. Đây là sự kiện chuyển đổi chính.
detail-page-view: Người dùng xem trang thơng tin khóa học.
category-pref: Người dùng có sở thích về một thể loại khóa học nào đó. Thể loại khóa
học là một tính chất của khóa học. Sự kiện này được kích hoạt cùng lúc với enroll, với
thể loại chính là thể loại của khóa học mà người dùng ghi danh.
search-pref: Người dùng tìm kiếm một từ khóa nào đó liên quan đến khóa học.
popularity-pref: Người dùng có sở thích về độ phổ biến của khóa học. Mức độ phổ
lượng học sinh) thành các nhóm: nhỏ, vừa và lớn. Tương tự với category-pref, sự kiện này cũng được kích hoạt cùng lúc với enroll.
positive-rating: Người dùng đánh giá tích cực về một khóa học nào đó. Đánh giá tích
cực được nhóm làm đề tài định nghĩa là đánh giá có trên 3 sao.
mentor-pref: Người dùng u thích một giảng viên nào đó. Sự kiện này được kích hoạt
cùng lúc với enroll. Đối với thực thể group:
join: Người dùng gửi yêu cầu tham gia vào khóa học nào đó. Đây là sự kiện chuyển
đổi chính
detail-page-view: Người dùng xem trang thơng tin nhóm.
topic-pref: Người dùng có sở thích về một đề tài nào đó. Đề tài là một tính chất của
khóa học. Sự kiện này được kích hoạt cùng lúc với join, với đề tài là đề tài của nhóm lúc gửi yêu cầu tham gia.
search-pref: Người dùng tìm kiếm một từ khóa nào đó liên quan đến nhóm.
popularity-pref: Tương tự như sự kiện cùng tên ở khóa học.
bookmark: Người dùng bookmark một khóa học.
Đối với thực thể user:
befriend: Người dùng gửi yêu cầu kết bạn đến ai đó. Đây là sự kiện chính.
detail-page-view: Tương tự với các sự kiện cùng tên.
enroll-course: Người dùng ghi danh vào khóa học.
join-group: Người dùng gửi yêu cầu tham gia nhóm.
search-pref: Tương tự với các sự kiện cùng tên.
Đối với thực thể post:
upvote: Người dùng ủng hộ vào một bài viết nào đó. Đây là sự kiện chuyển đổi chính.
comment: Người dùng bình luận vào một bài viết.
topic-pref: Sự kiện được ghi nhận từ sự kiện cùng tên của group.
category-pref: Sự kiện được ghi nhận từ sự kiện cùng tên của course.
op-pref: Người dùng u thích tác giả của bài viết nào đó. Được ghi nhận cùng lúc với
sự kiện upvote, với đối tượng tác giả chính là người viết nên bài viết đó.
Tóm lại, nhóm làm đề tài xây dựng các sự kiện chuyển đổi chính được xác định là mục tiêu cuối cùng của hệ thống giới thiệu cũng như các sự kiện phụ mà nhóm xác định một cách chủ quan rằng sẽ có khả năng đóng góp vào chất lượng của mơ hình. Tính chủ quan này khơng hề ảnh hưởng đến mơ hình, kể cả trong trường một số sự kiện trên khơng hề có tính tương quan với sự kiện chính trên thực tế, vì theo cơng thức của giải thuật CCO: mơ hình có
khả năng học được các mối tương quan tiềm ẩn đó thành các ma trận trọng số. Nếu sự tương quan là hầu như khơng có, trọng số của các phần tử trong ma trận giữa sự kiện đó và sự kiện chính sẽ hầu như khơng đáng kể và khơng ảnh hưởng nhiều đến recommendation score dự đốn.
Một nhược điểm của ActionML được rút ra ở bước xây dựng sự kiện đó chính là nó khơng có khả năng mơ hình được các sự kiện nhiều hơn hai tham số. Lấy sự kiện positive-
rating ở trên làm ví dụ: vì mơ hình khơng thể biểu diễn khái niệm: người dùng A đánh giá
khóa học B với mức đánh giá là X. Do đó, phải chuyển đổi sự kiện này thành: người dùng A đánh giá cao khóa học B. Điều này khiến mơ hình kém chắc chắn bởi vì nó giới thiệu thêm một siêu tham số đòi hỏi người thiết kế phải cân nhắc khi đánh giá mơ hình.
Một hệ quả của nhược điểm trên đó chính là ActionML khơng thể nào mơ hình được khái niệm: A có bạn bè là B cũng yêu cầu tham gia một khóa học nào đó chẳng hạn. Đây có thể nói là thiếu sót lớn nhất, vì hệ thống được xây dựng trên nền tảng mạng xã hội: khái niệm bạn bè ít nhiều có ảnh hưởng đến hành vi người dùng trong việc lựa chọn khóa học, nhóm, … mà mình muốn đăng ký. Hình thức giới thiệu trên cịn được gọi là Trust-aware Recommendation. Nhóm làm đề tài khắc phục nhược điểm trên bằng cách tận dụng khả năng hỗ trợ business rule của ActionML, cụ thể như sau:
1. Lưu trữ hoạt động của bạn bè với nhau và lưu trữ trong cơ sở dữ liệu. Đây chính là trường interactionScore của thực thể friend đã được mô tả ở mục Sắp xếp nội dung
người dùng.
2. Khi đưa ra lời giới thiệu, hệ thống query trong cơ sở dữ liệu những người có interactionScore với người dùng mục tiêu lớn hơn một giá trị ngưỡng T tự định nghĩa, gọi là trusted friend.
3. Khi query vào The Universal Recommender, thêm vào các business rule boost score của các kết quả tìm kiếm có liên quan với các trusted friends đó (ví dụ khóa học thì sẽ boost những khóa học có chứa trusted friend là học sinh).
Hình 47: API reference khi gửi query vào ActionML . ActionML thêm business rule để ràng buộc việc đưa ra giới thiệu thông qua rules.
Các câu query được hệ thống tích hợp vào API của mình bao gồm: Tìm kiếm phổ biến, tìm kiếm item tương tự item, tìm kiếm item mà người dùng có thể thích.
6.5.3 Hướng phát triển trong tương lai
Hướng phát triển đối với hệ thống đó chính là việc đánh giá hệ thống giới thiệu và tùy chỉnh khi đưa vào sử dụng rộng rãi. Có thể thấy, hệ thống giới thiệu của nhóm làm đề tài có khá nhiều siêu tham số, nhiều sự kiện và một vài business rule ràng buộc. Do đó, việc đánh giá hệ thống có vai trị quan trọng. Tuy vậy, vì trong giai đoạn luận văn nhóm làm đề tài chưa thể đưa hệ thống vào sử dụng và có dữ liệu thực tế, việc kiểm tra đánh giá được xác định sẽ là hướng phát triển trong tương lai.
Chiến lược đánh giá được đề ra như sau:
Thực hiện A/B Testing: Đưa vào sử dụng hai hệ thống giới thiệu với các biến thể config khác nhau và lần lượt so sánh chất lượng mỗi lần hai biến thể trên hai tập người dùng tương đương nhau. Việc phân bổ tập người dùng rất quan trọng vì mỗi một người dùng sẽ có sở thích khác nhau tùy vào giới tính, độ tuổi. Cách chia dễ dàng nhất đó là chia ngẫu nhiên: băm id của người dùng vào hai xô (bucket) theo một giải thuật băm nào đó rồi đưa vào một trong hai giải thuật tùy vào xơ mà người đó trúng. Nếu tập người dùng chúng ta đủ lớn, thì sự khác biệt giữa hai xô người dùng sau khi ngẫu nhiên là không đáng kể.
Metric sử dụng để so sánh chất lượng của hai mơ hình giới thiệu là conversion rate (CR). Ta lưu trữ danh sách các item được giới thiệu đến người dùng, thời gian giới
thiệu và mơ hình dùng để giới thiệu (A hoặc B). Ta định kỳ kiểm tra trong từng tập người dùng, tỉ lệ số người sau khi được giới thiệu lựa chọn mua bất kỳ một item trong