15Câu hỏi phỏng vấn#

Chương này không thêm kiến thức mới. Nó gom các nội dung của giáo trình thành những câu hỏi thường gặp khi phỏng vấn cho vị trí kỹ sư học máy hoặc kỹ sư MLOps, kèm cách trả lời mà một người đã hiểu kỹ vấn đề thường đưa ra.

15.1Cách trả lời#

Phần lớn câu hỏi về MLOps là câu hỏi mở, và người phỏng vấn quan tâm tới cách lập luận hơn là danh sách công cụ. Một câu trả lời tốt thường bắt đầu bằng việc nêu ràng buộc của bài toán, chẳng hạn "điều này phụ thuộc vào độ trễ nhãn" hay "phụ thuộc vào số mô hình dùng chung đặc trưng", vì nêu đúng ràng buộc cho thấy người trả lời hiểu bài toán. Sau đó là các lựa chọn và đánh đổi giữa chúng, rồi một lựa chọn cụ thể kèm lý do, thay vì dừng ở "còn tuỳ trường hợp". Cuối cùng là cách đo để biết lựa chọn đó có đúng không. Một con số cụ thể, như các số liệu đo được trong giáo trình, làm câu trả lời thuyết phục hơn nhiều so với một nhận định chung.

15.2Nền tảng#

Câu hỏi: MLOps là gì, và khác DevOps ở điểm nào?

Trả lời

DevOps quản lý một loại tạo tác là mã nguồn, và hệ thống chỉ thay đổi khi có người sửa mã. MLOps phải quản lý ba loại tạo tác thay đổi theo ba nhịp khác nhau: mã, dữ liệu và mô hình. Trong đó dữ liệu thay đổi theo thế giới bên ngoài mà không đi qua kho mã, nên ngoài CI/CD, hệ thống học máy cần thêm huấn luyện liên tục. Một khác biệt nữa nằm ở cách hệ thống hỏng: phần mềm thông thường thường báo lỗi khi có sự cố, còn mô hình nhận đầu vào đã thay đổi vẫn trả về kết quả đúng kiểu, đúng thời hạn, chỉ có điều kết quả đó sai. Vì vậy MLOps cần các cơ chế giám sát riêng.

Câu hỏi: Vì sao một mô hình tốt khi đánh giá lại suy giảm sau khi triển khai?

Trả lời

Thường do một trong bốn nguyên nhân. Đặc trưng lúc phục vụ được tính khác lúc huấn luyện, gọi là lệch huấn luyện–phục vụ. Dữ liệu thay đổi theo thời gian, gọi là dịch chuyển phân phối. Một hệ thống phía trước cung cấp dữ liệu thay đổi mà không thông báo, gọi là phụ thuộc dữ liệu không ổn định. Hoặc mô hình làm sai lệch chính dữ liệu huấn luyện của nó qua vòng phản hồi. Những nguyên nhân này khó phòng vì nguyên lý CACE: trong một mô hình, thay đổi bất kỳ thành phần nào cũng có thể thay đổi toàn bộ hành vi, nên không thể sửa cục bộ rồi yên tâm như với một hàm trong phần mềm thông thường.

Câu hỏi: Con số "5% mã học máy" nghĩa là gì?

Trả lời

Nó đến từ bài báo về nợ kỹ thuật của Sculley và cộng sự (2015), nằm trong phần bàn về mã keo chứ không phải chú thích của hình vẽ hay được trích dẫn. Bài báo nói một hệ thống trưởng thành có thể chỉ gồm nhiều nhất 5% mã học máy và ít nhất 95% mã keo; đây là nhận định định tính, không phải kết quả đo. Kết luận bài báo rút ra từ đó là đôi khi tự viết một giải pháp gọn còn rẻ hơn dùng lại một thư viện đa dụng, và nên bọc các thư viện sau một giao diện chung.

Câu hỏi: Các mức trưởng thành của MLOps là gì?

Trả lời

Theo kiến trúc tham chiếu của Google Cloud có ba mức. Ở mức 0, mọi bước làm bằng tay và thứ được bàn giao là một tệp mô hình. Ở mức 1, pipeline huấn luyện được tự động hoá và có huấn luyện liên tục, nên thứ được bàn giao là cả pipeline. Ở mức 2, chính pipeline có CI/CD, nên thứ được bàn giao là một hệ thống tự cập nhật. Tôi sẽ nói thêm rằng tự động hoá không thay thế được giám sát: một hệ thống ở mức 1 mà không có giám sát chỉ triển khai nhanh hơn, kể cả khi triển khai một mô hình đã hỏng.

