मैं Tensorflow के साथ भाषण मान्यता पर काम कर रहा हूं और LSTM NN को बड़े पैमाने पर तरंगों के साथ प्रशिक्षित करने की योजना बना रहा हूं। प्रदर्शन लाभ के कारण, मैं tfrecords का उपयोग करने की योजना बना रहा हूं। इंटरनेट पर कई उदाहरण हैं (पूर्व के लिए इंसेप्शन) जहां tfrecords फाइलें शार्क में विभाजित हैं। मेरा सवाल है: क्या tfrecords फ़ाइल शार्क में होने का लाभ है? क्या इस विभाजन का कोई अतिरिक्त प्रदर्शन है?
जवाबों:
कई फाइलों में विभाजित होने के लाभों पर शोध करने में, Google लोगों में से एकमात्र उचित जवाब आया।
उन्होंने कहा कि प्रदर्शन लाभ नगण्य हैं, लेकिन मैं मानता हूं कि विभाजन फाइलें मदद कर सकती हैं, खासकर यदि आप डेटासेट को किसी अन्य स्थान पर स्थानांतरित करना चाहते हैं।
ध्यान रखें कि अब आपको बचत करने से पहले फेरबदल करने की आवश्यकता नहीं है, क्योंकि (वर्तमान में) TFRecords को पढ़ने के लिए अनुशंसित विधि का उपयोग करता है tf.data.TFRecordDatasetजो बहुत उपयोगी .shuffle()विधि को लागू करता है ।
अभी भी सोच रहे लोगों के लिए: यह इतना है कि आप अपने डेटा को फेरबदल कर सकते हैं। एक फाइल में अपने TFrecords के साथ, आप ऑर्डर को फेरबदल नहीं कर सकते। यह विशेष रूप से SGD के साथ आवश्यक है।
हालांकि, शार्क के साथ, आप उन शार्क के आदेश को फेरबदल कर सकते हैं जो आपको डेटा को अनुमानित रूप से फेरबदल करने की अनुमति देता है जैसे कि आपके पास व्यक्तिगत TFRecords तक पहुंच थी। यह स्पष्ट रूप से कुछ भी नहीं की तुलना में बेहतर है, और स्पष्ट रूप से अधिक शार्क आपके पास इस सन्निकटन बेहतर है।
विकल्प आपके डेटा को पहले से ही डुप्लिकेट करने के माध्यम से फेरबदल करता है या TFRecords का उपयोग बिल्कुल नहीं करता है।
TFRecord फ़ाइलों को शार्क में विभाजित करने से आपको बड़े डेटासेट में फेरबदल करने में मदद मिलती है जो स्मृति में फिट नहीं होंगे।
कल्पना कीजिए कि आपके पास डिस्क पर लाखों प्रशिक्षण उदाहरण हैं और आप बार-बार उन्हें प्रशिक्षण प्रक्रिया के माध्यम से चलाना चाहते हैं। इसके अलावा, मान लीजिए कि प्रशिक्षण डेटा (यानी प्रत्येक अवधि) के प्रत्येक पुनरावृत्ति के लिए आप डेटा को पूरी तरह यादृच्छिक क्रम में लोड करना चाहते हैं।
एक दृष्टिकोण प्रति प्रशिक्षण उदाहरण के लिए एक फ़ाइल है और सभी फ़ाइलनामों की सूची तैयार करना है। फिर प्रत्येक युग की शुरुआत में आप फ़ाइल नाम की सूची में फेरबदल करते हैं और अलग-अलग फ़ाइलों को लोड करते हैं। इस दृष्टिकोण के साथ समस्या यह है कि आप अपनी डिस्क पर यादृच्छिक स्थानों से लाखों फाइलें लोड कर रहे हैं। यह विशेष रूप से हार्ड डिस्क ड्राइव पर धीमा हो सकता है। यदि आप यादृच्छिक स्थानों से लाखों छोटी फ़ाइलों को लोड कर रहे हैं, तो भी एक RAID 0 सरणी गति के साथ मदद नहीं करेगा। यदि आप नेटवर्क कनेक्शन पर फ़ाइलों तक पहुँच रहे हैं तो समस्या और भी बदतर हो जाती है।
एक अन्य दृष्टिकोण एक बड़ी TFRecord फ़ाइल से अनुक्रम में प्रशिक्षण के उदाहरणों को पढ़ना और एक फेरबदल बफर का उपयोग करके स्मृति में उदाहरणों को फेरबदल करना है। हालाँकि, फेरबदल बफ़र आमतौर पर आपके CPU के लिए उपलब्ध DDR मेमोरी से बड़ा नहीं हो सकता है। और यदि फेरबदल बफर आपके डेटासेट की तुलना में काफी छोटा है, तो यह डेटा को पर्याप्त रूप से फेरबदल नहीं कर सकता है। डेटा "स्थानीय रूप से" फेरबदल किया जा सकता है लेकिन "विश्व स्तर पर" फेरबदल नहीं किया जा सकता है। यही है, डेटासेट की शुरुआत से उदाहरणों को डेटासेट के अंत से उदाहरण के साथ फेरबदल नहीं किया जा सकता है।
एक अच्छा उपाय यह है कि अपने डेटासेट को कई TFRecord फ़ाइलों (शार्क कहा जाता है) में विभाजित करके उपरोक्त दो दृष्टिकोणों के संतुलित संयोजन का उपयोग करें। प्रत्येक युग के दौरान आप वैश्विक फेरबदल प्राप्त करने के लिए शार्द फाइलनामों को फेरबदल कर सकते हैं और स्थानीय फेरबदल प्राप्त करने के लिए एक फेरबदल बफर का उपयोग कर सकते हैं। एक अच्छा संतुलन शार्क को डिस्क की गति के मुद्दों को रोकने के लिए काफी बड़ा बना देगा, लेकिन एक फेरबदल बफर द्वारा पर्याप्त रूप से फेरबदल करने की अनुमति देने के लिए शार्क को काफी छोटा रखेगा।
यहाँ सटीक कदम हैं:
TFRecords फ़ाइल को कई शार्प में विभाजित करने के अनिवार्य रूप से 3 फायदे हैं:
.shuffle()यदि आपके पास एक बड़ी tfrecord फ़ाइल है, तो विधि एक आदर्श समाधान नहीं है। यदि आप एक बड़े बफर आकार का उपयोग नहीं करते हैं तो फेरबदल आउटपुट कुछ हद तक मूल क्रम से संबंधित है। मुझे लगता है कि tfrecord को सहेजने से पहले डेटा को पूर्व-फेरबदल करना चाहिए या जब आप एक बड़ा डेटासेट होते हैं तो शार्प में विभाजित करना आवश्यक है।