Hệ khuyến nghị 8 — Next-Best-Action ngân hàng

Từ recommender đến Next-Best-Action

Bảy bài trước xây dựng bộ máy khuyến nghị đầy đủ: từ tổng quan, collaborative filtering, matrix factorization, content/hybrid, deep learning, ranking & đánh giá đến production & serving. Tất cả trả lời một câu hỏi: "Sản phẩm nào phù hợp với khách này?".

Nhưng trong ngân hàng, câu hỏi thực tế rộng hơn: "Với khách hàng này, ngay lúc này, trên kênh này — hành động tốt nhất tiếp theo là gì?". Đó có thể là chào một sản phẩm, nhưng cũng có thể là gửi một ưu đãi, nhắc một khoản nợ đến hạn, gợi một tính năng trong app, hay đơn giản là không làm gì cả để tránh làm phiền. Khung tư duy này gọi là Next-Best-Action (NBA) — và nó chính là nơi recommender, phân tích rủi ro, tuân thủ và trải nghiệm khách hàng hội tụ.

Bài này là bài tổng kết ứng dụng của cả series: cách biến engine khuyến nghị thành một hệ NBA có trách nhiệm, đúng quy định, và đo được tác động thật trong bối cảnh NCB.

NBA là gì — và khác recommender thuần túy ra sao

NBA là bài toán chọn một hành động tốt nhất từ tập hành động khả dĩ, cho từng khách, trên từng kênh, tại từng thời điểm. Điểm khác biệt so với recommender sản phẩm thuần túy:

Nói cách khác, recommender là một thành phần của NBA (thường là engine sinh và chấm điểm ứng viên), còn NBA là khung ra quyết định bọc quanh nó: thêm ràng buộc nghiệp vụ, phối hợp kênh, và tối ưu giá trị dài hạn thay vì click ngắn hạn.

Các use case NBA trong ngân hàng

• Cross-sell / up-sell: gợi sản phẩm bổ sung phù hợp — thẻ tín dụng cho khách thu nhập ổn định, gói tiết kiệm cho khách có số dư nhàn rỗi, vay tiêu dùng đúng nhu cầu, bảo hiểm, sản phẩm đầu tư. Nguồn giá trị lớn nhất nhưng rủi ro nhất về suitability.
• Ưu đãi cá nhân hoá: chọn ưu đãi đúng khách đúng lúc (miễn phí thường niên thẻ, ưu đãi lãi suất) thay vì rải đại trà — tiết kiệm ngân sách, tăng tỉ lệ dùng.
• Giữ chân (retention): khách có tín hiệu rủi ro rời bỏ (giảm giao dịch, rút số dư, mở tài khoản bên khác) → NBA đề xuất retention offer phù hợp. Đây là chỗ NBA nối recommender với predictive analytics: mô hình churn xác định ai rủi ro (xem pa-05, loyalty-06), recommender xác định đề xuất gì.
• Kích hoạt / onboarding: khách mới mở tài khoản nhưng chưa dùng → chuỗi hành động dẫn dắt (nạp tiền lần đầu, kích hoạt thẻ, thiết lập chuyển lương).
• Gợi ý tính năng app: nhắc dùng tính năng chưa khám phá (đặt lịch thanh toán, sổ tiết kiệm online) — tăng gắn kết mà không đụng tới bán chéo.
• Nội dung giáo dục tài chính: bài viết/mẹo phù hợp hành vi (quản lý chi tiêu, cảnh báo lừa đảo) — xây niềm tin, đặc biệt hiệu quả với khách trẻ hoặc mới.

Điểm chung: mọi use case đều dùng lại engine candidate + ranking đã xây, chỉ đổi tập hành động và hàm mục tiêu.

Dữ liệu cho NBA

NBA giàu tín hiệu hơn recommender sản phẩm vì nó nhìn toàn cảnh khách hàng:

• Giao dịch: tần suất, giá trị, loại (chuyển khoản, chi tiêu thẻ, nạp/rút), xu hướng theo thời gian — nguồn hành vi mạnh nhất.
• Sản phẩm đang dùng: danh mục sản phẩm hiện có → xác định khoảng trống cross-sell và loại sản phẩm đã sở hữu (không gợi lại).
• Hành vi app: màn hình xem, tính năng dùng, phiên đăng nhập — tín hiệu ý định và mức gắn kết.
• Nhân khẩu học: tuổi, khu vực, phân khúc thu nhập — chủ lực cho cold start và eligibility.
• Vòng đời khách: mới / đang phát triển / trưởng thành / suy giảm — quyết định loại hành động phù hợp.
• Tín hiệu sự kiện (event triggers): lương về, đáo hạn tiết kiệm, số dư vượt ngưỡng, khoản vay sắp hết hạn — các "khoảnh khắc vàng" để hành động đúng lúc.

