Tối ưu hoá 1 — Tổng quan Vận trù học

Từ "chuyện gì xảy ra" đến "nên làm gì"

Phân tích dữ liệu có ba bậc, và giá trị kinh doanh tăng dần qua từng bậc:

• Descriptive (mô tả): chuyện gì đã xảy ra? Dashboard, báo cáo, KPI. "Tháng trước dư nợ tăng 3%, ATM khu vực Đông Nam thiếu tiền mặt 6 lần."
• Predictive (dự đoán): chuyện gì sẽ xảy ra? Mô hình dự báo, ML. "Tuần tới ATM này rút ra khoảng 1,8 tỷ; khách này có xác suất vỡ nợ 12%."
• Prescriptive (kê đơn): ta NÊN LÀM GÌ? Đây là bậc cao nhất — không chỉ mô tả hay dự báo, mà chỉ ra quyết định tốt nhất để đạt mục tiêu dưới các ràng buộc. "Nạp 2,1 tỷ vào ATM này thứ Hai và 1,3 tỷ thứ Năm; phân bổ 40% ngân sách marketing cho phân khúc A."

Tối ưu hoá & vận trù học (Operations Research, viết tắt OR) là ngành cung cấp công cụ cho bậc prescriptive: dùng mô hình toán để tìm phương án TỐT NHẤT trong vô số phương án khả thi, dưới các ràng buộc thực tế về tài nguyên, quy định và logic nghiệp vụ.

Điểm khác biệt cốt lõi: descriptive/predictive dừng ở việc hiểu thế giới; OR đi tiếp một bước quyết định — nó thay đổi thế giới bằng cách nói cho bạn hành động cụ thể. Một mô hình dự báo giỏi cho biết ATM sẽ rút bao nhiêu; nhưng chính bài toán tối ưu mới trả lời "vậy nên nạp bao nhiêu, ngày nào, để tối thiểu chi phí tiếp quỹ + chi phí vốn nằm chết mà không bao giờ hết tiền". Dự báo là đầu vào; tối ưu là quyết định.

Trong ngân hàng, mỗi ngày là hàng loạt quyết định phân bổ nguồn lực hữu hạn: vốn, tiền mặt, hạn mức, nhân sự, ngân sách. Khi quy mô lớn và ràng buộc phức tạp, trực giác con người không còn đủ — chênh lệch giữa quyết định "tạm ổn" và quyết định "tối ưu" có thể là hàng tỷ đồng mỗi năm. Đó là lý do OR đáng giá.

Series 8 bài này đi từ nền tảng (quy hoạch tuyến tính, quy hoạch nguyên/MILP, solver & công cụ) đến ứng dụng ngân hàng (danh mục/ALM, mạng lưới & lịch trình, tối ưu dưới bất định, ra quyết định ngân hàng).

Ba thành phần của MỌI bài toán tối ưu

Bất kỳ bài toán tối ưu nào — dù đơn giản hay phức tạp — đều gồm đúng ba thành phần. Nắm chắc ba thành phần này là nắm được 80% tư duy mô hình hoá.

1. Biến quyết định (decision variables)

Đây là những đại lượng ta được quyền chọn — nghiệm mà bài toán cần tìm. Ký hiệu thường là $x_1, x_2, \dots$ hoặc $x_i$.

• Tối ưu tiền mặt ATM: $x_i$ = số tiền nạp vào ATM $i$ mỗi lần tiếp quỹ.
• Phân bổ ngân sách marketing: $x_j$ = số tiền chi cho kênh/phân khúc $j$.
• Xếp lịch nhân sự: $x_{i,t}$ = 1 nếu nhân viên $i$ trực ca $t$, ngược lại = 0 (biến nhị phân).

Loại biến quyết định định hình loại bài toán: liên tục (số tiền), nguyên (số quầy mở), hay nhị phân (có/không). Đây là phần quan trọng nhất khi mô hình hoá — chọn sai biến thì cả mô hình sai.

2. Hàm mục tiêu (objective function)

