वास्तविक जगातील अनुभवातून शिकणे

वास्तविक जगात वापरकर्ते आमच्या उत्पादनांशी कसे संवाद साधतात हा मॉडेल प्रशिक्षणासाठी एक मौल्यवान स्त्रोत आहे. डेटा भरपूर आहे, वापरकर्ता कार्यांचे वास्तविक वितरण प्रतिबिंबित करतो आणि वापरकर्त्याच्या सुधारणा आणि टूल अपयश कॅप्चर करतो जे कृत्रिम वातावरण चुकवू शकते.

वास्तविक जगातील डेटावरून शिकण्याचा एक सामान्य मार्ग म्हणजे रिजेक्शन सॅम्पलिंग फाईन-ट्यूनिंग: प्रत्येक सत्राच्या परिणामाचे मूल्यांकन करा, यशस्वी सत्रे ठेवा आणि मॉडेलला त्यांचे अनुकरण करण्यासाठी प्रशिक्षण द्या. परंतु यशस्वी परिणामाचा अर्थ प्रत्येक पायरी बरोबर होती असा होत नाही, त्यामुळे संपूर्ण ट्रॅजेक्ट्रीचे अनुकरण केल्याने चांगल्या व्यतिरिक्त वाईट मध्यवर्ती वर्तनांना बळकट होण्याचा धोका असतो. अयशस्वी सत्रे टाकून दिल्याने मॉडेल कुठे कमी पडतो याचे महत्त्वपूर्ण पुरावे देखील गमावले जातात.

यशस्वी आणि अयशस्वी दोन्ही सत्रांमधून शिकण्यासाठी आम्ही रिजेक्शन सॅम्पलिंग फाईन-ट्यूनिंगला हिंट-गाईडेड सेल्फ-डिस्टिलेशनसह एकत्र करतो. हिंट ही एक छोटी corrective instruction असते जी मॉडेलने चूक केल्यावर त्याच्याकडे आधीपासून असलेल्या माहितीवर आधारित असते. यशस्वी सत्रांमधील उपयुक्त पायऱ्या नक्कल करण्याचे लक्ष्य राहतात, तर ग्राउंड केलेल्या हिंट्स टाळता येण्यासारख्या चुकांना सुधारणा लक्ष्यांमध्ये बदलतात.

वापरकर्त्याच्या सुधारणा आणि टूल त्रुटी शेवटी कार्य यशस्वी झाले की नाही याच्या वर, वाटेत काय चूक झाली याबद्दल पर्यवेक्षण जोडतात. कृत्रिम वातावरणातील त्या वातावरणामधील आणि वास्तविक जगातील वापरावरील दरी कमी करण्यात मदत करण्यासाठी आम्ही सिंथेटिक वातावरणातील रीइन्फोर्समेंट लर्निंगनंतर हा टप्पा लागू करतो.

प्रत्यक्ष वापरामध्ये, नंतरच्या पोस्ट-ट्रेन्ड GLM-5.2 चेकपॉइंटने पूर्वीच्या ट्रेन केलेल्या चेकपॉइंटच्या तुलनेत टूल-कॉल अपयश २१.२% ने कमी केले. GLM-5.3 साठी, पोस्ट-ट्रेनिं ेने स्टॉक मॉडेलच्या तुलनेत टूल-कॉल अपयश ३३.०% ने आणि मध्यम किंवा उच्च वापरकर्ता असमाधानाची सरासरी अंदाजित संभाव्यता १७.२% ने कमी केली.

कृत्रिम कार्ये आम्हाला सत्यापित करण्यास सोपे परिणाम असलेले नियंत्रित समस्या तयार करू देतात, परंतु ती सामान्यत: एकाच प्रॉम्प्टपुरती मर्यादित असतात आणि आपण स्पष्टपणे डिझाइन केलेल्या परिदृश्यांनाच कव्हर करू शकतात.

याउलट, वास्तविक जगातील सत्रांमधील वापरकर्ते परस्परसंवादाच्या अनेक टर्न्सवर उलगडणाऱ्या सत्रांमध्ये विविध सूचना, संदर्भ आणि टूल संयोजन आणतात. असा वास्तविक जगाचा वापर नैसर्गिकरित्या चुकांचे दोन मौल्यवान संकेत देतो: वापरकर्त्याच्या सुधारणा उघड करतात की एजंट त्यांना काय हवे होते ते वितरीत करण्यात कुठे अपयशी ठरले, आणि टूल त्रुटी दर्शवतात की वास्तविक वातावरणात त्याच्या कृती कुठे बिघडल्या. आमची सॅम्पलिंग पाइपलाइन वैयक्तिकरित्या ओळखण्यायोग्य माहिती (PII) असलेली आणि ऑप्ट आउट केलेल्या वापरकर्त्यांची सत्रे वगळून वापरकर्त्यांच्या गोपनीयतेचा आणि प्रशिक्षण पसंतींचा आदर करते.

वास्तविक जगातील डेटा आम्हाला अपयशाच्या केसेस देतो ज्या कृत्रिम वातावरण उघडू शकत नाही आणि बहुतेकदा अपयश आधीच कुठे घडले होते यासह येतो.

वास्तविक जगातील डेटावर प्रशिक्षण देताना, मानक रिजेक्शन सॅम्पलिंग फाईन-ट्यूनिंग (RFT) चांगल्या मध्यवर्ती कृतींना वाईट कृतींपासून वेगळे करण्यासाठी वापरकर्ता आणि टूल अभिप्रायाचा स्पष्टपणे वापर न करता, त्यांच्या अंतिम परिणामांवर आधारित यशस्वी सत्रे निवडते. एजंट वाईट टूल कॉलवरून पुनर्प्राप्त करू शकतो किंवा वापरकर्ता अभिप्राया नंतर चूक सुधारू शकतो आणि तरीही शेवटी योग्य आउटपुट वितरीत करू शकतो.

