AI: Sự bất tài được tăng tốc
(slater.dev)- Việc phụ thuộc quá mức vào LLM trong kỹ thuật phần mềm có thể làm tăng tốc độ trong ngắn hạn, nhưng lại làm suy yếu tư duy phản biện và năng lực giải quyết vấn đề
- Rủi ro lớn hơn cả đầu ra sai là việc chấp nhận nguyên xi những prompt có khiếm khuyết, khiến nợ kỹ thuật và sự suy giảm năng lực của người dùng tích tụ nhanh chóng
- Vì LLM hiện không thể ghi nhớ hay nội hóa lý thuyết chương trình vượt ra ngoài cửa sổ ngữ cảnh hiện tại, mô hình tinh thần chung cần cho thiết kế và bảo trì vẫn là lĩnh vực của kỹ sư con người
- Độ phức tạp tiếp tục gia tăng trong quá trình bảo trì, và LLM — những bộ dự đoán token ở mức văn bản — có thể làm tăng entropy chương trình bằng các thay đổi thừa thãi hoặc kỳ quặc
- AI có thể được dùng như một công cụ, nhưng không nên phụ thuộc như một chiếc nạng; cần tiếp tục đầu tư vào năng lực kỹ thuật nền tảng và tư duy sâu vốn đã có giá trị từ năm 2019
Rủi ro kỹ thuật do sự phụ thuộc vào LLM tạo ra
- Cách gọi LLM là “bạn đồng hành” giống một cách nói giảm nói tránh rằng nó mang lại lợi ích cho người dùng, hơn là một người bạn đồng hành thực sự
- Những kỹ sư nhìn theo góc độ này thường ưu tiên tốc độ, hoặc bị gây áp lực phải ưu tiên tốc độ
- LLM có thể tạo ra nhiều mã rất nhanh, nhưng việc sử dụng chúng đi kèm một cái đuôi rủi ro rất dài
Năm loại rủi ro bộc lộ trong việc sinh mã
-
Rủi ro đầu ra
- LLM có thể tạo ra kết quả sai rõ ràng, như mã không thể biên dịch
- Nguy hiểm hơn là các kết quả sai tinh vi và khó phát hiện, như lỗi logic
- Rủi ro tăng lên khi người viết prompt không đủ năng lực để đánh giá kết quả
- Bài viết nêu ví dụ tình huống một quản lý dự án yêu cầu mã nguồn
-
Rủi ro đầu vào
- LLM không phản bác các prompt có câu hỏi dẫn dắt, giả định sai hoặc ngữ cảnh không đầy đủ
- Ví dụ, với yêu cầu “hãy cung cấp một triển khai danh sách an toàn luồng trong C#”, nó có thể trả về 200 dòng mã nghe rất hợp lý, nhưng câu hỏi thật sự có thể là “làm sao để đoạn mã này trở nên an toàn luồng?”
- Trong trường hợp đó, câu trả lời có thể chỉ là một dòng mã dùng
System.Collections.Concurrent - Vì không được yêu cầu, LLM không nhận ra đây là một trường hợp của XY Problem
-
Suy giảm tốc độ trong tương lai
- LLM có thể làm giảm chất lượng codebase với tốc độ rất nhanh
- Nếu không có các lan can bảo vệ mạnh, mã do LLM tạo ra có thể trông ổn bên ngoài nhưng bên trong lại biến thành một không gian mất vệ sinh và phi chức năng
- Đây được xem là vấn đề cấp bách hơn cả các cuộc thảo luận thông thường về nợ kỹ thuật
-
Trẻ con hóa người dùng
- Ở những cá nhân và tổ chức giao phó việc tư duy và giải quyết vấn đề cho LLM, tài năng có thể mai một
- Kỹ sư senior có thể mất cơ hội học hỏi thông qua quá trình vật lộn hữu ích, từ đó suy yếu năng lực giải quyết vấn đề và tư duy phản biện
- Kỹ sư junior có thể không phát triển được các năng lực đó ngay từ đầu, và về sau cũng khó cố vấn cho các junior tương lai
- ThoughtWorks Technology Radar Volume 32 đề cập đến việc sự tự tin dựa trên AI đôi khi phải đánh đổi bằng tư duy phản biện
- Coding as Craft: Going Back to the Old Gym nhấn mạnh sự cộng tác có chủ đích với AI để gìn giữ việc lập trình như một nghề thủ công
- Thoughts on Thinking cho rằng LLM có thể đưa ra những suy nghĩ đã hoàn chỉnh, nhưng không mang lại sự trưởng thành trí tuệ do tự thân phát triển
-
Mất niềm vui
- Nhiều lập trình viên cho biết việc dùng AI lấy đi trạng thái nhập tâm và niềm vui sáng tạo
- Mã do AI sinh ra có thể trở thành thứ mã khiến việc đọc và chỉnh sửa trở nên khổ sở
- Bài viết liên quan được dẫn là The Hidden Cost of AI Coding
Hai năng lực mà LLM không thể thay thế
- Trước nỗi lo rằng kỹ sư lành nghề sẽ trở nên không còn cần thiết vì AI, bài viết tóm gọn hai năng lực lập trình mà LLM không thể cung cấp
- Hai năng lực đó là lý thuyết chương trình và entropy chương trình
Lý thuyết chương trình: mã không phải là bản thân chương trình
- Programming as Theory Building của Peter Naur xem lập trình là hoạt động hình thành hiểu biết hoặc lý thuyết về một vấn đề
- Theo góc nhìn của Naur, chương trình không phải là mã nguồn mà là một cấu trúc tinh thần được chia sẻ, tức lý thuyết hoặc thiết kế
- Mã được dẫn xuất từ thiết kế đó, nhưng đầu ra có giá trị nằm ở thiết kế hơn là ở mã
-
Thí nghiệm tư duy về hai nhóm
- Hai nhóm A và B có năng lực như nhau ở trong các phòng riêng biệt, không liên lạc với nhau
- Nhóm A viết một chương trình như trò chơi cờ vua chạy trên terminal, còn nhóm B thì chờ hoặc chơi cờ thật
- Sau khi nhóm A hoàn thành, mã nguồn được chuyển cho nhóm B, và cả hai nhóm đều phải bổ sung tính năng như người chơi cờ vua ảo
- Nhóm có khả năng đưa ra lời giải tốt hơn sẽ là nhóm A
- Nhóm A đang nắm giữ mô hình tinh thần còn mới mẻ về chương trình mà họ vừa tạo ra
- Nhóm B không có mô hình đó
- Vì chương trình liên tục bị sửa đổi sau khi được tạo ra ban đầu, nếu chỉ có mã nguồn mà không có sự hiểu biết đã được nội hóa về thiết kế, chi phí thay đổi sẽ rất cao
- Điều này gắn với trải nghiệm khi lần đầu tham gia một codebase lớn hiện có: năng suất gần như bằng 0, rồi tăng dần khi nạp lý thuyết chương trình vào đầu
-
LLM và lý thuyết chương trình
- LLM hiện nay không thể ghi nhớ vượt ra ngoài cửa sổ ngữ cảnh, nên không thể làm chủ lý thuyết, thiết kế hay cấu trúc tinh thần
- Thực thể có thể đạt được và duy trì lý thuyết chương trình là con người
Entropy chương trình: năng lực giảm hoặc kháng cự độ phức tạp
- Độ phức tạp là lực cơ bản đối kháng với lập trình, và có liên quan đến entropy
- The Mythical Man-Month của Fred Brooks xem việc xây dựng chương trình là quá trình giảm entropy, còn bảo trì là quá trình làm tăng entropy
- Theo góc nhìn của Brooks, sau giai đoạn xây dựng ban đầu, việc thay đổi chương trình tất yếu sẽ làm mã nguồn trở nên phức tạp hơn
- Tuy vậy, những thay đổi hài hòa với thiết kế có thể làm chậm tốc độ gia tăng độ phức tạp
-
LLM và entropy chương trình
- LLM là bộ dự đoán token và chỉ hoạt động ở cấp độ văn bản
- LLM không thể suy luận ở cấp độ khái niệm như ý tưởng, sơ đồ hay đặc tả yêu cầu
- Những ai từng đưa các khối mã lớn vào LLM sẽ thấy nó có xu hướng áp dụng các thay đổi thừa thãi và kỳ quặc
- Cuộc trò chuyện càng dài thì kết quả càng có thể lệch hướng
- Năng lực giảm độ phức tạp của mã hoặc kháng cự độ phức tạp nằm ở con người
Cách sử dụng AI trong kỹ thuật
- Nếu từng kỳ vọng AI sẽ đưa sự nghiệp kỹ thuật lên một nấc mới, thì nó có thể vận hành theo hướng ngược lại
- LLM có thể tăng tốc sự bất tài, nhưng không thể thay thế kỹ thuật của con người
- Sức hấp dẫn về mặt kinh doanh của AI nằm ở việc hàng hóa hóa kỹ thuật để cắt giảm chi phí
- Tuy nhiên, cũng như việc tận dụng nhân tài kỹ thuật ở nước ngoài từng cho ra kết quả lẫn lộn, LLM cũng đi kèm giới hạn và rủi ro
- Chu kỳ cường điệu AI rốt cuộc có thể sẽ đạt đỉnh
- Những công ty đang lạm dụng AI hiện nay sẽ phải gánh chi phí dài hạn, rồi hoặc đổi hướng, hoặc biến mất
- Đề xuất giá trị dài hạn của con người trong kỹ thuật không thay đổi
- Thế giới vẫn cần năng lực kỹ thuật và tư duy sâu
- Và sẽ trả tiền cho những năng lực đó
- AI sẽ tiếp tục tồn tại, nhưng cần được dùng như công cụ, không phải như chiếc nạng để phụ thuộc vào
- Cần tiếp tục đầu tư vào những năng lực kỹ thuật cơ bản từng được xem là có giá trị vào năm 2019
1 bình luận
Các ý kiến trên Hacker News
Đôi khi cuộc thảo luận về lập trình bằng AI có vẻ phản ánh sự khác biệt giữa kỹ sư phần mềm và nhà khoa học dữ liệu/kỹ sư machine learning
Cả hai đều xử lý các yêu cầu mơ hồ và những lỗi khó bắt, nhưng nhìn chung kỹ sư phần mềm tạo ra phần mềm phải luôn hoạt động theo một cách nhất định, nên khả năng tái lập, kiểm thử và các công cụ trưởng thành là rất quan trọng
Trong khi đó, kỹ sư machine learning xử lý các mô hình vốn mang tính xác suất, và việc kiểm thử cũng tập trung vào các chỉ số đánh giá như “cho ra kết quả đúng trong 90% trường hợp” hơn là có tạo ra một đầu ra cụ thể hay không
Vì vậy, lối tư duy đối phó với AI không bao giờ hoàn toàn đáng tin cậy có vẻ tự nhiên hơn với phía machine learning, và họ đánh giá trợ lý lập trình theo kiểu “đúng 80% nên giảm công sức, 20% còn lại tôi tự bắt là được”
Khi làm ở Amazon, tôi thường thấy các giải pháp dựa trên machine learning rất phù hợp với những vấn đề thực tế không có cách tiếp cận cổ điển. Chẳng hạn dự đoán chuyển động dựa trên bản đồ dạng lưới hoặc phân loại ảnh/bản đồ lưới đã tích hợp tốt vào pipeline ước lượng và điều khiển hiện có, và tỏ ra hữu ích
Ngược lại, ở một startup nọ, tôi liên tục bị một quản lý cấp thấp trách mắng chỉ vì nghi ngờ cách tiếp cận dựa trên học máy cho bài toán ước lượng theo thời gian hướng của một mặt phẳng đứng yên. Vì đội không biết những kiến thức cơ bản về mapping hay filtering và giả định rằng “cứ nhét thêm dữ liệu là giải quyết được”, toàn bộ pipeline điều khiển xe đang phải ăn các giá trị ước lượng góc quay tùy ý, nhấp nháy và giật cục
Khoảng cách này thực sự lớn, và tôi ước có cách tốt hơn để sàng lọc trong phỏng vấn
Trước đây tôi từng nghe kiến trúc sư cấp cao của công ty phàn nàn sau một cuộc họp rằng sản phẩm của công ty chúng tôi luôn lấy độ chính xác và tính đúng đắn làm điểm bán hàng lớn, nhưng đội machine learning ở văn phòng khác không hiểu điều đó và cho rằng độ chính xác 80–90% là đủ cho khách hàng
Điều này làm tôi nhớ đến cuộc tranh luận về việc tỷ lệ tử vong 1% của một bệnh dịch đại dịch là nhỏ hay lớn. 1 là số nguyên nhỏ nhất, nhưng 1% của 300 triệu người là 3 triệu người
Nhưng tôi không nghĩ bài viết chỉ nói về chuyện đó. Bài viết bàn về những mối lo ở cấp độ meta của những người làm kỹ nghệ phần mềm và AI phù hợp với chúng như thế nào; khi nói đến “entropy của chương trình”, tôi nghĩ nó đã chạm đúng trọng tâm
Một phần lớn của việc xây dựng sản phẩm phần mềm là quản lý entropy. Phải tăng mã nguồn và con người mà vẫn duy trì tốc độ tiến lên phù hợp, đồng thời đảm bảo mọi người hiểu các mảnh ghép khớp với nhau ra sao và cách thêm mảnh mới. Một ngày nào đó AI có thể khiến việc này dễ hơn, nhưng hiện tại nó thường làm entropy tệ hơn
Điều đó đã không thành vấn đề lớn nếu những người có lợi ích liên quan không cố thuyết phục rằng “không phải vậy, AI có thể dùng ngay cho mọi thứ”
Giả định này phi lý đến mức thậm chí khó phản bác bằng logic, và cho đến nay nó đã rất thành công như một câu chuyện dựa trên niềm tin để thu hút đầu tư khổng lồ và đóng gói việc tối ưu hóa nhân sự vì lợi nhuận
Tôi rất đồng ý với tiền đề và phần lớn các luận điểm cụ thể của bài viết, nhưng khi dùng LLM trong công việc hằng ngày, tôi cũng thấy những mặt tích cực. Nói thêm là tôi đã làm trong ngành phần mềm khoảng 30 năm
Khi xử lý mã do AI tạo, ta phải đọc mã. Việc phát triển trở nên giống một chuỗi code review hơn là một hành trình sáng tạo từ con số không; với lập trình viên làm một mình, nó có lợi ở chỗ mô phỏng và giúp học loại trách nhiệm thường chỉ dễ học trong một đội
Ngoài ra, làm việc với LLM nhanh chóng cho thấy lập trình viên phải hiểu vấn đề theo các tầng rõ ràng và có cấu trúc tốt. Nếu giao một việc lớn trong một lần, thường là tự bắn vào chân mình, nên cách tiếp cận từ góc độ thiết kế, viết đặc tả chi tiết và triển khai theo từng phần giúp xác định ranh giới và interface của các khối khái niệm
Có thể xem LLM là một chất xúc tiến mạnh giúp lập trình viên junior trưởng thành lên vai trò senior. Với hướng dẫn phù hợp, nó phơi bày tiến trình của những bài học mà người nhiều kinh nghiệm hơn đã mất thời gian để học. Tôi không cho rằng mọi thứ đều u ám, AI cũng sẽ không thay thế lập trình viên; hiện tại nó rất gây xáo trộn, nhưng cuối cùng có lẽ sẽ tìm được vị trí nào đó giữa các công cụ khác
Khi review mã do LLM hỗ trợ tạo ra, có thể nói là ta đang đọc loại mã nhạt nhẽo hơn, nhưng tôi vẫn nghĩ là có học được. Tôi đã đọc rất nhiều mã do LLM tạo và thường học được các idiom chưa quen hoặc các lời gọi thư viện mà trước đó không biết
Với lập trình viên senior, LLM còn là chất xúc tiến mạnh hơn. Vì họ biết cái gì tồn tại và cái gì không cần thử, nên có thể prompt tốt hơn
Chỉ cần nhìn tin gần đây cũng thấy các đợt sa thải vẫn tiếp diễn ở Big Tech, các công ty công nghệ tầm trung và các công ty công nghệ nhỏ
Còn nhớ thời người ta nói in 3D sẽ thay thế toàn bộ ngành sản xuất không?
AI gần với tâm lý đó hơn là với điểm kỳ dị
Cũng có thể xem là LLM không hẳn đã cải thiện điều gì, mà chỉ phơi bày các khiếm khuyết mang tính hệ thống, nhưng bản thân tác động thì rất rõ. Hàng chục luồng giảng dạy vốn còn là chuẩn mực cách đây 2 năm nay không còn vận hành được nữa
Điều này đặc biệt bao gồm toàn bộ giáo dục trực tuyến/từ xa; trớ trêu là ChatGPT xuất hiện đúng vào thời điểm nhiều trường đại học bắt đầu đầu tư vào mảng này sau Covid. Đây là tác động ở quy mô toàn bộ lĩnh vực giáo dục đại học và trung học trên toàn thế giới
Hàng không vũ trụ là ví dụ tốt. Rất nhiều việc SpaceX và các startup trẻ trong lĩnh vực này đang làm sẽ không thể thực hiện nếu không có các linh kiện in 3D. Những bộ phận như vòi phun, buồng đốt, bơm tuabin thường được in ra
Dù vậy, phép so sánh này có vẻ không công bằng. Khi tôi làm cơ khí, in 3D cho phép tạo mẫu nhanh hơn, rẻ hơn và mắc lỗi dễ hơn, nên thực ra đã làm kỹ năng kỹ thuật của tôi tốt lên
Nó không thay thế toàn bộ sản xuất, nhưng đóng vai trò quan trọng trong thiết kế và không làm kỹ năng của người dùng thoái hóa
LLM rất đáng kinh ngạc trong việc viết code, nhưng lại rất tệ trong việc sở hữu và bảo trì code đó
Mỗi dòng bạn chấp nhận mà không hiểu đều là sự hiểu biết đi vay, và khi bảo trì bạn sẽ phải trả lại với lãi suất cao. Nó có cảm giác như tốc độ miễn phí, nhưng thực chất giống nợ kỹ thuật với lãi khoảng 40% mỗi năm hơn
Cộng đồng chúng ta cần tìm cách dùng AI để tự động hóa việc gõ phím, nhưng không tự động hóa việc suy nghĩ
Nhưng nó không hiểu, và theo cách nó vận hành thì cũng không thể hiểu
Vì vậy, mỗi dòng từ LLM mà bạn chấp nhận khi chưa hiểu thực ra là một sự hiểu biết không tồn tại. Nó chỉ là một dòng code do mô hình xác suất nhả ra, và vẫn ở trạng thái chưa được hiểu cho đến khi một thực thể có thể thật sự hiểu ngữ cảnh, hệ thống và thiết kế của codebase xem xét nó. Hiện tại thực thể duy nhất được biết đến làm được điều đó là con người
Trong phát triển truyền thống, tôi không thích cả hai lắm, nhưng LLM hiện nay khiến cả hai trở nên dễ hơn và hữu ích hơn
Và “quy tắc ba lần” về cơ bản ngừng áp dụng giữa các component. Tác động của code hoặc phải mang tính cục bộ, hoặc phải là một phần của thư viện nền tảng cực kỳ vững chắc. Các trường hợp nằm giữa sẽ làm độ phức tạp của refactoring bùng nổ
“LLM không phản biện các prompt mang tính dẫn dắt” là rủi ro đầu vào gây đau đầu nhất cho đến nay.
Điều còn bực hơn là có thể chính tôi cũng không biết mình đang dẫn dắt theo một hướng cụ thể. Nghĩ về cách LLM vận hành thì điều đó có lý, nhưng chỉ một từ được viết mơ hồ cũng có thể làm kết quả lệch theo hướng xấu, đi ngược với điều tôi muốn và rơi vào một hang thỏ sai lầm.
Đến khi nhận ra thì tôi đã đứng giữa một vũng bùn code chắp vá, chỉ vừa đủ chạy. Ngôn ngữ của con người rất mơ hồ và không cụ thể, gần như cũng chính vì thế mà ban đầu chúng ta đã phát minh ra các ngôn ngữ hình thức có quy tắc, cho phép sự chính xác.
Cá nhân tôi cũng cảm thấy kỹ năng của mình thoái hóa nhanh vì các công cụ AI. Có lúc vì lười nên việc nhỏ nào tôi cũng với tay tới AI, nhưng lùi lại nhìn thì cũng chẳng tiết kiệm được bao nhiêu thời gian; trái lại, tôi mệt nhanh hơn nhiều vì phải đọc hàng chục, hàng trăm dòng code, nghĩ xem AI sai ở đâu rồi sửa lại.
Tôi không đo đạc, nhưng nhìn chung có vẻ thời gian tôi lãng phí với công cụ AI nhiều hơn hẳn thời gian tiết kiệm được.
Vấn đề thật sự là AI quả thực hữu ích cho nhiều việc, nhưng người dùng lại thuộc hai nhóm. Một bên dùng nó cho các tác vụ phức tạp, nơi những lỗi nhỏ tích tụ rất nhanh; bên kia chủ yếu là kiểu quản lý, thấy nó nhả ra 200 dòng code mà họ không hiểu, rồi xem một ứng dụng TODO vừa đủ chạy là “MVP” và nghĩ rằng “nếu nó làm được cái này thì việc của anh cũng dễ thôi”.
Nếu định trả lời theo kiểu quen thuộc rằng tôi dùng sai hoặc model sai, thì mong bạn đọc trước bình luận cũ của tôi tại https://news.ycombinator.com/item?id=44055448 để có bối cảnh về trải nghiệm của tôi với các công cụ này.
Nói cách khác, AI là trợ lý của tôi, nhưng trách nhiệm tạo ra kết quả chất lượng tốt và có thể bảo trì vẫn thuộc về tôi.
Tuy vậy, nhìn từ góc độ đại chúng thì cứ nghĩ tới chiếc máy tính bỏ túi đơn giản. Máy tính đã làm hỏng khả năng tính nhẩm của con người. AI sẽ làm điều tương tự với khả năng viết, giao tiếp, giải quyết vấn đề, v.v.
Có vẻ các model bám vào một từ khóa nào đó trong luồng prompt, vứt bỏ logic truyền thống, rồi đẩy vấn đề vào một lối hẹp hơn, thậm chí không giải quyết đúng vấn đề ban đầu. Cuối cùng chỉ làm phía con người thêm thất vọng và khổ sở.
Để tránh thoái hóa kỹ năng, tôi cố chỉ dùng AI cho những tác vụ nhỏ, rõ ràng mà trước đây tôi sẽ giải bằng cách tìm trên StackOverflow. Thay vì tìm “làm X thế nào?”, tôi hỏi model cùng câu đó và dùng câu trả lời như hướng dẫn giải quyết vấn đề chứ không coi là đáp án đúng.
Dù vậy, hiện nay vẫn có những việc AI làm cho dễ hơn. Ví dụ nếu có mẫu để dùng như “làm giống trang này nhưng dùng dữ liệu x thay vì y”, thì nhiều khi nhanh hơn tìm tài liệu. Dĩ nhiên vẫn có cảnh báo rằng nó có thể hallucinate, nhưng cũng có khả năng sẽ cải thiện theo thời gian.
Điều tôi muốn thấy được cải thiện là ngoài việc nói chung chính xác hơn, nó còn phải tìm giải pháp đơn giản nhất mà không cần lần nào cũng phải nhắc. Nhược điểm lớn nhất khi thả ChatGPT, Claude, v.v. tự làm là chúng tạo ra rất nhiều rác rất nhanh và không dừng lại để nói “cái này về sau sẽ quá phức tạp để xử lý”. Bài gốc cho rằng chỉ con người, người hiểu toàn bộ thiết kế, mới có thể chống lại entropy; có thể phần này không phải mãi mãi không cải thiện, nhưng hiện tại tôi thấy đây là vấn đề lớn nhất.
Ở vòng đầu, thường những giả định chính mà model đang có sẽ lộ ra, rồi từ đó có thể thu hẹp và làm rõ dần.
Đọc bình luận cũ nói rằng bạn đã thử nhiều cách, tôi thấy trải nghiệm của bạn với LLM rộng hơn tôi nhiều. Tuy nhiên tôi không thấy kỹ thuật này trong đó, nên để lại đây phòng khi có ích cho ai đó.
Những câu như “không thể suy luận từ ý tưởng, sơ đồ, đặc tả yêu cầu”, “chỉ con người mới có thể giảm độ phức tạp” có vẻ là trường hợp một khái niệm thú vị đi kèm những khẳng định chi tiết rõ ràng là sai.
Việc này làm rất dễ. Chỉ cần yêu cầu nó đưa ra code đơn giản hơn. Tôi thường dùng nó để lấy ý kiến thứ hai và nhận được kết quả tốt.
Nếu không hỏi model thì bạn sẽ không nhận được cả câu trả lời phức tạp lẫn câu trả lời đơn giản. Việc mặc định hỏi nó cũng là một lựa chọn, chứ không phải điều cố hữu trong khái niệm LLM.
Tôi cũng dùng nó tốt cho việc chuyển đổi qua lại giữa code và ý tưởng/sơ đồ. Tôi không hiểu vì sao người ta lại đưa ra những khẳng định mạnh mà mỗi ngày đều bị thực tế bác bỏ như vậy.
Bài viết cũng lặp lại một kiểu lập luận kỳ lạ: nhìn bề ngoài thì có vẻ đúng, nhưng soi kỹ thì không đứng vững. Câu chuyện về Naur giờ đã thành meme và được lặp lại ngoài đời như một insight, nhưng nó quên mất một quy tắc cơ bản và thực dụng khác của kỹ nghệ phần mềm. Các chương trình không tầm thường rất nhanh sẽ vượt quá khả năng một người có thể giữ toàn bộ lý thuyết trong đầu.
Chúng ta hầu như không làm việc với một lý thuyết chương trình đúng nghĩa. Ngôn ngữ lập trình, kỹ thuật, phương pháp luận và công cụ đều phát triển theo hướng giúp con người làm việc tốt hơn dù không hiểu phần lớn code.
Ở điểm này, con người cũng chia sẻ cùng giới hạn với LLM; chỉ là chúng ta quản lý tốt hơn vì không phải chờ được phép chạy thêm một vòng suy luận nữa để có góc nhìn khác.
Tôi nghĩ có thể áp dụng logic tương tự cho các công nghệ bản đồ như Google Maps hay Apple Maps. Lập luận là khi dùng những công cụ này, khả năng khám phá thế giới vật lý, cảm giác phương hướng và cảm nhận địa lý của chúng ta sẽ bị thoái hóa
Thực ra nói vậy không hẳn sai. Ngày nay nhiều người gặp khó khăn khi tìm đường nếu không có chỗ dựa như Google Maps, và mối quan hệ của họ với thế giới vật lý cũng đã thay đổi theo nhiều cách
Nhưng trước đây cũng có nhiều người vốn không đặc biệt giỏi tìm đường. Đặc biệt, năng lực trung bình để đi từ điểm A đến điểm B một cách an toàn và ổn định ở một khu vực xa lạ chắc chắn đã tăng lên đáng kể
Và với số ít người có năng khiếu bẩm sinh về địa lý và tìm đường, các công cụ như Google Maps không thay thế năng lực của họ mà bổ trợ cho nó
Tôi nghĩ AI cũng sẽ kết thúc theo cách tương tự, nhưng ở quy mô lớn hơn. Chắc chắn có những đánh đổi, và một số kỹ năng, năng lực sẽ giảm đi, nhưng sẽ có nhiều người hơn rất nhiều làm được những việc trước đây họ không làm nổi, còn một số ít sẽ làm tốt hơn những việc họ vốn đang làm
Tất nhiên không phải lúc nào cũng vậy. Vì lập bản đồ toàn thế giới là một công việc cực kỳ phức tạp, có vô số ngoại lệ và trường hợp biên. Nhưng so với đầu ra của LLM thì khác xa. Dù đặt temperature là 0 và tạo lại cùng một prompt nhiều lần, đầu ra vẫn khác nhau đáng kể
Ngoài ra, LLM xử lý phạm vi khái niệm rộng hơn rất nhiều, nên người ta sẽ dùng nó thay cho cái đầu của mình trong rất nhiều tình huống mà đáng ra tuyệt đối không nên. Chỉ riêng bản đồ thôi đã có người lái xe xuống hồ chỉ vì Google Maps bảo đó là đường; tôi không thể tưởng tượng nổi chuyện gì sẽ xảy ra khi người ta mù quáng tin vào đầu ra của LLM và thay thế tư duy của mình bằng nó
Ở nơi tôi sống, Google Maps tốt hơn tài xế taxi trong 90% trường hợp
AI thì còn không giỏi hơn một người mới làm việc đó vài ngày
Thực tế là 70% nhân viên làm việc quá qua loa, đến mức AI thường làm được ngang hoặc tốt hơn họ
Khó khăn thật sự là những người vốn làm qua loa thì dù dùng AI vẫn vô dụng, còn những người còn lại thì học hỏi và trưởng thành cùng AI
Tự lái hoàn toàn cũng tương tự. FSD tốt hơn những tài xế con người tệ hại, say rượu hoặc vừa lái vừa nhắn tin, mà trên đường thì có rất nhiều người như vậy
Tôi tò mò tác giả lấy cảm giác rằng “[AI] không thể làm việc ở cấp độ khái niệm” từ đâu
Điều các LLM gần đây đã chứng minh lặp đi lặp lại là chúng rõ ràng có thể làm việc ở cấp độ khái niệm, chẳng hạn như dịch đúng các khái niệm của một ngôn ngữ sang ngôn ngữ khác tùy theo ngữ cảnh
Việc nói rằng chúng không “hiểu” khái niệm như con người lại là chuyện khác. Chúng chưa trải nghiệm đau đớn nên có lẽ không “hiểu” đau đớn, nhưng con người cũng liên tục nói về những thứ mình chưa trực tiếp trải nghiệm. Có nên làm vậy hay không là một chủ đề khác
Đây là một mô hình yếu cho một số đặc trưng của khái niệm, chẳng hạn như liên tưởng. Ví dụ “dog” liên quan đến “cat”. Nhưng nó không mô hình hóa tính hợp thành, hàm ý, hay vai trò của thuật ngữ trong các câu điều kiện phản thực
Tuy vậy, nếu câu hỏi giống dữ liệu huấn luyện, ta có thể thu được năng lực khái niệm bề ngoài bằng cách đẩy brute force. Nếu ai đó từng hỏi “chó chơi trên Sao Hỏa thì có vui không?” hoặc một nhóm câu hỏi đủ tương tự, thì có thể đặt “dog” quanh cụm “sự kiện theo nghĩa đen” và cụm của một số điều phản thực đã biết
Để thấy sự khác biệt giữa điều này và năng lực tinh thần thật sự, hãy nhìn vào việc các tổ hợp khái niệm ở độ sâu tùy ý là vô hạn, và có thể được cấu thành từ vô số điều phản thực. Một đứa trẻ chỉ có các thành phần cơ bản và trí tưởng tượng có thể đánh giá sự đa dạng vô hạn này
Vì vậy LLM được dùng nhiều nhất trong các lĩnh vực hẹp nơi “công việc khái niệm” cần thiết đã được ghi chép rất tốt và đủ ổn định, đặc biệt là kỹ thuật phần mềm
Tôi ngày càng nghĩ mạnh hơn rằng nên biến 90s.dev thành một cộng đồng không có AI. Một nơi tập trung vào kỹ nghệ cổ xưa của việc viết phần mềm tốt, và chào đón tất cả những ai đã rèn giũa kỹ năng đó
Cần gì để bắt đầu? Diễn đàn? Mailing list? Một cách gom blog của nhiều tác giả như hackernoon?
Tôi đã tạo một mailing list tạm thời cho những người quan tâm tại https://github.com/sdegutis/90s.dev/issues/2; nếu muốn nhận email về chủ đề này thì hãy đăng ký theo dõi hoặc bình luận
Diễn đàn đã bị LLM và bot phá hỏng, nên lựa chọn đó bị loại. Để thứ như thế hoạt động, nó phải chỉ dành cho người được mời, và mỗi người giới thiệu phải chịu trách nhiệm về cây lời mời của mình
Cộng đồng phải đủ tốt để việc mất quyền truy cập trở thành động lực khuyến khích hành vi tốt. Trong một số cộng đồng trực tuyến nhất định, cách này hoạt động rất tốt