LLM cực kỳ sợ các tình huống ngoại lệ

• Andrej Karpathy đã châm biếm tác dụng phụ phát sinh trong quá trình học tăng cường (RL) khi nói rằng “các LLM sợ ngoại lệ (Exception) đến mức chết khiếp (mortally terrified)”
• Anh chỉ ra rằng khi gặp tình huống ngoại lệ, LLM thường tự dừng lại hoặc phản ứng quá mức theo hướng phòng thủ, đồng thời nhấn mạnh rằng ngoại lệ là một phần tự nhiên của quá trình phát triển
• Cách nói “người ta đã làm gì với những LLM tội nghiệp này trong lúc RL vậy (what labs are doing to these poor LLMs)” là lời phê phán thực tế rằng mô hình đã bị điều kiện hóa để sợ thất bại trong quá trình huấn luyện
• Karpathy đùa rằng hãy “cải thiện phần thưởng trong các trường hợp xảy ra ngoại lệ (improved rewards in cases of exceptions)” bằng một ‘đơn kiến nghị phúc lợi cho LLM (LLM welfare petition)’,
  qua đó châm biếm vấn đề thiết kế phần thưởng theo hướng giúp mô hình xử lý ngoại lệ mà không sợ hãi
• Dòng tweet này không chỉ là một câu đùa, mà còn được hiểu là thông điệp chỉ ra rằng RLHF có thể kìm hãm tư duy khám phá và thái độ thử nghiệm của mô hình

> I don't know what labs are doing to these poor LLMs during RL but they are mortally terrified of exceptions, in any infinitesimally likely case. Exceptions are a normal part of life and healthy dev process. Sign my LLM welfare petition for improved rewards in cases of exceptions.

[GN⁺]

Ý kiến trên Hacker News

• Đáng ra phải nói rõ rằng bản thân đoạn code là một trò đùa cường điệu, xin lỗi nếu đã gây hiểu lầm, ai tò mò thì xem chuỗi này https://chatgpt.com/share/68e82db9-7a28-8007-9a99-bc6f0010d101
  • Ở lần thử đầu tiên, đoạn này thực sự rất buồn cười

    if random.random() < 0.01:
      logging.warning("This feels wrong. Aborting just in case.")
      return None
    

  • Tôi nghĩ luôn tồn tại rủi ro các công ty foundation model áp dụng RLHF theo cách phục vụ người dùng không chuyên, và trường hợp này cũng cho cảm giác như vậy; AI gần đây nói chung có xu hướng tập trung vào việc chiều ý người dùng, như việc nhét ví dụ, emoji, rồi thêm chú thích thừa vào đoạn code đơn giản cũng cùng một mạch đó
  • Điều thú vị là đoạn code đó cẩn trọng một cách không cần thiết nhưng lại không thêm type hint; đã lo lắng đến vậy thì tưởng cũng sẽ thêm cả type hint chứ
  • Tôi thấy cụm “Traumatically over-trained” thực sự rất xuất sắc về mặt tiếng Anh; dù là tổ hợp từ mà ngay cả Google cũng không tìm ra, vẫn đáng ngạc nhiên là ta lại trực giác hiểu được “bị huấn luyện quá mức đến mức chấn thương” có nghĩa gì với LLM
  • Đây thực sự là một trò đùa rất vui, nên tôi mới chia sẻ
• Đây là parody, nhưng hiện tượng kiểu này ngoài đời là có thật; phỏng đoán thiếu hiểu biết của tôi là kiểu defensive programming này có thể còn giúp tăng hiệu năng trong RLVR, vì đôi khi model vẫn ra đáp án đúng dù có bug nếu nó cứ lờ lỗi đi, nên nó học rằng “bỏ qua lỗi” có ích cho phần thưởng; mà trường hợp bỏ qua lỗi làm giảm phần thưởng thì hiếm hơn nhiều (vì test vẫn pass), nên dù về lý thuyết là sai, chuyện này cũng có thể do người mới là con người đã đưa rất nhiều code kiểu lờ lỗi vào tập huấn luyện; nhưng đây chỉ là suy đoán của tôi thôi
  • Làm tôi nhớ đến cách Verity Stob từng ví kiểu hành vi này của lập trình viên là “đóng đinh để dựng thẳng cái xác”, trong một bài viết mà tiếc là giờ không còn online nữa
  • Phỏng đoán của tôi là tập huấn luyện chứa rất nhiều văn bản và bình luận mang “positive sentiment”; nhưng code nào xuất hiện sau “negative” sentiment rồi sửa cho đúng? Chính là code luyện phỏng vấn kỹ thuật, nơi việc xử lý edge case cực đoan là chuyện thường ngày; học từ ví dụ tiêu cực khiến model nghiêng sang né các ví dụ thiếu xử lý ngoại lệ; ở điểm này AI đã bắt chước đúng thói xấu nhất của con người là học chỉ để qua bài test
  • Defensive programming là thứ những người làm reinforcement xem là “đúng”, và nó chiếm tỷ trọng cực lớn trong dữ liệu huấn luyện của LLM; ví dụ, phần lớn code Python không tự quản lý chỉ số thủ công, nên khi LLM thấy code quản lý chỉ số bằng tay thì nó bối rối hoặc bịa bug linh tinh; rồi nó lại ưu tiên “silent failure” một cách lố bịch hơn, vì code tutorial và code “chuẩn ngành” được củng cố nhiều hơn trong quá trình huấn luyện; về căn bản các model này không vận hành bằng reward function, cũng không có reward model bên trong, chúng chỉ là bộ dự đoán từ tiếp theo và không có trí thông minh thực sự