यशस्वी न झालेली सत्रे वगळल्याने नमुना कार्यक्षमता देखीलमर्यादित होते. जे सत्र कधीही चांगल्या परिणामापर्यंत पोहोचत नाही ते देखील उपयुक्त प्रशिक्षण संकेत म्हणून स्पष्ट, टाळता येणारी चूक उघड करू शकते.

आम्ही दोन निर्णयांचे विलगीकरण करून या मर्यादा दूर करतो: कोणती सत्रे अनुकरण करण्यायोग्य वर्तन समाविष्ट करतात आणि कोणत्या टर्न्समध्ये सुधारणा करण्यायोग्य चुका आहेत. डेटा पाइपलाइन हे निर्णय स्वतंत्रपणे करते, नंतर मॉडेल टर्न्सना तीन उपचारांपैकी एक देते:

अनुकरण करा: यशस्वी सत्रांमधील गैर-त्रुटी टर्न्सना सामान्य क्रॉस-एन्ट्री (CE) लॉस प्राप्त होतो, ज्यामुळे रेकॉर्ड केलेल्या टोकन्सची संभाव्यता वाढते.
सुधार करा: यशस्वी आणि अयशस्वी दोन्ही सत्रांमध्ये, वैध हिंट असलेले त्रुटी टर्न्स कुल्बॅक-लेबलर (KL) डायव्हर्जन्स लॉस प्राप्त करतात, ज्यामुळे मॉडेलला हिंट दिसल्यावर ते जे पुढील-टोकन अंदाज करते त्या दिशेने हलवले जाते.
संदर्भ म्हणून ठेवा: ज्या अयशस्वी सत्रांमध्ये सत्यापित हिंटचा अभाव आहे त्यांमधील टर्न्स, आणि कोणत्याही सत्र प्रकारामध्ये सत्यापित हिंटशिवाय चिन्हांकित वाईट टर्न्स, संदर्भ म्हणून काम करतात परंतु दोन्हीपैकी कोणतीही लॉसेस प्राप्त करत नाहीत.

परिणामस्वरूप, यशस्वी सत्रे अनुकरण आणि सुधारणा दोन्ही टार्गेट्स पुरवू शकतात, तर अयशस्वी सत्रे केवळ सुधारणा टार्गेट्स पुरवतात. सिस्टम, वापरकर्ता आणि टूल आउटपुटसह इतर सर्व उरलेले टर्न्स संदर्भ म्हणून राहतात.

सत्र-राउटिंग आकृती: यशस्वी सत्रे CE अनुकरण आणि पात्र सुचवलेली सुधारणा प्रदान करतात; अयशस्वी सत्रे केवळ पात्र सुधारणा प्रदान करतात. — वर्तमान सत्र राउटिंग आणि सहाय्यक-सामग्री मास्क. यशस्वी सत्रे अनुकरण टार्गेट्स योगदान देतात; सत्र यशस्वी नसले तरीही राखीव अभिप्राय रेकॉर्ड सुचवलेले सुधारणा योगदान देऊ शकतात. इतर सामग्री संदर्भ म्हणून राहते. अपूर्ण सत्रे वगळली जातात. अंतिम नसलेला यील्ड/स्टॉप-टोकन CE अपवाद काढलेला नाही, आणि ही आकृती पूर्वीच्या चेकपॉइंटद्वारे वापरलेले मिश्रण स्थापित करत नाही.

अनुकरण भाग मानक RFT वापरतो. सुधारणात्मक भाग ऑन-पॉलिसी सेल्फ-डिस्टिलेशन (OPSD) वापरतो: शिक्षक आणि विद्यार्थी म्हणून समान मॉडेल कार्य करते, ज्यामध्ये शिक्षकाला विशेष माहिती दिली जाते. येथे, ती विशेष माहिती एक टाळता येणारी चूक स्पष्ट करणारी छोटी हिंट आहे. हिंट न देता विद्यार्थ्याला शिक्षकाच्या पुढील-टोकन अंदाजांशी जुळवून घेण्यासाठी आम्ही प्रशिक्षण देतो.

दोन्ही भाग महत्त्वाचे आहेत. केवळ-करेक्शन प्रशिक्षणातून शॉर्टकट समोर येऊ शकतो: सुधारणा शिकण्याऐवजी शिक्षक आणि विद्यार्थी संदर्भ दुर्लक्षित करून सहमत होऊ शकतात. CE टर्म प्रशिक्षणाला उपयुक्त वर्तनाशी जोडून ठेवते, ज्यामुळे संदर्भ दुर्लक्षित केल्यामुळे होणारी सहमती टाळण्यास मदत होते.

पोस्ट-ट्रेन केलेले विद्यार्थी नंतर कॉम्प्युटरमध्ये मॉडेल पर्याय बनतात. लाईव्ह वापरावरील ताजे सत्र प्रशिक्षण पाइपलाइनच्या दुसऱ्या फेरीत प्रवेश करण्यापूर्वी समान पात्रता आणि गोपनीयता फिल्टरमधून जातात.

पुढे, आपण अनुकरण आणि सुधारणा दोन्ही समाविष्ट करणाऱ्या ठोस उदाहरणातून जातो.

अधिकृत कागदपत्रे वापरून Python 3.13 मधील asyncio बदलांच्या तुलनेची वापरकर्ता विनंती करतो अशा शेवटी यशस्वी होणाऱ्या सत्राचा विचार करा. आमची टूल कागदपत्रे सांगत की search.web प्रत्येक url फील्डसह हिट्सची सूची परत करते.

तुलनेसाठी पुरावा गोळा करण्याच्या भागा म्हणून मॉडेल प्रथम एका आवृत्तीसाठी वैध शोध चालवते, जे अनुकरण करण्यासाठी एक चांगले वर्तन आहे.

तथापि, पुढील कोड-एक्झिक्युशन कॉल चुकीच्या पद्धतीने त्या सूचीला डिक्शनरी मानतो. कोड टूल TypeError: list indices must be integers or slices, not str परत करते. कॉल करण्यापूर्वी परतावा प्रकार दस्तऐवजीकरण केले गेल्यामुळे, ही अशी चूक आहे जी मॉडेल टाळू शकली पाहिजे होती. त्या कृतीची दुरुस्ती करण्यासाठी योग्य कॉलसह हिंट तयार केली जाऊ शकते.

