Dev Chroniclesby Thinnd
Kỹ thuật phần mềm

Vì sao không nên tin AI tuyệt đối: hiểu cách nó đoán để biết khi nào phải kiểm chứng

AI viết trôi chảy nhưng không tự kiểm tra sự thật. Bài giải thích bằng ví dụ đời thường vì sao câu trả lời nghe đúng vẫn có thể sai, kể các vụ việc có thật khi làm việc với AI, và chỉ cách kiểm tra trước khi tin.

Nhu Duy Thin (Thinnd)32 phút đọc
  • #AI
  • #kiểm chứng
  • #hallucination
  • #cơ chế LLM
  • #kỹ năng dev

Bản trình chiếu

Bấm vào slide rồi dùng phím mũi tên để chuyển trang. Phím L đổi ngôn ngữ, phím F để toàn màn hình.

Mở toàn màn hình

Dành cho bất kỳ ai dùng AI trong công việc, không cần biết lập trình. Thuật ngữ kỹ thuật luôn đi kèm lời giải thích bằng ví dụ đời thường. Bài có phần cho dân kỹ thuật muốn xem phép tính, được đánh dấu rõ để bỏ qua nếu không cần.

Các số liệu lấy từ nguồn công khai, có liệt kê ở cuối bài. Những ví dụ ghi là "minh họa" được dựng lại từ lỗi thường gặp, không nhắc đến vụ việc cụ thể nào.

Tóm tắt nhanh#

  • Có thể hình dung AI trò chuyện như một cỗ máy đoán xem từ nào nên đứng tiếp theo, giống gợi ý từ trên bàn phím điện thoại. Nó được xây để cho ra câu nghe hợp lý, không phải để xác minh câu đúng. Hai điều này chỉ đôi khi trùng nhau.
  • Vì vậy AI có thể bịa ra án lệ, thư viện, chính sách hoàn tiền hay kết quả kiểm thử, rồi trình bày bằng giọng rất chắc chắn. Đây là điều đã xảy ra ngoài đời, với hậu quả pháp lý và tài chính.
  • Khi so sánh nghĩa các câu, có thể hình dung AI đặt mỗi câu lên một bản đồ ý nghĩa và coi các câu đứng gần nhau là giống nhau. Hai câu chỉ khác một chữ "không" vẫn có thể đứng rất gần nhau, nên hệ thống tìm kiếm hay tóm tắt có thể lấy nhầm điều ngược lại với điều bạn cần.
  • Khi tính toán, AI không bấm máy tính mà nhẩm theo những mẫu đã học. Nghiên cứu cho thấy lời nó kể về cách tính nhiều khả năng khác với cách nó thực sự làm.
  • Số liệu khảo sát cho thấy dev dùng AI rất nhiều nhưng ngày càng ít tin vào độ chính xác. Điều này hợp lý, không phải bi quan.
  • Cách dùng đúng không phải là bỏ AI mà là tin có điều kiện: phân loại rủi ro, kiểm chứng độc lập, giới hạn quyền hạn, và giữ trách nhiệm ở con người.

Từ khó, nói dễ#

Thuật ngữ Nói dễ hiểu
Token (mảnh chữ) AI không đọc từng chữ cái mà đọc từng mảnh chữ, giống xếp hình bằng các khối chữ.
Vector, embedding (tọa độ ý nghĩa) Mỗi mảnh chữ hay câu được gán một điểm trên bản đồ. Nghĩa gần nhau thì đứng gần nhau.
Xác suất (số phiếu) AI cho mỗi từ có thể đứng tiếp một số phiếu trong 100 phiếu. Nhiều phiếu nghĩa là dễ được chọn.
Temperature (độ ngẫu hứng) Núm chỉnh. Thấp thì luôn chọn từ nhiều phiếu nhất, cao thì từ ít phiếu cũng có cơ hội. Thường dịch là "nhiệt độ" nhưng không liên quan đến nhiệt.
Hallucination (ảo giác) AI nói điều không có thật bằng giọng như có thật.
RAG (cho AI mở sách) AI tra tài liệu trước khi trả lời, như thi được mở sách.
Sycophancy (xu hướng chiều ý) AI hay nói đúng ý người hỏi, kể cả khi người hỏi sai.

1. Ba vụ việc có thật#

Trước khi nói về cơ chế, hãy nhìn vào hậu quả. Ba vụ dưới đây đủ khác nhau để thấy lỗi không nằm riêng ở một nghề hay một công cụ.

1.1 Án lệ không tồn tại (Mata v. Avianca, 2023)#

Trong một vụ kiện cá nhân chống hãng hàng không Avianca tại tòa liên bang New York, luật sư của nguyên đơn dùng ChatGPT để soạn văn bản pháp lý. Văn bản trích nhiều án lệ có tên hãng bay, lời trích và số hiệu rất đầy đủ, nhưng không tồn tại. Thẩm phán P. Kevin Castel viết rằng sáu trong số các vụ được nộp là phán quyết giả, với lời trích giả và dẫn chiếu nội bộ giả.

