AI agent hiếm khi bị sập. Chúng thất bại âm thầm, và nghiên cứu lý giải vì sao

AI agent dùng mô hình ngôn ngữ lớn hiện trả lời yêu cầu hỗ trợ, truy vấn cơ sở dữ liệu và lên kế hoạch cho các chuyến đi. Khi gặp trục trặc, chúng thường đưa ra câu trả lời đầy tự tin cùng mã báo thành công. Ngày càng có nhiều nghiên cứu lý giải vì sao những thất bại này khó bị phát hiện, cũng như cách các nhóm kỹ thuật đang học cách đo lường chúng.

Một sự cố trông như thành công

Phần mềm truyền thống thường gặp sự cố một cách rõ ràng. Một hàm phát sinh ngoại lệ, máy chủ trả về mã lỗi và bảng điều khiển giám sát chuyển sang màu đỏ. AI agent hoạt động khác. Nó vận hành theo một vòng lặp: mô hình ngôn ngữ đọc lời nhắc, quyết định gọi một công cụ như API tìm kiếm hoặc cơ sở dữ liệu, đọc kết quả rồi quyết định bước tiếp theo. Bất kỳ bước nào cũng có thể gặp trục trặc trong khi mọi yêu cầu mạng trong chuỗi vẫn thành công.

Hãy xem một trường hợp thường gặp. Công cụ thời tiết gặp sự cố và trả về dòng chữ “dịch vụ không khả dụng” trong một phản hồi vốn bình thường. Mô hình đọc dòng chữ đó, rồi lịch sự xin lỗi hoặc, tệ hơn, đưa ra một dự báo nghe có vẻ hợp lý dựa trên dữ liệu huấn luyện. Người dùng nhận được câu trả lời trôi chảy. Nhật ký máy chủ cho thấy yêu cầu đã thành công, với độ trễ bình thường. Không có thông tin nào trong hệ thống giám sát thông thường ghi nhận sự cố.

Các nhà cung cấp mô hình cũng mô tả khoảng trống tương tự trong tài liệu của mình. Hướng dẫn về Gemini API của Google lưu ý rằng mô hình “không tự thực thi hàm”. Mô hình chỉ đề xuất tên hàm và các đối số; ứng dụng của nhà phát triển mới là nơi thực hiện lệnh gọi. Vì vậy, ứng dụng là thành phần duy nhất trong hệ thống nhìn thấy kết quả thực tế. Hướng dẫn kỹ thuật của Anthropic về xây dựng agent cũng nêu rằng ở mỗi bước, agent cần có “thông tin thực tế chuẩn xác” từ môi trường, chẳng hạn như kết quả từ công cụ, để đánh giá tiến độ của chính mình. Khi công cụ báo lỗi dưới dạng văn bản thông thường, thông tin thực tế đó không chính xác và agent không có cách nào nhận ra.

Đây không phải là một vấn đề mới, mà chỉ là phiên bản rõ nét hơn của một vấn đề cũ. Năm 2015, các kỹ sư Google do D. Sculley dẫn đầu đã mô tả “nợ kỹ thuật tiềm ẩn” trong các hệ thống học máy. Họ cho rằng phần lớn rủi ro trong một hệ thống học máy đưa vào vận hành nằm ngoài mã của mô hình, trong các phụ thuộc dữ liệu, cấu hình và mã kết nối. Agent bổ sung thêm một lớp mới vào danh sách đó. Lời nhắc và mô tả công cụ là những phần cấu hình có thể làm thay đổi hành vi của hệ thống mà không cần sửa mã.

Chỉnh sửa nhỏ, tác động lớn

Một thay đổi nhỏ trong lời nhắc có thể ảnh hưởng đến mức nào? Trong một bài báo được trình bày tại ICLR 2024, Melanie Sclar của University of Washington cùng các đồng nghiệp chỉ thay đổi cách định dạng lời nhắc few-shot: dấu phân cách, khoảng cách và cách viết hoa. Ý nghĩa vẫn giữ nguyên. Tuy nhiên, hiệu suất trên cùng một tác vụ vẫn dao động tới 76 điểm phần trăm về độ chính xác trên LLaMA-2-13B. Độ nhạy này không biến mất khi dùng mô hình lớn hơn, thêm ví dụ hoặc tinh chỉnh theo chỉ dẫn.

Các tác giả khuyến nghị báo cáo khoảng hiệu suất trên nhiều định dạng lời nhắc hợp lý, thay vì chỉ đưa ra một con số. Với các nhóm kỹ thuật, bài học thực tế đơn giản hơn: chỉnh sửa lời nhắc cũng là một thay đổi mã. Thay đổi đó cần có lịch sử phiên bản và phải được kiểm thử trước khi đến tay người dùng.

