Vòng phản hồi, kỳ vọng của các bên và SLA

Giữa dự án, các bên liên quan bắt đầu than "trợ lý chậm quá". Bạn có thể tối ưu ngay, có thể giải thích rằng mô hình ngôn ngữ vốn vậy, hoặc có thể mở bảng số đo ra cùng họ xem. Chỉ cách cuối giữ được lòng tin, và nó chỉ làm được nếu từ đầu đã có một cam kết đo được.

Bài này giúp bạn trả lời: thống nhất kỳ vọng và cam kết mức dịch vụ (SLA, service level agreement) với các bên thế nào, và giữ chúng khớp với thực tế suốt dự án ra sao?

Ví dụ xuyên suốt: chuỗi rạp chiếu phim

Một chuỗi rạp chiếu phim đang chạy thử trợ lý chat trên app ở 5 rạp: trả lời lịch chiếu, giá vé, chính sách đổi vé, và giữ chỗ giúp khách. Sau một tối thứ Sáu đông khách, giám đốc vận hành nhận vài lời phàn nàn và muốn hợp đồng ghi "trợ lý luôn trả lời ngay, không bao giờ ngừng" trước khi mở rộng ra 40 rạp, đúng dịp mở bán vé một phim bom tấn. Cùng tuần đó, giám đốc marketing muốn thêm tính năng gợi ý phim theo sở thích vào đợt chạy thử.

SLA phải đo được

"Luôn trả lời ngay" là một mong muốn, chưa phải SLA. Một SLA dùng được trong vận hành có bốn phần:

Thiếu khoảng thời gian thì không ai biết một tối thứ Sáu chậm có tính là vi phạm hay không. Thiếu việc phải làm thì vi phạm xong cũng không có gì xảy ra.

Docs của Anthropic về tiêu chí thành công cũng nhắc rằng hầu hết ứng dụng cần đánh giá trên nhiều mặt cùng lúc, trong đó có độ trễ và chi phí bên cạnh chất lượng. Vì vậy, trước khi ký SLA, các bên nên thống nhất cả những chỉ số đi kèm: tỉ lệ trả lời đúng lịch chiếu trên bộ câu hỏi kiểm thử, tỉ lệ cuộc chat phải chuyển cho nhân viên, chi phí mỗi cuộc chat. Một SLA chỉ về tốc độ có thể đạt trong khi trợ lý trả lời sai giờ chiếu.

Cam kết của bạn dựa trên cam kết bạn nhận được

Trợ lý của bạn gọi Claude API, nên SLA bạn ký không thể mạnh hơn những gì API cam kết, trừ khi bạn có đường lùi. Đây là những gì docs của Anthropic nói:

Thêm một điều ít người để ý: trang hỗ trợ của Anthropic nói giới hạn do thiếu dung lượng không phải là sự cố, và sẽ không hiện trên trang trạng thái status.claude.com. Trang trạng thái chỉ báo các sự cố kỹ thuật thật. Muốn biết trợ lý của mình có giữ được SLA hay không, bạn phải tự đo.

Trong ví dụ, câu trả lời cho "không bao giờ ngừng" là một đề xuất cụ thể: SLA tính trên trải nghiệm của khách, kể cả khi Claude không trả lời được. Khi API báo lỗi, app hiện lịch chiếu lấy thẳng từ hệ thống bán vé kèm nút gọi tổng đài. Trước ngày mở bán phim bom tấn, nhóm đo đỉnh lưu lượng của tối thứ Sáu, xin nâng hạn mức, và mở rộng từ 5 lên 40 rạp theo từng đợt chứ không bật một lần.

Khi các bên lo lắng: đưa số đo, rồi thương lượng

Giám đốc vận hành lo vì vài lời phàn nàn. Hai việc làm cho kỳ vọng khớp lại với thực tế:

1. Đưa số đo so với ngưỡng đã thống nhất: p50 và p95 độ trễ đo được, đặt cạnh ngưỡng SLA. Trong ví dụ: p50 là 0,9 giây, p95 là 2,6 giây, vượt ngưỡng 2 giây chủ yếu ở các câu hỏi về đổi vé, loại câu cần tra nhiều thông tin.
2. Sửa SLA cùng các bên nếu ngưỡng hiện tại không đạt được trong điều kiện thật. Ví dụ tách thành hai ngưỡng: câu hỏi lịch chiếu và giá vé dưới 2 giây, câu hỏi đổi vé dưới 4 giây kèm dòng "đang kiểm tra vé của bạn".

