Câu hỏi hay.
Tôi đã bắt gặp hiện tượng này vài lần. Đây là những quan sát của tôi:
Gradient thổi lên
Lý do: độ dốc lớn khiến quá trình học tập đi chệch hướng.
Những gì bạn nên mong đợi: Nhìn vào nhật ký thời gian chạy, bạn nên xem các giá trị mất mát mỗi lần lặp. Bạn sẽ nhận thấy rằng tổn thất bắt đầu tăng lên đáng kể từ lần lặp lại, cuối cùng tổn thất sẽ quá lớn để được biểu diễn bằng một biến dấu phẩy động và nó sẽ trở thành nan.
Bạn có thể làm gì: Giảm base_lr(trong solver.prototxt) theo thứ tự độ lớn (ít nhất). Nếu bạn có nhiều lớp mất mát, bạn nên kiểm tra nhật ký để xem lớp nào chịu trách nhiệm cho việc thổi tăng độ dốc và giảm loss_weight(trong train_val.prototxt) cho lớp cụ thể đó, thay vì lớp chung base_lr.
Chính sách tỷ lệ học tập kém và các thông số
Lý do: caffe không tính được tỷ lệ học hợp lệ và nhận được 'inf'hoặc 'nan'thay vào đó, tỷ lệ không hợp lệ này sẽ nhân tất cả các bản cập nhật và do đó làm mất hiệu lực của tất cả các thông số.
Những gì bạn nên mong đợi: Nhìn vào nhật ký thời gian chạy, bạn sẽ thấy rằng bản thân tốc độ học tập sẽ trở thành 'nan', ví dụ:
... sgd_solver.cpp:106] Iteration 0, lr = -nan
Bạn có thể làm gì: sửa tất cả các thông số ảnh hưởng đến tốc độ học tập trong 'solver.prototxt'tệp của bạn .
Ví dụ: nếu bạn sử dụng lr_policy: "poly"và bạn quên xác định max_itertham số, bạn sẽ kết thúc với lr = nan...
Để biết thêm thông tin về tốc độ học trong caffe, hãy xem chủ đề này .
Chức năng Mất mát
Lý do: Đôi khi việc tính toán tổn thất trong các lớp tổn thất làm nanxuất hiện s. Ví dụ: InfogainLossLớp cấp dữ liệu với các giá trị không chuẩn hóa , sử dụng lớp mất mát tùy chỉnh có lỗi, v.v.
Những gì bạn nên mong đợi: Nhìn vào nhật ký thời gian chạy, bạn có thể sẽ không nhận thấy bất kỳ điều gì bất thường: tổn thất đang giảm dần và đột nhiên nanxuất hiện.
Bạn có thể làm gì: Xem liệu bạn có thể tái tạo lỗi hay không, thêm bản in vào lớp mất mát và gỡ lỗi.
Ví dụ: Một khi tôi sử dụng lỗ đã chuẩn hóa hình phạt bằng tần suất xuất hiện nhãn trong một đợt. Nó chỉ xảy ra như vậy nếu một trong các nhãn đào tạo hoàn toàn không xuất hiện trong lô - tổn thất được tính toán tạo ra nans. Trong trường hợp đó, làm việc với các lô đủ lớn (đối với số lượng nhãn trong tập hợp) là đủ để tránh lỗi này.
Đầu vào bị lỗi
Lý do: bạn có một đầu vào với nantrong đó!
Những gì bạn nên mong đợi: một khi quá trình học tập "chạm" vào đầu vào - đầu ra bị lỗi này sẽ trở thành nan. Nhìn vào nhật ký thời gian chạy, bạn có thể sẽ không nhận thấy bất cứ điều gì bất thường: tổn thất đang giảm dần và đột nhiên nanxuất hiện.
Bạn có thể làm gì: xây dựng lại bộ dữ liệu đầu vào của mình (lmdb / leveldn / hdf5 ...) đảm bảo rằng bạn không có tệp hình ảnh xấu trong bộ đào tạo / xác thực của mình. Để gỡ lỗi, bạn có thể xây dựng một mạng đơn giản đọc lớp đầu vào, có lỗ giả ở trên và chạy qua tất cả các đầu vào: nếu một trong số chúng bị lỗi, mạng giả này cũng sẽ tạo ra nan.
sải bước lớn hơn kích thước hạt nhân trong "Pooling"lớp
Vì một số lý do, việc chọn stride> kernel_sizeđể gộp có thể dẫn đến nans. Ví dụ:
layer {
name: "faulty_pooling"
type: "Pooling"
bottom: "x"
top: "y"
pooling_param {
pool: AVE
stride: 5
kernel: 3
}
}
kết quả với nans trong y.
Bất ổn trong "BatchNorm"
Người ta báo cáo rằng trong một số "BatchNorm"lớp cài đặt có thể xuất ra nando sự không ổn định về số.
Đây vấn đề được nêu ra trong bvlc / caffe và PR # 5136 đang cố gắng sửa chữa nó.
Gần đây, tôi đã biết về debug_infocờ: thiết lập debug_info: truein 'solver.prototxt'sẽ làm cho bản in caffein để ghi thêm thông tin gỡ lỗi (bao gồm cường độ gradient và giá trị kích hoạt) trong quá trình đào tạo: Thông tin này có thể giúp phát hiện các lỗi gradient và các vấn đề khác trong quá trình đào tạo .