Các tác nhân AI phục hồi một cách đáng kể khi bạn cho phép chúng một cách rõ ràng được chạy lại các công cụ của mình – tác giả đã phát hiện ra điều này – một thay đổi nhỏ trong cách diễn đạt đã nâng tỷ lệ sửa lỗi thành công từ 0,16 lên 1,00. Kết quả này, được gọi là “cấp phép hành động” (action-licensing), cho thấy việc thúc đẩy một tác nhân kiểm tra lại công việc của chính nó có thể hiệu quả hơn nhiều so với việc chỉ đơn thuần nhắc lại mục tiêu.
Tại sao giải pháp này lại quan trọng
Các trợ lý AI có khả năng gọi các công cụ bên ngoài (cơ sở dữ liệu, máy tính, API) đang ngày càng được sử dụng nhiều trong các quy trình công việc kinh doanh. Khi các tác nhân đó mắc lỗi, lỗi thường lan truyền một cách âm thầm, tạo ra các câu trả lời sai mà không có các tín hiệu thất bại rõ ràng. Một cách đáng tin cậy để can thiệp mà không cần viết lại toàn bộ câu lệnh (prompt) có thể giúp các nhà phát triển tiết kiệm thời gian và ngăn ngừa những sai lầm tốn kém trong các hệ thống thực tế.
Các lỗi thường xuất hiện như thế nào
Tác giả đã quan sát thấy hai mô hình lỗi phổ biến, khó nhận biết:
Bỏ qua tra cứu (Skipped Lookup) – Tác nhân biết rằng nó nên truy xuất một mẩu thông tin (ví dụ: tên của quản lý từ một ID) nhưng thay vào đó lại tự bịa ra một câu trả lời thay vì gọi công cụ tra cứu. Câu trả lời ở bề mặt trông có vẻ hợp lý, nhưng cơ sở thực tế lại bị thiếu.
Xác nhận sự vô lý (Validated Nonsense) – Tác nhân đưa dữ liệu sai định dạng hoặc không chính xác vào một công cụ. Công cụ trả về một kết quả mà không báo lỗi, và tác nhân coi kết quả đó là sự xác nhận, về cơ bản là tự chấp nhận sai lầm của chính mình.
Cả hai mô hình này đều để lại cho người dùng một câu trả lời đầy tự tin nhưng sai lệch, và chúng không kích hoạt các dấu hiệu thông thường của một vòng lặp hoặc một phản hồi bị thiếu mà các nhà phát triển thường theo dõi.
Thí nghiệm
Để đo lường các câu lệnh khác nhau ảnh hưởng đến việc sửa lỗi như thế nào, tác giả đã thiết lập một thử nghiệm có kiểm soát với các câu trả lời thực tế chuẩn xác (không sử dụng chấm điểm dựa trên LLM). Hai cách thúc đẩy đã được so sánh:
Thúc đẩy chỉ có mục tiêu (Goal-only nudge) – “Câu trả lời phải là tên của quản lý.” Tỷ lệ phục hồi: 0,16.
Thúc đẩy cấp phép hành động (Action-licensing nudge) – “Câu trả lời phải là tên của quản lý. Hãy sử dụng các công cụ để xác minh.” Tỷ lệ phục hồi: 1,00 (tất cả các lần chạy thất bại đều được khắc phục).
Sự khác biệt duy nhất là quyền cho phép rõ ràng được thực thi lại một công cụ. Câu lệnh thứ hai cho tác nhân biết rằng nó có thể quay lại, lấy dữ liệu còn thiếu và ghi đè lên dự đoán trước đó của mình. Sự cho phép đó đã biến một cách thúc đẩy hầu như không hiệu quả thành một giải pháp khắc phục chắc chắn cho các trường hợp được thử nghiệm.
Ý nghĩa của các con số
Sự nhảy vọt từ 0,16 lên 1,00 cho thấy rào cản đối với việc sửa lỗi không phải là sự hiểu biết của tác nhân về mục tiêu, mà là quyền tự do hành động mà nó cảm nhận được. Khi câu lệnh bảo mô hình “bạn có thể thử lại”, nó sẽ coi tình huống đó như một nhiệm vụ phụ mới thay vì một ngõ cụt, cho phép chuỗi gọi công cụ được khởi động lại.
Giới hạn của các giải pháp chỉ bằng câu lệnh
Thí nghiệm cũng làm nổi bật các kịch bản mà chỉ riêng việc dùng câu lệnh không thể cứu vãn được tác nhân:
Nếu một công cụ hạ nguồn âm thầm chấp nhận đầu vào lỗi và trả về một giá trị, tác nhân sẽ không có tín hiệu nào cho thấy dữ liệu của nó bị sai. Không có việc diễn đạt lại bao nhiêu cũng sẽ giúp nó phát hiện ra lỗi; bản thân công cụ phải thực hiện kiểm tra tính hợp lệ của đầu vào hoặc báo lỗi.
Các tác nhân gặp khó khăn trong việc gọi công cụ ngay từ đầu sẽ không bao giờ được hưởng lợi từ hướng dẫn “sử dụng công cụ”, bởi vì khả năng cơ bản đó không tồn tại. Việc kiểm tra khả năng sửa lỗi trên các mô hình như vậy sẽ làm lẫn lộn giữa việc đánh giá câu lệnh với khả năng gọi công cụ cơ bản của mô hình.
Những bài học thực tế cho các nhà phát triển
Cấp quyền (Grant permission) – Khi bạn can thiệp, hãy nói rõ với tác nhân rằng nó có thể lặp lại một lần gọi công cụ hoặc tính toán lại. Việc chỉ đơn thuần nhắc lại kết quả mong muốn thường khiến tác nhân bị mắc kẹt trong lộ trình sai lầm ban đầu của nó.
Bảo vệ các công cụ (Guard the tools) – Xây dựng các bước kiểm tra đầu vào và thông báo lỗi rõ ràng vào các công cụ mà tác nhân sử dụng. Điều này ngăn chặn tình trạng “xác nhận sự vô lý” lọt qua.
Phát hiện sớm (Detect early) – Sai lầm được phát hiện càng sớm thì câu lệnh thực thi lại càng dễ thành công. Việc giám sát sự không khớp giữa việc sử dụng công cụ dự kiến và thực tế có thể kích hoạt câu lệnh sửa lỗi vào đúng thời điểm.
Xác nhận khả năng của mô hình (Validate model capabilities) – Trước khi dựa vào việc sửa lỗi bằng câu lệnh, hãy xác nhận rằng mô hình có thể gọi các công cụ một cách đáng tin cậy ngay từ đầu. Nếu không, bạn có thể đang đo lường hiệu quả của câu lệnh trên một nền tảng đã bị hỏng.
Điểm mấu chốt: Việc cho phép một tác nhân AI một cách rõ ràng được làm lại công việc của mình có thể biến một giải pháp sửa lỗi nửa vời thành một sự phục hồi hoàn toàn. Những người thiết kế câu lệnh nên coi “sử dụng công cụ để xác minh” như một van an toàn, chứ không phải là một sự bổ sung tùy chọn.