Tối ưu hoá 8 — Ra quyết định tối ưu trong ngân hàng

Từ "hiểu số liệu" đến "quyết định số liệu"

Suốt series này ta đã đi qua công cụ: tổng quan tối ưu hoá, quy hoạch tuyến tính LP, quy hoạch nguyên & MILP, solver và công cụ, danh mục & ALM, mạng lưới & lập lịch, và tối ưu ngẫu nhiên & bền vững. Đó là cách giải các lớp bài toán.

Bài này tổng kết, gộp mọi thứ quanh câu hỏi thực của ngân hàng — ra một quyết định tốt hơn, tự động hơn, tái lập được hơn. Analytics có ba tầng: descriptive (đã xảy ra gì), predictive (sẽ xảy ra gì), prescriptive (nên làm gì). Tối ưu hoá là trái tim của tầng prescriptive — khó nhất, giá trị lớn nhất. Ta sẽ (1) lập bản đồ các bài toán tối ưu ngân hàng, (2) nối ML dự báo với tối ưu (predict-then-optimize), (3) bàn cách đưa vào sản xuất, (4) điểm mặt các cạm bẫy khiến nghiệm "tối ưu trên giấy" thành thảm hoạ thực tế.

1. Bản đồ bài toán tối ưu ngân hàng

Gần như mọi quyết định phân bổ nguồn lực khan hiếm trong ngân hàng đều là một bài toán tối ưu. Bảng dưới ánh xạ bài toán nghiệp vụ → lớp mô hình → phương pháp và bài trong series:

Điểm chung của tất cả: một hàm mục tiêu (tối đa lợi nhuận / thu hồi, tối thiểu chi phí / rủi ro), các ràng buộc (ngân sách, năng lực, tuân thủ, tối thiểu dịch vụ), và biến quyết định. Nhận ra khuôn mẫu này là nửa đường tới lời giải.

Ví dụ thu hồi nợ là knapsack kinh điển: đội thu hồi có T giờ-người/tuần, mỗi hồ sơ i tốn c_i giờ để xử lý và mang lại thu hồi kỳ vọng r_i (do mô hình dự báo). Chọn tập hồ sơ tối đa Σ r_i·x_i sao cho Σ c_i·x_i ≤ T, x_i ∈ {0,1}. Thêm ràng buộc kênh (gọi/SMS/thăm) và phân khúc là ra MILP đầy đủ.

2. Predict-then-optimize: nối ML với tối ưu

Đây là kiến trúc trung tâm của prescriptive analytics hiện đại. Mô hình tối ưu cần các hệ số — nhu cầu rút tiền ATM ngày mai, xác suất phản hồi chiến dịch, xác suất thu hồi được nợ, PD/LGD của khoản vay. Những con số đó không có sẵn: chúng là dự báo từ mô hình ML.

Luồng: dữ liệu → ML dự báo → dùng dự báo làm input → tối ưu → quyết định → thực thi → thu kết quả → học lại. Đây là vòng lặp khép kín.

Cảnh báo sai số ước lượng. Điểm chí tử của predict-then-optimize là: dự báo sai, và tối ưu hoá khuếch đại cái sai đó. Solver tin tuyệt đối vào hệ số bạn đưa vào — nếu mô hình phóng đại thu hồi của một nhóm hồ sơ, solver sẽ dồn hết nguồn lực vào nhóm đó. Vài hệ quả cần nhớ:

• Sai số không đều nhau về hậu quả. Dự báo sai ở biến mà nghiệm nhạy cảm (gần biên ràng buộc) nguy hiểm hơn nhiều so với biến "an toàn". Đo độ nhạy nghiệm (shadow price, sensitivity) để biết chỗ nào cần dự báo chính xác.
• Decision-focused learning. Xu hướng mới: huấn luyện mô hình ML để tối thiểu sai lệch của quyết định cuối, không phải sai lệch dự báo (MAE/MSE). Một dự báo có RMSE tốt hơn có thể cho quyết định tệ hơn nếu nó sai đúng chỗ hiểm. Cách tiếp cận "smart predict-then-optimize" (SPO) tối ưu trực tiếp cho chất lượng quyết định.
• Truyền độ bất định vào mô hình thay vì chỉ điểm ước lượng: dùng khoảng dự báo → mô hình stochastic/robust (bài 7). Nghiệm bền vững với sai số dự báo thường tốt hơn nghiệm tối ưu với một dự báo điểm.

Về nền tảng thống kê của bước dự báo, xem hồi quy & tương quan và đưa mô hình dự báo vào sản xuất.

