Gợi ý sản phẩm AI: đừng chỉ luyện model

Gợi ý sản phẩm AI: đừng chỉ luyện model

Một playbook mổ xẻ hệ thống recommendation có explainability: chọn kiến trúc, log, dashboard và đường triển khai trước khi khoe model.

“Nếu model gợi ý khách vay thêm tiền sai thời điểm, ai chịu trách nhiệm?”

Câu hỏi này nghe hơi gắt, nhưng với team đang build hệ thống next-best-product — gợi ý sản phẩm tiếp theo phù hợp cho khách hàng — nó là câu hỏi phải hỏi trước khi mở notebook. Không phải sau demo. Không phải lúc compliance gõ cửa. Và càng không phải khi dashboard conversion đang đỏ như đèn cảnh báo.

Luận điểm của mình hôm nay: recommendation trong ngân hàng không chỉ là bài toán xếp hạng; nó là một pipeline quyết định có thể giải thích, kiểm soát và bị truy vết. Nếu bạn chỉ chăm chăm chọn model mới, bạn đang vào dojo với đai trắng mà tưởng mình đã đai đen.

Sơ đồ minh họa cho bài Gợi ý sản phẩm AI: đừng chỉ luyện model

Sơ đồ tóm tắt ý chính của bài viết.

Mục tiêu thật: gợi ý được, giải thích được, rollback được

Một hệ thống gợi ý sản phẩm nghe đơn giản: lấy dữ liệu khách hàng, chạy model, trả về sản phẩm nên đề xuất. Nhưng khi đưa vào môi trường tài chính, câu hỏi đổi hẳn:

Nói thẳng ra thì, hệ thống này cần thế thủ vận hành trước khi cần cú đá model đẹp.

Bài AWS về kiến trúc next-best-product dùng SageMaker AI và PyTorch có một điểm đáng giữ: họ không chỉ nói về model, mà nhấn mạnh kiến trúc nhiều lớp dữ liệu, multi-tower neural network — mạng nhiều nhánh xử lý từng nhóm tín hiệu khác nhau — và attention — cơ chế giúp model cho biết phần tín hiệu nào đang được chú ý hơn trong dự đoán. Với builder, phần đáng học không phải là bê nguyên stack AWS, mà là cách tách hệ thống thành các quyết định có thể kiểm soát.

Checklist trước khi viết dòng training đầu tiên

Trước khi team bạn mở SageMaker, notebook, hoặc repo PyTorch, hãy trả lời 7 câu này. Không cần hoàn hảo, nhưng phải có chủ sở hữu rõ ràng.

| Câu hỏi | Nếu chưa trả lời, rủi ro là gì? |
|---|---|
| Gợi ý phục vụ mục tiêu nào: bán chéo, giữ chân, hay hỗ trợ tư vấn? | Model tối ưu nhầm metric |
| Sản phẩm nào được phép gợi ý cho từng nhóm khách? | Đề xuất vi phạm policy |
| Feature nào bị cấm dùng trực tiếp hoặc gián tiếp? | Rủi ro bias và compliance |
| Giải thích cần phục vụ ai: RM, compliance, hay khách hàng? | Explainability sai độ sâu |
| Có baseline rule-based để so sánh chưa? | Không biết model có đáng triển khai không |
| Có log quyết định ở mức từng khách chưa? | Không audit được khi có sự cố |
| Có cơ chế rollback theo sản phẩm/segment không? | Tắt hệ thống kiểu rút cầu dao |

Ví dụ cụ thể: giả sử team bạn 5 người ở một ngân hàng số nhỏ, đang muốn gợi ý “mở tài khoản tiết kiệm”, “nâng hạn mức thẻ”, hoặc “mua bảo hiểm”. Nếu chỉ train model dựa trên lịch sử mua sản phẩm, model có thể học lại hành vi cũ của đội sales thay vì nhu cầu thật của khách. Khách từng được gọi nhiều thì lại tiếp tục được gợi ý nhiều. Đó không phải personalization; đó là vòng lặp khuếch đại lịch sử.

Mổ hệ thống thành 5 lớp quyết định

