LLM và xu hướng lập trình đầu năm 2024
(antirez.com)- ChatGPT và các LLM cục bộ đã trở thành công cụ giúp lập trình viên có kinh nghiệm giảm bớt các công việc hao mòn như dò tài liệu, học API quá phức tạp, hay viết những chương trình sẽ sớm bị vứt bỏ, hơn là chỉ đơn thuần viết mã nhanh hơn
- LLM không phải trí tuệ siêu nhiên mà chỉ nội suy trong phạm vi không gian dữ liệu huấn luyện, nhưng ở những lĩnh vực có nhiều dữ liệu chất lượng như lập trình, chúng vẫn rất hữu ích như một “kẻ ngốc biết rất nhiều”
- Với các bài toán có thể kiểm chứng kết quả như biến đổi tensor PyTorch, client BLE Objective-C trên macOS, diễn giải đầu vào/đầu ra của mô hình ONNX, hay script phân tích CSV, GPT-4 giúp rút ngắn đáng kể thời gian làm việc
- Với các công việc cần suy luận phức tạp như lập trình hệ thống dựa trên C hay cài đặt thuật toán, giới hạn bộc lộ rõ trong việc thiết kế hash cho Bloom filter và diễn giải định dạng lượng tử hóa Q6_K của llama.cpp
- Nếu phần lớn lập trình là lặp lại các mẫu có sẵn với vài thay đổi nhỏ, thì khả năng dùng LLM tốt và mô tả vấn đề rõ ràng sẽ ngày càng quan trọng hơn
Vì sao lập trình viên có kinh nghiệm dùng LLM
- Mục đích dùng LLM không chỉ dừng ở việc viết mã nhanh hơn
- tìm kiếm tài liệu hiếm gặp
- học các API phức tạp quá mức
- viết những chương trình vài giờ sau sẽ bỏ đi
- xử lý những chi tiết không thú vị về mặt trí tuệ
- Khi Google trở thành một không gian tìm kiếm đầy spam, LLM trở thành con đường thay thế để lấy nhanh thông tin cần thiết
- Việc dùng LLM tăng lên trong các đoạn mã mức cao như Python, nhưng ít hơn nhiều với mã C
- Khác biệt quan trọng là biết phân biệt khi nào dùng LLM sẽ nhanh hơn, và khi nào lại khiến công việc chậm đi
- LLM, giống như Wikipedia hay các bài giảng YouTube, đặc biệt hữu ích với người có ý chí, năng lực và kỷ luật, nhưng có thể có giới hạn với người đang tụt lại phía sau
LLM không toàn tri toàn năng, cũng không chỉ là con vẹt
- Cách vận hành bên trong của mạng nơ-ron và LLM vẫn còn khá mờ đục
- Một số chuyên gia AI từng đánh giá thấp LLM như Markov chain nâng cao hoặc hệ thống chỉ lặp lại biến thể của dữ liệu huấn luyện, nhưng góc nhìn “con vẹt” đó phần lớn đã bị rút lại trước bằng chứng
- Ngược lại, thái độ gán cho LLM những năng lực siêu nhiên không có trong thực tế cũng không chính xác
- LLM có thể nội suy một cách hạn chế trong không gian tạo thành từ dữ liệu chúng đã thấy khi huấn luyện
- Có thể viết những chương trình chưa từng thấy chính xác trước đó
- Có thể trộn nhiều ý tưởng thường xuyên xuất hiện trong dữ liệu huấn luyện
- Có thể thất bại nặng nề khi cần suy luận tinh tế
- Dù có những giới hạn đó, LLM vẫn có thể được xem là thành tựu lớn nhất trong lịch sử AI
Trợ lý lập trình như một “kẻ ngốc biết rất nhiều”
- LLM có thể tạo ra suy luận sơ đẳng và thường không chính xác, ảo giác, cũng như bịa ra những sự thật không tồn tại
- Đồng thời, trong các lĩnh vực có nhiều dữ liệu tốt như lập trình, chúng hoạt động như một savant sở hữu lượng kiến thức khổng lồ
- Có thể chưa đủ tốt để trở thành đồng đội pair programming thực thụ, nhưng lại hữu ích trong mô hình người dùng đặt câu hỏi và tự kiểm chứng câu trả lời
- Trước đây, chỉ cần biết vài ngôn ngữ, thuật toán kinh điển và thư viện cốt lõi là có thể làm được nhiều việc
- Hiện nay, số lượng framework, ngôn ngữ và thư viện bùng nổ khiến độ phức tạp tăng mạnh, và trong môi trường đó một “kẻ ngốc biết mọi thứ” lại là đồng đội hữu ích
Các trường hợp thành công với mã mức cao và diễn giải dữ liệu
- Khi chuyển từ Keras sang PyTorch, LLM giúp viết mã cần thiết để dựng mô hình mà không phải học tài liệu PyTorch từ đầu
- Người dùng vốn đã hiểu các khái niệm như embedding hay residual network
- Cách đưa ra rõ ràng cấu trúc mô hình cần thiết và câu hỏi cụ thể tỏ ra hiệu quả
- GPT-4 xem mô hình PyTorch và định dạng batch, rồi viết mã reshape tensor cho phù hợp với đầu vào mạng nơ-ron
- Người dùng kiểm tra trong Python CLI xem số chiều của tensor và batch dữ liệu có khớp hay không
- Khi tạo client BLE cho thiết bị dùng ESP32, nó nhanh chóng viết mã Objective-C để dùng API gốc của macOS
- Các binding Bluetooth đa nền tảng nhìn chung được đánh giá là không dùng được
- Cần phải đụng lại API BLE Objective-C và các chi tiết Objective-C đã dùng từ rất lâu trước đó
- Mã cuối cùng nằm ở SerialBTE.m
- LLM không trực tiếp viết phần lớn mã, nhưng giải thích nguyên nhân vấn đề và cách xử lý, từ đó tăng tốc độ viết lên đáng kể
- Chương trình phụ trợ này có tỷ lệ lợi ích trên công sức thấp đến mức nếu không có ChatGPT thì có lẽ đã không thử làm luôn
Diễn giải mô hình ONNX và viết các chương trình dùng rồi bỏ
- Khi dùng một convnet định dạng ONNX có tài liệu nghèo nàn, LLM diễn giải cách hoạt động dựa trên metadata đầu vào/đầu ra và các giá trị raw output của ảnh thử nghiệm
- Ban đầu không biết định dạng và kích thước ảnh đầu vào
- Đầu ra không phải phân loại nhị phân đơn giản mà gồm hàng trăm giá trị
- ChatGPT giả định đầu ra có thể là các normalized box biểu diễn vùng lỗi tiềm năng trong ảnh cùng xác suất có lỗi
- Sau vài lượt trao đổi, đã tạo được script inference Python và mã biến đổi input tensor
- Với “chương trình dùng rồi bỏ”, đôi khi có thể giao cho LLM viết toàn bộ mã
- Để trực quan hóa loss curve khi huấn luyện một mạng nơ-ron nhỏ, GPT-4 nhìn định dạng CSV và tạo ra plot.py
- Yêu cầu là khi đưa nhiều file CSV trên dòng lệnh thì so sánh validation loss curve của từng thí nghiệm
- Toàn bộ việc này mất 30 giây
- Một chương trình pandas đọc báo cáo CSV của AirBnB, nhóm theo căn hộ và theo tháng/năm, rồi tính giá thuê trung bình theo tháng có xét phí dọn dẹp và số đêm lưu trú cũng chạy ngay từ lần thử đầu
- Những chương trình như vậy bản thân việc viết rất tẻ nhạt và ít hấp dẫn, nên khi LLM xử lý thì người dùng có thể tập trung vào việc quan trọng hơn
Những giới hạn bộc lộ trong C và lập trình hệ thống
- Khi viết chương trình C, LLM gần như luôn chỉ được dùng như một dạng tài liệu tiện lợi hơn
- Trong lập trình hệ thống, suy luận phức tạp là điều cần thiết, và LLM hiện nay thường thất bại đúng ở điểm này
- Khi được yêu cầu cài đặt Bloom filter, GPT-4 nhận điều kiện 100.000 phần tử và xác suất false positive tối đa 5%, nhưng không đưa ra được một triển khai tốt
- Chỉ dùng hai hash function khá giống nhau
- Thiếu một trừu tượng để tạo K hash đủ decorrelated từ cùng một chuỗi
- Nếu được yêu cầu rõ ràng phải tạo N đầu ra decorrelated thì nó đề xuất hash function tốt hơn
- GPT-4 có thể viết hash function phù hợp hơn nếu tách thành các bài toán con nhỏ, nhưng trong thiết kế tổng thể Bloom filter thì không tự áp dụng được ý tưởng đó
- Kết quả này có thể được xem là hệ quả của năng lực suy luận yếu, thiếu tư liệu theo chủ đề, và việc lẫn cả tài liệu chất lượng thấp
Khác biệt giữa mô hình cục bộ và mô hình lớn
- Với các bài toán lập trình hệ thống, khác biệt giữa mô hình nhỏ và mô hình lớn hiện ra khá rõ
- Mixtral, trong cùng bài toán
hash_id, đã đề xuất cách cộnghash_idvào cuối kết quả băm, và đây bị đánh giá là một lời giải rất tệ - Kết quả tốt hơn đến từ deepseek-coder 34B chạy lượng tử hóa 4-bit trên MacBook M1 Max
- Người dùng đưa ra gợi ý rằng việc thêm
hash_idở cuối làm phân phối xấu đi - Mô hình nhận ra phép cộng đơn giản có thể là nguyên nhân của vấn đề
- Nó đề xuất phương án thay thế là trộn
hash_idbằng các bitwise operation như XOR
- Người dùng đưa ra gợi ý rằng việc thêm
- Trường hợp này gần hơn với kiểu nhận diện nguyên nhân vấn đề và gợi ý cách giải quyết mà khó có được chỉ bằng tài liệu hay tìm Google
- Dù vậy, với lập trình viên hệ thống có kinh nghiệm, LLM nhìn chung vẫn hầu như chưa đưa ra được giải pháp thật sự thỏa đáng
Trường hợp diễn giải định dạng Q6_K của llama.cpp
- Dự án ggufflib là thư viện để đọc và ghi các tệp định dạng GGUF mà llama.cpp dùng khi nạp mô hình lượng tử hóa
- Để tăng tốc, mã hóa lượng tử lưu bit của từng quant theo cách khá phức tạp
- Ban đầu đã thử dùng ChatGPT để hiểu cách mã hóa, nhưng reverse engineering trực tiếp mã của llama.cpp nhanh hơn nhiều
- Dù hàm đủ nhỏ để nằm trong context của GPT-4, kết quả tái dựng tài liệu định dạng dữ liệu từ khai báo struct và hàm giải mã vẫn không hữu ích
- Ngay cả khi yêu cầu giải thích định dạng Q6_K, nó cũng không mô tả rõ cách các lower/upper bit được lưu vào
qlvàqhtùy theo vị trí của weight- Ngay cả khi yêu cầu một hàm giải thích cách lưu trữ đơn giản hơn, chỉ số vẫn bị sai
- Việc xử lý sign extension từ 6-bit sang 8-bit cũng sai
- Cuối cùng, công việc này được giải quyết bằng giấy bút, đọc mã và lần theo các bit mà decoder trích xuất
- Ngay cả kiểu công việc này cũng được dự đoán là có thể trở nên khả thi trong vài tháng tới chỉ với một chút scaling, không cần đột phá nào
Bản chất của công việc lập trình và năng lực tận dụng LLM
- Ngày nay, phần đáng kể của lập trình là lặp lại cùng một thứ dưới hình thức hơi khác, và nhiều khi không cần suy luận ở mức cao
- LLM khá mạnh ở kiểu lập trình lặp lại này, nhưng giới hạn kích thước context vẫn là một ràng buộc lớn
- Cần tự hỏi liệu việc chỉ viết những loại chương trình mà LLM có thể làm được một phần có còn là vị thế tốt sau 5 hoặc 10 năm nữa hay không
- Năng lực suy luận của LLM yếu và chưa hoàn chỉnh, nhưng cũng khó giải thích các kết quả quan sát được nếu chỉ xem chúng là công cụ nhắc lại từ ngữ đơn thuần
- Mục tiêu huấn luyện là dự đoán token tiếp theo buộc mô hình phải tạo ra một dạng mô hình trừu tượng, và mô hình đó thì yếu, nhiều lỗ hổng và không hoàn chỉnh
Vì sao dùng LLM ngay lúc này
- Trong lập trình, lý do để không dùng LLM là khá yếu
- Khả năng đặt đúng câu hỏi cho LLM đang trở thành một kỹ năng quan trọng
- Khả năng mô tả vấn đề rõ ràng không chỉ hữu ích với LLM mà còn hữu ích khi giao tiếp với con người
- Nhiều lập trình viên có thể rất giỏi trong một lĩnh vực cụ thể nhưng lại thiếu kỹ năng giao tiếp
- Trong bối cảnh Google ngày càng khó dùng, LLM cũng rất phù hợp để dùng như tài liệu nén
- Giá trị thực dụng của LLM nằm ở việc giúp người dùng bớt phải tự học trực tiếp những “kiến thức rác” như giao thức truyền thông mơ hồ hay các chi tiết thư viện phức tạp
1 bình luận
Ý kiến trên Hacker News
Điểm mấu chốt là đoạn này: “Liệu tôi có thể làm được nếu không có ChatGPT không? Dĩ nhiên là có thể, nhưng việc nó sẽ mất nhiều thời gian hơn không phải là điều thú vị nhất. Thực ra, vì nó không đáng công nên có lẽ tôi thậm chí đã chẳng thử”
Trong hỗ trợ viết code, tiềm năng thật sự của LLM nằm ở chỗ nó hạ thấp rào cản bắt đầu một công việc mới, khiến những việc vốn sẽ nằm vô thời hạn trong đống dự án tương lai được thực sự nắm lấy và hoàn thành
Internet và mã nguồn mở cũng từng có hiệu ứng tương tự; với cả những dự án ta quan tâm nhưng chưa tự làm, theo thời gian sẽ có ai đó giải quyết đủ những vấn đề tương tự để ta có thể tái sử dụng hoặc biến đổi, khiến số ứng dụng và thư viện hữu ích bùng nổ
Tôi đồng ý với tác giả rằng LLM tự thân không quá có năng lực, nhưng với người có kỹ năng nền tảng và động lực thì nó trở thành một bộ khuếch đại
Rồi tôi nhận ra chúng có thể làm được với ít công sức hơn dự kiến rất nhiều
Trao đổi ý tưởng với đúng người cũng có thể tạo hiệu ứng tương tự, nhưng không có ai đủ khả năng đưa ra đầu vào có ý nghĩa mà không nhất thiết phải hiểu trọn vẹn miền vấn đề lại luôn chờ sẵn 24 giờ mỗi ngày chỉ bằng một cú nhấp
Nó có giúp được vài việc, nhưng thường khi tôi chạm đến điểm mà mình không biết đang làm gì thì mô hình cũng chẳng biết hơn tôi
Ngoài ra, việc soạn prompt nhanh hơn tự viết code thường là điều khó
Tôi tự hỏi có phải mình không biết dùng các công cụ này không
Tôi khá quen với thư viện ow2 asm, nhưng nó giúp tôi tiết kiệm rất nhiều thời gian lục tìm để nhớ lại chính xác định dạng descriptor
Nó cũng giúp tôi hiểu vì sao các thư viện phân tích tĩnh khác không đủ cho nhu cầu của mình do cách chúng xử lý trạng thái
Với tôi, ChatGPT làm hai việc: giảm bớt các tìm kiếm StackOverflow lặt vặt và việc dò mã thư viện để trả lời các câu hỏi cụ thể, đồng thời ở giai đoạn khảo sát dự án trước khi bắt đầu, giúp tôi nắm được tính khả thi của hướng tiếp cận mình sẽ chọn
Khi bị ADHD nặng, những việc đơn giản lại là khó nhất; ngay cả đổ rác hay mở thư cũng gần như bất khả thi
Cuộc đối thoại trong đầu có thể gào lên hàng giờ rằng hãy cứ làm việc đó đi, nhưng cơ thể không nghe theo
Người ta gọi đây là rối loạn chức năng điều hành, nhưng với tôi nó là nỗi phiền toái trong đời sống
Chỉ riêng việc LLM giúp bắt đầu làm việc đó đã là chuyện cực kỳ lớn
Về lập trình thì tôi hoàn toàn đồng ý
Điểm tối ưu khi dùng LLM là khi bạn đã biết đủ về chủ đề để kiểm chứng kết quả, và biết đủ để mô tả chi tiết điều mình muốn, tốt nhất là đi thẳng vào trọng tâm
Nó giúp làm nhanh hơn, giúp bạn làm cả những việc vốn sẽ không làm, và cực kỳ hữu ích để tạo ra các chương trình nhỏ nhưng có giá trị, có thể bỏ đi được
Một lĩnh vực khác rất hữu ích là khám phá một chủ đề hoàn toàn mới, dù có phải lập trình hay không
Bạn có thể nói rằng mình không biết rõ, không nhất thiết cần chi tiết cụ thể, nhưng muốn bàn về chuyện này và nhờ nó giúp sắp xếp suy nghĩ
Điều này đặc biệt hữu ích nếu bạn sẵn sàng nghiên cứu thêm hoặc hỏi tiếp dựa trên những gì đã nghe
Cánh cổng bước vào nhiều lĩnh vực nằm ở việc hiểu thuật ngữ cơ bản, nghe người ta phân biệt những điều gì và vì sao, cũng như biết ai là những người có thẩm quyền trong chủ đề đó
Sẽ có tình huống họ cứ chọc ngoáy cho đến khi tạo ra một con quái vật mà mình không hiểu, miễn là build qua được
Người đang học thì cần được giúp đỡ, nhưng sự trợ giúp mà LLM dạng Copilot cung cấp không phải là dạng phù hợp
Sẽ rất thú vị nếu huấn luyện một mô hình Copilot được thiết kế như một người đồng hành đặt câu hỏi làm rõ và cùng xác định giải pháp, thay vì cố tạo code bằng mọi giá cho các câu hỏi mơ hồ hoặc chỉ định sai của junior
Lần nào nó cũng đưa ra thứ hoặc sai một cách tinh vi, hoặc hoàn toàn là tiền đề ảo giác, khiến tôi mất thời gian cho đến khi nhận ra nó sai
Nếu nó không có thái độ tự tin vô lý vào câu trả lời sai, có thể nói nó cũng không tệ hơn nhiều so với việc tôi tự nối ghép những gì mình biết; nhưng hiện tại thì nó chỉ ổn ở mức thay thế rubber duck hoặc autocomplete
Sẽ thật tốt nếu khi vào website của một ngôn ngữ mới, có một LLM để trò chuyện về tài liệu đó, đặt câu hỏi và giúp mình hiểu
Sẽ còn tốt hơn nếu nó được huấn luyện bằng các ví dụ code thực tế của ngôn ngữ hoặc framework đó, và giúp viết chương trình hay hàm mới ngay tại chỗ
Nếu được kết nối với một REPL trực tuyến và hỗ trợ trực tiếp inline thì đó sẽ là lợi thế còn lớn hơn
Tôi cho rằng khía cạnh bị đánh giá thấp nhất của LLM là vai trò kiểu lập trình viên biết tuốt, điều bài viết có chạm tới nhưng không trực tiếp bàn sâu.
Dù là lập trình viên senior đến đâu thì cuối cùng cũng sẽ gặp những công nghệ mà mình gần như không biết gì.
Ai cũng là junior trong một lĩnh vực nào đó.
Dù là bậc thầy về Win32, C++, COM, bạn vẫn có thể bị kẹt ở những script NSIS khó hiểu khi đóng gói phần mềm.
Dù đã làm web app suốt 25 năm và ngồi trong ủy ban ngôn ngữ PHP, nếu được giao triển khai một chuẩn ISO khó hiểu để giao tiếp với mạng thẻ tín dụng, có thể bạn chưa từng giao tiếp với mạng thẻ tín dụng ở mức đó.
Dù đã làm app iOS từ chiếc iPhone đầu tiên, trước đó làm app Mac, từng làm vài năm ở Apple, thuộc lòng hầu hết API iOS và thậm chí trực tiếp thiết kế chúng, nếu được giao triển khai hỗ trợ CalDAV cho ứng dụng, có thể bạn còn không biết CalDAV là gì.
Trong những tình huống như vậy, LLM có thể giúp ích; dù không thể viết toàn bộ code cho bạn, ít nhất nó cũng có thể dẫn bạn đi theo đúng hướng.
Sau khi nhồi đầy đầu bằng công nghệ khác, sẽ đến lúc bạn phải nhớ lại và ôn lại những gì từng học nhưng đã gác sang một bên vì công nghệ mới.
Đó là một cảm giác kỳ lạ.
Bạn tự nhiên trôi theo mức trung bình của công việc mà công ty đang làm, rồi rơi vào tình huống kiểu “cũng lâu rồi” chưa đụng tới CSS.
Có khi bạn cần học cuối tuần để khơi lại cảm giác về Python dataclass.
Nếu đó là thứ có thể tìm thấy trên Google, rất có khả năng LLM sẽ tìm và tổng hợp nhanh hơn, tốt hơn.
May là đến lúc đó có lẽ tôi đã nghỉ hưu rồi.
Xu hướng “phần lớn code được viết bằng cách cắt dán từ ChatGPT” thật đáng ngạc nhiên.
Tôi vẫn thấy sốc khi có nhiều người chịu đựng một workflow đau đớn như vậy.
Tác giả bài gốc rõ ràng không phải người mới dùng GPT để code vượt quá kiến thức của mình, mà là một kỹ sư lão luyện.
Bình thường đó sẽ là kiểu người quan tâm đến workflow lập trình cũng như tính tiện dụng và hiệu quả của công cụ, vậy mà rất nhiều người vẫn chịu được việc liên tục copy-paste code qua lại giữa GPT và file local.
Chính workflow bức bối này là lý do ban đầu tôi tạo ra aider.
aider chia sẻ repository git local với GPT để code mới và các chỉnh sửa được áp dụng trực tiếp vào file.
Nó cũng chia sẻ ngữ cảnh code liên quan với GPT, nên GPT có thể viết code tích hợp với dự án.
Vì vậy nó không chỉ tạo ra những đoạn code cô lập dễ copy-paste, mà còn có thể đóng góp tinh vi hơn.
Kết quả là một workflow pair programming mượt mà, nơi tôi và GPT cùng chỉnh sửa file trong lúc trò chuyện.
https://github.com/paul-gauthier/aider
Nhưng có cách nào dùng nó chỉ để trò chuyện về code không?
Tôi dùng LLM để trao đổi ưu nhược điểm của nhiều cách tiếp cận, hoặc để giải thích vấn đề kiểu rubber duck.
Muốn vậy thì phải copy code, nhưng aider tập trung vào việc áp dụng thay đổi nên không hợp lắm cho mục đích này.
Thường thì sau nhiều lượt trao đổi về cách đúng, tôi mới quyết định có áp dụng thay đổi hay không.
Ông ấy là người tạo ra Redis.
Nếu đã trả phí thuê bao rồi, việc copy-paste sẽ hợp lý hơn là trả thêm tiền API.
Hơn nữa, mỗi người có tiêu chuẩn khác nhau về việc mức tăng hiệu suất có đáng để phụ thuộc vào dự án của người khác hay không; những dự án như vậy cũng có nguy cơ bị thương mại hóa hoặc bị bỏ bê.
Lần đầu tôi thử với một file thật thì file quá lớn nên hỏng, và file thật thứ hai vẫn quá lớn.
Tôi ngạc nhiên vì có vẻ aider không thể chia file lớn để vừa với giới hạn token.
Giới hạn token của GPT không chứa nổi những file nguồn lớn như vậy.
Nếu tôi phải tự chọn file cần làm việc, rồi còn phải “phẫu thuật” để GPT không nghẹn, thì tôi không chắc nó tiết kiệm thời gian hơn dùng Copilot trong IDE.
Ban đầu tôi nghĩ đóng góp cốt lõi của aider là xử lý vấn đề “kích thước code ≫ giới hạn token”, nhưng có vẻ không phải vậy.
Tôi vẫn muốn thử lại, nhưng aider nằm trong nhóm bất lợi kiểu “phải tìm một vấn đề và codebase đủ đơn giản để aider chịu được”.
Trong khi đó, Copilot và ChatGPT mỗi ngày đều đến đúng nơi tôi đang làm trong công việc thật, với codebase thật, kể cả những khiếm khuyết của nó, để giúp tôi.
Tôi nghĩ với các tính năng hiện tại, nó đã bao phủ rất tốt các use case chat và xác nhận.
Các bình luận ở đây có thể không phản ánh mức độ hài lòng cao của phần lớn người dùng phần mềm.
Aider giúp thực sự thực hiện use case mà antirez nói trong bài.
Đặc biệt là khi, như antirez nói, ta ngày càng giỏi hơn trong việc đặt câu hỏi đúng cho LLM.
Trong vài ngày qua tôi đã cố sửa một lỗi trong một ứng dụng Mac mã nguồn đóng.
Tôi thích ứng dụng đó, nhưng lỗi này đã khiến tôi phát điên suốt nhiều năm.
Tôi khá chắc một method Objective-C nào đó đại khái là nguyên nhân gây ra lỗi, nhưng tôi không biết method đó làm gì, còn bản decompile thì là một mớ hỗn độn vô nghĩa.
Cảm giác như đâm vào tường.
Rồi tôi thử đưa đống nhiễu mà decompiler nhả ra vào GPT-4 và nhờ nó chuyển thành phiên bản sạch hơn.
Kết quả không hoàn hảo, nhưng tôi có thể chỉnh lại được; sau đó tôi swizzle kết quả đó vào ứng dụng thì có vẻ lỗi đã biến mất.
Tôi chưa bao giờ tìm được các bước tái hiện, nhưng bình thường thì đến lúc này vấn đề đã xảy ra rồi.
Không có GPT-4 thì đây là việc tôi tuyệt đối không thể làm được.
Tất nhiên nếu viết lại hoàn toàn một đoạn code, ngay cả khi không hiểu nó làm gì và dùng LLM, thì khả năng nó còn đúng cùng lỗi như bản triển khai ban đầu là thấp.
Tuy nhiên có thể phát sinh lỗi khác, và tôi hy vọng không ai làm theo cách này với những đoạn code mà hậu quả của lỗi là quan trọng, chẳng hạn gây gián đoạn hệ thống hoặc tốn chi phí cho khách hàng.
Bài viết này khiến tôi hoàn toàn sốc
Salvatore là một trong những kỹ sư phần mềm giỏi nhất còn đang hoạt động ngày nay
Anh ấy có thể thấy rõ rằng cái gọi là công cụ này hoàn toàn vô dụng trong lĩnh vực chuyên môn của mình
Thế nhưng thay vì vứt nó đi như một cái tua vít cong vênh không khớp, anh ấy lại chấp nhận tiền đề của những người ủng hộ rằng phải tìm cách nào đó để nó có ích
Như học trong lớp kinh tế vĩ mô nhập môn, nếu một hòn đảo vượt trội trong sản xuất widget A, thì dù năng lực sản xuất B của hòn đảo kia tệ đến đâu, vẫn sẽ xuất hiện sự chuyên môn hóa để đảo A tận dụng đảo B
Vì vậy việc năng lực tương đối của antirez trong lập trình hệ thống đẩy LLM sang các tác vụ lập trình khác là điều đương nhiên
Nhưng chúng ta không tồn tại trong cô lập
Xung quanh có vô số con người muốn những thử thách kỹ thuật và cái ăn
Nhiều người trong số họ có, hoặc có thể có, những kỹ năng bổ trợ cho chúng ta
Khi làm việc cùng nhau, kết quả hợp tác có thể vượt quá tổng các phần
Có lẽ LLM có thể viết mã PyTorch giỏi hơn antirez
Nhưng chỉ vì trong gara có một cái tua vít cũ cong vênh không có nghĩa là nhất thiết phải dùng nó
Có khi hôm nay đi ra cửa hàng đồ kim khí lại tốt hơn
Vì cú pháp chính xác hay việc reshape tensor không quá quan trọng với tôi
Nếu chỉ dùng cá nhân để tạo và huấn luyện một convnet cho ảnh của tôi, thì không cần làm phiền một chuyên gia Torch
Nếu tôi hiểu đủ về bản thân convnet và chỉ chưa biết đủ cú pháp hay phương thức của Torch, thì tôi có thể tự làm
Phương án thay thế là nghiên cứu chi tiết trong tài liệu hướng dẫn Torch, và kết quả sẽ giống nhau
Điều quan trọng trong công việc này không phải là chi tiết của MLX, Keras hay PyTorch, mà là kiểm soát các khái niệm học máy
Hiện giờ nó hữu ích ở một mức nào đó nhưng khó nói là thật sự như vậy, và không dùng cũng không bị “tụt lại phía sau”
Vì tất cả những người liên quan đều đang cố hết sức để làm cho nó giỏi hơn, nên khi ngày đó đến ta chỉ cần prompt những gì mình muốn
Không cần vội vắt kiệt thứ gì đó từ thế hệ hiện tại, và hiện tại nó thường làm giảm năng suất hơn là tăng
Đến mức tôi tự hỏi liệu chúng ta có đọc cùng một bài không
Anh ấy nhìn vào một công cụ mới mà người khác thấy thú vị, tìm ra cách dùng hữu ích cho mình, đồng thời thừa nhận cả những điểm vô dụng
Anh ấy cũng đưa đủ ví dụ cho những trường hợp không vô dụng
Với lập trình viên thì đây không phải là một nhận thức đặc biệt mang tính cách mạng
Chúng ta luôn dùng nhiều công cụ khác nhau, như ngôn ngữ lập trình, và mỗi công cụ đều có điểm mạnh, điểm yếu
Tôi không hiểu vì sao chỉ LLM lại phải khác đến vậy
Nói rằng nó hoàn toàn không có điểm mạnh nào thì có vẻ ngớ ngẩn
Có làm được việc đó với dưới 20 đô la mỗi tháng không?
Khi bắt đầu một dự án mới có một vấn đề trở kháng
Ban đầu công việc hoàn thành 0%, và phải bắt đầu từ đâu đó, dù là hello world, tệp CMakeLists hay script Python, nhưng điều đó rất khó
Trước ChatGPT/LLM, tôi phải kéo nỗ lực đó từ bên trong mình ra đến đầu ngón tay
Giờ thì có thể giao cho ChatGPT
Thực tế nó kém hiệu quả hơn và kém mạnh mẽ hơn so với “ngồi xuống tự làm”, nhưng nó loại bỏ chi phí của việc “quyết định ngồi xuống tự làm”
Dù vậy, rốt cuộc vẫn là chép và nhào nặn các mảnh được copy từ tìm kiếm mã GitHub, StackOverflow, bài blog ngẫu nhiên, tài liệu, Discord, v.v.
Sau vài lần thử và thử lại, dự án có được điểm khởi đầu 5%, và khi cuối cùng đã có hình dạng, tôi mới thật sự có thể làm việc
Cuối cùng, tôi nhanh chóng tạo ra bằng cách sao chép-dán các proof of concept nông cạn rác rưởi mà ChatGPT nhả ra, rồi khi có đủ đà thì chuyển sang tự đào sâu
Vì vậy nó chậm hơn, kém hiệu quả hơn và ChatGPT cũng không làm giỏi hơn tôi, nhưng dễ hơn và không cần đào sâu
Kết quả là tôi có thể trụ tốt hơn nhiều ở phần giữa và phần cuối, tức những phần thật sự quan trọng của dự án, và không bị kiệt sức ngay từ đầu
Ngay từ đầu tôi có đặt đúng câu hỏi không, và nếu không thì có thể cứu vãn công việc đó một cách hiệu quả không?
Chi phí chìm biến mất vào trong khoản thuê bao 20 đô la
Tôi cho rằng đoạn “khi có vấn đề, và nếu LLM nói nhảm thì tôi có thể kiểm chứng, tôi cần nhanh chóng biết nội dung đó. Trong những trường hợp như vậy, tôi dùng LLM để tăng tốc độ có được kiến thức” là insight cốt lõi
Một trong những lý do lập trình đặc biệt phù hợp với LLM là việc kiểm chứng đáp án thường khá đơn giản
Tôi đang thử nghiệm khái niệm đánh giá liệu LLM có phải là công cụ phù hợp cho một tác vụ hay không
Kiểu như vẽ biểu đồ giữa “mức độ quan trọng của việc đầu ra phải chính xác” và “mức độ dễ kiểm chứng đầu ra có chính xác hay không”
Việc dùng ChatGPT để lập danh sách các bài hát có nữ nghệ sĩ từng đoạt Emmy tham gia thì tốn thời gian kiểm chứng độ chính xác, nhưng mức độ quan trọng cũng thấp và có vài lỗi cũng không sao
Vì vậy phần mềm hoàn toàn không có bug sao?
Đó là những bài toán mà nghĩ ra lời giải thì khó nhưng kiểm chứng một lời giải khả dĩ thì dễ
Và ai cũng biết lớp bài toán đó được gọi là gì
Thế giới vốn đã đầy những tạp văn không liên quan và không chính xác, và tốt hơn là chúng ta nên giảm việc sản xuất chúng thay vì tăng tốc nó
Tôi không nói về ví dụ cụ thể, mà nói về toàn bộ ý tưởng
Dùng ChatGPT làm đối tác suy nghĩ khi viết code
Trò chuyện suốt cả ngày mỗi ngày để hoàn thành công việc
Công ty đã phê duyệt Copilot, nhưng tính năng tự động hoàn thành của Copilot là một trải nghiệm tệ hại
Công ty lại không phê duyệt Copilot Chat, thứ tôi cần
Dù vậy, tôi vẫn muốn có một công cụ tương tự có thể tạo unit test hoặc chú thích code, v.v. cho code của tôi trên laptop của tôi
Tất nhiên là dựa trên input và sự hướng dẫn của tôi
Đồng nghiệp khen rất nhiều nên tôi đã tự hỏi có phải mình kỳ quặc không, nhưng nó cực kỳ gây xao nhãng và tôi đã tắt sau vài ngày
Cảm giác như có ai đó cứ cố hoàn tất câu khi tôi còn đang nói
Ngay cả khi nó đúng thì vẫn gây khó chịu, làm đứt mạch suy nghĩ, và nó sai rất thường xuyên
[0] https://continue.dev/
[1] https://ollama.ai/
Vài ngày trước tôi đã thử Codeninja
Theo tôi nhớ thì hoàn toàn chưa bằng 4, thứ đang chạy backend của Copilot, nhưng với dữ liệu nhạy cảm không được phép đưa ra ngoài thì thực tế gần như là lựa chọn duy nhất
Hoặc cũng có thể nhận một instance riêng từ OpenAI
Đây có thể là đoạn quan trọng nhất trong bài viết này, và khi nghĩ về những gì sẽ xảy đến trong năm 2024, có nhắc lại bao nhiêu cũng không thừa:
“Vậy LLM có năng lực suy luận ở mức độ nào đó, hay tất cả chỉ là khoác lác? Như các nhà ký hiệu học nói, có thể nó đôi khi trông như đang suy luận vì ‘cái biểu đạt’ tạo ra ấn tượng về một ý nghĩa vốn thực ra không tồn tại. Nhưng những ai đã làm việc đủ nhiều với LLM đều biết rằng, dù chấp nhận các giới hạn của nó, chỉ điều đó thôi không thể giải thích hết được. Khả năng trộn lẫn những gì đã từng thấy vượt xa việc nhả lại từ ngữ một cách ngẫu nhiên. Dù phần lớn quá trình huấn luyện diễn ra bằng cách dự đoán token tiếp theo trong giai đoạn pretraining, mục tiêu này buộc model phải tạo ra một dạng mô hình trừu tượng nào đó. Mô hình này yếu, nhiều lỗ hổng và không hoàn chỉnh, nhưng nếu chúng ta quan sát được những gì đang quan sát, thì nó nhất định phải tồn tại. Khi sự chắc chắn về mặt toán học còn đáng ngờ và ngay cả các chuyên gia hàng đầu cũng thường đứng ở các phía đối lập, có vẻ khôn ngoan là hãy tin vào những gì chính mắt mình thấy”