Báo cáo không báo lỗi vẫn có thể đang bỏ sót dữ liệu

Có một kiểu sai sót khiến người làm báo cáo rất dễ yên tâm quá sớm: công thức không sai, quy trình chạy không báo lỗi, các ô kiểm tra đều màu xanh, nhưng câu trả lời cuối cùng vẫn thiếu một phần sự thật.

Phần bị thiếu có thể không nằm ở một phép tính. Nó nằm ở những dòng dữ liệu đã không còn xuất hiện từ trước khi phép tính bắt đầu. Một nhóm bản ghi đổi cách đặt tên. Một trạng thái mới chưa được đưa vào quy tắc phân loại. Một bảng dữ liệu cập nhật muộn hơn thường lệ. Một điều kiện lọc từng hợp lý nhưng nay âm thầm loại mất những trường hợp cần theo dõi. Báo cáo vẫn vận hành theo đúng chỉ dẫn đã được viết ra. Vấn đề là chỉ dẫn ấy không còn bao phủ thực tế.

Điều này dẫn đến một nguyên tắc đáng giữ lại: kiểm tra những gì báo cáo đã tính là cần thiết, nhưng kiểm tra những gì báo cáo không nhìn thấy cũng quan trọng không kém. Nếu chỉ nhìn vào đầu ra, nhiều sai lệch sẽ không có cơ hội tự lên tiếng.

1. Một báo cáo có thể đúng trong một phạm vi đã sai

Hãy xét một ví dụ giả định, không phải dữ liệu hay tình huống của một doanh nghiệp cụ thể. Một hệ thống tổng hợp các yêu cầu theo trạng thái. Quy tắc hiện tại biết đến ba tên trạng thái và phân chúng thành hai nhóm. Sau một lần thay đổi quy trình, nguồn phát sinh thêm tên trạng thái thứ tư. Người xây báo cáo chưa cập nhật danh sách nhận diện.

Bảng kết quả vẫn cộng đúng. Các phép đối chiếu bên trong hai nhóm được nhận diện vẫn khớp nhau. Nếu kiểm tra xem số ở từng dòng có bằng tổng các phần đã nhập hay không, câu trả lời là có. Nhưng một số yêu cầu mới đã bị loại từ cửa vào, nên tổng cuối cùng không còn đại diện cho toàn bộ yêu cầu phát sinh.

Sai số kiểu này khác với một ô công thức bị viết nhầm. Nó không nhất thiết tạo cảnh báo, vì phần lớn phép kiểm tra đang được thực hiện sau khi dữ liệu đã bị lọc. Tập dữ liệu đầu vào đã thu hẹp thì mọi phép tính phía sau vẫn có thể nhất quán với nhau.

Câu hỏi cần đặt ra không chỉ là “các số có cộng đúng không?” mà còn là “những đối tượng nào có quyền được đi vào phép cộng này?”. Không làm rõ câu hỏi thứ hai thì câu hỏi thứ nhất, dù được kiểm tra nhiều lần, vẫn chưa đủ.

2. Vì sao phần dữ liệu vắng mặt thường khó được phát hiện?

Con người dễ chú ý đến điều đang hiển thị. Khi dashboard có đường xu hướng mượt mà, bảng không có ô trống và quy trình tự động báo hoàn tất, sự chú ý thường chuyển sang diễn giải kết quả. Chính tại đây, cảm giác “đã có đủ dữ liệu” có thể xuất hiện mà chưa được chứng minh.

Dữ liệu vắng mặt lại không có màu sắc hay vị trí trên dashboard. Một nhóm bị bỏ qua không tự tạo thành một dòng mang tên “tôi đang bị thiếu”. Nếu hệ thống chỉ theo dõi số bản ghi hợp lệ và số lỗi trong bản ghi hợp lệ, những bản ghi chưa từng được đưa vào kiểm tra cũng không xuất hiện trong thống kê lỗi.

