# Cuốn sách ML dạy FDE làm phần việc không ai muốn khoe

> Emmanuel Ameisen viết cho 95% thời gian không dành cho train model, và đó là phần việc của FDE.

Bản gốc: https://fdetimes.net/vi/sach-khoa-hoc/sach-building-machine-learning-powered-applications-emmanuel-ameisen/

Trên trang giới thiệu sách của mình, Emmanuel Ameisen đưa ra một con số khiến nhiều người mới học ML chột dạ. Theo ông, data scientist dành 95% thời gian để thu hẹp use case sản phẩm, xử lý dữ liệu và deploy. Phần train model, thứ chiếm gần hết các khoá học, chỉ là phần nhỏ còn lại.

Cuốn *Building Machine Learning Powered Applications: Going from Idea to Product* (O'Reilly, 2020) viết cho chính 95% đó. Ameisen mô tả sách là những mẹo thực tế cho các khâu ít được chú ý của ML: tạo và gán nhãn dataset, debug model, deploy model.

Với một FDE, danh sách ấy gần như là bản mô tả công việc. Khách hàng hiếm khi thiếu thuật toán. Thứ họ thiếu là một bài toán được đặt đúng, một bộ dữ liệu dùng được và một hệ thống vẫn chạy khi gặp người dùng thật.

## Model chỉ là một mắt xích

Theo ghi chép của một người đọc trên GitHub, luận điểm xuyên suốt sách là: muốn đưa một sản phẩm ML đến người dùng, train model thôi chưa đủ.

Repo đi kèm, hundredblocks/ml-powered-applications, có ba phần: các Jupyter notebook minh hoạ khái niệm trong sách, thư viện ml_editor chứa các hàm lõi của case study, và một app Flask. Ba phần này khớp với ba chặng quen thuộc trong việc của FDE: thử nghiệm, đóng gói thành thư viện, rồi dựng thành app cho người dùng.

## Dữ liệu tìm thấy chưa chắc là dữ liệu cần

Ý đầu tiên nên giữ là một cảnh báo ngắn trong sách: người ta hay nhầm bộ dữ liệu mình tìm thấy với bộ dữ liệu mình cần. Ở site khách hàng, lỗi này lộ ra ngay tuần đầu, khi ai đó đưa bạn một bản export database và bảo "dữ liệu đây".

Thử hình dung một công ty chăm sóc khách hàng muốn "AI giúp nhân viên trả lời ticket hay hơn". Hiểu theo nghĩa đen, bạn sẽ đi sinh nguyên câu trả lời, một bài toán rộng, khó đo, khó debug.

Cách đặt hẹp hơn là đoán xem một bản nháp có cần sửa không. Input là bản nháp, output là một nhãn, còn thước đo là tỉ lệ bản nháp bị trưởng nhóm sửa lại.

Cái bẫy nằm ở đây. Kho ticket khách hàng đưa có thể chỉ lưu câu trả lời cuối, không lưu bản nháp trước khi sửa. Dữ liệu thì nhiều nhưng thiếu đúng cặp input và nhãn mà bài toán cần.

Vì thế, việc đầu tiên nên làm là hỏi hệ thống có ghi lại lịch sử chỉnh sửa không. Hãy hỏi xong câu đó rồi mới hứa với khách hàng bất kỳ con số nào.

**Điểm mấu chốt:** Dữ liệu bạn tìm được hiếm khi đúng là dữ liệu bài toán cần.

## Nhìn tận mắt trước khi tin vào chỉ số

Một bài review trên Substack nhắc rằng có được dữ liệu đã gán nhãn có thể rất khó. Bài review cũng trích một thói quen mà sách dẫn từ Monica Rogati: lướt qua thật nhiều mẫu xem có gì kỳ lạ không. Lời khuyên đơn giản đến mức dễ bị bỏ qua, nhưng nó rẻ hơn mọi dashboard.

Áp vào ví dụ ticket: trước khi mở notebook, hãy đọc vài chục bản nháp thật. Bạn có thể thấy những thứ mà không cột số liệu nào báo trước, như ticket trùng lặp, câu trả lời mẫu dán nguyên văn, hay ticket viết bằng nhiều ngôn ngữ. Mỗi phát hiện như vậy là một câu hỏi cụ thể cho buổi họp tiếp theo với khách hàng.

## Khi hệ thống sai, hãy làm model đơn giản đi

Ý thứ ba, theo ghi chép của người đọc kia, là thay model bằng một thứ đơn giản rồi debug toàn bộ pipeline. Nghe thì ngược, nhưng đây là cách nhanh nhất để biết lỗi nằm ở model hay ở những thứ xung quanh nó.

Với bài toán ticket, "model" tạm thời có thể chỉ là một luật: đánh dấu cần sửa mọi bản nháp ngắn hơn một ngưỡng nào đó.

Nếu luật này cho kết quả vô lý trên giao diện, lỗi nằm ở khâu đọc dữ liệu, ghép trường hoặc hiển thị chứ không ở thuật toán.

Pipeline chạy sạch từ đầu đến cuối rồi thì thay luật bằng model thật mới có ý nghĩa.

## Sách đã cũ ở chỗ nào

Sách ra năm 2020, trước làn sóng LLM. Bài review trên Substack nhận xét rằng trong thời LLM, sách đã đến lúc cần cập nhật nhưng vẫn hữu ích. Đánh giá này công bằng, vì ba ý trên không phụ thuộc vào loại model và vẫn đúng khi model chỉ là một lời gọi API.

Điểm yếu thứ hai FDE cần biết: một bài review trên DEV Community chê sách mỏng về chi tiết deploy. Nếu chỉ bù được một phần, hãy bắt đầu từ monitoring và rollback, vì đó là hai thứ quyết định một deployment có sống sót qua tuần đầu ở site khách hàng hay không.

Với ví dụ ticket, monitoring nghĩa là theo dõi tỉ lệ bản nháp bị trưởng nhóm sửa sau khi go-live, để thấy model tệ dần trước khi khách hàng phàn nàn. Rollback nghĩa là quay về luật đơn giản hoặc phiên bản model trước chỉ bằng một thay đổi cấu hình. Hãy dựng sẵn cả hai trước buổi demo đầu tiên.

## Ai nên đọc, và đọc thế nào

Sách hợp nhất với kỹ sư phần mềm đã biết Python và ML cơ bản nhưng chưa từng đưa model đến người dùng thật. Nên mở repo bên cạnh và chạy các notebook song song khi đọc sách.

Sau đó, hãy dành nhiều thời gian cho ml_editor và app Flask. Đó là chỗ model phải thành thứ người khác dùng được, tức gần nhất với việc bạn sẽ làm ở khách hàng.

Muốn cuốn sách thành một dòng trong CV, đừng dừng ở việc chạy lại repo của tác giả. Hãy áp cùng cấu trúc ba phần vào một nguồn dữ liệu công khai khác.

Ghi lại dữ liệu tìm thấy khác dữ liệu cần ở đâu, và baseline đơn giản đã giúp bạn bắt được lỗi gì. Trong phỏng vấn FDE, những quyết định này thuyết phục hơn bất kỳ con số accuracy nào.

Thuật toán sẽ còn đổi nhiều lần. Còn phần việc không ai muốn khoe, tức đặt đúng bài toán và tự nhìn dữ liệu, vẫn là lý do khách hàng thuê FDE.

**Thử ngay tuần này:**

- Lấy một yêu cầu thật của khách hàng, viết ra input, output và nhãn cần có, rồi kiểm tra xem dữ liệu hiện có có chứa đúng cặp đó không
- Mở dữ liệu của dự án đang làm và tự đọc vài chục mẫu, ghi lại mọi thứ trông bất thường
- Thay model trong pipeline bằng một luật if-else và chạy từ đầu đến cuối để xem lỗi nằm ở đâu

## Nguồn

- [Book – mlpowered (Emmanuel Ameisen)](https://www.mlpowered.com/book/)

- [Building Machine Learning Powered Applications: Going from Idea to Product – Open Library](https://openlibrary.org/isbn/9781492045113)

- [ml-powered-applications README (GitHub)](https://github.com/hundredblocks/ml-powered-applications/blob/master/README.md)

- [Course notes: Building Machine Learning Powered Applications (niazangels, GitHub)](https://github.com/niazangels/course-notes/blob/master/building-machine-learning-powered-applications)

- [Book Review: Building Machine Learning Powered Applications](https://talkingtocomputers.substack.com/p/book-review-building-machine-learning)

- [Book Review: Building Machine Learning Powered Applications (DEV Community)](https://dev.to/vidyabhandary/book-review-building-machine-learning-powered-applications-59c9)