Tôi đã phát hiện ra rằng một chỉ số cổng an toàn (safety-gate metric) duy nhất đã che giấu một sự cố ngừng hoạt động kéo dài cả ngày trong tính năng giải thích do AI tạo ra. Bằng cách coi “gate rejection” (từ chối bởi cổng) và “model load failure” (lỗi tải mô hình) là cùng một thứ, chỉ số này đã tạo ra một cảm giác sai lầm về tình trạng hoạt động ổn định. Nó ghi nhận bốn lần từ chối và không có lần thành công nào, nhưng thực tế mô hình chưa bao giờ chạy trong suốt khoảng thời gian đó—một sai lầm có thể khiến những người vận hành không nhận ra hệ thống đang bị hỏng.

Sự nhầm lẫn đã xảy ra như thế nào

Tính năng này sử dụng một mô hình ngôn ngữ cục bộ để chuyển đổi logic máy thô thành các câu văn dễ hiểu cho con người. Một cổng an toàn (safety gate) ở hạ nguồn sẽ chặn bất kỳ đầu ra nào vi phạm các quy tắc đã định trước. Trong môi trường production, tôi đã đưa ra một bộ đếm duy nhất, bộ đếm này sẽ tăng lên mỗi khi cổng từ chối một câu văn. Khi drone ghi lại bốn giải thích từ AI, bộ đếm báo cáo bốn lần từ chối và không có đầu ra thành công nào. Tôi đã hiểu nhầm đó là do cổng đang làm tốt nhiệm vụ của nó, chứ không phải do tính năng đang bị lỗi.

Những gì bộ đếm đã che giấu là một lỗi gồm hai giai đoạn:

  1. Model not running – Mô hình dùng chung máy với phần còn lại của hệ thống. Để tiết kiệm bộ nhớ, máy chủ sẽ giải phóng (unload) mô hình sau một thời gian không hoạt động.
  2. Timeout on reload – Khi một mối đe dọa mới xuất hiện, hệ thống đã cố gắng tải lại khoảng hai gigabyte dữ liệu mô hình. Việc tải lại vượt quá thời gian chờ phản hồi (timeout) là 30 giây, vì vậy yêu cầu đã bị hết thời gian và trả về một câu trả lời trống.

Vì bộ đếm coi một lần bị cổng từ chối và một câu trả lời trống do hết thời gian là cùng một sự kiện, bảng điều khiển (dashboard) hiển thị một “cổng an toàn đang hoạt động” trong khi tính năng AI thực tế đã ngừng hoạt động.

Tại sao điều này lại quan trọng

Trong các sản phẩm vận hành bằng AI, các cổng an toàn giúp ngăn chặn các đầu ra có hại hoặc vô nghĩa. Những người vận hành theo dõi tỷ lệ kích hoạt cổng (fire rate) như một tín hiệu sức khỏe hệ thống. Khi tín hiệu đó bị trộn lẫn với các chế độ lỗi không liên quan, chỉ số đó trở thành một lời nói dối thầm lặng: nó tạo cảm giác an tâm trong khi dịch vụ thực tế không khả dụng.

Giải pháp giúp khôi phục khả năng giám sát

Tôi đã thực hiện ba thay đổi thực tế:

  • Keep the model resident – Điều chỉnh máy chủ để giữ mô hình trong bộ nhớ, loại bỏ độ trễ khi tải lại.
  • Extend the timeout – Tăng cửa sổ phản hồi để xử lý các trường hợp tải chậm thỉnh thoảng xảy ra.
  • Split the counter – Thay thế chỉ số duy nhất “rejected by gate” bằng bốn bộ đếm riêng biệt: accepted, rejected, empty response, và no answer.

Bước thứ ba đã chứng minh được tính quyết định. Thay vì một con số duy nhất có thể hiểu theo cả hai cách, sự phân tách thành bốn phần cho thấy liệu cổng an toàn có đang hoạt động hay không, liệu mô hình có đang trả lời hay không, hoặc liệu yêu cầu thậm chí còn chưa bao giờ chạm tới mô hình.

Các đánh đổi và lập luận phản bác

Những điều cần lưu ý tiếp theo

Các nhà phát triển khi triển khai các thành phần AI nên kiểm tra lại bất kỳ bộ đếm tổng hợp nào đang trộn lẫn giữa kiểm tra an toàn và các lỗi ở cấp độ hệ thống. Việc xây dựng một nhật ký lịch sử chi tiết ghi lại lộ trình của mỗi yêu cầu—bắt đầu tải mô hình, đánh giá cổng, kết quả cuối cùng—sẽ cung cấp dữ liệu pháp chứng (forensic data) cần thiết để phát hiện các vấn đề tiềm ẩn.

Bài học rút ra: Một chỉ số “gate-rejection” duy nhất có thể che giấu một dịch vụ AI đã chết; việc chia nhỏ chỉ số đó thành các sự kiện cấu thành sẽ tiết lộ sự thật và ngăn chặn sự tự tin sai lầm vào một hệ thống thực tế không hề hoạt động.