Jev và sự bình thường hóa những thất bại không thể giải thích

Trong một tập phim gần đây của President Curtis, vị Tổng thống đã phải vật lộn với việc mở cửa trong hai tình huống riêng biệt.

Những cánh cửa này không hoạt động vì có vật cản: ban đầu là một thi thể, sau đó là số vàng trị giá khoảng một tỷ đô la.

Trong cả hai trường hợp, để đáp lại sự thất vọng, nhân vật này lẩm bẩm "cái thứ ngu ngốc này thật tệ hại". Đây không phải là một mô hình hợp lý về những cánh cửa! Cửa không nên "tệ hại" một cách khó hiểu như vậy! Tôi thấy những khoảnh khắc này hài hước một cách lố bịch¹ nhưng có lẽ bộ não ngu ngốc của tôi mới là thứ tệ hại.

Jev: Tạo ra nhiều cánh cửa tệ hại hơn

Internet đang xôn xao về Jev, một mô hình AI do TypeSafe AI phát triển, có khả năng trả về các giá trị định kiểu (typed values) kèm theo ước tính xác suất. Theo những gì tôi biết, những điểm quan trọng về Jev là:

• nó nhanh và rẻ,
• bạn có thể xây dựng ứng dụng dựa trên nó một cách nhanh chóng,
• nó nhanh, và
• nó rẻ.

Tôi không giỏi lắm trong việc nắm bắt công nghệ nào sẽ được đón nhận.

Tôi vẫn không hiểu² Slack.

Khoan đã.

Bạn vẫn phải làm phần khó nhất sao?

Có lẽ vấn đề của tôi là kỳ vọng các sản phẩm phải hoạt động hiệu quả.

Không ai mua thứ này mà lại chạy các bài đánh giá (evals) cả. Họ chỉ đưa những câu hỏi mơ hồ cho Jev và nhận lại những phản hồi mơ hồ. Nói một cách bao dung, điều này cho phép họ đánh dấu vào ô "AI-powered" và xuất xưởng trước thứ Sáu, và khi điều này làm hỏng logic ở hạ nguồn, họ luôn có thể nhún vai và nói "chà, AI thì cũng có lúc sai sót".

Ngân sách lỗi? Các kiểu thất bại? Bộ dữ liệu kiểm thử? Tất cả những thứ đó có thể xử lý sau. Người dùng có thể tự khám phá tỷ lệ thất bại! Bạn đã xuất xưởng rồi còn gì!

Sự tự tin giả tạo

"Ồ," nhân vật giả định phản hồi bài viết của tôi đáp lại, "bạn chưa tính đến việc Jev cung cấp cho bạn các điểm số tự tin!"

Bạn định làm gì với những điểm số đó?

Để làm điều gì đó hợp lý với các điểm số tự tin, bạn cần phải hiểu về cách hiệu chuẩn (calibration) các điểm số đó, đồng thời phải có một mô hình cho chi phí của sự không chắc chắn.

Về khía cạnh hiệu chuẩn: Nội dung quảng cáo chính của Jev chủ yếu nói về việc chúng đạt điểm cao như thế nào trên các tiêu chuẩn đánh giá khác nhau, chứ không nói về việc các điểm số tự tin của chúng được hiệu chuẩn tốt ra sao. Có một tài liệu hướng dẫn về việc sử dụng điểm số tự tin để đi lên một cây phân loại nhưng về cơ bản, điều đó không nói lên việc các điểm số tự tin tốt đến mức nào.

Tốt nhất thì mọi người sử dụng điểm số tự tin theo kiểu "sùng bái hàng hóa" (cargo cult). Tệ nhất thì mọi người dùng chúng làm cái cớ cho việc tại sao lệnh gọi API thất bại. Mô hình chỉ tự tin 73%! Nghĩa là ngân sách lỗi của tôi là 27%!

Trách nhiệm giải trình

