वास्तविक दुनिया के अनुभव से सीखना
सफल व्यवहारों की नकल करने, उपयोगकर्ता सुधारों की आवश्यकता को कम करने और टूल त्रुटियों से बचने के लिए Perplexity Computer मॉडल को पोस्ट-ट्रेन करना।
वास्तविक दुनिया में उपयोगकर्ता हमारे उत्पादों के साथ कैसे बातचीत करते हैं, यह मॉडल प्रशिक्षण के लिए एक मूल्यवान स्रोत है। डेटा प्रचुर मात्रा में है, उपयोगकर्ता कार्यों के वास्तविक वितरण को दर्शाता है, और उपयोगकर्ता सुधारों तथा टूल विफलताओं को कैप्चर करता है जिन्हें सिंथेटिक वातावरण छूट सकता है।
वास्तविक दुनिया के डेटा से सीखने का एक आम तरीका रिजेक्शन सैंपलिंग फाइन-ट्यूनिंग है: प्रत्येक सत्र के परिणाम का न्याय करें, सफल लोगों को रखें, और उनका अनुकरण करने के लिए मॉडल को प्रशिक्षित करें। लेकिन एक सफल परिणाम का मतलब यह नहीं है कि हर कदम सही था, इसलिए पूरे प्रक्षेपवक्र का अनुकरण करने से अच्छे के अलावा खराब मध्यवर्ती व्यवहारों को भी मजबूत करने का जोखिम होता है। असफल सत्रों को छोड़ना भी इस बात के महत्वपूर्ण साक्ष्य को खो देता है कि मॉडल कहाँ कम पड़ता है।
इस उदाहरण में, संकेत मॉडल को सफल और असफल दोनों सत्रों से सीखने के लिए रिजेक्शन सैंपलिंग फाइन-ट्यूनिंग को संकेत-निर्देशित सेल्फ-डिस्टिलेशन के साथ जोड़ते हैं। एक संकेत एक छोटी सुधारात्मक निर्देश होता है, जो उस जानकारी पर आधारित होता है जो मॉडल के पास गलती करते समय पहले से थी। सफल सत्रों के उपयोगी चरण इमिटेशन लक्ष्यों के रूप में बने रहते हैं, जबकि आधारित संकेत टाली जा सकने वाली गलतियों को सुधार लक्ष्यों में बदल देते हैं।
उपयोगकर्ता सुधार और टूल त्रुटियाँ इस बात के बारे में पर्यवेक्षण जोड़ती हैं कि रास्ते में क्या गलत हुआ, इसके अलावा कि क्या कार्य अंततः सफल हुआ। हम उन वातावरणों और वास्तविक दुनिया के उपयोग के बीच की खाई को पाटने में मदद करने के लिए सिंथेटिक वातावरण में सुदृढीकरण सीखने के बाद इस चरण को लागू करते हैं।
लाइव उपयोग में, बाद के पोस्ट-ट्रेन्ड GLM-5.2 चेकपॉइंट ने पहले प्रशिक्षित चेकपॉइंट की तुलना में टूल-कॉल विफलता को 21.2% तक कम किया। GLM-5.3 के लिए, पोस्ट-ट्रेनिंग ने स्टॉक मॉडल की तुलना में टूल-कॉल विफलता को 33.0% और मध्यम या उच्च उपयोगकर्ता असंतोष की औसत अनुमानित संभावना को 17.2% तक कम कर दिया।
सिंथेटिक से वास्तविक दुनिया के डेटा तक
सिंथेटिक कार्य हमें ऐसे नियंत्रित समस्याओं को बनाने की अनुमति देते हैं जिनके परिणाम सत्यापित करने में आसान होते हैं, लेकिन वे आमतौर पर एक ही संकेत तक सीमित होते हैं और केवल उन परिदृश्यों को कवर कर सकते हैं जिन्हें हम स्पष्ट रूप से डिज़ाइन करते हैं।
इसके विपरीत, वास्तविक दुनिया के सत्रों में उपयोगकर्ता सत्रों में विविध निर्देश, संदर्भ और टूल संयोजन लाते हैं जो बातचीत के कई मोड़ों पर सामने आते हैं। इस तरह के वास्तविक दुनिया के उपयोग से स्वाभाविक रूप से गलतियों के दो मूल्यवान संकेत मिलते हैं: उपयोगकर्ता सुधार यह प्रकट करते हैं कि एजेंट ने वह कहाँ वितरित करने में विफल रहा जो वे चाहते थे, और टूल त्रुटियाँ दिखाती हैं कि वास्तविक वातावरण में इसकी कार्रवाई कहाँ टूट गई। हमारी सैंपलिंग पाइपलाइन व्यक्तिगत रूप से पहचान योग्य जानकारी (PII) वाले सत्रों को बाहर करके और ऑप्ट आउट करने वाले उपयोगकर्ताओं से सत्रों को बाहर करके उपयोगकर्ताओं की गोपनीयता और प्रशिक्षण विकल्पों का सम्मान करती है।
इसलिए वास्तविक दुनिया का डेटा हमें ऐसे विफलता के मामले देता है जिन्हें सिंथेटिक वातावरण उजागर नहीं कर सकता है और अक्सर इसके साथ आता है कि विफलता पहले से ही कहाँ हुई थी।
अच्छे चरणों का अनुकरण करें, बुरे चरणों को सुधारें
वास्तविक दुनिया के डेटा पर प्रशिक्षण देते समय, मानक रिजेक्शन सैंपलिंग फाइन-ट्यूनिंग (RFT) अच्छे मध्यवर्ती कार्यों को बुरे कार्यों से अलग करने के लिए उपयोगकर्ता और टूल फ़ीडबैक का स्पष्ट रूप से उपयोग किए बिना, उनके अंतिम परिणामों के आधार पर सफल सत्रों का चयन करता है। एक एजेंट खराब टूल कॉल से उबर सकता है या उपयोगकर्ता फ़ीडबैक के बाद गलती को सुधार सकता है और अंत में सही आउटपुट दे सकता है।
विफल सत्रों को छोड़ना नमूना दक्षता को भी सीमित करता है। ऐसा सत्र जो कभी किसी अच्छे परिणाम तक नहीं पहुंचता, फिर भी उपयोगी प्रशिक्षण संकेतों के रूप में एक स्पष्ट, टालने योग्य गलती को प्रकट कर सकता है।
हम दो निर्णयों को अलग करके इन सीमाओं का समाधान करते हैं: किन सत्रों में अनुकरण करने लायक व्यवहार शामिल है, और किन टर्न में सुधार करने लायक गलतियाँ हैं। डेटा पाइपलाइन इन निर्णयों को अलग-अलग करती है, फिर मॉडल टर्न को तीन में से एक ट्रीटमेंट प्रदान करती है:
- अनुकरण करें: सफल सत्रों में गैर-त्रुटि टर्न सामान्य क्रॉस-एंट्रॉपी (CE) लॉस प्राप्त करते हैं, जिससे रिकॉर्ड किए गए टोकन की संभावना बढ़ जाती है।
- सही: सफल और असफल दोनों सत्रों में, एक वैध संकेत वाले त्रुटि टर्न Kullback–Leibler (KL) डाइवर्जेंस लॉस प्राप्त करते हैं, जो मॉडल को उन अगले-टोकन भविष्यवाणियों की ओर ले जाता है जो यह संकेत देखने पर करता है।
- संदर्भ के रूप में रखें: असफल सत्रों में ऐसे टर्न जिनमें एक मान्य संकेत का अभाव होता है, और किसी भी सत्र प्रकार में मान्य संकेत के बिना चिह्नित खराब टर्न, संदर्भ के रूप में कार्य करते हैं लेकिन दोनों में से कोई भी लॉस प्राप्त नहीं करते हैं।
परिणामस्वरूप, सफल सत्र अनुकरण और सुधार दोनों लक्ष्य प्रदान कर सकते हैं, जबकि असफल सत्र केवल सुधार लक्ष्य प्रदान करते हैं। सिस्टम, उपयोगकर्ता और टूल आउटपुट सहित सभी शेष टर्न, संदर्भ के रूप में रहते हैं।
अनुकरण भाग मानक RFT का उपयोग करता है। सुधारात्मक भाग On-Policy Self-Distillation (OPSD) का उपयोग करता है: वही मॉडल टीचर और स्टूडेंट के रूप में कार्य करता है, जिसमें टीचर को विशेषाधिकार प्राप्त जानकारी दी जाती है। यहाँ, वह विशेषाधिकार प्राप्त जानकारी एक टालने योग्य गलती को समझाने वाला एक छोटा संकेत है। हम स्टूडेंट को संकेत दिए बिना टीचर के अगले-टोकन भविष्यवाणियों से मेल खाने के लिए प्रशिक्षित करते हैं।
दोनों हिस्से मायने रखते हैं। केवल-करेक्शन प्रशिक्षण एक शॉर्टकट उजागर कर सकता है: सुधार सीखने के बजाय टीचर और स्टूडेंट संदर्भ की उपेक्षा करके सहमत हो सकते हैं। CE टर्म प्रशिक्षण को उपयोगी व्यवहार से जोड़ता है, जिससे उस सहमति को हतोत्साहित करने में मदद मिलती है जो संदर्भ की उपेक्षा करने से आती है।
इसके बाद पोस्ट-ट्रेन किया गया स्टूडेंट Computer में एक मॉडल विकल्प बन जाता है। लाइव उपयोग से मिलने वाले नए सत्र प्रशिक्षण पाइपलाइन के एक अन्य दौर में प्रवेश करने से पहले समान पात्रता और गोपनीयता फ़िल्टर से गुजरते हैं।
एक उदाहरण: एक सत्र दोनों सबक सिखा सकता है
इसके बाद, हम एक ठोस उदाहरण के माध्यम से चलते हैं जिसमें अनुकरण और सुधार दोनों शामिल हैं।
एक संभावित सफल सत्र पर विचार करें जहाँ उपयोगकर्ता आधिकारिक दस्तावेज़ीकरण का उपयोग करके Python 3.13 में asyncio परिवर्तनों की तुलना करने के लिए कहता है। हमारा टूल दस्तावेज़ीकरण बताता है कि search.web हिट्स की एक सूची लौटाता है, जिनमें से प्रत्येक में एक url फ़ील्ड होती है।
तुलना के लिए साक्ष्य इकट्ठा करने के हिस्से के रूप में मॉडल पहले एक संस्करण के लिए एक वैध खोज चलाता है, जो अनुकरण करने के लिए एक अच्छा व्यवहार है।
हालांकि, अगला कोड-निष्पादन कॉल गलती से उस सूची को एक शब्दकोश के रूप में मानता है। कोड टूल TypeError: list indices must be integers or slices, not str लौटाता है। चूँकि कॉल से पहले रिटर्न प्रकार का दस्तावेजीकरण किया गया था, यह एक ऐसी गलती है जिससे मॉडल को बचना चाहिए था। उस कार्रवाई को सुधारने के लिए सही कॉल के साथ एक संकेत उत्पन्न किया जा सकता है।
प्रशिक्षण कैसे काम करता है
प्रशिक्षण पाइपलाइन के चार चरण हैं: सत्रों का चयन करना और उनके परिणामों का न्याय करना, उपयोगकर्ता फ़ीडबैक और टूल त्रुटियों से गलतियों की पहचान करना और संकेत बनाना, टीचर और स्टूडेंट दोनों से अगली-टोकन संभावनाएँ उत्पन्न करना, और संयुक्त CE और KL लॉस के साथ मॉडल को प्रशिक्षित करना।
सत्रों का चयन करें, फिर परिणाम का न्याय करें
सैंपलिंग पाइपलाइन GLM 5.2 द्वारा सर्व किए गए वास्तविक दुनिया के Computer सत्रों के एक प्रशिक्षण-योग्य उपसमूह से डेटा लेती है। इस वर्कफ़्लो के लिए उदाहरण चुनने से पहले, प्रशिक्षण से बाहर होने के विकल्प और पाइपलाइन के PII-संबंधी बहिष्करण लागू किए जाते हैं।
प्रारंभिक स्क्रीनिंग प्रक्रिया LLM जज द्वारा पाँच-बिंदु कार्य-कठिनाई पैमाने पर 4 या 5 रेट किए गए उम्मीदवारों का चयन करती है और उन्हें 2 समूहों में विभाजित करती है:
- उपयोगकर्ता-फ़ीडबैक समूह में वास्तविक उपयोगकर्ता फ़ॉलो-अप या मध्यम-से-उच्च असंतोष फ़्लैग वाले सत्र शामिल हैं। हम सीखने के लिए इन उच्च-इरादे वाले फ़ॉलो-अप को विशेष रूप से उपयोगी पाते हैं: उपयोगकर्ता सक्रिय रूप से एक कार्य को पूरा करने की कोशिश कर रहे हैं, और उनके सुधार इस बात को इंगित करते हैं कि मॉडल से क्या छूट गया।
- टूल-त्रुटि समूह में नियम-आधारित जाँचों द्वारा फ़्लैग किए गए विफल कॉल वाले सत्र शामिल हैं, जिसमें मान्यता प्राप्त बुनियादी ढाँचा विफलताओं और अस्वीकृत प्राधिकरण को छोड़कर।
इसके बाद दो एलएलएम जज उपयोगकर्ता के अनुरोध के मुकाबले अंतिम डिलीवरी का आकलन करते हैं; सत्र को “सफल” के रूप में लेबल करने के लिए दोनों जजों का सकारात्मक निर्णय देना अनिवार्य है। ऐसे मामलों के लिए जो आर्टिफ़ैक्ट डिलीवर करते हैं, परिणाम चरण डिलीवरी का पुनर्निर्माण और निरीक्षण कर सकता है, और यदि वह चरण विफल हो जाता है, तो इसके टेक्स्ट-आधारित निर्णयों पर वापस लौट सकता है। अधूरे के रूप में वर्गीकृत सत्रों, जैसे कि उपयोगकर्ता की प्रतीक्षा कर रहे कार्य, को बाहर रखा गया है।
यह चरण सीखने के संकेतों के संभावित स्रोतों की पहचान करता है; हालांकि, हर त्रुटि मॉडल के कारण नहीं होती है, क्योंकि कुछ अस्पष्ट निर्देशों या बुनियादी ढाँचे की विफलताओं से उत्पन्न होती हैं। बाद का एनोटेशन निर्धारित करता है कि कौन सी उम्मीदवार गलतियाँ वास्तव में टालने योग्य हैं और प्रशिक्षण के लिए उपयुक्त हैं।
उपयोगकर्ता फ़ीडबैक से गलतियाँ ढूँढें
उपयोगकर्ता-फ़ीडबैक समूह में एक नमूना सत्र पर विचार करें, जहाँ उपयोगकर्ता पूछता है, "How do I find my w3 on paychex"। मॉडल "w3" को W-2 की वर्तनी की गलती (टाइपो) के रूप में मानता है, W-2 निर्देशों के लिए खोज करता है, और समझाता है कि उस फ़ॉर्म को कैसे खोजा जाए। उपयोगकर्ता का फ़ॉलो-अप, "I meant the W-3 transmittal form," गलती की पहचान करता है, भले ही सत्र अंततः सफल हो जाए।
शिकायत गलती का पता लगाने में मदद करती है, लेकिन मूल कारण W-2 के रूप में "w3" की पुनर्व्याख्या करने का पहला निर्णय है। मूल अनुरोध गलती को टालने योग्य बनाता है: मॉडल W-3 को संरक्षित कर सकता था या स्पष्टीकरण मांग सकता था। यह पता चलता है कि शिकायत से पहले का आखिरी सहायक टर्न केवल आधे समय ही मूल कारण होता है।
हमारी एनोटेशन पाइपलाइन प्रत्येक उपयोगकर्ता-फ़ीडबैक सत्र के भीतर कारण और प्रभाव को व्यवस्थित रूप से मैप करती है। एनोटेटर पहले छूटी हुई आवश्यकता या पहले के संदर्भ द्वारा समर्थित इरादे की जाँच करता है। इसके बाद तीन LLM जज ज़िम्मेदार टर्न की पहचान करते हैं, जिसमें किसी दिए गए टर्न पर सहमति के लिए कम से कम दो की आवश्यकता होती है। कभी-कभी एक पहला बयान स्पष्ट रूप से आवश्यकता स्थापित करता है। अन्य मामलों में, कोई भी एकल पूर्व बयान ऐसा नहीं करता है, लेकिन पूर्ववर्ती बातचीत के कई हिस्से संयुक्त रूप से इच्छित व्यवहार को अनुमान लगाने योग्य बनाते हैं। यह डिज़ाइन उन्हें अंतिम उत्तर के लिए पूरी तरह से ज़िम्मेदार ठहराने के बजाय किसी शिकायत को पहले की मूल गलती से जोड़ने की अनुमति देता है।
संकेत स्वीकार करने से पहले, पाइपलाइन यह भी जाँच करती है कि इसके सुधारात्मक दावे चिह्नित टर्न से पहले उपलब्ध जानकारी से अनुसरण करते हैं। इन जाँचों का उद्देश्य हिंडसाइट पूर्वाग्रह को कम करना है, जहाँ शिकायत में प्रकट की गई एक नई प्राथमिकता को ऐसी चीज़ के रूप में माना जाता है जिसे मॉडल को पहले से ही पता होना चाहिए था।
इस उदाहरण में, संकेत मॉडल को W-2 के बजाय Paychex पर W-3 ट्रांसमिटल फ़ॉर्म खोजने, या यदि अनुरोध अस्पष्ट हो तो पूछने के लिए कहते हैं कि उपयोगकर्ता का आशय कौन-सा फ़ॉर्म है। सुधार लक्ष्य पहले की व्याख्या और खोज निर्णय पर केंद्रित होते हैं, सिर्फ़ अंतिम उत्तर पर नहीं। मूल टर्न अपरिवर्तित रहता है; एनोटेशन में is_bad_turn: true और एक गैर-रिक्त hint जोड़ा जाता है.
टूल त्रुटियों से गलतियाँ ढूँढें
टूल-त्रुटि समूह में एक अन्य सत्र पर विचार करें जिसमें एक सर्च कॉल है जहाँ एजेंट recency_filter: "year" के साथ खोज करता है, लेकिन टूल इसे अस्वीकार कर देता है क्योंकि अनुमत मान “day,” “week,” या “month” हैं। यह एक स्पष्ट स्कीमा उल्लंघन है।
टूल-त्रुटि पथ ज्ञात गलतियों के लिए नियतिवादी नियमों और अस्पष्ट मामलों के लिए मॉडल निर्णय का उपयोग करता है। मॉडल को दोषी ठहराने के लिए अकेले एक त्रुटि संदेश भी पर्याप्त नहीं है; एक मूल्यांकित सुधार को किसी ऐसी चीज़ की ओर इशारा करना चाहिए जिसे मॉडल टूल स्कीमा, सिस्टम निर्देशों या पहले की बातचीत से जान सकता था।
यहाँ, संकेत विफल कॉल का नाम बताता है, सत्यापन त्रुटि को शामिल करता है, और मॉडल को अनुमत मान का उपयोग करने या वैकल्पिक होने पर फ़ील्ड को छोड़ने का निर्देश देता है।
दो फॉरवर्ड पास
एक बार टर्न चिह्नित हो जाने के बाद, ट्रेनर एक ही चेकपॉइंट को दो बार चलाता है: एक बार टीचर के रूप में और एक बार स्टूडेंट के रूप में। टीचर को हिंट दिखाई देता है; स्टूडेंट को नहीं।
दोनों पास टीचर फ़ोर्सिंग का उपयोग करते हैं, जहाँ हम मॉडल को नए टोकन चुनने देने के बजाय रिकॉर्ड किया गया सत्र फ़ीड करते हैं। फॉरवर्ड पास अभी भी प्रत्येक चरण में एक पूर्ण अगली-टोकन वितरण उत्पन्न करता है, लेकिन यह हमेशा रिकॉर्डिंग से निश्चित उपसर्ग पर आधारित होता है, न कि रोलआउट टोकन पर।
सर्च के उदाहरण के लिए, जब संकेत दिया जाता है तो वही मॉडल "month" को बहुत अधिक संभावना और "year" को कम संभावना प्रदान करता है। प्रशिक्षण इस वितरण संबंधी बदलाव को एक सॉफ्ट लक्ष्य के रूप में उपयोग करता है।
टीचर की भविष्यवाणियां अलग-थलग होती हैं, या स्टॉप-ग्रेडिएंट होती हैं: वे एक लक्ष्य प्रदान करती हैं लेकिन टीचर पास के माध्यम से कोई अपडेट प्राप्त नहीं करती हैं। स्टूडेंट के पास के बाद, एक ऑप्टिमाइज़र चरण साझा मॉडल को अपडेट करता है।
लॉस फ़ंक्शन
CE लॉस
CE लॉस अनुकरण के लिए चुने गए रिकॉर्ड किए गए टोकन को ग्राउंड-थ्रूप लक्ष्यों के रूप में मानता है और उन्हें कम संभावनाएँ प्रदान करने के लिए मॉडल को दंडित करता है। यह एक कठिन अनुकरण लक्ष्य बनाता है।
टोकन स्थिति पर, मान लीजिए कि पूर्ण शब्दावली में टोकन की स्टूडेंट की संभावना है। प्रतिक्रिया या टूल कॉल में रिकॉर्ड किया गया अगला टोकन है, वन-हॉट लक्ष्य वितरण है।
क्रॉस-एन्ट्रॉपी यह मापता है कि स्टूडेंट उस रिकॉर्ड किए गए टोकन की कितनी अच्छी तरह भविष्यवाणी करता है। वन-हॉट लक्ष्य के साथ, यह को निर्दिष्ट नकारात्मक लॉग-संभावना तक कम हो जाता है।
CE मास्क वह है जहाँ टोकन का अनुकरण किया जाना चाहिए और अन्य जगहों पर है। चयनित स्थानों पर योग करने से अनुकरण लॉस मिलता है।
KL लॉस
इसके बजाय KL लॉस, सॉफ्ट करेक्शन टारगेट के रूप में टीचर के पूर्ण नेक्स्ट-टोकन प्रोबेबिलिटी वितरण का उपयोग करता है। टीचर के संदर्भ में वर्तमान संकेत और उस प्रशिक्षण खंड में रखे गए कोई भी पहले के संकेत शामिल होते हैं; स्टूडेंट का संदर्भ हमेशा संकेत-मुक्त होता है।
KL मास्क वह है जहाँ टोकन को सुधारा जाना चाहिए और अन्य जगहों पर है; CE और KL मास्क ओवरलैप नहीं होते हैं। इन स्थानों पर, फॉरवर्ड KL पूर्ण शब्दावली में टीचर और स्टूडेंट के बीच असहमति को दंडित करता है:
संयुक्त लॉस
दोनों पद अलग-अलग सामान्यीकृत होने के बजाय एक हर साझा करते हैं। यह हर वैश्विक प्रशिक्षण बैच में अनुकरण के लिए चुने गए कुल टोकन की गणना करता है। भार अनुकरण के सापेक्ष सुधारात्मक प्रशिक्षण के योगदान को नियंत्रित करता है।
यह साझा सामान्यीकरण हमारे प्रशिक्षण बुनियादी ढाँचे के एकल-हर इंटरफ़ेस में फिट बैठता है और बेसलाइन तुलना को सरल बनाते हुए जब होता है तो मानक SFT लॉस को पुनर्प्राप्त करता है। चूँकि CE टोकन KL टोकन की तुलना में बहुत अधिक प्रचुर मात्रा में हैं, इसलिए साझा हर का उपयोग करने से कुछ चिह्नित टोकन वाले बैचों में व्यक्तिगत KL टोकन को अनुपातहीन रूप से बड़े भार देने से भी बचा जाता है।
पहले के उदाहरणों पर लागू, W-3/W-2 मिश्रण और अमान्य सर्च कॉल वाले टर्न KL प्राप्त करते हैं। एक सफल सत्र में अन्य अनचिह्नित सहायक सामग्री अभी भी CE प्राप्त करती है। एक असफल सत्र में अन्य सहायक सामग्री को संदर्भ के रूप में रखा जाता है लेकिन न तो CE और न ही KL प्राप्त होता है।
मूल्यांकन क्या दर्शाते हैं
हमारे मूल्यांकन दो अलग-अलग सवालों के जवाब देते हैं। पहला, जब संकेत मौजूद होता है तो क्या संकेत वास्तव में मॉडल को किसी त्रुटि को सुधारने में मदद करता है? दूसरा, क्या प्रशिक्षण मॉडल को बिना संकेत के, बाद में उस त्रुटि से बचने में मदद करता है? पहला यह परीक्षण करता है कि क्या संकेत उपयोगी प्रशिक्षण संकेत प्रदान करते हैं। दूसरा यह परीक्षण करता है कि क्या मॉडल उनसे सीखता है।
संकेत मॉडल को गलतियों से दूर ले जा सकते हैं
यह सुनिश्चित करने के लिए कि संकेत वास्तव में मॉडल को गलतियों से दूर ले जा सकते हैं, हम प्रशिक्षण चलने से पहले पहले प्रश्न का परीक्षण करते हैं।
उपयोगकर्ता फ़ीडबैक
हमने शून्य तापमान पर समान GLM-5.2 बेस मॉडल का उपयोग करते हुए, संकेत के साथ और संकेत के बिना चिह्नित उपयोगकर्ता-फ़ीडबैक टर्न को पुनर्जीवित किया। एक ब्लाइंड जज बाद की शिकायत को देखता है, लेकिन न तो संकेत को और न ही इस बात को देखता है कि किस स्थिति ने उत्तर तैयार किया।
W-3 के उदाहरण में, संकेत उपसर्ग "W-" के बाद अगले-टोकन की संभावना को "3" की ओर और "2" से दूर स्थानांतरित करता है।
स्पष्ट रूप से बताए गए पहले के साक्ष्य द्वारा समर्थित एक बड़े 40-टर्न हेल्ड-आउट नमूने पर, निश्चित या ट्रैक पर आंके गए हिस्से की हिस्सेदारी संकेत के बिना 40.0% से बढ़कर संकेत के साथ 75.0% हो जाती है। अनुमानित इरादे द्वारा समर्थित अन्य 40 टर्न पर, यह 32.5% से बढ़कर 80.0% हो जाता है।
टूल त्रुटियाँ
सर्च टूल त्रुटि के उदाहरण में, संकेत वास्तव में वर्ष टोकन से संभाव्यता द्रव्यमान को महीने के टोकन की ओर स्थानांतरित करता है।
एक बड़े 985-टर्न हेल्ड-आउट नमूने पर, हम समान बेस मॉडल का उपयोग करके संकेत के साथ और संकेत के बिना प्रत्येक टर्न को चार बार पुनर्जीवित करते हैं। एक ब्लाइंड जज मूल्यांकन करता है कि क्या प्रत्येक पुनरुत्थान मूल विफलता से बचता है। संकेत विफलता से बचाव को 75.1% से बढ़ाकर 93.7% कर देते हैं, जो 18.6 प्रतिशत अंकों की एक युग्मित वृद्धि है, और सुधारात्मक कार्रवाई करने वाले हिस्से को 60.6% से बढ़ाकर 82.3% कर देते हैं। अकेले बार-बार सैंपलिंग से ठीक होने में संघर्ष करने वाली त्रुटियों पर लाभ सबसे बड़ा होता है।
प्रशिक्षण के बाद टूल की विश्वसनीयता और उपयोगकर्ता प्रतिक्रिया
इसके बाद हम परीक्षण करते हैं कि क्या प्रशिक्षित मॉडल बिना संकेत प्राप्त किए कम गलतियाँ करता है। हम स्टॉक मॉडल और विभिन्न पोस्ट-ट्रेंड चेकपॉइंट्स का मूल्यांकन ऑफ़लाइन बेंचमार्क कार्यों और लाइव उपयोगकर्ता सत्रों में करते हैं, और कम टूल विफलताओं तथा कम उपयोगकर्ता असंतोष की जाँच करते हैं।
ऑफ़लाइन मूल्यांकन
ऑफ़लाइन मूल्यांकन BrowseComp, Finch, WideSearch, DRACO, DSQA, SpreadsheetBench, HLE, एक प्रतिनिधि Computer कार्य सेट का उपयोग करता है, और कौशल लोडिंग, दस्तावेज़ समीक्षा और इनलाइन उद्धरणों की जाँच करता है। हम मूल्यांकन प्रक्षेपवक्रों में उन टूल कॉलों के हिस्से को मापते हैं जिनके परिणामों को स्पष्ट रूप से त्रुटियों के रूप में चिह्नित किया गया है।
इन मूल्यांकनों में, रिकॉर्ड की गई टूल-त्रुटि दर स्टॉक GLM 5.2 के लिए 2.79%, केवल-RFT चेकपॉइंट के लिए 1.35%, और RFT-प्लस-OPSD चेकपॉइंट के लिए 0.87% थी। इन चेकपॉइंट को अलग-अलग डेटा पर प्रशिक्षित किया गया था, इसलिए यह OPSD का मिलान-डेटा एब्लेशन नहीं है। कार्य-स्तरीय बेंचमार्क परिणाम मिश्रित थे, इसलिए कम टूल त्रुटियाँ अकेले आवश्यक रूप से कार्य सफलता में व्यापक सुधार में अनुवाद नहीं करती हैं।
ऑनलाइन मूल्यांकन: GLM-5.2
GLM-5.2 के लिए, हमने प्रत्येक स्थिति में लगभग एक लाख उपयोगकर्ताओं के साथ दो अलग-अलग A/B परीक्षण चलाए। पहले में, एक शुरुआती RFT-plus-OPSD चेकपॉइंट की टूल-विफलता दर स्टॉक GLM 5.2 (2.94%) की तुलना में थोड़ी कम (2.82%) थी, लेकिन अंतर सांख्यिकीय रूप से महत्वपूर्ण नहीं था।
बाद के परीक्षण में, हमने दो RFT-प्लस-OPSD चेकपॉइंट की तुलना की: एक पहले वाला (चेकपॉइंट एक) और एक बाद वाला (चेकपॉइंट दो)। रिकॉर्ड की गई स्थिति वाले कॉल के 2.24% से गिरकर टूल-कॉल विफलताएँ 1.77% हो गईं। यह 21.2% की सांख्यिकीय रूप से महत्वपूर्ण सापेक्ष कमी थी। हमने ऑनलाइन स्टॉक GLM 5.2 के साथ सीधे चेकपॉइंट दो की तुलना नहीं की।
उपयोगकर्ता-प्रतिक्रिया के परिणाम कम निर्णायक थे। दूसरे GLM-5.2 प्रयोग में, मजबूत असंतोष (मध्यम या उच्च) की औसत संभावना पहले चेकपॉइंट के लिए 2.58% और दूसरे चेकपॉइंट के लिए 2.54% थी, जिसमें कोई सांख्यिकीय रूप से महत्वपूर्ण अंतर नहीं था।
ऑनलाइन मूल्यांकन: GLM-5.3
GLM-5.3 के लिए, हमने पोस्ट-ट्रेन्ड चेकपॉइंट की सीधे स्टॉक GLM-5.3 से तुलना की। दर्ज स्थिति वाली कॉलों में टूल-कॉल विफलताएं 3.56% से घटकर 2.38% हो गईं, जो 33.04% की सापेक्ष कमी है। MID+ दर, यानी मध्यम या उच्च असंतोष की औसत अनुमानित संभावना, 4.12% से घटकर 3.41% हो गई, जो 17.2% की सापेक्ष कमी है। दोनों कमियां सांख्यिकीय रूप से महत्वपूर्ण थीं।
निष्कर्ष
केंद्रीय विचार केवल सत्र के स्तर पर नहीं, बल्कि निर्णय के स्तर पर सीखना है।
एक सफल परिणाम गलतियों को छुपा सकता है, और एक असफल सत्र अभी भी यह प्रकट कर सकता है कि कैसे सुधार किया जाए। हम सफल सत्रों से उपयोगी व्यवहार को एक आधार के रूप में रखते हैं, टालने योग्य विफलताओं की पहचान करने के लिए शिकायतों और टूल त्रुटियों का उपयोग करते हैं, और उन गलतियों और सुधारों को स्पष्ट करने पर मॉडल को उन भविष्यवाणियों की ओर प्रशिक्षित करते हैं जो यह करता है। सफलता संरक्षित करने के लिए व्यवहार प्रदान करती है; विफलता सुधार के लिए दिशा प्रदान करती है।
वास्तविक दुनिया का उपयोग इस दृष्टिकोण को विशेष रूप से उपयोगी बनाता है। वास्तविक उपयोगकर्ता ऐसे लक्ष्य, विवशताएँ और वर्कफ़्लो लाते हैं जिनका सिंथेटिक वातावरण में अनुमान लगाना मुश्किल होता है। उनके सुधार उन आवश्यकताओं को प्रकट करते हैं जो मॉडल से छूट गईं, जबकि टूल त्रुटियाँ इस बात के बीच के अंतराल को उजागर करती हैं कि मॉडल ने क्या प्रयास किया और पर्यावरण क्या अनुमति देता है। ये संकेत परिणाम-आधारित प्रशिक्षण के पूरक हैं: केवल यह पूछने के बजाय कि क्या कोई कार्य सफल हुआ, हम यह पूछ सकते हैं कि मॉडल कहाँ गलत हुआ और कौन सी जानकारी इसे बेहतर निर्णय लेने में मदद कर सकती थी।
सीमाएँ उतनी ही महत्वपूर्ण हैं। जज गलत हो सकते हैं, और एक टर्न को सुधारने से इस बात की गारंटी नहीं मिलती है कि पूरा कार्य सफल हो जाएगा। इसका लक्ष्य केवल ऐसा एजेंट बनना नहीं है जो सुधार के बाद रिकवर हो जाए। बल्कि यह ऐसा एजेंट है जिसे कम बार सुधार की आवश्यकता होती है।
उद्धरण
@online{perplexity2026LearningFromRealWorldExperience,
author = {{Perplexity} and Senzeyu Zhang and Chuan Wang and Hang Wu and Hao Zhang and Yuan Liang and Yunfan Zhong and Phi Hoang and Claire Beamer and Jeremy Yang and Andrew Wilson and Denis Yarats},
title = {{Learning from real-world experience}},
date = {2026-09-21},
url = {https://www.perplexity.ai/hub/blog/learning-from-real-world-experience}
}