वर्णनात्मक कोडिंग सत्र: सिस्टम आणि वापरकर्ता इनपुट आणि टूल त्रुटी संदर्भ म्हणून राहतात; उपयुक्त रेकॉर्ड केलेले शोध आणि पुनर्प्राप्ती कॉल यशस्वी सत्रामध्ये CE प्राप्त करतात; चिन्हांकित सदोष सूची लुकअप ग्राउंडेड हिंट दिलेल्या शिक्षकाकडे KL प्राप्त करतो. — एक वर्णनात्मक कोडिंग सत्र तीन प्रशिक्षण भूमिका दर्शवते: केवळ-संदर्भ इनपुट आणि टूल आउटपुट (राखाडी), उपयुक्त रेकॉर्ड केलेल्या कॉल्सचे CE अनुकरण (गडद), आणि चिन्हांकित चुकीची दुरुस्ती KL (टीळ). येथे, मॉडेल चुकीच्या पद्धतीने शोध हिट्सच्या सूचीला डिक्शनरी मानतो; पूर्वीच्या टूल कागदपत्रांवर ग्राउंड केलेली केवळ-शिक्षक हिंट सुधारणेला मार्गदर्शन करते. जेव्हा पूर्ण झालेले सत्र यशस्वी न्यायले जाते तेव्हाच CE टार्गेट्स लागू होतात, तर अयशस्वी सत्र अजूनही पात्र KL सुधारणा टार्गेट पुरवू शकते.

प्रशिक्षण पाइपलाइनमध्ये चार टप्पे आहेत: सत्रे निवडा आणि त्यांच्या परिणामांचे मूल्यांकन करा, युजर फीडबॅक आणि टूल त्रुटींमधून चुका ओळखा आणि हिंट्स तयार करा, शिक्षक आणि विद्यार्थी दोघांकडून पुढील-टोकन संभाव्यता तयार करा आणि संयोजित CE आणि KL लॉससह मॉडेलला प्रशिक्षण द्या.

सॅम्पलिंग पाइपलाइन GLM 5.2 द्वारे सर्व्ह केलेल्या प्रत्यक्ष Computer सत्रांच्या प्रशिक्षणास पात्र अशा उपसमुहातून डेटा घेते. या वर्कफ्लोसाठी उदाहरणे निवडण्यापूर्वी training opt-outs आणि पाइपलाइनची PII-संबंधित वगळणी लागू केली जातात.

प्रारंभिक स्क्रीनिंग प्रक्रिया LLM ज्युजद्वारे पाच-गुण कार्य-कठीण मोजमापावर 4 किंवा 5 रेट केलेल्या उमेदवारांची निवड करते आणि त्यांना 2 ग्रुप्समध्ये विभाजित करते:

युजर-फीडबॅक ग्रुपमध्ये अस्सल वापरकर्ता फॉलो-अप किंवा मध्यम-ते-उच्च असमाधान फ्लॅग असलेली सत्रे समाविष्ट आहेत. आम्हाला हे उच्च-हेतू फॉलो-अप शिकण्यासाठी विशेषतः उपयुक्त वाटतात: वापरकर्ते सक्रियपणे कार्य पूर्ण करण्याचा प्रयत्न करत आहेत, आणि त्यांच्या सुधारणा मॉडेल काय चुकले हे अचूकपणे दर्शवतात.
टूल-त्रुटी ग्रुपमध्ये नियम-आधारित तपासांद्वारे फ्लॅग केलेले अपयशी कॉल असलेली सत्रे समाविष्ट आहेत, ज्यामध्ये ओळखल्या गेलेल्या पायाभूत सुविधांच्या अपयशांना आणि नाकारलेल्या अधिकृततेला वगळले आहे.

दोन एलएलएम (LLM) ज्युज नंतर वापरकर्त्याच्या विनंतीनुसार अंतिम वितरणाचे मूल्यांकन करतात; सत्राला "यशस्वी" म्हणून चिन्हांकित करण्यासाठी दोन्ही ज्युजनी सकारात्मक निकाल देणे आवश्यक आहे. आर्टिफॅक्ट्स वितरीत करणाऱ्या केसेससाठी, परिणाम टप्पा वितरणाचे पुनर्रचना आणि तपासणी करू शकतो, आणि तो टप्पा अयशस्वी झाल्यास त्याच्या मजकूर-आधारित निर्णयांवर परत जाऊ शकतो. अपूर्ण म्हणून वर्गीकृत केलेली सत्रे, जसे की वापरकर्त्याची वाट पाहणारे काम, वगळली जातात.

ही पायरी शिकण्याच्या संकेतांचे संभाव्य स्रोत ओळखते; तथापि, प्रत्येक त्रुटी मॉडेलला जबाबदार धरता येत नाही, कारण काही अस्पष्ट सूचना किंवा पायाभूत सुविधांच्या अपयशांमुळे उद्भवतात. नंतरचे ॲनोटेशन ठरवते की कोणते उमेदवार दोष खरोखर टाळण्यायोग्य आणि प्रशिक्षणासाठी योग्य आहेत.

वापरकर्ता-अभिप्राय गटातील एक नमुना सत्र विचारात घ्या, जिथे वापरकर्ता विचारतो, “How do I find my w3 on paychex”. मॉडेल “w3” ला W-2 साठीची टायपो म्हणून हाताळते, W-2 सूचनांचा शोध घेते, आणि ते फॉर्म कसा शोधायचा ते समजावते. वापरकर्त्याचा पुढील प्रश्न, “I meant the W-3 transmittal form,” चूक ओळखतो, जरी सत्र अखेरीस यशस्वी झाले तरीही.

