Hệ khuyến nghị 5 — Deep Learning cho khuyến nghị

Vì sao cần deep learning cho khuyến nghị

Matrix Factorization ở bài 3 đã cho ta embedding tự học và dự đoán bằng dot product. Nó mạnh, gọn, dễ mở rộng — nhưng dot product chỉ mô hình hoá tương tác tuyến tính giữa user và item. Khi dữ liệu đủ lớn và quan hệ đủ phức tạp, sự tuyến tính đó trở thành trần kính. Deep learning (DL — học sâu) xuất hiện để phá trần đó, với bốn động lực cụ thể:

• Bắt tương tác phi tuyến: sở thích thật hiếm khi cộng tuyến tính. "Khách thích gói tiết kiệm và đồng thời hay giao dịch quốc tế" là một tín hiệu khác hẳn tổng của hai sở thích riêng lẻ. Mạng neural nhiều lớp học được các tương tác bậc cao mà dot product không diễn đạt nổi.
• Nuốt được feature phong phú: MF thuần chỉ biết id-user và id-item. DL dễ dàng nhồi thêm hàng trăm đặc trưng dị chủng — tuổi, thu nhập, phân khúc, kênh, thiết bị, thời điểm, văn bản mô tả sản phẩm — và tự học cách kết hợp chúng.
• Hiểu chuỗi hành vi (sequence): hành vi khách hàng có thứ tự thời gian. Vừa mở tài khoản → tra cứu vay → xem bảo hiểm là một mạch ý định khác với chuỗi ngược lại. MF coi tương tác như một túi không thứ tự (bag); DL (RNN, Transformer) mô hình hoá được diễn tiến này.
• Cá nhân hoá sâu và chia sẻ biểu diễn: một mạng duy nhất có thể học chung cho hàng triệu khách, chia sẻ tham số nên khái quát tốt cho đuôi dài (long tail), đồng thời tinh chỉnh riêng cho từng người qua embedding cá nhân.

Ngôn ngữ chung xuyên suốt vẫn là embedding: mọi thực thể — khách, sản phẩm, merchant, danh mục, thậm chí thời điểm — được ánh xạ thành vector số ít chiều. DL chỉ khác ở chỗ nó biến đổi và kết hợp các embedding này bằng mạng neural thay vì một phép nhân vô hướng.

Cảnh báo sớm: DL không phải mặc định. Nó chỉ trả lời được khi bạn có đủ dữ liệu tương tác (thường hàng chục triệu event trở lên) và hạ tầng huấn luyện/phục vụ. Với dữ liệu vừa, MF hay thậm chí popularity baseline vẫn thắng về ROI. Luôn so với baseline đơn giản trước.

Kiến trúc 1 — Neural Collaborative Filtering (embedding + MLP)

Ý tưởng khởi đầu đơn giản nhất: thay phép dot product bằng một mạng neural. Trong Neural Collaborative Filtering (NCF), ta vẫn có embedding cho user và item như MF, nhưng thay vì $\hat{r}_{ui} = p_u \cdot q_i$, ta ghép (concatenate) hai embedding rồi cho qua vài lớp MLP (multi-layer perceptron — mạng nhiều lớp fully-connected):

$$\hat{y}_{ui} = \text{MLP}\big([,p_u ,\Vert, q_i,]\big)$$

MLP với hàm kích hoạt phi tuyến (ReLU) học được các tương tác mà dot product bỏ lỡ. NCF bản gốc thường kết hợp hai nhánh: một nhánh GMF (generalized matrix factorization — tổng quát hoá dot product) và một nhánh MLP, rồi hợp nhất ở lớp cuối. Đây là bước tư duy nền: recommender chính là một bài học biểu diễn + học hàm tương tác, và cả hai đều có thể là mạng neural.

Lưu ý thực tế: NCF hay bị phê phán là "phi tuyến hoá cho có" — nhiều nghiên cứu về sau chỉ ra một dot product được điều chỉnh tốt vẫn cạnh tranh sòng phẳng. Giá trị của NCF nằm ở việc mở cánh cửa cho các kiến trúc giàu feature hơn phía dưới, hơn là bản thân nó là giải pháp cuối.

Kiến trúc 2 — Two-Tower / Retrieval model (xương sống hiện đại)

Đây là kiến trúc quan trọng nhất cần nắm, vì nó là nền của retrieval quy mô lớn ở YouTube, Google, và hầu hết hệ recommender hiện đại.

Ý tưởng: dựng hai tháp mạng neural độc lập:

