Phép đo không thể sai thì không đo gì cả

Có một buổi sáng gần đây, một AI agent trong đội tôi chạy một câu kiểm tra rất đơn giản trên hệ thống của chúng tôi: trong toàn bộ dữ liệu người dùng, có địa chỉ email nào bị trùng theo kiểu chỉ khác nhau chữ hoa chữ thường không? Câu trả lời trở về gọn gàng: 0 dòng.

Đó là một con số đẹp. Nó có nghĩa là không ai bị ảnh hưởng, không có gì phải sửa, có thể đi làm việc khác.

Tôi suýt tin nó.

Thứ cứu chúng tôi là một cột thứ hai nằm ngay cạnh, tình cờ có mặt trong cùng câu lệnh: trong 1.118 địa chỉ, có bao nhiêu địa chỉ chứa dù chỉ một chữ hoa? Kết quả: 0.

Toàn bộ dữ liệu đó do máy sinh ra, và máy luôn viết chữ thường. Muốn có hai bản viết khác nhau về hoa-thường thì trước hết phải có chữ hoa. Không có chữ hoa nào, nên không có khả năng nào để phép đo ấy trả về một con số khác 0. Con số 0 kia không nói gì về sức khoẻ của hệ thống. Nó chỉ mô tả hình dạng của bộ dữ liệu mà câu lệnh vừa chĩa vào.

Cùng câu lệnh đó, chạy trên môi trường có dữ liệu người thật nhập tay, trả về 3 địa chỉ có chữ hoa trên 807. Và chính vì nó đếm được số 3, con số 0 bên cạnh mới trở thành một thông tin.

Một con số chỉ là bằng chứng khi ta gọi tên được cái đầu vào lẽ ra đã làm nó sai. Nếu không dựng được tình huống nào khiến nó đỏ, thì màu xanh không phải kết quả đo — nó là trang trí.

Bài viết này về khoảng cách giữa hai thứ mà các tổ chức gộp làm một hàng ngày: việc có đo và việc biết được điều gì.

Ba khuôn mặt của cùng một lỗi

Đây không phải một lỗi kỹ thuật. Nó là một lỗi về nhận thức, và nó xuất hiện ở mọi tầng của một doanh nghiệp — chỉ đổi trang phục.

Khuôn mặt thứ nhất: phép đo không thể đỏ

Đây là ca ở trên. Một chỉ số được cấu trúc sao cho nó chỉ có thể xanh, bất kể chuyện gì đang xảy ra bên dưới.

Nó phổ biến hơn ta tưởng, vì nó không bao giờ tự lộ ra. Một chỉ số hỏng theo kiểu báo động giả thì ồn ào và sẽ được sửa trong tuần. Một chỉ số hỏng theo kiểu không bao giờ báo động thì im lặng tuyệt đối, và sự im lặng ấy được đọc thành “mọi thứ ổn” mỗi ngày, trong nhiều năm.

Đổi sang ngôn ngữ vận hành, nó là: tỷ lệ khiếu nại tính trên số phiếu khiếu nại đã được nhập vào hệ thống — trong khi phần lớn khách bực mình thì bỏ đi chứ không nhập phiếu. Là chỉ số an toàn lao động đếm số vụ được báo cáo, ở một nơi mà báo cáo tai nạn thì tổ trưởng bị trừ thưởng. Là tỷ lệ giao hàng đúng hạn, với “hạn” được nhập vào hệ thống sau khi hàng đã đi.

Trong cả ba, con số đều thật, đều tính đúng, và đều không đo cái mà người đọc nó tưởng.

Khuôn mặt thứ hai: dụng cụ không nhìn thấy thứ nó đi tìm

Cùng buổi sáng đó, cũng chính agent ấy kết luận rằng một cấu hình nào đó “không tồn tại trong hệ thống”. Nó tìm bốn lần, bốn lần đều không thấy, và bốn cái “không” cộng lại thành một câu khẳng định — mà tôi, một lần nữa, gần như đã ghi vào sổ.