3. Chuẩn bị dữ liệu quyết định bằng SQL

Trước khi solver chạy, ta phải tổng hợp dữ liệu thành hệ số. Hai truy vấn dưới minh hoạ bước này trên sandbox — chúng feed thẳng vào bài toán phân bổ.

(a) Xếp hạng khách theo giá trị vs chi phí phục vụ — để ưu tiên nguồn lực (chăm sóc, thu hồi, upsell). Đây là bước "predict" đơn giản bằng dữ liệu quá khứ; thực tế thay bằng điểm mô hình:

-- ▶ Chạy được
WITH gt AS (
  SELECT
    a.customer_id,
    SUM(a.balance)                                       AS tong_so_du,
    COUNT(DISTINCT t.id)                                 AS so_gd,
    COALESCE(SUM(CASE WHEN t.kind = 'fee' THEN t.amount END), 0) AS phi_thu
  FROM accounts a
  LEFT JOIN transactions t ON t.account_id = a.id
  GROUP BY a.customer_id
)
SELECT
  c.id,
  c.full_name,
  c.city,
  gt.tong_so_du,
  gt.so_gd,
  gt.phi_thu,
  ROUND(gt.phi_thu / NULLIF(gt.so_gd, 0)::numeric, 2)    AS phi_binh_quan_gd,
  ROUND(gt.tong_so_du * 0.02 + gt.phi_thu, 2)            AS gia_tri_uu_tien
FROM gt
JOIN customers c ON c.id = gt.customer_id
ORDER BY gia_tri_uu_tien DESC NULLS LAST
LIMIT 50;

Cột gia_tri_uu_tien (minh hoạ: 2% số dư/năm + phí thực thu) chính là hệ số mục tiêu r_i cho một bài toán chọn khách để phân bổ nguồn lực chăm sóc có hạn.

(b) Tổng hợp nhu cầu theo phân khúc (thành phố) — để đặt trần hấp thụ / nhu cầu cho từng nhóm trong mô hình phân bổ ngân sách:

-- ▶ Chạy được
SELECT
  c.city                                                 AS phan_khuc,
  COUNT(DISTINCT c.id)                                   AS so_khach,
  COUNT(DISTINCT a.id)                                   AS so_tk,
  SUM(a.balance)                                         AS tong_so_du,
  ROUND(AVG(a.balance)::numeric, 2)                      AS so_du_tb,
  ROUND(
    SUM(a.balance) / NULLIF(COUNT(DISTINCT c.id), 0)::numeric,
    2
  )                                                      AS so_du_tb_moi_khach
FROM customers c
LEFT JOIN accounts a ON a.customer_id = c.id
GROUP BY c.city
ORDER BY tong_so_du DESC NULLS LAST;

Kết quả cho ta, với mỗi phân khúc: quy mô khách, tổng số dư (→ trần hấp thụ vốn của phân khúc), số dư trung bình (→ ước lượng lợi nhuận biên). Đây đúng là các hệ số cho ràng buộc và mục tiêu của mô hình phân bổ marketing/vốn ở mục 1. Lưu ý cả hai truy vấn đều ép ::numeric trước ROUND và bọc NULLIF ở mẫu số để tránh chia cho 0 — quy tắc bắt buộc.

4. Đưa vào sản xuất

Một notebook giải được bài toán một lần không phải là hệ thống ra quyết định. Đưa vào sản xuất nghĩa là dựng một pipeline lặp lại được, có kiểm soát:

Các thành phần cốt lõi:

• Tần suất. Chọn đúng nhịp: tồn quỹ ATM và tiếp quỹ có thể hàng ngày; phân bổ hạn mức/vốn hàng tuần; ALM và ngân sách marketing hàng tháng/quý. Chạy quá dày thì nhiễu và tốn; quá thưa thì quyết định lỗi thời. Airflow batch định kỳ là hình thái chủ đạo (đưa mô hình vào sản xuất).
• Con người trong vòng lặp (human-in-the-loop). Với quyết định giá trị lớn hoặc ảnh hưởng khách hàng, mô hình đề xuất, cán bộ duyệt. Solver không thấy được yếu tố ngoài mô hình (một khách VIP đang khiếu nại, một chi nhánh sắp sáp nhập). Chốt phê duyệt bảo vệ khỏi nghiệm phi thực tế và tạo trách nhiệm giải trình.
• Kiểm nghiệm trước khi tin. Luôn đọc trạng thái (Optimal / time-limit + gap / Infeasible / Unbounded). Infeasible thường là lỗi ràng buộc, không phải "không có đáp án". Sanity-check nghiệm với vài quy tắc nghiệp vụ trước khi để nó đi tiếp.
• Giám sát & cập nhật. Theo dõi: chất lượng dự báo (drift), giá trị thực tế thu được so với kỳ vọng của solver, tần suất Infeasible, thời gian giải. Khi giá trị thực lệch xa kỳ vọng → dấu hiệu mô hình dự báo hoặc giả định tối ưu đã lệch, cần hiệu chỉnh.
• Log để kiểm toán. Lưu phiên bản dữ liệu, phiên bản mô hình, hệ số đầu vào, nghiệm, ai duyệt. Cần cho tái lập và cho thanh tra.

