10Giám sát#

Đến đây ta đã biết những gì có thể hỏng trong một hệ thống học máy: dữ liệu đầu vào (Chương 3), đặc trưng (Chương 4), và phân phối dữ liệu theo thời gian (Chương 9). Giám sát là việc theo dõi liên tục để phát hiện những sự cố đó khi chúng xảy ra, và cảnh báo đúng người vào đúng lúc. Phần khó của giám sát không nằm ở việc đo được nhiều chỉ số, mà ở việc chọn đo cái gì và khi nào thì báo động.

10.1Chỉ số vận hành và chỉ số của mô hình#

Các chỉ số cần theo dõi chia thành hai loại. Loại thứ nhất là chỉ số vận hành: độ trễ, lưu lượng, tỉ lệ lỗi, mức sử dụng CPU, GPU, bộ nhớ. Chúng giống với chỉ số của mọi dịch vụ phần mềm khác, và khi có sự cố thì chúng thay đổi ngay. Sách Site Reliability Engineering của Google (Beyer và cộng sự, 2016) gọi bốn chỉ số độ trễ, lưu lượng, lỗi và mức bão hoà tài nguyên là bốn tín hiệu cơ bản (four golden signals). Sách cũng định nghĩa hai khái niệm sẽ dùng trong chương này: chỉ số mức dịch vụ (SLI) là một đại lượng đo được, như p99 của độ trễ, còn mục tiêu mức dịch vụ (SLO) là giá trị mục tiêu cho SLI đó, như "p99 dưới 200 ms trong 99,9% số phút".

Loại thứ hai là chỉ số riêng của mô hình học máy: độ chính xác, phân phối của dự đoán, phân phối của đặc trưng, chất lượng dữ liệu đầu vào. Khác với chỉ số vận hành, khi mô hình suy giảm thì các chỉ số này thường không thay đổi ngay, hoặc thay đổi mà không ai nhận ra. Ngành phần mềm đã có nhiều kinh nghiệm với loại chỉ số thứ nhất, nên phần còn lại của chương tập trung vào loại thứ hai.

10.2Các lớp giám sát#

Có thể sắp xếp các chỉ số của mô hình thành bốn lớp, theo khoảng cách tới nhãn: càng gần nhãn thì càng nói lên nhiều về chất lượng, nhưng càng khó có được.

Lớp ngoài cùng là dữ liệu đầu vào thô: dữ liệu tới có đủ số lượng, đúng giờ, đúng lược đồ không. Lớp này có ngay và phát hiện được lỗi cứng, nhưng nói rất ít về chất lượng dự đoán. Lớp thứ hai là đặc trưng: phân phối của từng đặc trưng, tỉ lệ giá trị thiếu, các giá trị danh mục lạ. Lớp này cũng có ngay, và phát hiện được covariate shift cùng lệch huấn luyện–phục vụ. Lớp thứ ba là dự đoán: phân phối của $\hat y$, tỉ lệ từng lớp, độ tự tin trung bình. Lớp này có ngay và phát hiện được nhiều sự cố mà không cần nhãn. Lớp trong cùng là chất lượng: độ chính xác, AUC, chỉ số sản phẩm. Lớp này có ý nghĩa nhất, nhưng chỉ có khi đã có nhãn, nên thường đến muộn.

Nguyên tắc chung là cảnh báo dựa trên lớp chất lượng khi có thể, và dùng ba lớp ngoài để điều tra nguyên nhân. Với những hệ thống có nhãn đến chậm, lớp dự đoán trở thành lớp giám sát chính.

10.3Độ lệch dự đoán#

Với lớp dự đoán, Sculley và cộng sự (2015) đề xuất một phép kiểm tra đơn giản nhưng hữu ích.

Định nghĩa 10.1 (Độ lệch dự đoán)

Trong một hệ thống hoạt động đúng, phân phối của các nhãn được dự đoán thường phải bằng phân phối của các nhãn quan sát được. Độ lệch dự đoán (prediction bias) là chênh lệch giữa hai phân phối đó.

Bài báo nêu rõ giới hạn của phép kiểm tra này: nó không đủ để khẳng định mô hình đúng, vì một mô hình luôn dự đoán đúng tỉ lệ trung bình mà không dùng gì tới đầu vào cũng có độ lệch bằng 0. Nhưng một thay đổi đột ngột của nó thường là dấu hiệu sự cố. Ưu điểm lớn của nó là không cần nhãn cho từng dự đoán, chỉ cần biết tỉ lệ nền theo thời gian. Ví dụ, nếu tỉ lệ giao dịch gian lận trong lịch sử là 1,2% mà mô hình đột nhiên đánh dấu 4,5% số giao dịch, có điều gì đó cần điều tra, dù chưa có nhãn nào cho ngày hôm nay.

Độ lệch dự đoán nên được tính theo lát cắt: theo thị trường, theo kênh, theo phiên bản ứng dụng. Độ lệch tổng thể bằng 0 vẫn có thể che giấu hai lát cắt lệch theo hai chiều ngược nhau.

10.4Giới hạn hành động và hệ thống phía trước#

Bài báo của Sculley và cộng sự đề xuất thêm hai cơ chế giám sát.

