Bài 7 — Đo hiệu quả, giám sát và gỡ lỗi đội agent

"Không đo được thì không cải thiện được"

Một đội agent triển khai xong không phải là đích — nó là điểm bắt đầu của việc đo và tối ưu. Bài này bàn về metrics phòng ban, observability (trace/log), và quy trình gỡ lỗi khi đội hành xử sai.

Bốn nhóm metric cần theo dõi

• Chất lượng: tỉ lệ giải quyết đúng (resolution rate), độ chính xác, tỉ lệ khách hài lòng (CSAT).
• Hiệu suất: thời gian phản hồi, số bước trung bình mỗi task, tỉ lệ tự động hóa (bao nhiêu % không cần người).
• Chi phí: token/task, chi phí/task, chi phí mỗi ca escalate.
• An toàn: tỉ lệ escalate, tỉ lệ chạm guardrail, số lỗi nghiêm trọng.

Ví dụ: bảng metric cho phòng CSKH

resolution_rate       82%   (mục tiêu >= 80%)  ✅
auto_resolution       61%   (mục tiêu >= 60%)  ✅
avg_response_time     9s    (mục tiêu <= 15s)  ✅
cost_per_task         1.240đ (mục tiêu <= 2.000đ) ✅
escalation_rate       18%   (theo dõi xu hướng)
guardrail_hit_rate    3%    (bất thường nếu tăng vọt)

Observability: trace là bạn thân khi debug

Mỗi request nên sinh một trace ghi lại toàn bộ hành trình:

{
  "trace_id": "req_8891",
  "steps": [
    {"agent": "router", "output": "refund", "ms": 320},
    {"agent": "refund_agent", "tool": "check_policy", "output": "eligible", "ms": 210},
    {"agent": "refund_agent", "tool": "create_refund", "output": "OVER_LIMIT", "ms": 90},
    {"agent": "escalation", "output": "pending_human", "ms": 40}
  ],
  "total_ms": 660,
  "tokens": 2140
}

Khi có trace, gỡ lỗi biến từ "đoán mò" thành "đọc dấu vết".

Ba loại lỗi hay gặp và cách nhận diện qua trace

• Lỗi định tuyến (routing): router phân loại sai nhánh. Dấu hiệu trên trace: bước đầu tiên (router) trả nhãn không khớp với ý khách. Sửa ở role prompt của router hoặc bổ sung nhãn mới.
• Lỗi gọi tool (tool-call): agent truyền tham số sai hoặc gọi nhầm tool. Dấu hiệu: một bước có tool trả về lỗi hoặc dữ liệu vô lý. Sửa ở description/validate tool.
• Lỗi vòng lặp (loop): trace dài bất thường, cùng cặp agent lặp lại. Sửa ở orchestration (max steps, điều kiện thoát).

Biết loại lỗi giúp bạn sửa đúng tầng thay vì vá lung tung.

Thiết lập cảnh báo (alerting) chủ động

Đừng chờ khách phàn nàn mới biết đội hỏng. Đặt cảnh báo tự động khi metric vượt ngưỡng, ví dụ:

ALERT nếu guardrail_hit_rate > 10% trong 1 giờ   -> có thể bị tấn công injection
ALERT nếu escalation_rate tăng > 1.5x so tuần trước -> agent đang mất năng lực tự xử
ALERT nếu cost_per_task > 2x ngưỡng               -> có task ngốn token bất thường

Cảnh báo biến giám sát từ thụ động (xem dashboard khi rảnh) thành chủ động (được báo ngay khi có bất thường).

Quy trình gỡ lỗi khi đội sai

• Lấy trace_id của request lỗi.
• Đọc trace để xác định agent/tool nào tạo ra output sai đầu tiên (root cause, không phải triệu chứng).
• Phân loại lỗi: sai định tuyến? sai gọi tool? guardrail chặn nhầm? prompt mơ hồ?
• Tái hiện lỗi bằng một test case tối thiểu.
• Sửa ở đúng tầng (prompt / tool / orchestration / guardrail).
• Thêm test case đó vào bộ regression để không tái phát.
• Theo dõi metric sau khi sửa để xác nhận cải thiện.

Checklist giám sát

• [ ] Đã định nghĩa metric cho cả 4 nhóm
• [ ] Mỗi metric có mục tiêu (target) rõ
• [ ] Mọi request sinh trace đầy đủ bước
• [ ] Có dashboard theo dõi xu hướng
• [ ] Có bộ regression test tích lũy
• [ ] Có cảnh báo khi metric vượt ngưỡng

Sai lầm thường gặp

• Chỉ đo chất lượng, quên chi phí: đội chính xác 95% nhưng tốn 20.000đ/task → không bền vững. Đo cả bốn nhóm.
• Không có trace: khi đội sai, debug bằng cách đoán → mất hàng giờ. Trace là bắt buộc.
• Sửa triệu chứng, không sửa gốc: vá output cuối mà không tìm agent gây lỗi → lỗi quay lại ở dạng khác.
• Không tích lũy regression test: sửa xong lỗi cũ tái phát sau vài tuần.
• Metric không có mục tiêu: "resolution 82%" tự nó vô nghĩa nếu không biết ngưỡng chấp nhận là bao nhiêu.