Khi một nút bấm trên trang web bị hỏng, tôi có một mô hình về những gì lẽ ra phải xảy ra. Đâu đó có một hợp đồng đã bị phá vỡ. DNS của tôi bị hỏng. Ai đó đã tung ra một đoạn mã cẩu thả có lỗi cú pháp JavaScript chỉ trên một đường dẫn nhất định. Một trình xử lý đã gặp lỗi không mong muốn. Tôi có thể không có quyền truy cập để gỡ lỗi một mã trạng thái HTTP 500, nhưng tôi mong đợi có ai đó chịu trách nhiệm hiểu tại sao endpoint lại trả về lỗi 500. Quyền sở hữu được xác định rõ ràng mặc dù hơi mơ hồ³.

Tuy nhiên, đối với nhiều người dùng, trải nghiệm thực tế chỉ đơn giản là "cái thứ ngu ngốc này thật tệ hại". Phần mềm vốn đã mang lại cảm giác thất thường; nhiều lỗi hơn chỉ làm thay đổi tần suất của sự thất vọng. Có vẻ như việc loại bỏ khả năng truy vết một lỗi đến nguyên nhân cụ thể cũng chẳng mất mát gì nhiều. Đôi khi mọi thứ chỉ đơn giản là tệ hại.

Điều này dẫn đến sự bình thường hóa của tính khó hiểu.

Nỗi sợ của tôi không phải là nhiều thứ sẽ hỏng hơn khi mọi thứ được tăng tốc bởi quá trình phát triển dựa trên LLM. Chúng sẽ hỏng. Chúng đã hỏng rồi. Đó là một phần cái giá phải trả khi xây dựng mọi thứ theo một cách mới lạ.

Nỗi sợ của tôi là "đôi khi nó chỉ đơn giản là tệ hại" sẽ ngày càng trở thành điểm kết thúc được chấp nhận cho các cuộc điều tra. Điều này thật đáng buồn vì quá trình phát triển được tăng tốc bởi LLM thực sự có thể giúp chúng ta giải quyết một số vấn đề này. Có rất nhiều quy trình QA tự động không được viết ra do thiếu thời gian kỹ thuật. Chính bài đánh giá mà bạn dùng để thay thế (hoặc thậm chí biện minh cho việc sử dụng) Jev có thể chỉ cách bạn vài câu lệnh (prompts).

Bi kịch của kỹ thuật phần mềm ngày nay là chúng ta đang tích cực xây dựng các hệ thống mà cả người dùng lẫn người xây dựng dường như không quan tâm đến việc kiểm tra xem có thi thể nào đằng sau cánh cửa hay không.

Chúng ta chỉ nhún vai và kết luận: cái thứ ngu ngốc này thật tệ hại.

¹Điều này làm tôi nhớ đến một câu nói mà tôi thấy cũng hài hước tương tự: "đôi khi bạn được đi thang máy, đôi khi bạn bị kẹt trong trục thang". Đây cũng không phải là một mô hình hợp lý về thang máy!!

²Hiệu ứng mạng lưới khóa người dùng (lock-in) thì tôi hiểu, nhưng tôi vẫn bối rối về việc làm thế nào mọi người lại tiêu chuẩn hóa một sản phẩm thậm chí không gửi tin nhắn một cách đáng tin cậy. Tôi đã thấy tin nhắn bị mất trên các phiên bản miễn phí, trả phí và doanh nghiệp mà phải vài tuần sau mới xuất hiện.

³Chà, có lẽ "xác định rõ ràng" là hơi lạc quan. Sau khi Bill Gates nổi tiếng với việc thất bại khi tải xuống Movie Maker, mọi người đều đồng ý rằng đó có lẽ là vấn đề của ai đó, chỉ là không nhất thiết phải là của họ. Lý tưởng nhất là chúng ta có thể đạt được mức độ trách nhiệm giải trình này mà khách hàng không cần phải là Bill Gates.