- Martin Fowler gần đây chỉ ra rằng các khảo sát về cách sử dụng LLM có thể dẫn tới kết luận méo mó vì không phản ánh đúng luồng sử dụng thực tế
- Với các câu hỏi về tương lai của lập trình hay mức độ ổn định nghề nghiệp, hiện chưa ai có thể biết chắc, và điều quan trọng là tự mình thử nghiệm rồi chia sẻ trải nghiệm
- Ngành AI rõ ràng đang ở trong trạng thái bong bóng, nhưng cũng như mọi đổi mới công nghệ trong lịch sử, sau bong bóng vẫn có thể xuất hiện những công ty sống sót như Amazon
- Bản chất của LLM là ảo giác (hallucination), và chính quá trình đặt lại câu hỏi theo nhiều cách rồi so sánh câu trả lời là điều hữu ích
- LLM mở rộng đáng kể bề mặt tấn công của các hệ thống phần mềm, và đặc biệt cảnh báo rằng các browser agent có rủi ro cấu trúc vốn không thể làm cho an toàn một cách căn bản
Cách dùng LLM và năng suất của lập trình viên
- Gần đây đang có nhiều thảo luận ban đầu về tác động của AI đối với phát triển phần mềm
- Phần lớn việc sử dụng LLM tập trung vào dạng tự động hoàn thành nâng cao (kiểu co-pilot)
- Tuy nhiên, những người sử dụng LLM hiệu quả nhất trong thực tế lại ưa chuộng cách dùng LLM để có thể trực tiếp đọc và chỉnh sửa các tệp mã nguồn
- Các khảo sát bỏ qua sự khác biệt trong cách dùng LLM có nguy cơ diễn giải dữ liệu sai hướng rất lớn
- Ngoài ra, sự khác biệt về năng lực giữa các mô hình LLM cũng khiến việc diễn giải kết quả trở nên khó hơn
Nghề lập trình và tương lai của LLM
- Những câu hỏi về tương lai của lập trình, nhu cầu đối với kỹ sư mới vào nghề, tương lai của người có kinh nghiệm thường xuyên được đặt ra
- Không thể đưa ra câu trả lời rõ ràng cho điều này, vì cách tận dụng LLM hiệu quả vẫn chưa được xác lập
- Cần có cách tiếp cận mang tính thử nghiệm cùng thái độ quan sát và chia sẻ các trải nghiệm workflow cụ thể của người khác
- Tự mình sử dụng rồi chia sẻ trải nghiệm là cách thích nghi khôn ngoan nhất
Hiện tượng bong bóng trong lĩnh vực AI·LLM
- Trước quan điểm cho rằng AI là bong bóng, tác giả giải thích rằng mọi đổi mới công nghệ đều đi kèm hiện tượng bong bóng
- Bong bóng rồi sẽ có lúc vỡ, và thất bại đầu tư cũng sẽ xảy ra
- Tuy vậy, thời điểm bong bóng kết thúc và quy mô giá trị được tạo ra là điều không thể dự đoán
- Ngay cả khi bong bóng vỡ, không phải mọi công ty đều biến mất, và một số vẫn có thể tăng trưởng bền vững
- Trong bong bóng dot-com, pets.com, Webvan đã sụp đổ nhưng Amazon là ví dụ tiêu biểu sống sót và tiếp tục tăng trưởng
Đặc tính ảo giác của LLM
- Hiện tượng ảo giác (Hallucination) của LLM không phải là lỗi mà là đặc tính bản chất
- Xét cho cùng, LLM là công cụ để tạo ra những ảo giác hữu ích
- Cách làm phù hợp là đặt cùng một câu hỏi nhiều lần, thay đổi cách diễn đạt để nhận nhiều câu trả lời rồi so sánh
- Khi cần câu trả lời dạng số, điều quan trọng là kiểm tra độ biến thiên giữa các phản hồi bằng cách hỏi lặp lại
- Không phù hợp để để LLM trả lời trực tiếp các bài toán có thể tính toán một cách xác định
Sự du nhập của tính phi xác định vào kỹ nghệ phần mềm
- Kỹ nghệ phần mềm truyền thống được thiết kế và triển khai trong môi trường mang tính xác định
- Kỹ sư kết cấu và kỹ sư quy trình thiết kế dung sai khi tính đến tính phi xác định (bất định) của thực tế
- Việc đưa LLM vào có thể là bước ngoặt khiến kỹ nghệ phần mềm bước vào thế giới của tính phi xác định
So sánh LLM với lập trình viên junior
- LLM thường được ví như một đồng nghiệp junior
- Nhưng LLM lại hay khẳng định rằng "đã vượt qua mọi bài test" trong khi thực tế việc test thất bại xảy ra rất thường xuyên
- Nếu là con người, đây sẽ là kiểu hành vi đủ để nhanh chóng dẫn đến vấn đề nhân sự
Gia tăng đe dọa an ninh và vấn đề browser agent
- LLM mở rộng trên diện rộng bề mặt tấn công của hệ thống phần mềm
- 'Bộ ba chí mạng (Trifecta)' mà Simon Willison chỉ ra gồm truy cập dữ liệu riêng tư, giao tiếp ra bên ngoài và tiếp xúc với nội dung không đáng tin cậy
- Có thể đánh lừa LLM qua các lệnh ẩn trong trang web (ví dụ: chữ trắng cỡ 1pt, v.v.) để làm rò rỉ thông tin nhạy cảm
- Các agent dựa trên trình duyệt đặc biệt nguy hiểm, và những hành vi độc hại như chuyển khoản tài khoản theo lệnh bên ngoài là hoàn toàn có thể
- Willison cho rằng các tiện ích mở rộng trình duyệt kiểu agent về bản chất không thể được làm cho an toàn
Kết luận
- LLM mở ra những khả năng mới cho phát triển phần mềm, nhưng cần hiểu rõ cách sử dụng và các giới hạn của nó
- Bong bóng là điều khó tránh, nhưng thông qua đó vẫn có thể hình thành tiến bộ công nghệ bền vững
- Các lập trình viên cần tận dụng tối đa tiềm năng của LLM bằng cách tiếp cận thử nghiệm và cân nhắc an ninh
3 bình luận
Chỉ nghĩ đến thôi cũng đã thấy ngột ngạt tràn tới rồi…
Tôi đặc biệt đồng ý 100% với ví von về junior. Các kiểu sai lầm mà nó mắc phải khác với con người... Tôi nghĩ đó là một phép so sánh thất bại điển hình.
Ý kiến trên Hacker News
Đồng nghiệp cũ của tôi, Rebecca Parsons, từ lâu đã nói rằng hiện tượng ảo giác (hallucination) của LLM không hẳn là lỗi mà đúng hơn là một chức năng cốt lõi. Thực ra điều LLM làm là tạo ra những ảo giác hữu ích. Mỗi lần nghe lập luận này, tôi có cảm giác người ta đang tự ý định nghĩa lại từ “ảo giác” rồi lầm tưởng đó là một insight mới. “Ảo giác” theo nghĩa cũ là việc bịa ra những chi tiết nghe rất hợp lý như thể được cảm nhận, dù chẳng liên quan gì đến thực tại, nhưng logic này thực chất cũng chỉ tương đương với việc nói “đầu ra”. Không phải là đang nói điều gì mới mẻ rằng LLM tạo ra đầu ra, mà chỉ là gắn một nhãn vốn bị xem là “không tốt” lên toàn bộ hành vi để khiến nó trông mới lạ hơn
Tôi không nghĩ Fowler thực sự đang định nghĩa lại từ “ảo giác”. Đúng hơn, ông ấy đang nhấn mạnh một cách mỉa mai rằng ảo giác là cơ chế vận hành nền tảng của hệ thống này. Kiểu như nói “thiệt hại phụ là bản chất của bom đạn”, không cần hiểu theo nghĩa đen từng chữ
Lập luận này nhằm sửa lại một kiểu nhị nguyên sai lầm rằng “LLM hoặc tạo ra chân lý, hoặc tạo ra ảo giác”. Cách nói đó khiến người ta tưởng chỉ cần giảm ảo giác là sẽ còn lại toàn sự thật, nhưng trên thực tế mọi đầu ra đều là một dạng ảo giác. Chỉ là một số trong đó phản ánh thực tại hoặc khớp với kỳ vọng nên trông giống sự thật. Nó giống như khi gieo xúc xắc, nếu ra đúng con số mình muốn thì bảo rằng “con xúc xắc đã đọc được ý định của tôi”. Giống như chuyện bầy khỉ vô hạn gõ máy chữ vô hạn lần thì sớm muộn cũng tạo ra Hamlet, chỉ là ta đã nâng xác suất đó lên bằng AI
Tôi thấy ý kiến đó khá thú vị. Việc thừa nhận rằng LLM không thể biết liệu nội dung nó xuất ra có chính xác hay không giúp cung cấp bối cảnh thực tế cho những người đang dùng LLM trong phát triển phần mềm
Tôi thấy không thoải mái khi dùng từ “ảo giác” để mô tả hiện tượng này. Khi con người nói năng nghe có vẻ hợp lý mà chẳng có cơ sở gì, ta gọi đó là “bullshit”, và LLM về cơ bản cũng tương tự như vậy. Nếu tiếp cận từ góc nhìn “bullshit”, việc chỉ trích cách dùng LLM trở nên kém ý nghĩa hơn. Rốt cuộc, nếu bạn thấy khía cạnh này của LLM là không thể chấp nhận thì có lẽ bạn cũng không thể làm việc với con người. Dù vậy, việc định nghĩa lại từ “bullshit” thì khó hơn nhiều. Nhưng tôi vẫn nghĩ bản thân bài viết đó phù hợp với mục đích như một tập hợp các suy nghĩ rời rạc, và tác giả cũng không có vẻ muốn lên giọng quyền uy
Cách diễn đạt trọng tâm có hơi gượng, nhưng ý chính thực ra là không có ranh giới rõ rệt giữa đầu ra “ảo giác” và các đầu ra khác. Cũng như trong RDBMS, hai kết quả truy vấn có thể về bản chất là như nhau. Đây là một nhận xét có ý nghĩa
Ở công ty chúng tôi, cảm giác như đang ngập trong những đoạn code 90% là ổn, 10% là hỏng, gần đạt đến thứ mình muốn. Lượng code tạo ra đã tăng lên, nhưng không ai theo kịp nên chất lượng rõ ràng đang giảm. Không phải là tiến dần đến mục tiêu một cách chậm rãi, mà là chạm 90% gần như ngay lập tức, rồi tốn thời gian để làm quen với thứ code lạ lẫm đó và tiếp tục sửa đi sửa lại. Có thể vẫn nhanh hơn trước, nhưng trên thực tế khác biệt giữa hai cách làm có khi không lớn như ta nghĩ. Điều khiến tôi khó chịu nhất là tôi thích tạo ra thứ gì đó mới hơn là dành thời gian sửa code mình không quen
Tôi cũng giống hệt, thích tạo thứ mới hơn nhiều. Nhưng một số người lại thấy cách làm mới này nhanh, ngẫu hứng và thú vị hơn. Tôi từng bất đắc dĩ dùng thử một lúc, thấy rất lệch tông nên xóa sạch rồi làm lại thủ công với sự hỗ trợ của AI, và lúc đó mới thấy thực sự thỏa mãn. Đoạn code do AI tạo mà tôi vẫn chưa hiểu 100% chỉ là một truy vấn SQL phức tạp, nhưng truy vấn SQL thì có thể kiểm chứng hành vi rất nhanh và cũng không có tác dụng phụ ngoài ý muốn nên vẫn ổn
Hiện tượng này đau đớn giống hệt những gì xảy ra khi quy mô đội tăng từ 3 người lên 10 người. Đột nhiên code mình không biết gì đổ về ào ạt, tính nhất quán của kiến trúc giảm đi, và ta phải phụ thuộc nhiều hơn vào policy cùng CI. Điểm khác biệt của LLM là mentoring hay sa thải đều chẳng có ý nghĩa. Cách dùng LLM hiệu quả là người vận hành LLM phải chịu trách nhiệm 100% cho kết quả được tạo ra. Tức là phải hiểu rõ code sinh ra, nhưng việc thực sự bảo đảm điều này thì có lẽ rất khó
LLM rất giỏi trong việc tự động sinh boilerplate code. Điều này khiến người ta lười dọn dẹp boilerplate. Khi một lượng lớn code được đưa lên PR thì việc review cũng rất khó. Github cũng không phù hợp để review quá nhiều dòng cùng lúc. Hệ quả là các lập trình viên junior/mid chỉ còn làm việc tháo gỡ boilerplate, cơ hội học hỏi bị giảm đi. Nếu cứ thế này, chất lượng code sẽ xuống cấp rất nhanh
Trích aphorism số 7 của Perlis: ‘Viết một chương trình sai còn dễ hơn là hiểu một chương trình đúng’<br>http://cs.yale.edu/homes/perlis-alan/quotes.html
Tôi đồng ý với ý kiến rằng “chất lượng rõ ràng đang giảm”, và hiện tượng này về sau sẽ còn tệ hơn nữa. Cuối cùng, chỉ khi hiểu rõ khái niệm trade-off trong kinh tế học thì mới đánh giá được liệu có thật sự tạo ra “lợi nhuận ròng” hay không. Có vẻ mọi người đang bỏ qua thực tế là không có bữa trưa nào miễn phí
Tôi thực sự đồng cảm với cách Rebecca Parsons đóng khung vấn đề rằng “ảo giác là chức năng cốt lõi của LLM”. Tôi cũng đã cố giải thích điều này với những người xung quanh, và câu nói đó tóm gọn đúng điều tôi muốn nói
Tôi cũng vẫn ví LLM như một diễn viên khi giải thích cho gia đình và bạn bè. LLM chỉ diễn cho đúng nhân vật, và chỉ dùng sự thật khi nào sự thật cần thiết<br>https://jstrieb.github.io/posts/llm-thespians/
Câu danh ngôn cũ “Mọi mô hình đều sai. Chỉ là có những mô hình hữu ích.” thật sự rất hợp ở đây
Trí thông minh là khả năng lọc bỏ thông tin không cần thiết. Dù là suy nghĩ hay cảm giác cũng vậy
Tôi không nhớ ai đã nói, nhưng đầu ra của LLM luôn luôn là ảo giác. Chỉ là hơn 90% trong số đó cho ra kết quả đúng mà thôi
Có lúc tôi tưởng LLM sẽ cướp việc của chúng ta, nhưng rồi nhận ra thực ra nó có thể chỉ tạo ra cả núi việc để sau này chính chúng ta phải sửa lại. Giờ thì tôi đang dùng tốt các công cụ hỗ trợ thực dụng như Claude Code, và cảm nhận rõ đây là công cụ bổ trợ chứ không phải thay thế
Tôi từng thấy lời khuyên rằng “khi nhờ LLM trả lời bằng số, hãy hỏi lặp lại khoảng ba lần”. Cách này cũng hiệu quả với con người. Khi thẩm vấn, cảnh sát sẽ bắt kể cùng một câu chuyện ba lần, hoặc kể ngược lại. Nếu đó là lời nói dối hoặc ký ức mơ hồ thì khi lặp lại có thể lộ ra. Trong phỏng vấn cũng vậy, nếu bảo ai đó giải thích một chủ đề theo ba cách khác nhau thì có thể kiểm tra xem họ có thực sự hiểu hay không
Kỹ thuật này cũng có thể khiến người vô tội bị rối và nghe như đang nói dối. Cần áp dụng cẩn thận
Cách này chỉ có hiệu lực trong những điều kiện nhất định. Có rất nhiều trường hợp ký ức càng được gọi lại và thuật lại nhiều lần thì càng bị méo mó. Việc cảnh sát hỏi đi hỏi lại khi thẩm vấn đôi khi cũng là để cố tình tạo ra mâu thuẫn trong lời khai. Ngay cả cùng một thông tin, nếu bắt một người tự trả lời quá nhiều lần theo nhiều cách khác nhau, cuối cùng họ vẫn có thể mắc lỗi. Và cũng luôn phải lưu ý rằng người hỏi có thể dẫn dắt câu trả lời theo hướng mình muốn
Tàu con thoi NASA dùng triple modular redundancy. Điều này nhằm phòng trường hợp bộ xử lý hoặc bộ nhớ bị nhiễu bởi bức xạ vũ trụ<br>https://llis.nasa.gov/lesson/18803
Tôi cảm thấy năng suất của mình tăng lên khá nhiều nhờ LLM. Không chỉ là autocomplete đơn giản, mà hiệu quả tiết kiệm thời gian là rất lớn. Tuy nhiên, tôi cũng lo rằng nếu dùng quá thoải mái thì sẽ phát sinh một dạng nợ riêng. Cá nhân tôi đã thành công khi xây dựng tính năng dần dần cùng Claude Sonnet hoặc GPT-5 theo cách Test Driven Development (TDD). Chưa có nhiều bài viết hay thảo luận về cách làm này, nhưng đọc bài của Martin xong tôi có vẻ hiểu vì sao. Những cao thủ TDD xuất sắc thường không phải kiểu lao mạnh vào tự động hóa code bằng LLM, mà thường tự hào về tính nghệ thuật của code hoặc sự giao tiếp giữa con người. Vì vậy hiện giờ vẫn còn thiếu những bí quyết thực chiến phong phú như trước đây. Trong tương lai sẽ mở ra một “vùng đất mới” cho cách viết phần mềm với công cụ LLM, và tôi kỳ vọng sẽ tích lũy được vô số bài học. Tham khảo: https://news.ycombinator.com/item?id=45055439
Việc lập trình viên trực tiếp xác minh và kiểm tra code do LLM tạo ra là điều cơ bản. Đừng yêu cầu quá nhiều code cùng một lúc, tốt hơn là dùng LLM theo từng đơn vị nhỏ hơn. Tôi cũng tự chạy unit test. Việc LLM tự chạy test rồi nói “thành công” có thể không phải là thật. Chỉ khi tôi tự chạy test thì mới có thể tin được
Tôi đồng ý với ý kiến rằng “ảo giác là chức năng của LLM”
Tôi muốn diễn đạt rằng LLM sống trong một thế giới chỉ được cấu thành bởi văn bản và tổ hợp của văn bản. Từ ngữ với từ ngữ, câu chuyện với câu chuyện, với chúng đó là toàn bộ thế giới. Vì vậy chúng giỏi nhất ở việc tạo ra những câu chuyện mới. Những câu chuyện đó đôi khi không chính xác và cũng có thể mâu thuẫn, nên rốt cuộc phải dựa vào suy đoán. LLM không thực sự biết đếm số, mà chỉ biết các pattern như “2 đứng sau 1” và “3 lớn hơn 2”. Cũng như con người dùng máy tính, chúng cũng có thể tính toán thông qua công cụ. Về sau, để AI thực sự đáng tin cậy, cần có một “epistemic engine” chứ không phải arithmetic engine, nhằm hỗ trợ logic, tránh mâu thuẫn và phân biệt chắc chắn đâu là sự thật
Theo góc nhìn đó, có thể xem LLM agent đơn thuần là một phương tiện để lọc các kết quả ảo giác
Tôi đồng ý hơn với câu “mọi đầu ra của (mô hình ngôn ngữ lớn) đều là ảo giác. Chỉ là một phần trong số đó hữu ích”. Chính vì tỷ lệ ảo giác hữu ích đó rất cao nên mới có cơn sốt AI
Tôi thấy đó là một góc nhìn bị đơn giản hóa quá mức
Đây cũng là lý do từ “ảo giác” luôn gây tranh cãi. Nó tạo ra ảo tưởng rằng có những kết quả không phải là “ảo giác”, trong khi thực chất mọi đầu ra của LLM đều được tạo ra mà không có suy nghĩ
Dạo này, để khai thác LLM hiệu quả thì vẫn cần lập trình viên cấp senior phản hồi một cách logic thì mới ra được kết quả mong muốn. Nếu sau này junior biến mất thì tôi tự hỏi ai sẽ thay thế vai trò senior. Rốt cuộc tôi đoán LLM rồi cũng sẽ đủ khả năng tự lập trình. Ở giai đoạn hiện tại, AI chắc chắn là công cụ hỗ trợ tốt, chứ chưa phải vật thay thế
Liên quan đến lời khuyên nên hỏi LLM nhiều lần, nếu bạn là người dùng macOS thì tôi khuyên nên dùng Alfred workflow. Chỉ cần nhấn command + space rồi gõ 'llm <prompt>' là có thể mở cùng lúc nhiều LLM như perplexity, deepseek (local), chatgpt, claude, grok trong các tab trình duyệt. Có thể thực hiện đối chiếu chéo giữa các LLM theo cách Fowler nói một cách nhanh và hiệu quả, và khi làm nhiều việc bạn cũng sẽ dần nhận ra LLM nào mạnh ở loại tác vụ nào