AI Observability là gì? Cách theo dõi hệ thống AI trong vận hành

AI Observability (khả năng quan sát hệ thống AI) là việc ghi lại và theo dõi đủ thông tin về từng lần hệ thống AI chạy — đầu vào, phiên bản, các bước trung gian, đầu ra, thời gian, chi phí, phản hồi của người dùng — để khi có vấn đề, đội vận hành trả lời được: chuyện gì đã xảy ra, từ lúc nào, với loại yêu cầu nào, và vì sao.

Observability khác đánh giá trước khi triển khai. AI Evaluation chạy hệ thống trên một bộ đầu vào cố định để quyết định có nên đưa một thay đổi vào dùng. Observability theo dõi hệ thống khi đang chạy với đầu vào thật, nơi luôn có những tình huống bộ kiểm thử chưa nghĩ tới. Một bên là kiểm tra trước khi xuất xưởng, một bên là theo dõi trên đường.

Vì sao theo dõi hệ thống AI khác phần mềm thường

Một yêu cầu tới hệ thống AI thường đi qua nhiều bước: truy xuất tài liệu, gọi mô hình, có khi gọi thêm công cụ rồi gọi mô hình lần nữa. Tracing là ghi lại cả chuỗi đó thành một “dấu vết” (trace), mỗi bước là một đoạn có thời gian, đầu vào, đầu ra riêng. Không có trace, bạn chỉ thấy câu trả lời cuối sai mà không biết sai ở bước nào.

Cần ghi lại những gì

Nhật ký cũng là dữ liệu cần bảo vệ. Nếu đầu vào chứa thông tin cá nhân của khách, hãy che hoặc bỏ các trường đó trước khi lưu, giới hạn người được xem nhật ký và đặt thời hạn xoá.

Thiết lập AI observability qua 6 bước

Bước 1. Ghi nhận request và phiên bản

Bắt đầu từ thứ rẻ nhất mà giá trị nhất: mỗi lần gọi AI có một mã, gắn với tác vụ, thời điểm và phiên bản của mọi thành phần — câu lệnh, mô hình, bộ tài liệu. Phần lớn câu hỏi khi điều tra sự cố bắt đầu bằng “từ khi đổi cái gì”. Nếu câu lệnh được quản lý theo phiên bản như ở bài Prompt Management, bước này chỉ là ghi thêm một con số.

Bước 2. Theo dõi độ trễ và lỗi

Theo dõi lỗi kỹ thuật: hết thời gian chờ, bị giới hạn tốc độ gọi, đầu ra sai định dạng khiến bước sau không đọc được. Với độ trễ, nhìn theo phân vị (ví dụ nhóm 5% yêu cầu chậm nhất) chứ không chỉ trung bình — một trợ lý trung bình trả lời nhanh nhưng thỉnh thoảng treo lâu vẫn làm nhân viên bỏ dùng.

Bước 3. Đo chi phí theo tác vụ

Cộng số token vào và ra theo từng tác vụ, nhân với đơn giá, để biết việc nào tốn nhất. Thường sẽ có bất ngờ: một tác vụ nhỏ chạy rất nhiều lần, hoặc ngữ cảnh phình dần vì lịch sử hội thoại bị gửi lại mỗi lượt. Cách dự toán và kiểm soát ngân sách chi tiết xem ở bài chi phí AI Marketing.

Bước 4. Lấy mẫu chất lượng đầu ra

Không đọc được mọi đầu ra, nhưng đọc được một mẫu. Mỗi tuần lấy ngẫu nhiên một số đầu ra, chấm theo cùng rubric dùng trong bộ eval. Kết hợp với tín hiệu gián tiếp có sẵn: tỷ lệ bản nháp bị sửa nhiều hoặc bị bỏ, tỷ lệ trường hợp phải chuyển người thật, phản hồi thích/không thích nếu có. Tín hiệu gián tiếp không nói đầu ra sai ở đâu, nhưng cho biết nên đọc mẫu ở nhóm nào.

Bước 5. Cảnh báo thay đổi bất thường

Xác định đường nền cho vài chỉ số chính rồi đặt cảnh báo khi lệch rõ: chi phí mỗi ngày tăng vọt, độ dài đầu ra thay đổi đột ngột, tỷ lệ câu trả lời “không đủ thông tin” tăng, số lần gọi công cụ mỗi yêu cầu tăng. Thay đổi bất thường không phải lúc nào cũng là lỗi, nhưng luôn đáng xem — đặc biệt sau khi nhà cung cấp cập nhật mô hình mà bạn không chủ động đổi gì.

Bước 6. Liên kết lỗi với nguyên nhân

Khi có ca lỗi, dùng trace để xếp nó vào một nhóm nguyên nhân: dữ liệu (tài liệu sai, cũ), truy xuất (đúng tài liệu nhưng không được lấy lên), câu lệnh (chỉ dẫn mơ hồ), mô hình (hành vi thay đổi sau cập nhật), công cụ (trả kết quả sai). Mỗi nhóm có cách sửa khác nhau. Ca lỗi đã hiểu rõ được đưa vào bộ eval để không tái diễn. Khung NIST AI RMF cũng coi việc theo dõi hệ thống AI sau triển khai là một phần của quản trị rủi ro.

Ví dụ thực hành: tỷ lệ chuyển người thật tăng sau khi đổi mô hình

Ví dụ giả định: một trung tâm tiếng Anh dùng trợ lý AI soạn nháp trả lời tin nhắn, nhân viên duyệt rồi gửi. Trợ lý được dặn đánh dấu “cần tư vấn viên” khi không đủ thông tin. Sau khi chuyển sang mô hình mới, nhân viên phàn nàn rằng bản nháp nào cũng bị đánh dấu chuyển người.

Trung tâm sửa câu lệnh để nói rõ khi nào được dùng học phí trong bảng, chạy lại bộ eval gồm cả các ca học phí, rồi mới áp dụng. Không có nhật ký theo phiên bản và tài liệu truy xuất, cuộc điều tra này chỉ còn là đoán.

Doanh nghiệp nhỏ cần làm đến đâu

Sai lầm thường gặp

• Chỉ ghi câu trả lời cuối, không ghi tài liệu truy xuất và phiên bản, nên không truy được nguyên nhân.
• Chỉ theo dõi lỗi kỹ thuật, coi hệ thống ổn khi không có báo lỗi dù câu trả lời đang sai.
• Lưu nguyên dữ liệu cá nhân của khách trong nhật ký không giới hạn thời gian.
• Nhìn chi phí theo hoá đơn cuối tháng thay vì theo tác vụ, nên không biết việc nào đang đốt tiền.
• Có dữ liệu nhưng không ai xem: bảng theo dõi không gắn với người chịu trách nhiệm.

Câu hỏi thường gặp