Xây dựng scorecard đánh giá chất lượng AI Agent như thế nào?

Sau vài tuần chạy thử, câu hỏi quen thuộc trong mọi buổi họp dự án là: AI Agent này đã đủ tốt chưa? Người bán hàng thấy nó trả lời trôi chảy, người phụ trách pháp chế lo vì một câu trả lời không có nguồn, còn đội kỹ thuật chỉ nhìn độ trễ. Mỗi bên chấm theo cảm nhận riêng, nên cuộc họp kết thúc mà không ai dám ký nghiệm thu.

Scorecard là cách đưa những cảm nhận đó về một bảng chung: mỗi câu trả lời hoặc mỗi tác vụ được chấm theo cùng một bộ tiêu chí, có thang điểm, có người chấm và có ngưỡng đạt. Bài viết trình bày tám tiêu chí nên có, cách dựng bộ mẫu để chấm và cách dùng kết quả để quyết định sửa gì trước khi mở rộng.

Scorecard khác với KPI vận hành. KPI như trong bài đo hiệu quả AI Agent bằng KPI nhìn tổng thể sau khi hệ thống chạy thật; scorecard soi từng câu trả lời để biết chất lượng hỏng ở đâu.

1. Bản chất của đánh giá chất lượng AI Agent

Một câu trả lời của AI Agent là kết quả của nhiều lớp: mô hình hiểu câu hỏi, bộ truy xuất lấy tài liệu, công cụ gọi vào hệ thống và lớp kiểm soát quyết định agent được làm gì. Nếu chỉ chấm “đúng” hay “sai”, doanh nghiệp không biết lỗi nằm ở lớp nào. Scorecard tách chất lượng thành các tiêu chí độc lập, để một câu trả lời có thể đúng nội dung nhưng vẫn trượt vì thiếu nguồn hoặc vượt quyền.

Ba loại việc của agent cần trọng số khác nhau. Với hỏi đáp từ kho kiến thức, tiêu chí nặng nhất là đúng nội dung và đúng nguồn. Với tra cứu thời gian thực như tồn kho hay trạng thái đơn, cần chấm thêm độ tươi của dữ liệu và độ trễ. Với hành động ghi như tạo phiếu hay cập nhật CRM, hành động chính xác và đúng quyền trở thành tiêu chí chặn: chỉ một lỗi là cả tác vụ không đạt, dù các tiêu chí khác cao đến đâu.

2. Các yếu tố cần thiết kế

1. Đúng nội dung

Câu trả lời khớp với đáp án chuẩn do người am hiểu nghiệp vụ viết sẵn, không thêm điều kiện hay con số không có trong nguồn. Nên chấm theo thang ba mức: đúng đủ, đúng nhưng thiếu ý quan trọng, sai. Thang năm hay mười mức thường khiến hai người chấm cùng một câu cho điểm khác nhau.

2. Đúng nguồn

Agent phải dựa vào tài liệu có thẩm quyền, còn hiệu lực, và trích được nguồn khi người dùng cần kiểm tra. Người chấm mở đúng đoạn được trích để xem nó có thật sự chứa câu trả lời không. Dấu hiệu nguy hiểm là câu trả lời đúng nhờ may mắn nhưng trích một tài liệu cũ; lần sau tài liệu đổi, câu trả lời sẽ sai theo.

3. Đúng quyền

Cùng một câu hỏi, nhân viên kinh doanh và kế toán có thể được xem thông tin khác nhau. Bộ ca chấm cần có câu hỏi gửi từ từng vai trò, trong đó có ca cố tình hỏi dữ liệu ngoài quyền. Đây là tiêu chí chặn: lộ dữ liệu một lần là không đạt, không lấy điểm tiêu chí khác bù vào.

4. Hành động chính xác

Với tác vụ ghi, người chấm kiểm tra kết quả trong hệ thống đích chứ không chỉ đọc lời agent nói. Phiếu có được tạo đúng loại, đúng trường, đúng người phụ trách không; gửi lại cùng yêu cầu có sinh bản trùng không. Một agent báo “đã tạo đơn” trong khi API trả lỗi là lỗi nặng hơn nhiều so với một câu trả lời vụng về.

5. An toàn

Tiêu chí này chấm cách agent xử lý yêu cầu lệch mục đích: câu lệnh cài trong tài liệu, người dùng đòi bỏ qua quy tắc, nội dung xúc phạm, câu hỏi về dữ liệu cá nhân của người khác. Bộ ca thử nên có những câu được viết khéo, không chỉ những câu lộ liễu. Kết quả là đạt hoặc không đạt, kèm ghi chú agent đã phản ứng thế nào.

6. Độ trễ

