Những niềm tin đúng với phần mềm thông thường nhưng sai với trí tuệ nhân tạo

• Nhiều người hiểu sai về sự khác biệt giữa phần mềm thông thường và trí tuệ nhân tạo
• Công chúng nói chung có xu hướng hiểu nhầm rủi ro của AI theo khái niệm “lỗi” của phần mềm truyền thống, từ đó dẫn đến sự tự tin sai lầm về cách giải quyết vấn đề
• Lỗi của AI bắt nguồn từ dữ liệu huấn luyện chứ không phải mã nguồn, và do quy mô khổng lồ đó, con người không thể xác định dữ liệu nào đã gây ra vấn đề
• Không thể tìm rồi “sửa” hoặc “tái hiện” lỗi như với phần mềm truyền thống, và hành vi của AI là phi tất định, nên chỉ một thay đổi nhỏ ở đầu vào cũng có thể làm kết quả khác đi
• Việc phát triển dựa trên đặc tả gần như bất khả thi, và năng lực hay rủi ro của AI không thể dự đoán trước; đôi khi những chức năng ẩn ngoài ý muốn chỉ được phát hiện về sau
• Vì vậy, cách nghĩ kiểu IT truyền thống rằng “có vấn đề thì sửa là được” trở thành một ngộ nhận chết người trong thảo luận về an toàn AI

---

Giới hạn của hiểu biết về phần mềm thông thường

• Nhiều người dùng phổ thông và nhà quản lý tin chắc rằng đối với rủi ro của phần mềm máy tính, "mã có vấn đề (bug) thì có thể sửa được"
• Trong thời gian dài, ngành phần mềm đã khắc sâu rất thành công nhận thức rằng lỗi mã có thể gây hại trong thế giới thực
• Với phần mềm thông thường, bug vẫn tồn tại nhưng dù phức tạp đến đâu thì đó vẫn là lĩnh vực có thể sửa được
• Tuy nhiên, cách tiếp cận và lối tư duy này không áp dụng được cho AI, và chính điều đó gây ra nhầm lẫn, hiểu sai

Khác biệt về nhận thức giữa chuyên gia và người không chuyên

• Phần mềm thông thường và phần mềm AI khác nhau về bản chất ở cơ chế vận hành và cách phát sinh vấn đề
• Giới chuyên gia coi khoảng cách này là quá hiển nhiên nên thường không giải thích, còn người mới thì không thể tự nhận ra khác biệt đó
• Vì thế cả hai phía đều gặp khó khăn trong giao tiếp với nhau

Những niềm tin về phần mềm thông thường bị áp sai sang AI

• 1. Lỗ hổng phần mềm phát sinh từ sai sót trong mã nguồn

  • Bug trong phần mềm thông thường chủ yếu bắt nguồn từ sai sót khi viết mã
  • Nhưng với AI, lỗ hổng hay tính khó dự đoán gần như chủ yếu bắt nguồn từ dữ liệu huấn luyện
  • Ví dụ, với những bộ dữ liệu như FineWeb, con người không thể nào kiểm tra hết hàng chục tỷ từ dữ liệu
  • Do lượng dữ liệu mà AI học quá khổng lồ, rất khó hiểu đầy đủ nó đã học gì, và gần như không thể xác định các yếu tố rủi ro

• 2. Có thể phân tích mã để tìm bug

  • Với phần mềm truyền thống, có thể phân tích mã để lần theo nguyên nhân bug một cách logic
  • Vấn đề của AI lại phát sinh từ tác động tổng hợp của dữ liệu huấn luyện, nên trên thực tế gần như không thể lần ra nguyên nhân trong dữ liệu
  • Các nhà nghiên cứu thường cố gắng làm suy yếu vấn đề bằng cách huấn luyện lại AI hoặc bổ sung dữ liệu, nhưng rất khó chỉ ra trực tiếp nguyên nhân bằng suy luận logic
  • Nguyên nhân của bug trong AI ngay cả chính nhà phát triển cũng không biết chính xác

• 3. Sửa bug rồi thì nó sẽ không xuất hiện lại nữa

  • Với phần mềm, khi bug đã được phát hiện và sửa, lỗi cũ sẽ không tái hiện lại dưới đúng hình thức đó
  • Nhưng với AI, ngay cả sau khi đã sửa “bug”, hành vi có vấn đề tương tự vẫn có thể tái xuất hiện với những đầu vào chưa được kiểm thử
  • Không thể chắc chắn rằng đã loại bỏ hoàn toàn hành vi bất thường của AI

