Giám sát AI khi đang chạy là theo dõi liên tục những gì đi vào hệ thống, những gì nó trả ra, những hành động nó làm và những gì nó tiêu tốn, để biết sớm khi nó bắt đầu sai. Kiểm định trước khi phát hành cho biết hệ thống tốt tới đâu trên những bài thử mình nghĩ ra; giám sát sau phát hành cho biết nó cư xử thế nào với những thứ không ai nghĩ ra.
Khác với phần mềm thường, AI hiếm khi hỏng ồn ào. Máy chủ vẫn chạy, câu trả lời vẫn ra đều, giọng văn vẫn lễ phép, chỉ có nội dung sai dần đi. Vì vậy những chỉ số quen thuộc như máy có sống không, phản hồi có nhanh không, không đủ để biết AI có đang làm đúng việc.
Vì sao AI cần giám sát kiểu khác
Một trang web bán hàng bị lỗi thì khách thấy trang trắng, hệ thống cảnh báo kêu ngay. Một chatbot tư vấn bị lỗi thì vẫn trả lời trôi chảy, chỉ là nó bắt đầu nói sai chính sách đổi trả, hoặc khẳng định một chương trình khuyến mãi đã hết. Không có mã lỗi nào được ghi lại. Người phát hiện thường là khách, qua một cuộc gọi khiếu nại.
Nguyên nhân sai cũng đa dạng hơn. Có khi do dữ liệu thay đổi: công ty đổi bảng giá nhưng tài liệu mà chatbot tra cứu chưa cập nhật. Có khi do người dùng thay đổi: một mùa cao điểm du lịch ở Đà Nẵng, khách hỏi bằng tiếng Anh, tiếng Hàn nhiều hơn hẳn, và chất lượng trả lời ở các thứ tiếng đó kém hơn tiếng Việt. Có khi do nhà cung cấp cập nhật mô hình phía sau mà không báo trước. Giới kỹ thuật gọi chung hiện tượng đầu vào thay đổi theo thời gian là dữ liệu trôi.
Có cả những thay đổi cố ý: người dùng thử đủ cách để chatbot nói điều nó không nên nói, hoặc dùng nó cho việc ngoài mục đích. Những cuộc thử như vậy để lại dấu vết trong nhật ký, nếu có người nhìn.
Vì thế giám sát AI phải theo dõi nội dung chứ không chỉ theo dõi máy. Đó là phần khó và tốn công, vì đánh giá nội dung đúng hay sai thường cần người hiểu nghiệp vụ, không đo được bằng một con số đơn giản.
Cần ghi lại những gì
Đầu vào đầy đủ. Câu hỏi của người dùng, kèm phần lời nhắc hệ thống và tài liệu được đưa vào cùng lúc, vì lỗi thường nằm ở tài liệu chứ không ở câu hỏi.
Đầu ra đầy đủ. Nguyên văn câu trả lời, không chỉ bản tóm tắt.
Mọi lời gọi công cụ. Với tác tử, ghi tên công cụ, tham số, kết quả trả về, thời điểm. Đây là phần quan trọng nhất khi điều tra sự cố.
Phiên bản. Phiên bản mô hình, phiên bản lời nhắc, phiên bản kho tài liệu. Không có thì không biết lỗi xuất hiện từ lúc đổi cái gì.
Phản hồi của người dùng. Nút thích, không thích, câu "sai rồi", việc người dùng hỏi lại cùng một câu nhiều lần.
Chuyển cho người. Khi nào hội thoại được chuyển sang nhân viên, và vì sao.
Chi phí và độ dài. Số lượng chữ xử lý, thời gian phản hồi, số lần gọi lại. Tăng đột ngột thường báo hiệu có gì bất thường.
Các lần bị chặn. Khi bộ lọc an toàn chặn đầu vào hay đầu ra, ghi lại để biết người ta đang thử gì.
Thông tin cá nhân được che. Nhật ký cần đủ để điều tra nhưng phải che số điện thoại, số căn cước, số tài khoản của khách.
Thời hạn lưu. Quy định rõ lưu bao lâu, ai được xem, xoá thế nào. Nhật ký AI chứa nhiều dữ liệu nhạy cảm hơn nhật ký phần mềm thường.
Lưu ở nơi riêng. Nhật ký được gửi sang hệ thống lưu trữ riêng mà chính ứng dụng AI không sửa hay xoá được.
Những chỉ số nên theo dõi và dấu hiệu bất thường
Tỷ lệ chuyển cho người. Tăng lên nghĩa là hệ thống đang gặp nhiều câu nó không xử lý được.
Tỷ lệ phản hồi tiêu cực. Theo dõi theo ngày và theo chủ đề. Một chủ đề đột ngột bị chê nhiều thường do tài liệu nguồn đã lỗi thời.
Tỷ lệ từ chối trả lời. Tăng quá cao là hệ thống đang quá rụt rè, giảm bất thường có thể là bộ lọc đã bị vô hiệu hoá.
Phân bố chủ đề câu hỏi. Chủ đề mới xuất hiện nhiều là dấu hiệu dữ liệu trôi, cần kiểm tra hệ thống có trả lời đúng mảng đó không.
Phân bố ngôn ngữ. Tỷ lệ câu hỏi tiếng nước ngoài, tiếng địa phương, viết không dấu thay đổi theo mùa và theo kênh.
Độ dài câu trả lời. Đột ngột dài ra hay ngắn lại sau một lần cập nhật thường là dấu hiệu hành vi đã đổi.
Câu trả lời trích nguồn. Với hệ thống tra cứu tài liệu, tỷ lệ câu có dẫn nguồn và nguồn đó có thật sự chứa thông tin hay không.
Hành động bất thường của tác tử. Gọi một công cụ nhiều hơn hẳn mọi khi, truy cập dữ liệu ngoài phạm vi quen thuộc, chạy vào giờ không ai làm việc.
Chi phí trên mỗi phiên. Tăng đột ngột có thể do vòng lặp lỗi, tác tử gọi đi gọi lại một công cụ không dừng.
Lặp lại cùng một câu hỏi. Người dùng hỏi lại nhiều lần thường là câu trả lời đầu không giúp được gì.
Khác biệt sau mỗi lần cập nhật. So chỉ số tuần trước và tuần sau mỗi lần đổi mô hình, đổi lời nhắc, đổi tài liệu.
Chấm mẫu ngẫu nhiên: việc nhàm chán mà không thay được
Chỉ số cho biết chỗ nào nên nhìn, nhưng không cho biết câu trả lời đúng hay sai. Cách đáng tin nhất vẫn là có người hiểu nghiệp vụ đọc một mẫu hội thoại ngẫu nhiên mỗi tuần và chấm theo một bảng tiêu chí cố định: đúng thông tin chưa, có bịa không, có làm điều không được phép không, giọng có phù hợp không.
Mẫu phải ngẫu nhiên thật. Nếu chỉ đọc những hội thoại bị khách chê, mình sẽ bỏ qua những câu trả lời sai mà khách không biết là sai, và đó thường là loại nguy hiểm nhất. Khách hỏi về điều kiện bảo hành, chatbot trả lời tự tin một điều kiện không có thật, khách tin và không phản hồi gì. Chỉ đọc mẫu ngẫu nhiên mới bắt được loại này.
Nhiều nơi dùng một mô hình khác để chấm sơ bộ hàng nghìn hội thoại, rồi người chỉ đọc những cái bị chấm thấp. Cách này giúp mở rộng quy mô, nhưng nên nhớ mô hình chấm cũng có điểm mù riêng, nhất là với lỗi tinh vi hay lỗi giống lỗi của chính nó. Vẫn cần một phần mẫu do người chấm hoàn toàn để đo xem mô hình chấm có đáng tin không.
Một mẹo nhỏ hữu ích: giữ một bộ câu hỏi cố định, khoảng vài chục câu bao phủ những chủ đề quan trọng, và chạy lại mỗi ngày. Câu trả lời thay đổi mà mình không đổi gì là dấu hiệu có thứ gì phía sau đã đổi.
Cảnh báo sao cho không bị ngợp
Ít cảnh báo nhưng chắc. Mỗi cảnh báo phải dẫn tới một việc cụ thể cần làm. Cảnh báo không ai làm gì sẽ khiến người trực bỏ qua luôn cả cảnh báo thật.
Chia mức khẩn. Mức gọi điện ngay, mức nhắn tin, mức ghi vào báo cáo tuần.
Ngưỡng theo giờ trong ngày. Lưu lượng ban đêm khác ban ngày, so sánh cùng khung giờ thay vì một ngưỡng cố định.
Gộp cảnh báo liên quan. Một sự cố gây ra mười chỉ số lệch thì nên thành một cảnh báo, không phải mười.
Mỗi cảnh báo có người nhận. Ghi rõ ai trực, ai thay khi người đó nghỉ.
Kèm đường dẫn tới ví dụ. Cảnh báo phản hồi tiêu cực tăng nên kèm vài hội thoại cụ thể để người trực xem ngay.
Có sẵn hướng xử lý. Viết trước cho từng loại cảnh báo: kiểm gì, tắt gì, báo ai.
Rà cảnh báo hằng tháng. Cảnh báo kêu mà không có sự cố thật thì chỉnh ngưỡng, sự cố thật mà không có cảnh báo thì thêm.
Tách cảnh báo kỹ thuật và cảnh báo nội dung. Máy chủ chậm là việc của kỹ sư hạ tầng, câu trả lời sai chính sách là việc của người nghiệp vụ.
Tập xử lý giả lập. Thỉnh thoảng tạo một sự cố giả trên môi trường thử để xem cảnh báo có kêu và người trực có biết làm gì không.
Ghi lại sau mỗi sự cố. Viết ngắn: chuyện gì xảy ra, phát hiện sau bao lâu, sửa thế nào, lần sau cần đo thêm gì.
Câu hỏi thường gặp
Giám sát AI khác kiểm định AI thế nào?
Kiểm định diễn ra trước khi phát hành, dùng bộ bài thử chuẩn bị sẵn. Giám sát diễn ra liên tục sau khi phát hành, theo dõi hệ thống với người dùng thật và tình huống thật. Hai việc bổ sung cho nhau, không thay nhau được.
Dữ liệu trôi là gì?
Là hiện tượng dữ liệu đi vào hệ thống thay đổi dần so với lúc hệ thống được xây dựng và thử nghiệm, ví dụ người dùng hỏi chủ đề mới hay viết theo kiểu mới. Khi đó chất lượng có thể giảm dù không ai sửa gì.
Ghi nhật ký hội thoại có vi phạm quyền riêng tư không?
Có thể, nếu không làm cẩn thận. Cần thông báo cho người dùng, che thông tin cá nhân, giới hạn người được xem và thời hạn lưu. Chi tiết theo quy định từng nơi nên hỏi người có chuyên môn pháp lý.
Doanh nghiệp nhỏ giám sát AI bằng cách nào cho đỡ tốn?
Ghi đầy đủ nhật ký, mỗi tuần dành một giờ đọc ngẫu nhiên vài chục hội thoại, theo dõi số lần chuyển cho nhân viên và số phản hồi tiêu cực. Ba việc này đã bắt được phần lớn lỗi thường gặp.
Có nên dùng AI để chấm câu trả lời của AI không?
Có thể dùng để lọc sơ bộ khi số lượng lớn, nhưng không nên tin hoàn toàn. Mô hình chấm có điểm mù riêng, nên cần một phần mẫu do người chấm để đo độ tin cậy của chính nó.