तक्रार चूक शोधण्यात मदत करते, परंतु मूळ कारण “w3” चा अर्थ W-2 असा लावण्याचा पूर्वीचा निर्णय आहे. मूळ विनंतीमुळे चूक टाळता येण्यासारखी बनते: मॉडेल W-3 संरक्षित करू शकले असते किंवा स्पष्टीकरणासाठी विचारू शकले असते. असे निष्पन्न होते की तक्रारीपूर्वीची शेवटची सहाय्यक टर्न ही केवळ अर्ध्या वेळा मूळ कारण असते.

आमची ॲनोटेशन पाइपलाइन प्रत्येक युजर-फीडबॅक सत्रात पद्धतशीरपणे कारण आणि परिणामाचा नकाशा तयार करते. ॲनोटेटर प्रथम चुकलेली आवश्यकता किंवा पूर्वीच्या संदर्भाद्वारे समर्थित हेतूसाठी स्क्रीन करतो. त्यानंतर तीन LLM ज्युज जबाबदार टर्न्स ओळखतात, ज्यासाठी दिलेल्या टर्नवर किमान दोघांचे सहमत असणे आवश्यक असते. कधीकधी एखादे पूर्वीचे विधान स्पष्टपणे आवश्यकता स्थापित करते. इतर केसेसमध्ये, कोणतेही एक पूर्व विधान असे करत नाही, परंतु मागील संभाषणाचे अनेक भाग संयुक्तपणे अभिप्रेत वर्तन अनुमानित करतात. ही रचना त्यांना तक्रारीला शेवटच्या उत्तराशी जोडण्याऐवजी पूर्वीच्या मूळ चुकाशी जोडण्याची परवानगी देते.

हिंट स्वीकारण्यापूर्वी, पाइपलाइन हे देखील तपासते की त्याचे सुधारणात्मक दावे चिन्हांकित टर्नपूर्वी उपलब्ध असलेल्या माहितीचे अनुसरण करतात का. या तपासांचा उद्देश दूरदृष्टी पूर्वग्रह (hindsight bias) कमी करणे आहे, जिथे तक्रारीत उघड झालेली नवीन प्राधान्ययोजना अशी मानली जाते जी मॉडेलला आधीच माहीत असावी.

या उदाहरणात, hint मॉडेलला W-2 ऐवजी Paychex वर W-3 transmittal form शोधण्यास, किंवा विनंती संदिग्ध असल्यास वापरकर्ता कोणता form म्हणत आहे ते विचारण्यास सांगतो. correction आधीच्या interpretation आणि search decision ला लक्ष्य करते, फक्त अंतिम उत्तराला नाही. मूळ turn अपरिवर्तित राहतो; annotation मध्ये is_bad_turn: true आणि एक nonempty hint जोडले जाते.

W-3 विनंतीचा अर्थ चुकीचा लावून W-2 केला जातो; नंतरची तक्रार पूर्वीच्या शोध निर्णयावर शोधली जाते आणि पूर्वीच्या पुराव्याविरुद्ध तपासली जाते. — ॲनोटेशन प्रक्रियेसह आच्छादित केलेल्या, तक्रार पूर्वीच्या चुकीशी कशी जोडली जाते हे दर्शवणारे एक वास्तविक सत्र. वापरकर्त्याने Paychex वर “w3” मागितले, परंतु मॉडेलने त्याला W-2 साठी टायपो मानले आणि चुकीचा फॉर्म शोधला. प्रस्तावक सहमती मूळ कारण शोधते, तर दोन ग्राउंडिंग तपासणी मूल्यांकन करतात की पुरावा चुकीच्या आधीचा आहे का आणि हिंटचे दावे त्या बिंदूवर उपलब्ध असलेल्या माहितीचे अनुसरण करतात का. स्वीकारलेले ॲनोटेशन मूळ मजकूर जतन करतात आणि पुनर्लेखन केलेल्या टार्गेट्सऐवजी खूण आणि हिंट्स जोडतात.

एजंट recency_filter: "year" सह शोध घेतो अशा शोध कॉलसह टूल-त्रुटी ग्रुपमधील आणखी एक सत्र विचारात घ्या, परंतु परवानगी असलेले मूल्ये “day,” “week,” किंवा “month” असल्यामुळे टूल ते नाकारते. हे स्पष्ट स्कीमा उल्लंघन आहे.

टूल-त्रुटी मार्ग ज्ञात चुकांसाठी निर्धारी नियम आणि अस्पष्ट केसेससाठी मॉडेल निर्णय वापरतो. केवळ त्रुटी संदेश देखील मॉडेलला दोष देण्यासाठी पुरेसा नाही; न्याय्य सुधारणेने अशा गोष्टीकडे निर्देश केला पाहिजे जी मॉडेलला टूल स्कीमा, सिस्टम सूचना किंवा पूर्वीच्या संभाषणावरून माहीत असू शकली असती.

शोध कॉल अवैध recency_filter मूल्य year वापरतो; ग्राउंडेड हिंट मॉडेलला सूचीबद्ध मूल्य वापरण्यास किंवा पर्यायी फील्ड वगळण्यास निर्देश देते. — अहवालचा अवैध शोध युक्तिवाद वर्तमान टूल-त्रुटी प्रक्रिया दर्शवतो. स्कीमामुळे ही चूक टाळता येण्यासारखी बनते; केवळ आउटेजमुळे नाही. मूळ कॉल रेकॉर्डमध्ये राहतो आणि ग्राउंडेड हिंट प्राप्त करतो. फील्ड पर्यायी असल्यास हिंट सूचीबद्ध मूल्य किंवा वगळण्याची परवानगी देते; ते प्रत्येक विनंतीसाठी “month” आवश्यक करत नाही.

येथे, हिंट अयशस्वी कॉलचे नाव देते, प्रमाणीकरण त्रुटी समाविष्ट करते आणि मॉडेलला परवानगी असलेले मूल्य वापरण्यास किंवा फील्ड पर्यायी असल्यास ते वगळण्यास निर्देश देते.

एकदा टर्न चिन्हांकित झाल्यानंतर, ट्रेनर समान चेकपॉइंट दोनदा चालवतो: एकदा शिक्षक म्हणून आणि एकदा विद्यार्थी म्हणून. शिक्षकाला हिंट दिसते; विद्यार्थ्याला दिसत नाही.

