ThinkingBox: từ trạng thái dữ liệu cuối đến acceptance criteria dễ kiểm chứng

ThinkingBox chấm AI agent bằng trạng thái dữ liệu cuối thay vì lời giải thích hay chuỗi thao tác. Kết quả cho thấy kiểm tra có thể thực thi giúp tăng tính lặp lại; đây cũng là gợi ý để BA/PO viết acceptance criteria rõ hơn.

Một agent có thể thực hiện nhiều thao tác trông hợp lý nhưng vẫn để lại dữ liệu nghiệp vụ sai.

Đó là vấn đề ThinkingBox tập trung đo lường: thay vì chấm agent theo câu trả lời cuối hoặc buộc nó đi theo một chuỗi thao tác cố định, hệ thống kiểm tra trạng thái cơ sở dữ liệu sau cùng.

Trong một tình huống về đổi hạng phòng được bài nghiên cứu mô tả, chính sách yêu cầu phê duyệt của quản lý trước khi thay đổi đặt phòng. Mô hình cơ sở đã thay đổi booking và hoàn tiền khi chưa có phê duyệt trong 15 trên 20 lần chạy. Đây là một ví dụ cho thấy thao tác có vẻ hoàn tất chưa chắc đã tạo ra kết quả nghiệp vụ đúng.

ThinkingBox đo kết quả agent như thế nào?

ThinkingBox-Bench gồm 507 tác vụ. Mỗi tác vụ cung cấp cho agent một backend thực, các công cụ để thao tác và một người dùng LLM mô phỏng có ngữ cảnh riêng. Sau khi agent hoàn tất, hệ thống chạy các kiểm tra có thể thực thi trên trạng thái dữ liệu cuối.

Điểm đáng chú ý là các kiểm tra này không yêu cầu agent phải dùng đúng một công cụ hay lặp lại đúng cách giải của con người. Điều được chấm là bản ghi nghiệp vụ cần thiết có ở đúng trạng thái hay không.

Vì vậy, thay vì chỉ hỏi:

Agent có nói đã xử lý xong không? Agent có gọi đúng công cụ không?

ThinkingBox hướng tới câu hỏi:

Các bản ghi cuối cùng có đúng như kết quả mong đợi không? Những dữ liệu không được phép thay đổi có còn nguyên không? Các điều kiện nghiệp vụ có được tuân thủ không?

Kết quả nghiên cứu: tăng tính lặp lại, không tăng độ bao phủ ở mọi chiều

Microsoft và Hugging Face dùng các kiểm tra trạng thái dữ liệu cuối này làm tín hiệu thưởng để huấn luyện bổ sung Qwen3.8-27B bằng GRPO trong 50 bước.

Cần phân biệt hai tập tác vụ:

Tập huấn luyện gồm các tác vụ khác, có cùng định dạng ThinkingBox nhưng nằm ngoài benchmark. ThinkingBox-Bench gồm 507 tác vụ được giữ lại để đánh giá; mô hình không được huấn luyện trực tiếp trên các tác vụ này.

Trên benchmark giữ lại, đánh giá với 20 lần thử cho mỗi tác vụ:

Tỷ lệ thành công trung bình tăng từ 51,70% lên 60,78%. Số tác vụ đúng trong toàn bộ 20 lần thử được ghi nhận tăng từ 38 lên 107. Số tác vụ giải được ít nhất một lần giảm nhẹ từ 453 xuống 446.

Đây là một đánh đổi quan trọng. Theo kết quả được công bố, mô hình sau huấn luyện không trở nên bao quát hơn trên mọi tác vụ; thay vào đó, các kết quả đúng trở nên lặp lại hơn.

Với các workflow liên quan đến hồ sơ, đơn hàng, thanh toán hoặc quyền lợi khách hàng, một màn demo thành công là chưa đủ. Câu hỏi cần thêm là: nếu chạy lại, agent có tiếp tục để lại trạng thái nghiệp vụ hợp lệ không?

Gợi ý vận dụng cho BA/PO: viết tiêu chí theo trạng thái cuối

Phần dưới đây là gợi ý vận dụng từ cách ThinkingBox đánh giá agent, không phải quy trình mà nghiên cứu này trực tiếp đề xuất cho BA/PO.

Acceptance criteria thường mô tả hành động hoặc màn hình:

> Nhân viên xử lý thành công yêu cầu hoàn tiền.

