Bài viết hay từ @balajis về "khoảng cách xác minh". Bạn có thể xem nó như có hai chế độ trong việc sáng tạo. Mượn thuật ngữ GAN: 1) tạo ra và 2) phân biệt. Ví dụ: vẽ tranh - bạn thực hiện một nét cọ (1) và sau đó bạn nhìn một lúc để xem liệu bạn có cải thiện bức tranh hay không (2). Hai giai đoạn này xen kẽ trong hầu hết mọi công việc sáng tạo. Điểm thứ hai. Phân biệt có thể rất khó về mặt tính toán. - Hình ảnh là dễ nhất. Ví dụ: các nhóm tạo hình ảnh có thể tạo ra các lưới kết quả khổng lồ để quyết định xem một hình ảnh có tốt hơn hình ảnh khác hay không. Cảm ơn bộ GPU khổng lồ trong não bạn được xây dựng để xử lý hình ảnh rất nhanh. - Văn bản thì khó hơn nhiều. Nó có thể được lướt qua, nhưng bạn phải đọc, nó có nghĩa, rời rạc và chính xác nên bạn cũng phải lý luận (đặc biệt trong ví dụ như mã). - Âm thanh có thể còn khó hơn nữa theo ý kiến của tôi, vì nó buộc phải có một trục thời gian nên nó thậm chí không thể lướt qua. Bạn bị buộc phải tiêu tốn tài nguyên tính toán theo chuỗi và không thể song song hóa nó chút nào. Bạn có thể nói rằng trong việc lập trình, LLM đã thu hẹp (1) xuống gần như ngay lập tức, nhưng đã làm rất ít để giải quyết (2). Một người vẫn phải nhìn vào kết quả và phân biệt xem chúng có tốt hay không. Đây là chỉ trích lớn nhất của tôi về lập trình LLM, rằng chúng thường xuyên sản xuất *quá* nhiều mã cho mỗi truy vấn với độ phức tạp tùy ý, giả vờ rằng không có giai đoạn 2. Có được nhiều mã như vậy là xấu và đáng sợ. Thay vào đó, LLM phải làm việc tích cực với bạn để phân chia các vấn đề thành những bước nhỏ từng bước một, mỗi bước dễ xác minh hơn. Nó phải dự đoán công việc tính toán của (2) và giảm thiểu nó càng nhiều càng tốt. Nó phải thực sự quan tâm. Điều này dẫn tôi đến có lẽ là sự hiểu lầm lớn nhất mà những người không lập trình có về lập trình. Họ nghĩ rằng lập trình là về việc viết mã (1). Không phải vậy. Nó là về việc nhìn vào mã (2). Tải tất cả vào bộ nhớ làm việc của bạn. Đi qua đi lại. Suy nghĩ về tất cả các trường hợp biên. Nếu bạn bắt gặp tôi vào một thời điểm ngẫu nhiên khi tôi đang "lập trình", tôi có thể chỉ đang nhìn vào màn hình và, nếu bị gián đoạn, thực sự tức giận vì điều đó rất tốn sức tính toán. Nếu chúng ta chỉ nhanh hơn nhiều ở (1), nhưng không giảm (2) (điều này thường xảy ra!), thì rõ ràng tốc độ tổng thể của việc lập trình sẽ không cải thiện (xem định luật Amdahl).