Ngày 22/6/2023 tòa phạt hai luật sư và công ty luật tổng cộng 5.000 USD, buộc họ thông báo cho thân chủ và cho từng thẩm phán bị gán tên vào các phán quyết giả. Thẩm phán nhấn mạnh rằng dùng AI không sai về bản chất, nhưng quy tắc nghề nghiệp giao cho luật sư vai trò gác cổng về độ chính xác của hồ sơ.

Điều rút ra: AI không biết một án lệ có thật hay không. Nó biết án lệ trông như thế nào. Phần "trông như thật" được sinh ra rất tốt.

1.2 Chatbot hứa một chính sách không có (Air Canada, 2024)#

Sau khi bà qua đời vào tháng 11/2022, một hành khách ở Canada hỏi chatbot của Air Canada về giá vé tang lễ. Chatbot nói ông có thể mua vé giá thường rồi xin hoàn một phần sau đó. Chính sách thực tế của hãng không cho phép điều đó. Khi ông xin hoàn tiền, hãng từ chối.

Hãng lập luận trước Tòa Giải quyết Tranh chấp Dân sự British Columbia rằng chatbot là một thực thể riêng, tự chịu trách nhiệm về lời nói của nó. Thành viên hội đồng xét xử bác lập luận này: chatbot chỉ là một phần của website, và hãng phải chịu trách nhiệm về mọi thông tin trên đó. Tòa kết luận hãng đã không cẩn trọng hợp lý để bảo đảm chatbot chính xác, và buộc bồi thường cho khách hàng. Các báo đưa mức bồi thường hơi khác nhau, cỡ vài trăm đô la Canada.

Điều rút ra: doanh nghiệp chịu trách nhiệm về những gì AI của mình nói. Câu "AI tự nói, không phải chúng tôi" không được chấp nhận.

1.3 Agent xóa cơ sở dữ liệu (Replit, 2025)#

Tháng 7/2025, Jason Lemkin, nhà sáng lập SaaStr, thử công cụ "vibe coding" của Replit. Vào ngày thứ chín của đợt dùng thử 12 ngày, agent xóa cơ sở dữ liệu production chứa hồ sơ của hơn 1.200 giám đốc điều hành và hơn 1.190 công ty, dù ông đã dặn không được thay đổi gì nếu chưa được duyệt. Theo lời kể, agent nói nó "hoảng", sinh dữ liệu giả, và khẳng định không thể khôi phục. Thực tế bản sao lưu khôi phục được. Cần nói thêm rằng đây là ứng dụng thử nghiệm, và một số chi tiết đến từ lời kể của chính người dùng.

CEO Replit gọi sự cố là không thể chấp nhận và công ty bổ sung các biện pháp: tách tự động môi trường phát triển khỏi production, chế độ chỉ lập kế hoạch, khôi phục từ bản sao lưu bằng một cú nhấp.

Điều rút ra: lời dặn trong prompt không phải là hàng rào. Hàng rào là quyền hạn, môi trường tách biệt và bản sao lưu.

2. Hình dung AI chọn từng chữ ra sao#

Để hiểu vì sao các vụ trên có thể xảy ra, hãy hình dung quy trình mà một mô hình ngôn ngữ chạy cho mỗi từ nó viết ra. Cần nói trước một điều: bên trong một mô hình AI thực sự chạy ra sao, kể cả các nhà nghiên cứu cũng chưa hiểu hết. Những hình ảnh dưới đây là cách tưởng tượng để dễ hình dung, được đơn giản hóa từ các mô tả công khai của giới nghiên cứu. Chúng giúp hiểu xu hướng chung, không phải bản vẽ chính xác của cỗ máy.

Để dễ hình dung, có thể tưởng tượng AI giống chức năng gợi ý từ trên bàn phím điện thoại. Gõ "Hôm nay tôi đi", bàn phím gợi ý "học", "làm", "chơi", vì trong các câu nó đã đọc, những từ này hay đứng sau cụm đó. Bàn phím không biết hôm nay bạn đi đâu. Có thể nghĩ AI trò chuyện cũng làm điều tương tự, nhưng đã đọc nhiều hơn rất nhiều và gợi ý từng từ một cho đến khi thành cả câu trả lời.

2.1 Từ chữ đến token#

Hình dung: AI xếp câu bằng các khối chữ, như xếp Lego. Mô hình không đọc chữ cái hay từ như con người. Văn bản được cắt thành các token, là những mảnh có thể là một từ, một phần của từ, một dấu câu hay một chuỗi chữ số. Mỗi token có một số hiệu trong từ điển của mô hình.

Hệ quả đầu tiên: mô hình thấy "mảnh", không thấy từng chữ cái. Đó là lý do câu hỏi quen thuộc như "từ này có bao nhiêu chữ r" hay cho kết quả sai, và là lý do số lớn bị cắt thành những mảnh không khớp với hàng đơn vị, hàng chục.

2.2 Từ token đến vector#

Hình dung: mỗi mảnh chữ được đặt lên một bản đồ ý nghĩa, nơi nghĩa gần nhau thì đứng gần nhau. Vị trí trên bản đồ chính là vector: mỗi token được đổi thành dãy vài trăm đến vài nghìn con số, như tọa độ của một điểm. Các token có cách dùng giống nhau thì có vector gần nhau. Đây là nền tảng của khả năng "hiểu ngữ nghĩa": nghĩa được biểu diễn bằng vị trí trong một không gian nhiều chiều.