Cấu hình đó tồn tại. Vấn đề là cả bốn lần đều đi tìm bằng những cái tên do chính người tìm tự đoán ra. Cái tên thật không nằm trong bốn cái đó. Dụng cụ ấy, theo đúng cấu tạo của nó, không có khả năng nhìn thấy thứ nó đang tìm — nên kết quả rỗng của nó không phải một phát hiện, nó là một sự im lặng.

Bốn lần “không phải cái tên này” không bao giờ cộng lại thành “không có cái nào”.

Trong doanh nghiệp, khuôn mặt này là câu quen thuộc: “Tôi đã hỏi khắp rồi, không ai phản ánh gì cả.” Hỏi ai? Hỏi bằng câu gì? Người biết chuyện có nằm trong nhóm được hỏi không, và họ có lý do nào để trả lời thật không? Một cuộc khảo sát nội bộ mà người trả lời phải điền tên, gửi cho cấp trên trực tiếp, thì kết quả “không có vấn đề gì” của nó là một hằng số, không phải một phép đo.

Cách thoát ra không phải hỏi thêm lần thứ năm bằng cái tên thứ năm. Nó là đổi câu hỏi: đừng hỏi “có phải cái này không”, hãy hỏi “có những cái nào”. Liệt kê toàn bộ rồi nhìn, thay vì đoán rồi kiểm chứng từng cái một.

Khuôn mặt thứ ba: tài liệu không phải cơ chế

Đây là khuôn mặt tốn tiền nhất, vì nó trông giống hệt sự chuyên nghiệp.

Vẫn ngày hôm đó, một sự cố xảy ra trong hệ thống của chúng tôi. Khi truy ra nguyên nhân thì lộ ra rằng chuyện này đã xảy ra một lần trước đó, vài tuần trước. Lần ấy nó đã được xử lý rất tử tế: người ta viết lại toàn bộ câu chuyện thành một ghi chú dài, đặt ngay bên cạnh chỗ hỏng, nêu đúng nguyên nhân, kèm đúng cách sửa.

Ghi chú ấy không cứu được gì. Lần này, kẻ mắc lại chính là kẻ đã mở đúng đoạn ghi chú đó ra đọc — một cái máy đọc nhanh hơn tôi rất nhiều, và nó dừng lại giữa chừng ở một chữ bị cắt ngang màn hình. Không phải vì lười. Vì đọc hết là một hành vi không ai kiểm được, kể cả khi người đọc là một cỗ máy.

Và đây là phần khiến nó tốn thời gian gấp đôi: khi sự cố xảy ra, hệ thống không im lặng. Nó báo lỗi rất rõ ràng — và chỉ sai hướng. Câu báo nói rằng cái chìa khoá bị từ chối, trong khi sự thật là chìa khoá không hề tồn tại. Hai chuyện đó đòi hai cách xử lý hoàn toàn ngược nhau: một bên là đi xin cấp quyền, một bên là đi tìm xem thứ bị thiếu nằm ở đâu.

Người đọc câu báo ấy tin nó, vì nó cụ thể và tự tin. Đó là một dạng hỏng nguy hiểm hơn im lặng: im lặng khiến người ta đi tìm, còn một câu sai hướng khiến người ta đi tìm sai chỗ, và tin rằng mình đang làm đúng.

Chỉ khi ba dòng ấy được biến thành một câu lệnh tự chạy, thì lỗi đó mới thật sự chấm dứt: kể từ đó, bất kỳ ai lặp lại sai lầm này đều bị chặn trong hai giây, kèm một dòng chỉ thẳng chỗ phải sửa.

Đây là chỗ tôi muốn nói to nhất, vì nó đúng với mọi SOP, mọi biên bản họp rút kinh nghiệm, mọi tài liệu đào tạo:

Tài liệu chỉ bảo vệ được người đọc hết. Còn “có đọc hết hay không” là thứ không ai kiểm được — nó không để lại dấu vết, và nó không có màu đỏ.

Một quy trình được viết ra sau sự cố cho ta cảm giác đã xử lý xong sự cố. Nhưng thứ đã thay đổi chỉ là kho tài liệu, không phải hành vi của hệ thống. Lần sau, cái quyết định kết quả không phải là tài liệu có tồn tại hay không, mà là người đang vội có đọc hết nó hay không. Và người đang vội thì không.