Câu này có thể chưa đủ để đội sản phẩm, QA và kỹ thuật cùng hiểu thế nào là “thành công”. Một cách viết dễ kiểm chứng hơn là làm rõ trạng thái nghiệp vụ sau xử lý.

Ví dụ, thay vì chỉ nêu “cho phép hoàn tiền”, có thể cần làm rõ:

Điều kiện nào phải được đáp ứng trước khi tạo hoàn tiền? Bản ghi nào phải được tạo hoặc cập nhật? Khoản hoàn tiền được liên kết với đơn hàng hay yêu cầu nào? Dữ liệu nào phải giữ nguyên khi thiếu điều kiện phê duyệt? Thông báo cho khách được tạo ở thời điểm nào?

Trọng tâm chuyển từ “hệ thống đã làm thao tác gì?” sang “sau khi xử lý, sự thật nghiệp vụ nào phải đúng?”

Một khung rà soát acceptance criteria

Khi refinement một user story, BA/PO có thể dùng các câu hỏi sau để làm rõ điều kiện kiểm chứng:

Dữ liệu nào bị tác động? Bản ghi nào được tạo, sửa, giữ nguyên hoặc liên kết với nhau?

Trạng thái trước và sau là gì? Điều kiện đầu vào nào phải có? Sau khi xử lý thành công, từng thực thể ở trạng thái nào?

Khi nào hệ thống không được thay đổi dữ liệu? Ví dụ: thiếu phê duyệt, xác thực không đạt hoặc yêu cầu không đủ điều kiện.

Quan hệ dữ liệu nào phải tồn tại? Chẳng hạn, một giao dịch hoàn tiền cần liên kết với đúng đơn hàng và đúng yêu cầu xử lý.

Bằng chứng nào xác nhận hoàn tất? Không chỉ là thông báo trên giao diện, mà có thể là trạng thái bản ghi hoặc quan hệ giữa các bản ghi.

Prompt tham khảo để làm rõ yêu cầu

AI có thể hỗ trợ bóc tách điểm mơ hồ trong user story. Tuy nhiên, đầu ra cần được BA/PO kiểm tra lại và không được tự coi là quy tắc nghiệp vụ đã được phê duyệt.

text Bạn là Business Analyst hỗ trợ rà soát yêu cầu.

Hãy phân tích user story và acceptance criteria dưới đây. Mục tiêu: xác định các điều kiện nghiệp vụ có thể kiểm chứng từ trạng thái dữ liệu sau khi xử lý.

User story: <dán user story>

Quy tắc nghiệp vụ đã biết: <dán quy tắc>

Hãy trả về: Các thực thể dữ liệu bị tác động Trạng thái trước và sau mong đợi của từng thực thể Trường hợp dữ liệu không được thay đổi Các quan hệ dữ liệu cần tồn tại Điểm mơ hồ hoặc mâu thuẫn cần xác minh với stakeholder Acceptance criteria viết lại theo Given / When / Then

Không tự giả định quy tắc chưa được nêu. Đánh dấu rõ các nội dung cần xác minh.

Đừng nhầm “đã hiển thị” với “đã hoàn tất”

Một thông báo thành công, ticket được đóng hoặc câu trả lời tự tin từ agent chưa tự nó chứng minh workflow đã hoàn tất đúng.

Với các quy trình có ràng buộc nghiệp vụ, acceptance criteria nên giúp trả lời được:

Kết quả cuối có đúng không? Điều kiện bắt buộc có được đáp ứng không? Dữ liệu có bị thay đổi sai ở đâu không? Nếu chạy lại workflow, kết quả có tiếp tục đáng tin cậy không?

ThinkingBox không trực tiếp biến acceptance criteria thành kiểm tra cơ sở dữ liệu. Nhưng cách hệ thống này đánh giá agent đưa ra một nguyên tắc hữu ích cho đội sản phẩm:

> “Done” nên được xác định bằng trạng thái nghiệp vụ cuối có thể kiểm chứng, không chỉ bằng thao tác đã thực hiện hoặc lời khẳng định đã xong.

Tìm hiểu thêm

Bài gốc: Turning Database Grading into RL Rewards: Post-Training Agents with ThinkingBox Bài gốc cũng cho biết ThinkingBox-Training đã được công bố trên GitHub, dành cho người muốn tìm hiểu hoặc tái lập training stack.