Đây là khung mình sẽ dùng nếu phải review một hệ thống next-best-product trong một buổi chiều. Không phải checklist trang trí; mỗi lớp tương ứng với một kiểu lỗi production khác nhau.

1. Lớp dữ liệu: không gom tất cả vào một nồi feature

Dữ liệu ngân hàng thường không đồng chất: giao dịch, nhân khẩu học, sản phẩm đang sở hữu, hành vi app, lịch sử campaign, tương tác với nhân viên tư vấn. Kiến trúc multi-tower hữu ích vì mỗi nhóm tín hiệu đi qua một nhánh riêng trước khi hợp lại.

Dịch sang việc build: đừng vội tạo một bảng feature khổng lồ rồi ném vào model. Hãy tách schema theo nguồn và nhịp cập nhật:

customer_profile:
  refresh: daily
  owner: data_platform
  pii_level: high

transaction_behavior:
  refresh: hourly
  owner: core_banking_data
  pii_level: high

product_ownership:
  refresh: daily
  owner: product_analytics
  pii_level: medium

campaign_response:
  refresh: per_campaign
  owner: growth_team
  pii_level: medium

Cái bạn cần không chỉ là feature tốt, mà là feature lineage — dấu vết feature đến từ đâu và được biến đổi thế nào. Không có lineage, explainability chỉ là tấm poster treo phòng họp.

2. Lớp model: chọn kiến trúc theo câu hỏi audit

Một model xếp hạng sản phẩm có thể dùng collaborative filtering, gradient boosting, neural network, hoặc hybrid. Nhưng trong môi trường cần giải thích, tiêu chí chọn không chỉ là accuracy.

Hãy hỏi: “Khi model gợi ý sản phẩm X, mình có thể nói lý do ở cấp nào?”

Attention có thể giúp hiển thị phần tín hiệu model đang đặt trọng số cao hơn, nhưng đừng nhầm nó với lời giải thích tuyệt đối. Nó giống đối luyện trong dojo: cho bạn thấy hướng ra đòn, không chứng minh toàn bộ ý đồ của võ sĩ.

3. Lớp serving: recommendation không nên đi thẳng ra production

Serving là cách model được gọi để trả kết quả trong sản phẩm thật. Với next-best-product, đừng chỉ dựng endpoint rồi cho app gọi trực tiếp.

Một flow an toàn hơn:

Request khách hàng
  -> kiểm tra consent và eligibility
  -> lấy feature online/offline
  -> gọi model ranking
  -> áp business rules
  -> tạo explanation
  -> log decision
  -> trả top-N recommendation

Hai điểm hay bị bỏ qua:

Nếu thiếu log này, khi RM hỏi “sao khách VIP lại bị gợi ý sản phẩm cơ bản?”, team chỉ còn cách mở notebook cầu may.

4. Lớp quan sát: dashboard phải kể được khác biệt vùng, nhóm, sản phẩm

Nguồn về visualization đa vùng bằng Highcharts trong QuickSight nhắc một bài học rộng hơn: dashboard mặc định thường không đủ khi dữ liệu có cấu trúc khác nhau. Với recommendation, cùng một metric ở hai segment có thể nói hai câu chuyện khác nhau.

Đừng chỉ theo dõi CTR tổng. Hãy chia ít nhất theo:

Observability — khả năng quan sát hệ thống khi chạy thật — ở đây không chỉ là latency và lỗi 500. Nó còn là drift, tức dữ liệu hoặc hành vi người dùng lệch dần so với lúc train; và outcome lag, tức kết quả kinh doanh đến muộn hơn thời điểm gợi ý.

5. Lớp trải nghiệm: explanation phải vừa đủ cho người dùng cuối

Nguồn GitHub về canvas gợi ý một hướng đáng chú ý: trải nghiệm tương tác giúp người dùng hiểu và điều chỉnh kết quả tốt hơn. Với hệ thống gợi ý sản phẩm, explanation không nên là một đoạn văn dài kiểu model tự biện hộ.

Tùy người xem:

Một explanation tốt không cần khoe thuật toán. Nó cần giúp người nhận quyết định bước tiếp theo.

