Customer 360 — 6 — Cá nhân hoá thời gian thực

Một khách hàng vừa tra cứu lãi suất vay mua ô tô trên app lúc 21h. Nếu hệ thống chờ batch chấm điểm chạy lúc 2h sáng, dựng danh sách khách tiềm năng, đẩy sang CRM, rồi RM gọi lại sau hai ngày — thì khoảnh khắc quan tâm đã nguội. Ngược lại, nếu ngay trong phiên đó app hiện một banner "Gói vay mua xe ưu đãi, lãi suất từ X%/năm, tính thử khoản trả góp" thì xác suất chuyển đổi cao hơn nhiều. Sự khác biệt không nằm ở mô hình mà nằm ở thời điểm.

Ở Next Best Action, chúng ta đã chọn được hành động tốt nhất tiếp theo cho mỗi khách. Bài này trả lời câu hỏi kế: làm sao đưa hành động đó tới khách đúng lúc ngữ cảnh còn nóng — cá nhân hoá theo thời gian thực (real-time) thay vì theo lô hằng đêm. Ta đi từ vì sao realtime → kiến trúc streaming → feature store → ra quyết định độ trễ thấp → trigger theo hành trình → thách thức → và điểm chung với rủi ro/gian lận.

1. Vì sao cần thời gian thực?

Giá trị của một gợi ý phân rã theo thời gian. Cùng một thông điệp, gửi ngay lúc khách bộc lộ nhu cầu thì đáng giá; gửi hôm sau thì gần như vô nghĩa. Ba loại khoảnkhắc (moment) tạo giá trị lớn nhất khi phản hồi tức thì:

• Khoảnh khắc có tiền: lương vừa về tài khoản → gợi ý gửi tiết kiệm gửi góp, hoặc nhắc thanh toán dư nợ thẻ. Chờ đến đêm thì tiền có thể đã được rút/chi tiêu hết.
• Khoảnh khắc có nhu cầu: khách đang xem trang vay, tính lãi, so sánh gói → đây là tín hiệu ý định (intent) mạnh nhất, chỉ tồn tại trong vài phút của phiên.
• Khoảnh khắc có rủi ro: một giao dịch bất thường (số tiền lớn, quốc gia lạ, nửa đêm) → phải chặn/xác thực trước khi giao dịch hoàn tất, không thể phát hiện sau 24 giờ.

Điểm mấu chốt: realtime không thay thế batch. Batch vẫn tốt cho việc nặng, tính định kỳ (phân khúc RFM, điểm churn/CLV — xem CLV & churn). Realtime bổ sung một lớp phản ứng theo sự kiện chồng lên nền tảng batch đó.

2. Kiến trúc streaming

Cá nhân hoá thời gian thực là một đường ống sự kiện (event pipeline): mỗi hành vi của khách sinh ra một sự kiện, sự kiện chảy qua hàng đợi, được xử lý để cập nhật đặc trưng, rồi kích hoạt quyết định và gửi ra kênh.

Các thành phần:

• Nguồn sự kiện: app/web phát sự kiện qua SDK; core banking phát sự kiện giao dịch (thường qua CDC — Change Data Capture — đọc log của core, xem Tích hợp dữ liệu).
• Event stream (Kafka): hàng đợi bền, phân vùng, cho phép nhiều consumer đọc song song, tái xử lý (replay) khi cần. Là "xương sống" tách nguồn khỏi bên xử lý.
• Stream processing (Flink / Spark Structured Streaming / Kafka Streams): tính đặc trưng theo cửa sổ (đếm giao dịch 5 phút gần nhất, tổng chi tiêu trong ngày), join sự kiện với hồ sơ, phát hiện mẫu, rồi ghi ra feature store và/hoặc gọi decision engine.
• Decision engine: áp luật kinh doanh + gọi mô hình online để chọn hành động, tôn trọng ràng buộc (consent, tần suất, eligibility).
• Kênh (channel): nơi hành động chạm khách — banner trong app, push, hoặc hành động bảo vệ (chặn, OTP).

Ta bám đúng nguyên tắc của tổng quan Customer 360: mọi thứ quay quanh một hồ sơ khách hàng nhất quán, chỉ khác là nay được cập nhật liên tục thay vì làm mới mỗi đêm.

3. Feature store — trái tim của hệ thống

Feature store là hệ thống quản lý đặc trưng (feature — biến đầu vào cho mô hình, ví dụ "tổng chi tiêu 30 ngày", "số ngày kể từ giao dịch cuối") dùng chung cho toàn tổ chức. Nó giải quyết hai vấn đề kinh điển của ML trong ngân hàng: lặp lại logic và lệch train/serve.