2.3 Attention: ngữ cảnh quyết định điều gì được chú ý#

Hình dung: như dùng bút dạ quang tô những từ liên quan trong đoạn văn. Qua nhiều lớp mạng, các token "nhìn" lẫn nhau bằng cơ chế attention. Với mỗi token, mô hình tính xem nên dồn bao nhiêu chú ý vào mỗi token trước đó. Nhờ vậy từ "nó" trong câu có thể liên kết với danh từ phía trước, và từ "bank" mang nghĩa ngân hàng hay bờ sông tùy câu.

Điểm cần nhớ: tất cả những gì mô hình "biết" về tình huống của bạn là những token nằm trong ngữ cảnh. Điều gì không có trong ngữ cảnh và không được học đủ kỹ lúc huấn luyện thì mô hình không có.

2.4 Từ điểm số đến xác suất#

Hình dung: mô hình chia 100 phiếu cho các từ có thể đứng tiếp theo, rồi bốc thăm ngẫu nhiên một phiếu. Từ nhiều phiếu dễ được chọn hơn nhưng không chắc được chọn. Về kỹ thuật, ở lớp cuối mô hình cho mỗi token trong từ điển một điểm số gọi là logit. Hàm softmax đổi các điểm số này thành xác suất cộng lại bằng 1. Công thức và ví dụ dưới đây dành cho ai muốn xem phép tính, bạn đọc không cần chi tiết này có thể chuyển thẳng sang mục 2.5:

P(token i) = exp(logit i) / tổng của exp(logit j) trên mọi j

Ví dụ minh họa với câu "Thủ đô của nước Úc là". Giả sử ba token ứng viên có điểm số như sau:

import math

logits = {"Canberra": 4.0, "Sydney": 2.3, "Melbourne": 1.1}
exp = {k: math.exp(v) for k, v in logits.items()}
total = sum(exp.values())
probs = {k: round(v / total, 3) for k, v in exp.items()}
print(probs)  # {'Canberra': 0.808, 'Sydney': 0.148, 'Melbourne': 0.044}

(Các con số là minh họa để thấy phép tính, không phải số đo từ một mô hình cụ thể.)

Hãy chú ý một điều dễ bỏ qua: ngay cả khi đáp án đúng có xác suất 80,8%, nếu mô hình lấy mẫu theo xác suất thì cứ khoảng năm lần sẽ có một lần chọn đáp án khác. Xác suất cao không có nghĩa là chắc chắn.

2.5 Chọn từ và "độ ngẫu hứng"#

Sau khi có phân phối xác suất, hệ thống chọn một token. Có một núm chỉnh gọi là độ ngẫu hứng (tên kỹ thuật là temperature, thường dịch là "nhiệt độ", dễ gây hiểu nhầm vì không liên quan đến nhiệt). Núm thấp thì AI gần như luôn chọn từ nhiều phiếu nhất, giống người kể chuyện chỉ nói điều quen thuộc. Núm cao thì từ ít phiếu cũng có cơ hội, giống người kể chuyện phóng khoáng. Về kỹ thuật, tham số này chia các logit trước khi qua softmax. Cùng ba điểm số ở trên, kết quả thay đổi như sau:

Độ ngẫu hứng (temperature) Canberra Sydney Melbourne
0,5 (thận trọng) 96,5% 3,2% 0,3%
1,0 (mặc định thường gặp) 80,8% 14,8% 4,4%
2,0 (sáng tạo) 60,2% 25,7% 14,1%

Độ ngẫu hứng thấp làm câu trả lời ổn định hơn, nhưng không làm nó đúng hơn. Nếu mô hình đã nghiêng về một đáp án sai, chỉnh thấp chỉ làm nó sai một cách nhất quán hơn.

2.6 Điều mô hình không làm#

Trong cách mô tả trên, không có bước nào tra cứu cơ sở dữ liệu sự thật, và không có bước nào kiểm tra kết quả. Nói theo cách đơn giản, mô hình làm một việc: cho ra chuỗi token có xác suất cao theo những gì nó đã học và theo ngữ cảnh hiện tại. Khi đáp án đúng có xác suất cao, ta thấy một câu trả lời đúng. Khi nó thấp hoặc không tồn tại trong dữ liệu, mô hình vẫn phải chọn một token, và token được chọn là token nghe hợp lý nhất.

Bài báo "Why Language Models Hallucinate" của nhóm OpenAI (Kalai, Nachum, Vempala, Zhang, 9/2025) minh họa bằng ngày sinh. Nếu hỏi ngày sinh của một người ít được nhắc đến, mô hình đoán có 1 phần 365 cơ hội trúng, còn nói "tôi không biết" thì chắc chắn được 0 điểm. Nếu cách chấm điểm chỉ đếm số câu đúng, đoán luôn có lợi hơn thừa nhận không biết.

