Đọc "Designing Machine Learning Systems" theo cách của FDE: bắt đầu từ chương 3, 4, 9 và 10

Đây là một cuốn sách về machine learning, vậy mà câu đáng nhớ nhất lại nói rằng thuật toán không cứu được bạn: nếu dữ liệu huấn luyện tệ, thuật toán sẽ không thể chạy tốt. Với người làm FDE, câu đó gần như là mô tả công việc.

Cuốn sách là Designing Machine Learning Systems của Chip Huyen, O’Reilly xuất bản năm 2022. Sách bắt nguồn từ CS 329S, khóa học Chip Huyen giảng ở Stanford với mục tiêu đưa ra một framework lặp để phát triển hệ thống ML chạy ngoài đời thực.

Bạn không cần đọc từ trang đầu. Một FDE ở chỗ khách hàng thường vật lộn với bốn việc: nối dữ liệu của họ vào, có dữ liệu huấn luyện đủ tốt, giữ model không lỗi thời, và trả lời câu hỏi nên tự xây hay đi mua hạ tầng. Chương 3, 4, 9 và 10 nói đúng về bốn việc đó.

Vì sao một cuốn sách “toàn diện” lại hợp với FDE?

Trang sách của tác giả mô tả đây là cách tiếp cận toàn diện khi thiết kế hệ thống ML. Mỗi quyết định, từ cách xử lý và tạo dữ liệu huấn luyện đến chọn feature nào, đều được cân theo mục tiêu của cả hệ thống chứ không xét riêng lẻ.

Repo GitHub chính thức của sách mở đầu bằng nhận định rằng hệ thống ML vừa phức tạp vừa đặc thù, và hướng tới hệ thống đáng tin, mở rộng được, bảo trì được. Công việc FDE xoay quanh chính sự đặc thù ấy: mỗi khách hàng một kiểu dữ liệu, một kiểu ràng buộc, nên tư duy hệ thống đáng giá hơn mọi mẹo tuning.

Định dạng dữ liệu là một cam kết với khách hàng

Chương 3, Data Engineering Fundamentals, có một câu đáng chép lại: với dữ liệu có cấu trúc, code ghi dữ liệu buộc phải giả định cấu trúc đó. Khi tích hợp dữ liệu khách hàng, chọn định dạng lưu trữ vì thế không phải chi tiết vặt, mà là thỏa thuận giữa hệ thống của bạn và hệ thống của họ.

Chương này cũng tách hai con đường. Dữ liệu xử lý theo batch cho ra feature tĩnh; dữ liệu đi qua real-time transport thường được xử lý bằng stream computation engine và cho ra feature động.

Thử hình dung một khách hàng làm giao hàng muốn dự đoán đơn nào sẽ bị hủy. “Số đơn trung bình mỗi tháng của người mua” thay đổi chậm, tính lại hằng đêm từ file xuất là đủ: đó là feature batch. “Số lần người mua đổi địa chỉ trong 10 phút qua” thì vô nghĩa nếu chờ đến sáng mai: đó là feature stream.

Tập phân loại feature như vậy ngay trong tuần đầu, vì câu trả lời quyết định bạn đề xuất kiến trúc gì. Nếu mọi feature quan trọng đều là batch, bạn có thể chưa cần đụng tới hạ tầng stream.

Accuracy 95% có thể chẳng bắt được gì

Chương 4, Training Data, khẳng định chất lượng dữ liệu huấn luyện quyết định hiệu năng, thuật toán thông minh đến đâu cũng không bù được. Chương này còn nhắc một sự thật khó chịu: mất cân bằng lớp là chuyện thường gặp ở dữ liệu thực tế chứ không phải ngoại lệ.

Hãy làm một phép tính nhỏ. Giả sử khách hàng đưa 1.000 giao dịch, trong đó 950 bình thường và 50 gian lận. Một model lười biếng đoán “bình thường” cho tất cả sẽ đúng 950 trên 1.000, tức accuracy 95%, trong khi bắt được 0 trên 50 vụ gian lận.

