Các Mô hình Ngôn ngữ Lớn đã thay đổi hoàn toàn việc phát triển phần mềm, nhưng chúng gặp khó khăn với một thách thức cơ bản mà các lập trình viên con người xử lý một cách tự nhiên: viết code cần được xây dựng từ phải sang trái hoặc không theo thứ tự. Hạn chế này trở nên đặc biệt rõ ràng với các ngôn ngữ lập trình chuyên biệt như q/kdb+ và APL, sử dụng việc đánh giá từ phải sang trái, nhưng vấn đề này còn mở rộng xa hơn những ngôn ngữ ngách này.
Vấn đề cốt lõi xuất phát từ cách các LLM hiện tại tạo ra văn bản. Chúng tạo ra các token tuần tự từ trái sang phải, khiến việc viết các biểu thức mà kết quả cuối cùng phụ thuộc vào các phép toán nên được viết ở cuối trước trở nên khó khăn. Điều này tạo ra vấn đề không chỉ với các ngôn ngữ từ phải sang trái, mà còn khi tái cấu trúc các lời gọi hàm lồng nhau hoặc làm việc với bất kỳ cấu trúc code nào có lợi từ việc kết hợp phi tuyến tính.
Ngôn ngữ lập trình từ phải sang trái:
- q/kdb+: Ngôn ngữ xử lý dữ liệu tài chính với cách thực thi từ phải sang trái
- APL: Ngôn ngữ lập trình mảng được tạo ra bởi người đoạt giải Turing Award Ken Iverson
- K: Kế thừa của APL với các nguyên tắc thực thi tương tự
- Phong cách thực thi: Từ phải sang trái không có thứ tự ưu tiên toán tử (RL/NOP)
Vấn Đề Tạo Ra Tuần Tự
Các mô hình dựa trên transformer hiện tại xuất sắc trong việc dự đoán token tiếp theo dựa trên ngữ cảnh trước đó, nhưng cách tiếp cận này bị phá vỡ khi luồng logic của việc xây dựng code không khớp với mẫu viết từ trái sang phải. Các nhà phát triển con người thường bắt đầu với kết quả mong muốn và làm việc ngược lại, hoặc nhảy qua các phần khác nhau của một biểu thức khi họ xây dựng nó. Các LLM không thể sao chép hành vi lập trình tự nhiên này.
Cộng đồng đã xác định đây là một hạn chế kiến trúc rộng hơn. Khi các nhà phát triển viết các biểu thức phức tạp, họ thường cần xem xét kết quả cuối cùng trước, sau đó điền vào các bước trung gian. Cách tiếp cận từ trên xuống này để xây dựng code là điều mà các mô hình hiện tại đơn giản là không thể thực hiện hiệu quả.
Những hạn chế hiện tại của LLM trong việc tạo mã:
- Việc tạo token tuần tự ngăn cản việc xây dựng mã từ phải sang trái
- Gặp khó khăn với các ngôn ngữ sử dụng đánh giá từ phải sang trái ( q/kdb+ , APL , K )
- Khó khăn trong việc soạn thảo mã phi tuyến tính và tái cấu trúc
- Vấn đề với việc quản lý trạng thái ngầm phức tạp ( Ruby on Rails )
- Xu hướng thêm các import không cần thiết như hành vi phòng ngừa
Tại Sao Dữ Liệu Huấn Luyện Không Phải Là Câu Trả Lời Duy Nhất
Trong khi một số người đề xuất rằng nhiều dữ liệu huấn luyện hơn cho các ngôn ngữ chuyên biệt có thể giải quyết vấn đề, vấn đề này chạy sâu hơn việc tiếp xúc đơn giản. Bản chất tuần tự của các kiến trúc mô hình hiện tại có nghĩa là chúng gặp khó khăn với bất kỳ mô hình lập trình nào đòi hỏi tư duy phi tuyến tính, bất kể có bao nhiêu dữ liệu huấn luyện.
Ngay cả các ngôn ngữ phổ biến cũng cho thấy điểm yếu này. Các ứng dụng Ruby on Rails, với việc quản lý trạng thái ngầm phức tạp của chúng, thường làm bối rối các LLM mặc dù có dữ liệu huấn luyện dồi dào. Các mô hình cũng có xu hướng thêm các import không cần thiết trong Python, đặt cược bằng cách bao gồm các module mà chúng có thể cần sau này trong quá trình tạo ra.
Mô Hình Diffusion Như Một Giải Pháp Tiềm Năng
Giải pháp hứa hẹn nhất đang được thảo luận liên quan đến các mô hình ngôn ngữ dựa trên diffusion. Không giống như các bộ tạo tuần tự truyền thống, các mô hình diffusion bắt đầu với văn bản ngẫu nhiên và dần dần tinh chỉnh nó thành đầu ra mạch lạc. Cách tiếp cận này về mặt lý thuyết có thể cho phép các mô hình làm việc trên các phần khác nhau của code đồng thời, giải quyết các phụ thuộc theo thứ tự nào có ý nghĩa nhất.
Một số mô hình lập trình dựa trên diffusion đã xuất hiện, mặc dù chúng chưa được huấn luyện cụ thể để xử lý việc đánh giá từ phải sang trái hoặc xây dựng code phi tuyến tính. Kiến trúc về mặt lý thuyết hỗ trợ việc tập trung vào các vùng khác nhau của code tại các thời điểm khác nhau, có khả năng giải quyết vấn đề viết ngược.
Các Cách Tiếp Cận Thay Thế Và Giải Pháp Tạm Thời
Một số nhà phát triển đang khám phá các giải pháp trung gian, như tạo cú pháp giống Python biên dịch thành các ngôn ngữ chuyên biệt. Cách tiếp cận này tận dụng thế mạnh của LLM với cú pháp quen thuộc trong khi xử lý thứ tự đánh giá phức tạp thông qua dịch thuật tự động.
Đôi khi tôi bắt đầu với dữ liệu và làm việc ngược lại thông qua các hàm bên ngoài, bỏ lồng khi tôi tiến hành. Đôi khi tôi bắt đầu với kết quả trả về cuối cùng và làm việc ngược lại với các đầu vào. Tôi nhận thấy đôi khi các LLM nên làm việc theo cách này, nhưng không thể.
Các giải pháp được đề xuất khác bao gồm huấn luyện các mô hình để tạo ra Cây Cú pháp Trừu tượng trực tiếp, hoặc sử dụng các cách tiếp cận huấn luyện hai chiều. Tuy nhiên, các phương pháp này đối mặt với những thách thức thực tế do bản chất dựa trên văn bản của hầu hết dữ liệu huấn luyện lập trình.
Các Giải Pháp Được Đề Xuất:
- Mô Hình Khuếch Tán: Bắt đầu với văn bản ngẫu nhiên và tinh chỉnh dần dần, cho phép tạo sinh không theo thứ tự tuần tự
- Phương Pháp Transpilation: Cú pháp giống Python được biên dịch thành các ngôn ngữ chuyên biệt
- Tạo Sinh AST: Tạo sinh trực tiếp các Cây Cú Pháp Trừu Tượng thay vì văn bản
- Huấn Luyện Hai Chiều: Huấn luyện mô hình theo cả hướng tiến và lùi trên mã nguồn
- Cải Tiến Prompting: Sử dụng các bước lý luận rõ ràng và chú thích chi tiết
Nhìn Về Phía Trước
Hạn chế này làm nổi bật một khoảng cách cơ bản giữa cách con người suy nghĩ về việc xây dựng code và cách các mô hình AI hiện tại hoạt động. Trong khi các giải pháp tạm thời tồn tại cho các trường hợp sử dụng cụ thể, việc giải quyết vấn đề cốt lõi có thể đòi hỏi các kiến trúc mô hình mới có thể xử lý việc tạo ra phi tuần tự một cách tự nhiên hơn.
Khi các mô hình diffusion tiếp tục phát triển và có khả năng kết hợp hỗ trợ tốt hơn cho đầu ra có cấu trúc như code, chúng ta có thể thấy những cải thiện đáng kể trong khả năng của LLM để xử lý các tác vụ lập trình phức tạp đòi hỏi tư duy phi tuyến tính. Cho đến lúc đó, các nhà phát triển làm việc với các ngôn ngữ chuyên biệt hoặc các tác vụ tái cấu trúc phức tạp sẽ cần dựa vào các chiến lược gợi ý cẩn thận và các công cụ dịch thuật trung gian.
Tham khảo: Why LLMs Can't Write q/kdb+: Writing code Right-to-Left