Ba tư duy để dữ liệu thực sự cất lên tiếng nói là cách tiếp cận giúp người làm Data và AI không chỉ xử lý dữ liệu cho đúng về mặt kỹ thuật, mà còn nhìn thấy những vấn đề dễ bị bỏ sót, hiểu đúng ý nghĩa của dữ liệu và khám phá được các mối quan hệ, mẫu hình, quy luật đang ẩn bên trong.
Trong một dự án Data, dữ liệu không tự nói cho chúng ta biết rằng:
- Tôi đang thiếu một khoảng thời gian,
- Giá trị 0 này có ý nghĩa khác,
- Nhóm nhỏ này đang có hành vi bất thường hay
- Quy luật thật sự chỉ xuất hiện khi kết hợp ba biến với nhau.
Dữ liệu ở trạng thái bị động. Người phân tích phải chủ động tìm kiếm, đặt câu hỏi, kiểm tra và đào sâu.
Ở bài trước về những cái bẫy dữ liệu khi làm dự án Data, có thể gom các vấn đề thành ba nhóm lớn:
- Dễ sót : khiến dữ liệu có điều đáng nói nhưng chúng ta không nghe thấy.
- Dễ nhầm : khiến dữ liệu nói một điều nhưng chúng ta lại hiểu thành điều khác.
- Dễ bỏ qua : khiến chúng ta mới nhìn thấy phần nổi và chưa khám phá hết câu chuyện.
Tương ứng với ba cái bẫy lớn đó, người làm Data/AI cần hình thành ba tư duy:
TÌM ĐỦ → HIỂU ĐÚNG → ĐÀO SÂU
Đây không phải ba bước máy móc phải thực hiện lần lượt. Đó là ba cách tư duy cần được duy trì xuyên suốt quá trình làm việc với dữ liệu.
Vì sao dữ liệu cần được làm cho lên tiếng?
Một dataset có thể chứa hàng trăm nghìn hay hàng triệu dòng dữ liệu nhưng điều đó không có nghĩa chúng ta đã có thông tin. Chúng ta có thể chạy:
- df.head()
- df.info()
- df.describe()
Có thể tính trung bình, tổng, min, max, correlation. Có thể vẽ hàng chục biểu đồ. Thậm chí có thể xây dựng một mô hình Machine Learning với metric rất đẹp. Nhưng vẫn chưa chắc chúng ta đã thực sự hiểu dữ liệu.
Một dự án Data có giá trị không chỉ vì nó trả lời được: Dữ liệu có bao nhiêu dòng? mà còn phải tiến tới những câu hỏi sâu hơn:
- Dữ liệu đang thiếu điều gì?
- Những giá trị này thực sự có nghĩa gì?
- Có nhóm nào đang hành xử khác phần còn lại?
- Điều gì thay đổi theo thời gian?
- Những yếu tố nào đang đi cùng nhau?
- Có quy luật nào chỉ xuất hiện khi nhiều điều kiện đồng thời xảy ra?
- Phát hiện vừa tìm được có thực sự đáng tin không?
Đó cũng là lý do ba tư duy để dữ liệu thực sự cất lên tiếng nói trở nên quan trọng: người phân tích phải biết tìm phần còn thiếu, hiểu đúng những gì đang thấy và tiếp tục đào sâu để khám phá các quy luật ẩn.
1. Tư duy Tìm Đủ:: Bức tranh dữ liệu có đủ chưa?
Tư duy đầu tiên là: TÌM ĐỦ . Tìm đủ không có nghĩa là phải thu thập càng nhiều dữ liệu càng tốt.
Tìm đủ có nghĩa là: Chủ động kiểm tra xem bức tranh dữ liệu mà mình đang nhìn có bị thiếu những mảnh quan trọng nào hay không.
Đây là tư duy trực tiếp giúp tránh nhóm bẫy DỄ SÓT.
Đừng chỉ nhìn những gì đang có
Một trong những sai lầm phổ biến khi bắt đầu phân tích là mặc nhiên cho rằng: Dataset có gì thì thực tế có như vậy.
Nhưng dữ liệu chúng ta nhận được chỉ là những gì đã được thu thập, lưu trữ, truyền đi và giữ lại qua nhiều công đoạn.
Một khoảng thời gian có thể bị mất hoàn toàn. Có khi một nhóm đối tượng có thể không xuất hiện. Cũng có lúc một biến quan trọng có thể chưa từng được thu thập. Một bảng phụ có thể thiếu record tương ứng. Một nhóm dữ liệu có thể biến mất sau bước lọc hoặc JOIN.
Điều nguy hiểm là những thứ đó đôi khi không tạo ra NULL để chúng ta dễ dàng phát hiện.
Nếu ngày 15/7 hoàn toàn không có record, isnull() cũng không thể nói: Bạn đang thiếu ngày 15/7.
Bởi vì ngày đó không tồn tại trong dataset. Vì vậy cần nhớ: Không thấy không có nghĩa là không tồn tại.
Tìm đủ đối tượng
Giả sử đang phân tích dữ liệu khách hàng. Có 50.000 khách hàng trong dataset.
Câu hỏi không chỉ là: Có bao nhiêu khách hàng? Mà phải hỏi thêm: Có loại khách hàng nào đáng lẽ phải xuất hiện nhưng hoàn toàn không có không?
Một nhóm tuổi bị thiếu? Vài khu vực không có record? Một loại sản phẩm không xuất hiện? Một nhóm người dùng mới chưa được tích hợp vào hệ thống?
Nếu không hỏi, phần thiếu đó sẽ không tự lên tiếng.
Tìm đủ thời gian
Với dữ liệu có Date hoặc Timestamp, cần đặc biệt kiểm tra độ phủ theo thời gian.
Giả sử dữ liệu chạy liên tục từ tháng 1 đến tháng 12. Nhìn qua có vẻ đầy đủ.
Nhưng nếu mất toàn bộ ba ngày trong tháng 8 thì sao?
Hoặc một hệ thống chỉ bắt đầu ghi nhận một thuộc tính từ tháng 6?
Nếu không kiểm tra timeline, kết quả phân tích có thể khiến chúng ta tưởng rằng một hiện tượng không xảy ra, trong khi thực tế chỉ là: không có dữ liệu để quan sát hiện tượng đó.
Tìm đủ thuộc tính
Một dataset có 50 cột chưa chắc đã đủ.
Có thể thiếu đúng một yếu tố quan trọng nhất để giải thích target.
Ví dụ muốn phân tích thời gian giao hàng nhưng không có thông tin khoảng cách.
Muốn phân tích doanh số nhưng không có thông tin khuyến mãi.
Muốn đánh giá rủi ro tín dụng nhưng thiếu một biến thể hiện lịch sử thanh toán quan trọng.
Điều cần hỏi không chỉ là: Dataset có những cột nào?
Mà còn là: Để hiểu bài toán này, tôi cần biết điều gì? Và dữ liệu hiện tại đã có thông tin đó chưa?
Tìm đủ liên kết
Khi dữ liệu nằm trong nhiều bảng, một record ở bảng này có thể không tìm được thông tin tương ứng ở bảng khác. Ví dụ :
- Có đơn hàng nhưng không có thông tin khách hàng.
- Có giao dịch nhưng không tìm được sản phẩm.
- Có cửa hàng nhưng không có metadata tương ứng.
Nếu JOIN xong chỉ kiểm tra xem SQL có chạy hay không thì rất dễ bỏ qua những record bị mất.
Tư duy TÌM ĐỦ buộc người phân tích phải hỏi: Có record nào không match không? Vì sao không match? Phần dữ liệu bị mất đó có đặc điểm chung gì không?
Câu hỏi cốt lõi của TÌM ĐỦ
Có thể cô đọng toàn bộ tư duy này thành một câu: Có điều gì đáng lẽ phải có nhưng tôi chưa nhìn thấy?
Đó là câu hỏi rất đơn giản nhưng có khả năng giúp phát hiện hàng loạt vấn đề mà các lệnh kiểm tra thông thường không chỉ ra được.
2. Tư duy Hiểu Đúng: Điều tôi đang thấy thực sự có nghĩa gì?
Có dữ liệu chưa có nghĩa là đã hiểu dữ liệu. Vì vậy tư duy thứ hai là: HIỂU ĐÚNG
Nếu TÌM ĐỦ giúp tránh bỏ sót thì HIỂU ĐÚNG giúp tránh nghe nhầm tiếng nói của dữ liệu.
Một phép tính có thể hoàn toàn chính xác về kỹ thuật nhưng kết luận cuối cùng vẫn sai nếu người phân tích hiểu sai ý nghĩa của dữ liệu đầu vào.
Trước khi hỏi bao nhiêu?, hãy hỏi nó có nghĩa là gì?
Giả sử một cột có giá trị: 0 . Đối với máy tính, đó chỉ đơn giản là số 0.
Nhưng đối với bài toán thực tế, số 0 có thể nghĩa là không có, chưa xảy ra, không áp dụng, chưa thu thập, dữ liệu mặc định hoặc thực sự có giá trị bằng 0. Ví dụ:
- Sales = 0
- Open = 0
có thể nghĩa là cửa hàng đóng cửa. Nhưng:
- Sales = 0
- Open = 1
lại là một tình huống hoàn toàn khác và đáng điều tra.
Nếu chỉ nhìn Sales = 0, chúng ta đã bỏ mất context.
Do đó: Một con số không tự mang đầy đủ ý nghĩa. Ý nghĩa đến từ ngữ cảnh.
Hiểu đúng một dòng dữ liệu
Một câu hỏi rất quan trọng nhưng thường bị bỏ qua là: Một row dữ liệu thực sự đại diện cho cái gì? Đây chính là grain của dữ liệu.
Một dòng có thể đại diện cho một khách hàng, một giao dịch, một đơn hàng, một sản phẩm trong đơn hàng, một cửa hàng trong một ngày hoặc một lần tương tác.
Nếu hiểu sai grain, rất nhiều thống kê phía sau sẽ sai.
Ví dụ một đơn hàng gồm 5 sản phẩm.
Nếu dataset ở cấp order_item, đơn hàng đó xuất hiện thành 5 dòng.
Nếu chạy: COUNT(*) rồi gọi kết quả là: Tổng số đơn hàng thì kết quả đã sai.
Điểm nguy hiểm là: SQL vẫn chạy. Python vẫn chạy. Dashboard vẫn hiển thị. Biểu đồ vẫn đẹp.
Sai không nằm ở cú pháp. Mà cái sai nằm ở cách hiểu dữ liệu.
Hiểu đúng quan hệ giữa các bảng
Các dự án Data thực tế hiếm khi chỉ có một bảng.
Khi JOIN dữ liệu, cần biết chính xác quan hệ giữa các bảng là: one-to-one, one-to-many hay many-to-many.
Giả sử trước JOIN có 100.000 dòng. Sau JOIN thành 150.000 dòng.
Điều đó có thể hoàn toàn hợp lý. Nhưng cũng có thể là hậu quả của việc key ở bảng bên phải không unique.
Nếu không hiểu relation, các phép tính phía sau có thể bị biến dạng: tổng tăng, trung bình thay đổi, tỷ lệ sai và model học trên những record bị nhân bản.
Vì vậy: JOIN thành công không đồng nghĩa với JOIN đúng.
Người làm dữ liệu cần hiểu bản chất của mối quan hệ, chứ không chỉ biết viết câu SQL chạy được.
Hiểu đúng điều dữ liệu cho phép mình kết luận
Một lỗi khác là nghe nhiều hơn những gì dữ liệu thực sự nói. Giả sử hai feature A và B có correlation rất cao.
- Dữ liệu đang nói: A và B thường thay đổi cùng nhau.
- Nhưng người phân tích lại viết: A làm B tăng.
Hai câu này hoàn toàn khác nhau.
Có thể C tác động đồng thời lên A và B. Rồi có thể B tác động A. Có thể cả hai cùng thay đổi vì thời gian hoặc một điều kiện khác.
Do đó một nguyên tắc quan trọng là: Không chỉ làm dữ liệu nói, mà còn phải không nghe quá những gì dữ liệu thực sự nói.
Đây chính là tư duy HIỂU ĐÚNG.
Câu hỏi cốt lõi của HIỂU ĐÚNG
Khi đối diện với một giá trị, biểu đồ hay kết quả phân tích, hãy tự hỏi: Điều tôi đang thấy thực sự có nghĩa gì?
Và đặc biệt: Đây là điều dữ liệu chứng minh, hay là điều tôi đang tự suy diễn thêm?
Hai câu hỏi này có thể ngăn được rất nhiều kết luận sai.
3. Tư duy Đào Sâu: Bên dưới phần nổi còn điều gì?
- Tìm đủ giúp chúng ta không thiếu nền tảng.
- Hiểu đúng giúp chúng ta không diễn giải sai.
- Nhưng nếu chỉ dừng ở đó, dữ liệu vẫn chưa thực sự cất lên tiếng nói.
Muốn tìm được những mối quan hệ và quy luật ẩn, cần tư duy thứ ba: ĐÀO SÂU
Đây là quá trình đi từ những mô tả đơn giản đến những phát hiện có ý nghĩa hơn.
Một phát hiện đầu tiên chỉ là lớp bề mặt
Giả sử phân tích cho thấy:
Nhóm A có doanh thu cao hơn nhóm B. Đây là một observation — một quan sát.
Nhưng đừng dừng lại. Hãy hỏi: WHY? – Tại sao?
- Có phải nhóm A có nhiều khách hơn?
- Có phải giá trị giao dịch lớn hơn?
- Có promotion?
- Có khác biệt về thời gian?
- Có một nhóm nhỏ bên trong tạo nên mức tăng đó?
Từ một observation, chúng ta bắt đầu hình thành giả thuyết.
Và sau đó quay lại dữ liệu để kiểm tra. Đó chính là quá trình đào sâu.
WHY? – Tại sao?
WHY? giúp chuyển từ: Chuyện gì xảy ra? sang: Điều gì có thể giải thích chuyện đó?
Ví dụ: Doanh số cuối tuần cao hơn. WHY?
- Có nhiều khách hơn?
- Khách mua nhiều hơn?
- Có nhiều chương trình khuyến mãi hơn?
- Một nhóm cửa hàng đặc biệt tạo ra mức tăng?
Không phải giả thuyết nào cũng đúng. Nhưng việc hình thành giả thuyết giúp người phân tích biết câu hỏi tiếp theo cần kiểm tra là gì.
WHAT ELSE? – Còn gì nữa?
Đây là một câu hỏi rất mạnh khi phân tích dữ liệu.
Giả sử phát hiện: Ngày có Promotion thường có Sales cao hơn.
Nếu dừng ở đây, câu chuyện rất đơn giản. Hãy hỏi: WHAT ELSE? – Còn gì nữa?
- Có giống nhau ở tất cả các nhóm không? Có thể không.
- Nhóm nào có khác biệt lớn nhất?
- Có phải hiệu ứng giống nhau vào mọi ngày?
- Có cửa hàng nào hoàn toàn không theo pattern chung?
- Có phải Promotion chỉ liên quan mạnh tới Sales trong một số điều kiện nhất định?
Từ một phát hiện đơn giản: Promotion ↔ Sales có thể đi sâu thành: Promotion liên quan mạnh hơn tới Sales trong một nhóm nhất định và tại một số thời điểm nhất định.
Đó là một quy luật sâu hơn.
Đổi góc nhìn để dữ liệu kể câu chuyện khác
ĐÀO SÂU không chỉ là chạy thêm nhiều câu lệnh.
Một trong những cách quan trọng nhất là thay đổi góc nhìn.
Một kết quả nhìn ở toàn bộ dataset có thể hoàn toàn bình thường.
- Nhưng khi tách theo nhóm, sự khác biệt xuất hiện.
- Nhìn theo thời gian có thể thấy trend.
- Nhìn phân bố có thể thấy skew, cluster hoặc outlier.
- Kết hợp hai biến có thể xuất hiện một quan hệ.
- Kết hợp ba biến có thể phát hiện một nhóm có hành vi hoàn toàn khác.
Điều quan trọng là: Mỗi góc nhìn mới phải giúp kiểm tra một câu hỏi mới.
So sánh để làm khác biệt xuất hiện
Một con số đứng riêng thường rất ít ý nghĩa. Ví dụ:
- Doanh thu = 100 triệu đồng. Cao hay thấp? Chưa thể biết.
- Nhưng nếu: tháng trước = 70 triệu đồng;
- … thì đã có câu chuyện.
Hoặc:
- nhóm A = 100 triệu;
- nhóm B = 50 triệu;
- … lại xuất hiện một câu chuyện khác.
So sánh là một trong những công cụ tư duy mạnh nhất trong Data Analysis.
So sánh theo nhóm, theo thời gian, trước và sau, có và không, bình thường và bất thường giúp những khác biệt vốn bị ẩn trong dữ liệu bắt đầu xuất hiện.
Bóc tách để tìm nơi khác biệt thực sự nằm
Giả sử toàn bộ hệ thống tăng trưởng 5%.
Có thể rất khó tìm ra insight nếu chỉ nhìn con số tổng.
Bóc xuống một lớp có thể phát hiện một nhóm tăng 30%, một nhóm gần như không thay đổi và một nhóm giảm 20%.
Tiếp tục bóc tách có thể phát hiện sự khác biệt chỉ tập trung tại một khu vực hoặc một thời điểm.
Tư duy này có thể hình dung như: Tổng thể → nhóm → nhóm nhỏ → điều kiện cụ thể.
Nhưng không phải chia dữ liệu vô hạn cho đến khi tìm được thứ mình muốn.
Mỗi lần bóc tách phải xuất phát từ một câu hỏi hợp lý.
Kết nối các biến để tìm quy luật ẩn
Nhiều quy luật không nằm trong một feature riêng lẻ.
- Biến A một mình có thể không đặc biệt.
- Biến B một mình cũng không đặc biệt.
- Nhưng A và B cùng xuất hiện thì target thay đổi rõ rệt.
Đó là interaction.
Trong AI, điều này đặc biệt quan trọng bởi model thường học được các mối quan hệ đa biến mà khi EDA chúng ta rất dễ bỏ qua.
Người phân tích vì vậy không nên chỉ hỏi: Biến nào ảnh hưởng đến target?
Mà nên hỏi sâu hơn: Trong điều kiện nào mối quan hệ đó thay đổi?
Đây chính là một bước quan trọng để từ EDA đi tới Feature Engineering.
Đào sâu phải đi cùng kiểm chứng
Có một nguy hiểm rất lớn: Đào càng nhiều, chúng ta càng dễ tìm thấy một thứ trông có vẻ thú vị chỉ do ngẫu nhiên.
Vì vậy: ĐÀO SÂU phải luôn đi cùng KIỂM CHỨNG.
Một phát hiện ban đầu chỉ nên được xem là manh mối.
Có thể kiểm tra lại bằng dữ liệu gốc, khoảng thời gian khác, nhóm khác, biểu đồ khác, một chỉ số thống kê khác hoặc kiến thức nghiệp vụ.
Một cách tư duy rất hữu ích là: Đừng chỉ tìm cách chứng minh phát hiện của mình đúng. Hãy thử tìm cách chứng minh nó sai.
Nếu sau nhiều lần kiểm tra pattern vẫn tồn tại, nó mới bắt đầu đáng tin.
Finding chưa chắc đã là Insight
Trong Data Analysis, hai khái niệm này rất dễ bị trộn lẫn.
Một finding là thứ ta vừa phát hiện. Ví dụ: Nhóm A cao hơn nhóm B 25%.
Nhưng đó chưa chắc đã là insight. Muốn trở thành insight, cần hiểu:
- Vì sao khác?
- Sự khác biệt có ổn định không?
- Nó xuất hiện trong điều kiện nào?
- Nó có ý nghĩa gì?
Một cách diễn đạt đơn giản: Finding + Context + Verification + Interpretation → Insight
Không phải mọi chart đều tạo ra insight.
Không phải mọi correlation đều là insight.
Và không phải một con số khác biệt lớn đã tự động trở thành insight.
SO WHAT? – Rồi sao?
Sau khi tìm được một quy luật, câu cuối cùng phải hỏi là: SO WHAT?
Nghĩa đơn giản là: Rồi sao? Điều đó có ý nghĩa gì?
Ví dụ: Nhóm A có tỷ lệ cao hơn nhóm B 25%. SO WHAT?
- Phát hiện này giúp chúng ta hiểu gì?
- Có cần xử lý hai nhóm khác nhau?
- Có nên tạo feature mới?
- Có cần phân khúc dữ liệu?
- Có phải giả thuyết ban đầu cần thay đổi?
- Có nên xem xét model riêng?
Đối với dự án AI, So what? không nhất thiết phải dẫn đến một quyết định kinh doanh.
Nó có thể dẫn tới một quyết định kỹ thuật như:
- nên tạo thêm feature thời gian;
- cần xử lý seasonality;
- cần tạo interaction feature;
- cần tách một nhóm dữ liệu;
- không nên sử dụng một biến;
- cần kiểm tra leakage;
- kết luận EDA ban đầu chưa đủ cơ sở.
Đó vẫn là những insight rất có giá trị.
Tìm Đủ – Hiểu Đúng – Đào Sâu liên kết với nhau như thế nào?
Ba tư duy để dữ liệu thực sự cất lên tiếng nói không phải ba công đoạn độc lập mà tạo thành một vòng lặp xuyên suốt dự án Data/AI
- TÌM ĐỦ đặt câu hỏi: Tôi còn chưa nhìn thấy cái gì?
- HIỂU ĐÚNG tiếp tục: Điều tôi đang thấy thực sự có nghĩa gì?
- ĐÀO SÂU hỏi: Bên dưới những gì vừa thấy còn có điều gì nữa?
Trong lúc đào sâu, chúng ta có thể phát hiện một khoảng dữ liệu bị thiếu thì quay lại TÌM ĐỦ.
Có thể phát hiện định nghĩa ban đầu của một feature chưa đúng thì quay lại HIỂU ĐÚNG.
Có thể xuất hiện một giả thuyết mới thì tiếp tục ĐÀO SÂU.
Vì vậy, một dự án Data tốt không đi theo đường thẳng kiểu như : Data → Clean → Chart → Model → Xong.
Mà thực tế thường là một vòng lặp: Quan sát → đặt câu hỏi → kiểm tra → hiểu lại → đào sâu → phát hiện mới → đặt câu hỏi mới.
Ba câu hỏi nên mang theo trong mọi dự án Data/AI
Nếu cần cô đọng toàn bộ tư duy trong bài thành ba câu hỏi, hãy nhớ:
- TÌM ĐỦ: Bức tranh dữ liệu đã đủ chưa?
- HIỂU ĐÚNG: Điều tôi đang thấy thực sự có nghĩa gì?
- ĐÀO SÂU: Bên dưới phần nổi còn điều gì chưa được phát hiện?
Ba câu hỏi này có thể áp dụng từ lúc đọc dataset, kiểm tra dữ liệu, JOIN bảng, cleaning, EDA, Feature Engineering cho đến khi xây dựng và đánh giá mô hình.
Không phải càng nhiều công cụ thì dữ liệu càng nói
Python, SQL, Pandas, PostgreSQL, Power BI, Machine Learning hay AI đều là những công cụ rất mạnh.
Nhưng công cụ không tự bảo đảm rằng chúng ta sẽ hiểu đúng dữ liệu. Hai người có thể sử dụng cùng một dataset và cùng một bộ công cụ.
Một người chỉ dừng ở: head(), info(), describe(), vài biểu đồ và một model.
Người còn lại liên tục hỏi:
- Có gì thiếu?
- Giá trị này nghĩa là gì?
- Nếu tách nhóm thì sao?
- Nếu nhìn theo thời gian thì sao?
- Tại sao?
- Còn gì nữa?
- Điều này có thực sự đúng?
- Rồi sao?
Kết quả của hai dự án có thể hoàn toàn khác nhau. Bởi vậy: Kỹ thuật giúp chúng ta xử lý dữ liệu. Tư duy quyết định chúng ta nhìn thấy gì trong dữ liệu.
Kết luận
Ba tư duy để dữ liệu thực sự cất lên tiếng nói có thể được cô đọng thành ba nguyên tắc rất đơn giản: TÌM ĐỦ để không bỏ mất những mảnh ghép quan trọng, HIỂU ĐÚNG để không nghe sai điều dữ liệu thực sự thể hiện và ĐÀO SÂU để những mối quan hệ, khác biệt và quy luật đang ẩn phải lộ ra.
Dữ liệu không tự kể cho chúng ta câu chuyện hoàn chỉnh.
Một dataset cũng không tự chỉ ra đâu là insight quan trọng nhất.
Người làm Data/AI phải chủ động đặt câu hỏi, kiểm tra, so sánh, bóc tách, kết nối và kiểm chứng.
Và có lẽ ba câu hỏi đáng mang theo nhất trong mọi dự án là:
- Tôi còn chưa nhìn thấy điều gì?
- Điều tôi đang thấy có thực sự mang ý nghĩa như tôi nghĩ không?
- Còn điều gì nằm phía dưới những gì vừa phát hiện?
Khi ba cách tư duy này được thực hiện, chúng ta không còn chỉ xử lý dữ liệu. Chúng ta bắt đầu hiểu dữ liệu. Và đó chính là lúc dữ liệu thực sự cất lên tiếng nói.
