Đội chăm sóc khách hàng sửa prompt để AI phân loại email chính xác hơn. Mười email thử đều đạt, nhưng một yêu cầu hoàn tiền có tệp đính kèm lại bị xếp vào nhóm hỏi thông tin chung sau khi phát hành. Vài ví dụ thuận lợi chưa đủ chứng minh thay đổi an toàn.
Quy trình có AI còn đổi khi model, tài liệu tham chiếu, dữ liệu hoặc luật kinh doanh thay đổi. Test hồi quy phải kiểm tra kết quả, đường đi của tác vụ và phản ứng khi hệ thống không đủ chắc chắn.
Vì sao kiểm tra vài câu lệnh chưa đủ?
Đầu vào thực tế có nhiều biến thể
Cùng là yêu cầu đổi lịch, khách hàng có thể gửi email, ảnh qua Zalo hoặc trả lời chuỗi cũ. Có người nêu đủ mã đơn, có người chỉ viết “đổi giúp mình sang chiều mai”. Bộ test chỉ chứa câu đầy đủ sẽ bỏ qua dữ liệu thiếu, ngôn ngữ mơ hồ và tệp lỗi.
Kết quả đúng vẫn có thể dẫn tới hành động sai
AI có thể phân loại đúng nhưng ghi sai trạng thái vào CRM hoặc gửi phản hồi khi cần nhân viên duyệt. Test phải quan sát cả đầu ra và hành động của hệ thống.
Chọn lỗi cần chặn trước khi chọn công cụ test
Hãy bắt đầu từ hậu quả vận hành. Lỗi chính tả trong bản nháp khác với việc tự gửi báo giá sai điều kiện. Những hành động có thể làm mất dữ liệu, lộ thông tin hoặc tạo cam kết sai phải chặn phát hành.
Câu trả lời thiếu tự nhiên hoặc phân loại chưa đủ chi tiết có thể được theo dõi theo mức độ. Không nên đánh đồng mọi khác biệt câu chữ với lỗi vận hành.
Bài cách thiết kế trạng thái công việc trước khi tự động hóa hướng dẫn chốt trạng thái, điều kiện chuyển và người chịu trách nhiệm trước khi đưa AI vào luồng.
Tạo bộ dữ liệu kiểm thử từ tình huống vận hành
Hãy lấy mẫu từ trường hợp đội đã xử lý, sau khi xóa thông tin nhận diện và dữ liệu nhạy cảm. Giữ lại đặc điểm khó xử lý như thiếu mã đơn, nhiều ý định, chính sách mâu thuẫn, tệp lỗi hoặc yêu cầu vượt quyền.
Với mỗi trường hợp, hãy ghi:
- Kết quả tối thiểu được chấp nhận.
- Hành động bị cấm, như tự hoàn tiền.
- Công cụ được phép gọi và tham số bắt buộc.
- Điều kiện chuyển người, dữ liệu cần kèm theo và người cập nhật mẫu.
Bổ sung mẫu từ sự cố mới, phản hồi của nhân viên và hàng chờ xử lý ngoại lệ để bộ test tiếp tục phản ánh quy trình đang chạy.
Quy trình chạy test trước mỗi lần phát hành
1. Khóa phiên bản cần so sánh
Ghi rõ model, prompt, tài liệu, luật xử lý và cấu hình công cụ. Chỉ đổi từng nhóm thành phần để dễ tìm nguyên nhân.
2. Chạy cùng bộ mẫu trên bản hiện tại và bản mới
Lưu đầu ra, công cụ đã gọi, trạng thái cuối và lý do chuyển người. Dùng môi trường thử cho tác vụ có tác động thật.
3. Chấm bằng luật và người có chuyên môn
Luật cố định kiểm tra định dạng, trường bắt buộc, quyền và hành động cấm. Người nghiệp vụ duyệt báo giá, khiếu nại và ngoại lệ chính sách.
4. Xem từng lỗi thay vì chỉ nhìn điểm trung bình
Điểm trung bình tốt hơn không bù được một hành động bị cấm. Gắn mỗi lỗi với mẫu, mức độ và thành phần vừa đổi.
5. Phát hành có giới hạn và theo dõi
Chỉ mở cho một phần tác vụ, giữ khả năng khôi phục phiên bản trước và theo dõi lỗi công cụ cùng phản hồi của nhân viên.
Chấm kết quả có nhiều cách diễn đạt đúng
Không nên bắt AI trả về đúng từng chữ khi có nhiều câu trả lời hợp lệ. Với email, hãy kiểm tra thông tin bắt buộc và cam kết ngoài chính sách. Với dữ liệu có cấu trúc, kiểm tra schema, kiểu dữ liệu và giá trị cho phép.
Tiêu chí cố định có thể chấm tự động. Phần cần hiểu ngữ cảnh phải do người nghiệp vụ duyệt. Nếu dùng model khác để chấm, vẫn cần kiểm tra định kỳ bằng người.
Phân chia trách nhiệm trong kiểm thử
Hệ thống tự động xử lý
- Chạy mẫu trên cấu hình được chỉ định.
- Kiểm tra schema, trường bắt buộc, hành động cấm và quyền công cụ.
- So sánh hai phiên bản và dừng phát hành khi vi phạm điều kiện chặn.
Con người xác nhận
- Chọn mẫu đại diện và xóa dữ liệu nhạy cảm.
- Định nghĩa kết quả chấp nhận được.
- Duyệt trường hợp mơ hồ và ngoại lệ chính sách.
- Quyết định phát hành, giới hạn phạm vi hoặc khôi phục phiên bản trước.
Theo dõi sau phát hành để cập nhật bộ test
Test trước phát hành không bao phủ hết dữ liệu thực tế. Ghi nhận trường hợp bị nhân viên sửa, tác vụ chuyển người không cần thiết và lỗi gọi công cụ. Tái hiện mỗi lỗi thành một mẫu trước khi sửa, rồi chạy lại toàn bộ bộ test.
Báo cáo theo phiên bản cần nêu nhóm lỗi thay đổi, mẫu bị chặn và nguyên nhân phổ biến. Với quy trình liên quan đến thanh toán, dữ liệu cá nhân hoặc cam kết khách hàng, người phụ trách nghiệp vụ phải quyết định phát hành.
Dịch vụ AI Agent Coaching của Auranium hỗ trợ đội chọn một quy trình cụ thể, xác định cổng kiểm tra và tổ chức thử nghiệm có kiểm soát trước khi mở rộng phạm vi.