LLM कैसे काम करते हैं

docs.scrimba.com

पहले, नाम। LLM का मतलब है बड़ा भाषा मॉडल: ChatGPT जैसे उपकरणों के पीछे की AI का प्रकार, वह चीज जिसे आप एक प्रॉम्प्ट भेजते हैं और टेक्स्ट वापस पाते हैं। यह अध्याय यह दिखाता है कि वास्तव में एक क्या है।

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

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

यह अध्याय इन प्रणालियों के तहत मानसिक मॉडल है: एक मॉडल क्या है, एक लूप जो यह चलाता है, और मुट्ठी भर गुण जो बाकी हैंडबुक को समझाते हैं। इसमें कोई गणित नहीं है। यह ब्लैक बॉक्स के विरुद्ध कोडिंग और यह जानने के बीच का अंतर है कि यह ऐसा व्यवहार क्यों करता है।

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

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

यहां कोई नया गणित नहीं है, और वह बिंदु है: टिकाऊ इंजीनियरिंग लाभ मॉडल के तंत्र में है, महीने के मॉडल में नहीं। इसे हर बाद की निर्णय का सबस्ट्रेट के रूप में पढ़ें।

एक मॉडल वास्तव में क्या है

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

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

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

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

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

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

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

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

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

एक तैनात मॉडल एक API के पीछे फ्रोजन वजन है: अरबों सीखी गई संख्याएं, प्रशिक्षण समय पर फिक्स, (वजन, इनपुट) का एक शुद्ध फंक्शन की गणना करते हुए। एकमात्र समय जब इसका व्यवहार वास्तव में बदलता है जब प्रदाता एक अलग मॉडल भेजता है।

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

वजन संपीड़ित parametric मेमोरी है, और यह हानिपूर्ण और अनुपयोगी दोनों है। आप यह diff नहीं कर सकते कि एक मॉडल संस्करण के बीच "जानता है", आप इसके तथ्यों को गणना नहीं कर सकते, और आप यह साबित नहीं कर सकते कि दिया गया तथ्य वहां है या सही है। इसलिए कभी भी एक लोड-असर करने वाले तथ्य की सत्यता को parametric recall पर न रखें। यदि एक गलत जवाब आपको खर्च करेगा, तो एक स्रोत से तथ्य प्रदान करें जिसे आप नियंत्रित कर सकते हैं और उद्धृत कर सकते हैं, और मॉडल को उस स्रोत पर फ्रेजिंग और तर्क देने की भूमिका में रखें, स्रोत नहीं।

जानबूझकर वजन बदलना वह है जो fine-tuning करता है, और यह स्पष्ट करने लायक है कि यह क्या खरीदता है। Fine-tuning विश्वसनीय रूप से व्यवहार और रूप, टोन, प्रारूप, कार्य आदतें बदलता है, लेकिन यह आपको तथ्यों का एक विश्वसनीय, क्वेरीयोग्य स्टोर नहीं देता है। इसे कैसे मॉडल प्रतिक्रिया देता है को आकार देने के लिए, ज्ञान की स्थापना के लिए नहीं। वजन में तथ्य रखें, वजन में शैली रखें, और आप या तो हैरान नहीं होंगे।

Junoएक मॉडल वास्तव में क्या है वजन फ्रोजन हैं, इसलिए व्यवहार केवल तब बदलता है जब प्रदाता एक अलग मॉडल भेजता है: संस्करण को पिन करें, इसे अपने अनुबंध का हिस्सा बनाएं, और अपग्रेड करने से पहले evals फिर से चलाएं या एक मौन स्वैप आपको सोते समय regress करेगा। Parametric मेमोरी हानिपूर्ण और अनुपयोगी है; आप यह diff नहीं कर सकते कि यह क्या जानता है, तो लोड-असर करने वाले तथ्यों को इनपुट में एक स्रोत से रखें जिसे आप नियंत्रित करते हैं, याद में नहीं। और fine-tuning व्यवहार और रूप बदलता है, विश्वसनीय तथ्य स्टोर नहीं, इसलिए इसे कैसे मॉडल प्रतिक्रिया देता है के लिए उपयोग करें, यह क्या जानना चाहिए इसके लिए नहीं।

अगले टोकन की भविष्यवाणी करना

संख्याओं का वह ढेर स्थान पर होने के साथ, मॉडल ठीक एक काम करता है: यह बार-बार अगले टेक्स्ट के हिस्से की भविष्यवाणी करता है।

यहां धीमी गति में लूप है। आप इसे कुछ टेक्स्ट देते हैं। यह उन सभी पैरामीटर के माध्यम से टेक्स्ट चलाता है और हर संभावित अगले हिस्से के लिए संभावना उत्पादन करता है जो यह जानता है, एक बार में दसियों हजार विकल्प। "फ्रांस की राजधानी है" के बाद, हिस्सा "दिल्ली" को 97% स्कोर मिल सकता है, "एक" को 1% स्कोर, और बाकी सब कुछ लगभग कुछ नहीं।

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

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

फोन कीबोर्ड जो आपके अगले शब्द का सुझाव देता है वही विचार लघु में है। अंतर भवष्यवाणी के पीछे अरबों पैरामीटर हैं। पर्याप्त पाठ पर प्रशिक्षित, "सबसे संभावित अगला हिस्सा क्या है" काम करने वाला कोड और स्पष्ट व्याख्या लिखने के लिए पर्याप्त अच्छा बदल जाता है। लेकिन अंतर्निहित कदम कभी नहीं बदलता है: यह भविष्यवाणी है, न कि समझ, और एक संग्रहीत उत्तर देख नहीं रहे हैं।

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

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

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

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

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

