Đừng để một AI tự chấm bài của chính nó

Gần đây tôi dùng AI khá sâu trong công việc, nhất là khi xây một hệ thống vận hành nội bộ. Nó giúp tôi phân tích yêu cầu, đề xuất cách tổ chức, viết phần thực thi, kiểm tra logic, review những gì vừa tạo ra và gợi ý bước tiếp theo.

Bài này kể một vấn đề tôi gặp khi làm như vậy, và cách tôi đang thay đổi để giảm nó. Đây là cách làm cá nhân tôi đang thử, không phải một phương pháp đã được kiểm chứng.

Tôi từng để AI vừa làm vừa tự kiểm tra#

Ban đầu cách làm của tôi rất đơn giản: tôi đưa yêu cầu, AI thực hiện, AI tự kiểm tra, rồi tôi xem kết quả.

Cách này chạy khá tốt. Kết quả thường ổn, bản kiểm tra thường kỹ, và tôi tiết kiệm được nhiều thời gian. Vì vậy tôi không nghĩ nhiều về nó, cho đến khi gặp vài lần mà phần kiểm tra trông rất thuyết phục nhưng vẫn bỏ sót điều quan trọng.

Báo cáo thuyết phục chưa có nghĩa là đã được kiểm tra#

Có những lần AI báo một giai đoạn công việc đã xong, hoặc một cấu hình đã đúng. Bản báo cáo rất chi tiết: việc gì đã làm, file nào đã thay đổi, kiểm tra nào đã qua, rủi ro nào còn lại, tình trạng hiện tại ra sao.

Đọc riêng bản báo cáo đó, rất dễ có cảm giác mọi thứ đã được soát kỹ.

Điều tôi nhận ra là vấn đề không nằm ở chỗ báo cáo trông có thuyết phục hay không. Nằm ở chỗ nó được viết ra từ đâu. Nếu cùng một AI hiểu yêu cầu theo một cách, tạo kết quả dựa trên cách hiểu đó, rồi tự review chính kết quả của mình, thì phần review có thể tiếp tục bảo vệ đúng giả định đã sai từ đầu.

Kết quả nhìn vẫn hợp lý. Phần review nghe vẫn thuyết phục. Nhưng cả hai có thể đang dựa trên cùng một điểm mù.

Tôi muốn nói rõ một điều: một AI hoàn toàn có thể review kết quả của chính nó, và nhiều lần việc đó hữu ích. Rủi ro nằm ở chỗ khi lượt review dùng chung ngữ cảnh, chung giả định và chung lối suy luận với lượt làm, nó dễ bỏ sót đúng thứ mà lượt làm đã bỏ sót.

Một lần AI đọc sai trạng thái nhưng vẫn giải thích rất logic#

Ví dụ rõ nhất với tôi là một lần AI đọc sai một trạng thái trên giao diện quản lý việc triển khai website.

Trên màn hình có hai thành phần giao diện mang chữ giống với tên một trạng thái. AI coi đó là trạng thái thật và kết luận rằng bản đang chạy thật có lỗi. Từ tiền đề đó, phần lập luận phía sau vẫn nghe hợp lý.

Khi tôi kiểm tra lại trực tiếp trong môi trường thật, hai thành phần đó chỉ là các bộ lọc của giao diện, không phải trạng thái của bản triển khai. Bản đang chạy vẫn hoạt động bình thường.

Điều làm tôi để ý không chỉ là lỗi đọc sai. Chuyện đó ai cũng có thể mắc. Điều đáng chú ý là AI đã tạo ra được một cách giải thích khá logic cho một tiền đề sai ngay từ đầu. Nếu tôi chỉ đọc báo cáo và chấp nhận kết luận, có thể tôi đã mất thời gian xử lý một vấn đề không tồn tại.

Tách Build, Review, Verify#

Từ đó tôi bắt đầu tách công việc thành các vai khác nhau.

Build. Một lượt tập trung làm việc được giao và tạo ra kết quả.