5. Thực hành & cạm bẫy

Đây là phần đúc rút kinh nghiệm — nơi các dự án tối ưu thất bại hay thành công:

• Mô hình đơn giản đúng > mô hình phức tạp sai. Một LP tuyến tính hoá "gần đúng" mà đội nghiệp vụ hiểu và tin thường tạo giá trị hơn một mô hình phi tuyến tinh vi mà không ai kiểm chứng được. Bắt đầu thô, tinh chỉnh dần khi có bằng chứng.
• Nghiệm "tối ưu" nhưng phi thực tế. Solver tối ưu đúng cái bạn viết ra — kể cả khi bạn quên một ràng buộc. Nó sẽ hồn nhiên đề xuất tiếp quỹ ATM lúc 3 giờ sáng, hay dồn 100% vốn vào một sản phẩm. Kiểm định nghiệm với nghiệp vụ là bước không thể bỏ: hỏi "nghiệm này có làm được thật không?".
• Ràng buộc mềm & tính khả thi. Ràng buộc cứng dễ khiến bài Infeasible vì một vi phạm nhỏ. Chuyển các ràng buộc "nên" (không phải "bắt buộc pháp lý") thành ràng buộc mềm có phạt: cho phép vi phạm nhưng trả giá. Vừa tránh vỡ vừa cho nghiệm thoả hiệp thực tế.
• Dữ liệu & giả định. "Rác vào, rác ra" nhân đôi trong tối ưu. Đơn vị nhất quán, hệ số cùng bậc độ lớn (scaling), giả định tuyến tính có kiểm chứng. Ghi rõ mọi giả định — chúng thường là chỗ vỡ.
• Thay đổi hành vi khi tối ưu (endogeneity). Nếu tối ưu định giá dựa trên đường cầu quá khứ, chính hành động đổi giá lại đổi hành vi khách → dự báo cũ lệch. Cẩn trọng với các vòng phản hồi mà quyết định làm thay đổi dữ liệu sinh ra nó.
• Quản trị & tuân thủ. Quyết định tự động ảnh hưởng khách hàng hoặc tín dụng (duyệt hạn mức, chọn ai bị đòi nợ, ai được ưu đãi) cần kiểm soát, giải trình được và tuân thủ khung quản trị dữ liệu — xem quyền riêng tư & tuân thủ và chất lượng dữ liệu. Phải trả lời được "vì sao hệ thống quyết định thế này?".
• Đạo đức & công bằng (fairness). Tối ưu hoá thuần "tối đa lợi nhuận" có thể vô tình phân biệt đối xử (ví dụ dồn thu hồi vào nhóm dễ tổn thương, từ chối phân khúc theo địa lý). Cần đưa ràng buộc công bằng và rà soát tác động, không để hàm mục tiêu hẹp dẫn dắt mù quáng.

Khi nào KHÔNG cần tối ưu phức tạp

Không phải bài nào cũng đáng dựng solver. Nếu một quy tắc heuristic đơn giản cho kết quả gần tối ưu và dễ hiểu, hãy dùng nó:

• Số phương án nhỏ, đủ để liệt kê hết (brute force) → không cần MILP.
• Bài phân tách được thành các quyết định độc lập → giải riêng từng phần.
• Quy tắc nghiệp vụ (ví dụ "nạp ATM khi tồn < 2 ngày rút trung bình") đã cho ~95% giá trị của nghiệm tối ưu, với chi phí xây dựng và bảo trì bằng một phần nhỏ.

Chi phí thực của một mô hình tối ưu không nằm ở lúc giải, mà ở xây dựng, kiểm chứng, bảo trì và giải trình. Chỉ trả chi phí đó khi giá trị tăng thêm biện minh được.

6. Bản đồ series — 8 bài đã đi qua

Đọc theo thứ tự: 01–04 là nền tảng (mô hình hoá + giải); 05–07 là các lớp bài toán và bất định; 08 là khớp tất cả vào vận hành thật.