पीढ़ी निर्माण द्वारा अनुक्रमिक है: मॉडल एक टोकन (टेक्स्ट का एक हिस्सा) उत्पादन करता है, इसे फीड करता है, और अगले की भविष्यवाणी करता है, इसलिए प्रत्येक आउटपुट टोकन नेटवर्क के माध्यम से एक अलग फॉरवर्ड पास है। आपके इनपुट को पढ़ना अपेक्षाकृत सस्ता है, एक बार में संसाधित; धीमा, महंगा हिस्सा मॉडल लिख रहा है। लेटेंसी और लागत आउटपुट लंबाई के साथ स्केल करते हैं, इनपुट लंबाई के साथ नहीं। व्यावहारिक लीवर उससे बाहर आते हैं: आउटपुट को छोटा रखें, टोकन स्ट्रीम करें ताकि उपयोगकर्ता पूरी प्रतिक्रिया के लिए प्रगति देखे, और आप फेंक देंगे ऐसे verbose formatting के लिए भुगतान न करें।

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

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

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

यादृच्छिकता डायल

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

आप कितनी यादृच्छिकता को तापमान नामक एक सेटिंग के माध्यम से नियंत्रित करते हैं, जिसे आप calling models from code पर अध्याय में मॉडल को कॉल करते समय सेट करते हैं। अंतर्ज्ञान अभी होने के लायक है। कम तापमान पर, मॉडल अपने शीर्ष पिक के करीब रहता है: केंद्रित, सुसंगत, पूर्वानुमेय, जो आप एक चालान से संख्या खींचने या टेक्स्ट को श्रेणियों में सॉर्ट करने के लिए चाहते हैं। उच्च तापमान पर, कम संभावना वाले हिस्से अक्सर चुने जाते हैं: अधिक विविध और रचनात्मक, और कहीं गलत भटकने की अधिक संभावना। बिचार और रचनात्मक लेखन उच्च अंत चाहते हैं; कुछ भी सही उत्तर के साथ कम अंत चाहता है।

तो एक एकल डायल मॉडल को "सावधान और दोहराना" और "आश्चर्यजनक और आविष्कारशील" के बीच स्लाइड करता है। यह तापमान के दोनों तरफ समान भविष्यवाणी लूप है; तापमान केवल यह बदलता है कि मॉडल अपने सबसे सुरक्षित अनुमान से परे कितनी साहसी होकर पहुंचता है।

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

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

तापमान यहां एकमात्र नॉब नहीं है। शीर्ष-पी (केवल सबसे छोटे सेट से नमूना जिनकी संभावनाएं पी तक जोड़ी जाती हैं) और शीर्ष-के (केवल के सबसे संभावित टोकन) दोनों नमूनाकरण से पहले उम्मीदवार पूल को ट्रिम करते हैं। वे प्रभाव में तापमान से अतिव्यापी हैं, इसलिए उन्हें एक यादृच्छिकता सेटिंग के रूप में सोचने में मदद मिलती है वजाय तीन स्वतंत्र लोगों के।

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

Junoयादृच्छिकता डायल तापमान नमूना से पहले संभाव्यता वितरण को फिर से आकार देता है: कम शीर्ष टोकन की ओर तेज करता है केंद्रित आउटपुट के लिए, उच्च विविधता के लिए इसे सपाट करता है। temperature, top_p, और top_k को एक यादृच्छिकता सेटिंग के रूप में मानें, तीन नहीं। कार्य के अनुसार इसे सेट करें: निष्कर्षण, वर्गीकरण, और संरचित आउटपुट के लिए कम; विचार के लिए उच्च। उच्च तापमान को top_p के साथ 1 के साथ न रखें जब आपको पार्सेबल परिणाम की जरूरत होती है।

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

यह नमूना व्यवहार को कैसे परीक्षण करता है को आकार देता है। एक एकल रन आपको लगभग कुछ भी नहीं बताता है stochastic सिस्टम (वह जिसका आउटपुट रन से रन तक भिन्न होता है), तो कई बार चलाकर प्रॉम्प्ट का मूल्यांकन करें और आउटपुट का वितरण देखें: यह कितनी बार spec में लैंड करता है, भिन्नता कितनी चौड़ी है, पूंछ कहां गलत हो जाती है। वह काम है जो आपके evals करते हैं, और वे अंतर को देखने के लिए पर्याप्त नमूने चाहते हैं, एक भाग्यशाली पास नहीं।

तापमान, top-p (केवल सबसे छोटे सेट से नमूना जिनकी संभावनाएं cumulative p तक पहुंचते हैं) और top-k (केवल के सबसे संभावित टोकन रखें) को एक नमूनाकरण बजट के रूप में मानें जिसे आप एक साथ ट्यून करते हैं वजाय तीन दिए जिन्हें आप reflex से सेट करते हैं। सबसे कम यादृच्छिकता चुनें जो अभी भी कार्य के लिए स्वीकार्य विविधता देता है: तीनों को एक साथ कसना कुछ repetitive और brittle में आउटपुट को ढहा सकता है, जबकि सभी को खुला छोड़ना आपको विविधता सौंपता है आपको तो validate करना होगा। लागत वास्तविक दोनों तरफ है, तो इसे जानबूझकर खर्च करें।

Junoयादृच्छिकता डायल तापमान 0 near-नियतात्मक है, गारंटी नहीं: फ़्लोटिंग-पॉइंट, बैचिंग, और आंतरिक रूटिंग nondeterminism लीक करते हैं, तो सटीक-मैच कैशिंग और सटीक-मैच परीक्षा छोड़ दें। कई रन पर नमूना व्यवहार का मूल्यांकन करें और वितरण पढ़ें, एक पास नहीं; वह यह है कि आपके evals क्या हैं। temperature, top_p, और top_k को एक नमूनाकरण बजट के रूप में ट्यून करें, और सबसे कम यादृच्छिकता चुनें जो अभी भी स्वीकार्य विविधता देता है।

टोकन