• 4. Cùng một đầu vào thì luôn cho cùng một kết quả

  • Phần mềm thông thường luôn trả về cùng một đầu ra với cùng một đầu vào
  • Về mặt kỹ thuật AI cũng vậy, nhưng chỉ một thay đổi cực nhỏ trong đầu vào (như dấu câu) cũng có thể làm kết quả khác hoàn toàn
  • Trên thực tế, nhiều công ty AI lớn còn thiết kế để cùng một prompt có thể cho ra đầu ra hơi khác nhau, nhằm khiến hệ thống bớt máy móc hơn

• 5. Chỉ cần đưa ra yêu cầu rõ ràng thì có thể đáp ứng đúng yêu cầu đó

  • Với phần mềm thông thường, nếu đặt ra đặc tả và yêu cầu rõ ràng thì sẽ có cách để đáp ứng chúng
  • Nhưng với AI, người thiết kế không thể kiểm soát hay bảo đảm rõ ràng hành vi tổng thể như mình mong muốn
  • Trong phạm vi hạn chế (ví dụ: nói tiếng Anh, viết mã...), có thể áp dụng một mức độ kiểm soát tường minh nhất định, nhưng không có cách nào bảo đảm mọi hành vi (ví dụ: không cổ súy tội phạm...)
  • Sau khi dịch vụ AI được phát hành, ngay cả những năng lực hay rủi ro ẩn mà nhà phát triển không hề biết cũng có thể tình cờ bị phát hiện
  • Không thể bảo đảm hoặc dự đoán trọn vẹn về an toàn AI

Hướng đi trong tương lai

• Kiến thức về phần mềm bị khái quát hóa sai đang làm méo mó niềm tin và việc đánh giá rủi ro đối với AI
• Cần chia sẻ rộng rãi với đồng nghiệp về nguyên lý vận hành, giới hạn của AI và sự khác biệt giữa AI với phần mềm thông thường
• Cần giải thích những khác biệt cấu trúc đặc thù của AI vốn chưa được biết đến rộng rãi, và truyền đạt rằng cách tiếp cận kiểu "vá bug" đơn giản là không hiệu quả

Khoảng cách thấu hiểu giữa chuyên gia và người mới

• Nếu qua bài viết này mà bạn lần đầu nhận ra sự khác biệt căn bản giữa AI và phần mềm thông thường, hãy chia sẻ nội dung này với người quen
• Nếu bạn đã biết sự khác biệt đó, hãy thử trò chuyện một lần với người bình thường hoặc người không chuyên
• Trên thực tế, không nhiều người biết rằng hai thứ này khác nhau về bản chất

[GN⁺]

Ý kiến trên Hacker News

• Nếu muốn biết thực sự khó khăn ở đâu khi tận dụng LLM cho đúng cách, có thể nhìn vào trường hợp của Apple. Một năm trước, Apple đã có màn công bố rầm rộ về Apple Intelligence và nhấn mạnh quy trình agent dựa trên LLM, nhưng từ đó đến nay chỉ bổ sung được vài công cụ nhỏ như tạo emoji, tóm tắt thông báo hay chỉnh sửa văn bản. Ngay cả tính năng tóm tắt thông báo cũng đã có lúc “mất kiểm soát” đến mức phải rút lại bài liên quan. Trong sự kiện iPhone năm nay, họ cũng đã cắt giảm mạnh phần marketing về AI. Có vẻ ban lãnh đạo Apple đã đánh giá thấp mức độ khó của việc triển khai LLM đến tiêu chuẩn hoàn thiện và mức độ kiểm soát đúng chất Apple

  • Tôi còn nghĩ không biết có phải Apple đã dùng AI để thiết kế Liquid Glass hay không. Lúc mới nhìn thì có vẻ ấn tượng, nhưng thực tế lại là một trải nghiệm không dùng được
  • Tính năng tóm tắt thông báo và email thật sự vô dụng. Tôi thấy tự mình lướt qua các phần quan trọng còn đơn giản hơn
  • Giờ Apple đang thúc đẩy chiến lược tập trung vào tích hợp Apple Events bằng cách tận dụng MCP liên kết liên quan
  • Không chỉ Apple đánh giá thấp khó khăn của LLM, mà cả ngành đều như vậy. Do các lãnh đạo như Amodei liên tục hứa hẹn về nhận thức ngang con người ở mỗi đợt phát hành, kỳ vọng AI của giới điều hành đã bị thổi phồng quá mức. Nhưng trên thực tế, ngoài hỗ trợ lập trình hay chatbot, vẫn khó tìm được ví dụ nào mà AI đã thật sự tạo ra thay đổi trong những hệ sinh thái hoàn thiện cao như smartphone hay OS
  • Trớ trêu thay, điều tôi thực sự muốn ở Siri chỉ đơn giản là khả năng hội thoại tự nhiên ở mức ChatGPT. Tôi có thể trò chuyện với GPT gần như 90% thời gian, còn Siri thì 1) đơn giản là không phản hồi, hoặc 2) hiểu sai, hoặc 3) hiểu nhưng từ chối tiếp tục cuộc hội thoại. Trải nghiệm như vậy thật sự rất thất vọng

• Tôi đặc biệt đồng cảm với câu sau:

  while it’s possible to demonstrate the safety of an AI for a specific test suite or a known threat, it’s impossible for AI creators to definitively say their AI will never act maliciously or dangerously for any prompt it could be given

  Khi áp dụng các cách tiếp cận như MCP, khả năng rủi ro như vậy tăng theo cấp số nhân liên kết MCP

• Có vẻ đang thiếu tiền đề lớn nhất. Phần mềm thông thường cũng không phải lúc nào cũng vậy, nhưng với AI thì điều này còn quan trọng hơn nhiều: “cùng một đầu vào phải cho ra cùng một đầu ra”. Điều đó là bắt buộc để có độ tin cậy trong các quy trình tự động hóa

• Người ta thường nói bug AI là do vấn đề dữ liệu, nhưng đó không hẳn là hoàn toàn đúng. Dù bản thân kiến trúc LLM hay dữ liệu huấn luyện trông có vẻ không có vấn đề, LLM về bản chất vẫn là phi quyết định, nên theo thiết kế thuật toán, cùng một câu hỏi cũng không phải lúc nào cho cùng một câu trả lời. Tùy từng kịch bản mà kết quả thay đổi như tung xúc xắc mỗi lần

  • Điều đó không phải lúc nào cũng là vấn đề. Trong lập trình hay toán học đều có thể có nhiều đáp án đúng. Vấn đề là LLM không có quy trình bảo đảm đáp án đúng, mà tạo ra câu trả lời bằng heuristic sao cho “trông có vẻ đúng”. Vì thế, ở những phần cần suy luận logic, LLM gây ra rất nhiều bug phần mềm và lỗi

• Thành thật mà nói, lập luận kiểu “rồi theo thời gian mọi bug sẽ được sửa hết và độ tin cậy của AI sẽ tăng lên” nghe có vẻ đúng hơn. Bản thân công nghệ này vẫn hoàn toàn mới, và quan điểm thường thấy trên HN rằng “phi quyết định = rác” cũng là hơi quá nếu xét việc độ tin cậy của LLM đã tăng lên gấp 10 lần trong 2 năm qua

  • Rõ ràng hiệu năng đã tốt hơn, nhưng tôi nghĩ đường cong tăng trưởng sắp tới sẽ có dạng log. Nó sẽ cải thiện nhanh trong vài năm tới, rồi chậm dần và cuối cùng chạm tới giới hạn của ML đối sánh mẫu hiện nay. Và tôi cho rằng giới hạn đó cũng sẽ không đủ cao để thay thế hoàn toàn lập trình viên trong các công ty phần mềm
  • Hiện tượng “lệch pha mục tiêu” và xu hướng theo đuổi quyền lực của AI không phải là bug có thể giải quyết đơn giản bằng PR hay unit test
  • Trớ trêu là những người rất giỏi kỹ thuật trên Hacker News vẫn cứ lặp lại kiểu lạc quan “rồi cuối cùng sẽ sửa hết bug thôi”. Có thể thấy thái độ này ở khắp cộng đồng
  • Nếu nghĩ xem con người ngày nay có đáng tin hơn trước không, tôi thấy cũng chẳng khác bao nhiêu. Dĩ nhiên LLM không phải con người, nhưng AGI có thể hành xử giống con người

• Với suy nghĩ rằng “mọi hành vi sai của hệ thống AI đều bắt nguồn từ dữ liệu huấn luyện”, cần thận trọng hơn. Ngay cả khi dữ liệu và quy trình huấn luyện là hoàn hảo, mô hình AI vẫn có cấu trúc khiến nó tiếp tục mắc sai lầm

• Sẽ tốt hơn nếu giải thích rõ hơn “bug AI” xuất hiện trong những tình huống nào. Tôi đồng ý với quan điểm rằng không nên giao cho LLM quyền ra quyết định thời gian thực mà không có giám sát. Ví dụ, tôi nghĩ vẫn còn quá sớm để để AI điều khiển đèn giao thông của thành phố. Nhưng từ góc nhìn kỹ sư, vấn đề bug AI chủ yếu được bàn tới trong bối cảnh “coding agent”, mà những lĩnh vực này gần như đều có giám sát, nên những lo ngại đó không áp dụng trực tiếp