15.3Dữ liệu và đặc trưng#

Câu hỏi: Lệch giữa huấn luyện và phục vụ là gì, và làm sao tránh?

Trả lời

Đó là khi đặc trưng lúc phục vụ được tính khác với lúc huấn luyện. Nguyên nhân thường gặp là có hai bản cài đặt: một truy vấn SQL trên kho dữ liệu khi huấn luyện, và một đoạn mã viết lại trong dịch vụ phục vụ cho đủ nhanh. Hai bản do hai người viết thì hiếm khi khớp hoàn toàn. Cách tránh là dùng một định nghĩa đặc trưng duy nhất cho cả hai nơi, đóng gói hàm biến đổi cùng mô hình, và đo độ lệch bằng cách so giá trị đặc trưng ở hai nơi trên cùng lưu lượng; đây là mục Monitor 3 của ML Test Score, và chạy shadow là cách rẻ nhất để đo nó.

Câu hỏi: Tính đúng theo thời điểm là gì?

Trả lời

Với mỗi dòng huấn luyện có thời điểm dự đoán $t$, giá trị mọi đặc trưng phải là giá trị quan sát được tại $t$, không phải giá trị tại lúc dựng tập dữ liệu. Ví dụ, một dòng của tháng 3 phải dùng tổng số đơn hàng của khách tại tháng 3. Nếu dùng con số hôm nay, mô hình học rằng khách có 480 đơn hàng thì không rời bỏ dịch vụ, trong khi con số 480 chỉ có được vì khách đã ở lại. Lỗi này nguy hiểm vì nó làm kết quả đánh giá ngoại tuyến tốt lên, nên không ai nghi ngờ cho tới khi mô hình chạy thật. Cách tránh là ghép dữ liệu theo thời điểm (as-of join) và thêm ràng buộc "không có sự kiện từ tương lai" vào hợp đồng dữ liệu.

Câu hỏi: Khi nào nên dùng kho đặc trưng?

Trả lời

Khi có đồng thời ba điều kiện: nhiều mô hình dùng chung đặc trưng, cần phục vụ trực tuyến với độ trễ thấp, và đặc trưng thay đổi theo thời gian. Thiếu các điều kiện đó, một bảng trong kho dữ liệu cộng với kỷ luật dùng chung một hàm biến đổi là đủ và rẻ hơn nhiều. Cũng cần biết rằng kho đặc trưng không tự động loại bỏ lệch huấn luyện–phục vụ; nếu nhóm vẫn viết một đường tính riêng cho phục vụ thì sự lệch quay lại.

Câu hỏi: Làm sao phát hiện dữ liệu có vấn đề?

Trả lời

Tôi chia lỗi dữ liệu thành ba loại với ba cách phản ứng. Lỗi cứng như sai lược đồ hay giá trị ngoài miền thì dừng pipeline. Lỗi mềm như thiếu một phần dữ liệu, đổi đơn vị hay giá trị danh mục lạ thì cảnh báo và theo dõi tỉ lệ. Dịch chuyển phân phối thì điều tra và có thể huấn luyện lại. Các kiểm tra được viết thành hợp đồng dữ liệu, suy ra từ dữ liệu tham chiếu rồi có người duyệt lại, và chạy ở cả đầu vào lẫn đầu ra của mỗi bước pipeline. Dùng chung một cơ chế cảnh báo cho cả ba loại lỗi là nguyên nhân phổ biến của báo động giả.

15.4Đánh giá và triển khai#

Câu hỏi: Vì sao không nên đánh giá mô hình chỉ bằng một chỉ số tổng thể?

Trả lời

Vì chỉ số tổng thể là trung bình theo lưu lượng, nên nhóm đa số quyết định kết quả. Trong thí nghiệm ở Mục 6.3, thêm một đặc trưng làm độ chính xác tổng thể tăng 19,8 điểm phần trăm, nhóm khách hàng cũ tăng 25,5 điểm, nhưng nhóm 15% khách hàng mới giảm 11,6 điểm, xuống dưới cả mô hình cũ. Lý do là đặc trưng mới chỉ có thông tin với khách hàng cũ, nên với khách hàng mới, trọng số lớn của nó đưa nhiễu vào dự đoán. Vì vậy cần đánh giá theo lát cắt, cùng với kiểm thử hành vi trên những trường hợp cụ thể.