एक मॉडल की भविष्य का "हिस्सा" एक नाम है: टोकन। एक टोकन टेक्स्ट का एक टुकड़ा है, अक्सर एक पूरा शब्द, कभी-कभी केवल एक का हिस्सा। आम शब्द आमतौर पर एक एकल टोकन हैं, जबकि लंबे या दुर्लभ शब्द कई में विभाजित हो जाते हैं।

"tokenization"  ->  "token" + "ization"
"unbelievable"  ->  "un" + "believ" + "able"
"cat"           ->  "cat"

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

यहां अंतर्निहित परिणाम है जो लोगों को आश्चर्य में डालता है। मॉडल कभी अक्षर नहीं देखता है। यह टोकन देखता है, जो उसके लिए वास्तव में उन हिस्सों के लिए ID नंबर हैं। तो कार्य जो हमें सहज दिखते हैं उसके लिए कठिन हो सकते हैं: एक शब्द में अक्षरों को गिनना, एक स्ट्रिंग को उलट देना, यह देखना कि "स्ट्रॉबेरी" में तीन र हैं।

यह dim नहीं हो रहा है। यह व्यक्तिगत वर्णों को बिल्कुल भी कथित नहीं करता है, जिस तरह आप तैयार रोटी में आटे के अलग-अलग अनाज का स्वाद नहीं ले सकते। जब मॉडल एक spelling या character-counting कार्य को fumbles करता है, यह क्यों है, और fix आमतौर पर सामान्य कोड में उस भाग को करना है।

टोकन भी दो चीजों की इकाई हैं जिनकी आप लगातार देखभाल करेंगे:

• पैसा: प्रदाता प्रति टोकन बिल करते हैं, आप जो भेजते हैं और मॉडल लिखता है दोनों टोकन, इसलिए एक लंबा दस्तावेज़ इनपुट और एक लंबा जवाब आउटपुट दोनों अधिक खर्च करते हैं। अंग्रेजी के लिए एक rough gauge लगभग चार अक्षर प्रति टोकन है, या हर 75 शब्दों के लिए 100 टोकन; कोड और अन्य भाषा अक्सर अधिक टोकन में विभाजित होते हैं, जो आंशिक रूप से यह है कि वे अधिक खर्च कर सकते हैं। आप सीधे इसे पूरा करेंगे जब आप calling models from code शुरू करते हैं।
• सीमाएं: मॉडल कितने टोकन को एक बार में संभाल सकता है इसकी एक सीलिंग है, जो अगला अनुभाग है।

Junoटोकन एक टोकन टेक्स्ट का एक हिस्सा है, आमतौर पर एक शब्द या एक का हिस्सा, और मॉडल उन हिस्सों को ID नंबर के रूप में पढ़ता है, अक्षर के रूप में नहीं। यही कारण है कि यह गिनती या spelling में stumble कर सकता है, इसलिए उस काम को सादे कोड के लिए सौंपें। और क्योंकि आप प्रति टोकन दोनों तरफ भुगतान करते हैं और एक बार कितने फिट करते हैं इसकी एक टोपी है, कम टोकन का मतलब कम लागत और अधिक कमरा है।

मॉडल टोकन की भविष्य दिखाता है, पाठ के टुकड़े जो अक्सर एक पूरा शब्द होते हैं और कभी-कभी एक टुकड़ा। टेक्स्ट को विभाजित करने वाला टुकड़ा tokenizer है, और यह एक सीखी हुई शब्दावली से काम करता है एक सीखी हुई शब्दावली से निर्मित है जो बार-बार सबसे सामान्य अक्षर जोड़े को मर्ज करके एक निश्चित कुछ दस हजार टुकड़े तक (एक योजना आमतौर पर byte-pair encoding, या BPE कहा जाता है)। यह इतिहास है कि आम शब्द एकल टोकन के रूप में क्यों समाप्त होते हैं जबकि दुर्लभ भाग में विभाजित होते हैं: सामान्य पैटर्न प्रशिक्षण के दौरान मर्ज हो गए, असामान्य कभी नहीं।

इस से दो व्यावहारिक तथ्य बाहर आते हैं। पहला, मॉडल कभी भी characters को संभालता नहीं है, केवल टोकन IDs, तो किसी भी character-level ऑपरेशन (अक्षरों को गिनना, एक स्ट्रिंग को उलट देना, एक सटीक स्थान पर स्लाइस करना) एक प्रॉम्प्ट के अंदर कमजोर है और आपके अपने कोड में विश्वसनीय है। वह काम को कोड के लिए पुश करें और मॉडल को भाषा भाग करने दें। दूसरा, tokenization model-specific है, इसलिए टोकन counts portable नहीं हैं। एक ही वाक्य एक अलग tokenizer पर टोकन की एक अलग संख्या खर्च कर सकता है, जो तुरंत मायने रखता है जब आप लागत बजट करते हैं या विंडो में सामग्री फिट करते हैं।

निर्माण के लिए takeaway: character length से token counts को eyeball न करें। मॉडल के actual tokenizer के साथ गिनती करें, क्योंकि वह संख्या है जिस पर आप बिल किए जाते हैं और सीमित होते हैं। आप इस सभी को ठोस रूप से पूरा करते हैं जब आप calling models from code शुरू करते हैं, जहां आप भेजते हैं वह गणना साथ आता है वह पिछले गणना आपका bill है।

Junoटोकन एक tokenizer एक सीखी हुई शब्दावली (BPE) का उपयोग करके टेक्स्ट को विभाजित करता है, जो यह है कि आम शब्द एक टोकन और दुर्लभ वाले टुकड़े में क्यों हैं। Tokenization model-specific है, इसलिए वर्णों से guessing के बजाय model के अपने tokenizer के साथ count करें। और character-level काम (counting, reversing, exact slicing) को अपने कोड में रखें, prompt में नहीं।

