# ISLP cho FDE: đọc chương nào trước, chương nào để dành > Lần đầu khách hàng hỏi "con số 92% này có tin được không", bạn sẽ cần mấy chương thống kê kinh điển này hơn mọi framework mới ra. Bản gốc: https://fdetimes.net/vi/sach-khoa-hoc/sach-introduction-to-statistical-learning-with-python/ Sách học máy thường già đi chỉ sau vài năm. An Introduction to Statistical Learning thì ngược lại: bản đầu ra năm 2013, bản R thứ hai năm 2021, rồi đến năm 2023 nhóm tác giả ra thêm bản Python với tên ISLP. Sau mười năm và ba ấn bản, nhóm tác giả vẫn thấy cuốn sách đáng viết lại cho một ngôn ngữ mới. Riêng điều đó đã cho thấy nội dung của nó bền đến mức nào. Với một Forward Deployed Engineer, phần cốt lõi của cuốn sách chính là kỹ năng hay bị bỏ qua nhất: đánh giá trung thực xem một mô hình có chạy được trên dữ liệu của khách hàng hay không. Agent, RAG hay eval cho LLM thực chất đều dựa trên những câu hỏi thống kê mà cuốn sách đã đặt ra từ lâu. Vì vậy, câu hỏi đáng trả lời không phải là có nên đọc ISLP hay không. Câu hỏi là đọc chương nào trước để tuần sau mang vào dự án dùng được ngay. ## Một cuốn sách viết cho người làm, không phải người chứng minh Trên trang chính thức statlearning.com, nhóm tác giả mô tả sách là một cách trình bày rộng và ít nặng kỹ thuật về các chủ đề chính của statistical learning. Nói cách khác, sách không bắt bạn chứng minh định lý. Sách muốn bạn hiểu vì sao một phương pháp chạy được và khi nào nó hỏng. Thứ làm ISLP hợp với FDE là bài lab ở cuối mỗi chương, trong đó khái niệm của chương được chạy thành code Python. Sách đi kèm thư viện ISLP, và theo tài liệu tại islp.readthedocs.io, có lab cho các chương từ 2 đến 13. Repo GitHub chính thức intro-stat-learning/ISLP_labs cập nhật lab theo mã nguồn của thư viện. Mục tiêu repo đặt ra là chỉ cần dựng môi trường ảo từ `requirements.txt` là tái lập được các kết quả trong đó. Với FDE, tính tái lập ấy có giá trị rất thực tế. Một notebook tái lập được là thứ bạn có thể mở ngay trong cuộc họp với khách hàng, thay vì chỉ kể lại những gì mình nhớ từ sách. Bản Python có thể mua qua Springer, và trang chính thức cũng có link tải PDF. ## Nên đọc theo thứ tự nào? Hãy bắt đầu bằng lab nhập môn ở chương 2. Repo hướng dẫn chạy nó bằng `uv run jupyter lab Ch02-statlearn-lab.ipynb`. Tiếp theo là hồi quy tuyến tính, vì đây là baseline bạn sẽ dựng trước tiên ở hầu như mọi dự án dữ liệu bảng. Sau đó, hãy đi thẳng vào ba nhóm chủ đề mà trang chính thức liệt kê và FDE cần nhất: resampling (cross-validation và bootstrap), regularization, và tree-based methods. Unsupervised learning để ngay sau, vì tuần đầu của một dự án thường là lúc bạn khám phá dữ liệu chưa có nhãn. Các chương bản Python bổ sung về deep learning, survival analysis và multiple testing nằm ở cuối sách. Cứ để dành chúng. Survival analysis đáng đọc khi khách hàng hỏi "bao lâu nữa thì khách rời bỏ" hoặc "bao lâu nữa thì máy hỏng". Multiple testing đáng đọc khi bạn bắt đầu chạy hàng chục thí nghiệm cùng lúc. ## Ý thứ nhất: con số chấm trên tập train là con số nói dối Thử hình dung khách hàng gửi 1.000 dòng dữ liệu kèm một mô hình mà vendor cũ báo đạt 92% accuracy. Nếu con số đó được chấm trên chính dữ liệu đã dùng để huấn luyện, nó gần như chẳng nói lên gì. 5-fold cross-validation chia 1.000 dòng thành 5 phần, mỗi phần 200 dòng. Mỗi lượt, mô hình học trên 800 dòng và bị chấm trên 200 dòng nó chưa từng thấy. Nếu con số trung bình rơi xuống quanh 70%, bạn vừa tìm ra vấn đề thật của dự án, trước khi nó kịp thành sự cố trên production. Bootstrap, phần còn lại của nhóm resampling, cho bạn thêm một khoảng dao động quanh con số đó. Trình bày cho ban giám đốc một khoảng như vậy trung thực hơn nhiều so với một con số duy nhất. **Điểm mấu chốt:** Đừng báo cáo con số nào mà mô hình đã nhìn thấy đáp án từ trước. ## Ý thứ hai: thêm biến không miễn phí Dữ liệu của khách hàng thường có hàng trăm cột: mã cửa hàng, ngày nhập liệu, cột nào cũng có vẻ hữu ích. Regularization dạy bạn phạt những mô hình quá phức tạp, để chúng không học thuộc nhiễu trong dữ liệu. Khi nhận được một bảng dữ liệu như vậy, việc đầu tiên nên làm là so mô hình đầy đủ với mô hình đã regularize, cả hai đều chấm bằng cross-validation. Nếu bản đơn giản hơn ngang ngửa hoặc tốt hơn, bạn vừa có mô hình dễ giải thích hơn vừa có một pipeline dữ liệu gọn hơn để vận hành. ## Ý thứ ba: cây quyết định là baseline khách hàng đọc được Tree-based methods hay bị coi là cũ, nhưng với FDE chúng là công cụ để trao đổi với khách hàng. Một cây nông có thể in ra dạng "nếu đơn hàng trên ngưỡng X và khách mới, rủi ro cao". Người vận hành bên khách hàng đọc được câu đó và cãi lại được nếu thấy sai, và chính lúc họ cãi lại là lúc bạn học được về nghiệp vụ. Lời khuyên ở đây: dựng một cây đơn giản trước, cho chuyên gia nghiệp vụ xem, rồi mới tính đến những mô hình phức tạp hơn. ## Khi nào cross-validation cũng cho số sai? Cross-validation chỉ trung thực khi bạn dùng nó đúng cách. Lỗi hay gặp nhất là chỉnh tham số trên chính các fold rồi báo luôn con số trên các fold đó. Nếu thử 50 mức regularization và chọn mức đẹp nhất, con số tốt nhất ấy đã được chọn lọc, nên gần như chắc chắn cao hơn thực tế. Cách sửa là giữ riêng một tập test không đụng tới cho đến bước cuối, hoặc lồng thêm một vòng cross-validation bên trong chỉ để chọn tham số. Cùng logic đó áp dụng cho chuẩn hóa hay chọn biến: bước nào học từ dữ liệu thì phải chạy bên trong từng fold, không chạy trước trên toàn bộ bảng. Lỗi thứ hai khó thấy hơn: rò rỉ cột đích. Thử hình dung bài toán dự đoán khách rời bỏ, trong bảng có cột "ngày hủy hợp đồng". Cột này chỉ có giá trị khi khách đã rời đi, nên mô hình đoán gần đúng hết trong cross-validation rồi sụp đổ trên production. Thói quen nên có: trước khi huấn luyện, ngồi với chuyên gia nghiệp vụ và hỏi từng cột một câu duy nhất, "vào lúc cần dự đoán, cột này đã có giá trị chưa?". Một con số đẹp bất thường thường là tín hiệu đầu tiên của rò rỉ. ## Biến việc đọc sách thành bằng chứng khi đi xin việc Vì thế, hãy biến các lab thành một repo riêng: chọn một bộ dữ liệu công khai, đặt con số chấm trên tập train cạnh con số cross-validation, và viết phần giải thích cho một người quản lý không làm kỹ thuật. Trong CV, hãy mô tả việc bạn làm bằng kết quả, ví dụ "phát hiện mô hình bị overfit bằng cross-validation", thay vì ghi "đã học ISLP". Khi đọc mô tả công việc, nếu thấy yêu cầu đánh giá mô hình trên dữ liệu thật hoặc giải thích kết quả cho người không làm kỹ thuật, hãy đưa repo ấy lên đầu hồ sơ. Framework sẽ còn thay đổi nhiều lần nữa. Còn câu hỏi "con số này có tin được không" thì khách hàng nào cũng sẽ hỏi, và ba nhóm chương ở giữa cuốn sách này giúp bạn trả lời được nó. **Thử ngay tuần này:** - Clone repo intro-stat-learning/ISLP_labs, dựng môi trường từ requirements.txt rồi chạy `uv run jupyter lab Ch02-statlearn-lab.ipynb` - Lấy một bộ dữ liệu công khai, so accuracy khi chấm trên chính tập train với accuracy khi chạy 5-fold cross-validation, rồi ghi lại chênh lệch giữa hai con số - Viết một trang README giải thích, cho người không làm kỹ thuật, vì sao bạn tin con số cross-validation hơn ## Nguồn - [An Introduction to Statistical Learning (statlearning.com)](https://www.statlearning.com/) - [ISLP documentation (islp.readthedocs.io)](https://islp.readthedocs.io/en/latest/) - [intro-stat-learning/ISLP_labs (GitHub)](https://github.com/intro-stat-learning/ISLP_labs)