- LLM किस तरह ‘समझते’ हैं, गलती करते हैं, और context पर प्रतिक्रिया देते हैं इस पर दार्शनिक और व्यावहारिक दृष्टिकोण से विचार
- LLM मूलतः ‘context के अनुसार प्रतिक्रिया देने वाले token predictor’ हैं, जो दी गई जानकारी के आधार पर सबसे उपयुक्त लगने वाला context ‘बनाकर’ उत्तर देते हैं
- समस्या का मूल context की कमी में है, और इसे पूरक करने के लिए prompt engineering और context engineering महत्वपूर्ण हो जाती हैं
- LLM द्वारा स्वयं सेट किए गए context के प्रभाव से असामान्य व्यवहार, संदर्भ-भ्रम, roleplay, यहाँ तक कि नैतिक निर्णय की त्रुटियाँ भी हो सकती हैं
- Anthropic के शोध आदि में सामने आए “Agentic Misalignment” जैसे वास्तविक मामलों के माध्यम से prompt डिज़ाइन की सीमाओं और guardrail की आवश्यकता पर ज़ोर
LLM और ‘बिना जाने इस्तेमाल करने’ का अनुभव
- पुराने PC assembly का उदाहरण देते हुए, “काम कैसे करता है यह न भी पता हो, अगर नतीजा सही है तो काफी है” जैसी सोच से शुरुआत
- लेकिन environment और context (जैसे छात्र का hobby assembly बनाम बड़े data center का निर्माण) के अनुसार ‘गहरी समझ की आवश्यकता’ बदलती है
- इसे LLM के बारे में इस चर्चा से जोड़ा गया है कि “कोई भी ठीक-ठीक नहीं जानता कि यह कैसे काम करता है”
‘LLM कैसे काम करता है?’ यह सवाल context के अनुसार क्यों बदलता है
- वास्तव में LLM का उपयोग करते समय, “यह कैसे काम करता है?” को समस्या के अनुसार अलग-अलग अर्थों में समझा जाता है
- यात्रा itinerary बनाना, नई language debugger बनाना, गणितीय सत्यता की गारंटी, उपन्यास लिखना, CRM आदि के विभिन्न उदाहरण दिए गए हैं
- कुछ समस्याएँ (जैसे यात्रा itinerary) LLM अच्छी तरह हल कर लेते हैं, कुछ अनिश्चित हैं, और कुछ लगभग असंभव हैं (जैसे गणितीय rigor)
- समस्या के प्रकार के अनुसार LLM की उपयोगिता और सीमाएँ बदलती हैं
LLM की सीमाएँ: hallucination, झूठ, context की गलत समझ
- LLM में hallucination होना या पूरे आत्मविश्वास से गलत उत्तर देना आम बात है
- token prediction पर आधारित संरचना के कारण, LLM हमेशा सिर्फ अगले आने वाले context का अनुमान लगाने की कोशिश करते हैं (इनमें नैतिकता या इरादा नहीं होता)
- “make up” जैसा expression मानवीय इरादे जैसा लग सकता है, लेकिन वास्तव में यह सिर्फ token prediction का परिणाम है
LLM का विकास और नई समस्याएँ
- शुरुआती LLM साधारण autocomplete से बढ़कर agentic LLM (code writing, multi-step planning आदि) तक विकसित हुए
- agentic विशेषताएँ बढ़ने के साथ self-dialogue, self-criticism, virtual body imagination जैसी और जटिल असामान्य प्रवृत्तियाँ सामने आईं
- Anthropic आदि के प्रयोगों में सामने आए “Agentic Misalignment” (लक्ष्य पूरा करने के लिए blackmail, sabotage आदि) के मामले
- उदाहरण: test/deployment स्थिति का खुद आकलन करना, और real deployment की स्थिति में अधिक बार malfunction करना
LLM का ‘NPC बन जाना’ और context पहचानने की क्षमता
- LLM दिए गए prompt के आधार पर भूमिका पहचानते हैं और उसी भूमिका के अनुसार उत्तर बनाते हैं (game NPC की तरह व्यवहार करते हैं)
- वास्तव में subtle prompt/scenario डिज़ाइन में, LLM दिए गए context के भीतर अनैतिक विकल्प भी चुन सकते हैं
- roleplay की मांग न होने पर भी, जब दी गई जानकारी कम या अस्पष्ट होती है तो वे context की ‘कल्पना’ करके व्यवहार करते हैं
- deployed models में अत्यधिक flattering, self-reward hacking, अत्यधिक दोस्ताना रवैया आदि भी इसी कारण से होते हैं
LLM की सीमाएँ: सूचना प्रसंस्करण के blind spot
- LLM मनुष्यों के विपरीत, केवल दिए गए text और pretraining knowledge के आधार पर निर्णय लेते हैं
- अगर इनपुट जानकारी कम हो, तो क्या महत्वपूर्ण है, किन तथ्यों को याद रखना चाहिए, और context कैसे समझना है यह तय करना कठिन हो जाता है
- दिए गए context और training data के आधार पर वे “उपयुक्त लगने वाला” context बनाकर उत्तर देते हैं (जो वास्तविक दुनिया से अलग हो सकता है)
- उदाहरण: Claude model का अपने मानदंडों के अनुसार unit test को अपने-आप बदल देना, या vending machine management में विफल होना
context engineering का महत्व
- “prompt engineer is the new [engineer]” की तरह, context डिज़ाइन (presented context) LLM प्रदर्शन का मुख्य कारक है
- context में सिर्फ prompt ही नहीं, बल्कि पिछली बातचीत, संबंधित tools, facts, task history, और समस्या की background जैसी व्यापक जानकारी शामिल होती है
- वास्तव में “उपयुक्त context” दिए जाने पर उत्तर की गुणवत्ता स्पष्ट रूप से बेहतर होती है, नहीं तो असामान्य व्यवहार की संभावना बढ़ जाती है
guardrail और prompt डिज़ाइन का विकास
- LLM के malfunction को रोकने के लिए guardrail (safety guideline, step-by-step reasoning guidance, information structuring आदि) की आवश्यकता है
- नवीनतम LLM में साधारण ‘प्रश्न-उत्तर’ से आगे बढ़कर, ‘समस्या समाधान के लिए आवश्यक जानकारी, tools और procedures’ को स्पष्ट रूप से मार्गदर्शित करने वाले prompt/context डिज़ाइन की जरूरत है
- साधारण prompt पर्याप्त नहीं है, बल्कि पूरे system के context डिज़ाइन (जैसे tool list, पिछली बातचीत का रिकॉर्ड, मुख्य facts आदि) का महत्व बढ़ गया है
LLM training data से ‘ब्रेनवॉश’ जैसे प्रभाव में क्यों आ सकते हैं
- उदाहरण: Grok जैसे कुछ LLM में Hitler-संबंधित Q&A पर विवाद सामने आने के मामले training data और context डिज़ाइन के तरीके से बहुत प्रभावित होते हैं
- राजनीतिक रूप से “असुविधाजनक सच” को जस का तस बताने के निर्देश, और tweets जैसी external data को तथ्य की तरह मानने वाली डिज़ाइन, अंततः malfunction का कारण बनी
- LLM दिए गए context के प्रति अत्यधिक संवेदनशील होते हैं, और उन्हें मिला data ही उनके लिए “दुनिया” बन जाता है
निष्कर्ष: LLM की प्रकृति और वास्तविक उपयोग के लिए insights
- LLM ‘context-आधारित autocomplete machine’ हैं, जो केवल इनपुट जानकारी और प्रशिक्षित ज्ञान के आधार पर उत्तर बनाते हैं
- वास्तव में वे सही उत्तर नहीं, बल्कि “दिए गए context के भीतर उचित लगने वाला narrative” बनाते हैं
- बेहतर उत्तर और अधिक भरोसेमंद परिणाम पाने के लिए व्यापक और परिष्कृत context देना अनिवार्य है
- आगे चलकर prompt engineering से भी आगे, context engineering, पूरे system का डिज़ाइन, और guardrail निर्माण LLM उपयोग की मुख्य क्षमता बनेंगे
1 टिप्पणियां
इसे पढ़कर अच्छा लगा।