दोन्ही पासेसमध्ये teacher forcing वापरले जाते, जिथे आपण मॉडेलला नवीन टोकन्स निवडू देण्याऐवजी नोंदवलेले सत्र फीड करतो. forward pass प्रत्येक टप्प्यावर तरीही पूर्ण next-token वितरण तयार करते, पण ते नेहमीच rollout tokens वर नव्हे, तर रेकॉर्डिंगमधील fixed prefix वर आधारित असते.

शोध (सर्च) उदाहरणासाठी, हिंट दिल्यावर समान मॉडेल "month" ला खूप जास्त संभाव्यता आणि "year" ला कमी संभाव्यता देते. प्रशिक्षण या डिस्ट्रिब्युशनल शिफ्टचा वापर सॉफ्ट टार्गेट म्हणून करते.

समान मॉडेल हिंटसह आणि हिंटशिवाय लॉग केलेल्या टर्नचे गुण मोजतो; वेगळे केलेले शिक्षक संभाव्यते केएल (KL) टार्गेट्स पुरवतात तर CE अनुकरणाला आधार देतो. — दोन पास, वजनांचा एक संच. दोन्ही पास लॉग केलेले सातत्य (continuation) स्कोअर करतात; फक्त शिक्षकाला हिंट्स प्राप्त होतात. त्याच्या वेगळ्या केलेल्या पुढील-टोकन संभाव्यता फॉरवर्ड केएल (KL) द्वारे विद्यार्थ्याला मार्गदर्शन करतात. स्वतंत्र CE टार्गेट्स अनुकरणाला आधार देतात. दोन्ही लॉसेस एक वजन अपडेट पुरवतात. पूर्वीच्या हिंट्स शिक्षकांच्या वर्तमान सेगमेंटमध्ये राहू शकतात; कोणताही पास बदली प्रशिक्षण उत्तर तयार करत नाही.

शिक्षकाचे अंदाज वेगळे केलेले किंवा स्टॉप-ग्रेडियंट असतात: ते लक्ष (टार्गेट) पुरवतात परंतु शिक्षक पासद्वारे कोणतेही अपडेट प्राप्त करत नाहीत. विद्यार्थ्याच्या पासनंतर, एक ऑप्टिमाइझर पायरी सामायिक मॉडेल अपडेट करते.

CE लॉस अनुकरणासाठी निवडलेल्या रेकॉर्ड केलेल्या टोकन्सना ग्राउंड-ट्रूथ टार्गेट्स मानतो आणि मॉडेलला त्यांना कमी संभाव्यता दिल्याबद्दल दंड आकारतो. हे कठीण अनुकरण टार्गेट तयार करते.

टोकन पोझिशन वर, समजा हे संपूर्ण शब्दावली मध्ये टोकन ची विद्यार्थ्याची संभाव्यता आहे. प्रतिसाद किंवा टूल कॉलमधील रेकॉर्ड केलेले पुढील टोकन आहे, वन-हॉट टार्गेट वितरण आहे. $i$ $p_i(v)$ $v$ $V$ $y_i$ $r_i$

r_i(v)=\mathbf{1}[v=y_i]

क्रॉस-एन्ट्री मोजते की विद्यार्थी त्या रेकॉर्ड केलेल्या टोकनचा किती चांगल्या प्रकारे अंदाज लावतो. वन-हॉट टार्गेटसह, ते $y_i$ ला नियुक्त केलेल्या नकारात्मक लॉग-संभाव्यतेपर्यंत कमी होते.

H(r_i,p_i)=-\sum_{v\in V}r_i(v)\log p_i(v)=-\log p_i(y_i)

CE मास्क $m_i^{\mathrm{CE}}$ टोकनचे अनुकरण कुठे केले जावे यासाठी $1$ आहे आणि इतरथा $0$ आहे. निवडलेल्या पोझिशन्सवर बेरीज केल्यास अनुकरण लॉस मिळतो.

\mathcal{L}_{\mathrm{CE}}=\sum_i m_i^{\mathrm{CE}}H(r_i,p_i)

केएल (KL) लॉस त्याऐवजी सॉफ्ट करेक्शन टार्गेट म्हणून शिक्षकांचे संपूर्ण पुढील-टोकन संभाव्यता वितरण $q_i$ वापरते. शिक्षकांच्या संदर्भामध्ये वर्तमान हिंट आणि त्या प्रशिक्षण विभागामध्ये राखीव ठेवलेली कोणतीही पूर्वीची हिंट समाविष्ट असते; विद्यार्थ्याचा संदर्भ नेहमी हिंट-मुक्त असतो.

KL मास्क $m_i^{\mathrm{KL}}$ टोकन सुधारले जावे तिथे $1$ आहे आणि इतरथा $0$ आहे; CE आणि KL मास्क ओव्हरलॅप होत नाहीत. या पोझिशन्सवर, फॉरवर्ड केएल (KL) संपूर्ण शब्दावलीमध्ये शिक्षक आणि विद्यार्थी यांच्यातील मतभेदाला दंड आकारतो:

\mathcal{L}_{\mathrm{KL}}=\sum_i m_i^{\mathrm{KL}}D_{\mathrm{KL}}(q_i\Vert p_i)=\sum_i m_i^{\mathrm{KL}}\sum_{v\in V}q_i(v)\log\frac{q_i(v)}{p_i(v)}

दोन्ही शर्ती वेगळ्या नॉर्मलाइज करण्याऐवजी एक डेनोमिनेटर सामायिक करतात. हा डेनोमिनेटर जागतिक प्रशिक्षण बॅचमधील अनुकरणासाठी निवडलेल्या एकूण टोकन्सची गणना करतो. वजन $\lambda$ अनुकरणाच्या सापेक्षा सुधारणात्मक प्रशिक्षणाचे योगदान नियंत्रित करते.

