Nếu là bạn thì phải ngăn kiểu trực quan hóa dữ liệu này — 16 loại biểu đồ tệ và lý do vì sao
(github.com/cxli233)- Đây là một kho lưu trữ GitHub tổng hợp 16 thực hành trực quan hóa sai lầm thường gặp trong bài báo khoa học và phân tích dữ liệu, kèm ví dụ; có thể tự tái hiện từng trường hợp bằng mã R và dữ liệu mô phỏng
- Chỉ ra cụ thể các kiểu trực quan hóa làm méo mó phân phối và đặc tính của dữ liệu như lạm dụng biểu đồ cột để so sánh trung bình, dùng violin plot cho mẫu nhỏ, hay áp dụng thang màu hai chiều cho dữ liệu một chiều
- Giải thích vấn đề của các loại biểu đồ không tính đến đặc điểm nhận thức thị giác của con người như không sắp xếp lại hàng/cột trong heatmap, không kiểm tra ngoại lệ, hay các giới hạn căn bản của biểu đồ tròn và biểu đồ donut đồng tâm
- Bao gồm cảnh báo về các lỗi thiết kế cấu trúc dễ gây hiểu nhầm như nhầm lẫn giữa trực quan hóa dựa trên vị trí và dựa trên độ dài, hoặc biểu đồ cột cắt trục
- Là một bộ sưu tập anti-pattern thực dụng mà mọi nhà nghiên cứu và lập trình viên làm việc với trực quan hóa dữ liệu đều có thể tham khảo, đồng thời đưa ra phương án trực quan hóa thay thế cho từng mục
1. Đừng dùng biểu đồ cột để so sánh trung bình
- Biểu đồ so sánh trung bình (means separation) là một trong những dạng trực quan hóa phổ biến nhất trong bài báo khoa học, nhằm thể hiện trung bình, phương sai và phân phối của từ hai nhóm trở lên
- Trong ví dụ, hai nhóm có trung bình và độ lệch chuẩn tương tự nhau nhưng phân phối hoàn toàn khác nhau — chỉ với biểu đồ cột thì không thể nhận ra khác biệt này
- Trước khi dùng biểu đồ cột, nhất định phải kiểm tra phân phối của dữ liệu; Weissgerber et al. (2015, PLOS Biology) cũng đã chỉ ra giới hạn của biểu đồ cột
2. Đừng dùng violin plot cho mẫu nhỏ
- Violin plot hay đường cong phân phối được làm mượt không có nhiều ý nghĩa khi kích thước mẫu nhỏ
- Với mẫu nhỏ, ngay cả cùng một tập quan sát thì phân phối và các tứ phân vị cũng dao động mạnh; cần n từ 50 trở lên thì tứ phân vị mới ổn định
- Điều này được chứng minh bằng thí nghiệm lấy mẫu nhiều lần từ cùng một phân phối chuẩn để so sánh các tứ phân vị
3. Đừng dùng thang màu hai chiều cho dữ liệu một chiều
- Trong thang màu, màu đậm nhất và màu nhạt nhất phải biểu thị những giá trị có ý nghĩa như giá trị lớn nhất, nhỏ nhất, trung bình hoặc 0
- Việc để màu sáng nhất hay tối nhất biểu thị một con số tùy ý là lỗi nghiêm trọng chẳng khác gì “trong biểu đồ cột mà cột dài nhất lại không phải giá trị lớn nhất”
- Khi dùng heatmap/thang màu gradient, bắt buộc phải chọn thang màu phù hợp với tính định hướng của dữ liệu (một chiều hay hai chiều)
4. Đừng tạo “đồng cỏ biểu đồ cột” (Bar Plot Meadow)
- Nếu liệt kê kết quả của thí nghiệm đa yếu tố bằng hàng loạt biểu đồ cột thì sẽ thành một “đồng cỏ biểu đồ cột”, rất kém hiệu quả trong truyền đạt kết quả
- Muốn truyền tải tốt kết quả thí nghiệm đa yếu tố, cần thiết kế grouping/faceting cẩn thận theo các yếu tố quan tâm
- Ví dụ so sánh tác động của Treatment và Explant lên Response ở cấp Variety nhấn mạnh rằng bố cục phải thay đổi theo trọng tâm phân tích
5. Không thể bỏ qua việc sắp xếp lại hàng và cột trong heatmap
- Heatmap rất phổ biến trong bài báo khoa học, đặc biệt là các bài về omics, nhưng nếu không sắp xếp lại thứ tự hàng và cột thì gần như không thể rút ra thông tin hữu ích
- Sắp xếp lại bằng clustering là cách thường dùng, nhưng không phải cách duy nhất; trong các trường hợp biểu diễn bố cục vật lý như đĩa 96 giếng thì không thể sắp xếp lại
- Kết hợp việc sắp xếp lại hàng/cột với gradient màu phù hợp có thể tạo ra heatmap vừa hữu ích vừa đẹp mắt
6. Không được bỏ qua ngoại lệ trong heatmap
- Ngoại lệ có thể thay đổi hoàn toàn cách cảm nhận và diễn giải heatmap; đây cũng là vấn đề áp dụng cho mọi kiểu trực quan hóa dùng màu để biểu diễn dữ liệu số
- Trong ví dụ có 2 quan sát đo 20 đặc trưng, nếu không kiểm tra ngoại lệ thì chúng trông khá giống nhau; nhưng khi điều chỉnh thang màu theo phân vị thứ 95, khác biệt xuất hiện ở tất cả đặc trưng
7. Hãy kiểm tra phạm vi dữ liệu ở từng mức của yếu tố
- Trong thí nghiệm đa yếu tố, phạm vi của biến phản hồi thường thay đổi mạnh theo từng mức của yếu tố
- Trong thí nghiệm giả lập đo 3 hợp chất ở 2 nhóm (đối chứng vs. xử lý), phạm vi nồng độ của hợp chất 1 hẹp hơn nhiều so với các hợp chất khác, nên có nguy cơ bỏ sót hiệu ứng xử lý
- Nếu không kiểm tra trước phạm vi dữ liệu của từng hợp chất thì có thể bỏ qua các hiệu ứng xử lý quan trọng
8. Hãy thử nhiều layout cho network graph
- Hình thức bên ngoài của network graph (layout, không phải topology) ảnh hưởng rất lớn đến hiệu quả thể hiện
- Với cùng một dữ liệu, 3 network graph có thể trông hoàn toàn khác nhau; bài cũng gồm ví dụ áp dụng 9 layout khác nhau
- Vì độ khó khi diễn giải mạng thay đổi rất nhiều theo layout, nên cần thử nhiều layout
9. Đừng nhầm lẫn giữa trực quan hóa dựa trên vị trí và dựa trên độ dài
- Trong biểu đồ điểm và đường, giá trị được biểu diễn bằng vị trí trên trục x và y; trong biểu đồ cột, giá trị được biểu diễn bằng khoảng cách (độ dài) tính từ trục x
- Trong ví dụ, biểu đồ cột không bắt đầu từ 0 khiến cột ở thời điểm 2 trông dài gấp khoảng 3 lần thời điểm 1, nhưng chênh lệch trung bình thực tế chỉ khoảng 1,6 lần — nhầm lẫn giữa độ dài và vị trí sẽ tạo ra biểu đồ gây hiểu sai
-
Cẩn thận với biểu đồ cột cắt trục (Broken Axis)
- Cắt trục hữu ích khi cần biểu diễn các giá trị trong phạm vi rộng (hoặc có thể dùng trục thang log thay thế), nhưng chỉ phù hợp với biểu đồ dựa trên vị trí
- Trong biểu đồ cột, thay đổi vị trí cắt trục sẽ tạo ảo giác thị giác khiến một số cột trông dài hơn hoặc ngắn hơn
- Trong ví dụ, độ dài của cột “d” trông rất khác nhau tùy vị trí cắt trục, vì biểu đồ cột là đồ họa dựa trên độ dài
10. Đừng tạo biểu đồ tròn
- Biểu đồ tròn thể hiện dữ liệu tỷ lệ bằng các cung tròn, nhưng con người đọc độ dài tốt hơn rất nhiều so với góc và diện tích
- Trong ví dụ gồm 2 nhóm, mỗi nhóm có 4 phân nhóm, biểu đồ tròn khiến việc so sánh giữa các nhóm trở nên rất khó
- Ngay cả khi đơn giản hóa thành donut chart, dữ liệu vẫn được biểu diễn bằng độ dài cung; tốt hơn là trải chiếc donut ra thành biểu đồ cột chồng để so sánh hiệu quả hơn nhiều
- Trong ggplot, script tạo biểu đồ tròn và donut thậm chí còn phức tạp hơn biểu đồ cột chồng
11. Đừng tạo biểu đồ donut đồng tâm
- Với donut đồng tâm, người ta dễ nghĩ dữ liệu được biểu diễn bằng độ dài cung, nhưng thực tế là bằng góc cung; trong khi con người lại rất kém trong việc đọc góc cung
- Độ dài cung của vòng ngoài lớn hơn nhiều vòng trong, nên dù Group 2 và Group 3 có cùng giá trị thì cung của Group 3 vẫn trông dài hơn nhiều
- Thứ tự nhóm (nhóm nào nằm ở vòng nào) ảnh hưởng lớn đến cảm nhận về biểu đồ, thậm chí có thể tạo ra nghịch lý giá trị lớn hơn nhưng cung lại ngắn hơn
- Vấn đề tương tự cũng áp dụng cho circos plot và các layout hình tròn khác; giải pháp thay thế đơn giản là trải donut ra thành stacked bar plot
12. Đừng dùng thang màu đỏ/xanh lá và cầu vồng
- Rối loạn sắc giác đỏ-lục (Deuteranomaly) là dạng mù màu phổ biến nhất, xuất hiện ở 1/16 nam giới và 1/256 nữ giới
- Thang màu đỏ/xanh lá và cầu vồng gây vấn đề cho người mù màu, đồng thời bảo toàn thông tin rất kém khi in đen trắng
- Các thang màu “hiện đại” như viridis vừa thân thiện với người mù màu, an toàn ở grayscale, vừa có chất lượng thị giác tốt
13. Đừng quên sắp xếp lại stacked bar plot
- Stacked bar plot thường được dùng để trực quan hóa dữ liệu tỷ lệ, cấu trúc cộng đồng, cấu trúc quần thể, phân tích admixture
- Trong ví dụ với 100 mẫu và 8 lớp, nếu không tối ưu thứ tự các cột thì không thể nhận ra bất kỳ mẫu hình nào từ biểu đồ
- Sau khi sắp xếp lại các cột, các mẫu hình hiện ra rất rõ; mấu chốt là grouping và tối ưu thứ tự sắp xếp của các mẫu
14. Đừng trộn stacked bar với so sánh trung bình
- Stacked bar plot dùng cho dữ liệu tỷ lệ có tổng bằng 100%, còn biểu đồ so sánh trung bình dùng để thể hiện chênh lệch trung bình và phương sai; đây là hai bài toán trực quan hóa hoàn toàn khác nhau
- Trong ví dụ thí nghiệm trên cây việt quất, stacked bar plot chuẩn cho thấy xử lý hóa học đã đẩy mạnh hồ sơ màu quả sang giai đoạn chín nhất (dark blue) một cách rất rõ
- Nếu chồng error bar và các điểm lên stacked bar thì sẽ không rõ các error bar và điểm đó đang được so sánh với phần nào; error bar của các lớp phía trên còn bị đẩy lên cao khiến việc đọc trục y không còn trực quan
- Nếu mục tiêu chính là trực quan hóa so sánh trung bình và phương sai thì một biểu đồ so sánh trung bình riêng biệt sẽ phù hợp hơn
15. Đừng dùng histogram cho mẫu nhỏ
- Histogram đôi khi được đề xuất như một thay thế cho biểu đồ cột, nhưng độ ổn định theo số lượng bin rất thấp khi mẫu nhỏ
- Nếu lấy mẫu từ cùng một phân phối chuẩn với n = 10, 100, 1000 rồi vẽ histogram với 10, 30, 50 bin, thì hình dạng histogram khác nhau rất nhiều dù cùng một phân phối
- Với mẫu nhỏ (n < 30), tốt hơn nhiều là hiển thị trực tiếp toàn bộ các điểm dữ liệu trên biểu đồ; ngay cả ở n = 100, hình dạng histogram cũng thay đổi mạnh theo số bin
- Histogram chỉ trở nên đủ vững trước thay đổi số bin khi kích thước mẫu khoảng từ 1000 trở lên
16. Đừng dùng boxplot cho dữ liệu hai đỉnh (bimodal)
- Boxplot tập trung vào trung vị và các tứ phân vị, nên không thể thể hiện đúng dữ liệu hai đỉnh (và đa đỉnh)
- Trước khi tạo boxplot, nhất định phải kiểm tra phân phối dữ liệu
- Với cỡ mẫu nhỏ đến trung bình (dưới vài chục nghìn), thực hành tốt nhất là dùng
geom_quasirandom()của gói ggbeeswarm để hiển thị trực tiếp mọi điểm dữ liệu - Các đồ họa dựa trên phân phối như violin plot và histogram không đủ vững với mẫu nhỏ
2 bình luận
Tiêu đề bài viết khá thú vị. Nếu xem bài gốc, bạn sẽ thấy có kèm các biểu đồ mẫu nên rất dễ theo dõi.
Ý kiến trên Hacker News
Một mặt, nội dung này trông khá hay
Mặt khác, có vẻ như khá nhiều trong số những biểu đồ tệ này được cố tình chọn để che giấu việc có quá ít điểm dữ liệu hoặc một phân phối nền đáng ngờ
Vì vậy, thay vì nói “nếu là bạn bè thì sẽ ngăn không cho làm kiểu này”, có lẽ đúng hơn là: “khi thấy một biểu đồ làm mọi thứ mơ hồ thay vì rõ ràng, hãy nghi ngờ rằng đó có thể là chủ ý”
Trong số các bài báo tôi từng tham gia, số lần có thái độ “đừng vội, hãy làm cho tốt hơn” là 0
Lý do biểu đồ không rõ ràng thường là vì để làm cho nó rõ thì cần thời gian và công sức, mà học thuật lại thiếu cả hai một cách nghiêm trọng. Chắc chắn đôi khi cũng có chuyện cố tình che đi các chi tiết xấu xí, nhưng tôi không nghĩ đó là nguồn chính tạo ra những hình tệ như vậy
Có nhóm thì chẳng muốn khơi ra rắc rối, có nhóm thì đơn giản là không biết. Cũng có những người đáng ra không nên làm nghiên cứu, nhưng vì đào tạo còn thiếu và cũng không dễ kiếm được nhân lực tiến sĩ giá rẻ, nên mọi thứ thành ra như bây giờ
Ví dụ “nếu là bạn bè thì sẽ không để họ làm heatmap mà lấy ngoại lệ làm giá trị tối đa” thực sự rất phổ biến. Điều này cũng thường thấy trong trực quan hóa thống kê của game video
Các game chiến lược và mô phỏng có nhiều dạng trực quan hóa để giúp người chơi hiểu tình huống hoặc vấn đề, nhưng heatmap thường khiến dải màu trở nên khá vô dụng vì hiệu ứng ngoại lệ
Ví dụ, trong Oxygen Not Included, nếu bật trực quan hóa nhiệt độ thì khi có nguồn nhiệt như núi lửa, mọi màu còn lại đều trông lạnh đi, nên màn hình thường chỉ biến thành xanh dương hoặc đỏ hồng. Bạn không thể phân biệt núi lửa 1000°C với phòng hơi nước hơi quá nhiệt khoảng 270°C; cả hai đều gần như cùng một màu đỏ hồng đồng nhất. Ngay cả căn cứ quá nóng 60°C cũng trông như lạnh một cách tương đối nên hiện ra màu xanh, khiến heatmap gần như vô dụng cho việc chẩn đoán vấn đề nhiệt độ
Thực ra, việc ý nghĩa của màu sắc thay đổi theo biến thiên nhiệt độ nghe đã là một ý tưởng khá tệ rồi
Nó vừa đóng vai trò cảnh báo điểm nóng, vừa như một lời nhắc rằng hãy bỏ qua chúng, nên thực sự rất hữu ích
Trước đây trên HN từng có một cuộc tranh cãi rất gay gắt khi có người nói rằng mọi biểu đồ mà giá trị nhỏ nhất của trục không phải là 0 đều gây hiểu lầm
Lúc đó đang bàn về biểu đồ mức tăng nhiệt độ toàn cầu do biến đổi khí hậu, và người đó nói biểu đồ gây misleading vì trục Y là nhiệt độ mà không bắt đầu từ 0. Không rõ là 0 độ F, 0 độ C hay quái quỷ hơn là 0 độ Kelvin nữa
Thậm chí họ còn nói kiểu “nếu khi đặt đáy là 0 mà thay đổi không còn nhìn thấy nữa, thì có lẽ thay đổi đó cũng không đáng kể đến thế?”. Có một thời gian niềm tin của tôi vào con người bị bóp méo ít nhiều, nhưng giờ thì may là có vẻ chúng ta đang nói chuyện ở mức cao hơn rồi. Có lẽ giai đoạn 2016~2020 đúng là một thời khác
Một biểu đồ khiến 25°C trông như “nóng hơn 25%” so với 20°C có thể bị xem là gây hiểu lầm theo nghĩa đó. Tất nhiên điều này không biện minh cho việc phủ nhận nóng lên toàn cầu
Ví dụ, đây là biểu đồ đầu tiên tôi tìm được: https://religionnews.com/wp-content/uploads/2014/08/61Years-...
Nhìn lướt qua thì có vẻ như đã giảm mất 2/3, và điều đó gây hiểu lầm. Những biểu đồ suy giảm kiểu này thường tạo ra ấn tượng thị giác không phản ánh đúng mức sụt giảm thực tế
Nếu muốn đọc thêm về trực quan hóa dữ liệu thì The Visual Display of Quantitative Information của Edward Tufte là một tài liệu tham khảo xuất sắc. Dù là tác phẩm kinh điển xuất bản lần đầu năm 1983, đến nay vẫn còn giá trị
Tuy vậy, tiền đề trung tâm của cuốn sách là “tối đa hóa tỷ lệ thông tin trên mực” nghe rất hợp lý nhưng về cơ bản có khiếm khuyết. Lý do là lượng mực, hay trên màn hình là số pixel màu đen, không đồng nghĩa với độ phức tạp thị giác. Khi não diễn giải thông tin thị giác, việc phát hiện biên, phân nhóm và các bước tiền xử lý khác đã diễn ra xong rồi.
Tác giả đưa ra ví dụ về việc trong biểu đồ phân tán, thay vì để trục gặp nhau ở góc thì rút ngắn trục để chỉ hiển thị phạm vi dữ liệu, và cho rằng đó là đôi bên cùng có lợi vì dùng ít mực hơn mà hiển thị được nhiều thông tin hơn. Nhưng khi so sánh, rõ ràng phiên bản đã chỉnh sửa lại phức tạp hơn về mặt thị giác. Nếu là một trang phức tạp có cả văn bản lẫn nhiều biểu đồ, các mảnh đó sẽ hòa lẫn vào nhau về mặt thị giác và còn tệ hơn.
Một cách để giảm kiểu phức tạp đó là bao quanh những vùng lớn như toàn bộ đồ thị bằng một khung, nhưng khung lại là kẻ thù tuyệt đối của Tufte trong cuốn sách đó và ở nhiều nơi khác. Thật ngạc nhiên là ông đã quan sát các biểu đạt thị giác lâu đến vậy mà vẫn giữ quan điểm như thế
Tukey là một trong những người cố vấn của Tufte
Nếu cần một cái nhìn tổng quan ở mức cao về cách chọn biểu đồ phù hợp với dữ liệu và câu chuyện của dữ liệu đó thì http://data-to-viz.com rất tuyệt, và các ví dụ từ nhiều thư viện vẽ đồ thị cũng là tài liệu tham khảo tốt để lấy cảm hứng. Ví dụ như https://matplotlib.org/stable/gallery/index.html
Nó rất thú vị và vẫn có liên quan, nhưng không phải kết luận cuối cùng cho chủ đề này
Nhưng nhiều người bỏ lỡ logic phía sau và chỉ sao chép nguyên xi phong cách Tufte, khiến kết quả đôi khi trông quá kiểu cách và mang tính phá bỏ biểu tượng. Biểu đồ mặc định của ggplot2 trong R là một ví dụ điển hình
Đây là bài viết điểm qua rất tốt các lỗi thường gặp trong trực quan hóa dữ liệu, nên tôi định chia sẻ với đồng nghiệp. Tài liệu bổ sung thì tôi đặc biệt khuyên đọc 39 studies about human perception in 30 mins của Kennedy Eliot: https://medium.com/@kennelliott/39-studies-about-human-perce...
Nó cho phép lướt nhanh qua cơ sở nghiên cứu đằng sau nhiều khẳng định về các thông lệ tốt trong trực quan hóa dữ liệu. Đặc biệt, sự giáo điều quanh việc không dùng biểu đồ tròn khá thú vị; đây là chủ đề khiến các nhà thiết kế khó chịu liên tục từ những năm 1930, nhưng kết quả nghiên cứu thì, ngay cả khi nhìn theo hướng tích cực, cũng không cho ra kết luận rõ ràng
Tôi vừa lướt qua bài trên Medium thì thấy có vẻ có cùng quan điểm về các vấn đề này, nên hai tài liệu có lẽ sẽ bổ sung tốt cho nhau
Ở mục “3. Nếu là bạn thì đừng để ai dùng thang màu hai chiều cho dữ liệu một chiều”, tôi không hiểu vì sao ngay từ đầu những ví dụ đó lại dùng màu
Trong nhiều trường hợp, biểu diễn một biến có thể tốt hơn khi dùng thang màu thay vì chỉ dùng mức xám. Trong những trường hợp đó, dùng thang hai chiều cho dữ liệu một chiều là tệ, và chiều ngược lại cũng vậy
Tức là đây không phải ví dụ minh họa cho việc khi nào nên dùng thang màu
Nhiều bài học kiểu này không có gì mới. Có thể xem cuốn Graphic presentation của Willard C. Brinton xuất bản năm 1939, hiện có thể truy cập miễn phí: https://archive.org/details/graphicpresentat00brinrich/mode/...
Theo mắt tôi thì những cái này vẫn đều dở cả. Có quá nhiều chartjunk, và phần lớn cũng dùng quá nhiều màu
Không cần tất cả những đường đó. Nếu tiết chế cẩn thận và bớt đi, chúng sẽ dễ đọc hơn. Bất kỳ cuốn sách nào của Edward Tufte cũng nói về điều này, và chỉ với vài kỹ thuật cơ bản thôi cũng có thể đi rất xa
Sửa lại: tôi tưởng là do Tufte tạo ra nhưng đã nhầm. https://www.amazon.com/Grammar-Graphics-Statistics-Computing...
Tôi chưa bao giờ thích biểu đồ violin, dù hoàn toàn không phải người trong lĩnh vực trực quan hóa dữ liệu. Mới khoảng một tuần trước tôi tình cờ xem video violin plots should not exist và mọi thứ bỗng trở nên sáng tỏ: https://youtu.be/_0QMKFzW9fw?feature=shared
Dựa trên nghiên cứu của Bill Cleveland, ông ấy đã có một bài thuyết trình tên là How Humans See Data, kết nối một vài ý tưởng như thế này trong một khuôn khổ nhất quán
https://www.youtube.com/watch?v=fSgEeI2Xpdc
Phần ước lượng ba giai đoạn thực sự đã mở mang tầm mắt. Về sau nhìn lại thì thấy hiển nhiên, nhưng trước khi được giải thích trực tiếp, tôi đã không thể kết nối được điều đó