LLM में तापमान क्या है?

Scrapeless Agent Browser वेब ऑटोमेशन के लिए एक क्लाउड ब्राउज़र प्रदान करता है।

LLM में Temperature एक डिकोडिंग पैरामीटर है जो अगला टोकन सैंपल करते समय उपयोग की जाने वाली सापेक्ष संभावनाओं को बदलता है। कम पॉज़िटिव मान उच्च-स्कोरिंग उम्मीदवारों पर संभावना को केंद्रित करते हैं। अधिक मान वितरण को समतल कर देते हैं और कम संभावित उम्मीदवारों को अधिक बार चुने जाने देते हैं। Temperature चयन व्यवहार को बदलता है; यह मॉडल में ज्ञान नहीं जोड़ता।

यह अंतर तब महत्वपूर्ण हो जाता है जब आप एक प्रोडक्शन असिस्टेंट को कॉन्फ़िगर करते हैं। अधिक विविध शब्दावली ब्रेनस्टॉर्मिंग में मदद कर सकती है, जबकि एक्सट्रैक्शन के लिए सुसंगत फ़ॉर्मेटिंग अधिक महत्वपूर्ण हो सकती है। किसी भी लक्ष्य को एक सार्वभौमिक सर्वश्रेष्ठ संख्या में नहीं बदला जा सकता। अपने वास्तविक मॉडल, प्रॉम्प्ट्स और कार्य के मूल्यांकन के माध्यम से एक सेटिंग चुनें।

तापमान टोकन की संभावनाओं को कैसे बदलता है

Temperature सैंपलिंग डिस्ट्रीब्यूशन की गणना से पहले टोकन स्कोर को रिस्केल करता है। आम सूत्रीकरण में, प्रत्येक उम्मीदवार के logit को एक पॉज़िटिव तापमान से विभाजित किया जाता है और परिणाम softmax से गुज़रते हैं। एक के मान पर temperature logits को रिस्केल नहीं करता। एक से कम मान मौजूदा स्कोर अंतर को अधिक स्पष्ट करता है; एक से अधिक मान उनके सापेक्ष प्रभाव को कम करता है।

एक काल्पनिक अगले-टोकन चयन की कल्पना करें जहाँ एक उम्मीदवार का स्कोर दूसरे से अधिक है। तापमान को कम करने से उच्च-स्कोरिंग टोकन का सापेक्ष लाभ बढ़ जाता है। यह कोई सबूत-जाँच नहीं जोड़ता या यह तय नहीं करता कि वह टोकन सही है या नहीं। यह तंत्र मॉडल के अनुमानित कंटिन्यूएशन पर काम करता है, जो किसी आत्मविश्वासी लेकिन असमर्थित कथन का पक्ष ले सकता है।

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

कम तापमान क्या कर सकता है और क्या नहीं

कम temperature आम तौर पर संभावित कंटिन्यूएशन को प्राथमिकता देकर सैंपलिंग में विविधता को घटा देता है। यह तब उपयोगी हो सकता है जब कार्य को स्थिर लेबल, संक्षिप्त एक्सट्रैक्शन या सुसंगत वाक्य-रचना की आवश्यकता हो। यह फिर भी सही होने की गारंटी के बजाय एक प्रायिकतात्मक जनरेशन सेटिंग है, और इसका प्रभाव इस पर निर्भर करता है कि मॉडल और सर्विंग सिस्टम डिकोडिंग को कैसे लागू करते हैं।

शून्य के रूप में प्रदर्शित मान को आम तौर पर वास्तविक शून्य से विभाजन के बजाय एक विशेष डिकोडिंग केस की तरह माना जाता है। उस व्यवहार पर निर्भर होने से पहले चयनित मॉडल के इंटरफ़ेस की जाँच करें। यहाँ तक कि एक greedy चयन नीति को भी हर डिप्लॉयमेंट स्थिति में समान आउटपुट का वादा नहीं कहा जाना चाहिए। मॉडल अपडेट और सर्विंग विवरण दृश्य सैंपलिंग कंट्रोल से स्वतंत्र रूप से पुनरुत्पादकता को प्रभावित कर सकते हैं।

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