Vì sao AI làm chuyện này tệ hơn nhiều

Ba khuôn mặt trên đã tồn tại từ trước khi có AI. Nhưng AI thay đổi quy mô của chúng theo một cách rất cụ thể: AI sinh ra thứ trông giống bằng chứng nhanh hơn tốc độ con người kịp hỏi bằng chứng đó đo cái gì.

Một bản báo cáo do AI viết ra đọc trôi chảy, có số, có cấu trúc, có kết luận. Nó mang đủ mọi dấu hiệu bề mặt của một phân tích đã được kiểm chứng. Nhưng những dấu hiệu ấy là thứ mô hình giỏi nhất — chúng nói lên rất ít về việc con số bên trong có đo đúng thứ nó tự nhận hay không.

Trước đây, làm ra một dashboard sai mất một tuần, và trong tuần đó có vài người kịp hỏi “cột này lấy từ đâu”. Bây giờ nó mất bốn phút, và không ai hỏi, vì nó đã đẹp sẵn.

Đây cũng là lý do tôi cho rằng câu chuyện “AI thay thế người phân tích” đang được kể sai trọng tâm. Phần AI làm giỏi — tính toán, tổng hợp, trình bày — chưa bao giờ là phần khó. Phần khó luôn là câu hỏi con số này sẽ sai trong trường hợp nào, và đó chính là phần AI không tự hỏi nếu không có ai bắt nó hỏi.

Tôi viết đoạn này không phải từ một dự đoán về ngành. Ba khuôn mặt ở trên đều xảy ra trong một buổi sáng, trên hệ thống của chúng tôi, do các agent tôi đang vận hành gây ra — và điều đáng chú ý không phải là chúng sai, mà là chúng sai theo đúng những cách con người sai: tin một con số 0 mà không hỏi nó có thể khác 0 được không, đoán tên rồi coi bốn lần không thấy là không có, đọc nửa chừng một ghi chú rồi lặp lại đúng lỗi ghi chú ấy cảnh báo.

Điểm khác biệt duy nhất là tốc độ. Một người mắc ba lỗi đó trong ba tháng. Ở đây chúng xảy ra trước bữa trưa, mỗi lỗi kèm một đoạn giải thích mạch lạc và tự tin về lý do kết luận ấy đúng.

Và đây là phần tôi cho là quan trọng nhất, vì nó quyết định cách một tổ chức nên dùng AI: cả ba đều bị bắt, và không lần nào bị bắt bởi con người đọc lại từng dòng. Chúng bị bắt bởi một cột số thứ hai đặt cạnh cột thứ nhất, bởi một agent khác đi kiểm bằng đường khác, và bởi việc chạy thử thay vì suy luận. Cái bắt được lỗi không phải sự giám sát — nó là cấu trúc của phép đo. Đó cũng đúng y hệt với một đội toàn người.

Bốn câu hỏi, dùng được ngay tuần này

Không cần một khung quản trị mới. Chỉ cần bốn câu, hỏi trước khi tin bất kỳ con số nào.

1. Điều gì lẽ ra đã làm con số này sai? Nếu không dựng được một tình huống cụ thể khiến chỉ số này đỏ, thì nó chưa từng được kiểm tra. Hãy đi dựng tình huống đó và xem nó có đỏ thật không. Một chỉ số chưa bao giờ đỏ không phải là một chỉ số tốt — nó là một chỉ số chưa được chứng minh là còn sống.

2. Phép đo này có đếm được một cái khác 0 nào ngay bên cạnh không? Đây là mẹo đã cứu chúng tôi buổi sáng hôm ấy, và nó rẻ đến mức nên thành thói quen. Trước khi tin một số 0, hãy bắt cùng phép đo ấy chỉ ra một thứ mà ta biết chắc là có. Nếu nó cũng trả về 0 cho thứ chắc chắn tồn tại, thì cái 0 kia không có nghĩa gì.

