Trực quan hoá 1 — Vì sao & quy trình

Mở đầu: vì sao trực quan hoá không phải "trang trí"

Hãy tưởng tượng bạn nhận một file Excel 200 dòng: dư nợ theo tháng của từng chi nhánh trong hai năm. Nhìn vào bảng số, mắt bạn phải đọc tuần tự từng ô, ghi nhớ, so sánh trong đầu — và sau vài phút bạn vẫn không biết chi nhánh nào đang tăng trưởng, chi nhánh nào đang tụt. Bây giờ đổi thành một biểu đồ đường: chỉ trong hai giây, bạn thấy ngay đường nào dốc lên, đường nào gãy xuống, đường nào có một điểm bất thường.

Đó là toàn bộ lý do trực quan hoá dữ liệu (data visualization) tồn tại. Não người xử lý thông tin thị giác theo cơ chế tiền chú ý (pre-attentive) — nhận diện màu sắc, độ dài, độ dốc, vị trí trong khoảng vài chục mili-giây, trước cả khi bạn "cố gắng" đọc. Ngược lại, đọc con số là quá trình tuần tự, chậm và tốn bộ nhớ làm việc. Chuyển dữ liệu thành hình ảnh nghĩa là giao việc nặng cho phần cứng mạnh nhất của bộ não.

Trực quan hoá giúp ta thấy ba thứ mà bảng số che giấu: mẫu hình (pattern) như tính mùa vụ, chu kỳ; xu hướng (trend) tăng/giảm dài hạn; và ngoại lệ (outlier) — điểm bất thường cần điều tra. Trong ngân hàng, một outlier trên biểu đồ giao dịch có thể là gian lận; một trend gãy có thể là dấu hiệu rủi ro tín dụng. Bảng số hiếm khi hét lên với bạn; biểu đồ thì có.

Đây là bài mở đầu của series Trực quan hoá dữ liệu: Nguyên lý & thực hành. Nó đặt nền tảng tư duy: khi nào vẽ để làm gì, quy trình chuẩn, và những nguyên lý sẽ theo bạn dù dùng công cụ nào.

Hai mục đích, hai cách làm: Exploratory vs Explanatory

Sai lầm phổ biến nhất của người mới là đối xử với mọi biểu đồ như nhau. Thực ra trực quan hoá phục vụ hai mục đích hoàn toàn khác nhau, và nhầm lẫn giữa chúng khiến bạn làm sai việc.

Exploratory — trực quan hoá để khám phá

Bạn là analyst, vừa nhận một bộ dữ liệu giao dịch mới và chưa biết trong đó có gì. Mục tiêu là tự mình tìm hiểu: phân phối số tiền giao dịch ra sao? Có bao nhiêu loại giao dịch? Có tương quan giữa số dư và tần suất không? Ở giai đoạn này bạn vẽ rất nhiều biểu đồ, rất nhanh, cho chính mình xem.

Đặc điểm của trực quan hoá khám phá:

• Số lượng nhiều, chất lượng "vừa đủ": vẽ histogram, scatter, boxplot hàng loạt; không cần tiêu đề đẹp hay màu chuẩn.
• Người xem là bạn (hoặc vài đồng nghiệp cùng phân tích) — bạn hiểu ngữ cảnh nên không cần chú thích cầu kỳ.
• Mục tiêu là phát hiện, chấp nhận 90% biểu đồ sẽ bị vứt đi. Đây là giai đoạn EDA (Exploratory Data Analysis).
• Công cụ điển hình: notebook (pandas + matplotlib/seaborn), truy vấn nhanh trong Metabase, "quick chart" trong BI tool.

Explanatory — trực quan hoá để giải thích

Bây giờ bạn đã tìm ra một insight: "dư nợ chi nhánh Cần Thơ giảm 18% trong Q2 do tập trung một nhóm khách hàng lớn tất toán sớm". Bạn cần truyền đạt đúng một thông điệp này cho Ban lãnh đạo trong cuộc họp. Đây là trực quan hoá giải thích.

Đặc điểm:

• Số lượng ít, chất lượng cao: thường chỉ 1–3 biểu đồ, mỗi cái phục vụ đúng một thông điệp.
• Người xem là người khác — không có ngữ cảnh của bạn, nên phải rõ ràng: tiêu đề nói thẳng insight, chú thích đầy đủ, highlight đúng chỗ cần nhìn.
• Mục tiêu là thuyết phục / thúc đẩy quyết định, không phải khoe hết dữ liệu. Mọi thứ không phục vụ thông điệp đều bị cắt.
• Đây là địa hạt của data storytelling — xem BI 10 — Data Storytelling.