• User tower (tháp người dùng): nhận toàn bộ feature của khách + ngữ cảnh (lịch sử, phân khúc, thời điểm) → xuất ra một user embedding $u \in \mathbb{R}^d$.
• Item tower (tháp sản phẩm): nhận feature của sản phẩm → xuất ra một item embedding $v \in \mathbb{R}^d$ cùng chiều, cùng không gian với user embedding.

Điểm mấu chốt: hai tháp được huấn luyện để user embedding gần item embedding (theo dot product hoặc cosine) khi khách có xu hướng tương tác. Vì item embedding không phụ thuộc vào user, ta có thể tính trước embedding của toàn bộ catalogue offline, nạp vào một chỉ mục ANN (Approximate Nearest Neighbor — tìm lân cận xấp xỉ) — xem bài về embedding & vector search. Lúc phục vụ, chỉ cần tính user embedding một lần rồi truy vấn ANN để lấy hàng trăm candidate trong mili-giây, kể cả khi catalogue có hàng triệu item.

Đây chính là lý do two-tower còn gọi là retrieval model: nhiệm vụ của nó không phải chấm điểm chính xác từng item, mà thu hẹp từ hàng triệu xuống vài trăm ứng viên tốt một cách siêu nhanh. Hạn chế cố hữu: hai tháp không "nhìn thấy nhau" cho tới bước dot product cuối — không có tương tác chéo user×item sớm — nên độ tinh không cao. Đó là lý do phải có giai đoạn ranking phía sau (mục dưới).

Kiến trúc 3 — Wide & Deep, DeepFM (ghi nhớ + tổng quát hoá)

Google giới thiệu Wide & Deep với một quan sát đắt giá: hệ recommender cần cả hai năng lực đối lập.

• Memorization (ghi nhớ) — phần wide: một mô hình tuyến tính trên các đặc trưng chéo thủ công (cross features, vd thành_phố=HCM AND sản_phẩm=vay_mua_nhà) ghi nhớ tốt các quy tắc đồng xuất hiện thường gặp và ngoại lệ.
• Generalization (tổng quát hoá) — phần deep: một mạng embedding + MLP khái quát sang các kết hợp chưa từng thấy trong huấn luyện, tránh việc chỉ gợi lại những gì đã phổ biến.

Hai nhánh được huấn luyện chung (joint) và cộng logit ở lớp cuối. Nhược điểm của Wide & Deep là phần wide vẫn cần feature engineering thủ công các cross feature.

DeepFM khắc phục điều đó: thay nhánh wide tuyến tính bằng một Factorization Machine (FM) — vốn tự học tương tác bậc hai giữa mọi cặp đặc trưng qua vector latent (xem phần FM ở bài 3) — và chia sẻ cùng bảng embedding với nhánh deep. Kết quả: bắt được cả tương tác bậc hai (FM) lẫn bậc cao (MLP) mà không cần chế cross feature bằng tay. Đây là họ mô hình chủ lực cho bài toán CTR prediction / ranking trên dữ liệu tabular giàu feature — rất hợp ngữ cảnh ngân hàng.

Kiến trúc 4 — Sequence / session-based (dự đoán hành động tiếp theo)

Các kiến trúc trên coi lịch sử khách như một túi không thứ tự. Nhưng nhiều bài toán bản chất là chuỗi: "cho chuỗi hành động vừa qua, đoán hành động tiếp theo". Đây là session-based / sequential recommendation.

• GRU4Rec: dùng RNN (cụ thể là GRU — gated recurrent unit) để đọc tuần tự chuỗi sự kiện trong một phiên và dự đoán item kế tiếp. Là mô hình sequential recommender đầu tiên gây tiếng vang.
• SASRec (Self-Attentive Sequential Recommendation): thay RNN bằng self-attention — cùng cơ chế của Transformer (xem bài về Transformers). Với mỗi bước, mô hình "chú ý có trọng số" tới các hành động quá khứ liên quan nhất, bất kể xa gần, thay vì nén tuần tự như RNN. Nhờ vậy nó bắt được phụ thuộc tầm xa tốt hơn và huấn luyện song song nhanh hơn.
• Transformer cho hành vi: tổng quát hơn, ta coi lịch sử tương tác như một "câu" gồm các token-item, và huấn luyện mô hình đoán token tiếp theo (giống mô hình ngôn ngữ). Đây là hướng đang thống trị sequential recommendation.

Trực giác giá trị: hành vi giao dịch ngân hàng vốn rất chuỗi — lương về → chuyển tiết kiệm → tra cứu vay → mở thẻ tín dụng. Một sequence model đọc được mạch ý định này và gợi đúng bước kế, điều mô hình "túi" không làm được.

Kiến trúc 5 — Graph-based (GNN) — khái quát

