"Không đo được thì không mở rộng được." Bài này thiết lập bộ chỉ số và quy trình đánh giá để biết agent đang tạo giá trị hay đang âm thầm gây hại.
Bốn nhóm chỉ số
1. Chất lượng (Quality): tỷ lệ hoàn thành đúng, độ chính xác, tỷ lệ hallucination.
2. Hiệu quả (Value): giờ người tiết kiệm, chi phí/ticket, doanh thu tác động.
3. Vận hành (Ops): tỷ lệ escalate, độ trễ, chi phí token/lần chạy.
4. Tin cậy (Trust): tỷ lệ khách hài lòng (CSAT), tỷ lệ khiếu nại do agent.
Một agent "rẻ và nhanh" nhưng đẩy CSAT xuống là thất bại — phải nhìn cả 4 nhóm, đừng tối ưu một chỉ số.
Xây bộ eval trước khi go-live
Đừng đánh giá agent bằng cảm giác. Tạo bộ test cố định gồm 30–100 ca thật (có cả ca khó, ca hiếm) với đáp án chuẩn. Chạy lại mỗi khi đổi prompt/model/tool.
Eval set (ví dụ support agent):
- 40 ca "đơn hàng ở đâu" (đáp án: trạng thái đúng)
- 20 ca yêu cầu hoàn tiền hợp lệ (đáp án: tạo phiếu đúng)
- 15 ca ngoài phạm vi (đáp án ĐÚNG = escalate, không bịa)
- 10 ca dữ liệu thiếu (đáp án ĐÚNG = hỏi lại/escalate)
Đạt production khi: chính xác >= 90%, escalate-đúng >= 95%,
tỷ lệ bịa (trả lời sai tự tin) <= 2%.
Ca "ngoài phạm vi" và "dữ liệu thiếu" quan trọng nhất: agent tốt biết khi nào nói không biết và escalate, thay vì bịa.
Ví dụ đọc chỉ số để ra quyết định
Sau 1 tháng chạy pilot với 20% lưu lượng ticket:
- Chính xác 92%, escalate-đúng 96%, CSAT không giảm, chi phí/ticket giảm 55%.
Nếu thay vào đó escalate-đúng chỉ 80% (agent tự xử ca lẽ ra phải chuyển người) → dừng mở rộng, siết guardrail, bổ sung ca vào eval set.
Một lưu ý về đo lường: đừng chỉ nhìn con số trung bình. Hãy tách theo phân khúc — ví dụ agent có thể chính xác 95% với ca "đơn ở đâu" nhưng chỉ 70% với ca hoàn tiền. Trung bình 90% che giấu điểm yếu nguy hiểm ở phân khúc rủi ro cao. Luôn xem chỉ số theo loại ca, đặc biệt các loại có chi phí sai lớn.
Khung quyết định mở rộng (scale gate)
CHỈ mở rộng lưu lượng khi TẤT CẢ đúng:
[ ] Chất lượng đạt ngưỡng eval trong >= 2 tuần liên tục
[ ] CSAT không giảm so với baseline con người
[ ] Chi phí/đơn vị công việc giảm rõ
[ ] Không có sự cố guardrail nghiêm trọng chưa khắc phục
Ngược lại -> giữ nguyên hoặc thu hẹp, sửa rồi mới scale.
Các bước làm
- Định nghĩa baseline con người cho 4 nhóm chỉ số trước khi bật agent.
- Xây eval set 30–100 ca có cả ca khó và ca escalate.
- Chạy pilot giới hạn (10–20% lưu lượng), giám sát dashboard hằng ngày.
- So sánh agent vs baseline theo cả 4 nhóm chỉ số.
- Áp scale gate: chỉ tăng lưu lượng khi mọi tiêu chí đạt.
- Đưa mọi ca lỗi mới phát hiện vào eval set (vòng lặp cải thiện).
Sai lầm thường gặp
- Chỉ đo giờ tiết kiệm, bỏ chất lượng/CSAT: agent "hiệu quả" nhưng làm mất khách.
- Không có eval set cố định: mỗi lần đổi prompt lại "cảm thấy tốt hơn" mà không chứng minh được.
- Mở rộng 100% ngay sau demo đẹp: demo không phản ánh đuôi dài ca thật.
- Không thưởng cho hành vi "biết nói không biết": agent bị ép trả lời mọi thứ sẽ bịa.
- Nhìn trung bình, bỏ qua phân khúc rủi ro cao: một điểm yếu 70% ở ca hoàn tiền bị che bởi trung bình 90%.
Tóm tắt
Đo lường biến agentic AI từ niềm tin thành bằng chứng. Bốn nhóm chỉ số (chất lượng, giá trị, vận hành, tin cậy), một eval set cố định gồm cả ca escalate, pilot giới hạn lưu lượng và một scale gate rõ ràng — đó là cơ chế giúp bạn mở rộng an toàn thay vì mở rộng mù. Mỗi lỗi mới là một test mới; eval set là tài sản tích lũy giá trị theo thời gian.
Bài 8 khép lại khóa học: đưa tất cả vào một tình huống vận hành thực tế end-to-end và những bài học triển khai giúp chương trình sống sót qua giai đoạn khó khăn nhất.