Một biểu thức toán duy nhất đo "độ tốt" của một phương án, mà ta muốn tối đa hoá (maximize) hoặc tối thiểu hoá (minimize):

• Max lợi nhuận / lợi suất: danh mục đầu tư, giá bán, cross-sell.
• Min chi phí: chi phí vận hành, chi phí vốn, chi phí tiếp quỹ ATM, chi phí tồn kho tiền mặt.
• Min rủi ro: phương sai danh mục (Markowitz), tổn thất kỳ vọng.

Chỉ có MỘT hàm mục tiêu (bài toán đơn mục tiêu). Khi có nhiều mục tiêu xung đột (vừa max lợi nhuận vừa min rủi ro), ta thường gộp bằng trọng số ($\max\ \text{lợi nhuận} - \lambda \cdot \text{rủi ro}$) hoặc biến một mục tiêu thành ràng buộc ("rủi ro ≤ ngưỡng"). Đây là kỹ thuật đa mục tiêu.

3. Ràng buộc (constraints)

Các bất đẳng thức/đẳng thức giới hạn tập phương án khả thi. Không có ràng buộc thì "max lợi nhuận" luôn là vô hạn — chính ràng buộc mới làm bài toán thú vị và có thực. Ba nhóm ràng buộc điển hình trong ngân hàng:

Một bài toán tối ưu tuyến tính điển hình viết gọn:

$$ \begin{aligned} \max_{x} \quad & c^\top x \quad \text{(hàm mục tiêu)} \ \text{s.t.} \quad & A x \le b \quad \text{(ràng buộc tài nguyên)} \ & x \ge 0 \quad \text{(miền giá trị)} \end{aligned} $$

Phân loại bài toán tối ưu

Chọn đúng "loại" bài toán quyết định thuật toán/solver dùng và bài toán có giải được trong thời gian hợp lý hay không. Đây là bản đồ phân loại thực dụng.

Theo dạng hàm: tuyến tính vs phi tuyến

• LP — Linear Programming (quy hoạch tuyến tính): hàm mục tiêu VÀ mọi ràng buộc đều tuyến tính (bậc nhất theo biến). Giải cực nhanh, kể cả hàng triệu biến, bằng simplex hoặc interior-point. Đây là "ngôn ngữ mẹ đẻ" của OR — chi tiết ở bài 2.
• NLP — Nonlinear Programming (phi tuyến): mục tiêu hoặc ràng buộc phi tuyến. VD tối thiểu phương sai danh mục (bậc hai — QP, quadratic programming là trường hợp riêng). Khó hơn LP; lời giải phụ thuộc mạnh vào tính lồi.

Theo loại biến: liên tục vs rời rạc

• IP / MILP — (Mixed) Integer (Linear) Programming: một số hoặc tất cả biến buộc phải NGUYÊN hoặc NHỊ PHÂN. Cần cho quyết định rời rạc: mở/không mở chi nhánh (0/1), số quầy nguyên, chọn/không chọn khoản đầu tư. MILP cực kỳ mạnh về biểu đạt nhưng thuộc lớp NP-hard — độ khó tăng vọt theo số biến nguyên. Xem bài 3.
• Tối ưu tổ hợp (combinatorial): chọn từ tập cấu hình rời rạc khổng lồ — định tuyến (routing), gán việc (assignment), đóng gói. Thường mô hình hoá bằng MILP.

Theo tính lồi (convexity) — ranh giới quan trọng nhất

• Bài toán lồi (convex): tập khả thi lồi và hàm mục tiêu lồi (khi minimize). Đặc điểm vàng: nghiệm tối ưu cục bộ CHÍNH LÀ toàn cục. LP và QP lồi thuộc nhóm này → giải được đảm bảo tối ưu. "Ranh giới thực sự trong tối ưu không phải tuyến tính vs phi tuyến, mà là lồi vs không-lồi."
• Bài toán không lồi (non-convex): có thể vướng nhiều nghiệm tối ưu cục bộ; solver chỉ đảm bảo tìm nghiệm cục bộ, không đảm bảo toàn cục. Cần solver toàn cục (chậm) hoặc chấp nhận nghiệm gần đúng.

