LLM không 'hiểu' — và vì sao điều đó chưa chắc quan trọng

Cứ vài tháng, tranh cãi này lại bùng lên: mô hình ngôn ngữ lớn (LLM) có thực sự hiểu điều nó nói không, hay chỉ là "con vẹt ngẫu nhiên" (stochastic parrot) ghép chữ theo xác suất?

Hai phe đều có lý lẽ mạnh. Phe hoài nghi chỉ ra rằng mô hình chỉ học phân bố thống kê của văn bản, không có trải nghiệm, không có cơ thể, không có thế giới để neo nghĩa vào. Phe còn lại đáp: nếu "chỉ là thống kê" thì tại sao mô hình giải được bài toán chưa từng thấy, viết được code chạy được, và phát hiện được lỗi logic trong lập luận của chính bạn?

Một câu hỏi không có trọng tài

Tôi dần tin rằng cuộc tranh cãi này bế tắc vì một lý do đơn giản: chúng ta chưa bao giờ định nghĩa được "hiểu" đủ rõ để làm bài kiểm tra. Với con người, ta không đo trực tiếp sự hiểu — ta đo hành vi: trả lời được câu hỏi, áp dụng được vào tình huống mới, giải thích được cho người khác. Học sinh làm được cả ba thì được coi là hiểu bài, chấm hết.

Khi LLM làm được cả ba, phe hoài nghi buộc phải rút lui về một tuyên bố không thể kiểm chứng: "nó làm được, nhưng bên trong không thực sự hiểu". Có thể đúng! Nhưng một mệnh đề không có cách nào kiểm chứng thì không giúp ta quyết định điều gì cả. Đó là tranh cãi của triết học — xứng đáng tồn tại, nhưng đừng nhầm nó với câu hỏi kỹ thuật.

Câu hỏi thực dụng hơn: hiểu đến đâu và hỏng kiểu gì

Câu hỏi tôi thấy hữu ích hơn nhiều: với tác vụ cụ thể này, năng lực của mô hình đáng tin đến mức nào, và khi hỏng thì hỏng theo kiểu gì?

Vì kiểu hỏng của LLM rất khác kiểu hỏng của người. Một người không biết thì thường im lặng hoặc nói "tôi không chắc". LLM không biết thì... bịa — trôi chảy, tự tin, đúng ngữ pháp và sai sự thật. Nó có thể giải tích phân rồi sai một phép cộng hai chữ số. Năng lực của nó không xếp thành bậc thang như của người, mà lỗ chỗ như phô mai Thuỵ Sĩ: rất giỏi ở chỗ này, thủng một lỗ ngay cạnh đó.

Hiểu được hình dạng của những lỗ thủng quan trọng hơn nhiều so với việc dán nhãn "hiểu" hay "không hiểu" cho cả khối phô mai.

Hệ quả cho người dùng và người xây dựng

Từ góc nhìn đó, vài nguyên tắc làm việc với LLM trở nên tự nhiên:

• Dùng nó ở nơi việc kiểm tra rẻ hơn việc tạo ra. Code có thể chạy thử, bản dịch có thể đọc lại, ý tưởng có thể thẩm định. Đừng dùng nó ở nơi bạn không có cách nào biết câu trả lời sai.
• Đừng suy diễn năng lực. Mô hình làm tốt việc A không có nghĩa nó làm tốt việc A' trông na ná. Phải thử.
• Thiết kế cho thất bại. Hệ thống tốt xây quanh giả định "mô hình sẽ sai một tỷ lệ nào đó" — có kiểm chứng, có con người ở những điểm quyết định.

"Nó có hiểu không?" là câu hỏi khiến ta tranh cãi. "Nó đáng tin đến đâu, ở việc gì, và ai kiểm tra?" là câu hỏi khiến ta xây được thứ có ích. Tôi chọn câu thứ hai.