Vì sao tác nhân AI cần bằng chứng trước khi thử lại

Cách ngăn phản hồi bị thất lạc dẫn đến hành động trùng lặp

Một tác nhân hỗ trợ được phép thực hiện một khoản hoàn tiền gửi yêu cầu nhưng bị mất kết nối. Tác nhân không nhận được xác nhận rằng yêu cầu đã thành công nên gửi lại yêu cầu hoàn tiền. Nếu yêu cầu ban đầu đã được thực hiện thành công, hành động lặp lại của tác nhân có thể dẫn đến khoản hoàn tiền thứ hai.

Đây hoàn toàn là tình huống giả định. Ví dụ này cho thấy có một vấn đề không thể giải quyết chỉ bằng độ chính xác của mô hình. Tác nhân nên làm gì nếu không thể xác định liệu hành động trước đó của mình có làm thay đổi trạng thái môi trường hay không?

Unite.AI đã tìm hiểu độ tin cậy của tác nhân vượt ra ngoài phạm vi các mô hình. Trong những cuộc thảo luận đó, các vấn đề khôi phục cần có những quy tắc riêng. Trước khi thực hiện lại một hành động có hệ quả đáng kể, tác nhân cần xác nhận điều gì đã xảy ra hoặc phải có một bảo đảm hợp lệ rằng hành động đó sẽ không gây ra tác động trùng lặp.

Không có phản hồi không đồng nghĩa với việc hành động thất bại

Không nhận được phản hồi không chứng tỏ hành động đã thất bại. Điều đó không cho biết lỗi xảy ra trước khi thực thi, hành động đã hoàn tất nhưng không có xác nhận, hay quá trình vẫn đang diễn ra.

Đây là vấn đề phổ biến trong các hệ thống phân tán, như Amazon mô tả. Amazon giải thích vì sao cơ chế thử lại cần có những biện pháp bảo vệ cụ thể để ngăn các tác động phụ lặp lại. Tác nhân bổ sung một thực thể ra quyết định mới vào quy trình khôi phục của hệ thống. Chúng có thể đưa ra thêm quyết định về cách khắc phục lỗi.

Những quyết định này có thể làm thay đổi cách doanh nghiệp vận hành. Chẳng hạn, thử lại một khoản hoàn tiền với số tiền khác không đơn thuần là gửi lại cùng một yêu cầu. Tương tự, chọn một dịch vụ thanh toán thứ hai khi dịch vụ đầu tiên ngừng phản hồi cũng không chỉ là gửi lại cùng một yêu cầu.

Các nhóm phải phân biệt giữa việc cho phép thực hiện một hành động và việc cho phép khôi phục khi chưa rõ kết quả. Sự phê duyệt ban đầu không có nghĩa là thực hiện lại hành động đó sẽ an toàn.

Nghiên cứu gần đây đo lường rủi ro

Một bản tiền ấn phẩm tháng 9 năm 2026 có tên “Tính chất thực thi đúng một lần nằm ở đâu?” đã giới thiệu bộ tiêu chuẩn LIMBO và thử nghiệm 25,930 lượt trên chín mô hình. Các dịch vụ mô phỏng được kiểm tra trong những tình huống xác nhận bị thất lạc, xử lý chậm và gửi trùng lặp.

Trong số 1,279 lượt thử nghiệm ở bài kiểm tra chính của các tác giả có phát sinh tác động trùng lặp, các tác nhân báo cáo hoàn tất thành công trong 90% trường hợp. Vì vậy, tác nhân có thể báo cáo thành công ngay cả khi đã xảy ra lỗi xử lý.

Các kết quả này dựa trên những bài kiểm tra có kiểm soát và không ước tính tỷ lệ lỗi trong môi trường sản xuất. Các dịch vụ được mô phỏng và một số phân tích mang tính thăm dò. Các nhóm nên đánh giá riêng kết quả hành động của tác nhân và báo cáo của chúng về việc thực thi thành công.

Bài báo cũng lý giải vì sao việc kiểm tra trạng thái hiện tại có thể chưa đủ. Một yêu cầu vẫn đang được xử lý có thể phát huy tác dụng sau khi được kiểm tra. Ngay cả khi phản hồi trạng thái trống, điều đó cũng không có nghĩa là yêu cầu sẽ không phát huy tác dụng sau này.