टोकन आपके द्वारा भेजने वाली हर चीज पर मीटर हैं। एक टोकन tokenizer की सीखी हुई शब्दावली से एक टेक्स्ट टुकड़ा है, और per-token बिल साथ fixed context ceiling दोनों संख्याएं हैं जो आपकी लागत और डिज़ाइन को आकार देते हैं। आरामदायक चार-characters-per-token rule of thumb plain अंग्रेजी prose में रखता है और ठीक वहीं falls apart जहां production रहता है: कोड, JSON, deeply nested formatting, और non-Latin scripts सभी हिसाब से कहीं अधिक टोकन में fragment करते हैं। तो real tokenizer के साथ budget करें, gauge नहीं, या आपकी लागत और क्षमता अनुमानें गलत होंगी जहां आप actually payloads भेजते हैं।

fragmentation समान रूप से distributed नहीं है, और यह बड़े पैमाने पर fairness और लागत समस्या है। एक non-Latin भाषा में समान अर्थ इसके अंग्रेजी version के tokens के कई गुना अधिक खर्च कर सकता है, तो यह ही feature quietly अधिक महंगा है, और कुछ users के लिए आपके slower है। upgrade करने से पहले प्रति भाषा measure करने के लायक है किसी को flat price या fixed latency promise।

Field से दो अधिक आदतें। Format spend है: whitespace, verbose delimiters, और decorative markdown सभी टोकन खर्च करते हैं zero added meaning के लिए, तो स्ट्रक्चर को compact रखें कि आप मॉडल को भोजन करते हैं और आपका कोड presentation को बाद में जोड़ता है। और clean, normal text भोजन करें, क्योंकि rare या malformed टोकन (mojibake, stray control characters, odd encodings) vocabulary के thin, undertrained corners में बैठते हैं और अजीब आउटपुट को ट्रिगर कर सकते हैं। कोई भी यह exotic नहीं है; यह एक token budget के बीच अंतर है जिसे आप विश्वास करते हैं और वह जो आपको आश्चर्य करता है आपके invoice में।

Junoटोकन चार-chars-per-token rule कोड, JSON, और non-Latin scripts पर breaks, जो यह है जहां आपका real traffic रहता है, तो actual tokenizer के साथ budget करें। Non-Latin languages कई गुना अधिक tokens के लिए same meaning खर्च कर सकता है, एक real cost और fairness gap worth measuring per language। decorative formatting को strip करें tokens save करने के लिए, और clean text भोजन करें तो rare या malformed tokens आपको अजीब behaviour न खरीदें।

संदर्भ विंडो

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

सभी शुरुआत में एक सीमा क्यों है? यह भविष्य से कैसे काम करता है। अगले टोकन को चुनने के लिए, मॉडल यह वजन करता है कि इनपुट में हर टोकन हर दूसरे टोकन से कैसे संबंधित है, तो यह बता सकता है कि "यह" तीन वाक्य पहले बिल्ली को संदर्भित करता है। यह सभी-से-सभी तुलना वह है जो मॉडल को एक पारित भर में अर्थ को track करने देता है, और यह वह भी है जो लंबे इनपुट को प्रक्रिया करने के लिए महंगा बनाता है। प्रदाता एक ceiling, संदर्भ विंडो को सेट करता है, प्रत्येक अनुरोध को manageable रखने के लिए।

जब डेस्क भरा है, कुछ को बाहर आना होगा। यदि एक बातचीत लंबे समय तक चलती है विंडो को overflow करने के लिए, सबसे पहली parts दूर हो जाती हैं और मॉडल उन्हें अब नहीं देख सकता। यही कारण है कि एक लंबी चैट शुरुआत में आप ने जो कहा यह "forget" करती है। यह मानव sense में forgot नहीं किया; वे tokens डेस्क से बाहर हैं। यह भी मदद करने के लिए जानने के लिए कि मॉडल आमतौर पर डेस्क पर क्या है की शुरुआत और अंत में closest ध्यान देते हैं और बीच में दफन चीजों का track खो सकते हैं, तो जहां आप महत्वपूर्ण टेक्स्ट रखते हैं तब मायने रखता है जब आप विंडो को भरते हैं।

अब बिंदु जो लगभग हर शुरुआती को catches, और यह बाकी सभी से अधिक मायने रखता है। मॉडल के पास अलग अनुरोधों के बीच कोई memory नहीं है। याद रखें कि इसकी संख्याएं frozen हैं। प्रत्येक कॉल एक खाली डेस्क के साथ शुरू होता है। मॉडल आपके आखिरी सवाल, आपके नाम, या एक मिनट पहले कुछ भी नहीं याद रखता है।

एक चैट ऐप एक flowing conversation की तरह केवल महसूस करता है क्योंकि ऐप quietly हर नए संदेश के साथ पूरा history को resend करता है। continuity कुछ है सॉफ्टवेयर मॉडल के चारों ओर builds, मॉडल ही नहीं।

वह एक बिंदु आकार देता है कि आप यहां से कैसे सब कुछ build करते हैं। यदि आप चाहते हैं मॉडल कुछ जानने के लिए, आपको उस request में डेस्क पर रखना होगा: अब तक की बातचीत, users विवरण, प्रासंगिक documents, यह सब, हर बार। इस handbook का एक बड़ा हिस्सा वास्तव में वह एक चीज अच्छी तरह करने के बारे में है, right टेक्स्ट को डेस्क पर प्राप्त करना।

Junoसंदर्भ विंडो संदर्भ विंडो मॉडल का डेस्क है: हर request इसमें फिट होना होगा, और जब यह overflow करता है तो oldest टेक्स्ट बाहर आती है। मॉडल calls के बीच कोई memory नहीं रखता है, तो ऐप hacks करने के लिए continuous chat fake करने के लिए हर बार पूरे history को resend करता है। आपका काम यहां से है right टेक्स्ट को उस डेस्क पर हर एकल request में प्राप्त करना है।

