Giám sát và ghi log khi dùng model AI trong hệ thống thật

Có một kiểu sự cố âm thầm mà rất nhiều doanh nghiệp chỉ phát hiện ra khi khách hàng đã phàn nàn: chất lượng câu trả lời của trợ lý AI cứ giảm dần sau một bản cập nhật model mà không ai để ý, vì trước giờ chẳng có ai theo dõi con số nào cả. Bài viết này giúp bạn dựng một hệ thống giám sát và ghi log tối thiểu nhưng đủ dùng, để mọi thay đổi bất thường đều được phát hiện trước khi khách hàng là người báo cho bạn biết.

Vì sao giám sát model AI không phải việc tuỳ chọn

Phần mềm truyền thống khi lỗi thường báo lỗi rõ ràng, còn model AI lại có kiểu hỏng rất khác: nó vẫn trả lời trôi chảy, vẫn đúng ngữ pháp, chỉ là câu trả lời dần sai lệch hoặc lệch tông so với trước - loại lỗi mà không hệ thống giám sát hạ tầng thông thường nào bắt được. Nguyên nhân có thể đến từ việc nhà cung cấp âm thầm cập nhật phiên bản model phía sau API mà bạn đang gọi, từ một thay đổi nhỏ trong dữ liệu đầu vào của khách hàng, hoặc từ chính đoạn chỉ dẫn hệ thống bị ai đó chỉnh sửa mà quên kiểm tra lại toàn bộ.

Chính vì vậy, việc dựng một lớp giám sát và ghi log riêng cho model AI giúp bạn nhìn thấy sự cố ở giai đoạn "vài người dùng gặp khó chịu" thay vì chỉ biết đến nó khi đã thành "nhiều khách hàng cùng phàn nàn trên mạng xã hội". Nếu công ty bạn mới bắt đầu tìm hiểu nên chọn model nào trước khi tính đến việc giám sát, bài AI Model là gì và doanh nghiệp nên chọn model nào cho công việc sẽ là điểm bắt đầu phù hợp hơn.

Những chỉ số cần theo dõi hằng ngày

Không cần theo dõi hàng chục chỉ số ngay từ đầu, bạn chỉ cần năm nhóm chỉ số dưới đây là đã đủ để phát hiện phần lớn sự cố thường gặp, sau đó mở rộng dần khi hệ thống lớn hơn.

• Độ trễ phản hồi (latency) - thời gian từ lúc gửi yêu cầu tới lúc nhận đủ câu trả lời, nên theo dõi cả mức trung bình lẫn mức chậm nhất trong 5% trường hợp tệ nhất, vì con số trung bình dễ che giấu những lần khách phải chờ rất lâu.
• Tỷ lệ lỗi và tỷ lệ timeout - số lượt gọi model bị lỗi hệ thống hoặc quá thời gian chờ trên tổng số lượt gọi, tính theo từng giờ để phát hiện được cả những đợt lỗi ngắn mà báo cáo theo ngày sẽ làm loãng đi.
• Chi phí theo token - số token đầu vào/đầu ra và chi phí quy đổi mỗi lượt, giúp bạn phát hiện sớm khi một đoạn chỉ dẫn hệ thống bị phình to bất thường hoặc một luồng nào đó gọi model lặp lại nhiều lần không cần thiết.
• Tỷ lệ fallback/từ chối trả lời - số lần model từ chối, trả lời né tránh hoặc phải chuyển sang model dự phòng, vì tỷ lệ này tăng đột ngột thường là dấu hiệu sớm của một thay đổi phía nhà cung cấp.
• Chất lượng phản hồi theo mẫu chấm điểm - lấy ngẫu nhiên một tỷ lệ nhỏ phản hồi mỗi ngày để con người hoặc một model khác chấm điểm theo bộ tiêu chí cố định, đây là chỉ số duy nhất phản ánh trực tiếp trải nghiệm khách hàng thay vì chỉ đo mặt kỹ thuật.

Nếu công ty bạn đã có bộ test riêng để chấm chất lượng model, chỉ số cuối cùng ở trên nên được ghép trực tiếp vào quy trình đã có trong bài Cách tự đánh giá model AI bằng bộ test của chính doanh nghiệp để không phải xây thêm một hệ thống chấm điểm riêng biệt.

Ghi log an toàn với dữ liệu nhạy cảm