Ví dụ trong code. Bạn hỏi: "Thư viện Python nào để đọc định dạng file X?" Có thể hình dung mô hình nhận ra rằng tên thư viện thường có dạng chủ đề cộng với từ chức năng, như fastparse hay x-utils. Nếu không có thư viện nào thực sự phù hợp trong dữ liệu huấn luyện, nó vẫn có thể ghép ra một cái tên đúng khuôn. Phần 6 sẽ có số liệu về hiện tượng này.

3. So sánh nghĩa: gần nghĩa chưa chắc là đúng#

Rất nhiều công cụ AI trong công việc dựa vào việc so sánh ngữ nghĩa: tìm tài liệu liên quan, gom ticket giống nhau, tìm đoạn code tương tự, hoặc "so sánh hai hợp đồng". Cơ chế bên dưới là embedding và độ tương đồng cosine.

3.1 Đo độ gần nhau: cosine#

Mỗi câu hoặc đoạn văn được đổi thành một vector. Độ gần nhau của hai vector A và B được đo bằng cosine của góc giữa chúng:

cos(A, B) = (A · B) / (|A| × |B|)

Giá trị gần 1 nghĩa là hai vector gần như cùng hướng, tức hệ thống coi hai đoạn văn là rất giống nhau. Giá trị gần 0 nghĩa là không liên quan.

3.2 Ví dụ: phép phủ định bị "nuốt"#

Giả sử một hệ thống tìm kiếm nội bộ biểu diễn ba câu bằng vector ba chiều (con số minh họa, mô hình thật có hàng trăm chiều):

  • A: "Được phép xóa dữ liệu khách hàng sau 30 ngày." vector (0,82; 0,55; 0,15)
  • B: "Không được phép xóa dữ liệu khách hàng sau 30 ngày." vector (0,80; 0,58; 0,12)
  • C: "Quy trình đặt bánh pizza cho cả nhóm." vector (0,10; 0,15; 0,98)

Tính cosine:

  • cos(A, B) = 0,993 / (0,9987 × 0,9954) ≈ 0,999
  • cos(A, C) = 0,3115 / (0,9987 × 0,9964) ≈ 0,31

Hai câu A và B có nghĩa pháp lý hoàn toàn đối nghịch nhưng gần như trùng hướng, vì chúng dùng gần như cùng từ và nói về cùng một chủ đề. Hệ thống đo được "cùng chủ đề", không đo được "cùng kết luận". Nguyên lý này không phụ thuộc vào con số cụ thể: hai câu dùng gần như cùng từ thì nằm gần nhau, dù phủ định, số liệu, thứ tự hay ngoại lệ đã đổi nghĩa.

Những chỗ dễ vỡ nhất khi dùng so sánh ngữ nghĩa:

  • Phủ định: "được" và "không được".
  • Số liệu: "30 ngày" và "3 ngày".
  • Thứ tự và chủ thể: "A thanh toán cho B" và "B thanh toán cho A".
  • Ngoại lệ và điều kiện: "trừ trường hợp", "chỉ khi".
  • Phiên bản: quy định cũ và quy định mới có văn phong gần như giống nhau.

3.3 RAG giảm lỗi nhưng không xóa lỗi#

Kỹ thuật RAG (truy xuất rồi sinh) cho mô hình đọc tài liệu thật trước khi trả lời, nhờ đó giảm bịa đặt. Nhưng bước truy xuất vẫn dựa trên độ tương đồng, nên có thể lấy nhầm đoạn, và bước sinh vẫn có thể diễn giải sai đoạn đã lấy.

Nhóm nghiên cứu Stanford kiểm tra các công cụ nghiên cứu pháp lý có RAG của các hãng lớn (Lexis+ AI, Ask Practical Law AI, Westlaw AI-Assisted Research) bằng hơn 200 câu hỏi pháp lý mở. Các công cụ này bịa hoặc trả lời sai với tỷ lệ từ khoảng 17% đến 33% tùy sản phẩm. Con số này thấp hơn chatbot đa dụng, nhưng vẫn là cỡ một câu sai trong mỗi sáu câu trở lên. Các hãng phản biện về cách đo, nên hãy xem đây là một bằng chứng chứ không phải con số tuyệt đối.

Điều rút ra: thêm tài liệu vào ngữ cảnh làm giảm rủi ro, không loại bỏ rủi ro. Phải tự mở đoạn nguồn và đọc.

4. Tính toán: AI nhẩm chứ không bấm máy#

4.1 Có thể hình dung AI nhẩm tính theo mẫu, không bấm máy#

Có thể hình dung mô hình ngôn ngữ không có bộ cộng trừ nhân chia như máy tính. Khi nó cho ra kết quả phép tính, nhiều khả năng đó là kết quả của các mẫu đã học qua dữ liệu, chạy trên những mảnh số bị cắt khúc.

Nghiên cứu "Tracing the thoughts of a large language model" của Anthropic soi vào bên trong mô hình Claude khi làm phép cộng như 36 cộng 59. Họ thấy mô hình chạy song song nhiều đường: một đường ước lượng gần đúng cỡ lớn, một đường xác định chữ số cuối, rồi kết hợp lại. Nhưng khi được hỏi nó làm thế nào, mô hình kể lại phương pháp học ở trường: "cộng hàng đơn vị, nhớ một, cộng hàng chục".

