Cách bắt lỗi khi AI bịa chuyện
AI nói ra những điều sai bằng giọng đầy tự tin. Bạn không ngăn được điều đó, nhưng bạn có thể chạy một quy trình ngắn, lặp lại được, để bắt phần lớn lỗi trước khi công việc rời khỏi bàn của bạn. Đây là phương pháp, và nơi nó dừng lại.
Trên trang này
Ai làm việc với AI cũng từng ít nhất một lần gặp chuyện này. Bạn đặt một câu hỏi, câu trả lời trở lại gọn gàng, được trình bày chỉn chu, bạn dán nó vào một tài liệu, và một ngày sau có người chỉ ra rằng một trong những dữ kiện trong đó là bịa đặt. Mô hình không nói dối. Nó không có khái niệm về đúng, cũng không có khái niệm về sai. Nó tạo ra những từ có khả năng xuất hiện kế tiếp cao nhất, mà những từ “có khả năng” lại sai nhiều hơn vẻ ngoài của chúng.
Bạn sẽ không huấn luyện để loại bỏ thói quen đó khỏi công cụ, nên việc của bạn là tự bắt lấy nó. Trong những đội nhóm chúng tôi đồng hành, những người lấy được kết quả đáng tin từ AI hiếm khi là người có công cụ tốt nhất. Họ là những người chạy một phương pháp trong khi mọi người khác làm tùy hứng. Đây là phương pháp chúng tôi thiết lập đầu tiên. Bốn thói quen, và một giới hạn trung thực.
Vì sao một câu trả lời sai lại nghe có vẻ đúng
Về cơ bản, một mô hình ngôn ngữ không tra cứu bất cứ điều gì. Những công cụ gắn thêm tìm kiếm web hay truy xuất tài liệu thay đổi phạm vi nó tiếp cận được, nhưng bản thân mô hình vẫn hoạt động theo cùng một cách. Nó tạo văn bản từng token một, mỗi token là phần tiếp nối có khả năng cao nhất của những gì đứng trước, và không có gì trong quá trình đó kiểm tra xem kết quả có đúng hay không. Khi các mẫu hình khớp với thực tế, bạn có câu trả lời đúng. Những lúc còn lại, bạn nhận một điều bịa đặt, được nói ra trong cùng một giọng điềm tĩnh.
Thường thì không có dấu hiệu đáng tin nào lộ ra trong câu chữ. Một câu tự tin về một quy định có thật và một câu tự tin về một quy định không tồn tại thường trông giống hệt nhau trên trang giấy. Vậy nên chỉ “đọc kỹ” thôi thì thất bại với tư cách một chiến lược. Bạn cần một quy trình hoạt động được ngay cả khi lỗi là vô hình.
Hãy là người am hiểu nhất trong phòng
Thói quen đầu tiên không tốn gì. Hãy hướng AI vào công việc mà bạn đã có thể tự đánh giá. Ethan Mollick nói thẳng trong Using AI Right Now: hãy dùng AI cho những chủ đề bạn hiểu cho đến khi bạn cảm nhận được năng lực và các kiểu lỗi của nó. Khi bạn nắm rõ địa hình, bạn nhận ra cái tên đường bịa đặt. Khi không, bạn đã trao quyền phán đoán của mình cho một hệ thống vốn không có khả năng đó.
Nó cũng thay đổi cách bạn làm việc với nó. Những người tận dụng AI tốt nhất coi nó như một cuộc trao đổi qua lại. Họ thúc ép, họ chất vấn câu trả lời đầu tiên, họ hỏi lý lẽ đằng sau nó. Phần lớn mọi người làm ngược lại. Một câu hỏi, không bối cảnh, thiết lập mặc định, và lấy bất cứ thứ gì hiện ra đầu tiên. Nước đi đáng tin cậy là tra hỏi bản nháp thay vì trích dẫn nó.
Đặt nền tảng cho mọi khẳng định
Sự am hiểu cho bạn biết khi nào cần nghi ngờ. Việc đặt nền tảng làm cho mô hình có ít chỗ để bịa đặt hơn ngay từ đầu. Điều đáng tin cậy nhất bạn có thể làm là ngăn nó trả lời từ trí nhớ và buộc nó trả lời từ những nguồn bạn trao cho nó. Một bài tổng quan về các phương pháp kiểm chứng dữ kiện trong tài liệu nghiên cứu (Rahman và cộng sự, 2025) cũng đi đến cùng kết luận: đặt kết quả trên các nguồn bên ngoài có thể kiểm chứng là cách hàng đầu để giảm sai sót về dữ kiện. Hướng dẫn của Anthropic về giảm ảo giác biến điều đó thành bốn bước bạn có thể tự làm bằng tay.
Cho phép mô hình nói “tôi không biết”
Hãy cho mô hình quyền rõ ràng để thừa nhận sự không chắc chắn. Nó có tác dụng hơn vẻ ngoài. Một mô hình chịu áp lực ngầm phải đưa ra câu trả lời sẽ đưa ra một câu, bất kể nó có cơ sở hay không. Hãy nói với nó rằng “tôi không có đủ thông tin để trả lời” là một phản hồi chấp nhận được, và phần lớn những điều vô nghĩa đầy tự tin sẽ biến mất.
Trích dẫn trước, trả lời sau
Với một tài liệu dài, hãy yêu cầu các đoạn chính xác trước, đúng từng chữ, và để mô hình chỉ trả lời từ những trích dẫn đó. Việc rút ra bằng chứng trước khi viết kết luận neo câu trả lời vào chính văn bản, thay vì vào một bản diễn giải mà mô hình chỉ nhớ mang máng.
Dẫn nguồn cho mọi khẳng định, loại bỏ phần còn lại
Thói quen này làm được nhiều việc nhất. Khi đã có bản nháp, hãy để mô hình tìm một trích dẫn hỗ trợ cho mọi khẳng định nó đưa ra, rồi bỏ đi bất kỳ khẳng định nào nó không thể chứng minh. Ví dụ của Anthropic đánh dấu mỗi khẳng định bị loại bằng cặp ngoặc rỗng, để bạn thấy rõ chỗ nào bản nháp đang chạy bằng sự tự tin chứ không phải bằng bằng chứng.
Giới hạn trong nguồn bạn cung cấp
Hãy bảo mô hình chỉ dùng những tài liệu bạn cung cấp và để kiến thức chung của nó sang một bên. Điều này giữ một ranh giới rõ ràng giữa điều bản tóm tắt thực sự nói và điều mô hình tự cho rằng nó biết, và đó chính là ranh giới mà những điều bịa đặt vượt qua.
Tam giác hóa, đừng lấy câu trả lời đầu tiên
Kết quả từ một hệ thống xác suất không ổn định, và bạn có thể tận dụng điều đó. Hãy chạy cùng một câu lệnh vài lần và so sánh. Ở chỗ các câu trả lời trùng khớp, bạn có một tín hiệu hợp lý, nhưng không phải bằng chứng. Một mô hình có thể lặp lại cùng một điều bịa đặt ở mọi lần chạy, vì câu trả lời sai đó vốn là câu có khả năng xuất hiện cao nhất ngay từ đầu. Ở chỗ các câu trả lời khác nhau, bạn đã tìm ra một điểm yếu đáng kiểm tra bằng tay.
Nghiên cứu ủng hộ trực giác này, trong một bối cảnh hẹp hơn bạn có thể tưởng. Khi một câu hỏi có một đáp án duy nhất kiểm tra được, việc lấy mẫu nhiều luồng suy luận độc lập và giữ lại kết quả đa số giúp cải thiện độ chính xác một cách đo lường được. Trong một nghiên cứu có kiểm soát, cách làm đó nâng kết quả trên một bộ kiểm thử toán tiểu học lên 17,9 điểm (Wang và cộng sự, 2023). Thí nghiệm đó hiệu quả vì mỗi câu trả lời là một con số kiểm tra được duy nhất, nên so sánh các bản nháp văn xuôi là một phiên bản lỏng lẻo hơn của cùng ý tưởng chứ không phải một thứ giống hệt. Hãy xem sự trùng khớp giữa các lần chạy như một sự ủng hộ cho thói quen này, không phải một bảo đảm, và xem sự khác biệt như một dấu hiệu đáng truy theo.
Bạn cũng có thể yêu cầu mô hình tự phê bình bản nháp của nó dựa trên các nguồn, và nó sẽ bắt được một số lỗi của chính mình. Đừng cho nó tiếng nói cuối cùng. Một mô hình tự chấm bài của mình thường có xu hướng dễ dãi với nó, nên lần kiểm tra cuối nên đến từ bên ngoài mô hình, dù là một phiên làm việc mới, chính tài liệu nguồn, hay một người khác.
Sửa câu lệnh, không sửa kết quả
Khi bắt được một kết quả tồi, nước đi hấp dẫn là sửa riêng sản phẩm đó bằng tay. Hãy cưỡng lại. Kết quả là thứ dùng một lần. Câu lệnh mới là thứ bạn chạy lại, nên câu lệnh là nơi một bản sửa thật sự mang lại lợi ích. Hãy sửa lỗi tận gốc và mọi lần chạy về sau đều thừa hưởng bản sửa đó.
Simon Willison vạch ra một ranh giới sắc bén trong Hallucinations in code are the least dangerous form of LLM mistakes. Với mã nguồn, bạn được kiểm chứng dữ kiện miễn phí. Chạy nó, và một hàm bịa đặt sẽ báo lỗi ngay lập tức. Văn xuôi không có lưới an toàn như vậy. Như ông nói, với văn xuôi thông thường “bạn cần một con mắt phê phán, trực giác mạnh và kỹ năng kiểm chứng dữ kiện được rèn giũa tốt.” Công việc của bạn càng xa khỏi thứ mà máy móc có thể kiểm tra giúp bạn, nó càng dựa vào chính phương pháp của bạn.
Giới hạn duy nhất, nói thẳng
Lưu ý đó mới là phần trung thực, và đó là lý do không điều nào ở đây hiệu quả như một mẹo làm một lần. Nó chỉ mang lại kết quả khi trở thành một thói quen bền bỉ, lặp đi lặp lại. Đặt nền tảng, dẫn nguồn, so sánh, và sửa câu lệnh thay vì sửa kết quả là những kỷ luật nhỏ khi đứng riêng. Được thực hành mỗi lần, chúng là thứ làm cho AI đủ đáng tin cậy để xây dựng công việc thật trên đó.
Điều này có ích dù bạn làm việc một mình hay trong một đội nhóm. Khi làm một mình, nó là thứ tách biệt kết quả bạn hy vọng là đúng khỏi kết quả bạn đã thực sự kiểm tra. Trong một đội nhóm, chính thói quen đó khi được viết ra và chia sẻ sẽ thôi là một bí quyết mà vài người cẩn thận nắm giữ và trở thành thứ mà mọi người áp dụng theo cùng một cách. Đó là nơi rủi ro lớn hơn được xử lý, phần công việc lẽ ra sẽ được phát hành mà không ai kiểm tra.
Thiết lập chuẩn mực đó, cùng sự phán đoán để biết phần việc nào cần mức kiểm tra nào, là công việc chúng tôi làm cùng những cá nhân và đội nhóm mà chúng tôi đồng hành. Nếu đó là khoảng cách bạn đang lấp đầy, hãy xem cách chúng tôi đồng hành cùng đội nhóm hoặc cùng bạn.
Nguồn
- Wang, X., Wei, J., Schuurmans, D., Le, Q., Chi, E., Narang, S., Chowdhery, A., & Zhou, D. (2023). Self-Consistency Improves Chain of Thought Reasoning in Language Models. ICLR 2023. arxiv.org/abs/2203.11171
- Rahman, S. S., Islam, M. A., et al. (2025). Hallucination to Truth: A Review of Fact-Checking and Factuality Evaluation in Large Language Models. Artificial Intelligence Review (Springer). arxiv.org/abs/2508.03860
- Mollick, E. (2025, June 23). Using AI Right Now: A Quick Guide. One Useful Thing. oneusefulthing.org
- Anthropic. Reduce hallucinations. Tài liệu Claude. platform.claude.com
- Willison, S. (2025, March 2). Hallucinations in code are the least dangerous form of LLM mistakes. simonwillison.net
Michael Linhardt
CEO & Đồng sáng lập
Đồng sáng lập kiêm CEO. Cựu IT Leader tại Decathlon Việt Nam, cựu sinh viên 42 Paris. Viết về ứng dụng AI trong các đội nhóm B2B thực tế.
LinkedInBài viết liên quan
Triển khai AI cần nhiều hơn vài người tiên phong
Một vài người đạt kết quả tốt với AI không giống với một đội nhóm làm được điều đó. Biến những thắng lợi rời rạc thành một thực hành chung, đáng tin cậy là thứ bạn thiết kế, chứ không phải thứ một công cụ trao sẵn. Đây là công việc đó trông ra sao, và một điều duy nhất nó không thể hứa hẹn.