Có thêm một nghịch lý: báo cáo càng được tự động hóa ổn định, những giả định cũ càng có cơ hội tồn tại lâu. Quy trình chạy đúng lịch làm giảm nhu cầu mở dữ liệu nguồn bằng tay. Một bộ lọc có thể tiếp tục làm đúng chính xác điều được lập trình, ngay cả khi điều đó đã không còn đúng với nhu cầu kinh doanh hiện tại.

Không nên vì vậy mà quay về kiểm tra thủ công tất cả. Tự động hóa vẫn có giá trị. Điều cần thay đổi là thiết kế bộ kiểm tra: thay vì chỉ xác nhận rằng công đoạn cuối hoàn tất, hãy tạo khả năng quan sát ở cả cửa vào và những nhánh bị loại trong quá trình xử lý.

3. Phân biệt ba câu hỏi trước khi gọi một báo cáo là đáng tin

Câu hỏi thứ nhất: Dữ liệu có được đưa vào đủ không? Ở đây, “đủ” phải gắn với phạm vi đã định. Nếu báo cáo tuyên bố phản ánh một giai đoạn, một tập đối tượng hoặc một nhóm sự kiện, cần biết nguồn của phạm vi ấy có được nhận diện đầy đủ hay chưa. Số bản ghi nguồn, số bản ghi được đưa vào và số bị loại cần có khả năng đối chiếu. Không nhất thiết mọi dòng đều phải được giữ, nhưng mọi loại trừ quan trọng phải giải thích được.

Câu hỏi thứ hai: Dữ liệu có còn cùng một định nghĩa không? Một tên chỉ số có thể được giữ nguyên trong khi quy tắc ghi nhận phía sau thay đổi. Trạng thái được đổi tên, sự kiện được gửi từ một nguồn mới hoặc một nhóm đối tượng được tách nhỏ. Nếu báo cáo coi đó là thay đổi kết quả thay vì thay đổi định nghĩa, quyết định rút ra sẽ không đáng tin. Vì vậy, quy tắc nhận diện và thời điểm có hiệu lực của nó cũng là một phần của lịch sử dữ liệu.

Câu hỏi thứ ba: Các phần được đối chiếu với nhau như thế nào? Tổng ở nguồn không phải lúc nào cũng bằng tổng trên báo cáo, bởi có thể có loại trừ hợp lệ, độ trễ hoặc quy tắc loại trùng. Điều quan trọng là chênh lệch có thể được giải thích. Một báo cáo đáng tin không đòi hỏi hai con số luôn bằng nhau trong mọi hoàn cảnh; nó đòi hỏi biết vì sao chúng bằng nhau hoặc vì sao chúng khác nhau.

Ba câu hỏi này không thay thế việc kiểm tra công thức, khóa dữ liệu hay kiểu dữ liệu. Chúng bổ sung một lớp trước đó: bảo đảm rằng đối tượng đang được đo thật sự là đối tượng người đọc tưởng mình đang nhìn thấy.

4. Khi một thay đổi giả trông giống kết quả thật

Giả sử một báo cáo cho thấy tỷ lệ xử lý thành công cao hơn kỳ trước. Phản ứng đầu tiên có thể là tin rằng quy trình đã tốt lên. Nhưng có ít nhất hai cách diễn giải khác nhau: chất lượng xử lý thật sự cải thiện, hoặc một nhóm trường hợp khó đã biến mất khỏi mẫu số vì cách phân loại thay đổi.

Hai tình huống có thể cho ra cùng một biểu đồ, nhưng dẫn đến hai quyết định trái ngược. Ở tình huống đầu, điều cần làm có thể là tìm nguyên nhân tạo ra cải thiện và giữ lại cách làm hiệu quả. Ở tình huống sau, ưu tiên phải là sửa hệ đo lường trước khi thảo luận về thành tích.