संदर्भ विंडो को tokens के एक fixed budget के रूप में सोचें कि एक request spend करता है, आपके निर्देशों, running conversation, पेस्ट किए गए documents, और answer generation को कवर करता है। विंडो attention नामक एक mechanism के कारण मौजूद है जो प्रत्येक टोकन को हर दूसरे टोकन के साथ compare करता है यह काम करने के लिए कि क्या से संबंधित है। यह तुलना वह है जो मॉडल को "यह" वापस noun में resolve करने देता है जो इसे points करता है, और इसकी लागत input length के साथ roughly के square के साथ grows करती है। tokens को double करें और आप काम के साथ से अधिक double। जो यह है कि लंबे इनपुट slow और cost को चलाते हैं।

विंडो में फिट करना मॉडल का use का समान नहीं है इसमें सब कुछ। एक well-documented effect है called lost in the middle: मॉडल शुरुआत और अंत के लिए reliably attend करते हैं और पेस्ट किए गए टेक्स्ट की दीवार में parked material को skim कर सकते हैं। तो अपने most महत्वपूर्ण निर्देशों और data को prompt के शीर्ष या नीचे के near रखें, बीच में दफन नहीं।

इसका दूसरा आधा memory है, और key fact है मॉडल है stateless: यह अलग requests के बीच कुछ भी नहीं याद रखता है। प्रत्येक कॉल एक empty window के साथ शुरू होता है, तो मॉडल को अब तक की बातचीत के बारे में एकमात्र तरीका यह है कि आप हर बार फिर से भेजते हैं। Resending और shaping वह history आपका काम है, मॉडल का नहीं। जैसे-जैसे चैट window से past बढ़ता है, अपने आप को manage करें old turns को trim करके या उन्हें एक short summary के साथ replace करके, तो tokens आप keep करते हैं वह हैं जो अभी भी मायने रखते हैं।

यह context construction को इन models के साथ build करने के center में रखता है। क्या window में जाता है यह decide करना, किस क्रम में, और कैसे compress करना है जो पहले आया वह है most काम, और prompting है जहां आप deliberately इसे shape करना सीखते हैं।

Junoसंदर्भ विंडो विंडो एक token budget है covering instructions, history, documents, और reply; attention लंबे इनपुट को उनकी लंबाई के square के साथ roughly लागत करता है। मॉडल lost-in-the-middle effect से पीड़ित होते हैं, तो अपने महत्वपूर्ण को start या end के near रखें। मॉडल stateless है, तो resending और trimming conversation history आप पर है, हर कॉल।

संदर्भ विंडो को एक ceiling के रूप में मानें, लक्ष्य नहीं। यह token budget है एक single request gets, spanning आपके निर्देश, running history, retrieved documents, और output।

हर टोकन जिसे आप इसमें put करते हैं money और latency लागत करता है, क्योंकि attention कदम (all-to-all टोकन compare जो मॉडल input को read करने के लिए चलाता है) लंबाई के साथ roughly square के साथ scales करता है। बदतर, effective recall well से पहले degrade होती है आप limit तक reach करते हैं: lost in the middle effect मतलब है कि center में buried material पर accuracy drops off भी जब यह technically fits। तो सब कुछ dump करने के बजाय context को curate करें, और जब source data large है, केवल relevant pieces को retrieve करें RAG के साथ बजाय पूरे corpus को paste करने के।

Order एक lever है, विस्तार नहीं। प्रदाता prompt caching के माध्यम से unchanged prefix के लिए compute को reuse कर सकते हैं, जहां cached internal state है KV cache, model की stored work जिसे यह tokens के लिए पहले से read किया। stable content पहले रखें (system instructions, fixed reference material) और variable content last, और repeated calls cheaper और faster बन जाते हैं क्योंकि prompt का front cache से served है। उस prefix को carelessly reorder करें और आप cache को invalidate करते हैं और full price फिर से pay करते हैं।

Turns के across memory एक feature नहीं है जो मॉडल है; यह एक इंजीनियरिंग choice है आप बनाते हैं, और प्रत्येक option अपने ही तरीके से fails:

• Plain windowing, most recent turns रखना, cheap है लेकिन silently drops early facts users अभी भी expect करते हैं आप को know करने के लिए।
• Summarisation अधिक history को fewer tokens में रखता है लेकिन detail को lose करता है और silently अपने errors को encode कर सकता है।
• Retrieval pulls back केवल relevant है लेकिन entirely depends करता है आपके index पर right pieces returning के।

Per use case चुनें, और assume जो भी आप choose करते हैं eventually wrong thing को surface करेगा; उसके बजाय इसके लिए instrument करें उस पर trusting से।

Junoसंदर्भ विंडो विंडो एक ceiling है, लक्ष्य नहीं: cost और latency हर token के साथ climb करते हैं और recall आप limit hit करने से पहले rot करते हैं, तो curate करें और retrieval पर large के लिए lean करें। Stable content पहले, variable last, तो prompt caching (KV cache) actually pays off। Cross-turn memory आपकी design choice है windowing, summarisation, और retrieval के बीच, और मैं सभी तीन से caught out हूँ, तो आप जो pick करते हैं उसे instrument करें।

मॉडल क्या नहीं जानता है

सभी मॉडल के ज्ञान को bake किया गया जबकि यह प्रशिक्षण दे रहा था, तो यह केवल जानता है जो उस प्रशिक्षण data में था, और वह data को gather किया गया था some cutoff point में past। दो सीमाएं सीधे इससे बाहर आती हैं।

पहला, यह कुछ नहीं जानता जो उसके cutoff के बाद हुआ। पूछो last week की news या library के बारे में जो this month बाहर आई और इसके पास कोई real idea नहीं है, हालांकि यह happily एक plausible-sounding answer produce कर सकता है। दूसरा, यह कभी कुछ private नहीं जानता। आपकी company की internal docs, एक user की order history, आपके database की contents: कोई भी यह उसके trained public text में नहीं था, तो यह नहीं जान सकता, no matter कितने nicely आप ask करते हैं।

