Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 8 — Vận hành sản xuất: đo lường, giám sát và cải thiện liên tục

Đã đọc 0/8 mục · còn khoảng 3 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Đưa voice agent lên sản xuất mới là lúc việc khó bắt đầu. Bài này về đo lường, giám sát, xử lý sự cố và vòng lặp cải thiện — thứ phân biệt demo với hệ thống thật.

Các chỉ số phải theo dõi

  • Độ trễ theo khối: TTFB của ASR, LLM (time-to-first-token), TTS (time-to-first-audio), và end-to-end. Theo dõi p50/p95/p99, không chỉ trung bình.
  • WER trên mẫu transcript thật (lấy mẫu định kỳ).
  • Tỷ lệ hoàn thành nhiệm vụ (task success rate): bao nhiêu cuộc gọi đạt mục tiêu (đặt được lịch, giải quyết được yêu cầu).
  • Tỷ lệ escalation: bao nhiêu phải chuyển người thật.
  • Barge-in rate và interruption errors: khách ngắt nhiều = agent nói dài hoặc chậm.
  • Chi phí trên mỗi cuộc hội thoại.
Dashboard tối thiểu:
- latency p95 (asr / llm / tts / e2e)   ← trễ nghẽn ở đâu?
- task_success_rate                     ← agent có hữu ích?
- escalation_rate                       ← khi nào cần người thật?
- wer_sampled                           ← ASR còn nghe đúng?
- cost_per_session

Quan sát được (observability)

Ghi log có cấu trúc cho mỗi lượt: timestamp từng khối, transcript in/out, tool call + kết quả, trạng thái state machine. Có session ID xuyên suốt để lần theo một cuộc gọi. Không có log này, bạn không thể debug "tại sao cuộc gọi lúc 3h chiều bị đơ".

Các bước dựng observability:

  • Gắn trace ID cho mỗi session, propagate qua mọi khối.
  • Log latency từng bước dạng số để tính percentile.
  • Lưu audio (nếu chính sách cho phép) để nghe lại ca lỗi.
  • Dựng alert khi p95 latency vượt ngưỡng hoặc task_success giảm.

Xử lý lỗi và fallback

Mọi khối đều có thể hỏng. Thiết kế fail-safe:

  • ASR không nghe ra → "Xin lỗi mình chưa nghe rõ, mình nói lại giúp em nhé?" (tối đa 2 lần rồi escalate).
  • LLM timeout → câu trả lời an toàn + thử lại một lần, sau đó escalate.
  • TTS lỗi → phát audio dự phòng đã cache hoặc chuyển kênh text.
  • Tool lỗi → xin lỗi, đề xuất phương án khác, không bịa kết quả.
Nguyên tắc: fail sang người thật hoặc câu an toàn, không bao giờ để im lặng hoặc bịa.

Vòng lặp cải thiện

  • Lấy mẫu các cuộc gọi thất bại/escalation hằng tuần.
  • Phân loại nguyên nhân: ASR sai? Prompt yếu? Tool lỗi? Trễ cao?
  • Sửa có mục tiêu: thêm phrase hints, tinh chỉnh prompt, tối ưu tool.
  • A/B test thay đổi trước khi rollout toàn bộ.
  • Đo lại chỉ số, lặp.

Khung tư duy: SLO cho voice agent

  • Latency SLO: p95 e2e dưới mục tiêu (ví dụ 900ms).
  • Quality SLO: task_success_rate trên ngưỡng (ví dụ 85%).
  • Safety SLO: 0 hành động ghi thực hiện mà không xác nhận.
Vi phạm SLO → alert → điều tra theo log.

Checklist go-live

  • [ ] Dashboard latency p95 theo khối?
  • [ ] Log có session ID xuyên suốt?
  • [ ] Fallback cho từng khối + escalation?
  • [ ] Xác nhận cho mọi hành động ghi?
  • [ ] Cơ chế lấy mẫu và review hằng tuần?
  • [ ] Alert khi vượt SLO?
  • [ ] Kiểm tra quyền riêng tư/lưu trữ audio hợp lệ?

Sai lầm thường gặp

  • Chỉ đo latency trung bình. p99 mới lộ ra trải nghiệm tệ; khách ở đuôi phân phối là người bỏ đi.
  • Không có session trace. Debug sự cố thành mò kim đáy bể.
  • Để agent bịa khi tool lỗi. Nguy hiểm hơn cả việc thừa nhận không làm được.
  • Rollout thẳng không A/B. Một thay đổi prompt tưởng tốt có thể làm giảm task success.
  • Không review dữ liệu thật. Agent trôi dạt theo thời gian (ngôn ngữ khách đổi, sản phẩm mới) mà không ai biết.
Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi