Hệ khuyến nghị 1 — Tổng quan & bài toán

Vấn đề: quá nhiều lựa chọn, quá ít sự chú ý

Một khách hàng mở app ngân hàng số. Trong đó có hàng chục sản phẩm: nhiều loại thẻ tín dụng, vài gói vay tiêu dùng, sản phẩm tiết kiệm kỳ hạn, chứng chỉ tiền gửi, bảo hiểm nhân thọ, bảo hiểm sức khoẻ, quỹ đầu tư, ưu đãi đối tác... Không ai đọc hết. Nếu app hiển thị cùng một banner cho tất cả mọi người, tỷ lệ nhấp (click-through) sẽ thấp, và tệ hơn — khách nhận được lời chào không liên quan sẽ thấy bị làm phiền.

Hệ khuyến nghị (recommender system) là hệ thống dự đoán khách hàng này, tại thời điểm này, nhiều khả năng quan tâm đến thứ gì nhất rồi sắp xếp gợi ý theo mức độ phù hợp. Nó biến một danh mục "biển lựa chọn" thành một danh sách ngắn, đúng người, đúng lúc.

Đây là bài mở đầu series Hệ khuyến nghị & Cá nhân hoá. Mục tiêu bài này là dựng khung tư duy: các dạng bài toán, cách biểu diễn dữ liệu (ma trận user-item), các họ phương pháp và thách thức cốt lõi. Từng phần sẽ được đào sâu ở các bài sau. Ta sẽ dùng ngữ cảnh ngân hàng (NCB) xuyên suốt.

Vì sao khuyến nghị quan trọng

Giá trị của cá nhân hoá không phải lý thuyết — nó tác động trực tiếp đến các chỉ số kinh doanh:

• Tăng gắn kết (engagement): nội dung/gợi ý đúng ý giữ khách ở lại app lâu hơn, quay lại thường xuyên hơn. Với ngân hàng, tần suất mở app là chỉ báo sớm của lòng trung thành.
• Tăng chuyển đổi (conversion): gợi ý đúng sản phẩm vào đúng thời điểm nhu cầu (ví dụ đề xuất vay khi khách vừa tìm hiểu mua nhà) nâng tỷ lệ đăng ký so với chào hàng đại trà.
• Bán chéo (cross-sell) & bán thêm (up-sell): khách đang có tài khoản thanh toán → gợi ý thẻ tín dụng; khách có thẻ chuẩn → gợi ý nâng hạng; khách có tiết kiệm → gợi ý bảo hiểm. Tăng số sản phẩm/khách (product-per-customer) là đòn bẩy doanh thu lớn với chi phí thu hút gần như bằng không.
• Giảm tải nhận thức cho khách: giúp khách tìm đúng thứ trong biển lựa chọn thay vì tự dò tìm — trải nghiệm tốt hơn, ít bỏ giữa chừng.
• Tối ưu chi phí marketing: thay vì gửi cùng một ưu đãi cho cả triệu người, chỉ nhắm đúng nhóm có xác suất phản hồi cao → tiết kiệm ngân sách và giảm "mệt mỏi vì quảng cáo".

Nói ngắn gọn: khuyến nghị là cầu nối giữa dữ liệu hành vi ngân hàng đã có sẵn và giá trị kinh doanh có thể thu về, qua lăng kính cá nhân hoá.

Các dạng bài toán khuyến nghị

"Khuyến nghị" không phải một bài toán duy nhất. Tuỳ mục tiêu, ta gặp các dạng khác nhau:

Điểm quan trọng: ranking (top-N) là dạng phổ biến nhất trong sản xuất. Khách hàng thực tế không quan tâm điểm dự đoán tuyệt đối là 4.2 hay 4.5 sao — họ chỉ thấy danh sách gợi ý. Vì vậy chất lượng của thứ tự (đưa đúng thứ lên đầu) quan trọng hơn độ chính xác của điểm số. Điều này thay đổi cả cách chọn mô hình lẫn cách đo lường — sẽ bàn kỹ ở Hệ khuyến nghị 6 — Ranking & đánh giá.

Trong hệ quy mô lớn, hai dạng cuối thường ghép thành kiến trúc retrieval → ranking: một tầng retrieval lọc nhanh vài trăm ứng viên tiềm năng từ toàn bộ danh mục, rồi một tầng ranking tinh chấm điểm và xếp hạng chính xác nhóm nhỏ đó. Kiến trúc phục vụ này là trọng tâm của bài 7 — Production & serving.

Ma trận user-item & tín hiệu tương tác

Nền tảng dữ liệu của gần như mọi hệ khuyến nghị là ma trận user-item: các hàng là người dùng (user), các cột là sản phẩm/mục (item), mỗi ô là tín hiệu tương tác giữa cặp đó.

Tín hiệu tương tác chia hai loại:

• Explicit feedback (phản hồi tường minh): khách chủ động cho biết mức độ thích — đánh giá sao, like/dislike, khảo sát hài lòng. Ưu điểm: rõ ràng. Nhược điểm: hiếm (đa số khách không đánh giá), có thiên lệch (người rảnh hoặc rất bực mới đánh giá).
• Implicit feedback (phản hồi ngầm): suy ra sở thích từ hành vi — click, xem, mua, sử dụng sản phẩm, tần suất giao dịch. Nhiều hơn nhiều lần so với explicit, nhưng "nhiễu" hơn: không click ≠ không thích (có thể chỉ chưa nhìn thấy), và không có tín hiệu "ghét" rõ ràng.

Trong ngân hàng, tín hiệu chủ yếu là implicit. Khách hầu như không "chấm sao" cho gói vay. Thay vào đó, ta có kho hành vi giàu có: khách đang giữ những sản phẩm nào, giao dịch loại gì, tần suất và giá trị ra sao, đã click ưu đãi nào, có đăng ký khi được chào không. Toàn bộ tín hiệu này đến từ dữ liệu giao dịch và trạng thái sản phẩm — nghĩa là ma trận user-item của ngân hàng được dựng từ hành vi, không phải từ đánh giá. Cách xử lý implicit feedback (như trọng số theo mức độ tự tin) là chủ đề của bài 3 — Matrix Factorization.

Các họ phương pháp (giới thiệu)

Có bốn họ phương pháp chính. Bài này chỉ giới thiệu trực giác; mỗi họ có bài riêng đi sâu.

• Collaborative Filtering (CF — lọc cộng tác): dựa trên nguyên lý "những khách hành vi giống nhau sẽ thích những thứ giống nhau". Không cần biết thuộc tính sản phẩm; chỉ cần lịch sử tương tác. Là xương sống của nhiều hệ khuyến nghị. Chi tiết ở bài 2 — Collaborative Filtering.
• Content-based (dựa nội dung): gợi ý item giống những item khách đã thích, dựa trên thuộc tính (đặc trưng sản phẩm, hồ sơ khách). Ví dụ: khách hay dùng sản phẩm tiết kiệm dài hạn → gợi ý sản phẩm cùng nhóm rủi ro thấp. Mạnh khi có item mới (biết thuộc tính là gợi ý được), nhưng dễ "đóng khung" trong sở thích cũ.
• Hybrid (lai ghép): kết hợp CF và content-based (và các tín hiệu khác) để lấy điểm mạnh, bù điểm yếu — đặc biệt để giảm cold start. Hầu hết hệ sản xuất là hybrid. Xem bài 4 — Content & Hybrid.
• Deep learning (học sâu): dùng mạng nơ-ron để học embedding của user/item, mô hình hoá chuỗi hành vi (sequential), kiến trúc two-tower cho retrieval quy mô lớn. Xem bài 5 — Deep learning cho khuyến nghị. Nền tảng embedding liên hệ DL 6 — Transformers và Vector DB.

Thách thức cốt lõi

Hệ khuyến nghị có những khó khăn đặc thù mà mô hình dự báo/phân loại thông thường không gặp:

• Cold start (khởi động lạnh): khách mới chưa có lịch sử → CF không có gì để dựa; item mới chưa ai dùng → không xếp hạng được. Đây là bài toán dai dẳng nhất. Cách gỡ: dùng content/thuộc tính, hoặc quy tắc, cho đến khi tích luỹ đủ hành vi.
• Sparsity (ma trận thưa): mỗi khách chỉ tương tác với một phần rất nhỏ danh mục. Ma trận user-item thường trống trên 99%. Thuật toán phải suy diễn tốt từ dữ liệu rất thưa — đây là lý do matrix factorization và embedding hữu dụng.
• Scalability (khả năng mở rộng): hàng triệu khách × hàng nghìn item → không thể tính brute-force mọi cặp mỗi lần. Cần kiến trúc retrieval + ranking và tính toán trước (precompute).
• Popularity bias (thiên lệch phổ biến): mô hình có xu hướng luôn đề xuất những item đã phổ biến, tạo hiệu ứng "kẻ giàu càng giàu" và bỏ quên item ngách. Cần cân đối bằng đa dạng hoá (diversity).
• Feedback loop (vòng phản hồi): hệ chỉ gợi ý một số item → khách chỉ tương tác với những item được gợi ý → dữ liệu huấn luyện lần sau càng lệch về nhóm đó. Vòng lặp này tự củng cố thiên lệch nếu không kiểm soát (ví dụ chèn khám phá — exploration).
• Đánh giá khó (evaluation): ta không biết khách sẽ phản ứng thế nào với item chưa từng được gợi ý. Metric offline (như precision@k, recall@k, NDCG) chỉ là proxy; chân lý cuối cùng là A/B test online. Đây là chủ đề của bài 6, liên hệ Thống kê — A/B testing.

Ứng dụng trong ngân hàng

Trong bối cảnh NCB, khuyến nghị hiện diện ở nhiều nơi:

• Next-Best-Action (NBA — hành động tốt nhất tiếp theo): bài toán trung tâm. Với mỗi khách, gợi ý sản phẩm/hành động nên chào tiếp theo — thẻ tín dụng, khoản vay, gói tiết kiệm, bảo hiểm, nâng hạng thẻ... NBA chính là ranking top-N áp trên danh mục sản phẩm ngân hàng. Đây là trọng tâm của bài 8 — Banking NBA.
• Ưu đãi cá nhân hoá (personalized offers): chọn đúng ưu đãi/khuyến mãi cho từng khách thay vì gửi đại trà — hoàn tiền, giảm phí, điểm thưởng đối tác.
• Gợi ý nội dung & tính năng app: sắp xếp banner, mẹo tài chính, tính năng nên dùng theo hành vi từng khách.
• Cross-sell / up-sell: bán chéo và bán thêm dựa trên sản phẩm hiện có và hành vi giao dịch.
• Giữ chân (retention): nhận diện khách có dấu hiệu rời bỏ và gợi ý hành động giữ chân phù hợp.

Việc phân nhóm khách (segmentation) thường là bước đệm hoặc tín hiệu đầu vào cho khuyến nghị — xem Loyalty — Analytics & Segmentation và Phân tích khách hàng — Segmentation RFM.

Khác biệt & ràng buộc đặc thù ngân hàng

Khuyến nghị ngân hàng không giống gợi ý phim hay hàng tiêu dùng. Có ràng buộc riêng, sẽ đào sâu ở bài 8:

• Tuân thủ (compliance): sản phẩm tài chính chịu quy định; không được chào tuỳ tiện.
• Phù hợp (suitability): chỉ nên gợi ý sản phẩm phù hợp năng lực và nhu cầu khách (ví dụ không chào vay vượt khả năng trả nợ). Gợi ý sai không chỉ vô ích mà còn rủi ro pháp lý và uy tín.
• Không spam: kiểm soát tần suất chào để tránh làm phiền và mệt mỏi khách.
• Công bằng (fairness): gợi ý không được phân biệt đối xử theo các thuộc tính nhạy cảm — vừa là yêu cầu đạo đức vừa là yêu cầu pháp lý.

Baseline "phổ biến nhất": điểm khởi đầu bắt buộc

Trước khi xây bất kỳ mô hình phức tạp nào, hãy luôn có một baseline. Baseline đơn giản và mạnh bất ngờ là "phổ biến nhất" (most popular): gợi ý cho mọi người những item được tương tác nhiều nhất tổng thể. Nó không cá nhân hoá, nhưng đặt ra ngưỡng để mọi mô hình khác phải vượt qua — nếu mô hình học sâu không đánh bại được "phổ biến nhất", thì nó chưa đáng để triển khai.

Trên sandbox PostgreSQL, ta minh hoạ baseline bằng cách đếm loại giao dịch (kind) phổ biến nhất từ bảng transactions — coi mỗi kind như một "item" và tần suất giao dịch như tín hiệu implicit:

-- ▶ Chạy được
SELECT kind AS item,
       COUNT(*) AS interactions,
       COUNT(DISTINCT account_id) AS distinct_accounts
FROM transactions
GROUP BY kind
ORDER BY interactions DESC
LIMIT 10;

Kết quả cho một bảng xếp hạng "item phổ biến nhất": loại giao dịch nào được dùng nhiều nhất, bởi bao nhiêu tài khoản khác nhau. Đây chính là danh sách top-N không cá nhân hoá — baseline để so sánh. (Đây là minh hoạ đơn giản hoá: trong thực tế "item" là sản phẩm ngân hàng, và ta còn tính đến số tài khoản/khách duy nhất để tránh một vài tài khoản giao dịch dày làm lệch thứ hạng.)

Use case thực tế

Bối cảnh. Đội Data của NCB muốn dựng module Next-Best-Action gợi ý 3 sản phẩm trên trang chủ app cho ~1,2 triệu khách hàng. Danh mục có 40 sản phẩm. Trước khi đầu tư mô hình phức tạp, đội chốt lộ trình theo đúng khung của bài này.

Các bước.

1. Dựng ma trận user-item từ implicit feedback. Với mỗi khách, lấy sản phẩm đang giữ + hành vi giao dịch/click 90 ngày. Ma trận 1,2 triệu × 40, độ thưa ~96% (trung bình mỗi khách chỉ chạm ~1,6 sản phẩm). Không có explicit rating — hoàn toàn implicit.
2. Baseline "phổ biến nhất". Xếp hạng sản phẩm theo số khách sử dụng, đề xuất top-3 chung cho mọi khách. Đo trên tập giữ lại (holdout): recall@3 = 21%. Đây là ngưỡng phải vượt.
3. Cold start. ~8% khách là mới (chưa đủ hành vi). Với nhóm này dùng quy tắc content-based theo phân khúc (segment) từ phân tích RFM thay vì CF.
4. Mô hình CF/hybrid (các bài sau). Mục tiêu vượt baseline recall@3 = 21% một cách có ý nghĩa thống kê.
5. Lọc tuân thủ & phù hợp. Trước khi hiển thị, loại sản phẩm khách không đủ điều kiện (ví dụ không chào vay cho khách quá hạn), giới hạn tần suất chào cùng một sản phẩm ≤ 1 lần/tuần.
6. Đánh giá online. A/B test: nhóm control (baseline phổ biến) vs nhóm treatment (mô hình cá nhân hoá). Chỉ số chính: tỷ lệ đăng ký sản phẩm được gợi ý; chỉ số phụ: CTR, khiếu nại "làm phiền".

Kết quả kỳ vọng. Cá nhân hoá nâng recall@3 và tỷ lệ chuyển đổi so với baseline, đồng thời không tăng khiếu nại — điều kiện để mở rộng toàn bộ tệp khách.

Ghi nhớ

• Hệ khuyến nghị dự đoán và xếp hạng thứ mỗi khách nhiều khả năng quan tâm; giá trị: tăng gắn kết, chuyển đổi, cross-sell/up-sell, giữ chân, và giảm chi phí marketing.
• Có nhiều dạng bài toán: rating prediction, ranking/top-N (phổ biến nhất), next-item/sequential, candidate retrieval. Trong sản xuất, thứ tự (ranking) quan trọng hơn điểm số tuyệt đối.
• Dữ liệu nền là ma trận user-item; tín hiệu là explicit (đánh giá) hoặc implicit (hành vi). Ngân hàng chủ yếu implicit từ giao dịch và sản phẩm đang giữ.
• Bốn họ phương pháp: collaborative filtering, content-based, hybrid, deep learning — sẽ đào sâu ở các bài sau; đa số hệ sản xuất là hybrid.
• Thách thức: cold start, sparsity (ma trận trống >99%), scalability, popularity bias, feedback loop, và đánh giá khó (offline chỉ là proxy, cuối cùng cần A/B test).
• Luôn có baseline "phổ biến nhất" trước khi xây mô hình phức tạp — mọi mô hình phải đánh bại được nó.
• Ứng dụng ngân hàng cốt lõi là Next-Best-Action; ràng buộc riêng: tuân thủ, phù hợp (suitability), không spam, công bằng — đào sâu ở bài 8.