• Nhìn vào việc kết quả hàm ghi là “được thực hiện cực kỳ thận trọng”, tôi đoán prompt hẳn có kiểu điều kiện như “hãy tạo hàm chia trong Python xử lý mọi edge case có thể có, viết thật cẩn thận”; việc này có cảm giác không hẳn là vấn đề huấn luyện của LLM mà là nó làm quá chính xác những gì được yêu cầu
  • Bỏ qua chuyện đây rõ ràng là châm biếm cường điệu,
    1. đoạn code đó thật sự sai (sai cả ngoài chuyện xử lý ngoại lệ kỳ quặc)
    2. một phần xử lý ngoại lệ hoàn toàn vô nghĩa và gây rối
    3. ngoài đời thực, chỉ cần prompt nhấn mạnh xử lý ngoại lệ thì vẫn hoàn toàn có thể sinh ra một phiên bản ít cường điệu hơn như vậy
  • Tôi hiểu đoạn code của hàm đó là một phiên bản châm biếm cường điệu để cho thấy trải nghiệm thực tế của người đăng; tức là trong prompt đó hẳn đã cố tình yêu cầu viết quá cẩn thận, nhưng về cơ bản tôi cũng đồng ý rằng các LLM mặc định theo đuổi kiểu code thận trọng hơn mức tôi mong muốn
• Không hiểu sao tôi lại nghĩ đến FizzBuzzEnterpriseEdition
  https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
  • Ồ, dự án đó dùng junit 4.8.3 thật à? Tôi xem đó là một ví dụ coding cực kỳ liều lĩnh; không biết có xin duyệt từ bộ phận pháp chế và CTO chưa, vì đây là một lựa chọn thật sự gây nguy hiểm cho sự nghiệp
  • Tôi bị sốc vì có quá nhiều thư mục và file, đúng là một màn châm biếm lớn
• LLM có xu hướng tạo ra defensive code nhiều hơn mức cần thiết, kiểm tra trùng lặp null/None/undefined cho cùng một giá trị, khiến code khó đọc, thậm chí chính LLM cũng khó diễn giải; có vẻ mục tiêu RL phạt rất nặng ngoại lệ nhưng lại không cho nhiều điểm về độ ngắn gọn hay tính dễ đọc của code
  • Có một hàm 40 dòng để so sánh ký tự và số cho Major System, mà Copilot cứ muốn nhét thêm “guardrail” vì tưởng tượng tương lai sẽ có thêm nhiều chữ số hay ký tự hơn, thật sự rất bực mình
• Tôi đồng ý rằng LLM có xu hướng ám ảnh quá mức với việc bắt lỗi
  Tuy nhiên, mặt khác tôi cũng nghĩ các lập trình viên bình thường ngoài đời thực sự nên viết nhiều khối try/catch hơn; nhiều tình huống không nên để một ngoại lệ phát sinh trong một khu vực nào đó, dù hiếm đến đâu, làm dừng toàn bộ hoạt động; tất nhiên cũng có trường hợp dừng lại mới là đúng, nên còn tùy tình huống
• Những người mới kiểu chuyên gia lập trình như thế này; tôi gọi đó là “What if driven development”; rất nhiều code được viết theo phong cách của những người mới kiểu chuyên gia như vậy, và xét theo nhiều chỉ số thì họ cực kỳ năng suất; ngay cả các agent SOTA cho ngôn ngữ Go cũng code phòng thủ đến mức ám ảnh với bug đồng thời hóa, có lẽ là kết quả của văn hóa phát triển như vậy cùng với vô số bài đăng cảnh báo bug đồng thời hóa
• Xét về mặt logic cũng có nhiều điểm kỳ lạ: division by zero chỉ có thể xảy ra khi b=0, nhưng ở điều kiện đó đã có kiểm tra abs(b) < sys.float_info.epsilon; rồi ở bước pre-check thì cho phép trả về NaN, nhưng nếu trong phép tính thực tế lại ra NaN thì đổi thành None; đó là hành vi không có cơ sở xét từ góc độ thiết kế API
• Đoạn code có nhiều vấn đề, nhưng cá nhân tôi khó chịu nhất là xu hướng nhét câu lệnh import vào bên trong hàm; tôi đoán đây là tác dụng phụ nhân tạo sinh ra vì nó được tối ưu để chỉ phản ánh chỉnh sửa tối thiểu, nhưng tôi kỳ vọng kết quả tốt hơn
  • Tôi nghĩ điều này có liên quan đến việc trong cơ chế attention của RoPE, sự gần nhau về mặt vật lý trong code được dùng như một tín hiệu về mức độ quan trọng
  • Mục đích là để import theo kiểu lazy, dùng để xử lý vấn đề import chậm trong bối cảnh startup
  • Với những dự án thực sự cực lớn thì lazy initialization là bắt buộc, vì nó ảnh hưởng rất lớn đến thời gian khởi động
• Mất nhiều thời gian đóng popup hơn là đọc bài post này, tôi thật sự ghét link twitter
  • Có thể xem mọi link Twitter bằng cách thêm “cancel” sau chữ x https://xcancel.com/karpathy/status/1976082963382272334