Điều tương tự cũng áp dụng cho mô tả công cụ, vì mô hình đọc chúng như một phần của lời nhắc. Hướng dẫn của Anthropic khuyến nghị dành cho định nghĩa công cụ “mức độ chú trọng kỹ thuật lời nhắc tương đương” với lời nhắc chính. Tài liệu mô tả một agent lập trình liên tục mắc lỗi với đường dẫn tệp tương đối. Sau khi công cụ được thay đổi để yêu cầu đường dẫn tuyệt đối, mô hình đã sử dụng công cụ mà không mắc lỗi. Mô hình không thay đổi; chỉ có phần mô tả mà nó đọc là khác đi.

Một lần thành công chưa nói lên nhiều điều

Một hướng nghiên cứu khác xem xét tính nhất quán. Bộ đánh giá chuẩn τ-bench, do Shunyu Yao và các đồng nghiệp tại Sierra công bố, được trình bày tại ICLR 2025. Bộ này mô phỏng các cuộc trò chuyện dịch vụ khách hàng, trong đó agent phải sử dụng công cụ và tuân thủ quy tắc kinh doanh. Các tác giả đưa ra một chỉ số có tên pass^k: xác suất agent giải quyết chính xác cùng một tác vụ trong cả k lần thử.

Kết quả đáng lo ngại. Một agent GPT-4o giải quyết thành công khoảng 61% tác vụ bán lẻ trong một lần thử. Khi phải hoàn thành cùng một tác vụ tám lần liên tiếp, tỷ lệ này giảm còn khoảng 25%. Một bản trình diễn hoạt động tốt một lần chẳng nói lên nhiều điều về cách hệ thống vận hành ở lần chạy thứ một nghìn.

Những điểm đứt gãy trong hệ thống đa agent

Hiện nay, nhiều nhóm kết nối nhiều agent thành chuỗi, trong đó một agent lập kế hoạch, agent khác thực thi và agent thứ ba kiểm tra kết quả. Một nghiên cứu năm 2025 của UC Berkeley, “Vì sao các hệ thống LLM đa agent thất bại?”, đã phân tích hơn 1.600 dấu vết thực thi được chú giải trên bảy khung đa agent phổ biến. Nhóm tác giả do Mert Cemri dẫn đầu đã xây dựng một hệ thống phân loại có tên MAST, gồm 14 dạng lỗi thuộc ba nhóm: vấn đề trong thiết kế hệ thống, sự thiếu đồng bộ giữa các agent và việc xác minh tác vụ.

Phát hiện trọng tâm của họ là nhiều sự cố bắt nguồn từ cách thiết kế hệ thống, chứ không chỉ từ những giới hạn của mô hình nền tảng. Agent phớt lờ vai trò được giao, mất dấu cuộc trò chuyện hoặc tuyên bố hoàn tất tác vụ mà không kiểm tra kết quả. Những lỗi này không để lại thông báo lỗi nào. Chỉ có thể nhận ra chúng nếu có người đọc được những gì từng agent thực sự đã làm. Bài viết của Unite.AI về nghịch lý đa agent cũng nêu một điểm liên quan ở góc độ kiến trúc: thêm agent có thể khuếch đại một lỗi ban đầu thay vì triệt tiêu nó.

Làm cho điều vô hình trở nên hữu hình

Phản ứng của giới kỹ thuật được kế thừa từ các hệ thống phân tán, nơi người ta từ lâu đã theo dõi yêu cầu qua nhiều dịch vụ bằng một kỹ thuật gọi là truy vết. Khi áp dụng cho các tác nhân AI, mỗi yêu cầu của người dùng trở thành một dấu vết, còn mỗi lần gọi mô hình hoặc công cụ trở thành một “span” bên trong dấu vết đó. Một span ghi lại dữ liệu đầu vào, đầu ra, số token đã sử dụng và thời gian xử lý. OpenTelemetry, tổ chức xây dựng tiêu chuẩn trong lĩnh vực này, đang soạn thảo các quy ước chung cho span trong AI tạo sinh. Tính đến năm 2026, các quy ước này vẫn được đánh dấu là đang trong quá trình phát triển, vì vậy tên thuộc tính vẫn có thể thay đổi.

Một số dự án mã nguồn mở như Langfuse, Arize Phoenix và AcruxCore đã áp dụng ý tưởng này. Mã nguồn của các dự án được công khai, nên các nhóm có thể kiểm tra cách lưu trữ một dấu vết và chạy phần mềm trên máy chủ của riêng mình. Các dự án này ghi lại những lần gọi mô hình và công cụ dưới dạng các span trong cùng một dấu vết, đồng thời cho phép các nhóm gắn điểm chất lượng vào đó. Việc chọn công cụ nào không quan trọng bằng một chi tiết: span của công cụ phải ghi lại chính xác những gì công cụ trả về, chứ không chỉ cho biết yêu cầu mạng có thành công hay không. Nếu thiếu thông tin đó, lỗi của công cụ thời tiết được mô tả ở trên sẽ vẫn không thể phát hiện.