Tương tác user-item bản chất là một đồ thị hai phía (bipartite graph): nút là user và item, cạnh là tương tác. Graph Neural Network (GNN) khai thác cấu trúc này bằng message passing: embedding của mỗi nút được cập nhật bằng cách gộp thông tin từ các nút láng giềng, lặp nhiều lớp để lan truyền tín hiệu qua nhiều bước (khách → sản phẩm → khách khác → sản phẩm khác…). Nhờ vậy GNN nắm được tín hiệu bậc cao (high-order connectivity) — quan hệ gián tiếp mà MF/two-tower khó chạm tới. Các mô hình như PinSage (Pinterest), LightGCN là đại diện. GNN mạnh nhưng nặng về hạ tầng và huấn luyện; ở đây chỉ nêu để bạn biết đây là một nhánh chính, không đi sâu.

Huấn luyện: negative sampling và loss ranking

Điểm chung của gần như mọi mô hình DL recommender là bài toán implicit, một lớp (one-class): ta chỉ có tín hiệu dương (khách đã click/dùng), còn "chưa dùng" không rõ là không thích hay chưa biết tới. Hai kỹ thuật cốt lõi:

• Negative sampling (lấy mẫu âm): với mỗi ví dụ dương, ta rút ngẫu nhiên một/nhiều item khách chưa tương tác làm ví dụ âm. Với two-tower, kỹ thuật phổ biến là in-batch negatives — coi item của các khách khác trong cùng batch làm mẫu âm, tận dụng lại tính toán nên rất hiệu quả (thường kèm hiệu chỉnh theo độ phổ biến để tránh phạt oan item hot).
• Loss ranking / contrastive: mục tiêu không phải đoán đúng con số mà xếp dương cao hơn âm. Two-tower thường dùng sampled softmax (phân loại item dương giữa dương + các âm). Các mô hình pairwise dùng BPR loss (đã gặp ở bài 3). Điểm chung: tối ưu trực tiếp cho thứ tự, đúng thứ mà top-N recommendation cần.

Pseudocode minh hoạ — two-tower (PyTorch)

Đoạn dưới là pseudocode minh hoạ cấu trúc two-tower và in-batch softmax, KHÔNG phải mã sản xuất và KHÔNG phải SQL.

# MINH HOẠ — không phải mã chạy được hoàn chỉnh
import torch, torch.nn as nn, torch.nn.functional as F

class Tower(nn.Module):
    def __init__(self, in_dim, out_dim=64):
        super().__init__()
        self.net = nn.Sequential(
            nn.Linear(in_dim, 128), nn.ReLU(),
            nn.Linear(128, out_dim),
        )
    def forward(self, x):
        return F.normalize(self.net(x), dim=-1)  # chuẩn hoá -> cosine

class TwoTower(nn.Module):
    def __init__(self, user_dim, item_dim, d=64):
        super().__init__()
        self.user_tower = Tower(user_dim, d)
        self.item_tower = Tower(item_dim, d)

def train_step(model, user_feats, pos_item_feats, temp=0.05):
    u = model.user_tower(user_feats)          # (B, d)
    v = model.item_tower(pos_item_feats)      # (B, d) — item dương của từng khách
    logits = (u @ v.t()) / temp               # (B, B): đường chéo là cặp dương
    labels = torch.arange(u.size(0))          # in-batch negatives
    return F.cross_entropy(logits, labels)    # sampled softmax

# Phục vụ: tính trước item_tower cho toàn catalogue -> nạp vào ANN.
# Lúc query: u = user_tower(feats); ANN.search(u, k=200) -> candidate.

Hai giai đoạn: Retrieval → Ranking

Mảnh ghép cuối, và là lý do các kiến trúc trên tồn tại song song thay vì thay thế nhau: hệ recommender quy mô lớn gần như luôn chia hai giai đoạn.

Two-tower nhanh nhưng thô (vì hai tháp không nhìn nhau sớm); mô hình ranking tinh nhưng đắt (không thể chạy trên hàng triệu item). Ghép lại: retrieval lọc thô ở quy mô lớn, ranking chấm kỹ trên tập nhỏ. Bài 7 về phục vụ production sẽ đi sâu kiến trúc hai giai đoạn này khi triển khai thực tế.

Đánh đổi: mạnh nhưng đắt

DL cho recommender không miễn phí. Cân nhắc tỉnh táo, đặc biệt trong ngân hàng:

