System DesignKhung trả lời đúng: bắt đầu bằng thứ chạy được với dữ liệu đang có, và tách rõ tính toán ngoại tuyến (offline) với phục vụ trực tuyến (online).
Ba mức tăng dần, nêu đúng thứ tự này là ghi điểm:
1. Theo quy tắc: bán chạy trong ngành hàng, xem gần đây, mua kèm — không cần mô hình, phủ được đa số vị trí hiển thị.
2. Item-to-item collaborative filtering: "người mua X cũng mua Y", tính từ log đơn hàng bằng một job Spark/SQL chạy hằng đêm. Đây là mức mang lại lợi ích lớn nhất so với công sức.
3. Mô hình học (matrix factorization, gradient boosting để xếp hạng lại) — chỉ khi đã có pipeline dữ liệu và chỉ số đo được.
Kiến trúc hai lớp:
offline: event log -> job hang dem -> bang goi y
recs(item_id, rank, related_item_id, score)
recs_user(user_id, rank, item_id, score)
online: API doc bang goi y tu Redis -> loc -> tra veĐường phục vụ không tính toán — chỉ tra cứu key rồi lọc. Nhờ vậy độ trễ ổn định vài mili giây và job ngoại tuyến hỏng cũng không làm sập trang.
Lọc lúc phục vụ là phần hay bị bỏ sót: bỏ sản phẩm hết hàng, sản phẩm đã mua, sản phẩm bị ẩn, và trộn thêm chút đa dạng để không hiện 10 món giống hệt nhau.
Vấn đề kinh điển phải nêu:
- Cold start: người dùng mới và sản phẩm mới không có dữ liệu → quay về gợi ý theo quy tắc (bán chạy theo ngành hàng, theo vị trí địa lý).
- Vòng lặp phản hồi: chỉ gợi ý thứ đang bán chạy sẽ khiến nó càng bán chạy. Chèn một tỉ lệ nhỏ khám phá (exploration).
Đo lường: không có A/B test thì không biết gợi ý có tác dụng hay không. Đo tỉ lệ click và doanh thu trên mỗi phiên, so với nhóm đối chứng dùng gợi ý theo quy tắc.
Đánh đổi: tính ngoại tuyến làm gợi ý cũ vài giờ — chấp nhận được với thương mại điện tử, không chấp nhận được với nội dung theo thời gian thực; khi đó phải bổ sung tín hiệu phiên hiện tại (vừa xem gì) trộn vào lúc phục vụ.