Câu hỏi: Shadow, canary và A/B test khác nhau thế nào?

Trả lời

Mỗi cách trả lời một câu hỏi khác. Shadow cho biết mô hình mới có chịu được tải thật không và đặc trưng có khớp với lúc huấn luyện không, mà người dùng không chịu rủi ro nào; nhưng nó không cho biết người dùng phản ứng ra sao. Canary cho biết có chỉ số vận hành nào xấu đi ở quy mô nhỏ không, và giới hạn phạm vi ảnh hưởng nếu có sự cố. A/B test cho biết mô hình mới có làm chỉ số sản phẩm tốt lên theo nghĩa nhân quả không. Một điểm hay bị nhầm là dùng canary để kết luận về chỉ số sản phẩm: ở 1% lưu lượng thì không đủ mẫu.

Câu hỏi: Vì sao không thể A/B test mọi thay đổi?

Trả lời

Vì lưu lượng có hạn, và cỡ mẫu cần thiết tỉ lệ nghịch với bình phương mức cải thiện cần phát hiện. Với tỉ lệ nền 5%, phát hiện một cải thiện tương đối 1% với lực kiểm định 80% cần khoảng 3 triệu mẫu mỗi nhánh, tức khoảng một tháng nếu mỗi nhánh có 100 000 lượt mỗi ngày. Vì vậy quy trình tốt loại các ý tưởng kém bằng những cách rẻ hơn, như đánh giá ngoại tuyến và shadow, trước khi dùng lưu lượng cho A/B test. Nếu cần rút ngắn thí nghiệm mà không giảm độ tin cậy, có thể giảm phương sai bằng CUPED.

Câu hỏi: Khi đọc kết quả A/B test, cần tránh những sai sót nào?

Trả lời

Sai sót phổ biến nhất là xem kết quả giữa chừng rồi dừng khi thấy $p < 0{,}05$, làm tỉ lệ dương tính giả tăng; nên cố định cỡ mẫu trước hoặc dùng kiểm định tuần tự. Tiếp theo là so sánh nhiều chỉ số cùng lúc; nên khai báo trước một chỉ số chính. Trong mạng xã hội hay sàn giao dịch, hai nhánh có thể ảnh hưởng lẫn nhau, nên cần chia ngẫu nhiên theo cụm. Trước khi đọc kết quả, tôi kiểm tra tỉ lệ mẫu giữa hai nhánh có đúng thiết kế không, vì tỉ lệ mẫu lệch là dấu hiệu thí nghiệm có lỗi. Cuối cùng là hiệu ứng mới lạ, nên thí nghiệm cần chạy đủ lâu.

Câu hỏi: ML Test Score được tính thế nào?

Trả lời

Bộ tiêu chí gồm 28 mục chia đều thành bốn nhóm: dữ liệu, phát triển mô hình, hạ tầng, giám sát. Mỗi mục được 0,5 điểm nếu làm thủ công có ghi lại kết quả, 1 điểm nếu có hệ thống chạy tự động và định kỳ. Điểm mỗi nhóm là tổng điểm các mục, còn điểm cuối cùng là giá trị nhỏ nhất trong bốn nhóm. Lấy giá trị nhỏ nhất vì cả bốn nhóm đều cần thiết: một hệ thống có hạ tầng hoàn hảo mà không có giám sát vẫn có điểm 0.

15.5Giám sát và dịch chuyển#

Câu hỏi: Có những loại dịch chuyển phân phối nào?

Trả lời

Ba loại chính. Covariate shift là khi $P(X)$ thay đổi mà $P(Y \mid X)$ giữ nguyên. Label shift là khi $P(Y)$ thay đổi mà $P(X \mid Y)$ giữ nguyên. Concept drift là khi chính quan hệ $P(Y \mid X)$ thay đổi. Hai loại đầu thường làm phân phối của $X$ thay đổi; concept drift thì không nhất thiết.

Câu hỏi: Loại dịch chuyển nào phát hiện được khi chưa có nhãn?

Trả lời