Con số 95% ấy trông rất ổn trong slide demo, nhưng 50 vụ gian lận mới là lý do khách hàng thuê bạn. Vì thế, ở buổi làm việc đầu tiên, hãy hỏi phân bố nhãn trước khi bàn chuyện dùng model gì, và báo cáo kết quả theo từng lớp thay vì một con số chung.

Phần việc thật bắt đầu sau buổi demo

Chương 9 bàn về continual learning và test in production, với nhận định rằng đây là bài toán riêng của ML nhưng chủ yếu cần giải pháp hạ tầng. Tác giả cũng phản bác nỗi lo streaming vừa khó vừa đắt: công nghệ streaming đã trưởng thành đáng kể.

Chương 10 về hạ tầng và công cụ cho MLOps gọi ML platform là một team mới nổi. Khi làm hạ tầng, câu hỏi build hay buy luôn ám ảnh cả engineering manager lẫn CTO, và sách thừa nhận vẫn chưa có đồng thuận về việc một ML platform nên gồm những gì.

Khoảng trống đó là nơi FDE có tiếng nói, vì bạn là người thấy tận mắt khách hàng đang thiếu gì. Một trang phân tích build-or-buy viết từ thực tế của chính khách hàng thường thuyết phục hơn mọi sơ đồ kiến trúc chung chung.

Gặp tình huống nào thì mở chương nào?

Đọc một lần chưa đủ; giá trị của bốn chương này nằm ở chỗ bạn biết quay lại đúng trang khi dự án vấp. Bảng dưới đây là một checklist gợi ý để dán cạnh bàn làm việc.

Khi dự án gặp tình huống	Mở chương	Việc nên làm ngay
Khách hàng gửi dữ liệu xuất từ hệ thống cũ	3	Ghi lại cấu trúc mà code ghi dữ liệu đang giả định, chốt định dạng trước khi viết pipeline
Có feature cần cập nhật theo phút	3	Tách feature tĩnh đi đường batch và feature động cần xử lý stream
Model demo đẹp nhưng khách hàng thấy sai	4	Đếm phân bố nhãn, báo kết quả theo từng lớp
Model cần cập nhật thường xuyên sau go-live	9	Xử lý như bài toán hạ tầng, đừng gạt streaming chỉ vì sợ khó và đắt
CTO hỏi nên tự xây hay đi mua	10	Viết một trang build-or-buy dựa trên thực tế của khách hàng

Thứ tự đọc nào giúp bạn chuyển sang FDE nhanh nhất?

Thứ tự hợp lý là 3, 4, 9 rồi 10, sau đó quay lại các chương còn lại khi dự án đòi hỏi. Trước khi mở sách, lướt bản tóm tắt chương tại github.com/chiphuyen/dmls-book để có bản đồ.

Trang của tác giả ở huyenchip.com/books, còn tài liệu khóa học nằm ở stanford-cs329s.github.io. Nếu bạn đang làm backend hay data và đã quen pipeline, bốn chương này sẽ nối tiếp tự nhiên với kinh nghiệm sẵn có.

Khi đọc một job description FDE, thử xếp từng yêu cầu vào bốn chương: phần về dữ liệu và dữ liệu huấn luyện ứng với chương 3, 4; phần về vận hành model và hạ tầng ứng với chương 9, 10.

Trên CV, một dự án nhỏ có cả feature batch lẫn feature stream, kèm ghi chú bạn đã phát hiện và xử lý mất cân bằng lớp ra sao, nói nhiều hơn một dòng “biết machine learning”.

Đọc xong bốn chương này, bạn sẽ không giỏi thuật toán hơn bao nhiêu. Nhưng bạn sẽ hỏi khách hàng đúng câu hỏi sớm hơn, và với FDE, đó mới là lợi thế.