Độ trễ được đo theo từng loại việc, vì người dùng chấp nhận chờ khác nhau: câu hỏi chính sách cần nhanh, báo cáo tổng hợp có thể chờ lâu hơn. Nên ghi thời gian ở từng chặng như truy xuất, gọi mô hình, gọi API để biết chậm ở đâu. Ngưỡng do chủ sở hữu nghiệp vụ đặt theo trải nghiệm thực tế, không dùng một con số chung cho mọi tác vụ.

7. Khả năng từ chối

Agent tốt biết nói “tôi chưa có thông tin này” và chuyển đúng người khi câu hỏi ngoài phạm vi hoặc dữ liệu không đủ. Scorecard cần những ca mà đáp án đúng chính là từ chối, và chấm cả chiều ngược lại: từ chối khi lẽ ra phải trả lời cũng là lỗi. Một agent từ chối quá nhiều trông rất an toàn nhưng sẽ sớm bị người dùng bỏ qua.

8. Trải nghiệm người dùng

Tiêu chí cuối chấm cách câu trả lời đến tay người dùng: có đi thẳng vào ý chính không, có hỏi lại khi thiếu thông tin thay vì đoán không, giọng văn có hợp kênh và đối tượng không. Phần này dễ bị chấm cảm tính, nên mỗi mức điểm cần mô tả cụ thể kèm vài câu mẫu tốt và chưa tốt để người chấm tham chiếu.

3. Quy trình triển khai thực tế

Bước 1: Xác định phạm vi và kết quả cần đo

Chọn những loại yêu cầu agent sẽ xử lý trong đợt đánh giá, rồi quyết định tiêu chí nào là tiêu chí chặn, tiêu chí nào tính điểm. Kết quả của bước này là bảng scorecard có định nghĩa, thang điểm và ngưỡng đạt cho từng tiêu chí. Chủ sở hữu nghiệp vụ ký xác nhận bảng này trước khi chấm câu đầu tiên.

Bước 2: Chuẩn hóa dữ liệu cùng quyền truy cập

Dựng bộ ca chấm từ câu hỏi thật trong email, tổng đài hay nhóm chat nội bộ, kèm đáp án chuẩn và nguồn đối chiếu. Mỗi ca ghi rõ vai trò người hỏi để chấm được tiêu chí đúng quyền. Dữ liệu cá nhân trong câu hỏi thật được che trước khi đưa vào bộ ca.

Bước 3: Thiết kế tích hợp ngoại lệ và phê duyệt

Với tác vụ ghi, chuẩn bị môi trường thử có dữ liệu giả để chấm hành động mà không chạm vào hệ thống thật. Viết sẵn ca ngoại lệ: API không phản hồi, thiếu trường bắt buộc, yêu cầu vượt hạn mức phải chờ duyệt. Người phụ trách kỹ thuật xác nhận môi trường thử có cấu hình quyền giống môi trường thật.

Bước 4: Kiểm thử vận hành rồi cải thiện theo log

Cho hai người chấm độc lập trên cùng một phần mẫu để xem thang điểm đã đủ rõ chưa; chỗ nào lệch nhiều thì sửa định nghĩa. Sau đó chấm toàn bộ, gom lỗi theo tiêu chí và theo lớp gây lỗi. Mỗi lần sửa dữ liệu, prompt hay mô hình, chạy lại cùng bộ ca để so với lần chấm trước.

4. Ví dụ giả định

Scorecard cho thấy câu trả lời đúng nhưng thiếu nguồn và chuyển người chậm, nên dự án chưa được nghiệm thu.

Tình huống này cho thấy điểm trung bình cao có thể che mất lỗi quan trọng. Từ đó nên thêm hai nhóm ca thử: cùng câu hỏi nhưng tài liệu nguồn đã bị gỡ, để xem agent có còn trả lời theo trí nhớ không; và câu hỏi cần chuyển người trong giờ cao điểm, để đo thời gian yêu cầu tới tay nhân viên. Bài học là mỗi tiêu chí cần ngưỡng riêng, và dự án chỉ được nghiệm thu khi không tiêu chí nào dưới ngưỡng, giống cách làm trong checklist nghiệm thu AI Agent.

5. Rủi ro và giới hạn

• Không tự động hóa khi dữ liệu hoặc thẩm quyền chưa rõ
• Giới hạn quyền đọc ghi theo nhu cầu tối thiểu
• Giữ người phụ trách cho ngoại lệ và quyết định quan trọng
• Theo dõi log và kiểm thử lại sau mỗi thay đổi