Covariate shift và label shift, vì cả hai làm phân phối của $X$ thay đổi. Concept drift có thể giữ nguyên $P(X)$, nên không phép kiểm tra nào chỉ dựa trên $X$ phát hiện được nó. Trong thí nghiệm ở Mục 9.2, concept drift làm độ chính xác giảm từ 75,6% xuống 26,9% trong khi kiểm định KS trên các đặc trưng cho $p = 0{,}48$. Ngược lại, covariate shift cho p-value gần bằng 0 mà độ chính xác gần như không đổi, nên nếu cảnh báo dựa trên $X$ thì đó là báo động giả. Từ đó, khi thiết kế giám sát, câu hỏi đầu tiên của tôi là sau bao lâu thì có nhãn thật.

Câu hỏi: Nên dùng ngưỡng PSI nào?

Trả lời

PSI là tổng hai chiều của phân kỳ KL giữa hai phân phối đã chia bin. Các ngưỡng 0,10 và 0,25 là quy tắc kinh nghiệm từ chấm điểm tín dụng và không tính tới cỡ mẫu hay số bin. Khi hai mẫu cùng phân phối, PSI có kỳ vọng xấp xỉ $2(k-1)/n$, nên với $n = 200$ và 20 bin, PSI trung bình đã là 0,205 dù không có dịch chuyển nào. Trong mô phỏng ở Mục 9.5, với $n = 50$ quy tắc PSI > 0,25 báo động 73% số lần khi không có dịch chuyển, còn với $n = 1\,000$ và dịch chuyển thật 0,3 độ lệch chuẩn thì nó không báo động lần nào. Tôi sẽ dùng kiểm định có p-value kèm hiệu chỉnh cho kiểm định nhiều lần; nếu buộc phải dùng PSI, tôi tính ngưỡng theo đúng $n$ và $k$, ví dụ $\tfrac{2}{n}\chi^2_{k-1,\,0{,}99}$, và giữ $n$, $k$ cố định giữa các lần đo.

Câu hỏi: Khi chưa có nhãn thì giám sát gì?

Trả lời

Tôi chia việc giám sát thành bốn lớp theo khoảng cách tới nhãn: dữ liệu thô, đặc trưng, dự đoán và chất lượng. Khi chưa có nhãn, lớp dự đoán là lớp chính: phân phối điểm số, tỉ lệ từng lớp, và độ lệch dự đoán so với tỉ lệ nền lịch sử, tính theo lát cắt. Độ lệch dự đoán không đủ để khẳng định mô hình đúng, vì một mô hình luôn dự đoán tỉ lệ trung bình cũng có độ lệch bằng 0, nhưng thay đổi đột ngột của nó thường là dấu hiệu sự cố. Với hệ thống có hành động thật, tôi thêm giới hạn hành động: đặt trần cho số hành động trong mỗi khoảng thời gian và cảnh báo khi chạm trần.

Câu hỏi: Vì sao cảnh báo hay bị bỏ qua, và nên thiết kế cảnh báo thế nào?

Trả lời

Vì báo động giả: khi phần lớn cảnh báo là giả, người nhận mất niềm tin và bỏ qua cả cảnh báo thật. Để tránh, mỗi cảnh báo phải gắn với một hành động cụ thể; cảnh báo được phân mức, từ gọi người trực, tạo phiếu xử lý, tới chỉ hiển thị trên bảng theo dõi; cảnh báo dựa trên triệu chứng như tỉ lệ chuyển đổi giảm, không dựa trên nguyên nhân như PSI của một đặc trưng; và chỉ báo động khi tín hiệu kéo dài qua nhiều cửa sổ liên tiếp.

15.6Thiết kế hệ thống#

Với câu hỏi dạng "thiết kế hệ thống học máy cho bài toán X", có thể đi theo trình tự của giáo trình để không bỏ sót. Bắt đầu bằng việc làm rõ bài toán: chỉ số sản phẩm là gì, chỉ số nào của mô hình đại diện cho nó, và hai chỉ số tương quan tới đâu. Tiếp theo hỏi về nhãn: lấy từ đâu, trễ bao lâu, có bị chính hệ thống làm sai lệch không; câu trả lời cho phần này quyết định phần lớn thiết kế còn lại. Sau đó chọn chế độ phục vụ rẻ nhất đáp ứng được yêu cầu, và lập ngân sách độ trễ nếu phục vụ trực tuyến. Về dữ liệu và đặc trưng, cần nói tới nguồn dữ liệu, hợp đồng dữ liệu, có cần ghép theo thời điểm không và có cần kho đặc trưng không. Về huấn luyện, cần nói tới nhịp huấn luyện lại, điều kiện kích hoạt và những gì cần cố định để tái lập. Về đánh giá, cần có tập kiểm tra cố định, các lát cắt, kiểm thử hành vi và bước so sánh với mô hình đang chạy. Về triển khai, cần có shadow, canary, A/B test và cơ chế quay lui. Về giám sát, cần nêu bốn lớp, chỉ số nào gọi người trực và quy trình khi có cảnh báo. Cuối cùng, cần xét hệ thống có ảnh hưởng tới dữ liệu tương lai của chính nó không và có cần nhóm đối chứng không. Hai phần hay bị bỏ qua nhất là câu hỏi về nhãn và câu hỏi về vòng phản hồi.