Việc này có tên sẵn trong khoa học thực nghiệm: đối chứng dương — cho dụng cụ đo một mẫu đã biết chắc là dương tính, để chứng minh nó có khả năng phát hiện, trước khi tin vào một kết quả âm tính. Không ai nhận kết quả xét nghiệm âm tính từ một cái máy chưa từng cho ra kết quả dương tính bao giờ. Nhưng đó chính xác là điều các tổ chức làm với chỉ số của mình, mỗi tháng.

3. Chuyện này đã xảy ra lần thứ hai chưa? Lần một, viết lại thành tài liệu là hợp lý. Lần hai là bằng chứng tài liệu không đủ. Đến lần thứ hai, câu hỏi phải đổi từ “ghi chép thế nào” sang “cơ chế nào chặn được nó mà không cần ai nhớ”. Nếu không dựng được cơ chế, ít nhất phải thừa nhận rằng ta đang dựa vào trí nhớ của người đang vội.

4. Ai là người sẽ mất nhiều nhất nếu con số này sai, và họ có quyền hỏi lại nó không? Rất nhiều chỉ số đẹp tồn tại được vì người có động cơ chất vấn chúng lại không có quyền truy cập vào cách chúng được tính.

Một ví dụ nằm ngoài doanh nghiệp, xảy ra đúng hôm nay

Hôm nay John Ternus nhận ghế CEO Apple. Kèm theo đó là một loạt bài báo đặt cùng một câu hỏi: “Apple có trở lại thời kỳ hoàng kim không?”

Hãy thử áp bốn câu hỏi ở trên vào chính câu đó. Điều gì lẽ ra đã làm nó sai?

Không có gì cả. Apple bán được nhiều hơn thì gọi là hoàng kim. Bán ít đi thì gọi là mất chất. Ra sản phẩm mới mà thành công thì “cỗ máy đã trở lại”, thất bại thì “đã đánh mất bản năng”. Không tồn tại một kết quả nào của thế giới thực có thể khiến người viết phải rút lại câu hỏi. Nó không thể sai, nên nó không nói gì — nó chỉ đóng gói một cảm giác vào hình dạng của một câu hỏi.

Điều đó không có nghĩa là mối lo đằng sau nó vô lý. Mối lo ấy thật, và nó cụ thể hơn nhiều so với chữ “hoàng kim”: Apple có còn là bên quyết định cách con người chạm vào máy tính nữa không? Đó là một câu hỏi khác hẳn với sức khoẻ tài chính — và chính bài báo đã chứng minh sức khoẻ tài chính vẫn tốt, bằng con số của họ, ngay trong bài.

Muốn biến nó thành thứ kiểm được thì chỉ cần một câu:

Trong năm năm tới, Apple có ra được một dòng sản phẩm đạt doanh thu hai mươi tỉ đô mỗi năm, ở một hạng mục mà trước đó họ không bán, hay không?

Câu này có thể sai, và đó là toàn bộ giá trị của nó. iPhone từng vượt ngưỡng ấy. Vision Pro thì chưa. Đến 2031 mở sổ ra đếm là biết, không cần ai thắng cuộc tranh luận nào.

Và đây là chỗ nó quay lại chuyện của chúng ta: nếu một người nói doanh nghiệp của họ “đang chuyển đổi số thành công”, hãy hỏi họ câu tương đương. Con số nào, mốc nào, và điều gì lẽ ra đã làm nó sai. Nếu không có câu trả lời, thì họ chưa nói gì về doanh nghiệp — họ đang mô tả tâm trạng của mình về nó.

Kết

Cái bẫy trong bài này không nằm ở việc đo sai. Đo sai thì sẽ có lúc lộ ra, vì thực tế cứ va vào con số mãi rồi cũng có người thấy vênh.

Cái bẫy nằm ở việc đo một thứ không thể sai, rồi sống nhiều năm trong cảm giác an toàn mà nó tạo ra. Không có gì vênh cả, vì nó không chạm vào thực tế ở bất kỳ điểm nào.

Nên trước khi tin một con số — và đặc biệt trước khi mang nó ra họp — hãy hỏi đúng một câu:

Điều gì lẽ ra đã làm nó sai? Nếu không trả lời được, thì ta chưa đo gì cả.