Review. Một lượt khác, không được mặc định rằng phần làm trước đó là đúng. Nhiệm vụ của nó là tìm: giả định sai, chỗ logic chưa chặt, trường hợp biên, thứ bị hỏng ở chỗ khác, vấn đề riêng tư, và những điều bản báo cáo nói là đã xong nhưng chưa thật sự được kiểm chứng.

Verify. Lượt cuối ưu tiên bằng chứng thực tế thay vì lập luận.

Human Decision. Cuối cùng là tôi: chấp nhận, sửa tiếp, hay đưa vào dùng.

Tôi không nhất thiết dùng ba sản phẩm AI khác nhau cho ba vai. Thứ tôi muốn tách là vai và ngữ cảnh. Người review không nên chỉ lặp lại lối suy luận của người làm. Người verify không nên chỉ đọc lại báo cáo của người review.

Ba lần hỏi AI chưa chắc là ba lớp kiểm tra. Nếu cả ba dựa trên cùng ngữ cảnh, cùng giả định và cùng cách suy luận, thêm bước chỉ làm cùng một sai sót đi qua nhiều lần hơn. Giá trị nằm ở sự độc lập giữa các bước.

Verify phải quay về bằng chứng thật#

Với tôi, đây là phần quan trọng nhất của cả chuỗi. Lượt verify không nên hỏi "báo cáo này có hợp lý không". Nó nên hỏi "thứ thật có đúng như báo cáo nói không", và khi có thể thì nhìn thẳng vào sản phẩm hoặc môi trường thật:

• chạy bước build và kiểm tra;
• xem kết quả đầu ra;
• kiểm tra trên bản đang chạy thật;
• mở trực tiếp giao diện;
• thử các đường dẫn;
• xem giao diện trên màn hình nhỏ;
• xem có lỗi trong console không;
• đối chiếu trạng thái thật với những gì báo cáo đã nói.

Trong trường hợp ở trên, chính việc nhìn trực tiếp vào trạng thái thật mới cho thấy kết luận "bản đang chạy có lỗi" là sai.

Người vẫn là lớp cuối#

AI giúp tôi thấy nhiều vấn đề hơn và làm nhanh hơn. Nhưng nó không thay tôi chịu trách nhiệm về kết quả. Quyết định cuối cùng, chấp nhận, sửa tiếp hay đưa vào sử dụng, vẫn là của tôi. Với những việc quan trọng, tôi vẫn cần tự kiểm tra, không giao hết cho các lớp AI.

Khi nào đáng dùng, khi nào là thừa#

Cách này có cái giá của nó:

• tốn thời gian hơn;
• tốn nhiều tài nguyên tính toán hơn;
• không cần cho mọi việc;
• các mô hình giống nhau vẫn có thể mắc cùng một kiểu lỗi.

Tôi không có quy tắc cứng. Cách tôi cân nhắc là xem một kết luận sai sẽ kéo theo hậu quả lớn đến đâu và có dễ làm lại không. Với việc nhỏ, dễ sửa, một lượt review thường đủ. Với việc tôi sẽ dựa vào để quyết định tiếp, hoặc khó đảo ngược, tôi mới thêm lượt verify trên bằng chứng thật.

Điều tôi vẫn đang thử#

Tôi chưa biết cách làm này đã đúng ở mức nào. Nó giúp tôi giảm khả năng một lỗi hoặc một giả định sai đi xuyên suốt cả quy trình mà không bị ai hỏi lại. Nó không loại bỏ lỗi, và tôi không có dữ liệu cho thấy nó luôn cho kết quả tốt hơn.

Có vài câu tôi còn đang theo dõi: bao nhiêu lớp là đủ cho từng loại việc, tách ngữ cảnh đến mức nào thì hai lượt AI mới thật sự độc lập, và khi nào một lượt kiểm tra bằng tay còn đáng tin hơn cả ba lượt AI.

Câu tôi hay tự hỏi bây giờ không còn là "AI có đúng không", mà là: ai đang kiểm tra nó, và người hoặc lượt kiểm tra đó có độc lập với nó không.