Thiết kế các tác nhân AI có khả năng tự điều chỉnh

Trong bài viết này, bạn sẽ tìm hiểu cách thiết kế các tác nhân AI (AI agents) có khả năng tự sửa lỗi một cách đáng tin cậy bằng cách neo các vòng phản hồi của chúng vào xác minh bên ngoài, thay vì dựa vào đánh giá của chính mô hình. Các chủ đề chúng ta sẽ đề cập bao gồm: Lý do tại sao việc tự sửa lỗi trong các mô hình ngôn ngữ chỉ hiệu quả khi tác nhân có một tín hiệu bên ngoài để kiểm tra, và khi nào thì không đáng để chi phí. Cách xây dựng một tác nhân tạo mã với một trình xác minh dựa trên thử nghiệm thực tế, một vòng lặp thử lại có giới hạn và một lộ trình leo thang có cấu trúc. Cách thêm một cổng tin cậy dựa trên tính nhất quán để tạo ra một giải pháp thứ hai độc lập nhằm xác nhận tính đúng đắn trước khi triển khai. Giới thiệu Năm 2024, một nhóm các nhà nghiên cứu đã công bố một bài báo với tiêu đề thẳng thắn: "Các mô hình ngôn ngữ lớn chưa thể tự sửa lỗi suy luận." Phát hiện của họ gây khó chịu cho bất kỳ ai đang xây dựng các tác nhân vào thời điểm đó. Khi bạn yêu cầu một mô hình kiểm tra lý luận của chính nó mà không có đầu vào bên ngoài, nó không đáng tin cậy trong việc phát hiện lỗi của mình. Đôi khi nó làm điều ngược lại: nó tự thuyết phục mình rằng một câu trả lời sai là đúng, và phiên bản "đã sửa" lại tệ hơn bản nháp đầu tiên, một mô hình mà các nghiên cứu sau này đã xác nhận và phát triển. Phát hiện đó là trọng tâm của mọi thứ trong bài viết này. Tự sửa lỗi trong các tác nhân AI là có thật; nó không phải là một mánh khóe hay một thuật ngữ tiếp thị, nhưng nó chỉ hoạt động trong một điều kiện cụ thể: tác nhân cần một thứ gì đó bên ngoài ý kiến của chính nó để kiểm tra. Cung cấp điều đó, và vòng lặp sẽ phát hiện ra những lỗi thực sự. Bỏ qua điều đó, và bạn đã xây dựng một cách phức tạp để mô hình tự đồng ý với chính nó. Hướng dẫn này xây dựng một ví dụ hoàn chỉnh để điều kiện luôn cụ thể thay vì trừu tượng: một tác nhân tạo mã viết một hàm Python, thực sự chạy các thử nghiệm của hàm, sửa những gì thất bại và biết khi nào nên ngừng cố gắng và chuyển vấn đề cho một người. Điều kiện tiên quyết: Python 3.10 trở lên Một khóa API (Anthropic API key) pip install langgraph langchain-anthropic pytest python-dotenv Tại sao việc yêu cầu một mô hình tự kiểm tra công việc của nó thường thất bại Hãy hình dung việc yêu cầu một học sinh tự chấm điểm bài kiểm tra của mình mà không có đáp án. Họ sẽ sửa những lỗi mà họ nhận thấy, nhưng những lỗi mà họ không nhận thấy chính là những lỗi mà họ sẽ chấp thuận lại khi xem xét lần thứ hai. Đó là cái bẫy nhất quán: sự phê bình của một mô hình ngôn ngữ đối với đầu ra của chính nó được tạo ra bởi cùng một trọng số, được huấn luyện trên cùng một mẫu, đã tạo ra đầu ra ngay từ đầu. Đó không phải là một kiểm tra độc lập. Đó là cùng một phán đoán được hỏi hai lần, và hai câu trả lời có xu hướng đồng ý, bất kể cả hai có đúng hay không. Điều này không có nghĩa là phản hồi (reflection) là vô giá trị; mà là phản hồi chỉ hiệu quả khi nó dựa trên một yếu tố mà bộ tạo (generator) không tạo ra. Bài báo gốc về Reflexion của Stanford đã chỉ ra rằng các tác nhân (agent) có khả năng tự phản hồi bằng lời nói đạt 91% pass@1 trên HumanEval, tăng từ mức cơ sở 80%, và đạt mức tăng tuyệt đối 20 điểm trên HotpotQA về trả lời câu hỏi so với tác nhân ReAct tiêu chuẩn. Bài báo Self-Refine của Madaan và cộng sự đã tìm thấy mức cải thiện trung bình tương tự 20% trên bảy nhiệm vụ khác nhau. Đó là những lợi ích thực sự, và điểm chung của chúng là các nhiệm vụ đã cung cấp cho mô hình một thứ để kiểm tra: mã (code) có các bài kiểm tra (test) có thể thành công hoặc thất bại, và truy xuất nhiều bước có các tài liệu có thể trả lời câu hỏi hoặc không. Phản hồi không còn hiệu quả đối với các nhiệm vụ đơn giản hơn mà không có yếu tố bên ngoài nào để kiểm tra. Nghiên cứu CorrectBench năm 2025 cho thấy tự sửa lỗi (self-correction) bổ sung khoảng 5% trên các điểm chuẩn suy luận khó như MATH, nhưng trên các nhiệm vụ dễ, suy luận chuỗi tư duy (chain-of-thought reasoning) đơn thuần cũng hiệu quả tương đương với việc sử dụng ít hơn 40% tài nguyên tính toán. Phản hồi không miễn phí. Nó tốn token, độ trễ và tiền mỗi khi vòng lặp chạy, vì vậy câu hỏi đáng đặt ra trước khi xây dựng một hệ thống không phải là "phản hồi có giúp ích không," mà là "tôi có yếu tố bên ngoài nào để bộ phê bình (critic) kiểm tra không, và nhiệm vụ có đủ khó để biện minh cho các lệnh gọi bổ sung không?" Đó là quy tắc mà phần còn lại của bài viết này tuân theo: đặt bộ phê bình dựa trên một yếu tố mà bộ tạo không viết. Đối với mã, đó là chạy các bài kiểm tra. Đối với nghiên cứu, đó là một nguồn đã được truy xuất. Đối với một tác nhân điền biểu mẫu, đó là xác thực lược đồ (schema validation). Dù dự án của bạn là gì, hãy tìm tín hiệu bên ngoài đó trước khi bạn viết một dòng logic sửa lỗi nào, bởi vì nếu không có nó, bạn đang xây dựng một phiên bản đắt tiền hơn của cùng một sai lầm. Các khối xây dựng, trước khi bạn viết bất kỳ mã nào Năm thành phần xuất hiện trong hầu hết các hệ thống tự sửa lỗi trong sản xuất, và điều đáng biết là mỗi thành phần thực sự dùng để làm gì trước khi kết nối chúng lại với nhau. Vòng lặp phản hồi (reflection loops) là chu trình tạo-phê bình-sửa đổi. Vòng lặp chỉ hoạt động nếu nó bị giới hạn. Một vòng lặp phản hồi không giới hạn không phải là một tính năng an toàn; nó là một trách nhiệm pháp lý, và một bài phân tích sau sự cố được chia sẻ rộng rãi vào năm 2026 đã mô tả một tác nhân xử lý tài liệu đã đi vào một vòng lặp thử lại qua đêm và gây ra hóa đơn 437 USD trong tám giờ trước khi có ai nhận ra. Mọi vòng lặp trong bài viết này đều có một giới hạn cứng. Bộ xác minh (verifiers) kiểm tra đầu ra của bộ tạo. Sự khác biệt quan trọng là giữa bộ xác minh và mô hình hiệu chuẩn (calibration model): bộ xác minh đánh giá chất lượng đầu ra theo cách độc lập với mô hình nào đã tạo ra nó, trong khi mô hình hiệu chuẩn ước tính mức độ tự tin mà mô hình tạo cụ thể nên có trong đầu ra của chính nó, đây là một tín hiệu khác biệt tinh tế và yếu hơn, như một bài báo năm 2025 về ước tính độ tin cậy chi tiết đã trình bày. Trong sản xuất, các bộ xác minh mạnh nhất và rẻ nhất thường là đơn giản nhất: chạy mã, kiểm tra lược đồ, truy vấn cơ sở dữ liệu. Hãy dành các mô hình phần thưởng quy trình được đào tạo, vốn đánh giá các bước suy luận trung gian thay vì chỉ câu trả lời cuối cùng, cho các trường hợp mà