StateBench: khung QA để bắt lỗi AI quên trạng thái trong ngữ cảnh dài
StateBench phân biệt AI chỉ tìm được thông tin mới nhất với AI thực sự theo dõi chuỗi cập nhật. Đây là khung tham khảo để QA thiết kế test cho chatbot, tài liệu dài và workflow nhiều bước.
Một chatbot hỗ trợ đơn hàng có thể trả lời đúng câu “địa chỉ giao hàng hiện tại là gì?” ngay sau khi khách đổi địa chỉ. Nhưng nếu khách đổi sản phẩm, chuyển đơn cho người khác, áp ưu đãi rồi hoàn tác một phần yêu cầu, chatbot còn theo dõi đúng trạng thái nào đang có hiệu lực không?
Đây là loại lỗi dễ lọt qua smoke test. Model có thể trông rất thuyết phục khi tìm được thông tin xuất hiện gần nhất, nhưng vẫn sai khi trạng thái thay đổi theo chuỗi, phụ thuộc vào biến khác hoặc trải qua nhiều lần hoán đổi.
StateBench của Ai2 là benchmark đánh giá năng lực theo dõi trạng thái thay đổi của thực thể trong ngữ cảnh dài. Với QA, đây là một khung tham khảo hữu ích để biến câu hỏi mơ hồ “AI có nhớ không?” thành test case có expected result rõ ràng.
State tracking là gì?
State tracking là việc duy trì đúng “giá trị hiện tại” của một thực thể sau nhiều cập nhật.
Trong code, đó có thể là một biến bị gán lại. Trong sản phẩm, đó có thể là người phụ trách ticket, trạng thái đơn hàng, vị trí đối tượng hoặc tổng số lượng sau các điều chỉnh.
StateBench chia bài toán thành bốn mức độ khó, có thể hình dung như các kiểu cập nhật biến mà QA nên đưa vào test data:
| Tầng | Kiểu cập nhật | Ví dụ áp dụng trong QA |
|---|---|---|
| R-trivial | Giá trị không đổi | Mã hồ sơ hoặc ngày sinh chỉ được khai báo một lần |
| Aperiodic | Gán lại theo giá trị mới nhất | Trạng thái ticket đổi từ “mở” sang “đã xử lý” |
| Soluble | Cập nhật dựa trên giá trị hiện tại | Tổng điểm, số lượng hoặc số dư thay đổi cộng dồn |
| General finite | Gán theo tham chiếu, hoặc hoán đổi biến | Chuyển quyền sở hữu hay hoán đổi người phụ trách |
Điểm cần lưu ý: tìm mention gần nhất chỉ đủ cho bài toán aperiodic.
Chẳng hạn, nếu có câu “A chuyển món đồ trong ba lô cho B”, model phải biết món gì đang ở trong ba lô của A trước đó. Chỉ đọc câu mới nhất là không đủ.
Theo Ai2, các frontier model được thử nghiệm làm tốt ở mức R-trivial và aperiodic. Tuy nhiên, ở các bài toán soluble và general finite, độ chính xác giảm mạnh khi đầu vào dài hơn. Với bài toán general finite dài nhất, kết quả giảm xuống 13% hoặc thấp hơn.
Biến bốn tầng thành ma trận test
Đừng chỉ kiểm thử happy path kiểu “người dùng đổi email, AI xác nhận email mới”. Hãy lập ma trận theo loại chuyển trạng thái.
Ví dụ, bạn đang test chatbot nội bộ hỗ trợ quản lý ticket:
> Nhân viên có thể tạo ticket, đổi người phụ trách, chuyển ticket giữa nhóm và đặt lại độ ưu tiên. Chatbot trả lời câu hỏi về trạng thái hiện tại của ticket.
Một tập test nhỏ có thể bao gồm:
R-trivial: “Ticket T thuộc dự án nào?” Dự án chỉ được khai báo khi tạo ticket.
Aperiodic: Độ ưu tiên lần lượt đổi từ thấp sang cao rồi trung bình. Hỏi giá trị cuối.
Soluble: Mỗi lần escalation, SLA còn lại giảm theo một quy tắc xác định. Hỏi SLA hiện tại.
General finite: Ticket được chuyển cho An; An chuyển ticket đang phụ trách cho Chi; Bình và Chi hoán đổi ticket phụ trách. Hỏi ai đang giữ ticket ban đầu.
Test case tốt không chỉ có expected result. Nó cần cho reviewer thấy đường đi dẫn đến kết quả, để phân biệt model trả lời đúng do suy đoán, bám câu cuối hay thực sự theo dõi toàn bộ chuỗi.
Prompt mẫu để phác thảo test case
Bạn có thể dùng AI để phác thảo dữ liệu kiểm thử, nhưng vẫn cần tự kiểm chứng logic trước khi đưa vào test suite. Prompt dưới đây chỉ dùng để tạo dữ liệu; không nên xem output của model là oracle.
text
Bạn là QA engineer kiểm thử chatbot theo dõi trạng thái.
Feature:
<motafeature>
Hãy tạo test case cho một thực thể <tenthucthe> theo bốn mức:
R-trivial: giá trị không thay đổi
Aperiodic: giá trị bị gán lại
Soluble: giá trị cập nhật dựa trên giá trị hiện tại
General finite: cập nhật tham chiếu hoặc hoán đổi giữa nhiều thực thể
Với mỗi test case, trả về:
Test objective
Conversation/history input
User question cuối
Expected answer
State table sau từng bước cập nhật
Lý do vì sao test này có thể bắt lỗi chỉ lấy thông tin xuất hiện gần nhất
Không dùng dữ liệu thật, thông tin định danh hoặc credential.
Ví dụ một case general finite có thể ở dạng log workflow:
text
Ticket A do An phụ trách.
Ticket B do Bình phụ trách.
An chuyển ticket mình đang phụ trách cho Chi.
Bình và Chi hoán đổi ticket đang phụ trách.
Câu hỏi: Ai đang phụ trách Ticket A?
Expected state cần được kiểm tra độc lập:
Ban đầu: An giữ Ticket A; Bình giữ Ticket B.
An chuyển ticket đang giữ: Chi giữ Ticket A.
Bình và Chi hoán đổi: Bình giữ Ticket A.
Expected answer: Bình.
Nếu model kết luận Chi chỉ vì bám vào câu “An chuyển ... cho Chi”, đó là một lỗi state tracking rõ ràng.
Cách kiểm tra output AI và tránh test case “trông đúng”
Khi AI hỗ trợ viết test case hoặc script, QA vẫn phải đóng vai trò oracle.
1. Kiểm tra coverage gap
Bộ test có chỉ dừng ở “giá trị mới nhất” không? Nếu có, nó mới phủ aperiodic. Hãy bổ sung cập nhật cộng dồn và cập nhật theo tham chiếu.
2. Tự xác minh expected result
Với mọi case soluble và general finite, hãy mô phỏng bằng state table hoặc logic độc lập. Không dùng câu trả lời của model làm nguồn chân lý duy nhất.
3. Đổi format, giữ nguyên logic
Ai2 ghi nhận định dạng bài toán có thể ảnh hưởng đáng kể đến kết quả ở một số mô hình: cùng bài toán R-trivial nhưng được trình bày theo kiểu khác có thể cho điểm khác nhau.
Vì vậy, hãy chạy cùng logic dưới các dạng gần với sản phẩm thực tế:
Hội thoại tự do
Audit log
Bảng thay đổi
Email tóm tắt
Ticket timeline
4. Tăng độ dài có kiểm soát
Chèn nội dung không liên quan giữa các cập nhật quan trọng nhưng giữ nguyên expected result. Mục tiêu là kiểm tra model có mất dấu trạng thái khi lịch sử kéo dài hay không.
5. Kiểm tra tham chiếu
Thử các cụm như “mục đang giữ”, “ticket đó” hoặc “người phụ trách hiện tại”. Đây là nơi hệ thống có thể nhầm thực thể hoặc liên kết sai tham chiếu.
Với automation, nên tách hai lớp assertion:
Assertion xác nhận UI hoặc API workflow đã tạo đúng trạng thái.
Assertion xác nhận câu trả lời của AI phản ánh đúng trạng thái đó.
Nếu chỉ assert text chatbot trả về, bạn khó xác định lỗi nằm ở backend state, retrieval hay suy luận của model.
Kết quả benchmark gợi ý gì cho QA?
StateBench so sánh các bài toán trên cùng chuỗi gán, chỉ thay đổi độ phức tạp của phép cập nhật. Đây là một ý tưởng QA có thể áp dụng: giữ nguyên thực thể, số lần thay đổi và vị trí thay đổi; chỉ nâng mức dependency.
Theo Ai2, khi được huấn luyện trực tiếp trên tác vụ, các mô hình Gated DeltaNet và hybrid có thể tổng quát hóa xa hơn transformer ở nhiều dạng state tracking. Tuy nhiên, với đội kiểm thử sản phẩm, không nên chọn kiến trúc chỉ từ một benchmark.
Kết luận thực dụng hơn là: context dài không tự động đồng nghĩa với việc model theo dõi đúng một workflow dài và nhiều phụ thuộc.
Checklist trước khi sign-off AI workflow
[ ] Có test cho giá trị bất biến, gán lại, cập nhật cộng dồn và tham chiếu/hoán đổi.
[ ] Mỗi expected result có state table hoặc bước suy luận độc lập.
[ ] Có cùng một kịch bản ở nhiều format đầu vào.
[ ] Có test chèn nội dung nhiễu giữa các lần cập nhật.
[ ] Có assertion tách riêng workflow state và AI response.
[ ] Không đưa dữ liệu production, PII hoặc credential vào công cụ AI công khai.
StateBench nhắc QA một điều đơn giản nhưng quan trọng: AI trả lời đúng câu cuối chưa chứng minh nó “nhớ” đúng cả quy trình. Muốn bắt lỗi khó, hãy kiểm thử cách trạng thái thay đổi, không chỉ kiểm thử câu trả lời cuối cùng.