15.7Ứng dụng dùng mô hình ngôn ngữ lớn#

Câu hỏi: Vận hành ứng dụng LLM khác vận hành mô hình học máy thông thường ở điểm nào?

Trả lời

Phần lớn nguyên tắc giữ nguyên: hợp đồng dữ liệu, quản lý phiên bản, shadow và canary, giám sát, quay lui. Có năm ràng buộc thay đổi: thường không tự huấn luyện mô hình; đầu ra là văn bản tự do nên không có hàm đúng sai hiển nhiên; kết quả không tất định và nhà cung cấp có thể cập nhật mô hình mà giữ nguyên tên gọi; chi phí chủ yếu là suy luận tính theo token, thay đổi theo từng yêu cầu; và có thêm các rủi ro như nội dung có hại, rò rỉ dữ liệu, prompt injection. Việc nhà cung cấp cập nhật mô hình là dạng cực đoan của phụ thuộc dữ liệu không ổn định, nên tôi dùng định danh phiên bản cố định và coi mỗi lần đổi phiên bản là một lần phát hành đầy đủ.

Câu hỏi: Đánh giá một ứng dụng dùng LLM như thế nào?

Trả lời

Tôi chia thành ba tầng theo chi phí. Kiểm tra theo quy tắc chạy trên mọi lượt gọi: định dạng, JSON, trích dẫn, độ dài. Giám khảo LLM chấm một mẫu để đánh giá chất lượng nội dung. Người chấm chấm một mẫu nhỏ định kỳ để hiệu chỉnh giám khảo. Thêm vào đó là một tập đánh giá chuẩn làm bước kiểm định trước mỗi lần phát hành, và chấm mẫu trên lưu lượng thật. Với giám khảo LLM, cần biết các thiên lệch đã được ghi nhận: thiên lệch vị trí, xử lý bằng cách hỏi hai lần với thứ tự đảo; thiên lệch độ dài; và khả năng tự ưu tiên câu trả lời của chính mình. Giám khảo cũng là một mô hình có thể thay đổi, nên tôi đo mức đồng thuận giữa nó và người chấm theo thời gian.

Câu hỏi: Một câu trả lời của hệ thống RAG bị sai. Điều tra thế nào?

Trả lời

Tôi tách thành hai câu hỏi. Tài liệu cần thiết có nằm trong ngữ cảnh không? Nếu không, đó là lỗi truy xuất, đo bằng recall@$k$, và sửa bằng cách chia đoạn, mô hình embedding, tìm kiếm kết hợp hay xếp hạng lại. Nếu có mà câu trả lời vẫn sai, đó là lỗi sinh, đo bằng độ trung thành với ngữ cảnh, và sửa bằng prompt, đổi mô hình hay yêu cầu trích dẫn. Để tách được hai loại lỗi, bản ghi vết phải lưu danh sách các đoạn đã truy xuất kèm điểm của chúng ngay từ đầu.

Câu hỏi: Làm sao giảm chi phí của một ứng dụng dùng LLM?

Trả lời

Tôi thử theo thứ tự: bộ nhớ đệm cho câu hỏi lặp lại, câu hỏi gần giống và phần đầu cố định của prompt; định tuyến câu hỏi dễ tới mô hình nhỏ; rồi giảm ngữ cảnh, như bớt số đoạn truy xuất hay tóm tắt lịch sử hội thoại. Tôi cũng ghi chi phí của giám khảo LLM thành một dòng riêng, để biết chi phí tăng vì lưu lượng hay vì tăng tỉ lệ lấy mẫu đánh giá.

15.8Những câu trả lời chưa đạt#

Bảng dưới liệt kê một số câu trả lời nghe hợp lý nhưng cho thấy người trả lời chưa hiểu kỹ vấn đề, kèm lý do.