Theo tính bất định

• Xác định (deterministic): mọi tham số biết chắc.
• Dưới bất định (stochastic / robust): đầu vào (nhu cầu, lãi suất, tỷ lệ vỡ nợ) là biến ngẫu nhiên. Stochastic programming tối ưu theo kỳ vọng trên các kịch bản; robust optimization tối ưu cho trường hợp xấu nhất trong một miền bất định. Rất quan trọng với ngân hàng vì tương lai luôn không chắc — xem bài 7.

Nghiệm khả thi, nghiệm tối ưu, cục bộ vs toàn cục

Ba khái niệm cần phân biệt rạch ròi để nói chuyện chính xác với solver:

• Nghiệm khả thi (feasible): một phương án THOẢ MỌI ràng buộc. Có thể có vô số nghiệm khả thi. Nếu không tồn tại nghiệm nào thoả tất cả ràng buộc → bài toán infeasible (vô nghiệm khả thi) — dấu hiệu ràng buộc mâu thuẫn, cần rà lại mô hình.
• Nghiệm tối ưu (optimal): nghiệm khả thi có giá trị hàm mục tiêu TỐT NHẤT. Nếu hàm mục tiêu có thể tăng/giảm vô hạn mà vẫn khả thi → unbounded (thường do quên ràng buộc).
• Tối ưu cục bộ (local) vs toàn cục (global): tối ưu cục bộ chỉ tốt nhất trong lân cận; toàn cục là tốt nhất trên toàn miền. Với bài lồi, hai khái niệm trùng nhau (may mắn lớn của LP). Với bài không lồi, đây là cạm bẫy: solver báo "tối ưu" nhưng thực ra chỉ là một hố cục bộ.

Thực chiến, solver còn báo khoảng cách tối ưu (optimality gap) — với MILP, ta thường dừng khi gap ≤ 1% thay vì chờ chứng minh tối ưu tuyệt đối (có thể mất hàng giờ). Một nghiệm cách tối ưu 0,5% giao ngay lúc 9h sáng đáng giá hơn nghiệm hoàn hảo lúc nửa đêm.

Quy trình vận trù học (OR process)

OR không phải là "quăng dữ liệu vào solver". Nó là một quy trình kỹ thuật năm bước, trong đó mô hình hoá và kiểm định chiếm phần lớn công sức — solver chỉ là một mắt xích.

1. Hiểu vấn đề: làm việc với nghiệp vụ để xác định QUYẾT ĐỊNH cần ra, mục tiêu thực sự, và ràng buộc bắt buộc. Bước dễ bị bỏ qua nhất nhưng quyết định thành bại — tối ưu sai mục tiêu còn tệ hơn không tối ưu.
2. Mô hình hoá: dịch nghiệp vụ thành biến quyết định, hàm mục tiêu, ràng buộc. Đây là nghệ thuật cốt lõi của OR.
3. Giải: đưa vào solver (bài 4). Solver phù hợp tuỳ loại bài (LP, MILP, NLP).
4. Diễn giải & kiểm định: nghiệm có hợp lý không? Phân tích độ nhạy (sensitivity) — nghiệm đổi thế nào nếu tham số đổi? Kiểm tra ca biên. Nếu vô nghiệm hoặc kết quả vô lý → quay lại bước 2.
5. Triển khai & giám sát: đưa vào quy trình ra quyết định thật, tự động chạy lại định kỳ, giám sát chất lượng khi dữ liệu/bối cảnh thay đổi.

Predict-then-optimize: cầu nối với ML/dự báo

OR và Machine Learning không cạnh tranh — chúng nối tiếp nhau. Kiến trúc phổ biến nhất là predict-then-optimize (dự báo rồi tối ưu):

1. Dự báo (predict): mô hình ML/thống kê ước lượng các tham số đầu vào cho bài toán tối ưu — nhu cầu rút ATM, xác suất vỡ nợ, độ co giãn phản hồi marketing, lợi suất kỳ vọng.
2. Tối ưu (optimize): mô hình OR nhận các tham số dự báo đó làm hằng số, tìm quyết định tốt nhất.