Các lần thử lại phải cùng hướng đến một ý định

Dịch vụ tiếp nhận có thể nhận biết những lần thử lặp lại cùng một thao tác thông qua khóa lũy đẳng. Nếu được hỗ trợ đúng cách, phương thức này bảo đảm rằng các lần thử lại không tạo ra tác động bổ sung. Khóa lũy đẳng phải giữ nguyên trong suốt mọi lần thử lại.

Tài liệu API của Stripe đưa ra ví dụ về cả cơ chế lẫn những hạn chế của khóa lũy đẳng. Với API v1, khóa có thể bị xóa sau tối thiểu 24 giờ. Sử dụng lại khóa đã bị xóa sẽ tạo ra một yêu cầu mới. Stripe cũng xác minh rằng các tham số do bên yêu cầu cung cấp khớp với những tham số trong yêu cầu ban đầu.

Xét trên phương diện ứng dụng thực tế, tính lũy đẳng phải được triển khai trong lớp tích hợp của bạn, chứ không chỉ nằm trong câu lệnh gợi ý. Trước khi gửi đi một thao tác, hãy ghi lại thao tác đã được phê duyệt. Lưu mã định danh, các tham số chính xác, mã tham chiếu của nhà cung cấp nếu có và trạng thái thao tác.

Đối với khoản hoàn tiền, hãy lưu mối liên kết giữa phê duyệt và giao dịch ban đầu, cùng mọi mã định danh khoản hoàn tiền do nhà cung cấp trả về. Tìm kiếm bất kỳ khoản hoàn tiền nào có cùng số tiền là bằng chứng kém thuyết phục hơn, vì hai yêu cầu hợp lệ có thể có cùng số tiền. Ngoài ra, có thể có độ trễ giữa lúc gửi yêu cầu hoàn tiền và lúc khoản tiền đó xuất hiện trong kết quả tìm kiếm. Yêu cầu ban đầu vẫn có thể đang được xử lý.

Khi tác nhân hoặc tiến trình làm việc khởi động lại, lớp thực thi phải giữ nguyên định danh đó. Lớp này phải từ chối yêu cầu đã bị sửa đổi nhưng được gửi dưới dạng cùng một thao tác. Thay đổi như vậy là một hành động mới, cần có quyết định phê duyệt mới theo các quy tắc của quy trình.

Mô tả công cụ là chưa đủ

Ngoài mô tả công cụ, hãy xác minh hợp đồng của dịch vụ tiếp nhận về khả năng hỗ trợ tính lũy đẳng. Kiểm thử cách triển khai để xác nhận những bảo đảm nào thực sự được đáp ứng.

Xem sự không chắc chắn là một trạng thái vận hành

Hình 1. Quy trình khôi phục được đề xuất cho các hành động có hệ quả đáng kể. Mỗi lần thử lại cũng cần có sự cho phép còn hiệu lực.

Khi việc hoàn tất được xác nhận, quy trình sẽ ghi lại kết quả và tiếp tục mà không lặp lại hành động. Chỉ được phép thử lại nếu đã xác nhận hành động không được thực hiện, không còn yêu cầu ban đầu nào đang chờ xử lý và quyền cho phép vẫn còn hiệu lực.

Còn nhiều điều cần cân nhắc khi kết quả chưa được xác định. Nếu có bảo đảm hợp lệ từ nhà cung cấp rằng hành động sẽ không bị thực hiện trùng lặp, bạn có thể cho phép thử lại yêu cầu ban đầu bằng cùng một khóa. Nếu không, hãy tạm dừng việc ghi dữ liệu và xác minh lại bằng cách truy vấn trạng thái, liên hệ bộ phận hỗ trợ của nhà cung cấp hoặc nhờ người vận hành được ủy quyền. Việc kiểm tra chưa đưa ra kết luận không phải là lý do đủ để cho phép thử lại.