Một nguyên tắc tương tự áp dụng khi số lượng đột ngột giảm. Giảm có thể đến từ nhu cầu thực tế, nhưng cũng có thể đến từ dữ liệu đến muộn, lỗi nối bảng hoặc một điều kiện lọc không còn nhận diện được định dạng mới. Nếu không phân biệt được thay đổi của thế giới với thay đổi trong cách hệ thống quan sát thế giới, báo cáo sẽ trộn lẫn hai loại tín hiệu.

Vì thế, tỷ lệ luôn cần được đọc cùng quy mô, và xu hướng luôn cần được đọc cùng mức độ bao phủ. Một thay đổi đẹp về tỷ lệ không đủ để kết luận rằng công việc đã tạo ra nhiều giá trị hơn. Trước hết phải biết mẫu số còn là mẫu số mình đã định nghĩa hay không.

5. Những phép kiểm tra quen thuộc làm được gì và chưa làm được gì?

Các công cụ hiện nay đã có nền tảng kiểm tra dữ liệu khá thực dụng. Chẳng hạn, tài liệu chính thức của dbt mô tả những phép thử phổ biến để tìm khóa trùng, giá trị rỗng, giá trị nằm ngoài danh sách cho phép hoặc mối quan hệ không hợp lệ giữa các bảng. Đây là các phép kiểm tra hữu ích, đặc biệt khi giả định về dữ liệu được viết thành điều kiện rõ ràng.

Nhưng việc một cột vượt qua kiểm tra không trùng hoặc không rỗng không tự chứng minh rằng mọi bản ghi cần thiết đã xuất hiện trong bảng. Nếu các trường hợp bị loại bỏ từ bước trước, chúng không còn ở đó để bị phát hiện là sai. Kiểm tra một tập dữ liệu đúng cách và kiểm tra phạm vi của tập dữ liệu là hai công việc liên quan, nhưng không giống nhau.

Tài liệu dbt về freshness cũng cho thấy tính cập nhật cần có kỳ vọng rõ ràng: nguồn nào phải đến trong khoảng thời gian nào, khi nào nên cảnh báo và khi nào nên coi là lỗi. Dữ liệu được lưu đúng cấu trúc nhưng chưa cập nhật đủ kỳ vẫn có thể làm méo cách hiểu xu hướng.

Tương tự, tài liệu Google Cloud về kiểm tra chất lượng dữ liệu cho phép định nghĩa quy tắc và điều kiện lựa chọn dữ liệu khi quét. Điều đó gợi ra câu hỏi không nên bỏ qua: chính tập dữ liệu được chọn để kiểm tra có phải là phạm vi cần ra quyết định hay không? Công cụ giúp thực thi điều kiện; con người vẫn phải chịu trách nhiệm xác định điều kiện đúng.

6. Một thói quen nhỏ trước khi tin vào kết quả

Không cần biến mỗi báo cáo thành một dự án kiểm toán lớn. Có thể bắt đầu bằng một bảng đối chiếu rất nhỏ đặt trước phần phân tích: số bản ghi nguồn trong phạm vi, số bản ghi được nhận diện, số bị loại có lý do, số chưa phân loại và thời điểm dữ liệu cập nhật gần nhất.

Điểm đáng giá của bảng đối chiếu không nằm ở việc có thêm nhiều chỉ số. Nó biến phần vô hình thành thứ có thể hỏi đến. Nếu nhóm chưa phân loại xuất hiện, quy trình biết rằng có một giả định cần xem xét. Nếu số bản ghi nguồn khác thường, người đọc được nhắc kiểm tra lịch nhập và tính đầy đủ trước khi diễn giải. Nếu có thay đổi quy tắc, kỳ báo cáo có thể được đánh dấu để tránh so sánh như thể mọi thứ không đổi.