Rủi ro lớn nhất của scorecard là bộ ca chấm quá dễ. Nếu chỉ gồm câu hỏi chuẩn do đội dự án tự nghĩ ra, điểm sẽ cao nhưng không phản ánh cách khách hàng thật đặt câu hỏi. Rủi ro thứ hai là agent bị chỉnh để qua đúng bộ ca đó; nên giữ riêng một phần ca chấm không dùng trong lúc sửa lỗi, chỉ mở ra ở vòng nghiệm thu. Ngoài ra, câu hỏi thật dùng làm ca chấm thường chứa dữ liệu khách hàng, nên bộ ca cũng phải được phân quyền như dữ liệu gốc.

6. Phân chia trách nhiệm vận hành

Chủ sở hữu nghiệp vụ quyết định tiêu chí, ngưỡng đạt và đáp án chuẩn, vì chỉ họ biết câu trả lời nào là đúng với khách hàng. Người chấm nên là chuyên viên đang làm việc đó hằng ngày, không phải người viết prompt, để tránh chấm theo điều mình mong muốn. Đội kỹ thuật lo công cụ ghi log, môi trường thử và bảng điểm theo từng lần chạy. Bộ phận an toàn thông tin duyệt riêng các ca thử về quyền và an toàn.

Bản thân scorecard cũng cần quản lý phiên bản như agent. Khi thêm tiêu chí hay đổi thang điểm, điểm cũ và điểm mới không còn so trực tiếp được, nên mỗi lần chấm phải ghi rõ dùng phiên bản nào. Nếu một tiêu chí chặn tụt dưới ngưỡng sau một thay đổi, người có quyền phải dừng phát hành bản đó và quay về bản trước cho tới khi sửa xong.

7. Chỉ số nên theo dõi

• Tỷ lệ đạt theo từng tiêu chí đã duyệt
• Tỷ lệ từ chối đúng và chuyển người phụ trách
• Lỗi tích hợp, độ trễ và số thao tác phải sửa
• Chi phí cùng tác động kinh doanh của quy trình

Điểm tổng trung bình là con số dễ báo cáo nhưng ít giá trị nhất. Nên theo dõi tỷ lệ đạt của từng tiêu chí, số lỗi thuộc tiêu chí chặn, mức chênh giữa hai người chấm và xu hướng điểm qua các phiên bản. Tách theo nhóm câu hỏi để biết nhóm nào đang kéo chất lượng xuống.

8. Checklist trước khi vận hành

• Bảng tiêu chí, ngưỡng đạt và người chấm đã xác nhận
• Quyền đọc ghi đã thử với nhiều vai trò
• Có phương án khi hệ thống lỗi hoặc thiếu dữ liệu
• Có log, phê duyệt và cơ chế chống thao tác trùng
• Có bộ kiểm thử hồi quy và người vận hành

9. Câu hỏi thường gặp

Có thể dùng scorecard đánh giá chất lượng AI Agent ngay không? Có thể bắt đầu ngay ở mức đơn giản, với vài tiêu chí chính và một bộ câu hỏi lấy từ thực tế. Điều kiện là đáp án chuẩn đã được người am hiểu nghiệp vụ xác nhận; thiếu phần này thì điểm chấm không có căn cứ.

Nên bắt đầu xây scorecard từ đâu? Bắt đầu từ những câu hỏi và tác vụ agent gặp nhiều nhất, cộng thêm các ca từng gây sự cố. Chốt trước các tiêu chí chặn như đúng quyền và an toàn, rồi mới thêm tiêu chí về trải nghiệm.

Khi nào kết quả chấm scorecard cần người duyệt? Mọi lần chấm dùng để nghiệm thu hoặc quyết định phát hành đều cần chủ sở hữu nghiệp vụ duyệt. Những ca hai người chấm cho kết quả khác nhau và mọi lỗi thuộc tiêu chí chặn phải được người có thẩm quyền xem trực tiếp.

Có nên dùng một mô hình AI khác để chấm tự động không? Có thể dùng để chấm sơ bộ những tiêu chí dễ đo như có trích nguồn hay không, giúp chạy lại nhanh sau mỗi thay đổi. Kết quả chấm tự động cần được đối chiếu định kỳ với người chấm, và không thay người ở các tiêu chí chặn.

Kết luận

Scorecard biến câu hỏi “AI Agent đã đủ tốt chưa” thành một bảng có tiêu chí, ngưỡng và người chịu trách nhiệm. Giá trị của nó nằm ở việc chỉ ra lỗi thuộc lớp nào để sửa đúng chỗ, và giữ chất lượng không tụt sau mỗi lần thay đổi. Scorecard cũng là đầu vào cho vòng phản hồi từ người dùng, được trình bày ở bài human feedback loop cho AI Agent.

Trao đổi với Naventic để xây bộ tiêu chí đánh giá cho AI Agent của doanh nghiệp. Đọc thêm: Dịch vụ.