Việc tạm dừng cũng có thể hợp lý khi nhà cung cấp công bố giới hạn về thời gian xử lý và khả năng hiển thị trạng thái. Nếu không có những giới hạn đó, chỉ dựa vào thời gian đã trôi qua thì không thể xác nhận rằng hành động chưa được thực hiện. Bạn cần xác định ai chịu trách nhiệm xử lý các trường hợp chưa được giải quyết và khi nào những người đó phải xem xét chúng.

Khắc phục sự cố có thể đòi hỏi một quy trình nghiệp vụ khác

Nếu việc hoàn tiền thành công nhưng thông báo tiếp theo cho khách hàng không gửi được, chạy lại toàn bộ quy trình có thể khiến khoản tiền được hoàn lần nữa. Việc khắc phục nên tập trung vào hoàn tất bước còn dang dở, đồng thời lưu giữ bằng chứng về những công việc đã hoàn thành.

Nếu cần thực hiện hành động khắc phục đối với những việc đã hoàn tất trước đó, Microsoft hướng dẫn về các giao dịch bù trừ. Mỗi ứng dụng sẽ xác định cách phù hợp để khắc phục lỗi. Biện pháp bù trừ không nhất thiết đưa mọi thứ trở lại trạng thái ban đầu, và chính việc bù trừ cũng có thể thất bại.

Ngoài ra, việc hủy giao dịch có thể phát sinh phí. Việc sửa một tin nhắn không thể bảo đảm rằng chưa ai nhìn thấy phiên bản trước đó. Vì vậy, mọi hoạt động khắc phục phải nêu rõ những gì tác nhân được phép hoàn tác, thay đổi hoặc cam kết thực hiện. Những quyết định nằm ngoài các giới hạn này phải được chuyển cho người có đủ thẩm quyền.

Kiểm thử lần thử thứ hai trước khi triển khai

Chọn một công cụ có thể gây ra hậu quả đáng kể và chủ động kiểm thử khả năng khắc phục trong môi trường thử nghiệm. Sau khi thao tác thực hiện thành công, hãy loại bỏ phản hồi cho yêu cầu ban đầu. Trì hoãn việc thực thi yêu cầu đầu tiên cho đến sau khi kiểm tra trạng thái. Trong quá trình khắc phục, hãy khởi động lại tiến trình xử lý. Chờ cho đến khi thời hạn lưu giữ khóa hết trước khi thử lại. Thay đổi một tham số trong các lần thử liên tiếp.

Hãy đánh giá hồ sơ nghiệp vụ phát sinh thay vì chỉ dựa vào phản hồi từ công cụ. Ghi nhận các tác động trùng lặp, thao tác chưa được giải quyết, công việc bị bỏ sót, thời gian khắc phục và số lần cần can thiệp thủ công bổ sung. Tính chi phí cho mỗi nhiệm vụ hoàn tất chính xác dựa trên tổng chi phí quy trình, bao gồm cả việc đảo ngược giao dịch và biện pháp khắc phục cho khách hàng.

Ngoài ra, hãy kiểm thử một yêu cầu thứ hai thực sự, tương tự yêu cầu ban đầu. Đảm bảo hệ thống tránh tạo ra các bản trùng lặp mà không ngăn cản công việc mới. Đánh giá riêng khả năng tránh trùng lặp và khả năng hoàn tất nhiệm vụ về sau. Nếu không, một tác nhân chấm dứt mọi nhiệm vụ có thể có vẻ an toàn, dù tạo ra rất ít hoặc không tạo ra giá trị nào.

Cần nêu rõ câu hỏi đánh giá: Hệ thống có thể giải thích những điều sau không?

• Thao tác nào đã được cho phép?
• Có bằng chứng nào cho thấy kết quả của thao tác đó?
• Vì sao có thể cho phép thử lại?

Một tác nhân tạm dừng do chưa thể giải quyết sự không chắc chắn có thể trông kém hiệu quả hơn trong các buổi trình diễn. Tuy nhiên, trong môi trường vận hành thực tế, việc tạm dừng có thể giúp giữ nguyên ý định ban đầu của khách hàng. Khả năng duy trì trạng thái hữu ích có nghĩa là hệ thống hoàn tất các nhiệm vụ được cho phép mà không âm thầm thực hiện chúng nhiều lần.