Các khảo sát trong ngành cho thấy truy vết hiện đã phổ biến, nhưng việc kiểm thử vẫn chưa theo kịp. Báo cáo Hiện trạng kỹ thuật tác nhân AI của LangChain khảo sát 1.340 người làm trong lĩnh vực này vào cuối năm 2025. Chất lượng là rào cản được nhắc đến nhiều nhất khi đưa tác nhân AI vào sản xuất, với 32% số người trả lời nêu vấn đề này. Có 89% tổ chức cho biết họ áp dụng một hình thức giám sát khả năng quan sát nào đó cho các tác nhân AI, còn 62% theo dõi chi tiết từng bước và từng lần gọi công cụ. Chỉ 52,4% đánh giá ngoại tuyến trên các tập dữ liệu kiểm thử, còn 37,3% đánh giá lưu lượng trực tiếp. Hầu hết các nhóm đều có thể thấy tác nhân AI đã làm gì. Nhưng ít nhóm kiểm tra xem việc đó có đúng hay không.

Đánh giá câu trả lời trên quy mô lớn

Dấu vết cho thấy điều gì đã xảy ra. Nhưng chúng không cho biết câu trả lời có tốt hay không. Việc đọc thủ công từng cuộc hội thoại không thể mở rộng theo quy mô, vì vậy ngày càng nhiều nhóm dùng một mô hình thứ hai làm giám khảo; cách tiếp cận này được gọi là “LLM làm giám khảo”. Một bài báo tại NeurIPS 2023 của Lianmin Zheng và các đồng nghiệp cho thấy những mô hình mạnh như GPT-4 đồng thuận với lựa chọn của con người trong hơn 80% trường hợp, gần bằng tỷ lệ con người đồng thuận với nhau.

Bài báo đó cũng ghi nhận những điểm yếu của phương pháp này. Các mô hình giám khảo thiên về câu trả lời được trình bày trước, thích câu trả lời dài hơn và có thể ưu ái văn bản do chính chúng viết. Vì vậy, điểm số của mô hình giám khảo chỉ là ước tính. Chúng hữu ích khi cần đánh giá số lượng lớn, nhưng cần được đối chiếu với một tập nhỏ ví dụ do con người gán nhãn, trong đó thứ tự câu trả lời được xáo trộn.

Từ thực tiễn đến chính sách

Công tác đo lường này cũng đang trở thành một kỳ vọng về quản trị. Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ đã công bố Khung Quản lý Rủi ro AI vào tháng 1 năm 2023. Một trong bốn chức năng cốt lõi của khung, “Đo lường”, yêu cầu các tổ chức định lượng, theo dõi và ghi chép các rủi ro AI theo thời gian. Đối với một tác nhân AI, dấu vết và điểm đánh giá chính là những bằng chứng mà chức năng này yêu cầu.

Các nhóm có thể làm gì ngay lúc này

Điều này cũng nhắc lại lập luận từng được nêu trên nền tảng này rằng độ tin cậy mới là phép thử thực sự đối với AI có khả năng hành động. Nghiên cứu trên bổ sung chi tiết về cách đo lường cho lập luận đó: độ tin cậy không phải là thuộc tính có thể quan sát một lần, mà là một khoảng giá trị cần được đo lường liên tục.

Nghiên cứu gợi ra một số thói quen cần duy trì, và các nhà cung cấp mô hình lớn cũng khuyến nghị nhiều điều tương tự. Hướng dẫn thực tiễn của OpenAI về xây dựng tác nhân AI khuyên các nhóm “thiết lập quy trình đánh giá để xác định mức hiệu suất cơ sở” trước khi tối ưu hóa, đồng thời chuyển quyền kiểm soát cho con người khi tác nhân AI vượt quá số lần thử thất bại đã định hoặc gặp phải một hành động có rủi ro cao. Anthropic khuyến nghị “kiểm thử kỹ lưỡng trong môi trường hộp cát” trước khi để các tác nhân AI tự hành động.

Trên thực tế, điều đó có nghĩa là thực hiện một số bước cụ thể. Quản lý phiên bản lời nhắc và mô tả công cụ như mã nguồn. Kiểm thử từng thay đổi trong lời nhắc trên một tập dữ liệu cố định và dự kiến kết quả sẽ dao động trong một khoảng, thay vì chỉ có một con số duy nhất. Chạy mỗi trường hợp kiểm thử nhiều lần, vì một lượt chạy không thể cho thấy sự thiếu nhất quán. Ghi lại đầu ra của công cụ trong dấu vết để công cụ gặp lỗi không thể che giấu điều đó bằng một mã báo thành công. Hãy xem điểm số do mô hình tự động chấm chỉ là ước tính và đối chiếu chúng với đánh giá của con người.

Không thói quen nào trong số này đòi hỏi phải có bước đột phá về năng lực mô hình. Điều cần thiết là nhìn nhận tác nhân AI đúng như bản chất của nó: một hệ thống xác suất cần được đo lường, bởi nó hiếm khi tự báo rằng mình đã thất bại.