Phân biệt chiến dịch, cấu hình và lần chạy
Một chiến dịch mang một câu hỏi, ví dụ so sánh một mốc tham chiếu với một bản điều chỉnh. Một cấu hình mô tả các lựa chọn kỹ thuật. Một run là một lần thử chạy cấu hình đó, với một seed, thời điểm bắt đầu, thời điểm kết thúc và trạng thái. Do đó hai lần thử giống hệt nhau vẫn giữ hai mã định danh, kể cả khi lần thứ hai thay thế một lần chạy bị gián đoạn.
Hãy thêm mã định danh đánh giá khi cùng một artifact được đánh giá trên nhiều tập dữ liệu hoặc với một chỉ số mới. Điều này tránh nhầm lẫn một mô hình mới với một cách đọc mới của mô hình hiện có. Hãy nối lần thử khôi phục với lần thử trước đó và với checkpoint đã nạp.
MLflow cũng tổ chức việc theo dõi quanh các run, tham số, chỉ số và artifact. Sự phân biệt này hữu ích ngay cả trong một thư mục tệp đơn giản. Bạn có thể áp dụng nó với công cụ quen thuộc của mình; không cần một nền tảng theo dõi cụ thể nào để bắt đầu.
Nguồn kỹ thuật: MLflow — run, tham số, chỉ số và artifact
Viết manifest thực sự đã chạy
Hãy giữ các tham số đã được giải quyết sau khi áp dụng giá trị mặc định và các đối số khởi chạy. Tệp cấu hình gốc có thể bỏ sót một batch mặc định hoặc một tùy chọn đã bị sửa lúc chạy. Hãy ghi lại những gì thực sự đã được dùng, kèm một bản sao mã hoặc một revision bất biến và trạng thái của các thay đổi chưa lưu.
Manifest cũng nối các phiên bản của mô hình và tokenizer, môi trường phần mềm, GPU thực sự được dùng, độ chính xác, dữ liệu, seed và định nghĩa các chỉ số. Nó mô tả lần thử, chứ không trở thành một hướng dẫn cài đặt. Hãy ghi rõ đơn vị: giây, byte, token, điểm hoặc tỷ lệ trên 0 đến 1 tùy theo phép đo.
Khi khởi động, trạng thái là đang chạy; khi kết thúc, nó trở thành hoàn tất, thất bại hoặc bị gián đoạn tùy theo những gì bạn quan sát được. Đừng bổ sung sau đó một phiên bản bị bỏ quên bằng phiên bản hiện đang được cài. Hãy đánh dấu thông tin chưa biết và giới hạn kết luận phụ thuộc vào nó.
| Khối | Các yếu tố cần giữ | Câu hỏi được giải đáp |
|---|---|---|
| Danh tính | campaign_id, config_id, run_id, parent_run_id nếu có | Lần thử nào tạo ra kết quả này? |
| Mã và mô hình | Các revision chính xác, thay đổi cục bộ, mô hình cơ sở và tokenizer | Phép tính nào thực sự đã được chạy? |
| Dữ liệu | Phiên bản, split, tiền xử lý, mã định danh và thứ tự liên quan | Trên những đầu vào nào? |
| Tham số | Giá trị thực tế, seed và đơn vị | Với những thiết lập nào? |
| Đánh giá | Artifact được đánh giá, chỉ số/phiên bản, ngưỡng và tập hợp | Điểm số có ý nghĩa gì? |
| Kết thúc | Trạng thái, lỗi, tệp được tạo và quyết định | Lần thử có thể khai thác được không? |
Nhận diện dữ liệu ngoài tên thư mục
Một đường dẫn như donnees/final không chỉ định một phiên bản ổn định. Hãy giữ bản kiểm kê các tệp hoặc ví dụ, các split và quy trình biến đổi. Nếu bạn sửa nhãn hoặc lọc dòng, hãy tạo một phiên bản mới và giữ mối liên hệ với phiên bản trước. Điểm số cũ phải tiếp tục trỏ tới dữ liệu cũ của nó.
Hugging Face Datasets gắn các fingerprint với trạng thái của một bộ dữ liệu và các biến đổi của nó để quản lý cache. Cơ chế này hữu ích, nhưng cũng cần giữ nguồn gốc dữ liệu và tiền xử lý. Một biến đổi không thể băm được có thể dẫn đến một fingerprint ngẫu nhiên: mã định danh cache không tự nó thay thế được hồ sơ nguồn gốc của bạn.
Với các artifact cố định, hãy thêm kích thước và dấu vân tay tệp. Một digest SHA-256 được tính trước và sau khi sao chép cho phép kiểm tra rằng các byte khớp với tham chiếu được giữ lại. Nó không chứng minh chất lượng nhãn, quyền sử dụng, cũng không chứng minh không có rò rỉ giữa các split.
Nguồn kỹ thuật: Hugging Face Datasets — fingerprint và biến đổi · Python 3.14 — dấu vân tay tệp với hashlib
Nối chỉ số, dự đoán và artifact
Một dòng chỉ số nên xác định rõ run, artefact được đánh giá, tập đánh giá, phiên bản của chỉ số và phạm vi của nó. Hãy nêu rõ giá trị đó thuộc về một checkpoint trung gian, mô hình cuối cùng hay một nhóm con. Một đường cong là chưa đủ nếu ta không còn biết tệp nào tương ứng với điểm được chọn.
Hãy lưu giữ các dự đoán kèm theo mã định danh đầu vào, trạng thái và những thông tin cần thiết cho việc đánh giá. Các tham chiếu mong đợi có thể nằm trong một tệp riêng được đánh phiên bản. Với đầu ra có cấu trúc, hãy phân biệt kết quả thô, kết quả đã phân tích cú pháp và phán quyết: việc sửa lỗi phân tích cú pháp không được ghi đè lên đầu ra ban đầu.
MLflow cho phép liên kết các chỉ số với mô hình và dữ liệu. Với các tệp, hãy áp dụng nguyên tắc tương tự bằng các mã định danh tường minh. Giữ một bản kiểm kê dễ đọc các artefact: trọng số hoặc bộ thích ứng, tham số sinh, đầu ra, báo cáo đánh giá và ghi chú quyết định. Đừng cho rằng một ảnh chụp màn hình có thể thay thế những tệp này.
Nguồn kỹ thuật: MLflow — liên kết chỉ số, mô hình và tập dữ liệu
Ví dụ: sáu run và một bản trùng lặp che giấu một thiếu sót
Hãy xét một ví dụ về bài toán xếp hạng với hai cấu hình và ba hạt giống. Nó tạo ra sáu run dự kiến. Mỗi run phải dự đoán cùng 300 mã định danh đánh giá: thư mục đầy đủ vì thế cần 6 × 300 = 1 800 cặp duy nhất (run_id, input_id). Phép tính này mô tả một bản kiểm kê mong đợi, không phải một thí nghiệm đã thực sự được chạy.
Giả sử một tệp chứa 300 dòng, nhưng mã định danh doc-042 xuất hiện hai lần và doc-117 bị thiếu. Tổng số dòng có vẻ đúng; tuy nhiên chỉ có 299 mã định danh duy nhất. Run này không đạt kiểm tra độ phủ cho đến khi bất thường được giải thích và khắc phục.
Nếu sau đó mỗi run được đánh giá trên toàn bộ corpus và trên nhóm con các văn bản dài của nó, bạn thu được mười hai dòng chỉ số cho một chỉ số nhất định. Đó vẫn là sáu run, không phải mười hai lần huấn luyện độc lập. Khóa đánh giá phải bao gồm phạm vi để giữ nguyên sự phân biệt này.
| Kiểm tra | Mong đợi | Bất thường minh họa |
|---|---|---|
| Run | 2 cấu hình × 3 hạt giống = 6 | Một lần chạy lại nhận một mã định danh mới |
| Dự đoán theo mỗi run | 300 mã định danh duy nhất được mong đợi | 300 dòng nhưng chỉ có 299 mã định danh duy nhất |
| Cặp run/đầu vào | 6 × 300 = 1 800 | Chỉ riêng tổng số không phát hiện được mọi bản trùng lặp |
| Đánh giá | 6 run × 2 phạm vi = 12 | Mười hai điểm số không tạo ra mười hai run |
Khép lại hồ sơ bằng một quyết định dễ đọc
Trước khi tuyên bố một run đã hoàn tất, hãy kiểm tra sự hiện diện và khả năng mở của các tệp, sự khớp của các mã định danh, các chỉ số có thể tính lại và trạng thái của từng lỗi. Một lần thử đã hoàn tất về mặt kỹ thuật vẫn có thể bị từ chối vì chất lượng không đủ. Hãy giữ hai trạng thái này tách biệt.
Ghi chú quyết định tập hợp câu hỏi, các biến thể được so sánh, tiêu chí đã công bố, các kết quả được chọn và lý do loại trừ. Hãy trích dẫn các run_id và đường dẫn artefact thay vì “mô hình mới nhất”. Thêm vào các giới hạn: ít lần lặp lại, nhóm con không đủ, phiên bản không tìm thấy hoặc so sánh trở nên bất khả thi.
Một chỉnh sửa về sau phải để lại dấu vết: đánh giá mới, báo cáo mới và lý do thay đổi. Hãy giữ kết luận cũ như một phiên bản lịch sử được định danh, không để nó xuất hiện như quyết định hiện tại. Cuối cùng, hãy kiểm tra rằng bản sao đã xuất mở được từ thư mục đích của nó.
Tránh thu thập không cần thiết và những lời hứa về tái lập
Hãy thu thập các trường cần thiết cho bằng chứng, không phải mọi biến môi trường hay lịch sử terminal. Một cấu hình hoặc một URL có thể chứa token; hãy chuẩn bị một phiên bản chia sẻ được không có bí mật và giữ dữ liệu cần riêng tư ở đúng vị trí được phép. Các mã định danh kỹ thuật của lần thử không cần phải bao gồm tên của một người.
Một hồ sơ đầy đủ cải thiện khả năng làm lại và hiểu một thí nghiệm. Nó không bảo đảm sự bằng nhau về mặt con số giữa các nền tảng hay phiên bản: PyTorch ghi lại những giới hạn tái lập này. Hãy phân biệt việc tìm lại giao thức, tải lại artefact và tái lập chính xác các con số.
Sổ tay IteraGPU có thể lưu giữ mục tiêu, tham số và quyết định của bạn, cùng các tham chiếu hữu ích. Nó không chạy các run cũng không tự động thu thập tệp hay dữ liệu đo từ xa. Hãy dùng nó như chỉ mục cho lập luận của bạn và giữ hồ sơ artefact trong các bản sao lưu của riêng bạn.
Nguồn kỹ thuật: PyTorch 2.14 — giới hạn khả năng tái lập giữa các môi trường
Câu hỏi thực tế
Một commit Git có đủ để tìm lại một thí nghiệm không?
Một commit xác định một phiên bản mã nguồn, nhưng không nhất thiết xác định dữ liệu, trọng số, các tham số thực tế hay những thay đổi chưa được lưu lại. Hãy kết hợp nó với một manifest và các artifact được tạo ra. Nếu thiếu những liên kết này, hai lần chạy cùng một commit có thể tương ứng với hai thí nghiệm khác nhau.
Có nên giữ lại tất cả các dự đoán không?
Hãy giữ lại các đầu ra cần thiết để kiểm chứng kết luận và tính lại đánh giá, trong giới hạn về quyền và ràng buộc lưu trữ của bạn. Với một tập dữ liệu so sánh có giới hạn, các định danh và dự đoán đầy đủ giúp các lỗi có thể kiểm tra được. Một điểm số tổng hợp đơn thuần thường không cho phép tìm lại các mẫu còn thiếu.
Một lần chạy lại có nên dùng cùng run_id không?
Schema được đề xuất cấp một định danh mới cho mỗi lần thử và liên kết lần chạy lại với lần chạy trước đó cũng như với checkpoint đã nạp. Bạn có thể nhóm các lần thử này dưới cùng một thí nghiệm logic. Sự tách biệt này giúp thấy rõ việc gián đoạn, chi phí và các tệp thực sự được tạo ra ở mỗi bước.