एक quieter सीमा भी है। मॉडल आपको आमतौर पर नहीं बता सकते कि कहां से कुछ "जानता है" आता है, क्योंकि ज्ञान अंदर blend किया जाता है बजाय अलग, sourced तथ्यों के रूप में filed किए जाने के। यह आपको एक citation लिख सकता है, लेकिन यह एक real को look up नहीं करते हुए citation देख रहा है।

यह एक technique के लिए कारण है जिसे आप बाद में मिलेंगे retrieval कहा जाता है, या RAG। यदि आप चाहते हैं एक मॉडल recent events के बारे में या आपने अपने private data के बारे में answer करने के लिए, आप इसे retrain नहीं करते। आप relevant text को खुद fetch करते हैं और request time पर डेस्क पर सेट करते हैं, तो मॉडल के पास guessing के बजाय सामने तथ्य हैं। एक मॉडल आपको देते हैं बहुत अधिक होता है एक reasoner over text से specific तथ्यों के एक reliable well की तुलना में।

Junoमॉडल क्या नहीं जानता है एक मॉडल केवल जानता है जो अपने प्रशिक्षण data में था, एक cutoff तक past, तो इसे मिस करता है recent events और कुछ भी private, और यह reliably नहीं कह सकते कहां इसके तथ्य आते हैं। जब आपको current या private information की जरूरत है, retrain न करें: relevant text को fetch करें और request में इसे हाथ दें। मॉडल को कुछ reasoner के रूप में मानें जिसे आप देते हैं, विश्वसनीय memory के रूप में नहीं।

एक मॉडल का built-in ज्ञान, इसका parametric knowledge (तथ्य encoded वजन में, tunable संख्याएं set प्रशिक्षण के दौरान), frozen है training cutoff पर। कुछ भी नहीं जो cutoff के बाद हुआ यह में है, और कुछ भी private कभी नहीं था, क्योंकि weights shaped public text के द्वारा थे। तो memory आपको देते हैं दो predictable gaps: recency, cutoff के बाद कुछ भी, और privacy, कुछ भी जो कभी public training data में नहीं था।

वह दो gaps वास्तव में एक gap हैं दो पक्षों से देखें, और यह same तरीके से close करते हैं: put needed text request में। आप recent article या relevant database row को खुद fetch करते हैं और supply करते हैं question के साथ, तो मॉडल frozen training से recalls करने के बजाय तथ्य को पढ़ता है। यह core idea है RAG, retrieval-augmented generation के पीछे, जो आप use करेंगे जब भी answers must reflect current या proprietary information।

Parametric ज्ञान भी कोई source attached नहीं carry करता है। तथ्य weights के across blended हैं, अलग entries के रूप में stored नहीं एक record के साथ, तो मॉडल नहीं कर सकता reliably आपको बताएं कहां कुछ आता है। एक citation यह produce करता है generated है look right करने के लिए, एक record से retrieved नहीं, जो exactly है क्यों grounding answer text में आप provide करते हैं worth is करने की प्रयास।

Building के लिए व्यावहारिक rule: मत करो ask मॉडल को recall current या proprietary तथ्यों को memory से। यदि एक तथ्य सही होना होगा, fetch और supply करें, और मॉडल को reason दें इसके ऊपर।

Junoमॉडल क्या नहीं जानता है Parametric ज्ञान, ज्ञान weights में held, frozen है training cutoff और carries कोई source, तो मॉडल misses recent और private information और नहीं कर सकता reliably cite कुछ भी। दोनों gaps same बंद करते हैं तरीके: relevant text को fetch करें और request में डालें, जो RAG के पीछे idea है। Rule के रूप में, मत करो मॉडल को recall current या proprietary तथ्य memory से; supply उन्हें और इसे reason दें।

मॉडल का parametric memory, knowledge held weights में (tunable संख्याएं fixed प्रशिक्षण के दौरान), unversioned और unauditable है। आप नहीं कर सकते इसे diff करते हैं, claim कहां रहता है point करो, या confirm कर सकते हैं यह नहीं drifted। तो कुछ के लिए जो सही होना होगा, current, या compliant, मत करो मॉडल trust के say-so: answer को retrieved source में ground करें और उस source को cite करें। built-in ज्ञान को fluent prior के रूप में मानें, एक system of record नहीं।

Cutoff भी fuzzier है एक single date से अधिक suggests। Training data uniform नहीं है right तक उस date: recent material thinner है और less digested than older, well-covered material से, तो recent-but-pre-cutoff तथ्यों को unevenly जानते हैं। एक मॉडल confident और wrong हो सकता है कुछ के बारे में एक साल अपने cutoff पहले जबकि nailing एक decade-old तथ्य, जो यह है क्यों "is it pre-cutoff?" एक weaker guarantee है than यह लगता है, और क्यों आप retrieve कुछ भी जो सही होना होगा।

Reach gaps के लिए right tool के लिए, क्योंकि दो common ones interchangeable नहीं हैं। Retrieval तथ्य supply करता है request time पर और stays current आपके sources update के रूप में। Fine-tuning, continuing training पर आपने अपनी examples, shifts form और behaviour, tone, format, कैसे मॉडल अपने conventions को follow करता है, और यह एक poor, stale तरीका है knowledge को inject: trained तथ्य frozen फिर से हैं, hard update करने के लिए, और अभी भी unsourced। Retrieval को use करें क्या सच है के लिए, fine-tuning को कैसे sound करना चाहिए के लिए।

Junoमॉडल क्या नहीं जानता है Parametric memory unversioned और unauditable है, तो कुछ के लिए जो सही होना होगा, current, या compliant, answer को retrieved source में ground करें और cite करें, मॉडल का word नहीं। याद रखें cutoff fuzzy है: recent-but-pre-cutoff तथ्यों को unevenly जानते हैं, तो retrieve कुछ भी जो सही होना होगा। और tool को gap से match करें: retrieval तथ्य supply करता है, जबकि fine-tuning shifts form और behaviour और knowledge को inject करने का stale तरीका है।