Online store vs offline store

Một feature store thường có hai mặt, cùng định nghĩa đặc trưng nhưng khác kho lưu:

Cùng một đặc trưng "avg_txn_amount_30d" được định nghĩa một lần, tính cho lịch sử để huấn luyện (offline) và tính/cập nhật liên tục để phục vụ (online). Nhờ vậy, mô hình lúc serving thấy đúng loại đặc trưng như lúc training → tránh train/serve skew (lệch huấn luyện–phục vụ), một nguyên nhân phổ biến khiến mô hình "tốt trên giấy, tệ trên thực tế".

Point-in-time correctness

Đây là khái niệm quan trọng và dễ sai nhất. Khi tạo tập huấn luyện, mỗi nhãn (ví dụ "khách có vay trong 7 ngày tới không") gắn với một thời điểm t. Đặc trưng đưa vào mô hình cho hàng đó chỉ được dùng dữ liệu có trước t — không được "nhìn tương lai". Nếu tính "tổng chi tiêu 30 ngày" mà vô tình gộp cả giao dịch sau thời điểm dự đoán, mô hình học được thông tin nó sẽ không có lúc chạy thật → rò rỉ dữ liệu (data leakage), chỉ số offline đẹp giả tạo, sản xuất sụp đổ.

Feature store giải bài này bằng point-in-time join (còn gọi as-of join): với mỗi (entity, timestamp) trong tập nhãn, lấy giá trị đặc trưng hợp lệ tại đúng thời điểm đó. Về bản chất giống chọn bản ghi mới nhất trước hoặc bằng t cho từng khoá — một dạng "as-of" mà dân SQL quen với window function (SQL window).

4. Ra quyết định độ trễ thấp

Khi khách mở app, backend cần trả lời "hiện gì cho người này?" trong một ngân sách độ trễ (latency budget) rất hẹp — thường vài chục mili giây để không làm chậm giao diện. Chuỗi xảy ra:

1. Nhận sự kiện/yêu cầu (khách mở màn hình chính).
2. Tra cứu hồ sơ 360 đã cache + đặc trưng từ online store (KV, ~1–5 ms).
3. Decision engine áp luật loại trừ (đang nợ xấu thì không mời vay thêm; đã từ chối offer này thì ẩn), rồi model online chấm điểm các hành động ứng viên.
4. Chọn hành động điểm cao nhất còn đủ điều kiện và đúng consent (Quyền riêng tư & consent).
5. Trả về kênh; ghi log quyết định (impression) để đo lường và học tiếp.

Vài kỹ thuật để giữ độ trễ:

• Tính trước (precompute) đặc trưng nặng trong stream, chỉ tra cứu lúc phục vụ — không tính toán nặng trên đường nóng (hot path).
• Cache hồ sơ 360: giữ bản tóm tắt khách (phân khúc, sản phẩm sở hữu, cờ eligibility) trong KV store để đọc tức thì.
• Tách luật khỏi mô hình: luật cứng (regulatory, eligibility) chạy trước và rẻ; mô hình chỉ xếp hạng phần còn lại.
• Degrade an toàn: nếu model/feature store timeout, rơi về đề xuất theo phân khúc (kết quả batch) thay vì lỗi trắng màn hình.

Decision engine thường kết hợp rule engine (dễ kiểm soát, audit được — rất quan trọng với ngân hàng) và model (bắt tín hiệu tinh vi). Luật đóng vai "hàng rào an toàn", model đóng vai "tối ưu trong hàng rào đó".

5. Trigger theo sự kiện & hành trình (journey orchestration)

Ngoài "khách mở app thì hiện gì", realtime còn cho phép kích hoạt chủ động theo sự kiện: nếu X xảy ra → làm Y. Đây là nền của journey orchestration — điều phối hành trình khách hàng qua nhiều bước, nhiều kênh, có điều kiện và độ trễ.

Ví dụ kịch bản (minh hoạ):

Journey khác một trigger đơn lẻ ở chỗ nó có trạng thái: chờ khách phản hồi, rẽ nhánh theo hành vi, đặt cửa sổ yên tĩnh (không làm phiền ngoài giờ), giới hạn tần suất (frequency capping) để tránh spam. Stream processing với stateful processing (Flink giữ state theo khoá khách) rất hợp cho việc này.

6. Thách thức & lộ trình thực tế