Bảng dưới tóm tắt khác biệt cốt lõi:

Xác định mình đang ở chế độ nào trước khi mở công cụ giúp tiết kiệm hàng giờ. Đừng chăm chút màu mè cho biểu đồ EDA; và đừng dội một dashboard 20 chart lộn xộn vào mặt lãnh đạo khi họ chỉ cần một thông điệp.

Quy trình trực quan hoá 6 bước

Trực quan hoá tốt không phải khoảnh khắc cảm hứng, mà là một quy trình. Dưới đây là sáu bước áp dụng được cho cả hai mục đích (ở exploratory bạn chạy nhanh và lặp; ở explanatory bạn đầu tư kỹ từng bước).

Bước 1 — Hiểu câu hỏi & khán giả. Biểu đồ trả lời một câu hỏi, không phải "hiển thị một bảng". "Doanh số 3 tháng qua thế nào so với mục tiêu?" là câu hỏi tốt. Khán giả quyết định độ chi tiết: CEO cần một con số + một xu hướng; trưởng phòng vận hành cần chi tiết theo chi nhánh.

Bước 2 — Chuẩn bị dữ liệu. Làm sạch giá trị thiếu/sai, tổng hợp về đúng mức (theo tháng, theo chi nhánh), tính toán các đại lượng dẫn xuất (tỷ lệ, tăng trưởng %). Chất lượng biểu đồ không vượt quá chất lượng dữ liệu đằng sau.

Bước 3 — Chọn encoding / biểu đồ. Ánh xạ biến dữ liệu vào kênh thị giác (vị trí, độ dài, màu, kích thước). Loại câu hỏi quy định loại chart: so sánh → bar; xu hướng theo thời gian → line; phân phối → histogram/box; tương quan → scatter; tỷ trọng thành phần → stacked bar. Chi tiết ở viz-03-chart-selection.

Bước 4 — Thiết kế. Bố cục, thứ tự sắp xếp (sắp bar theo giá trị chứ không theo bảng chữ cái nếu mục tiêu là so sánh), bảng màu, nhãn trục.

Bước 5 — Tinh chỉnh. Loại bỏ nhiễu (chartjunk): đường lưới thừa, viền, hiệu ứng 3D, màu loè loẹt. Dùng màu và độ đậm để highlight đúng chỗ cần nhìn. Kiểm định lại: trục có bị cắt gây hiểu lầm không?

Bước 6 — Kể chuyện. Với explanatory, gắn insight vào ngữ cảnh: tiêu đề nói thẳng kết luận ("Dư nợ Cần Thơ giảm 18% do tất toán sớm"), thêm annotation chỉ vào điểm quan trọng.

"Vẽ đẹp" khác "truyền đạt đúng"

Một biểu đồ có thể rất đẹp — gradient mượt, font sang, animation — mà vẫn truyền đạt sai. Và một biểu đồ xám xịt, đơn giản có thể truyền đạt hoàn hảo. Đây là điểm nhiều người nhầm lẫn.

Mục tiêu tối thượng của trực quan hoá là giảm thời gian và công sức để người xem hiểu đúng sự thật. Cái đẹp chỉ có giá trị khi nó phục vụ mục tiêu đó: bố cục sạch giúp mắt lướt nhanh, màu nhất quán giúp nhận diện, khoảng trắng giúp tách nhóm. Cái đẹp chống lại mục tiêu khi nó thêm nhiễu: biểu đồ tròn 3D nghiêng làm sai lệch tỷ lệ, thang màu cầu vồng khiến người xem không đọc được thứ tự.

Nguy hiểm hơn, một biểu đồ đẹp mà dối trá thì tệ hơn cả bảng số thô: trục y bị cắt để phóng đại chênh lệch, chọn khoảng thời gian có lợi, dùng diện tích thay vì độ dài để đánh lừa cảm nhận. Series này có một bài riêng về những cạm bẫy và đạo đức trực quan hoá — viz-07-pitfalls-ethics. Nguyên tắc: ưu tiên trung thực và rõ ràng; cái đẹp là phương tiện, không phải mục đích.

Vai trò trong BI và data storytelling

