LLM không phải là một tầng trừu tượng cao hơn

LLM không phải là một tầng trừu tượng cao hơn

Gần đây, tôi bắt gặp rất nhiều tuyên bố trên mạng cho rằng Mô hình Ngôn ngữ Lớn (LLM) là một tầng trừu tượng cao hơn. Cụ thể, nhiều người tin rằng việc lập trình với LLM là bước tiếp theo trong chuỗi tiến hóa: từ mã nhị phân (binary) sang hợp ngữ (assembly), rồi đến ngôn ngữ C, tiếp đến là Python, và giờ đây là LLM.

Những người ủng hộ quan điểm này thường cho rằng sự chuyển dịch này tương tự, nếu không muốn nói là giống hệt, các bước trừu tượng hóa trước đây mà chúng ta đã chứng kiến. Một số người còn khẳng định với tư cách là những lập trình viên kỳ cựu: "Tôi đã lập trình được 30 năm, và giờ đây lập trình lại thú vị hơn bao giờ hết".

Tuy nhiên, quan điểm này là sai lầm. Dù người nói có uy tín đến đâu, sự thật vẫn không thay đổi.

Bản chất của sự trừu tượng hóa trong lập trình

Mỗi lần chúng ta chuyển từ một lớp của công nghệ lên một lớp cao hơn, luôn luôn liên quan đến một hàm số xác định.

Cho một đầu vào x cụ thể, bạn luôn nhận được một kết quả y cụ thể được tạo ra.

• Khi x là mã nguồn hợp ngữ, một đầu vào cụ thể luôn cho ra kết quả nhị phân giống hệt nhau.
• Khi x là mã nguồn C, một đầu vào cụ thể luôn tạo ra cùng một tệp nhị phân.
• Khi x là mã nguồn Python, một đầu vào cụ thể cũng luôn dẫn đến cùng một kết quả nhị phân.

Đó là quy luật của lập trình truyền thống: tính xác định (deterministic).

Sự khác biệt cốt lõi của LLM

Với LLM, đầu ra của hàm số không phải là một giá trị cụ thể, mà là xác suất của một giá trị. Nghĩa là, đầu vào x của bạn không dẫn đến y, mà dẫn đến xác suất để có được y.

Thực tế còn tồi tệ hơn. Không có khả năng xảy ra trường hợp không tạo ra kết quả nào cả. Hàm số thực tế trông giống như sau:

f(x) = {y, z1, z2, ...}

Nghĩa là, bạn có cơ hội nhận được y (cái bạn muốn), hoặc cơ hội nhận được một số lượng các tạo phẩm khác không xác định.

Nếu suy nghĩ kỹ hơn, tình hình còn tồi tệ hơn thế. Trong thực tế với LLM, bạn có cơ hội nhận được y cùng với một số thứ khác mà bạn không hề yêu cầu. Vì vậy, hàm thực sự là:

f(x) = {y, z1, z2, ... zN}

Nói cách khác, nếu bạn chạy một bài kiểm tra trên đầu ra để tìm y, bài kiểm tra đó có thể thành công ngay cả khi bạn không chỉ nhận được y, mà còn nhận được tất cả những thứ khác trong z1..zN.

Rủi ro tiềm ẩn

Hãy tưởng tượng bạn yêu cầu LLM viết một hệ thống quản lý công việc kiểu "TODOist" — đó là y, và câu lệnh (prompt) của bạn là x.

Bạn chỉ kiểm tra xem nó có đưa ra ứng dụng TODO WebApp đó hay không. Các bài kiểm tra của bạn không kiểm tra sự tồn tại của z1, thứ có thể là "Mở thông tin xác thực của tôi ra mạng công cộng", hoặc z2 có thể là "Chia sẻ máy chủ lưu trữ của tôi với cả thế giới thông qua quyền truy cập FTP công cộng", hoặc z3 có thể là... ừm, bạn hiểu ý tôi rồi đấy!

Đây là sự khác biệt nguy hiểm giữa việc lập trình với một ngôn ngữ xác định và việc "lập trình" với một mô hình xác suất.

Kết luận

Nếu đến năm 2026, vẫn còn ai đó đưa ra tuyên bố phi lý về sự trừu tượng hóa này, hãy gửi cho họ liên kết đến bài viết này!

Và nếu chính bạn là người đang đưa ra tuyên bố này, hãy tự hỏi tại sao quan điểm này lại quan trọng với bạn đến vậy. Chúng ta cần những lập trình viên có nhận thức tự thân, chứ không phải những người chỉ đóng vai trò là kênh truyền để các tạo phẩm AI thâm nhập vào thế giới thực.