Realtime hấp dẫn nhưng đắt và khó vận hành. Các đánh đổi chính:

• Độ trễ vs độ chính xác: tính nhiều đặc trưng hơn → chậm hơn. Phải chọn tập đặc trưng "đủ tốt" trong ngân sách.
• Nhất quán dữ liệu: online store và offline store có thể lệch (một cái cập nhật, cái kia chưa). Cần theo dõi độ trễ đồng bộ và độ lệch giá trị giữa hai kho.
• Chi phí hạ tầng: Kafka + Flink + KV store luôn bật, đội ngũ vận hành 24/7, giám sát nghiêm ngặt. Không rẻ như một job batch.
• Giám sát (observability): phải theo dõi độ trễ end-to-end, tỉ lệ lỗi, feature freshness (đặc trưng có cũ không), drift của model.
• Đúng đắn nghiệp vụ: offer sai thời điểm còn tệ hơn không offer; cần A/B test và guardrail chặt.

Lời khuyên thực dụng: bắt đầu từ near-real-time (độ trễ vài phút, micro-batch) khi bài toán chưa đòi hỏi realtime tuyệt đối. Rất nhiều use case cá nhân hoá chấp nhận trễ 1–5 phút mà vẫn "đủ nóng", trong khi hạ tầng đơn giản hơn nhiều. Chỉ đẩy xuống mili giây cho phần bắt buộc — điển hình là chống gian lận, nơi quyết định phải xảy ra trong lúc giao dịch chạy.

Dùng chung hạ tầng với rủi ro/gian lận

Điều đáng giá: đường ống streaming cho cá nhân hoá gần như trùng với đường ống cho phát hiện gian lận thời gian thực. Cùng sự kiện giao dịch, cùng feature store (velocity, độ lệch so với hành vi thường ngày), cùng decision engine — chỉ khác chính sách: một bên chọn offer, một bên chọn chặn/xác thực. Nhiều ngân hàng xây một nền tảng quyết định thời gian thực dùng chung, phục vụ cả marketing lẫn phòng chống rủi ro (xem AML/Fraud — tổng quan). Đây là lý do đầu tư hạ tầng realtime dễ được duyệt hơn khi gộp cả hai bài toán.

7. Ví dụ: luồng sự kiện → đặc trưng → quyết định

Pseudocode một handler stream (minh hoạ, không phải API thật):

# Stream processor: mỗi sự kiện của khách
def on_event(event):
    cid = event.customer_id

    # 1) Cập nhật đặc trưng theo cửa sổ vào ONLINE store
    if event.type == "transaction":
        online_store.incr(cid, "txn_count_5m", ttl="5m")
        online_store.add(cid, "spend_1d", event.amount, ttl="1d")

    # 2) Chỉ ra quyết định với sự kiện "ý định" hoặc "rủi ro"
    if event.type in ("view_loan_page", "transaction"):
        feats   = online_store.get(cid)             # ~vài ms
        profile = profile_cache.get(cid)            # hồ sơ 360 cache

        # 3) Luật cứng trước (eligibility, consent, tần suất)
        if not eligible(profile) or not has_consent(profile, "marketing"):
            return
        if frequency_capped(cid):
            return

        # 4) Model online xếp hạng hành động ứng viên
        action = decision_engine.best_action(profile, feats, event)

        # 5) Gửi kênh + log để đo lường
        if action and action.score >= THRESHOLD:
            channel.deliver(cid, action)
            emit_impression(cid, action)            # quay lại stream để học

Phần đặc trưng offline để huấn luyện thì tính bằng SQL trên lakehouse/kho lịch sử. Dưới đây là một đặc trưng dạng hành vi chi tiêu gần đây per khách hàng — chạy được trên sandbox PostgreSQL (chỉ đọc):

-- ▶ Chạy được
SELECT
  c.id                                   AS customer_id,
  c.full_name,
  COUNT(t.id)                            AS txn_count_30d,
  ROUND(COALESCE(SUM(t.amount), 0)::numeric, 2) AS spend_30d,
  ROUND(COALESCE(AVG(t.amount), 0)::numeric, 2) AS avg_txn_30d,
  MAX(t.created_at)                      AS last_txn_at
FROM customers c
JOIN accounts a     ON a.customer_id = c.id
LEFT JOIN transactions t
       ON t.account_id = a.id
      AND t.created_at >= NOW() - INTERVAL '30 days'
GROUP BY c.id, c.full_name
ORDER BY spend_30d DESC;