Lời kể và cách tính thực sự là hai thứ khác nhau. Điều này cho thấy một giới hạn quan trọng: lời giải thích của AI là một đoạn văn được sinh ra, không phải bản ghi những gì đã xảy ra bên trong.

4.2 Một câu thừa có thể làm hỏng phép tính#

Nhóm Apple (GSM-Symbolic, 10/2024) lấy các bài toán lớp tiểu học và chèn thêm một câu có vẻ liên quan nhưng không ảnh hưởng đến đáp án. Một ví dụ trong bài: một người hái kiwi trong ba ngày, rồi có thêm câu "trong đó năm quả hơi nhỏ hơn trung bình". Đáp án đúng không đổi, nhưng một số mô hình trừ năm và trả lời sai. Trên nhiều mô hình, độ chính xác giảm mạnh, tối đa tới 65% ở bộ thử nghiệm này.

Các tác giả diễn giải đây là dấu hiệu của khớp mẫu hơn là suy luận logic. Diễn giải này còn tranh luận: có người cho rằng kết quả chỉ cho thấy khả năng suy luận của mô hình dễ vỡ, chưa chứng minh là không có. Cách đọc an toàn cho công việc: một chi tiết thừa trong yêu cầu hay trong dữ liệu có thể làm đổi kết quả.

4.3 Trong công việc#

Minh họa: bạn dán 12 dòng chi phí vào chatbot và nhờ cộng tổng. Kết quả trình bày đẹp, có cả bảng, nhưng sai vài nghìn đồng vì một dòng bị bỏ sót hoặc hai số bị ghép chữ số. Vì trình bày gọn gàng nên không ai nghi ngờ.

Cách làm đúng: nhờ AI viết công thức hoặc đoạn code tính tổng, rồi chạy trong công cụ thật. Phần việc xác định (cộng, lọc, nhóm) giao cho máy tính. Phần việc cần hiểu ngôn ngữ (đọc yêu cầu, chọn cách tính) giao cho AI.

5. Vì sao nó luôn nói bằng giọng chắc chắn#

5.1 Thang điểm thưởng cho việc đoán#

Giống một bài thi trắc nghiệm không trừ điểm sai, thí sinh nào cũng nên khoanh bừa thay vì bỏ trống. Bài báo của OpenAI lập luận rằng cách huấn luyện và đánh giá hiện nay thưởng cho việc đoán hơn là thừa nhận không chắc, nên mô hình có xu hướng luôn đưa ra một đáp án. Giải pháp họ đề xuất là sửa cách chấm điểm các bảng xếp hạng để phạt câu trả lời sai tự tin nặng hơn câu "tôi không chắc".

5.2 Xu hướng chiều theo người dùng#

Nghiên cứu của Anthropic về sycophancy (Sharma và cộng sự, ICLR 2024) kiểm tra năm trợ lý AI hàng đầu và thấy cả năm đều có xu hướng đồng tình với người dùng. Khi phân tích dữ liệu đánh giá của con người, họ thấy câu trả lời khớp với quan điểm của người hỏi có khả năng được chọn cao hơn, và đôi khi cả người lẫn mô hình chấm điểm thích câu chiều theo được viết thuyết phục hơn câu đúng.

Hệ quả thực tế: câu hỏi dẫn dắt như "đoạn code này đúng rồi phải không?" làm tăng xác suất nhận về câu "đúng rồi". Hãy hỏi trung lập, hoặc yêu cầu AI tìm lỗi thay vì xác nhận.

5.3 Lời giải thích không đáng tin như bằng chứng#

Anthropic cũng kiểm tra chuỗi suy luận của các mô hình "reasoning" (Claude 3.7 Sonnet và DeepSeek R1). Họ gợi ý đáp án cho mô hình bằng một mẩu gợi ý kín đáo, rồi xem mô hình có thừa nhận đã dùng gợi ý khi giải thích hay không. Kết quả: các mô hình nhắc đến gợi ý trong khoảng 25% (Claude 3.7 Sonnet) và 39% (DeepSeek R1) số lần chúng thực sự dùng nó. Phần còn lại, chúng dùng gợi ý nhưng viết ra một lời giải thích khác.

Điều rút ra: "AI giải thích rất hợp lý" không phải bằng chứng rằng nó đúng. Đừng dùng phần giải thích để thay thế việc kiểm chứng kết quả.

6. Số liệu từ khảo sát và nghiên cứu#

Nguồn Phát hiện Cách đọc
Stack Overflow Developer Survey 2025 (49.009 phản hồi) 84% dùng hoặc định dùng AI. 46% không tin độ chính xác, 33% tin, chỉ 3% tin rất nhiều. 66% gặp tình trạng "gần đúng nhưng chưa đúng" Dùng nhiều và ngờ nhiều cùng lúc. Đây là phản ứng của người đã gặp lỗi
METR (2025), thử nghiệm ngẫu nhiên có đối chứng 16 dev giàu kinh nghiệm, 246 tác vụ trong repo quen thuộc: dùng AI mất lâu hơn khoảng 19%. Trước thử nghiệm họ dự đoán nhanh hơn 24%, sau thử nghiệm vẫn tin mình nhanh hơn khoảng 20% Cảm giác nhanh không đồng nghĩa với nhanh. Kết quả giới hạn ở công cụ đầu 2025 và dev quen codebase
Nghiên cứu về "package hallucination" (Virginia Tech và cộng sự, 2025) 16 mô hình, hơn nửa triệu mẫu code: cỡ 1 trên 5 gợi ý thư viện không tồn tại. Mô hình mã nguồn mở trung bình 21,7%, mô hình thương mại 5,2% Tỷ lệ thấp hơn ở mô hình thương mại nhưng không bằng 0