उच्च तापमान रचनात्मकता की गारंटी क्यों नहीं है

उच्च temperature कम-प्रायिकता वाले कंटिन्यूएशन के चुने जाने की संभावना बढ़ा देता है, जो अधिक विविध आउटपुट उत्पन्न कर सकता है। यह विविधता नामों की खोज, वैकल्पिक वाक्य-रचना, या संभावित व्याख्याओं को तलाशने में मदद कर सकती है। यह अप्रासंगिक या असंगत टेक्स्ट भी दे सकती है। यह तय करें कि उपयोगी विविधता से आपका आशय क्या है, इससे पहले कि आप यह मापें कि कोई सेटिंग इसे बेहतर बनाती है या नहीं।

एक ब्रेनस्टॉर्मिंग मूल्यांकन उन विचारों को पुरस्कृत कर सकता है जो अर्थपूर्ण रूप से भिन्न हों और साथ ही बाधाओं को पूरा करें। एक तथ्यात्मक सारांश मूल्यांकन असमर्थित दावों को दंडित कर सकता है, भले ही गद्य प्रभावी लगे। इन कार्यों को अलग-अलग रूब्रिक की आवश्यकता होती है। केवल यह गिनना कि कितने अद्वितीय शब्द प्रकट होते हैं, यह आँकने का कमजोर विकल्प है कि आउटपुट उपयोगी है या नहीं।

पर शोध temperature और समस्या‑समाधान प्रदर्शन को कार्य‑और मॉडल‑निर्भर व्यवहार मिलता है, न कि कोई सार्वभौमिक सटीकता नियम। कम temperature को सत्य सेटिंग या उच्च temperature को बुद्धिमत्ता सेटिंग की तरह मानने से बचें। जिस वास्तविक व्यवहार की आपको परवाह है उसका मूल्यांकन करें और उस चयन के लिए सबूत सुरक्षित रखें।

तापमान बनाम Top-p और अन्य नियंत्रण

Temperature सापेक्ष स्कोर को रिस्केल करता है, जबकि top-p उन टोकनों के समूह तक सैंपलिंग को सीमित करता है जिनकी संचयी संभावना किसी थ्रेशोल्ड तक पहुँच जाती है। ये कंट्रोल चयन प्रक्रिया के अलग-अलग हिस्सों को प्रभावित करते हैं। उनका संयुक्त व्यवहार मॉडल इंटरफ़ेस द्वारा लागू क्रम और विवरण पर निर्भर करता है।

आउटपुट‑लंबाई सीमा एक अलग मुद्दे को संबोधित करती है: कितना टेक्स्ट जनरेट किया जा सकता है। एक फ़ॉर्मेटिंग बाधा स्वीकार्य आउटपुट संरचना को संबोधित करती है। एक सिस्टम निर्देश वांछित व्यवहार का वर्णन करता है। इनमें से एक कंट्रोल बदलने से अन्य अनावश्यक नहीं हो जाते। कम‑temperature वाला उत्तर फिर भी बहुत लंबा, डाउनस्ट्रीम पार्सर के लिए अमान्य, या स्रोत द्वारा असमर्थित हो सकता है।

किसी समस्या का निदान करते समय, एक समय में एक ही कंट्रोल बदलें। यदि आप एक साथ प्रॉम्प्ट को दोबारा लिखते हैं, पुनः प्राप्त सामग्री को बदलते हैं और सैंपलिंग बदलते हैं, तो बेहतर परिणाम यह नहीं बताएगा कि किस हस्तक्षेप से मदद मिली। प्रत्येक मूल्यांकन के लिए इनपुट, मॉडल पहचान, सेटिंग्स और स्कोरिंग निर्णय को रिकॉर्ड करें ताकि तुलना व्याख्यायोग्य रहे।

