प्रशिक्षण के दौरान नैन के सामान्य कारण

Question 1

मैंने देखा है कि प्रशिक्षण के दौरान अक्सर होने वाली घटना NANको पेश किया जा रहा है।

अक्सर कई बार ऐसा लगता है कि यह इनर-प्रोडक्ट / फुल-कनेक्टेड या कनवल्शन लेयर्स में वज़न बढ़ा रहा है।

क्या ऐसा इसलिए हो रहा है क्योंकि ढाल की संगणना बह रही है? या यह वजन आरंभीकरण के कारण है (यदि हां, तो वजन आरंभीकरण का यह प्रभाव क्यों है)? या क्या यह इनपुट डेटा की प्रकृति के कारण होता है?

यहाँ अतिव्यापी प्रश्न बस है: प्रशिक्षण के दौरान नान के लिए सबसे आम कारण क्या है? और दूसरी बात, इसका मुकाबला करने के लिए कुछ तरीके क्या हैं (और वे काम क्यों करते हैं)?

Question 2

अच्छा प्रश्न।
मुझे इस घटना के बारे में कई बार पता चला। यहाँ मेरी टिप्पणियों हैं:

धीरे-धीरे झटका

कारण: बड़े ग्रेडिएंट सीखने की प्रक्रिया को बंद कर देते हैं।

आपको क्या उम्मीद करनी चाहिए: रनटाइम लॉग को देखते हुए, आपको प्रति चलना नुकसान मानों को देखना चाहिए। आप ध्यान देंगे कि नुकसान की शुरुआत से पुनरावृत्ति में काफी वृद्धि होने लगती है , अंततः नुकसान एक अस्थायी बिंदु चर द्वारा प्रतिनिधित्व करने के लिए बहुत बड़ा होगा और यह बन जाएगा nan।

आप क्या कर सकते हैं:base_lr (कम से कम) परिमाण के क्रम से (solver.prototxt में) घटाएं । यदि आपके पास कई नुकसान परतें हैं, तो आपको यह देखने के लिए लॉग का निरीक्षण करना चाहिए कि कौन सी परत ढाल के लिए जिम्मेदार है और loss_weightसामान्य के बजाय उस विशिष्ट परत के लिए (train_val.prototxt में) कमी करें base_lr।

खराब सीखने की दर नीति और पारमेस

कारण: Caffe एक वैध सीखने दर की गणना करने में विफल रहता है और हो जाता है 'inf'या 'nan'बजाय, इस अवैध दर पलता सभी अद्यतन और इस प्रकार सभी मापदंडों अमान्य।

आपको क्या उम्मीद करनी चाहिए: रनटाइम लॉग को देखते हुए, आपको यह देखना चाहिए कि सीखने की दर स्वयं बन जाती है 'nan', उदाहरण के लिए:

... sgd_solver.cpp:106] Iteration 0, lr = -nan

आप क्या कर सकते हैं: अपनी 'solver.prototxt'फ़ाइल में सीखने की दर को प्रभावित करने वाले सभी मापदंडों को ठीक करें ।
उदाहरण के लिए, यदि आप उपयोग करते हैं lr_policy: "poly"और आप max_iterपैरामीटर को परिभाषित करना भूल जाते हैं , तो आप समाप्त कर देंगे lr = nan...
कैफ में सीखने की दर के बारे में अधिक जानकारी के लिए, यह धागा देखें ।

दोषपूर्ण नुकसान समारोह

कारण: कभी-कभी नुकसान परतों में नुकसान की गणना nanदिखाई देने लगती है। उदाहरण के लिए, InfogainLossगैर-सामान्यीकृत मूल्यों के साथ खिला परत , कीड़े के साथ कस्टम हानि परत का उपयोग करना, आदि।

आपको क्या उम्मीद करनी चाहिए: रनटाइम लॉग को देखते हुए आप शायद कुछ भी असामान्य नहीं देखेंगे: नुकसान धीरे-धीरे कम हो रहा है, और अचानक nanप्रकट होता है।

आप क्या कर सकते हैं: देखें कि क्या आप त्रुटि को पुन: उत्पन्न कर सकते हैं, हानि परत में प्रिंटआउट जोड़ें और त्रुटि को डीबग करें।

उदाहरण के लिए: एक बार जब मैंने एक नुकसान का उपयोग किया था जो एक बैच में लेबल घटना की आवृत्ति द्वारा जुर्माना को सामान्य करता है। यह सिर्फ इतना हुआ कि यदि प्रशिक्षण लेबल में से एक बैच में बिल्कुल भी प्रकट नहीं हुआ - नुकसान की गणना उत्पादित nanएस। उस स्थिति में, इस त्रुटि से बचने के लिए बड़े पर्याप्त बैचों (सेट में लेबल की संख्या के संबंध में) के साथ काम करना पर्याप्त था।

दोषपूर्ण इनपुट

कारण: आपके पास nanइसके साथ एक इनपुट है!