Trực quan hoá là lớp "mặt tiền" của cả hệ thống BI. Dù pipeline dữ liệu, data warehouse, mô hình chiều (dimensional model) có tinh vi đến đâu, người ra quyết định chỉ chạm vào báo cáo và dashboard — tức là các biểu đồ. Nếu lớp này kém, toàn bộ giá trị đầu tư phía sau bị nghẽn ở "chặng cuối". Xem tổng quan hệ sinh thái BI ở BI 1 — Business Intelligence là gì.

Trong ngân hàng, cùng một tập dữ liệu được trực quan hoá theo nhiều cấp khán giả:

• Ban điều hành: dashboard tổng quan — tổng dư nợ, NPL ratio, CASA, so với kế hoạch; ít chart, mỗi chart một KPI, có so sánh mục tiêu.
• Trưởng khối / phòng ban: chi tiết theo chi nhánh, sản phẩm, phân khúc — cho phép drill-down.
• Analyst / nghiệp vụ: biểu đồ khám phá phục vụ điều tra một vấn đề cụ thể (một chi nhánh bất thường, một nhóm khách rủi ro).

Trực quan hoá kết thúc bằng kể chuyện: sắp xếp các biểu đồ và insight thành một mạch lập luận có mở đầu (bối cảnh), phát triển (điều gì đang xảy ra), cao trào (insight quan trọng) và kết (đề xuất hành động). Đó là chủ đề của bài viz-06-storytelling và bổ trợ bởi BI 10 — Data Storytelling.

Bài học kinh điển: Anscombe's quartet — vì sao phải VẼ

Năm 1973, nhà thống kê Francis Anscombe tạo ra bốn bộ dữ liệu (x, y) — gọi là Anscombe's quartet — với một điểm chung gây sốc: cả bốn có gần như y hệt các thống kê tóm tắt (summary statistics):

Nếu chỉ nhìn bảng số này, bạn kết luận bốn bộ dữ liệu "giống nhau". Nhưng khi vẽ ra, chúng khác nhau hoàn toàn: bộ I là quan hệ tuyến tính bình thường; bộ II là một đường cong (không tuyến tính — hồi quy tuyến tính hoàn toàn sai); bộ III tuyến tính chặt nhưng bị một outlier kéo lệch; bộ IV là một cột điểm thẳng đứng cộng một điểm duy nhất tạo ra toàn bộ tương quan giả.

Bài học nằm ở chỗ: thống kê tóm tắt che giấu hình dạng dữ liệu. Trung bình, phương sai, hệ số tương quan là những con số nén — chúng ném đi thông tin về phân phối, phi tuyến, và ngoại lệ. Chỉ có trực quan hoá mới phơi bày những thứ đó. Đây chính là lý do EDA luôn bắt đầu bằng vẽ, và vì sao ta không được tin một con số r = 0.82 mà chưa nhìn scatter plot. (Về giới hạn của thống kê mô tả, xem stat-01-descriptive.)

Liên hệ ngân hàng: nếu bạn chỉ báo cáo "giao dịch trung bình 12 triệu, độ lệch chuẩn 8 triệu", bạn giấu mất chuyện phân phối có thể lệch phải nặng với vài giao dịch 500 triệu — chính những điểm cần chú ý cho phòng chống rửa tiền lại bị con số trung bình làm cho vô hình.

Ví dụ: dữ liệu cho một biểu đồ xu hướng

Trước khi vẽ, ta cần dữ liệu ở đúng mức tổng hợp. Đây là bước 2 (chuẩn bị dữ liệu) cho một biểu đồ đường "tổng giao dịch theo tháng". Truy vấn sau chạy được trên sandbox PostgreSQL:

-- ▶ Chạy được
SELECT date_trunc('month', created_at) AS thang,
       COUNT(*)                        AS so_giao_dich,
       ROUND(SUM(amount)::numeric, 2)  AS tong_tien
FROM transactions
GROUP BY date_trunc('month', created_at)
ORDER BY thang;

Kết quả là một bảng "gọn": mỗi dòng một tháng, kèm số giao dịch và tổng tiền. Đây chính là input cho một biểu đồ line (xu hướng theo thời gian). Lưu ý cách ép kiểu ::numeric trước ROUND — vì amount là NUMERIC, việc này đảm bảo hàm ROUND hai tham số hoạt động đúng. Từ bảng này, việc chọn line chart (bước 3) là hiển nhiên: biến thời gian ở trục x, giá trị liên tục ở trục y, có thứ tự tự nhiên.

Lộ trình series

Series này đi từ nền tảng nhận thức đến thực hành ngân hàng:

• viz-02-perception — nhận thức thị giác: kênh mã hoá nào não đọc chính xác nhất, thuộc tính tiền chú ý.
• viz-03-chart-selection — chọn biểu đồ theo loại câu hỏi.
• viz-04-color-design — dùng màu đúng, bảng màu tuần tự/phân kỳ/định tính, khả năng tiếp cận.
• viz-05-dashboard-design — thiết kế dashboard: bố cục, phân cấp, drill-down.
• viz-06-storytelling — kể chuyện bằng dữ liệu.
• viz-07-pitfalls-ethics — cạm bẫy và đạo đức: trục cắt, biểu đồ dối trá.
• viz-08-practice-banking — thực hành: dựng bộ báo cáo cho ngân hàng từ đầu đến cuối.

Use case thực tế

Bối cảnh. Khối Bán lẻ NCB họp giao ban Q2. Analyst nhận yêu cầu: "Cho biết tình hình giao dịch nửa đầu năm." Dữ liệu thô là bảng transactions với hàng triệu dòng.

Sai lầm nếu không phân biệt mục đích. Analyst dán thẳng một dashboard 15 biểu đồ (mọi thứ mình từng vẽ khi khám phá) lên màn hình họp. Lãnh đạo hoa mắt, không rút ra kết luận, cuộc họp trôi qua vô ích. Đây là lỗi mang biểu đồ exploratory đi làm việc explanatory.

Làm đúng theo quy trình.

1. Câu hỏi & khán giả: khán giả là Ban điều hành; câu hỏi thực sự họ quan tâm là "xu hướng giao dịch có lành mạnh không, có gì bất thường không?". Chỉ cần một thông điệp.
2. Chuẩn bị dữ liệu: chạy truy vấn tổng hợp theo tháng như phần ví dụ ở trên, ra 6 dòng (tháng 1–6).
3. Chọn biểu đồ: xu hướng theo thời gian → line chart, một đường tổng tiền.
4. Thiết kế: trục y bắt đầu từ 0 (không cắt gây hiểu lầm); nhãn tháng rõ; một đường duy nhất.
5. Tinh chỉnh: phát hiện tháng 4 có một đỉnh bất thường (+35% so với xu hướng) — highlight điểm đó bằng màu và annotation.
6. Kể chuyện: EDA sâu hơn cho thấy đỉnh tháng 4 đến từ 3 giao dịch doanh nghiệp lớn tất toán. Tiêu đề biểu đồ đổi thành: "Giao dịch tăng đều 6 tháng; đỉnh tháng 4 là bất thường một lần (3 khách doanh nghiệp), không phải xu hướng."

Kết quả: một biểu đồ, một thông điệp, một quyết định — lãnh đạo hiểu ngay rằng đà tăng là thật nhưng phải điều chỉnh kỳ vọng cho quý sau vì đỉnh tháng 4 không lặp lại. Thời gian truyền đạt: dưới một phút, thay vì 15 biểu đồ gây rối.

Ghi nhớ

• Não đọc hình ảnh (vị trí, độ dài, độ dốc, màu) nhanh hơn số/bảng nhiều lần — trực quan hoá là giao việc nặng cho phần cứng mạnh nhất của bộ não.
• Trực quan hoá phơi bày pattern, trend, outlier mà bảng số che giấu.
• Phân biệt Exploratory (khám phá — nhiều chart nhanh, cho chính mình) và Explanatory (giải thích — ít chart tinh, cho người khác); nhầm hai loại là lỗi phổ biến nhất.
• Quy trình 6 bước: hiểu câu hỏi & khán giả → chuẩn bị dữ liệu → chọn encoding/biểu đồ → thiết kế → tinh chỉnh → kể chuyện.
• "Vẽ đẹp" ≠ "truyền đạt đúng": cái đẹp chỉ có giá trị khi phục vụ sự rõ ràng và trung thực; ưu tiên đúng hơn đẹp.
• Anscombe's quartet: bốn bộ dữ liệu có cùng thống kê tóm tắt nhưng hình dạng khác hẳn → luôn phải VẼ, đừng chỉ tin trung bình/phương sai/tương quan.
• Trong ngân hàng, cùng dữ liệu được trực quan hoá theo cấp khán giả: điều hành (KPI tổng), quản lý (drill-down), analyst (khám phá).
• Trực quan hoá là "chặng cuối" của BI và là nền cho data storytelling — nơi biểu đồ trở thành lập luận thúc đẩy hành động.