AI không phải công cụ vạn năng: bắt được một con ve không có nghĩa bạn có cả mùa hè

Một model AI viết được một đoạn code phức tạp, hay trả lời đúng một câu hỏi chuyên môn khó, rất dễ tạo ra một kết luận nhảy vọt: 'AI đã đủ giỏi để tự động hóa cả quy trình này.' Đây chính xác là cái bẫy mà câu tục ngữ 'bắt được con ve không có nghĩa bạn có cả mùa hè' mô tả — một thành công hẹp, cụ thể, bị hiểu nhầm thành năng lực tổng quát trên toàn bộ phạm vi bài toán. Vấn đề không phải AI 'giả vờ' thông minh — mà là năng lực thật của nó phân bố không đồng đều theo cách con người khó đoán trước bằng trực giác, và khoảng cách đó đã gây ra sự cố thật trong production năm 2026.

Nghiên cứu 'Jagged Frontier': AI giỏi ở đâu và tệ ở đâu không theo trực giác con người

Năm 2025-2026, một nhóm nghiên cứu từ Harvard Business School và Boston Consulting Group (Dell'Acqua và cộng sự, công bố trên Organization Science, tóm tắt tại Harvard Business School AI Institute) đã chạy một thí nghiệm ngẫu nhiên có tiền đăng ký (preregistered) trên 758 chuyên gia tư vấn quản lý, chia làm ba nhóm: không dùng AI, dùng GPT-4, và dùng GPT-4 kèm hướng dẫn prompt engineering. Với các tác vụ nằm trong 'biên năng lực' của GPT-4, nhóm dùng AI hoàn thành nhiều hơn 12.2%, chất lượng cao hơn hơn 30%, và nhanh hơn khoảng 25%. Nhưng với một tác vụ quản lý phức tạp được thiết kế nằm ngoài biên năng lực của GPT-4, việc dùng AI làm giảm độ chính xác tới 19 điểm phần trăm — nghĩa là dùng AI cho đúng loại tác vụ này khiến kết quả tệ hơn cả không dùng AI.

Điểm quan trọng nhất của nghiên cứu không nằm ở hai con số đó, mà ở tính chất 'lởm chởm' (jagged) của đường biên năng lực: nếu năng lực AI tạo thành một dốc trơn tru theo độ khó, con người có thể xây một mô hình tâm lý đơn giản ('việc khó thì AI kém, việc dễ thì AI giỏi') và áp dụng nhất quán. Nhưng biên năng lực thực tế lồi lõm không theo cách con người cảm nhận độ khó — một tác vụ con người thấy dễ có thể nằm ngoài biên AI, và một tác vụ con người thấy khó có thể nằm sâu trong biên AI. Không có shortcut trực giác nào đáng tin cậy để đoán trước ranh giới này.

Ngay trong một model, năng lực cũng không đồng đều

Sự lởm chởm này không chỉ xảy ra giữa 'có AI' và 'không có AI' — nó xảy ra ngay trong năng lực của một model duy nhất. Trong bài viết về GLM-5.2 của Z.ai, chúng tôi đã trích dẫn: cùng một model đạt 62.1 điểm trên SWE-bench Pro (coding agent dài hơi) nhưng chỉ 40.5 điểm trên HLE (Humanity's Last Exam — bộ câu hỏi kiến thức tổng quát khó). Đây không phải mâu thuẫn hay lỗi benchmark — đó chính xác là jagged frontier thể hiện trong một model: giỏi vượt trội ở một trục năng lực (coding agentic) không đảm bảo giỏi tương đương ở trục khác (kiến thức tổng quát chuyên sâu). 'Model tốt' luôn là một phát biểu cần gắn với một tác vụ cụ thể, không phải một điểm số tổng quát duy nhất.

Khi 'bắt được con ve' trở thành sự cố thật

Khoảng cách giữa năng lực trong demo và độ tin cậy trong production không phải lý thuyết suông. Trong vụ Moffatt v. Air Canada, 2024 BCCRT 149, chatbot hỗ trợ khách hàng trên website Air Canada trả lời tốt phần lớn câu hỏi thông thường — nhưng khi một khách hàng hỏi về việc xin hoàn tiền giá vé tang lễ sau khi đã bay, chatbot tự tin khẳng định anh có thể nộp đơn hoàn tiền trong vòng 90 ngày, trái với chính sách thật của hãng. Tòa án dân sự British Columbia bác bỏ lập luận của Air Canada rằng 'chatbot là một thực thể riêng biệt', buộc hãng bồi thường vì misrepresentation — một minh chứng cụ thể rằng một hệ thống hoạt động tốt ở phần lớn tác vụ vẫn có thể tự tin đưa ra thông tin sai ở đúng góc cạnh nằm ngoài biên năng lực của nó, và hậu quả không chỉ dừng ở một câu trả lời tệ. Ở quy mô rộng hơn, RAND Corporation ghi nhận hơn 80% dự án AI thất bại đạt được giá trị kỳ vọng, và MIT Project NANDA ghi nhận khoảng 95% pilot generative AI không mang lại ROI đo lường được. Theo Báo cáo AI Index 2026 của Stanford HAI, số sự cố AI được ghi nhận đã tăng từ 233 (2024) lên 362 (2025). Nguyên nhân gốc phổ biến nhất trong các báo cáo này không phải 'AI xây dở' — mà là triển khai mà không hiểu rõ khoảng cách giữa năng lực-đã-chứng-minh-trong-demo và độ-tin-cậy-cần-có-trong-production.

Vì sao cái bẫy này dễ mắc phải đến vậy

Một demo thành công tạo cảm giác 'bài toán đã được giải quyết' — nhưng demo gần như luôn chạy trên input được chọn lọc, tải thấp, và không có edge case bất thường. Con ve bắt được trong demo là thật, nhưng nó không đại diện cho toàn bộ 'mùa hè' của các tình huống production thực tế: input sai định dạng, tải đột biến, mất kết nối giữa chừng, hay một phân phối dữ liệu khác với tập test. Khoảng cách này càng nguy hiểm hơn vì AI thường trả lời với vẻ tự tin như nhau bất kể nó đang ở trong hay ngoài biên năng lực — không có tín hiệu cảnh báo tự nhiên nào báo cho người dùng biết 'câu trả lời này nằm ngoài vùng tôi đáng tin cậy'.

Cách tránh: thiết kế cho sự lởm chởm, không phải giả vờ nó không tồn tại

Phản ứng sai lầm phổ biến là chọn một trong hai thái cực: tin tưởng AI cho mọi việc, hoặc từ chối dùng AI hoàn toàn. Cách tiếp cận đúng là thiết kế hệ thống thừa nhận biên năng lực lởm chởm ngay từ đầu:

• **Router định tuyến theo tác vụ, không theo giả định 'một model làm được mọi thứ'** — đúng nguyên tắc Router trong KonexForge AI Core: mỗi loại tác vụ được định tuyến đến đúng model/tier dựa trên năng lực đã đo, không phải năng lực được suy luận từ một demo hay một benchmark chung
• **Critic Engine đánh giá trước khi output ảnh hưởng đến quyết định thật** — không tin tưởng mù quáng ở những tác vụ gần rìa năng lực chưa được kiểm chứng kỹ, tương tự nguyên tắc chúng tôi đề cập khi bàn về kiểm soát chất lượng nội dung AI
• **Giám sát liên tục vì biên năng lực có thể dịch chuyển theo thời gian** — một model hoạt động tốt lúc go-live có thể suy giảm khi phân phối dữ liệu thay đổi, đúng cơ chế data drift và concept drift đã phân tích trong bài monitoring drift cho model AI production — biên năng lực không phải một đường cố định vẽ một lần rồi thôi
• **Chọn use case theo năng lực thật đã đo, không theo kỳ vọng chung chung** — nguyên tắc tương tự khi chúng tôi bàn về tiêu chí chọn use case cho Qwen3-VL trong production: một Vision-Language Model mạnh ở OCR không tự động mạnh ở visual inspection chi tiết cao — mỗi use case cần được kiểm chứng riêng

Kết luận

AI không phải công cụ vạn năng, và một thành công cụ thể — một demo ấn tượng, một điểm benchmark cao, một use case chạy tốt — không phải bằng chứng cho năng lực tổng quát trên mọi tác vụ liên quan. Bắt được một con ve chứng minh mùa hè đã đến, nhưng không chứng minh bạn đã nắm được cả mùa hè. Cách xử lý đúng không phải tin tưởng tuyệt đối hay từ chối hoàn toàn, mà là thiết kế hệ thống thừa nhận biên năng lực lởm chởm: đo năng lực theo từng tác vụ cụ thể, định tuyến đúng, kiểm định trước khi output ảnh hưởng quyết định thật, và giám sát liên tục vì biên đó dịch chuyển theo thời gian. Đây là cách tiếp cận chúng tôi áp dụng khi xây dựng năng lực AI & ML cho khách hàng — liên hệ nếu bạn cần đánh giá lại xem một thành công AI cụ thể có thực sự tổng quát hóa được cho hệ thống của mình hay không.