Tôi lo sợ về tương lai của các báo cáo sự cố do LLM viết
(surfingcomplexity.blog)- Trong báo cáo sự cố, LLM hữu ích để hỗ trợ thu thập và sắp xếp tư liệu, nhưng nếu giao cả phần nội dung báo cáo thì quá trình kiểm chứng sẽ yếu đi
- Quá trình tự tay viết buộc người viết kiểm tra tính nhất quán giữa bằng chứng và phần giải thích, và bản thân việc viết là cơ chế làm lộ ra sự thiếu hiểu biết, nhưng nội dung do LLM tạo ra sẽ bỏ qua bước tư duy này
- Báo cáo do LLM viết có thể trông rất hợp lý nhưng vẫn bịa ra các liên kết giữa các hệ thống vốn không tồn tại, hoặc bỏ sót những tương tác quan trọng trong sự cố
- Với lập trình hay AI SRE, có thể xác nhận bằng kết quả kiểm thử và phục hồi, nhưng với báo cáo sự cố thì không có bài kiểm tra rõ ràng để xác minh đáp án đúng, nên báo cáo sai còn nguy hiểm hơn
- Việc viết báo cáo càng phiền toái thì cám dỗ dùng AI tạo nội dung càng lớn, và dù hình thức vẫn đầy đủ thì việc học thực sự về hệ thống có thể lại giảm đi
Tương lai đang đến của các báo cáo sự cố do LLM viết
- Từ bài đăng pha chút châm biếm của Reginald Braithwaite, tác giả chỉ ra rằng tương lai của những báo cáo sự cố hoàn toàn do LLM viết đang đến gần
Viết báo cáo sự cố là một công việc chỉ tốn thời gian, trong khi thực tế chẳng ai trong tổ chức có lý do để đọc tài liệu đó cả. Bạn có muốn giải quyết vấn đề này không?
Hãy tham gia hành trình tuyệt vời của chúng tôi để xây dựng công cụ AI Ops viết báo cáo sự cố để AI tự đọc và tự hành động. Hơn nữa, công cụ này còn tóm tắt báo cáo, nên con người bận rộn không cần đọc từng chi tiết nhỏ nhặt nữa.- Bài đăng này mang giọng điệu mỉa mai, nhưng tác giả cho rằng một tương lai như vậy chắc chắn sẽ đến
- Để viết một báo cáo sự cố tốt, cần rất nhiều lao động lặp lại (toil) để thu thập dữ liệu cần thiết, và ai cũng đồng ý rằng LLM có thể giảm đáng kể gánh nặng này
- Tuy vậy, giữa việc thu thập nguyên liệu cần cho báo cáo và việc để LLM viết chính bản báo cáo có một khác biệt rất lớn
- Chính sự cám dỗ (seduction) của LLM kiểu “cứ bảo nó viết là nó viết” mới là điều đáng sợ
Vai trò của việc viết đối với tư duy
- Họa sĩ truyện tranh Dick Guindon từng nói: "Viết là cách mà tự nhiên cho bạn thấy tư duy của mình lộn xộn đến mức nào"
- Dù bạn nghĩ mình hiểu một khái niệm, chỉ đến khi thực sự cố giải thích nó bằng văn bản, bạn mới nhận ra mức độ mơ hồ trong sự hiểu biết của chính mình
- Hành động viết bằng ngôn ngữ của chính mình buộc bạn đối diện với mức độ hiểu biết thực sự
- Leslie Lamport nói: "Nếu bạn nghĩ mà không viết, thì bạn chỉ đang tự lừa mình rằng mình đang nghĩ"
- Khi LLM tạo ra văn bản báo cáo sự cố, nó đã đi vòng qua bước tư duy (thinking step) này
- Người kiểm duyệt (human in the loop) phải đối diện với việc phần giải thích có thực sự khớp với bằng chứng đã thu thập hay không sẽ biến mất
Rủi ro của báo cáo do LLM tạo ra
- Kết quả chỉ là một lời giải thích có vẻ hợp lý đối với những người không nắm rõ chi tiết
- Người đọc có thể gật gù và nghĩ “à ra vậy”
- Nhưng LLM có thể bịa ra các liên kết (couplings) giữa những hệ thống vốn không hề tồn tại, hoặc bỏ sót các tương tác cốt lõi của sự cố
- Vì không ai trực tiếp tự tổng hợp dữ liệu, nên không ai nhận ra những lỗi như vậy
- Nếu mục tiêu là giảm công sức viết lách, thì công sức bỏ ra để kiểm chứng kết quả của LLM cũng khó có thể nhiều hơn
So sánh với lập trình và AI SRE
- Tác giả cho rằng báo cáo sự cố do LLM tạo ra còn nguy hiểm hơn công việc lập trình hay AI SRE
- Với công việc lập trình: dù không trực tiếp soi từng dòng mã, vẫn luôn có bước kiểm thử để xác nhận xem nó có hoạt động như mong muốn hay không
- Với công việc AI SRE: đầu ra của LLM hoặc giúp giải quyết sự cố, hoặc không, và kết quả sẽ lộ ra ngay
- Trong cả hai trường hợp, “Tự nhiên (Nature)” đóng vai trò trọng tài cuối cùng cho đầu ra của LLM
- Nhưng với báo cáo sự cố thì tác hại của kết quả kém chất lượng không lộ ra ngay lập tức
- Một báo cáo trông như đúng chuẩn về hình thức nhưng thực chất sai lệch có thể được tạo ra, và không có bài kiểm tra rõ ràng nào để xác minh tính chính xác
Sự thu hẹp của cơ hội học hỏi
- Vì viết báo cáo rất tốn thời gian nên cám dỗ dùng công cụ AI sẽ là điều áp đảo
- Nhưng LLM không trực tiếp trò chuyện với những người đã tham gia vào sự cố
- Những báo cáo như vậy sẽ trở thành các mô hình mô phỏng (simulacra) chỉ có hình thức, không mang lại cho người đọc hiểu biết thực sự về bản chất của hệ thống
- Kết quả là lượng học hỏi giảm mạnh
- Mọi người thậm chí còn có thể lại đem những báo cáo được tạo ra như vậy đi nhờ AI tóm tắt lần nữa
"Tôi không mong chờ một tương lai như vậy."
1 bình luận
Ý kiến trên Lobste.rs
Vài tháng trước ở chỗ làm tôi có một sự cố bảo mật, nguyên nhân là một tính năng vibe coding đã được AI review, và đáng tiếc là cách làm đó đang dần trở thành tiêu chuẩn
Tôi đã đọc tài liệu phân tích sau sự cố trước cuộc họp thực tế, nhưng nội dung trước sau không khớp nhau. Một đoạn nói rủi ro xung đột là thấp, đoạn khác lại nói xung đột là điều chắc chắn
Trong cuộc họp, tôi hỏi kỹ sư dẫn dắt phần hậu kiểm rằng “Vậy cái nào mới đúng?”, thì anh ta trả lời “Tôi không biết!”. Tôi hỏi lại “Ý là sao? Chính anh viết cái này mà!”, thì anh ta nói “Không… agent của tôi viết!”
Nếu dùng AI mà còn không hiểu đầu ra của nó và đem tư duy của mình đi thuê ngoài, thì đó thực sự là một sai lầm nghiêm trọng, và nếu tiếp diễn thì tôi cho rằng đủ lý do để sa thải
Tôi lo chuyện này sẽ còn tệ hơn nữa. Trước hết, mọi người (dù là SRE, dev hay ai khác) không xem báo cáo sự cố là cơ hội để hiểu điều gì đã thực sự ảnh hưởng đến độ tin cậy của hệ thống, mà chỉ coi đó như một ô checkbox nữa cần tích
Cá nhân tôi thấy chỉ riêng điều đó thôi cũng đã làm giảm mạnh giá trị của báo cáo hay phân tích hậu kiểm
Hiệu ứng bậc hai cũng đang xuất hiện. Các công ty quảng bá rằng họ sẽ dùng những báo cáo kiểu này làm dữ liệu huấn luyện phù hợp với “kiến trúc cụ thể” và “cấu hình riêng”, nhưng rồi mô hình sẽ ảo giác nhiều hơn và trình bày những ảo giác đó như sự thật. Thậm chí nó còn có cả bằng chứng rằng những “sự thật” đó thực sự đã từng được ghi thành tài liệu
Nói thêm thì tôi cũng thấy xu hướng chạy prompt hay skill gì đó cho một cảnh báo cụ thể, rồi dán nguyên kết quả vào và nói “đây là những gì đã xảy ra”. Vài tháng nữa, có lẽ một số người trong nhóm đó sẽ không thể chẩn đoán sự cố cho ra hồn nếu không có agent dắt tay
Tôi đồng ý với toàn bộ bài viết, nhưng tôi không nghĩ so sánh với code là hoàn toàn phù hợp
Bài viết nói rằng với code thì có bước kiểm thử để xác nhận nó có hành vi mong muốn hay không, còn với báo cáo sự cố thì hậu quả của một báo cáo tệ không lộ ra ngay, nên sẽ sinh ra những báo cáo bề ngoài đúng mẫu nhưng thực chất sai
Nhưng với code ở quy mô không hề nhỏ, còn có các yếu tố như thiết kế, hiệu năng, độ trễ, và những thứ này ngày càng khó bị bắt chỉ bằng các tiêu chí đỗ/trượt đơn giản
Hệ quả của code viết sai cũng không lộ ra ngay với con mắt thiếu kinh nghiệm hoặc với góc nhìn chỉ nhìn vào kết quả. Nếu bạn tung ra thứ gì đó với tốc độ kỷ lục, mọi người sẽ reo hò và đập tay ăn mừng
Rồi người tiếp theo đến phải vật lộn để hiểu nó hoặc debug các edge case thì chậm lại, người sau nữa cũng lại chậm tiếp. Vì người thứ hai đã chắp vá thêm các biện pháp tình thế thay vì đưa ra lời giải nhất quán, và cứ thế tiếp diễn
Ở chỗ làm tôi có người đã tạo trigger để với mọi cảnh báo Slack, nó sẽ tạo thread rồi dán vào một bài dài do LLM viết về phân tích nguyên nhân gốc rễ, các bước tiếp theo, v.v.
Khi cần phản hồi một cảnh báo, việc phải đọc đống tạp văn này chẳng tốt chút nào, nhưng cũng không có vẻ gì là nó sẽ dừng lại, vì kiểu “đó là tương lai mà”
Tôi nghĩ đây hơi giống kiểu chiếc hộp Pandora. Hộp đã mở rồi và không kiểm soát lại được nữa, nên tốt hơn là phải điều chỉnh để nó đỡ tệ hơn
Nếu tài liệu được tạo ra đầy rác AI, thì cần điều chỉnh để tránh đi theo hướng đó. Ví dụ như sự dài dòng quá mức, danh sách ví dụ lê thê, hay các kiểu diễn đạt “không phải x mà là y”
Ý tưởng “cứ đưa tôi prompt thôi” cũng có thể mở rộng sang LLM. Kiểu như “nếu nhìn đầu ra này mà người dùng có cảm giác muốn hỏi ‘cứ đưa tôi prompt thôi’, thì coi như thất bại”
Tôi nghĩ hiện giờ vẫn đang ở đoạn thung lũng kỳ quái của đường cong. Văn xuôi đủ ổn để trông có vẻ hợp lý, nhưng vẫn thiếu cảm giác như do con người viết. Sau khoảng 2 năm nữa (+/-2 năm), có thể nó sẽ được tối ưu theo hướng người ta thực sự muốn đọc, và chúng ta có thể sẽ thấy đầu ra khó phân biệt với thứ do con người viết
Mà là quá trình tự tay viết báo cáo tự thân nó tạo ra sự học hỏi cho người viết, và sự học đó không thể có được bằng cách chỉ tạo ra báo cáo
Có câu rằng “bài của Braithwaite đầy tính châm biếm, nhưng báo cáo sự cố do LLM viết toàn bộ chắc chắn sẽ đến”, nhưng tôi có cảm giác như chúng ta đã sống trong thực tế đó từ khá lâu rồi
Báo cáo sự cố là một trong những loại văn bản lộ rõ nhất dấu hiệu do LLM tạo ra. Vì các nhà nghiên cứu bảo mật chịu áp lực phải công bố trước người khác
Tôi đã ở trong tình huống phải đọc những tài liệu thiết kế hệ thống rõ ràng là do AI viết, và có lúc chỉ muốn từ chối luôn
Khi ai đó nhờ bạn đọc một tài liệu khổng lồ mà bản thân họ gần như chẳng tốn công sức gì để làm ra, thì đúng là cảm thấy bị xúc phạm