Ví dụ: dự báo chuỗi thời gian cho nhu cầu tiền mặt từng ATM → bài LP/MILP quyết định lịch và lượng tiếp quỹ. Hay hồi quy ước lượng độ co giãn phản hồi → bài phân bổ ngân sách marketing.

Lưu ý thực chiến: sai số dự báo lan sang quyết định. Một nhánh hiện đại (decision-focused learning) huấn luyện mô hình dự báo sao cho tối ưu chất lượng QUYẾT ĐỊNH cuối cùng, chứ không chỉ tối ưu độ chính xác dự báo — vì dự báo chính xác nhất không phải lúc nào cũng cho quyết định tốt nhất. Với bất định lớn, ta chuyển hẳn sang stochastic/robust (bài 7) thay vì cắm một điểm dự báo.

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

Ngân hàng là mảnh đất màu mỡ cho OR: quyết định quy mô lớn, ràng buộc quy định dày đặc, và mỗi quyết định là tiền thật. Bảng dưới dẫn các bài sau của series:

Điểm chung: đều là "phân bổ nguồn lực hữu hạn để tối đa lợi ích / tối thiểu chi phí dưới ràng buộc" — chính là định nghĩa OR. Liên hệ chặt với quản lý hạn mức & danh mục tín dụng ở khâu ràng buộc rủi ro.

Chuẩn bị dữ liệu đầu vào cho bài toán tối ưu

Trước khi mô hình hoá, bước tiền xử lý luôn là tổng hợp dữ liệu thô thành các tham số đầu vào cho bài toán — ví dụ tổng hợp số dư/nhu cầu theo nhóm để làm hệ số phân bổ. Với bài "phân bổ vốn/nguồn lực theo thành phố", ta cần biết quy mô mỗi thành phố:

-- ▶ Chạy được
-- Tổng hợp số dư & nhu cầu giao dịch theo thành phố -> đầu vào cho bài phân bổ
WITH bal AS (
  SELECT c.city,
         COUNT(DISTINCT c.id)        AS so_khach,
         SUM(a.balance)              AS tong_du
  FROM customers c
  JOIN accounts a ON a.customer_id = c.id
  GROUP BY c.city
),
flow AS (
  SELECT c.city,
         SUM(ABS(t.amount))          AS luong_gd_30d
  FROM customers c
  JOIN accounts a     ON a.customer_id = c.id
  JOIN transactions t ON t.account_id = a.id
  WHERE t.created_at >= NOW() - INTERVAL '30 days'
  GROUP BY c.city
)
SELECT b.city,
       b.so_khach,
       ROUND(b.tong_du::numeric, 0)                                   AS tong_du,
       ROUND(COALESCE(f.luong_gd_30d, 0)::numeric, 0)                 AS luong_gd_30d,
       ROUND(100.0 * b.tong_du
             / SUM(b.tong_du) OVER ()::numeric, 2)                    AS ty_trong_von_pct
FROM bal b
LEFT JOIN flow f ON f.city = b.city
ORDER BY tong_du DESC;

Cột ty_trong_von_pct chính là gợi ý phân bổ theo tỷ trọng — một baseline đơn giản (heuristic tỷ lệ) mà bài toán tối ưu thực thụ sẽ vượt qua, vì tối ưu còn cân nhắc chi phí, rủi ro và ràng buộc mà quy tắc tỷ lệ bỏ qua. Đây là ranh giới giữa "phân bổ theo cảm tính/tỷ lệ" và "phân bổ tối ưu".

Use case thực tế

Bối cảnh: NCB vận hành 60 ATM ở khu vực trọng điểm. Đội tiếp quỹ mỗi lần nạp tốn 1,2 triệu đồng/ATM (nhân sự + xe + bảo vệ). Tiền mặt nằm trong ATM là vốn chết — chi phí cơ hội ~0,02%/ngày (tương đương lãi suất huy động bỏ lỡ). Nếu ATM hết tiền, ước tính thiệt hại uy tín + khách mất giao dịch ~3 triệu đồng/sự cố. Bài toán: nạp bao nhiêu, ngày nào, cho từng ATM trong tháng tới.