• Đói dữ liệu: cần hàng chục–hàng trăm triệu event mới vượt được MF một cách ổn định. Dữ liệu vừa → MF/FM thắng.
• Hạ tầng nặng: GPU để huấn luyện, feature store cho feature realtime, chỉ mục ANN, pipeline hai giai đoạn — chi phí vận hành cao hơn hẳn.
• Khó giải thích (interpretability): chiều ẩn của mạng sâu gần như không diễn giải được. Với ngân hàng — nơi cần giải trình quy định (vì sao gợi sản phẩm này cho khách này) và tránh thiên lệch (bias/fairness) — đây là rào cản thật, không chỉ kỹ thuật.
• Luôn so baseline: quy tắc vàng — trước khi tin một mô hình DL, phải chứng minh nó thắng popularity baseline và MF trên A/B test online, không chỉ metric offline. Rất nhiều dự án DL thua baseline mà không ai để ý.

Use case thực tế

Bài toán: NCB muốn gợi ý "hành động/sản phẩm tiếp theo" trên app cho ~5 triệu khách cá nhân, với catalogue mở rộng gồm ~40 sản phẩm lõi + ~200k merchant ưu đãi. Dữ liệu: ~120 triệu event/tháng (mở màn hình, click banner, kích hoạt sản phẩm, giao dịch).

Cách làm (kiến trúc hai giai đoạn):

1. Feature: user tower nhận hồ sơ (tuổi, phân khúc, thu nhập ước lượng) + chuỗi 50 hành vi gần nhất (mã hoá bằng self-attention kiểu SASRec) + ngữ cảnh (thời điểm, kênh). Item tower nhận thuộc tính sản phẩm/merchant.
2. Retrieval: huấn luyện two-tower với embedding $d = 64$, in-batch negatives + sampled softmax. Tính trước embedding của 200k merchant + 40 sản phẩm, nạp vào chỉ mục ANN (xem vec-01). Lúc phục vụ: tính user embedding, lấy top-200 candidate trong ~10 ms.
3. Ranking: mô hình DeepFM chấm điểm 200 candidate với đầy đủ feature chéo user×item, xuất xác suất click/kích hoạt, lấy top-5 hiển thị.
4. Lọc tuân thủ: bỏ sản phẩm đã sở hữu; áp quy tắc (không gợi vay cho khách nợ xấu); ghi log lý do phục vụ giải trình.
5. Đánh giá: offline Recall@200 cho retrieval, NDCG@5/AUC cho ranking (xem bài 6); rồi A/B test online so với MF baseline.

Kết quả minh hoạ (mô phỏng): so với two-tower đơn thuần không dùng chuỗi hành vi, việc thêm sequence encoder nâng Recall@200 từ ~0,42 lên ~0,55; giai đoạn ranking DeepFM tăng CTR banner ~1,4 lần so với chỉ sắp theo điểm retrieval. Tổng đầu tư hạ tầng chỉ được duyệt sau khi A/B test xác nhận vượt MF baseline có ý nghĩa thống kê.

Vận hành: retrieval huấn luyện lại theo tuần (batch), ranking cập nhật thường xuyên hơn; embedding và feature chuỗi phục vụ realtime qua feature store; giám sát drift phân phối hành vi để biết khi nào cần huấn luyện lại.

Ghi nhớ

• Chỉ dùng DL khi dữ liệu lớn (chục–trăm triệu event) và có quan hệ phi tuyến/chuỗi; luôn so với baseline (popularity, MF) trên A/B test trước khi tin.
• NCF: thay dot product bằng MLP trên embedding ghép — mở đường cho mô hình giàu feature, nhưng bản thân không phải liều thuốc thần.
• Two-tower / retrieval là xương sống hiện đại: tháp user + tháp item → embedding cùng không gian → ANN lấy candidate ở quy mô triệu item; nhanh nhưng thô (hai tháp không nhìn nhau sớm).
• Wide & Deep / DeepFM: kết hợp ghi nhớ (wide/FM) + tổng quát hoá (deep); DeepFM tự học feature interaction, không cần cross feature thủ công — hợp ranking tabular ngân hàng.
• Sequence model (GRU4Rec, SASRec/Transformer, xem dl-06) đọc chuỗi hành vi để đoán hành động tiếp theo — hợp mạch giao dịch ngân hàng có thứ tự.
• GNN khai thác đồ thị user-item, nắm tín hiệu bậc cao — mạnh nhưng nặng hạ tầng.
• Embedding là ngôn ngữ chung; huấn luyện dựa trên negative sampling (in-batch) và loss ranking (sampled softmax/BPR), tối ưu thứ tự chứ không phải giá trị.
• Hệ thực tế chia hai giai đoạn retrieval → ranking (dẫn bài 7); đánh đổi lớn: đói dữ liệu, hạ tầng đắt, khó giải thích — cân nhắc kỹ với ràng buộc giải trình của ngân hàng.