हे सामायिक नॉर्मलायझेशन आमच्या प्रशिक्षण पायाभूत सुविधांच्या सिंगल-डेनोमिनेटर इंटरफेसशी जुळते आणि $\lambda=0$ असताना मानक SFT लॉस पुनर्प्राप्त करते, ज्यामुळे बेझलाइन तुलना सोपी होते. CE टोकन्स KL टोकन्सपेक्षा खूप जास्त असल्याने, सामायिक डेनोमिनेटर वापरल्याने काही चिन्हांकित टोकन्स असलेल्या बॅचेसमध्ये वैयक्तिक KL टोकन्सना प्रमाणाबाहेर मोठी वजने देणे टाळले जाते.

\mathcal{L}=\frac{\mathcal{L}_{\mathrm{CE}}+\lambda\mathcal{L}_{\mathrm{KL}}}{\sum_i m_i^{\mathrm{CE}}}

पूर्वीच्या उदाहरणांवर लागू केल्यावर, W-3/W-2 मिक्स-अप आणि अवैध शोध कॉल समाविष्ट करणारे टर्न्स केएल (KL) प्राप्त करतात. यशस्वी सत्रातील इतर चिन्हांकित नसलेली सहाय्यक सामग्री अजूनही CE प्राप्त करते. अयशस्वी सत्रातील इतर सहाय्यक सामग्री संदर्भ म्हणून राखली जाते परंतु ना CE ना KL प्राप्त करते.

आमची मूल्यांकने दोन स्वतंत्र प्रश्नांची उत्तरे देतात. प्रथम, हिंट उपस्थित असताना ती खरोखर मॉडेलला चूक सुधारण्यास मदत करते का? दुसरे, प्रशिक्षण मॉडेलला हिंटशिवाय ती चूक नंतर टाळण्यास मदत करते का? प्रथम हे तपासते की हिंट्स उपयुक्त प्रशिक्षण संकेत देतात का. दुसरे हे तपासते की मॉडेल त्यांच्याकडून शिकते का.

हिंट खरोखरच मॉडेलला चुकांपासून दूर नेऊ शकतात याची खात्री करण्यासाठी आम्ही प्रशिक्षण सुरू होण्यापूर्वी पहिल्या प्रश्नाची चाचणी घेतो.

आम्ही झिरो टेंपरेचरवर समान GLM-5.2 बेस मॉडेल वापरून, हिंटसह आणि हिंटशिवाय चिन्हांकित युजर-फीडबॅक टर्न्स पुनरुत्पादित (regenerate) केले. अंध ज्युजला नंतरची तक्रार दिसते, परंतु ना हिंट दिसते ना कोणती अट उत्तर तयार करण्यासाठी कारणीभूत ठरली हे दिसते.

W-3 उदाहरणात, उपसर्ग "W-" नंतर हिंट पुढील-टोकन संभाव्यतेला "3" कडे आणि "2" पासून दूर नेतो.

न बदललेल्या बेस मॉडेलला हिंट मिळाल्यावर W- नंतरची पुढील-टोकन संभाव्यता 2 ऐवजी 3 कडे सरकते. — हिंट विनंती केलेले W-3 फॉर्म जतन करतो. बार्स आठ फॉरवर्ड पासमधील सरासरी पुढील-टोकन संभाव्यता दर्शवतात; व्हिस्कर निरीक्षण केलेली श्रेणी दर्शवतात, विश्वास अंतराल नाही. दोन्ही शर्ती न बदललेले बेस मॉडेल वापरतात.

स्पष्टपणे सांगितलेल्या पूर्वीच्या पुराव्याद्वारे समर्थित मोठ्या 40-टर्न राखलेल्या (held-out) नमुन्यावर, निश्चित किंवा ऑन-ट्रॅक न्याय केलेला हिस्सा हिंटशिवाय 40.0% वरून हिंटसह 75.0% पर्यंत वाढतो. अनुमानित हेतूद्वारे समर्थित आणखी 40 टर्न्सवर, तो 32.5% वरून 80.0% पर्यंत वाढतो.

हिंट प्रमाणीकरण: स्पष्ट पुराव्यासाठी निश्चित किंवा ऑन-ट्रॅक दर 40.0% वरून 75.0% पर्यंत आणि अनुमानित हेतूसाठी 32.5% वरून 80.0% पर्यंत वाढतात. — हिंट प्रमाणीकरण, पोस्ट-प्रशिक्षण मूल्यांकन नाही. शून्य तापमानावर न बदललेले GLM-5.2 वापरून प्रत्येक पुरावा ग्रुपमधील समान 40 चिन्हांकित टर्न्स हिंटसह आणि हिंटशिवाय पुनरुत्पादित केले जातात. ज्युजला तक्रार दिसते परंतु हिंट किंवा अट दिसत नाही. अहवालचे दर आणि नमुना आकारांमधून संख्या प्राप्त केल्या जातात; विश्वास अंतराल नोंदवले जात नाहीत.

शोध टूल त्रुटी उदाहरणात, हिंट खरोखरच वर्ष टोकनवरून महिना टोकनकडे संभाव्यता मास शिफ्ट करते.

हिंट न बदललेल्या बेस मॉडेलची पुढील-टोकन संभाव्यता वर्षपासून दूर आणि परवानगी असलेल्या मूल्य महिन्याकडे नेतो. — हिंट परवानगी असलेल्या मूल्याकडे संभाव्यता नेतो. बार्स आठ फॉरवर्ड पासमधील सरासरी पुढील-टोकन संभाव्यता दर्शवतात; व्हिस्कर निरीक्षण केलेली श्रेणी दर्शवतात, विश्वास अंतराल नाही. दोन्ही शर्ती समान बेस मॉडेल वापरतात; कोणत्याही प्रशिक्षित चेकपॉइंटची तुलना केली जात नाही.