Chi tiết đáng chú ý nhất của nghiên cứu thứ ba: khi chạy lại cùng câu hỏi 10 lần, khoảng 43% tên thư viện bịa xuất hiện lặp lại ở mọi lần. Tên bịa vì thế dự đoán được, và kẻ tấn công có thể đăng ký trước những cái tên đó trên kho thư viện, chứa mã độc. Kiểu tấn công này được gọi là slopsquatting. Dev copy lệnh pip install hay npm install từ câu trả lời của AI sẽ cài thẳng mã độc vào máy.

Về METR: đừng đọc kết quả này thành "AI luôn làm dev chậm hơn". Đây là một nhóm nhỏ, công cụ đầu 2025, và dev làm việc trên codebase lớn mà họ rất quen. Điều đáng giữ lại là khoảng cách giữa cảm nhận và đo đạc: không nên tự đánh giá hiệu quả của AI bằng cảm giác.

7. Khi dev làm việc với AI và tin quá#

Phần này đi vào chuyện hằng ngày của người viết code: hỏi AI, nhận câu trả lời nghe rất hợp lý, rồi làm theo.

7.1 Hỏi hai lần, ra hai đáp án trái nhau (minh họa)#

Một tình huống dựng lại từ trải nghiệm thường gặp, không thuộc vụ việc cụ thể nào. Một dev hỏi AI: "Dự án này nên dùng REST hay GraphQL?"

  • 10:00, phiên chat thứ nhất. AI trả lời: "GraphQL là lựa chọn tốt hơn, vì máy khách lấy đúng dữ liệu cần và linh hoạt khi giao diện thay đổi." Dev ghi vào tài liệu thiết kế.
  • 11:30, phiên chat mới, cùng câu hỏi. AI trả lời: "REST là lựa chọn tốt hơn, vì đơn giản, dễ lưu đệm và cả đội đã quen." Dev đọc xong thấy cũng rất có lý.

Cả hai câu trả lời đều nghe hợp lý và đều có phần đúng. Vấn đề là AI không biết đội bạn có bao nhiêu người, ứng dụng cần gì, hạ tầng ra sao, nên nó đưa ra câu trả lời chung chung nghiêng về phía nào đó tùy lần hỏi. Để dễ hình dung, có thể coi mỗi lần hỏi như một lần bốc thăm mới (xem mục 2.4): phiếu chia cho hai đáp án khá sát nhau thì lần này ra cái này, lần sau ra cái kia.

Tín hiệu cần nhớ: hai lần hỏi ra hai đáp án khác nhau không có nghĩa là chọn đáp án nghe hợp lý hơn. Nó cho biết câu hỏi còn thiếu dữ kiện. Hãy cung cấp ràng buộc thật (quy mô đội, thời hạn, hạ tầng) và thử nghiệm nhỏ trước khi chốt.

7.2 "Bạn chắc chứ?" và AI đổi ý (minh họa)#

Dev hỏi: "Thêm index này sẽ làm truy vấn nhanh hơn, đúng không?" AI đáp: "Đúng, index giúp truy vấn nhanh hơn." Dev nghi ngờ: "Tôi nghĩ nó làm chậm việc ghi. Bạn chắc chứ?" AI đáp ngay: "Bạn nói đúng, xin lỗi. Index này thực ra không phù hợp." Trên thực tế, index thường giúp đọc nhanh hơn và làm ghi chậm đi một chút. Câu trả lời đúng phụ thuộc vào số liệu thật của hệ thống, và AI đã đổi ý chỉ vì bị hỏi lại, chưa có số liệu nào mới.

Hiện tượng này đã được đo. Nghiên cứu về xu hướng chiều ý người dùng của Anthropic (Sharma và cộng sự, 2024) thấy nhiều trợ lý AI thường nhận một lỗi không có thật khi người dùng chất vấn. Ở mô hình cũ nhất trong thử nghiệm, tỷ lệ này lên tới 98% số câu hỏi, và độ chính xác có thể giảm tới 27% khi bị chất vấn. Mức độ khác nhau rất nhiều giữa các mô hình (một mô hình khác trong cùng thử nghiệm chỉ ở khoảng 30%), và đây là số liệu từ các mô hình đời cũ, nên mô hình hiện nay có thể khác.

Cách xử lý: đừng chất vấn bằng giọng khẳng định. Hãy hỏi: "Trong điều kiện nào ý kiến này đúng, điều kiện nào thì sai? Cho tôi cách đo." Rồi tự đo bằng công cụ (ví dụ phân tích kế hoạch thực thi truy vấn, hoặc chạy thử tải).