Làm trong một buổi chiều: bản nháp triển khai có kiểm soát

Nếu team bạn đang ở giai đoạn thiết kế, đây là bài tập 4 giờ đủ thực dụng:

Giờ 1: vẽ decision flow

Viết một sơ đồ từ request đến recommendation. Đánh dấu chỗ nào là model, chỗ nào là rule, chỗ nào là log.

Giờ 2: định nghĩa reason code

Tạo danh sách 10-20 mã lý do gợi ý. Ví dụ:

CASHFLOW_STABLE
NO_SIMILAR_PRODUCT
RECENT_SALARY_INCREASE
HIGH_APP_ENGAGEMENT
ELIGIBILITY_LIMIT_REACHED
POLICY_BLOCKED

Reason code không cần hoàn hảo từ đầu, nhưng phải ổn định đủ để dashboard và audit dùng được.

Giờ 3: thiết kế bảng log

Tối thiểu nên có:

recommendation_id
customer_id_hash
request_time
model_version
rule_version
candidate_products
ranked_products
blocked_products
reason_codes
channel
served_or_not

Lưu ý customer_id_hash: dùng định danh đã băm thay vì phơi dữ liệu cá nhân trong log phân tích.

Giờ 4: chọn chế độ rollout

Đừng mở toàn bộ. Chọn một trong ba:

| Chế độ | Dùng khi nào |
|---|---|
| Shadow mode — chạy ngầm, chưa hiển thị | Muốn so model với rule hiện tại |
| Advisor assist — gợi ý cho nhân viên duyệt | Cần human review trước khi chạm khách |
| Limited exposure — mở cho nhóm nhỏ | Đã có log, dashboard, rollback |

Nếu là mình, mình sẽ bắt đầu bằng shadow mode ít nhất qua vài chu kỳ campaign. Không phải vì sợ AI, mà vì production là nơi mọi giả định bị đánh thử như lên sàn đối luyện.

Những bẫy dễ làm hệ thống trông giỏi nhưng khó sống lâu

Bẫy 1: lấy conversion làm metric duy nhất. Conversion cao có thể đến từ việc gợi ý sản phẩm dễ bán, không phải sản phẩm phù hợp. Cần thêm guardrail metric như complaint, opt-out, rejection reason, hoặc manual override.

Bẫy 2: explanation sinh bằng LLM nhưng không nối với quyết định thật. Nếu phần giải thích được viết sau bằng prompt, nhưng không dựa trên feature/model/rule log, nó có thể nói hay mà sai. Explanation nên được tạo từ decision trace trước, văn phong chỉ là lớp cuối.

Bẫy 3: dashboard trung bình che lỗi cục bộ. Tổng thể ổn không có nghĩa từng nhóm khách ổn. Bài toán đa vùng trong visualization cũng vậy: cấu trúc thị trường khác nhau thì một biểu đồ trung bình dễ làm mất tín hiệu.

Bẫy 4: coi OCR, RAG, hoặc LLM là đường tắt cho dữ liệu bẩn. Pipeline OCR cho tài liệu phức tạp có thể hữu ích khi dữ liệu nằm trong PDF hoặc ảnh scan, nhưng recommendation vẫn cần schema, kiểm tra chất lượng và quyền truy cập. Model đọc được tài liệu không đồng nghĩa dữ liệu đã sẵn sàng cho quyết định tài chính.

Sau bài này, nên nghĩ khác điều gì?

Đừng hỏi “model nào gợi ý tốt nhất?” đầu tiên. Hãy hỏi: “kiến trúc nào giúp team chịu trách nhiệm được với từng gợi ý?”

Khi nhìn như vậy, multi-tower, attention, dashboard, OCR, canvas, hay LLM đều trở thành công cụ trong một hệ thống lớn hơn. Cái đáng triển khai không phải là model biết đoán khách muốn gì, mà là pipeline biết nói vì sao nó đoán như vậy, ai được phép dùng kết quả đó, và khi nào phải dừng lại.

Trong dojo production AI, cú ra đòn đẹp chỉ được tính điểm nếu bạn còn đứng vững sau khi bị audit quật lại.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo