Khi agent sai lần đầu trước mặt người dùng: nói gì, sửa gì

Thử hình dung: ba ngày sau go-live, agent hỗ trợ bạn triển khai cho một chuỗi bán lẻ điện tử trả lời một người dùng rằng họ được đổi trả trong 60 ngày. Chính sách thật chỉ có 30 ngày. Người dùng chụp màn hình, và tấm ảnh đó đang nằm trong kênh chat của ban giám đốc bên khách.

FDE nào triển khai agent cũng nên chuẩn bị trước cho khoảnh khắc này. Model có lúc sai là chuyện gần như chắc chắn. Câu hỏi thật là trong vài giờ đầu bạn nói gì, sửa gì, và làm sao để khách vẫn muốn mở rộng deployment thay vì rút lại.

Vì thế, đây là kỹ năng đáng luyện từ trước ngày go-live, chứ không đợi đến lúc sự cố xảy ra mới học. Nếu bạn đang chuẩn bị phỏng vấn FDE, một sự cố từng xử lý tốt cũng là câu chuyện đáng có sẵn trong đầu.

Lỗi của agent là lời của chính khách hàng

Trước khi soạn tin nhắn nào, bạn cần hiểu ai chịu trách nhiệm. Trong vụ Moffatt kiện Air Canada, Civil Resolution Tribunal, cơ quan tài phán dân sự ở British Columbia, bác lập luận rằng chatbot tách biệt khỏi hãng. Quyết định viết rằng chatbot dù có tính tương tác thì vẫn chỉ là một phần website của Air Canada.

Cơ quan này đi xa hơn: hãng phải chịu trách nhiệm về mọi thông tin trên website của mình, và Air Canada đã không cẩn trọng hợp lý để bảo đảm chatbot trả lời chính xác.

Hệ quả cho FDE rất rõ. Câu “AI đôi khi bị ảo giác” không bào chữa được gì. Với người dùng cuối, agent nói thay khách hàng của bạn. Với khách hàng, agent nói thay bạn.

Vụ của Anysphere, công ty làm Cursor, cho thấy một agent có thể bịa ra cả một chính sách. Bot hỗ trợ tên Sam khẳng định mỗi gói đăng ký chỉ dùng được trên một thiết bị, gọi đó là một chính sách bảo mật cốt lõi.

Thực tế không có quy định nào như vậy, nhưng người dùng đã nghe điều đó từ chính kênh hỗ trợ của sản phẩm.

Giờ đầu tiên: chặn, đo, rồi mới nói

Việc đầu tiên là chặn, chưa cần giải thích. Trong ví dụ bán lẻ, bạn tắt riêng chủ đề đổi trả: mọi câu hỏi có chữ “đổi”, “trả”, “hoàn tiền” được chuyển sang nhân viên. Agent vẫn chạy cho các chủ đề còn lại, nên khách không phải chọn giữa “tắt hết” và “để nguyên”.

Việc thứ hai là đo phạm vi. Lục log mọi hội thoại về đổi trả kể từ go-live và lọc những câu trả lời có nhắc đến một con số ngày. Kết quả là danh sách người cần liên hệ, và đó cũng là con số đầu tiên người phụ trách bên khách sẽ hỏi bạn.

Đến lúc này mới nói. Hướng dẫn của một nhà cung cấp AI chăm sóc khách hàng là nội dung tiếp thị, nên cần đọc thận trọng, nhưng công thức ba phần họ gợi ý cho tin nhắn sau một câu trả lời sai rất hợp lý: thừa nhận chuyện đã xảy ra, sửa lại thông tin, đề xuất cách bù đắp riêng cho từng người.

Bỏ phần nào thì tin nhắn hỏng phần đó.

Lời đính chính của Anysphere là mẫu đáng học vì nó ngắn. Họ nói thẳng điều bot nói là sai: người dùng được tự do dùng Cursor trên nhiều máy. Họ cũng nói đang tìm nguyên nhân thật, có thể là một lỗi phiên đăng nhập sinh ra từ các bản cập nhật bảo mật. Không vòng vo, không đổ cho “trí tuệ nhân tạo”.

Với ví dụ bán lẻ, tin nhắn gửi người phụ trách bên khách trong giờ đầu có thể như sau:

Chủ đề: Agent trả lời sai thời hạn đổi trả, đã chặn lúc [giờ]

Chuyện gì đã xảy ra: từ [ngày] đến [giờ], agent nói thời hạn đổi trả là 60 ngày.
Chính sách đúng là 30 ngày.
Phạm vi: [N] hội thoại, danh sách đính kèm.
Đã làm: chủ đề đổi trả đã chuyển sang nhân viên, các chủ đề khác vẫn chạy bình thường.
Đề xuất cho người dùng bị ảnh hưởng: [cách bù đắp], cần anh/chị duyệt.
Tiếp theo: nguyên nhân và bản sửa gửi trước [giờ]; số đo theo dõi gửi sau 72 giờ.

Chú ý dòng “cần anh/chị duyệt”. Cách bù đắp cho người dùng là quyết định kinh doanh của khách. Bạn đề xuất, khách quyết.

Sửa hệ thống, đừng tìm người để trách

Khi cơn nóng qua đi, áp lực tìm “ai làm hỏng” sẽ đến. Sách SRE của Google định nghĩa một postmortem thật sự blameless là postmortem tập trung vào các nguyên nhân góp phần, không đổ lỗi cho cá nhân hay nhóm. Sách viết rằng bạn không “sửa” được con người, nhưng sửa được hệ thống và quy trình để giúp con người chọn đúng.

Lý do không chỉ là chuyện tử tế. SRE Workbook cảnh báo văn hóa đổ lỗi làm các nhóm ngại rủi ro vì sợ bị bêu tên trước mọi người, và họ có thể giấu chính những chi tiết cần để lỗi không lặp lại. Nếu kỹ sư bên khách sợ bị trách, bạn sẽ không bao giờ biết ai đã tải tài liệu nào lên index.

Áp vào ví dụ bán lẻ, giả sử lần ngược lại bạn tìm ra ba nguyên nhân góp phần. Một bản chính sách cũ ghi 60 ngày vẫn nằm trong index RAG. Bộ eval không có case nào về thời hạn đổi trả. Không có cảnh báo nào khi agent nêu một con số chính sách.

Mỗi nguyên nhân cần một bản sửa riêng: gỡ tài liệu cũ và gắn ngày hiệu lực cho tài liệu chính sách, thêm eval case cho từng con số, dựng một bộ kiểm tra đối chiếu mọi con số agent nêu với nguồn chuẩn.

Những sai lầm khiến lần sai đầu thành lần sai cuối

Sai lầm phổ biến nhất là đổ cho model. Vụ Air Canada cho thấy lập luận đó không đứng vững trước cơ quan tài phán, và trong phòng họp với khách nó còn yếu hơn. Sai lầm thứ hai, ngược lại, là đổ cho một người: bạn được một cái tên nhưng mất luôn những sự thật cần để sửa.

Sai lầm thứ ba là âm thầm sửa rồi coi như chưa có gì. Người dùng đã nhận thông tin sai vẫn đang làm theo thông tin đó. Sai lầm thứ tư là tuyên bố “đã xong” trước khi có số đo, rồi lỗi quay lại đúng tuần sau.

Sai lầm thứ năm là bù đắp đồng loạt một kiểu cho tất cả, trong khi người đã mất tiền và người chỉ đọc nhầm cần hai cách xử lý khác nhau.

Lòng tin quay lại khi có số đo

Lời xin lỗi mở được cửa, nhưng lòng tin chỉ quay lại khi khách thấy số đo. Postmortem tháng 9/2025 của Anthropic về ba sự cố chất lượng là một ví dụ nhận lỗi thẳng. Họ nhắc lại cam kết về chất lượng, rồi viết rằng trong các sự cố gần đây họ đã không đạt chuẩn ấy.

Phần đáng học hơn là bản sửa cụ thể về phát hiện lỗi. Anthropic cam kết chạy các bài đánh giá chất lượng liên tục trên chính hệ thống production thật để bắt lỗi, chứ không chỉ chạy trước khi phát hành. Với FDE, đó là khác biệt giữa “eval đã pass hôm go-live” và “eval vẫn pass sáng nay”.

Hướng dẫn của nhà cung cấp kể trên khuyên theo dõi điểm faithfulness của cụm chủ đề bị ảnh hưởng trong 48 đến 72 giờ sau bản sửa để chắc nó giữ được. Trong ví dụ bán lẻ, bạn chỉ mở lại chủ đề đổi trả khi các eval case mới pass. Sau đó gửi khách biểu đồ 72 giờ cùng postmortem một trang.

Đừng giữ postmortem trong nhóm mình. SRE Workbook khuyên chủ động chia sẻ postmortem càng rộng càng tốt, kể cả với khách hàng. Một tài liệu ghi rõ nguyên nhân, bản sửa và số đo thường làm người phụ trách bên khách yên tâm hơn mọi cuộc gọi trấn an.

Chính những con số trong runbook ấy cũng là cách kể sự cố trong CV hay buổi phỏng vấn: chặn sau bao lâu, bao nhiêu hội thoại bị ảnh hưởng, eval case mới đã bắt được gì sau đó. Ghi “xử lý sự cố” chung chung thì không ai nhớ.

Lần sai đầu tiên của agent là lần đầu khách thấy bạn làm việc lúc mọi thứ không suôn sẻ. Nếu bạn chặn nhanh, nói thật và mang số đo đến, nhiều khách sẽ tin bạn hơn cả trước khi sự cố xảy ra.