मॉडल चीजें क्यों बनाते हैं

कभी-कभी एक मॉडल कुछ false state करता है कुल आत्मविश्वास के साथ: एक quote कोई नहीं कहा, एक function जो मौजूद नहीं है, एक citation एक study को जो कभी नहीं लिखा गया। यह hallucination कहा जाता है, और last few sections के बाद यह feel करना चाहिए लगभग inevitable रहस्यमय के बजाय।

कारण है मॉडल के पास "सच" vs "गलत" की कोई internal sense नहीं है। यह केवल है "likely text" vs "unlikely text"। अधिकांश समय वह line up, क्योंकि text में यह trained, true statements far हैं अधिक common false वाले से, तो probable continuation आमतौर पर सही है।

लेकिन जब मॉडल gap hits, कुछ यह कभी trained नहीं था, या आपकी private data यह कभी नहीं देख सकता, यह नहीं stop और flag gap। यह reliably नहीं बता सकता जो यह नहीं जानता। यह करता है केवल चीज यह कभी करता है: produce most probable-sounding continuation।

एक confident, well-formed, wrong उत्तर अक्सर ठीक है क्या sounds most probable है। यही machinery जो इसे fluent बनाता है इसे fluent बनाता है जब यह गलत है।

यह हिस्सा है sit करने के लिए: hallucination एक glitch नहीं है आप पूरी तरह prompt दूर कर सकते हैं। आप reduce कर सकते हैं, और बाद के chapters show करते हैं कैसे। मॉडल को बताना इसके allowed है say "I do not know" एक little मदद करता है। asking जब इसे answer करना केवल text से आप provide करते हैं मदद करता है much अधिक, क्योंकि अब कोई gap नहीं है fill करने के लिए frozen training से। लेकिन tendency आता है कहां से मॉडल fundamentally है, एक probability machine कोई fact-checker के साथ अंदर नहीं, तो durable fixes structural हैं: इसे तथ्य दें work करने के लिए बजाय hoping वह trained में थे, और answers को verify करें जो matter बजाय trusting उन्हें।

Carry out एक rule अन्य सभी के ऊपर यह chapter से: एक मॉडल की confidence आपको बताता है कुछ भी नहीं क्या यह सही है। Fluency और correctness produced हैं same process से और come apart सभी समय। Build जैसे कोई भी single answer गलत हो सकता है, क्योंकि कोई भी single answer हो सकता है।

Junoमॉडल चीजें क्यों बनाते हैं एक hallucination मॉडल है confidently filling gap के साथ text जो सही दिखता है लेकिन नहीं है, क्योंकि यह केवल जानता है "likely" और नहीं "सच"। आप कैसे अक्सर lower कर सकते हैं यह happens, लेकिन आप पूरी तरह prompt दूर नहीं कर सकते, तो safe कदम है hand मॉडल को तथ्य यह needs और check answers जो matter। और याद रखें big एक: confident tone proof नहीं है, तो कभी never trust certainty अपने आप से।

जब एक मॉडल invents एक quote, एक function, या एक citation और states यह कुल के साथ confidence, वह एक hallucination है, और यह falls सीधे कैसे से मॉडल काम करता है। मॉडल के पास कोई signal नहीं है truth के लिए। यह scores continuations "likely text" से vs "unlikely text", और अधिकांश समय likely और true overlap क्योंकि true statements dominated training data इसके।

Hallucination spikes ठीक जहां overlap breaks down: किनारों पर इसके knowledge के, rare या niche topics पर, और आपके private data पर यह कभी नहीं था trained पर। वहां मॉडल अभी भी produce करता है इसके most probable continuation, और एक fluent, well-formed, wrong उत्तर अक्सर है क्या scores highest।

तो आप fix नहीं कर सकते यह wording के साथ alone, लेकिन आप rank कर सकते हैं आपके mitigations कितने से वह actually मदद करते हैं। सबसे बड़ा lever by far है grounding: put real तथ्यों prompt में और tell मॉडल को answer केवल से वह supplied text, ideally quoting यह। अब नहीं कोई gap frozen training से fill करने के लिए। retrieving right text को supply करने के लिए अपने ही technique है, covered RAG में।

नीचे यह से, दे मॉडल को एक explicit escape hatch, permission answer "I do not know" के बजाय guessing, जो removes कुछ pressure invent करने के लिए। और keep temperature (randomness dial on token selection) modest factual work के लिए, चूंकि high randomness widens door unlikely, off-base continuations के लिए।

व्यावहारिक परिणाम: constrain मॉडल को context को आप provide, और verify outputs जो matter। Treat करो prompt phrasing एक small adjustment के रूप में structural moves के top पर, कभी नहीं पूरे defense के रूप में। एक मॉडल जो sounds certain has आपको बताया है कुछ भी नहीं क्या यह सही है, क्योंकि fluency और correctness आते हैं same process से और routinely diverge।

Junoमॉडल चीजें क्यों बनाते हैं Hallucination मॉडल है emitting fluent, likely text with कोई internal check truth के लिए, और यह worse हो जाता है किनारों पर इसके knowledge के और data पर यह कभी नहीं देखा। Rank आपके fixes impact से: ground इसे text में आप supply करो (biggest lever), दे इसे room say "I don't know", tell इसे answer केवल from provided context और quote यह, और keep temperature modest factual work के लिए। Constrain context को और verify outputs जो matter; do नहीं lean wording tricks अकेले पर।

Hallucination मॉडल है returning confident, well-formed text जो happens to be false, और यह एक architecture की property है, bug नहीं आप patch। मॉडल ranks continuations by likelihood with कोई attached truth signal, तो training के किनारों पर, rare topics, fresh events, कुछ भी private, यह अभी भी emits इसके most probable guess। आप एक को eliminate नहीं करेंगे। Job है system design करना तो एक wrong answer caught या contained है पहले यह reach करता है कुछ जो matters।