Một cách triển khai đơn giản là giữ lại cả những dòng chưa khớp quy tắc thay vì âm thầm xóa chúng. Chúng có thể nằm trong một danh sách chờ kiểm tra. Mỗi lần mở rộng hoặc sửa cách nhận diện cần có ghi chú về thời điểm bắt đầu, phạm vi ảnh hưởng và cách đối chiếu dữ liệu của các kỳ trước. Với hệ thống quan trọng, nên kiểm tra trên một tập mẫu có cả trường hợp bình thường và trường hợp ngoại lệ.

Điều này cũng giúp tránh một sai lầm khác: mỗi khi phát hiện thiếu dữ liệu thì vội sửa lịch sử để biểu đồ trở nên đẹp và liên tục. Dữ liệu quá khứ có thể được hiệu chỉnh khi có bằng chứng, nhưng việc thay đổi định nghĩa phải được công khai trong phạm vi quản trị báo cáo. Một biểu đồ liền mạch không có giá trị nếu người đọc không biết các giai đoạn đang được đo bằng những tiêu chuẩn khác nhau.

7. Không phải mọi chênh lệch đều là lỗi

Cẩn trọng với dữ liệu không có nghĩa là yêu cầu mọi số liệu phải khớp tuyệt đối. Một hệ thống có thể có thời gian chờ ghi nhận, có trễ giữa các nguồn, có bản ghi được loại trừ hợp lệ hoặc có những sự kiện không cần đưa vào KPI cuối cùng. Sự khác biệt đó không tự động làm báo cáo sai.

Điểm phân biệt nằm ở việc có quy tắc trước khi xem kết quả hay không. Nếu phạm vi loại trừ được xác định rõ, bản ghi bị loại được ghi nhận và độ trễ nằm trong mức đã chấp nhận, chênh lệch có thể là một phần hợp lý của thiết kế. Ngược lại, nếu chỉ sau khi nhìn thấy con số bất thường mới tìm một lời giải thích vừa khớp với kết quả, hệ thống đang có nguy cơ hợp lý hóa sai lệch.

Một quy trình trưởng thành nên cho phép trả về trạng thái “chưa đủ tín hiệu để kết luận”. Đó không phải thất bại của người lập báo cáo. Đó là ranh giới cần thiết giữa điều dữ liệu đã xác nhận và điều chúng ta mới đang nghi ngờ. Khi dữ liệu chưa đầy đủ, quyết định có thể được trì hoãn, thu hẹp phạm vi hoặc chuyển thành một thử nghiệm nhỏ có theo dõi.

8. Đặt câu hỏi về phần vắng mặt trước khi tối ưu phần hiển thị

Một công cụ biểu đồ tốt có thể giúp người đọc phát hiện bất thường trong dữ liệu đang có. Một quy trình kiểm chứng tốt còn phải nhắc người đọc hỏi điều gì đã không đến được biểu đồ. Hai khả năng này cần đi cùng nhau, nhất là khi báo cáo bắt đầu được dùng để tự động đưa ra khuyến nghị hoặc kích hoạt hành động.

Trước khi đánh giá một kết quả tốt hơn, có thể hỏi ba điều: nguồn có còn đủ không, định nghĩa có còn như cũ không và phần chênh lệch có thể giải thích không. Chỉ sau đó mới nên bàn sâu đến nguyên nhân kinh doanh và hành động tiếp theo.

Đôi khi, thứ đáng kiểm tra nhất trong một bảng báo cáo không phải con số đang nổi bật ở giữa màn hình. Đó là những dòng dữ liệu đã biến mất từ lâu, đến mức không còn ai nhớ rằng chúng phải có mặt.

---

Về phạm vi và nguồn: Bài viết phát triển một nguyên tắc kiểm chứng dữ liệu thành góc nhìn làm việc, không kể lại một trường hợp cá nhân, khách hàng hay doanh nghiệp có thật. Những tình huống trong bài đều là giả định để minh họa. Tài liệu chính thức của dbt và Google Cloud được dùng để kiểm chứng khả năng kiểm tra dữ liệu nêu trong bài; chúng không được xem là bằng chứng cho một trường hợp thực tế cụ thể.