मोठ्या 985-टर्न राखलेल्या (held-out) नमुन्यावर, आम्ही समान बेस मॉडेल वापरून हिंटसह आणि हिंटशिवाय प्रत्येक टर्न चार वेळा पुनरुत्पादित करतो. एक अंध ज्युज मूल्यांकन करतो की प्रत्येक पुनरुत्पादन मूळ अपयश टाळते का. हिंट्समुळे अपयश टाळण्याचे प्रमाण 75.1% वरून 93.7% पर्यंत वाढते, जी 18.6 टक्के गुणांची जोडीची वाढ आहे, आणि सुधारित कृती करणाऱ्याचा हिस्सा 60.6% वरून 82.3% पर्यंत वाढवतो. केवळ पुनरावृत्ती सॅम्पलिंग ज्या चुका दुरुस्त करण्यासाठी संघर्ष करते त्यावर वाढ सर्वात जास्त असते.

985 राखलेल्या चिन्हांकित टूल-त्रुटी टर्न्सवर, हिंट्स अपयश टाळणे 75.1% वरून 93.7% पर्यंत आणि सुधारित-कृती दर 60.6% वरून 82.3% पर्यंत वाढवतात. — प्रत्येक अटीसाठी चार पुनरुत्पादनांसह, 985 राखलेल्या चिन्हांकित टर्न्सवर टूल-त्रुटी हिंट प्रमाणीकरण. बार्स हिंटसह आणि हिंटशिवाय, न बदललेल्या बेस मॉडेलसाठी अपयश टाळणे आणि सुधारित-कृती दर दर्शवतात. लक्ष्यित चूक टाळल्याने टूल-कॉल किंवा कार्य यश स्थापित होत नाही.

पुढे आपण तपासतो की प्रशिक्षित मॉडेल सूचनांशिवाय कमी चुका करते का. आम्ही stock model आणि विविध post-trained checkpoints यांचे offline benchmark tasks वर तसेच live user sessions मध्ये मूल्यांकन करतो, आणि कमी tool failures व कमी user dissatisfaction तपासतो.

ऑफलाइन मूल्यांकन BrowseComp, Finch, WideSearch, DRACO, DSQA, SpreadsheetBench, HLE, एक प्रातिनिधिक कॉम्प्युटर कार्य संच वापरते, आणि कौशल्य लोड करणे, दस्तऐवज पुनरावलोकन आणि इनलाइन उद्धरण तपासते. मूल्यांकन ट्रॅजेक्टरीजमध्ये ज्यांचे निकाल स्पष्टपणे त्रुटी म्हणून फ्लॅग केले आहेत अशा टूल कॉल्सचा हिस्सा आम्ही मोजतो.

या मूल्यांकनांमध्ये, रेकॉर्ड केलेले टूल-त्रुटी दर स्टॉक GLM 5.2 साठी 2.79%, RFT-फक्त चेकपॉइंटसाठी 1.35%, आणि RFT-plus-OPSD चेकपॉइंटसाठी 0.87% होते. हे चेकपॉइंट्स वेगवेगळ्या डेटावर प्रशिक्षित केले गेले होते, त्यामुळे हे OPSD चे जुळवलेले-डेटा ॲब्लेशन नाही. कार्य-स्तरीय बेंचमार्क निकाल संमिश्र होते, त्यामुळे केवळ कमी टूल त्रुटी म्हणजे कार्यांच्या यशात व्यापक सुधारणा असे नाही.

ऑफलाइन रेकॉर्ड केलेले टूल-त्रुटी दर: स्टॉक GLM 5.2 साठी 2.79%, केवळ-RFT साठी 1.35%, आणि RFT plus OPSD साठी 0.87%; प्रशिक्षण डेटा भिन्न आहेत. — स्टॉक GLM-5.2, RFT-only, आणि Rft-plus-OPSD चेकपॉइंट्ससाठी ऑफलाइन टूल-त्रुटी दर. चेकपॉइंट्समध्ये प्रशिक्षण डेटा भिन्न आहे; हे नियंत्रित ॲब्लेशन नाही.

GLM-5.2 साठी, आम्ही प्रत्येक स्थितीत सुमारे एक लाख वापरकर्त्यांसह दोन स्वतंत्र A/B चाचण्या चालवल्या. पहिल्या चाचणीत, सुरुवातीच्या RFT-plus-OPSD चेकपॉइंटचा टूल-अपयशाचा दर स्टॉक GLM 5.2 पेक्षा किंचित कमी होता, 2.82% विरुद्ध 2.94%, परंतु हा फरक सांख्यिकीयदृष्ट्या महत्त्वपूर्ण नव्हता.

नंतरच्या चाचणीत, आम्ही दोन RFT-plus-OPSD चेकपॉइंट्सची तुलना केली: एक आधीचा (चेकपॉइंट एक) आणि एक नंतरचा (चेकपॉइंट दोन). रेकॉर्ड केलेली स्थिती असलेल्या कॉल्सच्या 2.24% वरून टूल-कॉल अपयश 1.77% पर्यंत घसरले. ही सांख्यिकीयदृष्ट्या महत्त्वाची 21.2% सापेक्ष घट होती. आम्ही चेकपॉइंट दोनची थेट ऑनलाइन स्टॉक GLM 5.2 शी तुलना केली नाही.

वापरकर्त्याच्या अभिप्रायाचे निकाल कमी निर्णायक होते. दुसऱ्या GLM-5.2 प्रयोगात, तीव्र असमाधानाची (मध्यम किंवा उच्च) सरासरी संभाव्यता चेकपॉइंट एकसाठी 2.58% आणि चेकपॉइंट दोनसाठी 2.54% होती, ज्यामध्ये कोणताही सांख्यिकीयदृष्ट्या महत्त्वपूर्ण फरक नव्हता.

दोन स्वतंत्र ऑनलाइन ए/बी चाचण्या; फक्त नंतरच्या चेकपॉइंट तुलनेत टूल-अपयशात लक्षणीय घट झाली आहे, ज्यामध्ये MID+ असमाधानात कोणताही लक्षणीय बदल झालेला नाही. — दोन स्वतंत्र GLM-5.2 थेट A/B चाचण्या. चेकपॉइंट 1 ची तुलना स्टॉक GLM-5.2 शी केली जाते; चेकपॉइंट 2 ची तुलना चेकपॉइंट 1 शी केली जाते. या दोन चाचण्यांमध्ये, केवळ नंतरचे टूल-अपयश कमी होणे सांख्यिकीयदृष्ट्या महत्त्वपूर्ण आहे. MID+ दर मध्यम किंवा उच्च असमाधानाची सरासरी अंदाजित संभाव्यता दर्शवतात, तक्रारींची संख्या नाही.