दोहराने योग्य मूल्यांकन के साथ एक सेटिंग चुनें

तापमान चयन एक कार्य-विशिष्ट मूल्यांकन सेट और स्वीकार्य व्यवहार की परिभाषा से शुरू होना चाहिए। सामान्य अनुरोधों और कठिन मामलों को शामिल करें, जैसे अस्पष्ट इनपुट, गायब प्रमाण, विरोधाभासी स्रोत, और असामान्य रूप से लंबी दस्तावेज़। प्रत्याशी सेटिंग्स के बीच समान मूल्यांकन इनपुट को बनाए रखें।

प्रत्येक सेटिंग को कई अनुरोधों पर चलाएँ और गुणवत्ता तथा परिवर्तनशीलता दोनों की जाँच करें। दोहराए गए सैंपलिंग से वह अस्थिरता सामने आ सकती है जिसे एक बार दिया गया सफल उत्तर छिपा देता है। रन की संख्या निर्णय की लागत और देखी गई विविधता के अनुसार तय करें, न कि किसी मनमाने सार्वभौमिक नियम के अनुसार। असफल उदाहरणों को रिकॉर्ड में रखें; उन्हें हटाने से सेटिंग वास्तविक से अधिक मज़बूत दिखाई देगी।

संरचित निष्कर्षण के लिए, फ़ील्ड की शुद्धता, गायब मानों के प्रबंधन, और आउटपुट की वैधता को अलग‑अलग अंक दें। लेखन के लिए, बाधाओं के पालन और उपयोगी विविधता का मूल्यांकन करें। किसी एजेंट के लिए, टूल आर्गुमेंट्स और समापन शर्तों का मूल्यांकन करें। जो सेटिंग गद्य की विविधता बढ़ाती है, वह टूल चयन जैसे कार्य को कम अनुमानित बना सकती है, इसलिए जहाँ अनुप्रयोग अलग कॉन्फ़िगरेशन की अनुमति देता है, वहाँ इन सतहों को स्वतंत्र रूप से जाँचें।

सैंपलिंग समस्याओं को प्रमाण संबंधी समस्याओं से अलग करें

सैंपलिंग समस्या इस बात से जुड़ी है कि मॉडल उत्तर कैसे चुनता है; प्रमाण संबंधी समस्या इस बात से जुड़ी है कि आवश्यक जानकारी उपलब्ध और भरोसेमंद है या नहीं। जब किसी उत्तर में कोई असमर्थित वर्तमान तथ्य हो, तो पहले प्रमाण का निदान करें। अलग तापमान मॉडल के संचित ज्ञान को अपडेट नहीं कर सकता।

The real-time web search workflow वर्तमान स्रोत सामग्री प्राप्त करने को संबोधित करता है। आपका अनुप्रयोग अभी भी उस सामग्री का निरीक्षण करेगा और यह तय करेगा कि उत्तर को क्या समर्थन दे रहा है। ब्राउज़र एक्सेस और डिकोडिंग सेटिंग्स अलग‑अलग स्तरों पर काम करती हैं, इसलिए प्रत्येक स्तर का मूल्यांकन उसकी अपनी ज़िम्मेदारियों के विरुद्ध करें।

अतिरिक्त संदर्भ जानकारी के साथ‑साथ ध्यान भंग भी ला सकता है। irrelevant context in language-model tasks पर किए गए प्रयोग दिखाते हैं कि संदर्भ चयन को अलग ध्यान क्यों मिलना चाहिए। असंगत उत्तरों को ठीक करने के लिए सैंपलिंग समायोजित करने से पहले जाँचें कि क्या प्रॉम्प्ट प्रासंगिक प्रमाण को असंबंधित नेविगेशन, दोहराई गई सामग्री, या प्राप्त पृष्ठों से परस्पर विरोधी निर्देशों के साथ मिला रहा है।

निर्णय प्रकार के अनुसार एजेंट कॉन्फ़िगर करें