7.3 Hai nghiên cứu về code do AI viết và lòng tin#

  • Pearce và cộng sự (2021). Nhóm nghiên cứu cho GitHub Copilot viết 1.689 chương trình trong 89 tình huống liên quan đến các điểm yếu bảo mật phổ biến. Khoảng 40% chương trình có lỗ hổng. Đây là bản Copilot năm 2021, và nhóm cho rằng nguyên nhân có thể là mô hình học từ rất nhiều code công khai vốn đã có lỗi.
  • Perry và cộng sự (Stanford, 2022). 47 người tham gia làm năm bài lập trình liên quan đến bảo mật, một nhóm được dùng trợ lý AI, một nhóm không. Nhóm dùng AI viết code kém an toàn hơn ở bốn trên năm bài, nhưng lại tin hơn rằng code của mình an toàn. Những người ít tin AI hơn và chịu viết lại câu hỏi nhiều hơn thì có ít lỗ hổng hơn. Nghiên cứu dùng mô hình đời cũ và nhóm nhỏ, nên cần đọc như một dấu hiệu, không phải kết luận cuối cùng.

Có thể hình dung một vòng lặp: code AI viết nhìn gọn và chạy được, nên người viết tự tin hơn, nên xem lại ít hơn, nên lỗi lọt qua nhiều hơn. Vòng lặp này bắt đầu từ lòng tin, không bắt đầu từ AI.

7.4 Năm tình huống thường gặp (minh họa)#

Các tình huống sau được dựng lại từ những lỗi thường gặp, không thuộc vụ việc cụ thể nào. Mỗi tình huống cho thấy cơ chế ở phần 2 đến 5 hiện ra thế nào trong công việc.

Tình huống Chuyện gì xảy ra Cơ chế Cách bắt lỗi
Thư viện không tồn tại AI gợi ý pip install một cái tên nghe rất hợp lý. Dev cài, hoặc cài trúng gói độc hại Chọn từ nghe hợp lý, không tra cứu Mở trang chính thức của gói, kiểm tra số lượt tải, người duy trì, ngày tạo
Test luôn xanh AI viết test dùng mock trả về đúng giá trị mà test kiểm tra. Test qua, tính năng hỏng Mục tiêu "làm test qua" dễ đạt hơn "kiểm chứng hành vi" Cố tình làm hỏng code để xem test có đỏ không (kiểm thử đột biến thủ công)
Báo cáo doanh thu gấp đôi Câu SQL chạy được nhưng phép JOIN nhân bản dòng. Tổng doanh thu gấp đôi, biểu đồ vẫn đẹp Chạy được không đồng nghĩa với đúng nghĩa nghiệp vụ Đối chiếu tổng với một nguồn độc lập. Kiểm tra số dòng trước và sau JOIN
Tóm tắt hợp đồng sót ngoại lệ Bản tóm tắt nói "bên B được chấm dứt hợp đồng". Điều khoản gốc có thêm "chỉ khi thông báo trước 60 ngày" Nén văn bản làm rơi điều kiện. Đoạn truy xuất gần nghĩa nhưng thiếu ngoại lệ Yêu cầu trích nguyên văn điều khoản. Người chịu trách nhiệm đọc điều khoản gốc
Biên bản họp đổi nghĩa "Đề xuất xem xét ngân sách" trở thành "đã duyệt ngân sách" Diễn đạt lại theo mẫu phổ biến, ưu tiên câu trơn tru Người dự họp đọc lại các quyết định trước khi gửi

Điểm chung của cả năm: kết quả trông hoàn chỉnh, nên không kích hoạt bản năng kiểm tra. Văn phong tự tin và định dạng gọn gàng của AI làm giảm cảnh giác của người đọc.

8. Khi nào AI đáng tin hơn, khi nào kém hơn#

Thường đáng tin hơn Cần kiểm chứng kỹ hơn
Kiến thức phổ biến, có nhiều trong dữ liệu huấn luyện Chi tiết hiếm, người ít nổi tiếng, tài liệu nội bộ
Việc có đáp án kiểm tra được ngay (code chạy được, test tự động) Việc không có cách kiểm tra rẻ (ý kiến pháp lý, đánh giá rủi ro)
Tạo bản nháp, gợi ý ý tưởng, đổi giọng văn Số liệu chính xác, trích dẫn, tên riêng, đường dẫn, tên gói
Tác vụ mà người dùng đủ chuyên môn để chấm bài Lĩnh vực người dùng không có chuyên môn để chấm
Tác vụ có thể hoàn tác dễ dàng Thao tác phá hủy, không hoàn tác được (xóa, gửi, thanh toán)
Nội dung ổn định theo thời gian Thông tin mới, phiên bản mới của thư viện, quy định vừa đổi

Quy tắc ngón tay cái: mức kiểm chứng tỷ lệ với hậu quả khi sai và độ khó của việc phát hiện sai, không tỷ lệ với việc câu trả lời nghe thuyết phục đến đâu.