Yêu cầu phát sinh cũng xử lý theo tinh thần đó. Gợi ý phim theo sở thích là một nhu cầu chính đáng, nhưng thêm vào giữa đợt chạy thử sẽ đẩy lùi ngày mở rộng. Cách làm: ghi nhận yêu cầu, nói rõ tác động lên phạm vi và tiến độ, rồi đưa các lựa chọn để người yêu cầu tự chọn: để sang đợt sau, bỏ bớt một việc khác, hoặc lùi ngày mở rộng.

Vòng phản hồi có nhịp

Kỳ vọng không thống nhất một lần là xong. Lưu lượng, khách hàng, model đều thay đổi, nên giả định ban đầu cũng phải được xem lại.

Một buổi phản hồi có ích khi:

• Có chương trình họp tập trung, và tài liệu (bảng số đo, các cuộc chat mẫu) được gửi trước buổi họp để mọi người chuẩn bị.
• Quyết định và việc cần làm được ghi lại bằng văn bản, mỗi việc có người phụ trách và hạn.

Ngoài từng buổi họp, cả quy trình cần:

• Nhịp xem lại cố định cho kỳ vọng và giả định. Trong ví dụ: hai tuần một lần trong lúc chạy thử, mỗi tháng một lần sau khi mở rộng.
• Giải quyết công khai khi các bên có ý kiến khác nhau. Giám đốc vận hành muốn trợ lý chuyển cho nhân viên sớm, giám đốc marketing muốn trợ lý giữ khách lâu hơn. Đặt hai ý đó cạnh nhau, cùng số liệu, và chốt một quy tắc. Lờ đi cho buổi họp êm thì bất đồng sẽ quay lại ở lần sau.

Một phần của nhịp xem lại là báo trước những thay đổi từ phía Anthropic. Docs về vòng đời model chia bốn trạng thái: đang dùng (Active), cũ (Legacy, không cập nhật nữa), sắp ngừng (Deprecated, đã có ngày ngừng và model thay thế), và đã ngừng (Retired, gọi tới là lỗi). Với model đã phát hành công khai, Anthropic báo qua email cho khách đang dùng ít nhất 60 ngày trước ngày ngừng. Trong ví dụ, nhóm ghi vào kế hoạch: ai nhận email đó, trong bao lâu báo cho các bên, và lịch chạy lại bộ kiểm thử với model thay thế. Trang trạng thái cũng nên có người theo dõi để báo sớm khi có sự cố thật.

Phân biệt xuống cấp thật với dao động bình thường

Một tối chậm hay một câu trả lời sai chưa chắc là hệ thống xuống cấp. Model có tính ngẫu nhiên: cùng câu hỏi, chạy hai lần có thể ra hai kết quả. Bài viết về đánh giá agent của Anthropic phân biệt hai cách đo: tỉ lệ làm được ít nhất một lần trong k lần thử (pass@k) và tỉ lệ cả k lần đều làm được (pass^k). Với trợ lý khách hàng, khách mong lần nào cũng đúng, nên pass^k mới là con số đáng báo.

Trước khi báo động hay hứa sửa, kiểm vài điều:

• So trên cùng khoảng thời gian của SLA (28 ngày), không phải một buổi tối.
• So với mức nền đã đo khi bắt đầu, trên cùng bộ câu hỏi kiểm thử, chạy nhiều lần. Cách tính khoảng tin cậy cho các lần chạy có ở bài 4.3.
• Xem thay đổi có trùng với một sự kiện không: mở thêm rạp, đổi prompt, đổi model, lưu lượng tăng vọt.

1. Số đo vượt ngưỡng trên cả khoảng thời gian của SLA?Vi phạm thật: làm đúng việc đã ghi trong SLA
2. Lệch khỏi mức nền ngoài khoảng dao động của các lần chạy?Tìm nguyên nhân, báo các bên kèm số đo
3. Chỉ một buổi hay vài cuộc chat lẻ?Ghi lại, theo dõi tiếp, chưa đổi hệ thống
4. Còn lạiBáo trong buổi phản hồi định kỳ