Trong nhiều dự án Machine Learning, vấn đề không nằm ở việc mô hình có chạy được hay không, mà là: vài tuần sau, không ai tái tạo lại được kết quả đã từng báo cáo. Cùng một notebook, cùng một ý tưởng, nhưng chỉ cần dữ liệu thay đổi, thư viện được cập nhật, hoặc bước tiền xử lý bị chỉnh nhẹ là chỉ số đã khác. Với dự án nhỏ, điều này gây khó chịu. Với sản phẩm thật, nó có thể khiến nhóm mất niềm tin vào toàn bộ quy trình thử nghiệm. Tái lập thí nghiệm không có nghĩa là mọi lần chạy đều cho kết quả giống tuyệt đối trong mọi môi trường. Mục tiêu thực tế hơn là: khi cần kiểm tra lại một kết quả, nhóm biết chính xác dữ liệu nào đã dùng, mã nguồn nào đã chạy, tham số nào đã đặt và mô hình nào đã được sinh ra. Một thí nghiệm ML nên ghi lại những gì? 1. Phiên bản dữ liệu Không nên chỉ ghi “dùng file train.csv”. Cần biết file đó được tạo từ nguồn nào, vào thời điểm nào, có áp dụng bộ lọc nào không. Ví dụ, với bài toán dự đoán khách hàng rời bỏ dịch vụ, tập huấn luyện có thể phụ thuộc vào ngày chốt dữ liệu. Nếu hôm nay truy vấn lại cơ sở dữ liệu mà không cố định mốc thời gian, bạn có thể đang huấn luyện trên một tập khác. Lời khuyên thực tế: lưu snapshot dữ liệu, mã truy vấn, hoặc ít nhất là mã băm/checksum của file dữ liệu đầu vào. 2. Phiên bản mã nguồn Notebook rất tiện để khám phá, nhưng dễ trở thành nơi chứa nhiều ô lệnh chạy không theo thứ tự. Khi kết quả bắt đầu quan trọng, hãy đưa các bước chính vào script hoặc pipeline rõ ràng: tải dữ liệu, xử lý đặc trưng, huấn luyện, đánh giá. Mỗi thí nghiệm nên gắn với một commit cụ thể trong hệ thống quản lý mã nguồn. Khi ai đó hỏi “mô hình này được huấn luyện bằng code nào?”, câu trả lời không nên là “chắc là bản tuần trước”. 3. Tham số và cấu hình Các tham số như learning rate, số cây, độ sâu mô hình, batch size, seed ngẫu nhiên, cách chia train/validation đều cần được ghi lại. Nhiều nhóm chỉ lưu kết quả cuối cùng mà quên lưu cấu hình, dẫn đến việc không biết vì sao mô hình A tốt hơn mô hình B. Một cách đơn giản là đặt toàn bộ cấu hình vào file YAML/JSON hoặc dùng công cụ theo dõi thí nghiệm. Dù dùng công cụ nào, nguyên tắc là cấu hình phải nằm ngoài trí nhớ của lập trình viên. 4. Môi trường chạy Khác phiên bản thư viện cũng có thể làm kết quả thay đổi. Ví dụ, một phiên bản mới của thư viện xử lý dữ liệu có thể thay đổi hành vi mặc định, hoặc thư viện học máy cập nhật thuật toán tối ưu. Vì vậy, nên lưu requirements.txt, environment.yml hoặc Dockerfile cho các thí nghiệm quan trọng. Nếu dự án có dùng GPU, cũng nên ghi lại loại GPU, phiên bản CUDA, framework và các cài đặt liên quan. Không phải lúc nào cũng cần tuyệt đối giống nhau, nhưng có thông tin để điều tra khi kết quả lệch là rất quan trọng. 5. Kết quả đánh giá và artefact mô hình Ngoài metric tổng như accuracy, F1 hoặc RMSE, nên lưu cả kết quả theo từng nhóm dữ liệu nếu bài toán có rủi ro lệch phân phối. Ví dụ, mô hình phân loại hồ sơ có thể đạt điểm trung bình tốt nhưng kém trên một nhóm khách hàng mới. Artefact mô hình cũng cần được lưu có tổ chức: file trọng số, bộ mã hóa đặc trưng, tokenizer, scaler, danh sách cột đầu vào. Một lỗi phổ biến là chỉ lưu model mà quên lưu bước tiền xử lý, khiến lúc triển khai dự đoán không khớp với lúc huấn luyện. Một quy trình tối thiểu có thể áp dụng ngay Nếu nhóm chưa có hệ thống phức tạp, có thể bắt đầu bằng quy trình đơn giản: - Mỗi lần chạy thí nghiệm tạo một thư mục riêng theo thời gian hoặc mã run. - Lưu file cấu hình tham số. - Lưu phiên bản commit của mã nguồn. - Lưu thông tin dữ liệu đầu vào hoặc đường dẫn snapshot. - Lưu metric, biểu đồ quan trọng và mô hình đầu ra. - Ghi chú ngắn: mục tiêu thí nghiệm là gì, thay đổi gì so với lần trước, kết luận gì. Ví dụ, thay vì đặt tên file là model_final.pkl, hãy đặt theo dạng có ý nghĩa hơn như churn_xgb_2026-08-05_run23.pkl và đi kèm config_run23.json, metrics_run23.json. Tên file không thay thế được hệ thống quản lý thí nghiệm, nhưng nó tốt hơn rất nhiều so với một thư mục lộn xộn đầy “final”, “final2”, “best_new”. Khi nào cần đầu tư công cụ chuyên nghiệp? Khi số lượng thí nghiệm tăng, nhiều người cùng làm, hoặc mô hình bắt đầu ảnh hưởng tới sản phẩm thật, nên dùng công cụ tracking thí nghiệm và quản lý model registry. Công cụ chỉ là phương tiện; điều quan trọng là nhóm thống nhất quy ước: cái gì phải được ghi lại, ai chịu trách nhiệm, khi nào một mô hình được coi là đủ điều kiện triển khai. Tái lập thí nghiệm nghe có vẻ như việc phụ, nhưng thực ra là nền móng của làm AI nghiêm túc. Một mô hình tốt mà không ai tái tạo được thì rất khó bảo trì, khó kiểm chứng và khó cải thiện. Ngược lại, một quy trình ghi chép rõ ràng giúp nhóm học nhanh hơn từ mỗi lần thử, so sánh công bằng hơn giữa các phương án và giảm đáng kể rủi ro khi đưa mô hình vào thực tế.