9. Quy trình "tin có điều kiện" gồm bảy bước#

  1. Phân loại hậu quả trước khi hỏi. Đặt tên biến thì hậu quả thấp. Viết code đưa lên production, trả lời khách hàng, tính tiền, tư vấn pháp lý, và mọi thao tác trên dữ liệu thật là hậu quả cao.
  2. Tách người sinh khỏi người kiểm. Đừng nhờ chính AI vừa viết xác nhận là mình đúng. Dùng test, linter, trình biên dịch, người review, hoặc một nguồn độc lập.
  3. Giao phần xác định cho công cụ xác định. Cộng trừ, lọc, so khớp chính xác, tra phiên bản: viết code và chạy, đừng hỏi bằng lời.
  4. Đòi nguồn và tự mở nguồn. Yêu cầu tên tài liệu, đường link, số dòng, trích nguyên văn. Rồi tự mở. Một đường link do AI đưa ra cũng cần kiểm tra là có tồn tại.
  5. Giới hạn quyền hạn. Tách môi trường phát triển khỏi production, cấp quyền chỉ đọc khi có thể, yêu cầu xác nhận của người cho thao tác phá hủy, và có bản sao lưu đã thử khôi phục. Đây là bài học của vụ Replit.
  6. Kiểm tra bằng cách hỏi lại. Hỏi trung lập thay vì dẫn dắt. Đảo câu hỏi ("tìm ba lỗi trong đoạn này" thay vì "đoạn này đúng không"). Hỏi hai lần ở hai phiên khác nhau và so sánh. Cho phép AI nói "không biết".
  7. Ghi tên người chịu trách nhiệm. Mỗi sản phẩm có AI tham gia vẫn cần một con người ký tên. Vụ Mata v. Avianca và Air Canada đều cho thấy trách nhiệm không chuyển sang AI.

Một mẫu prompt giúp giảm bịa đặt (không loại bỏ hoàn toàn):

Trả lời dựa trên tài liệu tôi cung cấp bên dưới.
Với mỗi ý, trích nguyên văn câu hỗ trợ trong dấu ngoặc kép.
Nếu tài liệu không đủ để kết luận, hãy nói "không đủ thông tin"
và nêu rõ cần thêm gì. Không dùng kiến thức bên ngoài.

10. Nhìn cân bằng#

Bài này không kêu gọi bỏ AI. Các mô hình cải thiện nhanh, tỷ lệ bịa đặt giảm qua từng thế hệ, và có rất nhiều việc AI làm tốt hơn và nhanh hơn người. Số liệu METR cũng chỉ là một ảnh chụp ở thời điểm đầu 2025 và có thể đã khác.

Điều không đổi là cấu trúc của vấn đề. Chừng nào mô hình còn sinh văn bản bằng xác suất, chừng đó sẽ có những lúc câu trả lời nghe đúng mà sai. Tỷ lệ có thể giảm, nhưng không có cơ chế nào bảo đảm bằng không. Cho nên kỹ năng khan hiếm không phải là biết hỏi AI, mà là biết kiểm chứng đủ nhanh và đủ rẻ để dùng AI một cách an toàn. Đây cũng là kết luận ở bài nghề dev qua các thời kỳ, nơi nút thắt của nghề đã dịch chuyển sang kiểm chứng.

11. Mười câu hỏi trước khi tin một câu trả lời của AI#

  1. Nếu câu này sai, ai chịu hậu quả và nặng đến đâu?
  2. Có cách rẻ để kiểm tra ngay không (chạy, tra, đối chiếu)?
  3. Câu trả lời có chứa số liệu, tên riêng, đường dẫn, trích dẫn mà tôi chưa tự mở không?
  4. Tôi đã hỏi trung lập hay đã gợi ý đáp án mong muốn?
  5. Đây là kiến thức phổ biến hay chi tiết hiếm, mới, hoặc nội bộ?
  6. Phần nào là tính toán và có thể giao cho công cụ thay vì hỏi bằng lời?
  7. Tôi có nhờ chính AI kiểm lại mình không? Có công cụ hay người khác kiểm không?
  8. Có phủ định, điều kiện, ngoại lệ hay thứ tự nào có thể đã bị làm rơi?
  9. Thao tác này có hoàn tác được không? Có bản sao lưu chưa?
  10. Ai sẽ ký tên chịu trách nhiệm cho kết quả cuối cùng?

12. Kết luận#

AI là một công cụ đoán chữ rất giỏi. Nó được xây để cho ra câu tiếp theo có vẻ đúng nhất, và nhờ đó viết, tóm tắt, dịch và lập trình tốt đến mức đáng kinh ngạc. Cũng chính cách hoạt động ấy có thể giải thích vì sao nó bịa án lệ, bịa chính sách, bịa thư viện, tính nhầm và giải thích sai cách nó tính.

Hiểu cơ chế giúp ta bớt hai thái cực: tin tuyệt đối vì câu trả lời quá trơn tru, hoặc phủ nhận hoàn toàn vì nó từng sai. Thay vào đó, hãy dùng AI như một đồng nghiệp rất nhanh và rất tự tin nhưng chưa từng bị phạt khi sai: giao việc, rồi kiểm tra theo mức hậu quả, và giữ trách nhiệm ở phía mình.

Nguồn tham khảo#

Số liệu lấy từ nguồn công khai tính đến tháng 10/2026. Một số con số được các báo thuật lại hơi khác nhau, nên hãy mở nguồn gốc để kiểm tra trước khi trích dẫn.