आपको क्या उम्मीद करनी चाहिए: एक बार सीखने की प्रक्रिया इस दोषपूर्ण इनपुट "हिट" के बाद - आउटपुट बन जाती है nan। रनटाइम लॉग को देखते हुए आप शायद कुछ भी असामान्य नहीं देखेंगे: नुकसान धीरे-धीरे कम हो रहा है, और अचानक nanप्रकट होता है।

आप क्या कर सकते हैं: अपने इनपुट डेटासेट (lmdb / leveldn / hdf5 ...) को फिर से बनाएं, सुनिश्चित करें कि आपके पास अपने प्रशिक्षण / सत्यापन सेट में खराब छवि फ़ाइलें नहीं हैं। डीबग के लिए आप एक साधारण नेट बना सकते हैं जो इनपुट लेयर को पढ़ता है, उसके ऊपर एक डमी लॉस होता है और सभी इनपुट्स के माध्यम से चलता है: यदि उनमें से एक दोषपूर्ण है, तो यह डमी नेट भी उत्पन्न होना चाहिए nan।

`"Pooling"`परत में कर्नेल आकार से बड़ा

किसी कारण से, चुनने stride> kernel_sizeके साथ परिणाम हो सकता है पूलिंग के लिए nanहै। उदाहरण के लिए:

layer {
  name: "faulty_pooling"
  type: "Pooling"
  bottom: "x"
  top: "y"
  pooling_param {
    pool: AVE
    stride: 5
    kernel: 3
  }
}

साथ परिणाम nanमें y।

में अस्थिरता `"BatchNorm"`

यह बताया गया कि कुछ सेटिंग्स "BatchNorm"परत के तहत nanसंख्यात्मक अस्थिरताओं के कारण उत्पादन हो सकता है ।
यह मुद्दा bvlc / caffe में उठाया गया था और PR # 5136 इसे ठीक करने का प्रयास कर रहा है।

हाल ही में, मैं के बारे में पता बन गया debug_infoझंडा: सेटिंग debug_info: trueमें 'solver.prototxt'प्रशिक्षण के दौरान अधिक डिबग जानकारी (ढाल परिमाण और सक्रियण मूल्यों सहित) लॉग इन करने के Caffe प्रिंट कर देगा: यह जानकारी कर सकते हैं प्रशिक्षण प्रक्रिया में ढाल blowups और अन्य समस्याओं खोलना में मदद ।

Question 3

मेरे मामले में, सजा / विघटनकारी परतों में पूर्वाग्रह स्थापित नहीं करना इसका कारण था।

समाधान: कनवल्शन लेयर पैरामीटर्स में निम्नलिखित जोड़ें।

bias_filler {प्रकार: "स्थिर" मान: 0}

Question 4

यह उत्तर nans के लिए एक कारण के बारे में नहीं है , बल्कि इसे डीबग करने में मदद करने का एक तरीका प्रस्तावित करता है। आप इस अजगर परत हो सकता है:

class checkFiniteLayer(caffe.Layer):
  def setup(self, bottom, top):
    self.prefix = self.param_str
  def reshape(self, bottom, top):
    pass
  def forward(self, bottom, top):
    for i in xrange(len(bottom)):
      isbad = np.sum(1-np.isfinite(bottom[i].data[...]))
      if isbad>0:
        raise Exception("checkFiniteLayer: %s forward pass bottom %d has %.2f%% non-finite elements" %
                        (self.prefix,i,100*float(isbad)/bottom[i].count))
  def backward(self, top, propagate_down, bottom):
    for i in xrange(len(top)):
      if not propagate_down[i]:
        continue
      isf = np.sum(1-np.isfinite(top[i].diff[...]))
        if isf>0:
          raise Exception("checkFiniteLayer: %s backward pass top %d has %.2f%% non-finite elements" %
                          (self.prefix,i,100*float(isf)/top[i].count))

इस परत को अपने train_val.prototxtकुछ बिंदुओं पर जोड़ने से आपको संदेह होता है कि परेशानी हो सकती है:

layer {
  type: "Python"
  name: "check_loss"
  bottom: "fc2"
  top: "fc2"  # "in-place" layer
  python_param {
    module: "/path/to/python/file/check_finite_layer.py" # must be in $PYTHONPATH
    layer: "checkFiniteLayer"
    param_str: "prefix-check_loss" # string for printouts
  }
}

Question 5

Learning_rate उच्च है और इसे कम किया जाना चाहिए। RNN कोड में सटीकता नैन थी, सीखने की दर के लिए निम्न मान का चयन करता है जो इसे ठीक करता है

Question 6

मैं एक विरल ऑटोकेनोडर बनाने की कोशिश कर रहा था और इसमें कई परतें थीं ताकि स्पार्सिटी को प्रेरित किया जा सके। अपना नेट चलाते समय, मैंने NaN का सामना किया। कुछ परतों को हटाने पर (मेरे मामले में, मुझे वास्तव में 1 को हटाना था), मैंने पाया कि NaN गायब हो गया। तो, मुझे लगता है कि बहुत अधिक विरलता NaN के रूप में अच्छी तरह से हो सकती है (कुछ 0/0 कम्प्यूटेशंस को लागू किया जा सकता है!)