Muốn điều tra lại một câu trả lời sai, bạn gần như bắt buộc phải lưu lại nội dung yêu cầu gốc và câu trả lời của model, nhưng đây cũng chính là chỗ dễ vi phạm quy định bảo vệ dữ liệu cá nhân nhất nếu làm không cẩn thận, vì nội dung khách hàng gửi lên thường lẫn cả tên, số điện thoại hoặc thông tin đơn hàng thật. Cách an toàn hơn là che (mask) các trường dữ liệu nhạy cảm ngay tại tầng ghi log, trước khi bản ghi được lưu vào hệ thống quan sát, thay vì lưu nguyên văn rồi tính chuyện xử lý sau.

Bên cạnh việc che dữ liệu, bạn cũng nên đặt rõ thời gian giữ log (ví dụ 30-90 ngày cho log chi tiết, giữ lâu hơn cho bản tổng hợp đã ẩn danh), phân quyền ai được xem log gốc và cơ chế xoá log theo yêu cầu nếu khách hàng đề nghị - ba việc này nên nằm chung trong quy chế sử dụng AI nội bộ, được bàn kỹ hơn ở bài Xây quy chế sử dụng AI cho nhân viên.

Chọn công cụ quan sát phù hợp

Bạn không cần tự viết hệ thống giám sát từ đầu, vì thị trường hiện đã có khá nhiều nền tảng chuyên cho việc này, mỗi nền tảng lại phù hợp với một kiểu đội ngũ khác nhau.

Với công ty vừa và nhỏ, bạn không nhất thiết phải chọn công cụ mạnh nhất ngay từ đầu, mà nên bắt đầu với công cụ tích hợp nhanh nhất để có dữ liệu quan sát sớm, rồi chuyển sang công cụ chuyên sâu hơn khi hệ thống AI đã phức tạp lên. Dù chọn công cụ nào, bạn cũng nên kiểm tra kỹ chính sách lưu trữ dữ liệu và hạn mức của gói miễn phí ngay tại tài liệu chính thức của nhà cung cấp trước khi đưa vào dùng thật, vì các mức này thường thay đổi theo thời gian.

Đặt ngưỡng cảnh báo ở đâu là hợp lý

Có số liệu mà không đặt ngưỡng cảnh báo thì cũng giống như có camera an ninh nhưng chẳng ai xem lại - bạn chỉ biết chuyện đã xảy ra khi lật lại lịch sử, chứ không được báo ngay lúc nó đang diễn ra. Nguyên tắc đặt ngưỡng dễ nhớ nhất là so với đường nền của chính hệ thống bạn, không so với một con số lý tưởng nào đó trên mạng, vì mỗi sản phẩm có mức bình thường khác nhau.

Cách làm thực tế: theo dõi từng chỉ số trong 2-4 tuần đầu để biết mức bình thường, sau đó đặt cảnh báo khi chỉ số lệch quá xa mức đó trong một khoảng thời gian ngắn - ví dụ tỷ lệ lỗi tăng gấp đôi so với trung bình 7 ngày gần nhất, hoặc chi phí token trong 1 giờ vượt quá một mức trần đã đặt trước. Ngưỡng nên được xem lại định kỳ mỗi quý, vì hệ thống càng lớn thì mức bình thường cũng thay đổi theo.

Sai lầm thường gặp khi giám sát model AI

Sai lầm phổ biến nhất là chỉ giám sát mặt hạ tầng (server có sống hay không, API có phản hồi hay không) mà bỏ qua hoàn toàn chất lượng nội dung, trong khi model AI có thể "sống khoẻ" về mặt kỹ thuật nhưng trả lời sai lệch hoàn toàn về nội dung. Sai lầm thứ hai là dựng hệ thống giám sát cho việc dùng model đơn lẻ nhưng quên mất phần agent tự vận hành nhiều bước - nếu công ty bạn đang triển khai AI Agent thay vì chỉ gọi model một lần, phần giám sát riêng cho agent (nhật ký hành động, cơ chế phê duyệt, dừng khẩn) cần được bàn thêm ở bài Quản trị và giám sát AI Agent: nhật ký, phê duyệt, dừng khẩn.

Sai lầm thứ ba là để một mình bộ phận kỹ thuật xem log mà không có ai đối chiếu với phản ánh thật từ bộ phận chăm sóc khách hàng, khiến hai nguồn thông tin này không bao giờ gặp nhau dù cùng nói về một vấn đề. Doanh nghiệp làm tốt việc này thường có một buổi đối chiếu ngắn hằng tuần giữa hai bên, chỉ 15-20 phút, nhưng lại là nơi phát hiện ra phần lớn sự cố sớm nhất.