GLM-5.3 साठी, आम्ही पोस्ट-ट्रेन्ड चेकपॉइंटची थेट स्टॉक GLM-5.3 शी तुलना केली. रेकॉर्ड केलेली स्थिती असलेल्या कॉलपैकी टूल-कॉल अपयश ३.५६% वरून २.३८% पर्यंत खाली आले, जी ३३.०४% ची सापेक्ष घट आहे. MID+ दर, मध्यम किंवा उच्च असमाधानाची सरासरी अंदाजित संभाव्यता, ४.१२% वरून ३.४१% पर्यंत खाली आली, जी १७.२% ची सापेक्ष घट आहे. दोन्ही घट सांख्यिकीयदृष्ट्या महत्त्वपूर्ण होत्या.

GLM-5.3 A/B चाचणी: टूल-अपयश दर ३.५६% वरून २.३८% पर्यंत खाली येतो आणि MID+ दर, मध्यम किंवा उच्च असमाधानाची सरासरी अंदाजित संभाव्यता, ४.१२% वरून ३.४१% पर्यंत खाली येतो. CUPED-समायोजित सापेक्ष घट अनुक्रमे ३३.०४% आणि १७.१६% आहेत. दोन्ही ९५% अनुक्रमिक अंतरांमध्ये शून्याचा समावेश नाही; प्राथमिक प्रतिबद्धता मेट्रिक महत्त्वपूर्ण नाही. — वेगळ्या ऑनलाइन A/B चाचणीमध्ये स्टॉक GLM-5.3 विरुद्ध पोस्ट-ट्रेन्ड GLM-5.3. टूल-अपयश आणि MID+ दर, सापेक्ष बदल आणि ९५% अनुक्रमिक आत्मविश्वास अंतराल CUPED समायोजन वापरतात. दोन्ही घट सांख्यिकीयदृष्ट्या महत्त्वपूर्ण आहेत. MID+ दर हे तक्रारींची संख्या नसून पात्र स्कोअर केलेल्या फॉलो-अप थ्रेड्सवरील मध्यम किंवा उच्च असमाधानाची सरासरी अंदाजित संभाव्यता दर्शवतात. टूल-अपयश दरांमध्ये रेकॉर्ड केलेली यश किंवा अपयश स्थिती नसलेले कॉल वगळले आहेत.

केंद्रीय कल्पना निर्णयाच्या पातळीवर शिकणे ही आहे, केवळ सत्राच्या पातळीवर नाही.

यशस्वी परिणाम चुका लपवू शकतो, आणि अयशस्वी सत्र सुधारणा कशी करावी हे तरीही उघड करू शकते. आम्ही यशस्वी सत्रांमधून उपयुक्त वर्तन एक अँकर म्हणून ठेवतो, टाळता येण्यासारखी अपयशे ओळखण्यासाठी तक्रारी आणि टूल त्रुटी वापरतो आणि त्या चुका आणि सुधारणा स्पष्ट केल्यावर मॉडेल ज्या अंदाज करते त्या दिशेने प्रशिक्षण देतो. यश संरक्षित करण्यासाठी वर्तन प्रदान करते; अपयश सुधारण्यासाठी दिशा प्रदान करते.

वास्तविक जगातील वापरामुळे हा दृष्टिकोन विशेषतः उपयुक्त ठरतो. वास्तविक वापरकर्ते अशी उद्दिष्टे, मर्यादा आणि वर्कफ्लो आणतात ज्यांचा कृत्रिम वातावरणात अंदाज लावणे कठीण असते. त्यांच्या सुधारणा मॉडेल चुकलेल्या आवश्यकता उघड करतात, तर टूल त्रुटी मॉडेलने काय प्रयत्न केले आणि वातावरण काय परवानगी देते यामधील दरी उघड करतात. हे संकेत परिणाम-आधारित प्रशिक्षणाला पूरक आहेत: कार्य यशस्वी झाले का एवढेच विचारण्याऐवजी, आपण हे विचारू शकतो की मॉडेल कुठे चुकला आणि कोणत्या माहितीने त्याला चांगला निर्णय घेण्यास मदत केली असती.

मर्यादा तितक्याच महत्त्वाच्या आहेत. परीक्षक चुकीचे असू शकतात आणि एक टर्न सुधारल्याची हमी पूर्ण कार्य यशस्वी होत आहे असे नाही. ध्येय केवळ असे एजंट बनवणे नाही जे सुधारणेनंतर पूर्वस्थितीत येते. तर असे एजंट बनवणे आहे ज्याला कमी वेळा सुधारण्याची गरज भासते.

BibTeX

@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}
}

कृत्रिम ते वास्तविक जगातील डेटा

चांगल्या पायऱ्यांचे अनुकरण करा, वाईट पायऱ्या सुधार करा

एक उदाहरण: एक सत्र दोन्ही धडे शिकवू शकते

प्रशिक्षण कसे कार्य करते

सत्रे निवडा, नंतर परिणामाचे मूल्यांकन करा

वापरकर्ता अभिप्रायावरून चुका शोधा

टूल त्रुटींमधून चुका शोधा

दोन फॉरवर्ड पास

लॉस फंक्शन

CE लॉस

KL लॉस

संयुक्‍त लॉस

मूल्यांकने काय दर्शवतात

हिंट्स मॉडेलला चुकांपासून दूर नेऊ शकतात

वापरकर्ता अभिप्राय

टूल त्रुटी

प्रशिक्षणानंतर टूलची विश्वासार्हता आणि वापरकर्त्याचा अभिप्राय

ऑफलाइन मूल्यांकन

ऑनलाइन मूल्यमापन: GLM-5.2

ऑनलाइन मूल्यमापन: GLM-5.3

निष्कर्ष

उद्धरण