Use case thực tế

Bối cảnh: pipeline predict-then-optimize cho ưu tiên thu hồi nợ tại NCB

Đội thu hồi nợ có năng lực giới hạn: 12 nhân sự × 30 giờ tương tác/tuần = 360 giờ. Trong kỳ có 4.000 hồ sơ quá hạn nhẹ (DPD 1–30). Không thể chạm hết — phải chọn hồ sơ nào, kênh nào để tối đa số tiền thu hồi được.

Bước 1 — Predict (ML). Mô hình xác suất thu hồi cho mỗi hồ sơ i và mỗi kênh k (SMS/gọi/thăm) một xác suất p_ik và dư nợ d_i. Thu hồi kỳ vọng r_ik = p_ik · d_i. Chi phí giờ-người mỗi kênh: SMS 0.05h, gọi 0.3h, thăm 2h.

Bước 2 — Chuẩn bị dữ liệu (SQL). Truy vấn kiểu mục 3 tổng hợp lịch sử tương tác + dư nợ + phân khúc, feed feature cho mô hình và cho bài toán.

Bước 3 — Optimize (MILP). Biến x_ik ∈ {0,1}: có xử lý hồ sơ i qua kênh k không.

max   Σ_ik  r_ik · x_ik
s.t.  Σ_ik  cost_k · x_ik ≤ 360        (năng lực đội)
      Σ_k   x_ik ≤ 1     ∀i             (mỗi hồ sơ tối đa 1 kênh)
      ràng buộc công bằng: tỷ lệ chạm không lệch quá X% giữa phân khúc

Bước 4 — Giải & kiểm. CBC giải vài giây, trạng thái Optimal. Solver chọn ~1.100 hồ sơ giá trị cao qua gọi/thăm, phần đuôi dài đẩy sang SMS chi phí thấp. Sanity-check: không ai bị chọn thăm nhà cho dư nợ 200 nghìn (ràng buộc công bằng + ngưỡng dư nợ tối thiểu chặn).

Bước 5 — Phê duyệt & thực thi. Trưởng nhóm thu hồi duyệt danh sách, chỉnh vài hồ sơ nhạy cảm, hệ thống phát lệnh phân công.

Bước 6 — Giám sát. Cuối kỳ so thu hồi thực tế với kỳ vọng của solver. Chênh lệch lớn → hiệu chỉnh mô hình p_ik. Kết quả điển hình: cùng 360 giờ, thu hồi tăng 15–25% so với quy tắc "gọi theo dư nợ giảm dần" nhờ tính cả xác suất phản hồi và chi phí kênh — đúng tinh thần predict-then-optimize.

Ghi nhớ

• Tối ưu hoá là tầng prescriptive (nên làm gì) — tầng cao nhất và tạo giá trị lớn nhất của analytics, đứng trên descriptive và predictive.
• Hầu hết quyết định phân bổ nguồn lực khan hiếm trong ngân hàng đều là bài toán tối ưu: tồn quỹ ATM, tiếp quỹ (VRP), ngân sách marketing, hạn mức/vốn, ALM, xếp ca, thu hồi nợ, định giá. Nhận ra khuôn mẫu mục tiêu–ràng buộc–biến là nửa đường tới lời giải.
• Predict-then-optimize là kiến trúc trung tâm: ML dự báo cung cấp hệ số (nhu cầu/rủi ro/phản hồi) làm input cho mô hình tối ưu. Nhưng tối ưu khuếch đại sai số dự báo — chú ý decision-focused learning và truyền độ bất định (stochastic/robust) thay vì tin mù dự báo điểm.
• Sản xuất hoá = pipeline lặp lại có kiểm soát: dữ liệu → dự báo → tối ưu → kiểm nghiệm → phê duyệt (human-in-the-loop) → thực thi → giám sát. Chọn đúng tần suất, log để kiểm toán.
• Cạm bẫy lớn nhất: nghiệm "tối ưu" nhưng phi thực tế vì thiếu ràng buộc. Luôn kiểm định nghiệm với nghiệp vụ; dùng ràng buộc mềm có phạt để tránh Infeasible dễ vỡ.
• Quyết định tự động ảnh hưởng khách/tín dụng cần quản trị, giải trình được, tuân thủ và công bằng — không để hàm mục tiêu hẹp dẫn dắt mù quáng.
• Không phải bài nào cũng cần solver phức tạp: nếu heuristic/quy tắc đơn giản đạt ~95% giá trị và dễ bảo trì, hãy dùng nó. Chi phí thật nằm ở xây dựng–kiểm chứng–bảo trì–giải trình.