Bài 8 — Giám sát production

Ship xong không phải là hết — đó là lúc bắt đầu. Agent trong production gặp input lạ, traffic tăng đột biến, model nhà cung cấp âm thầm đổi hành vi. Bài này biến observability thành hệ thống giám sát chủ động: bạn biết trước khi khách phàn nàn.

Bốn nhóm chỉ số phải theo dõi

• Chất lượng: điểm LLM-judge trên sample traffic, tỉ lệ 👎, tỉ lệ escalate sang người.
• Độ tin cậy: tỉ lệ lỗi tool, tỉ lệ trace lỗi, tỉ lệ hết vòng lặp (agent bỏ cuộc).
• Hiệu năng: p50/p95/p99 latency, số bước trung bình mỗi trace.
• Chi phí: token/ngày, chi phí/request, top trace đắt nhất.

Bước 1 — Dựng dashboard

• Tạo dashboard trên nền tảng (LangSmith/Langfuse có sẵn charts; Braintrust có view monitoring).
• Vẽ 4 nhóm chỉ số trên theo thời gian.
• Chia nhỏ theo prompt_version, feature, environment để so sánh nhánh.
• Ghim biểu đồ "chi phí/ngày" và "tỉ lệ lỗi tool" — hai thứ hay cháy nhất.

Bước 2 — Eval online (chấm điểm traffic thật)

Bạn không chấm 100% traffic (đắt). Thay vào đó:

# giả mã: chấm 5% traffic bằng LLM-judge chạy nền
if random.random() < 0.05:
    score = llm_judge(question, answer, reference)
    platform.create_score(trace_id=tid, name="factuality", value=score)

Mẫu sample này cho bạn xu hướng chất lượng thật, phát hiện "drift" khi input người dùng đổi hoặc model đổi.

Bước 3 — Đặt cảnh báo (alerting)

Dashboard chỉ hữu ích khi bạn nhìn. Cảnh báo tự tìm bạn:

Cảnh báo mẫu (gửi Slack/Telegram/email):
- error_rate (5 phút) > 5%            -> khả năng tool/API hỏng
- p95_latency > 8s                    -> nghẽn hoặc vòng lặp
- factuality_score_avg (1 giờ) < 0.75 -> chất lượng tụt / drift
- cost_per_hour > ngưỡng $X           -> có thể vòng lặp tốn token
- thumbs_down_rate > 15%              -> người dùng bất mãn

Bước 4 — Quy trình điều tra sự cố (runbook)

Khi cảnh báo nổ, đừng hoảng — theo runbook:

• Khoanh vùng: lọc trace trong khung giờ cảnh báo, theo error=true hoặc điểm thấp.
• Đọc trace đại diện: mở 5–10 trace lỗi, tìm điểm chung (cùng tool? cùng loại câu hỏi? cùng prompt_version?).
• Định vị span hỏng: lỗi ở retriever, tool, hay LLM reasoning?
• Đối chiếu thời điểm: có deploy nào, đổi model nào, tăng traffic nào trùng khớp?
• Giảm đau trước (rollback prompt/model, tắt tool lỗi) rồi mới sửa gốc.
• Biến sự cố thành ca eval: thêm ca lỗi vào dataset để không tái diễn (đóng vòng lặp bài 1).

Bước 5 — Bảo mật & quyền riêng tư

• Che PII trước khi gửi trace (email, SĐT, số thẻ) — dùng masking/redaction.
• Nếu dữ liệu không được rời hạ tầng → chọn self-host (Langfuse).
• Đặt retention (thời gian lưu trace) hợp lý để giảm rủi ro và chi phí.

Checklist vận hành production

• [ ] Dashboard 4 nhóm chỉ số, chia theo phiên bản.
• [ ] Eval online sample % traffic đang chạy.
• [ ] Ít nhất 4 cảnh báo (lỗi, latency, chất lượng, chi phí) gắn kênh thông báo.
• [ ] Runbook điều tra sự cố viết sẵn, cả team biết.
• [ ] PII được che; retention và quyền truy cập được cấu hình.
• [ ] Cơ chế đưa lỗi production trở lại dataset eval.

Sai lầm thường gặp

• Chỉ có dashboard, không có cảnh báo: sự cố xảy ra lúc 2h sáng và không ai biết.
• Cảnh báo quá nhạy (alert fatigue): nổ liên tục rồi cả team tắt thông báo, bỏ sót cái thật.
• Không sample eval online: bạn thấy latency/chi phí nhưng mù về chất lượng thực tế đang tụt.
• Không đóng vòng lặp: sửa sự cố xong quên biến nó thành ca eval → lỗi quay lại.
• Log PII thô: vi phạm tuân thủ, rủi ro pháp lý.
• Bỏ quên chi phí: một agent lặp vòng có thể âm thầm đốt ngân sách cho tới cuối tháng mới lộ.

Hết khóa. Bạn giờ có vòng đời đầy đủ: gắn trace → quan sát → dựng dataset → eval → so sánh & ship an toàn → giám sát production → đóng vòng lặp. Đó là khác biệt giữa một demo may rủi và một agent đáng tin cậy trong thực chiến.