Đặc trưng như txn_count_30d, avg_txn_30d, last_txn_at chính là loại biến mà stream processor cập nhật liên tục ở phiên bản online; định nghĩa phải khớp giữa hai bên để tránh train/serve skew. Một tín hiệu "velocity" bất thường — ví dụ số giao dịch trong 5 phút vượt xa trung bình 30 ngày — vừa dùng để gợi ý, vừa dùng để cảnh báo gian lận.

Use case thực tế

Bối cảnh NCB. NCB muốn tăng chuyển đổi tín dụng cá nhân và giảm gian lận thẻ, tận dụng cùng một hạ tầng streaming. Hai luồng cùng chạy trên một event bus.

Luồng A — gợi ý vay trong phiên. Khách đăng nhập app và vào màn hình "Vay tiêu dùng", xem bảng lãi suất, bấm "tính thử khoản trả góp" hai lần trong 3 phút. Các sự kiện view_loan_page chảy qua Kafka → Flink dựng đặc trưng phiên (số lần xem, thời lượng) và join với hồ sơ 360 cache (điểm tín dụng nội bộ, thu nhập ước tính, cờ "không nợ xấu"). Decision engine kiểm luật eligibility, thấy đủ điều kiện và có consent marketing → chọn gói vay tín chấp phù hợp và hiển thị banner cá nhân hoá ngay trong phiên, kèm hạn mức gợi ý và nút đăng ký. Toàn bộ trong ngân sách ~50 ms để không giật màn hình.

Luồng B — cảnh báo giao dịch lạ. Cùng khách, tối đó phát sinh giao dịch thẻ giá trị lớn tại kênh lạ. Sự kiện transaction đi qua stream, feature store trả về velocity (số giao dịch 5 phút) và độ lệch so với chi tiêu trung bình 30 ngày. Decision engine dùng chính sách rủi ro thay vì marketing → yêu cầu xác thực OTP trước khi cho hoàn tất, thay vì đề xuất sản phẩm.

Số liệu ước lượng (minh hoạ, không phải số công bố):

Lộ trình. NCB bắt đầu ở near-real-time (micro-batch 2–3 phút) cho phần gợi ý — đủ nóng, hạ tầng đơn giản — và chỉ đẩy xuống mili giây cho luồng chống gian lận, nơi độ trễ là bắt buộc. Sau khi ổn định, phần gợi ý mới nâng dần lên realtime trong phiên.

Ghi nhớ

• Đúng thông điệp, đúng lúc: giá trị của gợi ý phân rã theo thời gian; realtime thắng batch ở các khoảnh khắc có tiền / có nhu cầu / có rủi ro.
• Realtime bổ sung, không thay thế batch: batch lo việc nặng định kỳ (phân khúc, churn/CLV); realtime lo phản ứng theo sự kiện chồng lên đó.
• Kiến trúc: sự kiện → Kafka → stream processing (Flink) → feature store → decision engine → kênh; core banking đưa sự kiện qua CDC.
• Feature store là trái tim: định nghĩa đặc trưng một lần, phục vụ cả offline (huấn luyện) và online (serving mili giây) → tránh train/serve skew.
• Point-in-time correctness: chỉ dùng dữ liệu trước thời điểm dự đoán; sai sẽ rò rỉ dữ liệu, đẹp offline mà sập production.
• Độ trễ thấp: precompute đặc trưng, cache hồ sơ 360, tách luật khỏi model, và degrade an toàn về đề xuất theo phân khúc khi timeout.
• Trigger & journey: nếu X → làm Y, có trạng thái, rẽ nhánh, cửa sổ yên tĩnh và frequency capping để không spam.
• Bắt đầu near-real-time khi chưa cần mili giây; chỉ realtime tuyệt đối cho phần bắt buộc — điển hình là chống gian lận.
• Dùng chung hạ tầng cho cá nhân hoá và phát hiện gian lận: cùng stream, cùng feature store, chỉ khác chính sách quyết định (xem AML/Fraud).

Nguồn tham khảo

• Apache Kafka Documentation — event streaming, partitions, consumer groups, replay.
• Apache Flink Documentation — stateful stream processing, windowing, event time.
• Spark Structured Streaming Programming Guide — micro-batch / near-real-time processing.
• Feast — Feature Store Documentation — online/offline store, point-in-time joins, feature serving.
• Redis Documentation — KV store độ trễ thấp cho online feature store / cache hồ sơ.
• Debezium Documentation — Change Data Capture (CDC) từ core banking sang stream.