Các tín hiệu này được kết hợp qua chính các kỹ thuật của series: collaborative filtering bắt "khách giống nhau dùng gì", content/hybrid bắt "sản phẩm giống nhau", feature store (mlops-03) đảm bảo nhất quán offline–online.

Kiến trúc NBA ngân hàng

Kiến trúc NBA kế thừa khung nhiều giai đoạn ở rec-07, nhưng đặt ràng buộc tuân thủ làm tầng bắt buộc, không phải tùy chọn.

Giai đoạn 1 — Candidate: sinh tập hành động khả dĩ cho khách (sản phẩm chưa có, ưu đãi đang chạy, nội dung liên quan, nhắc nhở đến hạn). Đây là chỗ recommender (ANN, co-occurrence, rule) sinh ứng viên sản phẩm, kết hợp candidate từ predictive analytics (khách rủi ro churn → thêm ứng viên retention).

Giai đoạn 2 — Ranking: chấm mỗi hành động theo giá trị kỳ vọng = xác suất chuyển đổi × giá trị nếu chuyển đổi. Với ngân hàng, giá trị nên là dài hạn (CLV, số dư kỳ vọng, biên lợi nhuận), không chỉ "một hợp đồng". Lý tưởng hơn nữa là chấm theo uplift (mục dưới) thay vì xác suất tuyệt đối.

Giai đoạn 3 — Re-rank theo ràng buộc: đây là phần khiến NBA ngân hàng khác biệt căn bản.

Bản thân bước sinh candidate thường bắt đầu từ một truy vấn đơn giản: "khách giá trị cao nhưng chưa dùng loại giao dịch/sản phẩm X" → ứng viên cross-sell. Ví dụ minh hoạ trên sandbox, tìm top khách theo tổng số dư nhưng chưa từng có giao dịch loại 'invest' (proxy cho "chưa dùng sản phẩm đầu tư") — đây chính là danh sách ứng viên cross-sell đầu vào cho tầng ranking:

-- ▶ Chạy được
SELECT c.id, c.full_name, c.city,
       SUM(a.balance) AS total_balance,
       COUNT(t.id)    AS tx_count
FROM customers c
JOIN accounts a       ON a.customer_id = c.id
LEFT JOIN transactions t ON t.account_id = a.id
WHERE c.id NOT IN (
        SELECT a2.customer_id
        FROM accounts a2
        JOIN transactions t2 ON t2.account_id = a2.id
        WHERE t2.kind = 'invest'
      )
GROUP BY c.id, c.full_name, c.city
ORDER BY total_balance DESC
LIMIT 20;

Truy vấn dùng đúng 3 bảng customers/accounts/transactions với khoá join chuẩn (transactions.account_id → accounts.id, accounts.customer_id → customers.id), loại các khách đã có giao dịch 'invest', rồi xếp theo tổng số dư. Trong thực tế, danh sách này còn phải đi qua tầng suitability trước khi được chào.

Ràng buộc & trách nhiệm đặc thù ngân hàng

Đây là phần quan trọng nhất của bài. Trong thương mại điện tử, một gợi ý sai chỉ tốn một lượt hiển thị. Trong ngân hàng, một gợi ý sai có thể đẩy khách vào khoản nợ không trả nổi, vi phạm quy định, hoặc phá vỡ niềm tin. NBA ngân hàng phải đặt các ràng buộc sau trên cả doanh thu:

• Tuân thủ & phù hợp (suitability) — ràng buộc số một. Không chào sản phẩm không phù hợp với năng lực tài chính và khẩu vị rủi ro của khách. Ví dụ điển hình: đẩy khoản vay lớn cho người có tỉ lệ nợ/thu nhập (DTI) đã cao, hoặc chào sản phẩm đầu tư rủi ro cho khách bảo thủ/ít hiểu biết. Suitability là hard filter dựa trên eligibility (KYC, tuổi, thu nhập) và đánh giá khả năng chi trả — liên quan chặt chấm điểm tín dụng (credit-03).
• Không lạm dụng / dark pattern: không dùng thiết kế đánh lừa để khách đăng ký thứ không cần. NBA tối ưu cho quyết định tốt của khách, không phải cho việc "chốt" bằng mọi giá.
• Không spam (fatigue/frequency cap): giới hạn số lần tiếp xúc mỗi khách mỗi tuần, tránh nhồi cùng một chào bán. "Không hành động" phải là lựa chọn hợp lệ khi mọi ứng viên đều yếu.
• Quyền riêng tư dữ liệu: xử lý dữ liệu cá nhân theo Nghị định 13 (NĐ13) về bảo vệ dữ liệu cá nhân — cơ sở pháp lý, mục đích, quyền của khách. Xem gov-07.
• Công bằng (fairness): không để hệ thống phân biệt đối xử theo giới, khu vực, nhóm nhạy cảm — dù trực tiếp hay gián tiếp qua biến ủy nhiệm (proxy). Cần đo chênh lệch tỉ lệ chào bán/phê duyệt giữa các nhóm.
• Minh bạch & giải thích được: cán bộ và (khi cần) khách phải hiểu vì sao một hành động được đề xuất. Mô hình quá hộp đen khó kiểm toán tuân thủ.
• Ưu tiên lợi ích khách: mục tiêu tối ưu phải cân cả lợi ích khách, không chỉ doanh thu ngân hàng. Một gợi ý tăng doanh thu ngắn hạn nhưng hại khách sẽ làm tăng khiếu nại, opt-out và rủi ro pháp lý dài hạn.

# Minh hoạ (KHÔNG phải SQL chạy được) — re-rank NBA với ràng buộc ngân hàng
def next_best_action(customer, scored_actions):
    acts = [a for a in scored_actions if is_eligible(customer, a)]      # KYC, tuổi, quy định
    acts = [a for a in acts if is_suitable(customer, a)]                # khả năng chi trả, khẩu vị rủi ro
    acts = [a for a in acts if not already_has(customer, a)]
    acts = [a for a in acts if within_frequency_cap(customer, a)]       # chống spam/fatigue
    acts = apply_fairness_guardrail(customer, acts)                     # kiểm soát chênh lệch nhóm
    if not acts or best_score(acts) < ACTION_THRESHOLD:
        return NO_ACTION                                               # không hành động là hợp lệ
    return pick_channel(customer, acts[0])                              # điều phối kênh phù hợp

Thứ tự bắt buộc: eligibility & suitability chạy trước mọi tối ưu doanh thu. Không bao giờ để một quy tắc tăng conversion đẩy một hành động không phù hợp lọt ra ngoài.

Đo lường: uplift chứ không chỉ conversion

Sai lầm phổ biến nhất khi đánh giá NBA: đo conversion tuyệt đối trên nhóm được chào. Vấn đề — nhiều khách đăng ký dù có được chào hay không. Chào những khách này tốn ngân sách và làm phiền mà không tạo giá trị tăng thêm; tệ hơn, một số khách bị chào lại phản tác dụng (khó chịu, opt-out).

Câu hỏi đúng là uplift (tác động nhân quả thật): "Hành động này làm THAY ĐỔI hành vi khách bao nhiêu so với không hành động?". Bốn nhóm khách theo tư duy uplift:

NBA tối ưu nên nhắm persuadables — những người thực sự thay đổi hành vi nhờ hành động. Cách đo tác động thật là thử nghiệm ngẫu nhiên có nhóm đối chứng (holdout): chia khách theo customer thành nhóm được NBA và nhóm giữ nguyên, so chênh lệch chuyển đổi/giá trị — nền tảng ở A/B testing (stat-07).

Guardrail đi kèm mỗi thử nghiệm: canh khiếu nại, opt-out, đa dạng sản phẩm không xấu đi; đủ thời gian và cỡ mẫu (quyết định tài chính có độ trễ dài — khách cân nhắc vay/đầu tư hàng tuần).

Con người, kênh & vận hành

NBA không phải lúc nào cũng tự động hoá hoàn toàn:

• Điều phối kênh: cùng một hành động có thể tới qua app (self-service, chi phí thấp), RM/tổng đài (giá trị cao, cần tư vấn con người cho sản phẩm phức tạp như đầu tư), SMS/email (nhắc nhở, ưu đãi). NBA chọn cả hành động lẫn kênh & thời điểm, và phối hợp để một khách không bị dồn nhiều kênh cùng lúc.
• Con người trong vòng lặp: với sản phẩm rủi ro cao (vay lớn, đầu tư), NBA nên là gợi ý cho RM kèm lý do, để con người quyết định cuối — vừa tăng suitability vừa dễ giải thích.
• Vận hành: kế thừa toàn bộ rec-07 — batch-hybrid (batch tính điểm hằng đêm + online re-rank ngữ cảnh), feature store, monitoring kỹ thuật lẫn nghiệp vụ, fallback, versioning đồng bộ mô hình/embedding/index. NBA thêm một lớp giám sát riêng: tỉ lệ hành động bị chặn bởi suitability, chênh lệch fairness giữa nhóm, tần suất tiếp xúc trung bình.