Các bước theo quy trình OR:

1. Hiểu vấn đề: quyết định = lịch + lượng tiếp quỹ; mục tiêu = min tổng chi phí; ràng buộc = không được hết tiền, không vượt sức chứa hòm tiền.
2. Dự báo (predict): mô hình chuỗi thời gian ước lượng nhu cầu rút mỗi ATM mỗi ngày (VD ATM #17: trung bình 210 triệu/ngày, cao điểm cuối tháng 380 triệu).
3. Mô hình hoá (MILP):
   • Biến: $x_{i,t}$ = số tiền nạp ATM $i$ ngày $t$ (liên tục ≥ 0); $y_{i,t}$ = 1 nếu có tiếp quỹ (nhị phân).
   • Mục tiêu: $\min \sum (1{,}2\text{tr}\cdot y_{i,t} + 0{,}0002 \cdot \text{tồn}{i,t} + 3\text{tr}\cdot \text{hết}{i,t})$.
   • Ràng buộc: tồn quỹ $i$ ngày $t$ = tồn hôm trước + nạp − rút dự báo ≥ 0; tồn ≤ sức chứa; $x_{i,t} \le M \cdot y_{i,t}$ (chỉ nạp khi có chuyến).
4. Giải & diễn giải: solver MILP đưa lịch tối ưu — ví dụ ATM #17 nạp thứ Hai 550 triệu + thứ Năm 700 triệu thay vì nạp đều mỗi ngày.
5. Kết quả (minh hoạ): so với quy tắc "nạp đầy mỗi tuần", lịch tối ưu giảm ~18% số chuyến tiếp quỹ và ~25% vốn chết trung bình, gần như xoá sự cố hết tiền. Với 60 ATM, tiết kiệm ước tính vài trăm triệu đồng/năm — từ đúng một mô hình toán chạy lại hằng tuần.

Đây chính là predict-then-optimize: dự báo cho nhu cầu → MILP cho quyết định. Chi tiết mô hình mạng lưới & lịch trình ở bài 6.

Ghi nhớ

• Prescriptive là bậc cao nhất: descriptive (đã xảy ra gì) → predictive (sẽ xảy ra gì) → prescriptive (nên làm gì). OR/tối ưu hoá là công cụ của bậc prescriptive — nó kê đơn hành động, không chỉ mô tả/dự đoán.
• Ba thành phần của MỌI bài toán tối ưu: (1) biến quyết định — ta chọn gì; (2) hàm mục tiêu — max/min cái gì (lợi nhuận/chi phí/rủi ro); (3) ràng buộc — giới hạn tài nguyên/quy định/logic. Không có ràng buộc thì bài toán vô nghĩa.
• Phân loại quyết định solver: LP (tuyến tính, nhanh), MILP/IP (có biến nguyên/nhị phân, NP-hard), NLP (phi tuyến). Ranh giới thật sự là lồi vs không lồi: bài lồi thì tối ưu cục bộ = toàn cục.
• Phân biệt nghiệm: khả thi (thoả ràng buộc) ≠ tối ưu (tốt nhất). Cảnh giác infeasible, unbounded, và bẫy tối ưu cục bộ ở bài không lồi. Thực chiến thường dừng ở optimality gap ≤ 1%.
• Quy trình OR 5 bước: hiểu vấn đề → mô hình hoá → giải → diễn giải & kiểm định → triển khai. Mô hình hoá + kiểm định là phần khó nhất; solver chỉ là một mắt xích.
• Predict-then-optimize: ML/dự báo cung cấp tham số đầu vào (nhu cầu, xác suất, lợi suất); OR biến chúng thành quyết định. Với bất định lớn, dùng stochastic/robust thay vì một điểm dự báo.
• OR đáng giá khi: quyết định quy mô lớn, ràng buộc phức tạp, và tiền thật — đúng đặc điểm của phân bổ vốn/tiền mặt/ngân sách/nhân sự trong ngân hàng.