वह means तीन structural moves, कोई भी नहीं उन्हें prompt wording। Validate हर answer का shape: make मॉडल को return data एक schema के विरुद्ध तो malformed या out-of-range output loudly fail करता है downstream flowing के बजाय, जो structured output आपको खरीदता है। Measure करो आपके actual hallucination rate evals के साथ, एक held-out input set known-good answers के साथ automatically scored, बजाय spot-checking कुछ prompts और calling it fine। और keep एक human in the loop जहीं भी cost गलत होना है high, क्योंकि कोई automated guard catches everything।

Trap अंदर सभी यह calibration है। Model confidence poorly calibrated है: stated certainty evidence नहीं है correctness का, और tone एक answer carry नहीं करता कोई information इसके truth value के बारे में। तो कभी never gate decision model सुनने के ऊपर sure।

Build और prefer एक abstain path, एक sanctioned "I cannot answer यह from क्या मुझे दिया था", और make abstaining cheap तो system reach करता है यह के लिए instead inventing का। वह structural mindset, assume कोई भी single answer गलत हो सकता है और contain damage, है क्या पूरे safety और limits chapter built पर।

Junoमॉडल चीजें क्यों बनाते हैं आप delete नहीं कर सकते hallucination, तो engineer containment के लिए: validate structure schemas के साथ, measure rate evals के साथ अपने spot-checking एक few outputs के बजाय, और keep एक human जहीं भी गलत होना expensive है। Model confidence badly calibrated है, तो sure tone नहीं है evidence और आप कभी never gate यह पर। दे system को एक cheap, sanctioned तरीका abstain के लिए, और prefer यह एक confident guess से हर समय।

इसे एक साथ रखना

इस chapter में सब कुछ एक idea एक विचार अलग angles से। एक मॉडल एक frozen ढेर है numbers जो token का अगला predict, और लगभग हर behaviour आप deal करेंगे falls एक से:

• यह predict एक token at एक समय probability की ranking से, तो यह improvises बजाय recalls, और randomness (temperature) का touch मतलब answers vary।
• Tokens chunks हैं यह काम करता है: आपके bill की unit, आपके size limit की unit, और कारण यह नहीं कर सकता reliably letters count करना।
• Context window एक single request का desk है, shared हर चीज से, और मॉडल requests के बीच कुछ भी नहीं याद रखता, तो continuity आपका काम है।
• Its knowledge है frozen एक training cutoff पर और कभी नहीं included आपकी private data, जो यह है क्यों आप fetch तथ्य और put उन्हें prompt में।
• Hallucination price है एक system का जो predict करता है likely text no sense के साथ truth का, reduced by grounding और checking, कभी नहीं clever wording अकेले से।

Hold ये together और surprising amount की AI engineering turns out एक task है different costumes में: get right text onto desk, एक right shape में, एक right moment पर, और कभी नहीं trust output blindly। अगला chapter, Open और closed models, looks कि क्या kinds models हैं और आप एक कैसे get, और फिर prompting है जहां आप शुरू करते हैं steering सभी यह prediction कि आप actually चाहते हैं।

Junoइसे एक साथ रखना लगभग सब कुछ एक model के बारे में follows एक fact से: यह frozen set है numbers जो token का अगला predict। उस से come varied answers, token-based cost और limits, requests के बीच memory नहीं, training cutoff, और hallucination। ये models के साथ बहुत building है right text को desk पर प्राप्त करना और output blindly कभी नहीं trust करना।

एक fact generates पूरे chapter: एक मॉडल एक frozen function है जो token का अगला predict एक probability distribution से। Trace consequences और आप अपने working model है:

• Prediction plus sampling मतलब output varies; temperature सेट कितना।
• Tokens unit हैं cost का, unit limit का, और क्यों character-level tasks belong code में।
• Context window finite है और stateless, तो आप resend और curate हर चीज मॉडल needs।
• Knowledge frozen है cutoff पर और unsourced, तो current और private तथ्य आते हैं retrieval से, recall नहीं।
• Hallucination structural है, reduced grounding और verification से, wording नहीं से।

Pattern सभी यह में same है: get right text context में, right shape में, right time पर, और verify क्या back आता है। वह है क्या rest handbook builds, starting open और closed models landscape के साथ और फिर prompting।

Junoइसे एक साथ रखना पूरे chapter एक fact और इसके fallout है: एक frozen next-token predictor आपको varied output, token-based cost और limits, statelessness, knowledge cutoff, और hallucination देता है। Job जो follows constant है: get right text context में right shape में, फिर verify क्या back आता है। Prompting है जहां आप शुरू करते हैं यह करना।

सब कुछ यहां एक sentence तक reduces: एक frozen function predict next token over text आप provide, no state के साथ, no truth signal, और no plan। हर production property आप manage एक corollary है:

• Output stochastic है, तो आप test distributions, single runs नहीं।
• Cost और latency track tokens, especially output, तो आप budget और stream।
• Context finite है और stateless, तो memory एक engineering choice है failure modes के साथ।
• Parametric knowledge frozen है, lossy, और unsourced, तो कुछ भी load-bearing gets grounded और cited।
• Confidence uncalibrated है, तो आप verify रहे trust करने के बजाय।

Payoff है यह नहीं move जब model करता है। Pin एक version, build harness model failure modes के चारों ओर, और next release एक upgrade है आप evaluate, कोई surprise नहीं आप absorb। Rest handbook है वह harness, और यह शुरू होता है landscape के साथ, open और closed models, फिर prompting।

Junoइसे एक साथ रखना एक sentence runs chapter: एक frozen, stateless next-token predictor no truth signal के साथ। Stochastic output, token-driven cost, finite context, frozen knowledge, और uncalibrated confidence सभी corollaries हैं, और आपका harness exists हर एक को contain करने के लिए। Upside है यह नहीं move जब model करता है, तो pin एक version और build failure modes के चारों ओर।