Bản đồ toàn series

Tám bài gộp lại thành một lộ trình từ nền tảng đến ứng dụng:

• rec-01 — vì sao khuyến nghị, các họ thuật toán, chỉ số.
• rec-02 & rec-03 — tín hiệu từ hành vi tập thể, embedding tiềm ẩn.
• rec-04 — content & hybrid, giải cold start.
• rec-05 — two-tower, mô hình sâu.
• rec-06 — biến điểm thành thứ hạng, đo NDCG/recall.
• rec-07 — đưa vào production nhiều giai đoạn.
• rec-08 (bài này) — bọc tất cả thành NBA có trách nhiệm cho ngân hàng.

Use case thực tế

Bối cảnh: NCB xây hệ NBA cho ~2 triệu khách bán lẻ, phối hợp 4 kênh (app, RM, SMS, email). Tập hành động ~40 loại: chào sản phẩm, ưu đãi, retention offer, nhắc nhở, gợi tính năng, nội dung giáo dục.

Pipeline chọn:

1. Candidate: mỗi khách sinh ~30 hành động khả dĩ — cross-sell từ recommender (sản phẩm chưa có), retention nếu điểm churn cao, ưu đãi chiến dịch đang chạy, nhắc nhở theo event trigger (tiết kiệm đáo hạn).
2. Ranking: chấm theo giá trị kỳ vọng 90 ngày.
3. Ràng buộc: hard filter eligibility (KYC/tuổi) + suitability (loại chào vay cho khách DTI cao) + loại sản phẩm đã có + frequency cap 2 tiếp xúc/tuần + guardrail fairness. Nếu điểm tốt nhất dưới ngưỡng → NO_ACTION.
4. Kênh: sản phẩm đầu tư/vay lớn → gợi cho RM kèm lý do; ưu đãi đơn giản → app/SMS.

Kết quả (minh hoạ) — thử nghiệm holdout 8 tuần, chia theo customer, đo uplift thay vì conversion tuyệt đối: nhóm NBA có tỉ lệ nhận sản phẩm bổ sung cao hơn nhóm đối chứng 1,8 điểm phần trăm (uplift thật, không phải conversion thô). Khi phân tích 4 nhóm uplift, phát hiện ~25% ngân sách chào bán trước đây rơi vào "sure things" — cắt nhóm này giúp giảm 25% chi phí tiếp xúc mà uplift không đổi. Guardrail: opt-out không tăng, tỉ lệ hành động bị chặn bởi suitability ~9% (bằng chứng filter đang hoạt động, không phải cản trở). Bài học: giá trị lớn nhất đến từ nhắm đúng persuadables và filter suitability đúng, không phải từ mô hình ranking phức tạp hơn.

Ghi nhớ

• NBA = chọn hành động tốt nhất tiếp theo (sản phẩm, ưu đãi, nhắc nhở, nội dung, tính năng — hoặc không hành động) cho từng khách, từng kênh, từng thời điểm. Recommender là một thành phần, NBA là khung ra quyết định bọc quanh.
• Use case chính: cross-sell/up-sell, ưu đãi cá nhân hoá, giữ chân (nối recommender với predictive churn), onboarding/kích hoạt, gợi tính năng, giáo dục tài chính.
• Kiến trúc: candidate → ranking theo giá trị kỳ vọng → re-rank theo ràng buộc → điều phối kênh — kế thừa multi-stage của rec-07.
• Ràng buộc ngân hàng đặt trên doanh thu: suitability (không chào sản phẩm quá khả năng khách), không dark pattern, chống spam, riêng tư (NĐ13), fairness, minh bạch, ưu tiên lợi ích khách. Eligibility & suitability là hard filter chạy TRƯỚC mọi tối ưu.
• Đo uplift/tác động thật bằng thử nghiệm holdout, không đo conversion tuyệt đối; nhắm persuadables, tránh sleeping dogs và "sure things".
• Điều phối đa kênh; sản phẩm rủi ro cao đưa cho con người (RM) quyết định cuối, kèm lý do để giải thích được.
• Series 8 bài: từ nền tảng CF/MF/hybrid/deep → ranking → production → NBA ngân hàng có trách nhiệm là đích đến.