एक एजेंट मॉडल के कई प्रकार के निर्णय कर सकता है, और साझा तापमान उन्हें अलग‑अलग तरह से प्रभावित कर सकता है। खोज क्वेरी का मसौदा तैयार करना, टूल चुनना, किसी कीमत को निकालना, और अंतिम व्याख्या लिखना समान आवश्यकताएँ नहीं रखते। जहाँ आपकी संरचना इसका समर्थन करती है, वहाँ पूरे कार्य के लिए एक ही सेटिंग मान लेने के बजाय प्रत्येक निर्णय प्रकार के लिए कॉन्फ़िगरेशन का मूल्यांकन करें।

निष्पादन संबंधी सीमाओं को सैंपलिंग से अलग रखें। टूल अलाउलिस्ट, आर्गुमेंट वैलिडेशन, और खर्च सीमा, मॉडल जो भी टेक्स्ट उत्पन्न करे, उसके बावजूद प्रभावी रहनी चाहिए। यदि कोई एजेंट किसी अवैध कार्रवाई का प्रस्ताव देता है, तो रनटाइम को उस कार्रवाई को अस्वीकार करना चाहिए। अधिक रूढ़िवादी सैंपलिंग कुछ अवांछित प्रस्तावों को कम कर सकती है, पर उसे एक्सेस नियंत्रण का पूरा बोझ नहीं उठाना चाहिए।

ब्राउज़र‑आधारित कार्यों के लिए, Agent Browser इंटरैक्शन सतह प्रदान करता है। मॉडल कॉन्फ़िगरेशन आस‑पास के अनुप्रयोग में होता है। मॉडल कॉल्स और ब्राउज़र कार्य की लागतों की तुलना अलग‑अलग करें, और बाद वाले के लिए Scrapeless pricing का उपयोग करें, बजाय इसके कि सभी रनटाइम शुल्कों को टोकन के रूप में माना जाए।

अपने परिणाम की सीमाएँ दर्ज करें

तापमान संबंधी अनुशंसा को उस मूल्यांकन के दायरे को स्पष्ट करना चाहिए जो उसे समर्थन देता है। मॉडल कॉन्फ़िगरेशन, कार्य सेट, प्रॉम्प्ट संस्करण, और गुणवत्ता मानदंड दर्ज करें। यदि इनमें से कोई भी बदलता है, तो पहले यह जाँचें कि क्या वही सेटिंग अब भी वही आवश्यकताएँ पूरी करती है, उसके बाद ही पहले के परिणाम को वर्तमान मानेँ।

किसी संकीर्ण मूल्यांकन को सभी भाषा मॉडलों के लिए सामान्य नियम के रूप में रिपोर्ट करने से बचें। दो सिस्टम एक ही नाम वाला पैरामीटर प्रदान कर सकते हैं, लेकिन समर्थन, डिफ़ॉल्ट और अन्य नियंत्रणों के साथ उनकी पारस्परिक क्रिया अलग हो सकती है। एक उपयोगी इंजीनियरिंग नोट यह बताता है कि क्या मूल्यांकित किया गया और कौन से विफलता मामले शेष हैं। इसे यह दावा करने की आवश्यकता नहीं है कि कोई एक मान सार्वभौमिक रूप से सबसे सुरक्षित या सबसे रचनात्मक है।

सारांश

तापमान उस वितरण को नियंत्रित करता है जिसका उपयोग टोकन सैंपलिंग के लिए किया जाता है। इसे अपने अनुप्रयोग को जिन व्यवहारों की ज़रूरत है, उन्हें मापकर चुनें, और गायब प्रमाण या खराब वैलिडेशन की जाँच अलग से करें। स्पष्ट कार्य रूपरेखा से शुरू करें, निश्चित इनपुट्स पर प्रत्याशी सेटिंग्स की तुलना करें, और वे उदाहरण सुरक्षित रखें जो बताते हैं कि चुनी गई सेटिंग क्यों अनुकूल है।