Cơ chế thứ nhất là giới hạn hành động (action limits). Với những hệ thống thực hiện hành động thật, như đặt giá thầu quảng cáo, chặn tin nhắn hay khoá tài khoản, cần đặt và thực thi giới hạn cho số hành động trong mỗi khoảng thời gian, như một phép kiểm tra hợp lý. Giới hạn đủ rộng để không bị chạm khi hệ thống hoạt động bình thường; khi bị chạm thì tự động cảnh báo và cần người xem xét. Cơ chế này không cần biết mô hình đúng hay sai. Nó chỉ cần biết rằng, chẳng hạn, việc khoá 50 000 tài khoản trong một giờ chưa từng xảy ra và không nên xảy ra.

Cơ chế thứ hai liên quan tới hệ thống phía trước (up-stream producers), tức các hệ thống cung cấp dữ liệu cho hệ thống học máy. Chúng cần được giám sát, kiểm thử và có SLO phù hợp với nhu cầu của hệ thống học máy phía sau. Cảnh báo ở phía trước phải được chuyển tới hệ thống học máy; ngược lại, khi hệ thống học máy không đạt SLO, mọi bên sử dụng kết quả của nó phải được thông báo. Đây cũng là cách xử lý dạng nợ "bên sử dụng không khai báo" ở Mục 1.4: biến các phụ thuộc ngầm thành phụ thuộc có tên và có cảnh báo theo cả hai chiều.

10.5Thiết kế cảnh báo#

Mục 3.2 đã nhắc tới khó khăn được nêu nhiều nhất trong nghiên cứu của Shankar và cộng sự: báo động giả. Khi phần lớn cảnh báo là giả, người nhận dần bỏ qua chúng, kể cả những cảnh báo thật. Một hệ thống cảnh báo như vậy có thể còn tệ hơn không có, vì nó tạo ra cảm giác an toàn không có cơ sở. Kinh nghiệm vận hành phần mềm, được tổng kết trong sách của Beyer và cộng sự (2016), cho bốn nguyên tắc thiết kế cảnh báo.

Nguyên tắc thứ nhất là mỗi cảnh báo phải gắn với một hành động cụ thể. Nếu người nhận không biết phải làm gì khi nhận được nó, đó là thông tin để xem chứ không phải cảnh báo, và nên được đưa vào bảng theo dõi (dashboard) thay vì gửi thông báo. Nguyên tắc thứ hai là phân mức độ: gọi người trực ngay (page) cho lỗi cứng và khi dịch vụ ngừng hoạt động; tạo phiếu xử lý (ticket) cho dịch chuyển và suy giảm chậm; phần còn lại chỉ hiển thị trên bảng theo dõi. Nguyên tắc thứ ba là cảnh báo theo triệu chứng chứ không theo nguyên nhân. "Tỉ lệ chuyển đổi giảm 15%" là một triệu chứng ảnh hưởng tới người dùng và đáng gọi người trực; "PSI của đặc trưng thứ 37 vượt 0,2" là một manh mối để điều tra, chưa phải một sự cố. Nguyên tắc thứ tư là yêu cầu tín hiệu kéo dài: một điểm dữ liệu vượt ngưỡng có thể là nhiễu, còn vượt ngưỡng trong ba cửa sổ liên tiếp mới là tín hiệu đáng tin.

10.6Ngưỡng quyết định khi mô hình thay đổi#

Sculley và cộng sự đặt tên cho một dạng nợ rất hay gặp liên quan tới giám sát: ngưỡng cố định trong hệ thống thay đổi (fixed thresholds in dynamic systems). Nhiều mô hình cần một ngưỡng quyết định, ví dụ để quyết định một email có phải thư rác không. Ngưỡng thường được đặt bằng tay để cân bằng precision và recall. Khi mô hình được huấn luyện lại trên dữ liệu mới, phân phối điểm số của nó thay đổi, và ngưỡng cũ có thể không còn phù hợp: cùng ngưỡng 0,7 nhưng số email bị chặn có thể tăng gấp đôi.

Cập nhật ngưỡng bằng tay cho nhiều mô hình vừa tốn công vừa dễ quên. Bài báo đề xuất xác định ngưỡng tự động trên một tập kiểm định riêng mỗi lần huấn luyện, và coi ngưỡng là một phần của mô hình, lưu cùng mô hình trong sổ đăng ký, thay vì là một hằng số trong cấu hình của dịch vụ. Đây cũng là một ví dụ của CACE: huấn luyện lại làm thay đổi phân phối điểm số, nên mọi thứ phụ thuộc vào điểm số đó cũng thay đổi theo, kể cả một con số trong tệp cấu hình mà không ai coi là một phần của mô hình.

10.7Tóm tắt#

Giám sát một hệ thống học máy gồm chỉ số vận hành, giống mọi dịch vụ khác, và chỉ số riêng của mô hình, xếp thành bốn lớp từ dữ liệu thô, đặc trưng, dự đoán tới chất lượng. Khi nhãn đến chậm, lớp dự đoán là lớp chính, với độ lệch dự đoán là một phép kiểm tra đơn giản. Giới hạn hành động bảo vệ hệ thống khỏi những hành động bất thường mà không cần biết mô hình đúng hay sai, còn cảnh báo cần gắn với hành động, phân mức độ, dựa trên triệu chứng và tín hiệu kéo dài để tránh báo động giả. Cuối cùng, ngưỡng quyết định phải được xác định lại mỗi lần huấn luyện lại mô hình.

Khi giám sát cho thấy mô hình đã suy giảm, cách xử lý thông thường là huấn luyện lại. Chương 11 bàn về việc huấn luyện lại: khi nào, bao lâu một lần, và làm sao để việc tự động hoá nó không tạo ra sự cố mới.