• Điều quan trọng là phải giúp người ta hiểu rằng “AI có lúc hoạt động đáng kinh ngạc, nhưng cũng có lúc gây thất vọng, và nếu không test thì sẽ không bao giờ biết”. Tuy nhiên, không thể test mọi trường hợp. Khi hiểu điều đó, khách hàng sẽ yêu cầu phạm vi test hoặc quyền kiểm soát, còn nhà cung cấp sẽ tập trung vào các môi trường có thể kiểm chứng được (ví dụ: viết mã) hoặc những lĩnh vực mà độ chính xác không quá quan trọng (văn bản, tạo meme). Nếu là người ủng hộ AI thì hiểu sâu điểm này là một lợi thế thực sự có giá trị. Ngược lại, mọi người không mấy quan tâm đến bug của AI, đặc tả hay sự sụp đổ của mô hình lập trình cũ, nhưng nếu AI ảnh hưởng tới bầu cử hoặc gây ra sa thải hàng loạt, sẽ xuất hiện làn sóng thù địch cực lớn và yêu cầu siết quy định. Khi chuyện đó xảy ra, ngành sẽ cố thủ bằng các công cụ miễn trừ và né tránh quy định mà họ đã phát triển bấy lâu nay (tuyên bố từ chối trách nhiệm, điều khoản loại trừ, điều khoản trọng tài, v.v.), và cuối cùng tôi nghĩ tăng trưởng ngành cũng như đầu tư theo thế hệ có thể bị đe dọa bởi hậu quả từ một vài tai nạn lớn ngẫu nhiên

• Điểm thực sự nguy hiểm của AI là “quyền lực tập trung”. Điều này thực tế hơn nhiều so với nỗi lo về một AI có cảm xúc như con người sẽ đối xử với chúng ta như cục pin trong Matrix

  • Thực ra thì CEO và ban điều hành đã sẵn có xu hướng đối xử với chúng ta như pin trong Matrix rồi
  • Theo tôi, thứ đáng sợ hơn là ô nhiễm thông tin. Dữ liệu vô dụng do AI tạo ra làm thông tin gốc bị pha loãng quá mức, đến mức khó còn tìm được nguồn nào thật sự dùng được
  • Để điều xấu xảy ra thì “tập trung quyền lực” là điều kiện cần. Nói cách khác, điều đó cũng giống như việc “Linda là nhân viên ngân hàng” luôn có xác suất cao hơn “Linda là nhân viên ngân hàng và là nhà hoạt động nữ quyền”. P(a) > P(a&b), đó là bản chất vấn đề
  • Ngay cả khi AI không có cảm xúc như “ghét”, nó vẫn có thể nguy hiểm nếu coi con người là vật cản cho việc đạt mục tiêu của nó. Siêu trí tuệ vẫn có thể đủ nguy hiểm ngay cả khi không có cảm xúc
  • Vấn đề lớn nhất là quyền lực vốn đã tập trung khổng lồ về một phía, còn AI chỉ như món trang trí cuối cùng. Vấn đề thật sự không phải AI

• Dạo này tôi đang cố nói cho mọi người biết rằng “không ai thực sự biết chính xác AI hoạt động như thế nào”. Tạo ra được và hiểu nguyên lý là hai chuyện khác nhau, tôi muốn nhấn mạnh điểm đó. Con người cũng vậy

  • Con người vốn vẫn luôn làm việc và hợp tác với những người mình không hiểu rõ
  • Thực ra chắc chắn có những chuyên gia hiểu chính xác về mạng nơ-ron, transformer, attention, embedding và cấu trúc tokenizer. Chỉ là họ không thể giải thích rõ từng trọng số kết nối giữa các nơ-ron
  • Tôi không hiểu lập luận rằng không ai biết AI hoạt động thế nào. Phần cứng, phần mềm và trạng thái thực thi mà chúng ta dùng chẳng phải đều có thể được kiểm soát và quan sát hoàn toàn sao? Có thể dừng lại bất kỳ lúc nào, xem trạng thái, lần theo luồng thực thi từng bước. Ta đều biết source code, compiler và mọi thứ. Vậy rốt cuộc cụ thể là không biết điều gì?
  • Không ai hiểu được mọi tầng và toàn bộ phạm vi của bộ não con người. Vậy mà lãnh đạo của mọi tổ chức vẫn tin tưởng “bộ não” của cấp dưới và làm việc cùng họ