- bozo bit là thái độ cho rằng không còn đáng để lắng nghe hay coi trọng phán đoán và lời nói của một người nào đó nữa
- Khi tách người liên quan đến sự cố ra như một người kém năng lực, tổ chức sẽ giảm cơ hội học hỏi từ sự cố
- Cách PocketOS phản ứng với sự cố AI thuộc trường hợp distancing through differencing của Cook và Woods
- Nhà máy tại Mỹ đã bỏ lỡ điểm chung của hệ thống khi xem vụ cháy ở nhà máy nước ngoài là chuyện của người khác
- Nếu khép lại sự cố AI bằng câu “họ lẽ ra phải biết”, sẽ khó dẫn tới cải thiện về an toàn
Khi xem sự cố là chuyện của người khác, việc học hỏi sẽ dừng lại
- bozo bit là cách nói trong ngành phần mềm để chỉ việc không còn tôn trọng phán đoán của một người cụ thể và cho rằng những gì người đó nói không còn đáng để nghe nữa
- Khi nghe tin về một sự cố và nói kiểu như “làm sao có thể không làm X được?”, ta sẽ nhìn bên liên quan đến sự cố như những người kém năng lực và tách họ ra khỏi tổ chức của mình
- Bài đăng trên X của nhà sáng lập PocketOS, Jer Crane, An AI Agent Just Destroyed Our Production Data. It Confessed in Writing đã thu hút sự chú ý lớn như một sự cố liên quan đến AI, và trên mạng có nhiều bài viết xem phía PocketOS là thiếu năng lực
- Thái độ như vậy làm giảm cơ hội học hỏi từ sự cố, và tương ứng với khái niệm distancing through differencing mà Cook và Woods nói tới
-
Tạo khoảng cách bằng cách nhấn mạnh khác biệt (distancing through differencing)
Những sự cố lặp lại và các điểm chung bị bỏ lỡ
- Cook và Woods đưa ra trường hợp một vụ cháy hóa chất tại nhà máy sản xuất ở Mỹ
- Trước đó đã có một vụ cháy tương tự tại một nhà máy ở nước ngoài của cùng công ty, và nhân viên Mỹ biết về việc đó
- Tuy nhiên, nhân viên Mỹ cho rằng nhân viên ở nước ngoài kém thành thạo hơn, ít động lực hơn và ít cẩn trọng hơn, nên kết luận rằng họ không có gì để học từ đó
- Ngay cả sau khi xảy ra hỏa hoạn tại nhà máy ở Mỹ, công nhân ở ca khác trong cùng nhà máy vẫn quy nguyên nhân cho tay nghề thấp của ca đã gặp sự cố
- Kiểu phân biệt này khiến người ta không nhìn thấy điểm chung của hệ thống mà họ chia sẻ với bên gặp sự cố
- Cook và Woods cho rằng không nên gạt bỏ những sự kiện trông có vẻ khác nhau trên bề mặt, và rằng ở một cấp độ phân tích thì mọi sự kiện đều là duy nhất, nhưng ở cấp độ khác lại bộc lộ những mẫu hình chung
- Nếu chỉ kết luận sự cố của PocketOS bằng câu “họ đã dùng AI một cách vô trách nhiệm”, thì sẽ chẳng còn gì để học
- Railway, nền tảng mà PocketOS sử dụng, là một vendor có công khai delete API, và sau đó đã thực hiện các thay đổi để nâng cao độ an toàn của toàn bộ hệ thống, như họ cho biết trong Your AI wants to nuke your database. Guardrails fix that
- Trong tương lai, ngành này sẽ còn tiếp tục xuất hiện các sự cố liên quan đến AI, và thái độ “họ lẽ ra phải biết là không nên làm X” chính là đang rơi vào cái bẫy của distancing through differencing
- Trường hợp ai đó cố ý chấp nhận rủi ro quá mức khác với trường hợp vô tình chấp nhận rủi ro quá mức mà không tự nhận ra, và rất khó để đổ lỗi cho cá nhân chỉ vì họ đã không biết điều mà họ không biết
- Khi vượt qua được distancing through differencing, cách một tổ chức phản ứng có thể thay đổi
1 bình luận
Ý kiến trên Lobste.rs
Giá trị của bozo bit nằm ở chỗ một số người là nguồn phản thông tin đáng tin cậy
Những người đó theo thói quen lặp đi lặp lại việc đi đến kết luận sai, hiểu sai cả những tài liệu được viết cực kỳ trực tiếp, và đưa ra các thiết kế không giải quyết được mục tiêu mà còn tạo thêm vấn đề mới
Bật bozo bit với ai đó nghĩa là bạn đã kết luận rằng thời gian cố gắng thu nhận kiến thức từ cách người đó giao tiếp là lãng phí
Bài viết này đang trộn bozo bit với một hiện tượng khác: tin chắc rằng một vấn đề cụ thể không thể xảy ra, rồi từ đó suy ngược để bịa ra lý do
Thuật ngữ quen thuộc cho việc này là hợp thức hóa hậu nghiệm, và trong hàng thế kỷ, thậm chí hàng thiên niên kỷ, đã có rất nhiều tranh luận về việc nên tránh nó
Quay lại ví dụ trong bài về công ty đã cấp quyền quản trị cơ sở dữ liệu production cho LLM, phản ứng kiểu “chuyện đó sẽ không xảy ra với tôi vì X” là chính đáng nếu X gần với “cấp quyền quản trị cơ sở dữ liệu production cho LLM quá kỳ quặc và nguy hiểm đến mức điên rồ nên ngay từ đầu tôi sẽ không làm vậy”
Nó giống với những người ăn thứ nguy hiểm rồi gặp thảm họa. Khi đọc tin ai đó ăn sên trần rồi chết vì ký sinh trùng não, tôi có thể tin chắc rằng mình sẽ không chết vì đúng nguyên nhân đó
Tác giả tưởng rằng đó là vì tôi tin mình giỏi hơn hay thông minh hơn người đã chết, nhưng quá trình suy nghĩ thực tế gần với kiểu “tôi chắc chắn 100% rằng ngay cả khi đang chết đói trên một hoang đảo đầy sên trần mọng nước, tôi cũng sẽ không tự nguyện ăn sên trần, nên ký sinh trùng lây qua sên trần không nằm trong mô hình rủi ro của tôi”
Tôi cũng khó đồng ý với đoạn nói rằng câu “họ lẽ ra phải biết” là incoherent. Con người luôn bị trách vì những điều họ không biết, và đó là một phần của cuộc sống trưởng thành
Nếu một đứa trẻ 3 tuổi ăn sên trần thì tôi sẽ không trách, nhưng nếu một đồng nghiệp 30 tuổi ăn sên trần thì tất nhiên tôi sẽ trách. Những hành vi ngu ngốc quá hiển nhiên thì hoàn toàn có thể trách một người
Tôi nghĩ bài này có nêu ra một điểm hay mà trước đây tôi chưa từng nghĩ tới, nhưng với tôi nó cũng có vài khuyết điểm rõ ràng, và đó là khuyết điểm đầu tiên
Khuyết điểm thứ hai là khi đọc về người Mỹ, tôi tự hỏi: “Liệu kiểu distancing through differencing của họ có thật sự giống với điều tôi làm khi gạt đi các sự cố xóa dữ liệu do AI vận hành không?”
Tức là, nếu họ hoàn toàn không biết rủi ro đã phát sinh như thế nào ở một nhà máy khác mà vẫn gạt đi rằng chuyện đó sẽ không ảnh hưởng đến họ, thì điều đó không chính đáng
Nhưng nếu bạn nghe rằng ban quản lý đã đưa một robot hình người mới, mang tính thử nghiệm và phi quyết định vào sàn nhà máy để tự do hỗ trợ công nhân lành nghề làm việc nhanh hơn, thì sự phớt lờ của họ không thể bị nhìn dưới cùng một ánh sáng
Dù vậy, tôi vẫn chấp nhận kết luận. Vì tính liều lĩnh không phải là nhị phân
Lần tới khi nghe một câu chuyện lố bịch, có lẽ tôi sẽ dừng lại một chút để nghĩ: “Dù mình không bất cẩn đến mức như những gì họ đã làm, nhưng trong những việc mình đang làm, có điều gì đáng cẩn thận hơn và nên đặt thêm chốt an toàn không?”
Nhưng nếu một đồng nghiệp 30 tuổi ăn sên trần, tôi sẽ điều tra kỹ lưỡng diễn biến đã dẫn tới tình huống đó
Nếu tôi thấy muốn “trách” người đó, thì trước tiên có lẽ tôi sẽ hỏi vì sao chúng ta lại tuyển người ăn sên trần, và liệu bây giờ vẫn còn làm vậy không
Có một vài điểm hợp lý
Ở đoạn “Tôi muốn nói về lý do phản ứng này phản tác dụng. Và tôi muốn chỉ ra thuật ngữ kỹ thuật cho hiện tượng bà con với việc bật bozo bit này. Nó được gọi là distancing through differencing”, phản ứng này vừa có tính sản xuất vừa phản tác dụng
Trong một thế giới đã có quá nhiều sự việc đổ dồn đến mức không thể xử lý, việc không phải đánh giá mọi đầu vào là một tối ưu hóa cực lớn, nên nó có tính sản xuất
Đồng thời, nó cũng phản tác dụng vì những lý do nêu trong bài
Biết cái gì cần được xem là nghiêm túc và cần chú ý mới là bí quyết thật sự. Khi nào tôi học được bí quyết đó, tôi sẽ báo lại
Từ chuyện ai đó cấp quyền truy cập trực tiếp vào production cho AI, tôi cần học được gì?
Tôi từng làm ở một công ty đang tăng trưởng nhanh, nơi phần lớn thực hành kỹ thuật giống startup trong gara hơn là một tập đoàn đa quốc gia quy mô 1000 người
Lúc đó có ba điều đúng. Thứ nhất, triển khai dịch vụ được thực hiện bằng cách
cdvào thư mục Git checkout trên laptop rồi chạy<tool> deploy <service-name>, và đúng commit Git hiện đang checkout sẽ được triển khaiThứ hai, vì văn hóa tin tưởng đồng nghiệp, hệ thống triển khai có kiểm soát truy cập tối thiểu. Có một danh sách được phép triển khai, và nếu có tên trong đó thì bạn có thể triển khai bất kỳ dịch vụ nào
Thứ ba, kho Git chính rất lớn và wifi văn phòng lại tắc nghẽn nên clone mất nhiều thời gian. Để nhân viên mới bắt đầu nhanh hơn, ảnh provision laptop có sẵn một Git checkout của kho chính
Rồi một ngày nọ, đội cơ sở dữ liệu có một thực tập sinh mới, và trong lúc làm theo hướng dẫn wiki Database Team 101, người đó chạy lệnh được gợi ý để kiểm tra quyền triển khai có hoạt động hay không:
<tool> deploy --prod <database>Hóa ra ảnh provision laptop đã cũ, và thực tập sinh đó còn chưa học đến buổi onboarding có bước
git pull origin masterCâu chuyện “LLM phá production” và câu chuyện “thực tập sinh phá production” khá giống nhau, nhưng câu sau dễ học từ đó hơn. Vì các sai lầm riêng lẻ nhỏ hơn
Nhìn từ góc độ phân tích sự cố, bật bozo bit rồi ngừng học hỏi là kiểu dừng lại ở một yếu tố đóng góp đơn lẻ trong khi lẽ ra phải nhìn toàn bộ cây sự cố, tức là dừng ở chỗ “lỗi con người!”
Trong ví dụ được nêu, nút “đã cấp quyền truy cập production cho vòng lặp LLM” trong cây sự cố kích hoạt heuristic “phớt lờ bọn ngốc” của người đọc
Nhưng nút anh em “hệ thống cho phép xóa không xác nhận qua API” lại là một bài học quý giá, và nếu dừng ở nút đập vào mắt đầu tiên thì có thể bỏ lỡ
Cây sự cố cũng nên bao gồm các nút con đào sâu vào việc vì sao thao tác nguy hiểm đó đã bị gỡ khỏi GUI nhưng vẫn còn trong API, và vì sao LLM lại có được quyền truy cập production
Mặt khác nữa, câu hỏi thật sự có thể là liệu trong đó có những nút tỏa sáng rõ hơn dưới điều kiện bozo hay không
Việc các nút đó bị nhận diện sai và nối sai có thể không quá quan trọng. Rốt cuộc, thứ tôi cần không phải là cây sự cố cho các thất bại trong quá khứ của họ, mà là kiểm tra xem tôi đã bỏ sót điều gì trong cây sự cố của mình để ngăn thất bại trong tương lai
Bài này bỏ qua một cách rất dễ thấy phần giải thích vì sao bật bozo bit với bozo trong ví dụ trung tâm mà nó nêu ra lại là sai
Nó chuyển sang ví dụ trong bài báo và không xử lý ví dụ trung tâm của chính mình
Vì vậy trông như tác giả đang cố lén cho qua một bozo khác
Có học được một điều: đừng dùng công cụ AI